Martijn - It looks like Mapillary has updated their sign naming convention a bit now that they’re recognizing more signs, which seems to make all their signs show up as question marks in the ScoutSigns plugin (they also disappear if both the Skobbler and Mapillary signs are enabled). Any chance of an update to fix this?

Very exciting. Now the race is on between Telenav and Mapillary to get US speed limit sign recognition working. :)

In the St. Louis airport example you have, there were roads there in that neighborhood until about a decade ago, until the “white elephant” new runway was built displacing the community. So TIGER was accurate-ish a while ago but has been overtaken by events.

I’ve been working on the code a bit using the data from the link above. I’ve fixed a few performance issues and a few real bugs so far… but it’s still slow. I really need to do some optimizations in the path search code as well. I’ve never run it on so much data before (typically, areas substantially smaller than what the OSM editing API will allow, with fewer source traces), so this is a bit of a learning experience! This feedback has really helped improve the code and is starting to push me to improve its documentation.

The good news is that once I have the bugs worked out and some more optimizations done I think parallelizing the remaining computation-intensive code (mainly calls to dist2Line, which involve a lot of floating point math) will be fairly easy.

Sorry, misunderstood - thought the Oct 31 post was using osm-makeroads. I’ll definitely investigate what’s going on in the GPX data you provided.

Hello! Glad to see someone using osm-makeroads. I have been working on a few speed improvements the last couple of days, but there are still issues to be worked on of course - I definitely want to add some multicore support, so I’ve been refactoring the code to make that possible.

Even so I’m a bit surprised it took 18 hours on a Phenom II X2; I have a Athlon II X4 630 (which should be similar performance-wise). I’ll download the GPX data you used and see what the bottleneck is; it may be memory usage rather than CPU speed (I haven’t paid much attention to memory usage yet).

There is a poorly documented method to bring in GPX files directly (avoiding the need to download it from the API), if you use getOSMtracksFiles() instead of getOSMtracks(). You can also rearrange the bbox setup lines to the order you’re comfortable with (and getOSMtracks doesn’t mind if you accidentally swap left/right and top/bottom).

I’ll comment on the fit quality issues on your Oct 31 blog.