Sean,
thank you for your answer. You are absolutely right, the problem of
extracting vehicle routes from OSM data can get very complex and has
various pitfalls. We have experimented with simple map matching
approaches where station positions were understood as very sparse sample
points, but personally I think this approach is not the best and yields
suboptimal results.
However, we achieved very got results by using iterative shortest-path
(Dijkstra) calculations for each trip and between each station on a
network graph (for example OSM). This respects the fact that each trip
of a route can have its own shape. The shortest-path algorithm can be
implemented with special cost functions for each vehicle type (for
example, trains making a u turn out of a station should be punished).
Our application is still in a very early state of development, but
already produces usable results.
With this approach, it could be possible to quickly import bus routes
into OSM that aren't yet represented there at all. These routes would
have to be checked and corrected by hand, of course, but we
expect the station-to-station-shortest-path shapes of bus lines to be
nearly equal to the "real" shapes.
This is, of course, a top-down approach, and tools like TransitWand tend
to be more exact because someone actually rode on the vehicle. However,
for rural areas with low-density road networks and very few transit data
enthusiasts, such an approach could be used to fill gaps in the data.
Patrick
--
web www.geops.de
rss www.geops.de/blog/feed
follow www.twitter.com/geops
On 08/04/14 00:22, Barbeau, Sean wrote:
Patrick,
Thanks for the feedback! If I recall correctly, we do have a basic
route info sync, but it’s meant for route properties, not the spatial
representation of the route. You can view the route diff view here:
https://code.google.com/p/gtfs-osm-sync/wiki/GettingStarted#Report_Route_Viewer
However, I believe MapQuest’s XAPI changed shortly after we implemented
this and removed the ability to get route information, and the feature
currently isn’t functional.
Routes can actually have several shapes based on the trip_ids and
stop_times that run on different schedules or stop sequences. So, this
can get very complex and depends on temporal information as well. In my
opinion this would be a significant undertaking, and as I mentioned
earlier I’m not convinced that maintaining temporal information in OSM
is the best way to represent/store the data.
No future plans to include such functionality as of now (our work is
grant funded, and we currently don’t have funding source to continue
development), although we’d be glad to accept contributions if someone
else wants to take this on.
On a related note, I think tools like Transit Wand have a lot of promise
in assisting agencies/others in creating more accurate shapes.txt
information:
http://transitdata.openplans.org/
Sean
----------------------------------------------------------------------
Message: 1
Date: Fri, 04 Apr 2014 14:36:25 +0200
From: Patrick Brosi | geOps <patrick.br...@geops.de
<mailto:patrick.br...@geops.de>>
To: talk-transit@openstreetmap.org <mailto:talk-transit@openstreetmap.org>
Subject: Re: [Talk-transit] GTFS and the like
Message-ID: <533ea749.5080...@geops.de <mailto:533ea749.5080...@geops.de>>
Content-Type: text/plain; charset=windows-1252; format=flowed
Sean, it would be interesting to know whether GO-Sync's processing
includes the GTFS route shapes (the exact vehicle paths stored in
shapes.txt) in any way. For example: if the GTFS feed only covers the
location / attributes of stations and is missing shapes.txt information,
does GO-Sync try to extract these shapes from OSM data? If so, what
approach do you use? How are existing shapes compared to data already
existent in OSM?
Many public transport companies have very good data regarding the
position of their stops, but lack the exact paths vehicles take between
succeeding stations. In my opinion, providing not only the possibility
to extract these shapes from existing OSM data but also the tools to
edit them via OSM would dramatically increase the geospatial quality of
many GTFS feeds.
I just browsed GO-Sync's paper and couldn't find anything relating to
this problem. Are there any future plans to include the functionality
described above?
Thank you!
Best regards
Patrick Brosi
--
geOps e.K.
--------------------------------
Commercial Registry A 702785, Freiburg
Kaiser-Joseph-Strasse 263
D-79098 Freiburg
--------------------------------
direct +49 (0)761 458925 10
free +800 436 436 436
--------------------------------
web www.geops.de <http://www.geops.de>
rss www.geops.de/blog/feed <http://www.geops.de/blog/feed>
follow www.twitter.com/geops <http://www.twitter.com/geops>
--------------------------------
_______________________________________________
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit
_______________________________________________
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit
