<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">
<pre wrap="">Thanks for your feedback.
<blockquote type="cite"><pre wrap="">Did you already had a chance to test this on some real data? E.g.
in an adapted web view?
</pre></blockquote>Not yet, but it is on my todo list.
<blockquote type="cite"><pre wrap="">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 ;)</pre></blockquote>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.
</pre>
<blockquote type="cite">
<pre wrap="">BTW: instead reader.debugPath(p1) I would probably use more unit tests.
So that it can be run automatically.
</pre>
</blockquote>
Agree.<br>
<blockquote type="cite">
<pre wrap="">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?</pre>
</blockquote>
There is a shapes.txt in GTFS which describes how a route is drawn
(see
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
<a
href="https://developers.google.com/transit/gtfs/reference#shapes_fields">https://developers.google.com/transit/gtfs/reference#shapes_fields</a>).
But it is optional and what I've seen, it's usually not provided.
<br>
<br>
Regards,<br>
Thomas<br>
<br>
On 06/01/2013 03:43 PM, Peter K wrote:<br>
</div>
<blockquote cite="mid:51A9FA86.7020304@yahoo.de" type="cite">
<pre wrap="">Hi Thomas,
</pre>
<blockquote type="cite">
<pre wrap="">So, I implemented a very rudimentary public transport support for
</pre>
</blockquote>
<pre wrap="">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 ;)
</pre>
<blockquote type="cite">
<pre wrap="">I choose the time-expanded approach mostly because I didn't know how a
</pre>
</blockquote>
<pre wrap="">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.
</pre>
<blockquote type="cite">
<pre wrap="">Hi,
So, I implemented a very rudimentary public transport support for
graphhopper.
It works with a time-expanded graph like it is described in
<a class="moz-txt-link-freetext" href="http://d-nb.info/1001586921/34">http://d-nb.info/1001586921/34</a>. 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
<a class="moz-txt-link-freetext" href="https://github.com/initdch/graphhopper/tree/feature/GTFS">https://github.com/initdch/graphhopper/tree/feature/GTFS</a> . I would
appreciate your feedback.
Regards,
Thomas
</pre>
</blockquote>
<pre wrap="">
_______________________________________________
GraphHopper mailing list
<a class="moz-txt-link-abbreviated" href="mailto:GraphHopper@openstreetmap.org">GraphHopper@openstreetmap.org</a>
<a class="moz-txt-link-freetext" href="http://lists.openstreetmap.org/listinfo/graphhopper">http://lists.openstreetmap.org/listinfo/graphhopper</a>
</pre>
</blockquote>
<br>
</body>
</html>