[pgrouting-dev] Re: Network Layering support
Daniel Kastl
daniel at georepublic.de
Fri Mar 4 00:40:16 EST 2011
Hi Steve,
Thank you for sharing your ideas!
I think that your proposal of a modular approach is very similar to what
Anton and I had discussed already in the past and what we would like to
have, too. Though it's difficult to estimate how much effort and work would
be required to achieve some usable result. It would probably be too much for
a GSoC project.
Honestly I couldn't tell right now how to get started best. I'm concerned to
start something and get stuck in the middle without some usable result. It's
probably hard to work on such a change without someone volunteer or without
some funding.
It's difficult to keep an open source project active, and I would like to
know for example if Ashraf is still engaged in the opengraphrouter project.
Is he?
Daniel
2011/3/3 Stephen Woodbridge <woodbri at swoodbridge.com>
> 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
>>
>
> _______________________________________________
> pgrouting-dev mailing list
> pgrouting-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/pgrouting-dev
>
--
Georepublic UG & Georepublic Japan
eMail: daniel.kastl at georepublic.de
Web: http://georepublic.de
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/pgrouting-dev/attachments/20110304/22036f23/attachment.html
More information about the pgrouting-dev
mailing list