[OSGeo-Discuss] Remote routing solutions

Stephen Woodbridge woodbri at swoodbridge.com
Tue Oct 6 20:11:28 PDT 2009


Excellent. I did not know about your project. Taking a quick peek, looks 
like you are doing it in Java. A few of our drivers are:

1) C/C++
2) MIT-X style license
3) build a reusable library that can be embedded in other products or 
4) Build a reference web service using our library

So we probably can't do much to collaborate on code. Ashraf has written 
some of our algorithms, but I'm pushing on using Boost Graph first and 
foremost. If Boost isn't fast or doesn't have something we need then 
we'll look at doing our own or extending Boost.

We can probably do something on the face of an Open API. We are 
currently using a simple Ajax API that I build to talk to my modified 
pgRouting from OpenLayers.


I also think it would be good to look at the appropriate parts of OpenLS 
that the OGC published as part of that focuses on Routing/Driving 
Directions/Trip Planning.


Chris Holmes wrote:
> We've actually also just kicked off an open source routing engine 
> project, attempting to collaborate with all the open source trip 
> planners we knew about at the time.
> See http://opentripplanner.org/
> We're working with Brandon of GraphServer, as well as the developers of 
> Five Points (see http://new.atltransit.com/), One Bus Away (which has a 
> trip planner) and ByCycle.org
> Focused on multi-modal, to replace the routing engine at 
> http://ride.trimet.org/ (currently the only proprietary piece of their 
> whole map).  Though we might also have a bike routing use case soon.
> Steven - it'd be great to collaborate in some way: if it's too late to 
> collaborate on code we could at least build a common API.  In time we're 
> hoping to establish a nice library of transit specific GeoExt type 
> components.  So people could easily use OpenLayers and Ext.js to compose 
> a transit map like Portland's.  It'd be great if those components could 
> talk to the same routing API, and indeed could be the start of an 
> improved open standard.
> best regards,
> Chris
> Stephen Woodbridge wrote:
>> Mateusz Loskot wrote:
>>> Folks,
>>> May I kindly ask for a bit of brainstorming about
>>> available and programmatically callable,
>>> optionally usable,
>>> optionally effective,
>>> optionally robust
>>> solutions of remote routing services?
>>> The use case is very simple:
>>> 1) client is a non-Web thin client
>>> 2) client has access to the Internet
>>> 3) client knows two locations "start" and "destination"
>>> 4) client wants to know how to travel from start to destination
>>> What are available options to achieve that? Where if availability means:
>>> * accessible for public
>>> * free of charge
>>> * does not require to sign anything,
>>> Custom solutions built on OGC-enabled stack (e.g. PyWPS, etc.) is also
>>> an option to discuss.
>>> Any input greatly appreciated.
>>> Best regards,
>> Mateusz,
>> Is the client looking for a solution that runs somewhere on the net 
>> that they can make requests to, or are they looking to setup a server 
>> with data and a routing engine?
>> So I'll plug my infant and immature routing engine project:
>> http://sourceforge.net/projects/opengraphrouter/
>> Also pgRouting is an option.
>> The big issues in most cases will be data. Some people are doing 
>> routing with OpenStreetMap and pgRouting. If they want accurate (ie: 
>> navigable routes then they will probably need something based on 
>> Navteq or TeleAtlas) or if they are look at a small county or state 
>> wide area then they might be able to get data from the local 
>> governments like http://www.mass.gov/mgis/mapping.htm
>> Because good data is expensive and licensed, in most cases by 
>> transactions, it is not likely that you will find services equivalent 
>> to Google that are free.
>> -Steve W
>> _______________________________________________
>> Discuss mailing list
>> Discuss at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/discuss

More information about the Discuss mailing list