[Talk-transit] GTFS compatibility
Peter Miller
peter.miller at itoworld.com
Tue Jul 13 21:44:49 BST 2010
On 13 Jul 2010, at 20:22, Joe Hughes wrote:
> Hi Peter,
>
> Thanks for digging into this issue. I think that your goals of
> improving the precision and identifier-stability of existing open
> transport data are good ones. The question is then: how and where can
> the OSM community apply leverage to help make this happen?
Thanks for responding Joe. I think The OSM can help by building great
physical models of the fixed infrastructure. The most useful bit
required from the Transit Agency is then a good fixed ID to associate
schedules to the platforms/Stop Points that they are referring to. If
they don't provide a good ID then some technical matching might be
possible using the name and the lat/long of the stop as a signature
for the stop.
>
> At the end of the day, the people that you want to influence are the
> people that create and maintain the data on the agency side. In many
> cases, when they create their exports, they're looking for the minimal
> transformation that they can make between their existing databases and
> the export format, such that the data looks decent in consuming
> applications.
Agreed. We will mention this to agencies when we talk to them. Clearly
better information does create a better experience though.
>
> Given this, I'd posit that you'd have a much greater effect on data
> exporting practices by building an OSM-based transport renderer that
> makes a bad-looking rendering when the input data has the
> characteristics you mentioned (i.e. stops on opposite sides of the
> street represented by a single logical stop in the data). I suspect
> that this would be much more meaningful to agency folks than an
> abstract recommendation in a spec document. Given the success of
> ITO's visualizations, I expect that you have a deep understanding of
> how well the visual approach can work.
Thanks! We are already able to use such data where it exists - for
example on this map which uses the bearing and street name in NaPTAN
to snap stops to the correct roads:
http://www.flickr.com/photos/peterito/2102416239/sizes/o/in/pool-559674@N22/
We are creating some tools to visualise GTFS content on an OSM
background which we hope will be useful. More details in soon.
> As for the potential new fields you mentioned, I recommend proposing
> them to the community on the gtfs-changes list; some of the things
> you've mentioned are already under discussion, and merely lack willing
> participants for an end-to-end test of the the features to verify that
> they work as intended when used with real data.
Fixed Stop IDs for linking to schedules are the only things that the
OSM community can't do for themselves - possibly we start by working
on data providers to supply these using the current standard in the
stop_id field. When we have some examples in use we can push for more
content. Any suggestions of places that use good permanent IDs?
I signed off from gtfs-changes some time ago, possibly you could
forward my emails to the list if that would help? Happy to get
involved if that would be productive, do let me know.
>
> Either way, I hope that a desire for tidier data won't get in the way
> of OSM making the most of the wealth of transport data that's already
> been made available to the public.
Agreed. Finding places with good GTFS stops data and then importing it
in OSM would be a great start.
Regards,
Peter
>
> Cheers,
> Joe
>
> On Tue, Jul 13, 2010 at 1:54 PM, Peter Miller <peter.miller at itoworld.com
> > wrote:
>> Apologies form coming into the conversation late( (I have just
>> returned from
>> the State of the Map conference which was very impressive as always).
>> I have been spending some time looking at GTFS stops data for San
>> Francisco
>> today. There seems to be a problem where there are multiple stops
>> with the
>> same name, there also appear to be different names for the same
>> physical
>> stop which may appear multiple times as I don't believe there are
>> that many
>> actual stops on the ground.
>> On the junction of Market St & Castro St there are 8 bus stop
>> points in GTFS
>> They are called:
>> Market St & Castro St
>> Market St & Castro St
>> Market St & Castro St
>> Castro St & Market St
>> Market St & Castro St
>> Market St & 17th St
>> Castro St & 17th St
>> 17th St & Castro St
>> And then the following for metro services (note the names are not
>> that well
>> chosen as a pair)
>> Metro Castro Station/Downtown
>> Metro Castro Station/Outbound
>> Not all of the above have actual services from them and Google
>> Transit bails
>> out, merges the services into a smaller number of stops (one for
>> bus and one
>> for metro) and when one pulls up a service lists them as 'services
>> available
>> from near here'. The full list of stops (some of which have no
>> services) do
>> however appear on the google streetview images.
>> We have experience of the UK NaPTAN database where there is a
>> separate DB
>> for the stops from the schedules and from the mapping). I would
>> suggest
>> that:
>> We recommend that GTFS is modified so that
>> Stop_ID should ideally be used for a stable authority wide ID for
>> the stop
>> (or indeed stable national ID)
>> That there is space for a separate 'indicator' for each of the stop
>> typically used around for stops around a junction where the name is
>> the same
>> (possibly A,B,C etc)
>> That the 'name' of the stops is the same for every stop around a
>> junction.
>> At ITO we want to be able to connect stops to the correct side of
>> the
>> correct street and I think this will be of more general use to
>> other service
>> providers. This information should not be dependent on a particular
>> supplier
>> of mapping. We have found the following successful in the UK and
>> recommend
>> that GTFS allows and encourages suppliers to include the same
>> information
>> for a stop.
>> A direction flag (N,NE,E,SE etc) which indicates the direction that
>> vehicles
>> take when leaving the stop
>> A street-name which holds the name of the street on which the stop
>> point
>> appears.
>>
>> Some time ago I noticed that some providers of GTFS data supply
>> only a
>> single Stop for use by services in both directions. I suggest that
>> GTFS
>> recommends (but doesn't require) that a stop is provided for each
>> direction.
>> Finally GTFS does not specify where the stop should be located. OSM
>> uses the
>> place where one waits (the shelter/pole etc) and not the place
>> where the
>> vehicle stops. Again I suggest that the standard should recommend
>> this
>> practice. OSM has a separate field to indicate where on the highway
>> or
>> railway the vehicle stops.
>> I agree that Stop Areas can often be worked out automatically,
>> especially if
>> the 'name' is the same for all the stops in the area. For major
>> interchange
>> then explicit Stop Areas can be useful in a hierarchy although this
>> is not
>> done well in the UK yet even though it is possible. I would
>> recommend that
>> GTFS allows one to express a hierarchy of this sort.
>> It feels to me that the time is right to have a good push to get
>> these
>> issues sorted both in GTFS and also in OSM - in particular to use
>> OSM to
>> grab information about the physical infrastructure and connect it
>> to the
>> official ID for the stop used by the authority. It will however
>> take time to
>> get there one city at a time!
>>
>> Regards,
>>
>> Peter Miller
>> ITO World Ltd
>>
>>
>>
>> On 4 Jul 2010, at 13:16, john whelan wrote:
>>
>> In the UK streets are tagged with the value on the sign at the end
>> of the
>> street and this works very well with printed maps. When I lived in
>> London a
>> group of bus stops might be labeled A-E but in general bus stops
>> do not
>> have a name or id painted on the bus stop. Unfortunately UK
>> practice is not
>> followed by other parts of the world. In Ottawa each bus stop has
>> a four
>> digit number painted on it in General Transit Feed Specification
>> (GTFS)
>> terms this is known as the stop_id. The GTFS stop_name value is not
>> apparent to the mapper.
>>
>> The GTFS file contains bus stop location information but this
>> information
>> can be up to 200 meters out. In Ottawa the convention is to name
>> the stop
>> after the nearest cross street. Add in town planning where through
>> traffic
>> is discouraged from travelling on residential roads but footpaths
>> have been
>> placed to give access to bus stops and you can have two or three
>> different
>> bus stops with the same stop_name value but different stop_id values.
>>
>> Does it matter what we call the stop? Well having the stop_id value
>> available means that local mappers can at least map the bus stops
>> to the
>> correct location. Without the stop_id value it becomes more
>> difficult. The
>> current Ottawa GTFS stops.txt file is incomplete, some stops appear
>> to be
>> missing, mapping with the stop_id makes it easier to identify them.
>>
>> We now have applications that process the tags on an osm file.
>> Maperitive
>> for example will search tags to locate points of interest.
>> shop=florist
>> finds local florists. There are many GTFS aware applications that
>> know the
>> GTFS tag names so reusing them in OSM makes sense. Routing systems
>> for
>> example work better if the bus stop is in the right place and
>> correctly
>> labeled.
>>
>> With the NAPTAN import some one decided which NAPTAN field should
>> be placed
>> in the name tag and I suspect the original field in the NAPTAN
>> database
>> wasn't simply name.
>>
>> Locally my personal preference for the name tag would be to
>> concatenate the
>> GTFS stop_id and stop_name fields but also retain them as separate
>> tags.
>> That way some one could set up the rendering rules for bus stops to
>> display
>> either should they wish to do so.
>>
>> By the way even street name signs are not always simple. In OSM
>> the rule is
>> to use the name on the street sign at the time of mapping.
>> Recently in
>> Ottawa there has been a move to bilingual street signs so Leduc
>> Crescent
>> becomes "croissant Leduc Crescent". If you tag street
>> name:"croissant Leduc
>> Crescent" then you get into issues of what do you expect a casual
>> user to
>> enter on a find or search command adding in that some streets were
>> mapped
>> before the new street sign rules.
>>
>> Cheerio John
>>
>>
>> On 4 July 2010 06:23, Jenny Campbell <jenuk1985 at googlemail.com>
>> wrote:
>>>
>>> In the UK, following the NAPTAN import, all stops use name, not
>>> stop_name.
>>> A name tag on a bus stop implies that the tag is referring to the
>>> name of
>>> the stop anyway, no risk of mix ups there! We use name in the same
>>> way for
>>> everything else on the map, why should a bus stop be different?
>>>
>>> Jeni
>>>
>>> On 01/07/2010 17:08, john whelan wrote:
>>>>
>>>> Since the JOSM plug_in will become the defacto standard since it
>>>> will be
>>>> used by many people who don't read posts here or understand the
>>>> issues may I
>>>> request that it uses the GTFS tag of stop_name and stop_code
>>>> rather than the
>>>> tag of name.
>>>>
>>>
>>> _______________________________________________
>>> Talk-transit mailing list
>>> Talk-transit at openstreetmap.org
>>> http://lists.openstreetmap.org/listinfo/talk-transit
>>
>> _______________________________________________
>> Talk-transit mailing list
>> Talk-transit at openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-transit
>>
>>
>> _______________________________________________
>> Talk-transit mailing list
>> Talk-transit at openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-transit
>>
>>
>
> _______________________________________________
> Talk-transit mailing list
> Talk-transit at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-transit
More information about the Talk-transit
mailing list