[GraphHopper] Public Transport Support

[Thomas Bürli]

Thanks for your feedback.
> Did you already had a chance to test this on some real data? E.g.
> in an adapted web view?
Not yet, but it is on my todo list.

> I saw you were using a specialized Location2ID index, but I think you
> can use the more memory efficient Location2NodesNtree where you add all
> the different nodes of the same location (in prepare()) and on retrieval
> you iterate over those matching node ids and return the closest AND the
> ones matching your startTime (or even a startTimeInterval). Later on it
> will be relative easy to improve query times for bigger stations with
> lots of departure/arrival times (via deeper nesting of the n-tree) but
> for now not necessary I guess ;)
I was not sure how to encode the entrance node ( the node which represent a station at midnight). Therefore I went for the easy approach and added the node on graph generation
  to the index. But I will take a look into it.

> BTW: instead reader.debugPath(p1) I would probably use more unit tests.
> So that it can be run automatically.
Agree.
> BTW2: when I have a route are the all gps coordinates in the GTFS file
> (start station+end station+intermediate points without a station) or
> would I need to fetch this information from another source like OSM?
There is a shapes.txt in GTFS which describes how a route is drawn (see 
https://developers.google.com/transit/gtfs/reference#shapes_fields). But 
it is optional and what I've seen, it's usually not provided.

Regards,
Thomas

On 06/01/2013 03:43 PM, Peter K wrote:
> Hi Thomas,
>
>> So, I implemented a very rudimentary public transport support for
> graphhopper.
>
> nice! Did you already had a chance to test this on some real data? E.g.
> in an adapted web view?
>
> I saw you were using a specialized Location2ID index, but I think you
> can use the more memory efficient Location2NodesNtree where you add all
> the different nodes of the same location (in prepare()) and on retrieval
> you iterate over those matching node ids and return the closest AND the
> ones matching your startTime (or even a startTimeInterval). Later on it
> will be relative easy to improve query times for bigger stations with
> lots of departure/arrival times (via deeper nesting of the n-tree) but
> for now not necessary I guess ;)
>
>
>> I choose the time-expanded approach mostly because I didn't know how a
> time-depended graph should be implemented.
>
> Ok. For bigger areas a time dependent approach is probably the best in
> terms of memory usage. (but not sure)
> To do this a completely new GraphStorage has to be developed, probably
> one needs to extend or adapt the Graph interface as well.
>
> BTW: instead reader.debugPath(p1) I would probably use more unit tests.
> So that it can be run automatically.
> BTW2: when I have a route are the all gps coordinates in the GTFS file
> (start station+end station+intermediate points without a station) or
> would I need to fetch this information from another source like OSM?
>
> Regards,
> Peter.
>
>
>> Hi,
>>
>> So, I implemented a very rudimentary public transport support for
>> graphhopper.
>>
>> It works with a time-expanded graph like it is described in
>> http://d-nb.info/1001586921/34. I choose the time-expanded approach
>> mostly because I didn't know how a time-depended graph should be
>> implemented.
>> A unit test is added which show how the GTFSReader is used and how
>> routing can be done.
>>
>> You can take a look at it at
>> https://github.com/initdch/graphhopper/tree/feature/GTFS . I would
>> appreciate your feedback.
>>
>> Regards,
>> Thomas
>
> _______________________________________________
> GraphHopper mailing list
> GraphHopper at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/graphhopper

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/graphhopper/attachments/20130603/4ebbf6be/attachment-0001.html>