[Talk-transit] GTFS compatibility

Joe Hughes joe at headwayblog.com
Tue Jul 13 20:22:39 BST 2010


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?

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.

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.

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.

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.

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
>
>




More information about the Talk-transit mailing list