Notices

That's a good question! The overall online routing situation for modRana is not ideal at the moment, as modRana currently only supports some old Google provided routing API which AFAIK might be reaching it's end of life soon.

This is less serious on Sailfish OS due to the glorious offline routing API provided by OSM Scout Server, but much more of a problem for the N900, where OSM Scout Server is not available & the old Monav based offline routing is often far from ideal.

Trying now on desktop with the Google online routing provider - and I'm getting failures. So looks like they might have already shut down the old API modRana uses & an alternative will be needed. Yay.

Not just yet, but it's planned & coming soon (tm).

Basically the idea is to parse the command line arguments the launcher gets, and then decide what to do next. There are basically two options:

1) The command line arguments are not related to the modRana GUI (stuff like --help, adding a POI via CLI, etc.). In such a case the launcher will run modrana.py and pass it the arguments, expecting it to handle the CLI use case by itself.

2) The command influences the modRana GUI. This could be telling modRana which UI variant to launch or request to perform an action on startup (zoom on certain coordinates, serach for a POI, perform routing & start navigation, etc.). In this case the launcher would pass the arguments to the GUI and start it.

At the moment I'm thinking about doing just very simple argument parsing in C++, just to tell me if some arguments have been passed or not - actually, I guess it might be enough to just check the number of arguments.

If some arguments are found, the launcher would run modrana.py in some special mode which would tell it what to do next - terminate (if modRana already performed the CLI task) or to start the GUI (if the task requested is GUI related). If this works out, I should be able to avoid duplicating the option parsing logic in C++ in the launcher, even partially.

Nothing of the above should really be relevant for the user, they would just type (once implemented):

And then use one of the command line options available.

Much appreciated!

@MartinK: you could add Stadia Maps as an online router. It's the same Valhalla router as in OSM Scout Server and was free for a decent amount of calls and they probably will not get exceeded. Since router is the same, you would probably not need much to code to use it.

Martink, is there a file that I could python scrape out turn by turn instruction events from?
I am hoping to add some GPS navigation event transfers for Maebble(Pebble watch daemon) for an easy to see turn by turn and maybe distance countdown or speedometer that cyclists and automobile drivers could use. If possible I will make it like an SMS or email event push so I dont need to figure out how to write a special watch app(probably will never happen).
I was also thinking of an approximate boundary near arrival to be used for bus and train travellers to know the correct stop or station.
Be aware I am looking for the lazyest way to do this I am not a real dev and have only minimal debuggind skills. If this works I will add it to the garage and maybe even try to get it into the repos.
Maebble http://talk.maemo.org/showthread.php?p=1559017

Do you mean some piece of Python code you could reuse from modRana to return you turn by turn navigation instructions, which you could then show in your app ?

I'm afraid the routing situation @ modRana is currently less than ideal, as online routing is currently broken & I have not yet got to fixing it (as rinigus suggests a post above).

For offline routing, the OSM Scout Server using code might be usable but that's of course Sailfish OS only, so likely not usable for your Maemo 5 app.

I am just looking for an easy way to get the turn by turn instructions out into a parseable format.
An intermediate script might work but I am a cut-paste-tweak-pray kinda non-dev.
I am just trying to cobble a crappy but simple hack similar to parsing the dbus event stream. By similar I am meaning almost identical so I can reuse edited lines of code from the currently working maebbled.py

HI MartinK,
I tried modrana offline mode on N900 as descripted in maemo-wiki. I unzipped tile-file on my linux-laptop, then copied via usb cable to correct folder on N900. But it works only in N900-ONLINE-Mode. Switch to offline, "tile download failed" displayed on map... Turned to online mode it works... Network-Settings in modrana are on "unlimited use of network".

How to enable correct offline-mode?

Thanks!

For anyone interested support for N900 has ended.
https://github.com/M4rtinK/modrana/pull/287
I believe there will still be a fair few N900 users that should be made aware of this here.
It's a shame but I can understand this especially with python and GTK2 support disappearing.
One request i would have would be to get the last version into extra-devel if possible.
I think we spoke in the past about updates and that less devs have a build environment available but at least N900's would have a more upto date version in the repo if this was done.

Well with Leste coming along well maybe the dev will change their mind or maybe it will be easier to port?

Always sad when software support ends on Maemo. But like you said it understandable.

x

I'm afraid that the only fully offline mode supported by modRana on the N900 was the rudimentary offline routing based on Monav. Tile display was always working with map tiles downloaded from the internet. You could batch download it, but that was pretty much it.

The situation is much better on Sailfish OS devices & on desktop Linux. There modRana can talk to OSM Scout Server, which provides offline tile rendering, routing and PoI search.

Yeah, I planned to do an announcement here, likely as part of next version release notes, but might as well do it now.

BTW, I really wonder how many users are actually affected - the version in Extras has really not been updated in a while, mainly do to most of the recent work & fixes not really affecting the parts of modRana in use on Maemo. I guess that also kinda implies the code duplication that has been in place up till now. :P

Pretty much - for some time this was an interesting exercise in keeping a non trivial application compatible with a wide range of Python versions (2.5-3.4/3.6). This experience came really handy at work at Red Hat when I helped to port the Anaconda installer used by Fedora/CentOS/RHEL to Python 3.

Still I don't think supporting Python 2, especially the ancient Python 2.5 needed for the N900 is viable anymore, with Sailfish OS upgrading to 3.7 a while ago, Python 2 going EOL this January & Fedora and other distros getting ridd of Python 2 software where possible.

Another issue is also the original GTK2/Cairo GUI - back then it really was the best option given the environment (first the Neo FreeRunner & early N900), but things changed quite a bit since then.

Newer GUI technologies, such as Qt 5/QML make achieving what modRana needs in it's interface much easier, nice, faster and more responsive with far lesser amount of custom code & hacks needed to achieve the desired end result.

Also let's say I can write much better code now than I did 10 years ago + not all design decisions I did back then turned out to be good. ;-)

So this really had to be done & would likely be done much sooner in another project - but at least we can celebrate the 10th modRana aniversary with a bang! :-)

(I started working on modRana for my bachelors thesis at the end of Janury 2010.)

Hopefully this change will make the source code of modRana much more readable, fully Python 3 compatible & more unit-testable. Also potentiall contributors will be much less likely to run away screaming when they no longer see modules full of Python 2/3 compatible code mixed together with direct drawing of screen content via Cairo vector commands. ;-)

I have actually created a N900 specific branch in case some fixes would be needed after Python 2 & GTK2 support has been dropped from the master branch:

https://github.com/M4rtinK/modrana/tree/n900-branch

That could be a good starting point for such an update effort. Still, I'm not sure I will still be able to generate the needed source-deb file, not to mention being able to talk to autobuilder in the correct manner.

Assistance of someone who still has the necessary tools available would be definitely welcome.