[OSM-dev] Seeking advice for OSM based routing application

Toby Murray toby.murray at gmail.com
Mon Mar 18 06:07:00 UTC 2013

On Sun, Mar 17, 2013 at 4:52 PM, Matt Hoover <the.one.eleven at gmail.com> wrote:
> I recently developed a fairly simple open-source application for
> creating/editing/analyzing GPX files.  It relies heavily on OSM tiles and
> JMapViewer (a JOSM component).  If interested, the beta version is hosted at
> http://www.gpxcreator.com.
> Currently the only way to create a GPX file is by pointing and clicking on
> the map repeatedly, for each point in the route.  My ultimate goal though is
> to have start-to-end routing, and I'd like it to work for backcountry
> hiking/biking/etc trails.  OSM seems to be the best map system I've found
> yet as far as having a lot of these trails included in its maps (in USA west
> coast at least, where I've looked so far).  I haven't worked much with
> actual OSM data yet (only tiles), but I understand the main way to download
> the data is in an XML format.  In trying to accomplish my goal of adding
> routing to my application, I'm faced with what I see as a few limited
> options, and none of them seem ideal.  I'd appreciate insight/advice from
> people more experienced both with OSM data and routing implementations.
> Here are the options as I see them:
> 1) Host OSM data myself and run a routing algorithm on the server.  This
> would be ideal in theory, but in reality I doubt I can afford to do
> something so big.
> 2) Have the routing algorithm run on client machine, and request the data it
> needs from OSM with each routing attempt.  This seems bad for a number of
> reasons.  Even to do a relatively short route ( < 100 miles), it seems like
> a pretty big chunk of data would need to be downloaded to the client (like
> 50MB at least in some quick tests I did).  This is not ideal for the client,
> nor is it nice to the OSM server.  Plus all that XML would need to be parsed
> on the client and re-structured into some format the routing algorithm could
> use, which would be time consuming for the client.
> 3) Use one of the existing servers which has its own data, routing
> implementation, and public API.  This sounds like a very promising idea at
> first.  However, I'm running into some weird issues, and I've tried every
> single option listed in OSM wiki.  I first tried YOURS.  See the linked
> image here, an attempted route near [38.198108, -119.883907].  The routing
> algorithm refuses to jump from the road to the trail, instead choosing to do
> a long roundabout trip.  I tried several other online routers, and they all
> made the same choice, so I naturally assumed maybe there was a problem with
> the OSM data at this point.  But I examined it up close with JOSM and the
> ways seem connected properly (though I could be mistaken since I haven't
> used JOSM much).  To make matters stranger, I finally found a single service
> (out of all the many I tried), which is able to route correctly across that
> junction!  This service is BRouter, which the linked image here shows
> performing as desired.  However, BRouter does not have a public API, so I
> would seem to be out of luck for all options here.
> 4) Client side routing logic using OSM server-side data?  The routing
> algorithm would make many single element requests to the server, as it runs,
> downloading individual nodes/ways needed for the routing, rather than all
> data in vicinity as in option 2 above.  I don't even think this is a
> legitimate idea, since I would guess that there would be way too many
> messages sent back and forth between client and server, and communication
> cost would be far too expensive (though overall amount of data downloaded
> would be far less than option 2 above).  But the idea crossed my mind so I
> figured I'd add it to the list.  Maybe I'm wrong here though and the
> communication cost is affordable?
> Are the any other options I've missed?  Are any of my considerations of
> these 4 options wrong?  Which is the best option for my situation, in your
> opinion?
> Thanks in advance for any advice anybody can offer.  I really appreciate it.

Well options 2 and 4 are absolutely not feasible, assuming you are
talking about using the osm.org map query API. The OSM API is for
editing the map only, not for clients to query for use in some 3rd
party service. Of course some small non-editing related calls get
through but if you start querying a lot of data you will get blocked
pretty quickly. For non edit related querying there are other services
like jxapi or overpass. But even then, this does not sound like the
best idea.

The specific example you linked to does seem very odd. It does look
like the MapQuest Open routing service behaves correctly thought:

Looking on a couple of other routing services, the OSRM demo is set
for cars only so it won't even try to go on the highway=path. No clue
where the cloudmade router's head is. It will obviously use
highway=path but for some reason it is refusing to transition to it
right there. I can't figure out why either.


More information about the dev mailing list