[Talk-transit] GTFS compatibility

Sam Vekemans acrosscanadatrails at gmail.com
Fri Sep 10 16:54:24 BST 2010


Hi John, & talk-transit
I didn't actually see that text file with all the transitID tag codes until now.
I'll include them in my master tagging chart im working on.
>From what i can see, all the keys look unique,so it should work out.


Thanks,
I'll post the results when i have them.


Sam

On 6/30/10, john whelan <jwhelan0112 at gmail.com> wrote:
> I'm currently looking at Bus stops in Ottawa in OSM and finding similar
> issues with the existing bus_stops.  I'm seriously wondering where
> stop_codes exist if one approach might be to import bus_stops using GTFS
> data and use the GTFS tags such as stop_code etc from stops.txt
> http://code.google.com/transit/spec/transit_feed_specification.html#stops_txt___Field_Definitions
>
> Tools such as JOSM have a search facility so we should be able to search for
> bus_stops without a stop_code then reconcile them with the ones that have a
> stop_code tag.  If the GTFS data is wrong then we should be able to send a
> report somewhere probably the transit authority saying we think this stop is
> incorrect.
>
> My personal view is while we should respect work done already adding extra
> tags in this way doesn't remove this work and it is up to the rendering
> rules to either omit or include a particular bus_stop for display.  This can
> be selected by the presence or absence of a stop_code tag, certainly in
> Maperitive.
>
> If we were to do this we would probably need some sort of wiki write up and
> a standard way to label bus_stops.  Currently in Ottawa I've seen at least
> four different ways the ones with the bus route on being the least useful as
> they tend to be out of date.
>
> I don't think mapping routes works at all well.  Certainly in Ottawa the bus
> stops and stop_codes stay in the same physical place but the bus routes can
> be modified three or four times a year.  Some changes are greater than
> others and the transit route planning system that can be accessed from the
> web or by phone includes school buses which are not listed in the stop but
> do sometimes provide a useful and quicker way to get from point A to point
> B.
>
> Cheerio John
>
>
> On 30 June 2010 09:25, Hillsman, Edward <hillsman at cutr.usf.edu> wrote:
>
>> Our center has a project to explore the use of OSM as a repository and
>> tool
>> for supporting multimodal trip planners (for example, bike to transit,
>> ride
>> the bus, walk or bike to final destination). We are keenly interested in
>> the
>> current discussion of transit and GTFS in OSM, because one of our tasks is
>> to develop software to import from GTFS into OSM, and then update the
>> import
>> as a transit agency modifies its routes or stops, taking into account that
>> OSM mappers may have found and corrected errors in what was uploaded (or
>> may
>> have introduced errors). I'm writing to share some of our experience and
>> get
>> your suggestions. We will make the software we develop in this project
>> (for
>> uploading, matching, and updating GTFS data in OSM) publicly available.
>>
>> We think it should be relatively easy to upload a set of GTFS stops into
>> an
>> area where no one has mapped bus stops into OSM. Generating the route
>> relations will be harder and we may not accomplish that as part of this
>> project. And we think that updating such data will be relatively simple,
>> because it can rely on tags identifying and cross-referencing the stops;
>> software would look for changes, and manual work would be needed to
>> reconcile them. The hard part is going to be designing the initial upload
>> process to work in areas where OSM already includes some bus stops, but
>> not
>> all of them. In the state of Florida, where we are working, there are
>> about
>> 450 stops already in OSM, many in areas served by transit agencies with
>> GTFS
>> data. Obviously, we want to respect what has been mapped. Things that
>> complicate the initial upload include:
>>
>> (1) Locational errors in the GTFS data. These are not systematic, and some
>> are surprisingly large. One is more than 200 meters from its actual
>> location, and only about 10 meters from another stop that GTFS has within
>> 10
>> meters of its actual location (and that is mapped accurately in OSM). We
>> came into this project knowing that there is locational error in GTFS. Now
>> we are trying to figure out how to deal with it. The GTFS locations do
>> match
>> those appearing in Google Transit, by the way.
>> (2) Locational errors in the OSM data. These aren't systematic either but
>> tend to be much smaller, except that in a few cases the stop has been
>> recorded on the wrong side of the street, and a mapper in one city has
>> recorded stops as nodes defining the street way rather than as points to
>> the
>> sides of the street.
>> (3) Incomplete and inconsistent tagging of the OSM stops.
>> (4) The presence in an area of stops for multiple agencies, only one of
>> which has GTFS data. Our campus has a shuttle bus circulator system with
>> no
>> GTFS data (they operate without a set schedule but with a target 10-minute
>> headway, and frequency changes during the day and with the university
>> class
>> schedule). The area's main public transportation agency has several routes
>> that pass through the campus, and has GTFS data. Most of the public-agency
>> stops on campus, but not all, are also campus shuttle stops, and there are
>> many more shuttle stops on campus than there are public-agency stops.
>> (5) Incomplete mapping of stops for each agency in OSM.
>>
>> At the moment, we are rethinking the whole idea of trying to match the
>> GTFS
>> stops to the OSM stops for the initial upload. One idea would be to screen
>> all stops in a GTFS area to look for tags indicating the operator (or no
>> operator), tag all of them with a FIXME describing that an upload has
>> occurred and may produce duplicates, but otherwise leave them alone, and
>> then upload the GTFS ones. I see problems with that, and in any case it
>> should be done only if there is a commitment by the uploader to work
>> quickly
>> to reconcile the two data sets in OSM. Given the surprisingly large
>> locational errors in GTFS, I'm also uncomfortable with simply uploading
>> it,
>> because putting bad data into the system will create confusion. I suspect
>> this is a problem with all uploads. We've certainly seen it with the TIGER
>> street data.
>>
>> But we are still in the thinking-about-this stage, haven't made any
>> decisions, and are looking for suggestions and comments (hence this
>> posting). Until we get a much better handle on the initial upload
>> problems,
>> any actual uploading we do as part of the project will be limited to the
>> area of our campus, where we know what is actually on the ground and can
>> clean up anything we do. We'd definitely enjoy sharing work and ideas.
>>
>> Ed Hillsman
>>
>> Edward L. Hillsman, Ph.D.
>> Senior Research Associate
>> Center for Urban Transportation Research
>> University of South Florida
>> 4202 Fowler Ave., CUT100
>> Tampa, FL  33620-5375
>> 813-974-2977 (tel)
>> 813-974-5168 (fax)
>> hillsman at cutr.usf.edu
>> http://www.cutr.usf.edu
>>
>>
>>
>> On Tue, 29 Jun 2010 15:26:07 +0100 Joe Hughes <joe at headwayblog.com> wrote:
>> >I agree that it would be helpful to end up with something that allows
>> >straightforward conversions to and from the GTFS format.  GTFS is a
>> >CC-licensed specification [1] which is evolved by an open community
>> >process [2].  Also, the great majority of U.S. and Canadian transport
>> >data is already available to developers in GTFS format [3], which has
>> >led to a community of developers  creating apps which can consume and
>> >produce it [4].
>> >
>> >Incidentally, as someone who's been deeply involved in the development
>> >of the format, I'm happy to answer any questions, and generally help
>> >to get this substantial mass of transport data into OSM.
>> >
>> >Cheers,
>> >Joe
>> >
>> >Links:
>> >[1] http://code.google.com/transit/spec/transit_feed_specification.html
>> >[2] http://groups.google.com/group/gtfs-changes/
>> >[3] http://www.gtfs-data-exchange.com/
>> >[4] http://groups.google.com/group/transit-developers
>>
>> _______________________________________________
>> Talk-transit mailing list
>> Talk-transit at openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-transit
>>
>


-- 
Twitter: @Acrosscanada
Blogs: http://acrosscanadatrails.posterous.com/
http://Acrosscanadatrails.blogspot.com
Facebook: http://www.facebook.com/sam.vekemans
Skype: samvekemans
IRC: irc://irc.oftc.net #osm-ca Canadian OSM channel (an open chat room)
@Acrosscanadatrails



More information about the Talk-transit mailing list