Notices

I experienced something similar to what sixwheeledbeast experienced - crash while logging a track using modRana. A while after starting this a system hang occured. After some time I unlocked the phone I saw a lockscreen with the time shown as half an hour ago.

Btw. do you have any progress on the mapnik maps? It's something I'm really anticipating and modRana is absolutely useless if you go abroad or to some place with poor signal (or without signal at all)

I don't know if it's usable after last reports, but I have collected some outputs from terminal in cases where ModRana crashes. Posting only one here, as it all seems to boil down into the same cairo-related lined at the end.

As a side note, those crashes are happening *very* often here - i.e. it's guaranteed that it will crash, if I try to have it navigating me for an hour (sometimes, it crashes after just few seconds...). For sure it wasn't the case few versions ago.

Output:

Sometimes, it lacks the "aborted" part (crashes before aborting?).

Cheers,
/Estel

I have noticed few things that might help in debugging the issue:

1. Every action that involves redraw due to user input works much slower than it used in the past. I mean things like moving map around, or changing zoom. It is noticeably more "sluggish".

2. Every time you zoom in or out, there is noticeable delay between action and the "zooming in/out to n" popup appearing. Also, zooming is the most common case when ModRana crashes (but in can crash while just dragging map around).

3. What's very interesting ModRana *won't* crash, if it's left alone - i.e. without any user input - even if performing resource-heavy tasks, like centering map on location, rotating map in direction of travel, and logging track (all at the same time). Despite fact that it redraws map a lot while traveling, it won't crash, tested for many hours. It seems to crash only if user is doing anything, actively.
---

From a different barrel - I've been playing with customizing modes (foot, bike, car, etc), and found some issues and few areas where slight improvements could be made:

1. [foot] mode customization doesn't work, like, at all. You can change every other mode without problems, but whatever you put in [foot], this mode will look exactly as it looks by default.

2. Would it be possible to make OSD items using the "offset" variable too, like menu items override? Without it, making speed indicator stick to right down corner involved ton of trial&error guesswork positioning.

With offset, such operations would be as easy as giving it px 1.0, py1.0, offsety -1 offsetx -1. And it's just one of the situation where having the same positioning tools as for menu items would be very handy - there are tons of other.

Also, without such flexible positioning, it is impossible to make layouts that work both for portrait and for landscape, at the same time. Following my example, the speed indicator that is made to "Stick" into right down corner in portrait, will be half-hidden under screen in landscape. Icon size offset would fix it (and does so for override interface items).
---

Another small feature request, unrelated to the above - currently, we have a centering mode with shift in ModRana, which shifts our location by set amount of %, allowing to view more road ahead. Sadly, it works *only* if we have "rotate map in direction of travel" thing enabled, otherwise, current location is always in the center.

My request is to make it shift (relatively to direction of travel) even if we're in the mode that keeps north up. So, if we're traveling east, location would be shifted to the left, if we're going north, location would shift to the south, etc - all with map still having north "up".

Of course, manually dragging map would still disable any shifting, just like it does now, with respect to all existing settings (what kind of drag disables centering on location, etc). I don't see how it could conflict with any existing feature/option, and would help much in many, many situations.

Cheers,
/Estel

estel, are u using latest thumb release? wondered if slowdown could be related to the libc issues experienced by others

Nope, I'm on some older version - my libcairo2 is:
1.8.8-0maemo1+0m5+thumb0

...and libc6 is:
2.5.1-1eglibc27+0m5+cssu1

/Estel

For the record, I am on thumb...

EDIT:
ldconfig -v says:
libc.so.6 -> libc-2.5.so ???




and completely unrelated, Estel for president

fair enough, just thought i'd so as to eliminate it.

The non-free upload is back working. Should I upload mapnik there (although it uses thumb gcc)?

What does that actually mean ? Will only people running CSSU Thumb be able to use it ? Will it be faster ? (BTW, I'm already on CSSU Thumb, so I'll be able to use it/test it even if it really is Thumb only).

BTW, I plan to FINALLY checkout your Mapnik Python bindings this weekend & will report back my findings. Thanks yet again for the porting effort!

In other news:
The modRana global Monav offline routing data repository has been updated!
The whole 146 GB dataset is yet again up to date to the OpenStreetMap data state as of 26. June 2014. Enjoy!

Where can I find the repository ?
http://data.modrana.org/monav/

How can I use it ?
Check the modRana offline routing guide on the wiki.

Do these 6GB continental Europe & co routing data packs even work on the N900?

YES!
A 3000 km route with 136 turns from the literal End of the World to Vienna - took about 60 seconds to compute on the N900, but seemed to work fine. Shorter trips seem to take the same time to compute as with the smaller data packs.

Acknowledgment
A huge thanks yet again goes to the Natural Language Processing Centre at the Faculty of Informatics, Masaryk University in Brno. Without their help it would not be possible to generate and host such huge global routing data set! Thanks!