Sounds like a plan.

Nope, I've never quite understood the scaling options, so I've never changed them. I'm actually quite unclear on why I'd want one vs the other.

The 30 second thing would fit in place with what I saw. I also had an issue near the end of the trip where it was on/routing for 4+ hours where it complained about "Operation canceled due to lack of memory". I "fixed" that by closing and restarting the app though, as I was semi-lost at the time.

I will... how big are the logs it generates with normal usage? If they're small I may just turn it on and let it log everything, then chop out the parts I need later for issues. (I need an on-screen debug widget/button! )

I always like option 3: User setting to choose which one.

There was mention in the article about another project for N900 using it. You may be able to get hints on it from that package maintainer? If you're not hitting a wall yet though, no big reason to pull it in right away. If on-device tiling causes contention later though, this may be helpful.


Wow.. nice map. What profiler are you using to generate that? Is it just for python? I code mainly in C/C#/C++, so not too familiar with python and it's tool set. Nice look to it though.

Hmm... Odd. It's been much better about warning 3 to 4 miles out since the update to 19. Maybe it works better on trips with longer distances between points? Is the length of the segment used at all to compute how early to trigger?


Overall, sounds like you've got plenty on the plate to work with. I'll happily test things out with new releases as they come out! I'm also hopeful to getting things setup (build env, etc) this weekend to start porting the tile server. I probably won't have a release before Monday, but if things go smoothly... we'll see.