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

Matt Hoover the.one.eleven at gmail.com
Sun Mar 17 21:52:13 UTC 2013

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
See the linked image here <http://i.imgur.com/6zRhDB3.png>, 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 <http://brensche.de/brouter/>, which the linked image
here <http://i.imgur.com/Cx5fZ6n.png> 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

Thanks in advance for any advice anybody can offer.  I really appreciate it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20130317/a7d6484b/attachment.html>

More information about the dev mailing list