Routing on OpenStreetMap.org
blog.openstreetmap.org
blog.openstreetmap.org
I sort of wish the router got open sourced, but then again it was not great for long distance routing since we were doing mostly local stuff. For example, routing across the US would have taken pretty close to exponential time.
Interestingly, we could not make Google Maps, or any other maps work for this besides OSM for two reasons: the data wasn't good enough and the roads were not uniquely and stably identified in the routes these API's produced.
Lastly, I will say that the biggest challenge to using OSM at scale, aside from varying quality of data was lack of good servers and documentation. Some of their secondary services run on one-off slowish hardware with pretty strict rate limits. We would run our own, except the documentation (and the packaging) for OSM software was leaving something to be desired. That is to say if you want to help OSM, there are plenty of ways to do so.
This is exactly why we've exposed routing on the front page of osm.org.
I run my own site with OSM-based routing, http://cycle.travel/map . When I first got the routing engine up and running, I literally spent the next fortnight fixing routing bugs in OSM - "I'd go that way, why doesn't the router agree?".
By putting routing front-and-centre, we're hoping that our dedicated contributors - and OSM contributors are nothing if not dedicated! - will do exactly that: they'll find an error and fix it. In the UK and Germany this'll just be little slip-ups, turn restrictions and so on, but in the US there are whole counties that need serious fixup.
That's why I submitted the pull request for this[1] and why I'm delighted it's now live. OSM is already a great display map; by making routing more visible, we can make it a great routable map too.
[1] https://github.com/openstreetmap/openstreetmap-website/pull/...
The various services on openstreetmap.org don't have terribly strict usage policies, but they all pretty much ask heavy users to set up their own instance (or use other resources; for example, Mapquest has quite generous free usage, and there are lots of paid OSM tile hosters).
If you click the stack on the right tool bar, you get a layers menu, where 4 of the styles are rendered and served by other projects. So the routing is similar to that, showcasing how the data can be used.
However, all these compromises on the front page are too complicated for end users and scare them off.
End users expect services that seamlessly work together. If centralization is needed to achieve that, then yes, OSMF needs centralization.
People find it hard to get out of the "Google Maps" mindset, just as everyone approached Linux as a "Cheap Windows" when in reality it can be so much more.
OSM's strategy (and data) aren't perfect, but they're growing the pie rather than fighting for a larger slice and doing pretty well with it. Just like using Linux has become a no-brainer for all sorts of projects from smartphones to supercomputer clusters to educational toys OSM is well on it's way to being the default peer-produced commons for geographical data. Whether that usage happens on one site or a million different commercial, government, non-profit and amateur sites isn't important.
The interest generated by this change demonstrates your point well enough, OSRM has been available at http://map.project-osrm.org/ with worldwide coverage for quite a while, and the other projects are also up for quite a while.
I even see a bunch of OSM enthusiasts who were apparently oblivious to the availability of the routing services (saying 'wow, it works good' sort of indicates they haven't seen it work before).
Secondly, if these projects already exist and are easy to integrate, I fail to see why it should be problematic for OSM to use them. OSRM is completely open source, anyone can spin up their own instance if they wanted to, so someone else can host it if the current server goes down. Open source routing engines like OSRM exist so that OSM doesn't need to roll their own. I'm having a hard time wrapping my head around how you construe this to be a bad thing.
Instead the community should be on the OSM site and contribute to open layers hosted on the official page and open routing code so that the OSM map data can be tuned for it. But apparently it goes in the opposite direction :(
Well everything has a cost and while OSM wants to make their website useful for mappers you shouldn't rely on data API to build a business. For example for the geocoding service there are quite a few abusers who'd run (or try) 1 million requests per day. The hardware is actually quite fast and expensive.
(I'm biased. We're running a geocoding SaaS based on open data http://geocoder.opencagedata.com/)
It's a great example of how theoretical CS research can have a huge impact on practical applications.
http://en.wikipedia.org/wiki/Contraction_hierarchies
http://algo2.iti.kit.edu/documents/routeplanning/geisberger_... (PDF)
https://github.com/Project-OSRM https://github.com/graphhopper
Please do elaborate! I often spend a lot of time just figuring out what the best practices are to map. I'd like to make the map data perfect for all uses but I don't know what kind of tags are needed when I'm mapping.
Another common example is one-way streets. If you have several sections of a street with conflicting one-way markings like this:
----> . <---- . ---->
then the street becomes unroutable (assuming no intersections at the .s). I found this was a fairly common issue on the entry/exit flares at roundabouts.http://wiki.openstreetmap.org/wiki/Quality_assurance#Error_d...
http://wiki.openstreetmap.org/wiki/TIGER_fixup/250_cities
They just started with the most important connectivity problems and worked their way down. As the data improved more and more corporate users found it close enough for their needs and started contributing the fixes they needed in a positive feedback loop.
There's now various commercial organisations either fixing the map directly for their own benefit or providing lists of issues for the community to address through projects like Maproulette (http://maproulette.org/) which can point you to random (or nearby) issues for you to fix based on various automated checks (e.g. rivers running uphill) or open data like a list of soccer pitches in France.
This is most likely to be fixed in the medium term by moving to vector rendering via WebGL et al.
It looks as though OSM is making great inroads as far as routing and addresses go, and so the next big thing will be getting the iD editor working well on mobile devices.
There's also not much fuzziness in the search. For example, "Tolado Ohio" will not be found.
It kind of demonstrates how far behind they are with things like navigation, search etc. It's a shame because the actual mapping data behind OSM is absolutely fantastic.
To quote from the link "Well, the first thing to note is that the philosophy of OpenStreetMap is not to offer a one-stop-shop on our main website, but to create truly open data to empower others to do great things with it."
The search has always been... odd, though.
I really want OSM to be good for this sort of thing, so I'll probably end up poking around and fixing the errors that led to this mess.
We don't have as strong a community in the US. In SF, NYC etc. the data's pretty good. In rural Nevada it... isn't. It's still raw untouched TIGER (US census data) in most places.
So: hell yes, poke around and fix it. We would love OSM to be as good in the US as it is in Europe. And if anything isn't clear, pop in here or on IRC and ask. We're a friendly community.
It's probably issues with OSM's data rather than the routing mechanism itself, however, so yeah, it should be possible to poke at it a bit and fix things up (as I likely will do, being no stranger to OSM editing myself).
Instead of picking up that the address was in suburb "A", it put it inside "Ward 47 of Tshwane", Tshwane being the city/municipality. Perhaps the data for suburbs is not up to scratch in my particular area.
Likely a missed opportunity for a big exit for me, but life's too short to work against poor-quality crowd-sourced data as a one-man startup in Venice.
It's a classic open source problem: pack in the functionality, but not be entirely sure how best to present it, so provide everything with lots and lots of switches for power users to toggle what they want.
Starting out with less stuff might help; starting out remembering to go to the map would, I suspect, be a great UX experience for a map app.
For your usecase, have a look at mapswithme instead. It's proprietary but very neat. Does only the basics but does them well.
There are plenty of mobile apps using OSM data, some of them high quality and improving regularly. If one app doesn't suit you, look around. Have another look if you last tried many months ago.
* https://alpha.openaddressesuk.org/
...which is still only in alpha, so don't expect much. Read their posts about the data sources (https://alpha.openaddressesuk.org/about/docs) to see why this is in such a bad state.
That said, OSM's geocoder has a few issues with postcodes at present: https://trac.openstreetmap.org/ticket/2497 . The second para of lonvia's final comment is the crux - "[postcode updates are] a very expensive operation and so the centroids don't get updated and postcodes go stale with time".
No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://www.openstreetmap.org' is therefore not allowed access.Car routing only for OSRM. Is this something which will be fixed?
Also egregiously missing is the ability to create a link to a pre-made route.
http://www.openstreetmap.org/directions?engine=osrm_car&rout...
I’m assuming I missed it. Sorry about that.
Do you know of any other alternative routing libraries that can be used with OSM data similar to pgrouting?