[pgrouting-dev] Re: Network Layering support

[Stephen Woodbridge]

Daniel and PSC,

So the opengraphrouter project that I started and was home to a couple 
of Google Summer of Code projects has stalled out. But the concept of 
building a library that could be used standalone or integrated in 
pgRouting or maybe some other databases or projects still has appeal if 
not downright desirability.

I'm wonder is this might not be a good place to implement the CH code. I 
would be all for moving the project management and ownership under the 
pgRouting PSC.

I think this would give us more opportunity to be more inclusive of 
other projects and to get other developers to contribute to a common, 
multi-use routing project. Then pgRouting would just work on wrapping 
the libraries and embedding them in postgresql.

We would need to discuss how to modularize the components for reuse, but 
just off the top of my head I'm thinking something like:

o routing engine solvers
   - dijkstra solution
   - A* solver
   - shooting star solver
   - CH solver
   - etc
o specific data readers
   - shapefile reader (simple generic, vendor specific, ie Navteq)
   - OSM data reader
   - SQL table data loaders
   - etc
o data storage managers
   - PostGIS
   - SpatialLite
   - SQLite
   - Our data file
   - etc
o solution post processors
   - drivetime contours
   - TSP
   - Driving Directions
   - etc

Anyway, this needs some thought, but you get the idea. Each of these 
could be a library with an API that make is easy to mix and match the 
components.

I would be interested in your thoughts on this.

Best regards,
   -Steve

On 2/18/2011 8:57 PM, Daniel Kastl wrote:
> I may have written this already, but in case I didn't do yet:
> OpenTripPlanner also seems to have an implementation of CH:
> http://opentripplanner.org/browser/trunk/opentripplanner-routing/src/main/java/org/opentripplanner/routing/contraction
>
> Though their license is LGPL. How does this work?
> Because it's their own implementation?
> http://opentripplanner.org/browser/trunk/opentripplanner-routing/src/main/java/org/opentripplanner/routing/contraction/ContractionHierarchy.java#L66
>
> Daniel
>
> <http://opentripplanner.org/browser/trunk/opentripplanner-routing/src/main/java/org/opentripplanner/routing/contraction>
>
> 2011/2/19 Daniel Kastl <daniel at georepublic.de
> <mailto:daniel at georepublic.de>>
>
>     Hi Jay and Steve,
>
>     This email is getting very long, so I will shorten it a bit.
>
>
>
>                     * http://routingdemo.geofabrik.de/
>                     * http://sourceforge.net/projects/routed/
>
>                 It uses contraction hierarchies algorithm.
>
>
>
>             Thanks for the links. Are you certain that the above project
>             uses
>             contraction hierarchies algorithm by Robert Geisberger? I
>             went thru the
>             source, and they are using contraction, but I did not see
>             where they
>             have used the node ordering step as proposed in the CH
>             paper. I did not
>             find contraction hierarchies mentioned in their readme too:
>             http://sourceforge.net/apps/trac/routed/wiki/ReadMe
>
>
>         It is possible that they read the paper and made their own
>         implementation to avoid the AGPL license. The paper is describes
>         the algorithms in great detail, so I'm sure this is possible.
>
>
>     The notice I read through Twitter:
>     http://twitter.com/#!/geofabrik/status/38579590834159616
>     According to this is uses CH. And the license is AGPL as well.
>
>
>                  If we are using the code already made available thru
>             AGPL (I dont
>             understand the intricacies of different licences) by Robert
>
>
>         I think we need to read and understand the AGPL license and how
>         it might impact on the current license. These are tricky issues
>         and it might prohibit us from including their code directly.
>
>         If we wanted to do that we could still use the AGPL code to
>         build test model that would allow us to validate the our code
>         was getting reasonable results.
>
>
>     As far as I understand AGPL is more strict than GPL in terms of
>     services delivered with this software. So if you offer a routing
>     service with this software, you need to also give access to the
>     source code to the users of this service (GPL licensed software only
>     cares about the software you pass to someone).
>     This is probably something that not every pgRouting user would be
>     happy with.
>
>     Daniel
>
>
>     --
>     Georepublic UG & Georepublic Japan
>     eMail: daniel.kastl at georepublic.de <mailto:daniel.kastl at georepublic.de>
>     Web: http://georepublic.de <http://georepublic.de/>
>
>
>
>
> --
> Georepublic UG & Georepublic Japan
> eMail: daniel.kastl at georepublic.de <mailto:daniel.kastl at georepublic.de>
> Web: http://georepublic.de <http://georepublic.de/>
>
>
>
> _______________________________________________
> pgrouting-dev mailing list
> pgrouting-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/pgrouting-dev