Thoughts on Station Platforms

[Brian Ferris]

Hey everyone,

I wanted to start a conversation about platforms.  There is a lot of value in being able to tell a rider which platform their train will be departing from (or which pier their ferry, or which bay their bus) at a large station complex.  GTFS sort of has support for platforms already using the stop-station hierarchy semantics of 'location_type' and 'parent_station' in stops.txt.  However, the are a few places where we can do better.

Where things specifically get tricky is with platform naming.  Right now, you could imagine a large station complex with a number of stops, each with a stop_name like 'Grand Central Station - Platform 6'.  The challenge comes when we want to localize that name.  Ideally, we would rewrite 'Platform 6' into a translated, locale-specific form appropriate to the rider (handy when I'm navigating a transit system halfway around the world in a foreign language).  That becomes tricky when the agency providing the GTFS is specifying the platform identifier as part of the larger stop name string.  True, you could imagine translating these stop name strings directly, but I'd argue that this gets pretty complex when you think about supporting lots of different languages.

What to do?  Ideally, we'd have that platform identifier as a stand-alone field in the GTFS (just '6' in our example) so that we could localize as need be.  What's the best way to accomplish this?  Here's is one idea:

I propose adding a new stops.txt location_type 3 to indicate a transit platform (recall that the default 0=just a stop, 1=station, 2=entrance [proposed]).  For platform stops, a parent_station must be specified to indicate that the platform is part of a larger station complex.  Additionally, for platform stops, the 'stop_name' must be the standalone platform identifier stripped of any language-specific terms for platform (eg. require '2' instead of 'Platform 2', require 'B' instead of 'Pier B').  Generally speaking, to construct the full name of the platform, one will combine the stop_name of the parent station along with the language + locale + route type specific word for platform.

Obviously, that bit about "route type specific word for platform" is a bit tricky.  If a stop is primarily serving boats vs buses vs trains vs light-rail, the consumer of GTFS would need pick the appropriate word to use, which moves the burden of word choice from the producer to consumer.  There is an open question about whether providers of GTFS in the same locale will use different words to "indicate platform" for the same vehicle type and I welcome counter examples to indicate that my proposal is fraught with peril.

Thoughts on this?  Alternative proposals?

Thanks,

Brian

[John L]

For clarity, Grand Central Terminal will never show platforms, only tracks. This is because most platforms share 2 tracks.

I do however agree that in the subway for Grand Central Station, uptown express (the 4 and 5 lines) track and the uptown local track (6 line)  would exemplify your statement. Better yet,  uptown platform.

--
You received this message because you are subscribed to the Google Groups "General Transit Feed Spec Changes" group.
To post to this group, send email to gtfs-c...@googlegroups.com.
To unsubscribe from this group, send email to gtfs-changes...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/gtfs-changes?hl=en.

[David Healy-AUS]

Hi Brian,

 

As a consumer of the GTFS data, I think the proposal definitely has merit especially in the area of localisation. However, I’d like to suggest an alternative (feel free to shoot this down).

 

The main issue is that currently the trips stops defined in the stop_times.txt file only ever specify stops, not stations. This means that when we display trip and journey  information, we simply use the details of the stop specified in stop_times.txt and that’s it. There is no need to refer to the parent station (although we could if we wanted to).

 

If the stop_times.txt could refer to a stop who’s stop name was simply “6” this would result in us displaying trips such as “Depart 6 at 7:00am ....” where previously it would have been “Depart Grand Central Platform  6 at 7:00am ....”. This isn’t a show stopper and we can resolve this, however it may cause issues for any existing systems or apps out there that simply use the stop name directly rather than referring to the parent station name.

 

An alternative solution would be to include the platform number as a new optional field in the stop_times.txt. One advantage of this is that the platform type can now be inferred from route type of the trip specified in stop_times.txt. This will make selecting the appropriate type of platform (“Stand”, “Platform”, “Wharf” etc.,) easier and means that these strings can inturn then be localised.

 

Cheers,

 

David Healy.

--

[StuartJReynolds]

Brian, hi.

In the UK, we have different types of words for "platform" when used
in a bus context, and you can't determine by locale which one you are
going to use. So, in a bus station we would generally have either
"Bay" or "Stand" in England, and in Scotland they might additionally
use "Stance". Out on the street, lettered stops are usually prefixed
by "Stop" e.g. "Stop 3" would be an on-street bus stop, while "Bay 3"
would be one in a bus station. But not always!

In the UK stops standard, NaPTAN, we have the concept of an indicator.
This is something that qualifies, or adds to, the name of the stop
(the "Common Name" in NaPTAN). What this does is to allow many stops
to share the same name (e.g. "High Wycombe Bus Station") but then to
have indicators of e.g. "Bay 1", "Bay 2", etc to distinguish them.
Because the indicator contains the appropriate positional reference,
there is no need to try and infer it from the mode, locality or agency
- which you cannot in the UK.

Something along those lines could work here. It would have the
advantage that users could decide whether to say "take bus 7 from High
Wycombe Bus Station" - just using the name of the stop - or whether
they wanted to give more precise information e.g. "take bus 7 from
High Wycombe Bus Station Bay 3". At present they don't have that
option, because the Bay is being coded directly into the stop name as
it has nowhere else to go!

You could add parent_stop as well, and I would be happy to support
that, although that the concept should be extended to make logical
groupings of all sorts of stops (so a ferry pier and a bus stop on the
road outside could all be logically grouped as "Ferry Terminal" for
example), but if we had the principle of a name and optional
indicator, then you could assume an implicit grouping of stops based
on similar name if you wanted to which might make it easier to
populate the data sets in the first place.

Regards,
Stuart

[Roger Slevin (TSE)]

Brian

 

Can I add some comments at the level of principles - once we have established those then the mechanics of how they might be reflected in GTFS should become clearer (to those who are coders, which is not me!).

 

The way the stop locations are encoded within European/UK standards separates out four (or more) different conceptual levels :

·         The “bay” - an indicator to specify which particular stop point is being referred to on the roadside, or which platform/track is being referred to in a station

·         The “commonname” - the name which is shared amongst all “bays” within a cluster of adjacent or nearby stops that function as a single node in the pt network

·         The “locality” - the name of the geographic area (suburb, village, town, city) in which the stop is located

·         The “parent locality” (if there is one) where the suburb or district is the locality, which itself is part of a much larger and well recognised urban area

We then have a structure that places each stoppoint within a Stoparea - often referred to as the “Stop” in parts of Europe (but not in the UK - where we use the word stop to refer to an individual stoppoint for roadside stops - though we would use the stoparea for things like rail stations ... ah the confusion and imprecision of everyday language!).  So all stoppoints which have the same commonname would sit in a stoparea with that same name.

 

Timetables generally will be created with the concept of the “Stoparea” - but will then reference the specific stoppoint when referred to in public information.  So you can create a timetable in both directions which refers to a stop at “Town Hall”, for example.  But when it comes to telling the public about where to get the bus, you need to tell them that the stop is “outside” or “opposite” (or whatever).  So Town Hall is the stoparea name, and also the commonname for both stoppoints - and outside or opposite are what we would call the indicator.   The two stop points might equally be called “stop A” and “stop B” - or they might use the word Bay, Stance, Gate, etc in front of the letter or number, depending on local parlance.  For rail stations and the like in general we use numerics for platforms (interesting to note that a platform in Europe is an “edge” and not a “surface” - so the comment about Grand Central Station shows a contrasting approach ... in Europe each side of a platform surface would have a different platform number.  Platform numbers can run from 0 (zero) upwards - and sometimes will have a suffix letter to indicate a section of the platform - or they can be referenced with letters alone in some cases.

 

Complex interchanges may have more than one stoparea - and these can be nested under a parent stoparea to create a single interchange between the multiple stopareas.  This allows different clusters of stops to be named differentially whilst still being part of a wider interchange between modes, or between different clusters of stops.   Unlike Google Transit, where as far as I am aware it is only proximity that determines whether an interchange is possible, this structure ensures that the interchange stretches as far as is appropriate, but equally can exclude elements which for some reason are not part of the same interchange (perhaps close, but behind a physical barrier - so interchange is not possible).

 

So the principles that come out of this are that it would be good to be able to separate the indicator from the commonname of a stoppoint.  The indicator needs to be capable of handling strings - not just numbers or letters - so that the relevant prefix word (Platform, Bay, etc) can be used, or words such as opposite, outside, etc can be adopted.  I have attached a document which sets out the rules currently in use in the UK for indicators - to which Gate is likely to be added as a permitted variant (with options for an alphameric extension such as Gate A or Gate 1).

 

I hope these are helpful thoughts about the principles which I believe should be built into any enhancement of GTFS in this respect.

 

Best wishes

 

Roger Slevin

for traveline south east

www.travelinesoutheast.org.uk

 

From: gtfs-c...@googlegroups.com [mailto:gtfs-c...@googlegroups.com] On Behalf Of Brian Ferris
Sent: 02 February 2012 3:57 PM
To: gtfs-c...@googlegroups.com
Subject: [gtfs-changes] Thoughts on Station Platforms

 

Hey everyone,

--

[David Turner]

That's also true on the Septa Regional Rail in Philadelphia -- trains at
the three hub stations are announced as "Track 4, section B." Sections
here refer to the front (B) or the back (A) of the platform; the
platforms are two trains long.

[Roger Slevin]

Sorry - I just remembered the attachment for my posting on 3 Feb.  It is attached to this message.

 

Roger

[Brian Ferris]

Thanks for all the feedback everybody.  Here are my follow-up thoughts:

1) First, I acknowledge that station - stop - platform - section hierarchies are complex and I'm by no means proposing a full schema to represent all cases with this proposal.  I do believe that there is a path forward for representing station platform sections (eg. "Station Name - Platform # - Section B") by introducing stop entries that are children of platform stops, but I think that's a discussion for another day.

2) David H, I think you make a good point and I'm willing to amend my proposal to reflect it.  Specifically, I would propose introducing a "platform_code" field to stops.txt that should be used to specify the standalone platform identifier stripped of any language-specific terms for platform (eg. require '2' instead of 'Platform 2', require 'B' instead of 'Pier B').  This code would be used with existing stops that are part of a stop-station hierarchy (thus, I'm rescinding my proposal for a new location_type value) to indicate their platform code.  The stop_name field can continue to be used in the way it is today, which will provide good behavior who just want to use the default name provided by the agency (eg. "Station Name - Platform #") but allow for more localization control for those who want to use "platform_code" directly.

Thanks,

Brian

[StuartJReynolds]

Brian, hi

You said:

"I acknowledge that station - stop - platform - section hierarchies
are complex and I'm by no means proposing a full schema to represent
all cases with this proposal."

but just to be controversial for a moment, why aren't you?

There are a number of existing stop-model standards around the world
right now that are richer in content than GTFS. Europe in particular
has some well-developed (and long established) ones, and there is a
new schema there too that is working its way towards being accepted as
a European Standard. The advantage of these existing standards is that
they already include many of the fields that you might want to
consider. For example, UK NaPTAN (which I quote simply because it is
the one that I am most familiar with) contains language fields. It is
therefore extensible so that things like Platform 2 can be
internationalised. "Quai deux" or "Gleis zwei" anybody? Just French
and German versions of the indicators. Also, information is broken
down into component parts so that you can pick and choose what you
want to convey. Call a stop by an intersection? No problem - street
and cross street are there. Call a stop by a name including bay
number? Again, name and indicator are there and you can combine them
as you see fit. Something like that would give a great deal of
versatility in creating richness (or, rather, allowing richness to be
created rather than compelling it) but at the same time proving a
reasonably straightforward mapping onto today's GTFS model.

If we were starting from scratch, and no-one had thought of doing a
stop model before, then adding small increments as you need them is
sensible. But only to a point. There comes a time when you have to
grasp the nettle and look at what you need and want, and go for a "big
bang" approach - if only because no-one wants to be continually
upgrading their software to cope with continually changing specs, and
there is only so long that you can remain backwardly compatible.

As I said, I'm being deliberately provocative and I'm sure that in
this case a simple addition would suffice. But perhaps the time is
drawing near when we should grasp that nettle.

Regards,
Stuart

> > attached to this message.****
>
> > ** **
>
> > Roger****
>
> > ** **
>
> > *From:* gtfs-c...@googlegroups.com [mailto:
> > gtfs-c...@googlegroups.com] *On Behalf Of *Roger Slevin (TSE)
> > *Sent:* 03 February 2012 10:00 AM
> > *To:* gtfs-c...@googlegroups.com
> > *Subject:* RE: [gtfs-changes] Thoughts on Station Platforms****
>
> > ** **
>
> > Brian****
>
> > ** **

>
> > Can I add some comments at the level of principles - once we have
> > established those then the mechanics of how they might be reflected in GTFS

> > should become clearer (to those who are coders, which is not me!).****
>
> > ** **

>
> > The way the stop locations are encoded within European/UK standards

> > separates out four (or more) different conceptual levels :****
>
> > **·         **The “bay” - an indicator to specify which particular stop

> > point is being referred to on the roadside, or which platform/track is

> > being referred to in a station****
>
> > **·         **The “commonname” - the name which is shared amongst all

> > “bays” within a cluster of adjacent or nearby stops that function as a

> > single node in the pt network****
>
> > **·         **The “locality” - the name of the geographic area (suburb,
> > village, town, city) in which the stop is located****
>
> > **·         **The “parent locality” (if there is one) where the suburb or

> > district is the locality, which itself is part of a much larger and well

> > recognised urban area****

>
> > We then have a structure that places each stoppoint within a Stoparea -
> > often referred to as the “Stop” in parts of Europe (but not in the UK -
> > where we use the word stop to refer to an individual stoppoint for roadside
> > stops - though we would use the stoparea for things like rail stations ...
> > ah the confusion and imprecision of everyday language!).  So all stoppoints
> > which have the same commonname would sit in a stoparea with that same name.

> > ****
>
> > ** **

>
> > Timetables generally will be created with the concept of the “Stoparea” -
> > but will then reference the specific stoppoint when referred to in public
> > information.  So you can create a timetable in both directions which refers
> > to a stop at “Town Hall”, for example.  But when it comes to telling the
> > public about where to get the bus, you need to tell them that the stop is
> > “outside” or “opposite” (or whatever).  So Town Hall is the stoparea name,
> > and also the commonname for both stoppoints - and outside or opposite are
> > what we would call the indicator.   The two stop points might equally be
> > called “stop A” and “stop B” - or they might use the word Bay, Stance,
> > Gate, etc in front of the letter or number, depending on local parlance.
> > For rail stations and the like in general we use numerics for platforms
> > (interesting to note that a platform in Europe is an “edge” and not a
> > “surface” - so the comment about Grand Central Station shows a contrasting
> > approach ... in Europe each side of a platform surface would have a
> > different platform number.  Platform numbers can run from 0 (zero) upwards
> > - and sometimes will have a suffix letter to indicate a section of the

> > platform - or they can be referenced with letters alone in some cases.****
>
> > ** **

>
> > Complex interchanges may have more than one stoparea - and these can be
> > nested under a parent stoparea to create a single interchange between the
> > multiple stopareas.  This allows different clusters of stops to be named
> > differentially whilst still being part of a wider interchange between
> > modes, or between different clusters of stops.   Unlike Google Transit,
> > where as far as I am aware it is only proximity that determines whether an
> > interchange is possible, this structure ensures that the interchange
> > stretches as far as is appropriate, but equally can exclude elements which
> > for some reason are not part of the same interchange (perhaps close, but

> > behind a physical barrier - so interchange is not possible).****
>
> > ** **

>
> > So the principles that come out of this are that it would be good to be
> > able to separate the indicator from the commonname of a stoppoint.  The
> > indicator needs to be capable of handling strings - not just numbers or
> > letters - so that the relevant prefix word (Platform, Bay, etc) can be
> > used, or words such as opposite, outside, etc can be adopted.  I have
> > attached a document which sets out the rules currently in use in the UK for
> > indicators - to which Gate is likely to be added as a permitted variant

> > (with options for an alphameric extension such as Gate A or Gate 1).****
>
> > ** **

>
> > I hope these are helpful thoughts about the principles which I believe

> > should be built into any enhancement of GTFS in this respect.****
>
> > ** **
>
> > Best wishes****
>
> > ** **
>
> > Roger Slevin****
>
> > for traveline south east****
>
> >www.travelinesoutheast.org.uk****
>
> > ** **
>
> > *From:* gtfs-c...@googlegroups.com [
> > mailto:gtfs-c...@googlegroups.com <gtfs-c...@googlegroups.com>] *On
> > Behalf Of *Brian Ferris
> > *Sent:* 02 February 2012 3:57 PM
> > *To:* gtfs-c...@googlegroups.com
> > *Subject:* [gtfs-changes] Thoughts on Station Platforms****
>
> > ** **
>
> > Hey everyone,****
>
> > ** **

>
> > I wanted to start a conversation about platforms.  There is a lot of value
> > in being able to tell a rider which platform their train will be departing
> > from (or which pier their ferry, or which bay their bus) at a large station
> > complex.  GTFS sort of has support for platforms already using the
> > stop-station hierarchy semantics of 'location_type' and 'parent_station' in

> > stops.txt.  However, the are a few places where we can do better.****
>
> > ** **

>
> > Where things specifically get tricky is with platform naming.  Right now,
> > you could imagine a large station complex with a number of stops, each with
> > a stop_name like 'Grand Central Station - Platform 6'.  The challenge comes
> > when we want to localize that name.  Ideally, we would rewrite 'Platform 6'
> > into a translated, locale-specific form appropriate to the rider (handy
> > when I'm navigating a transit system halfway around the world in a foreign
> > language).  That becomes tricky when the agency providing the GTFS is
> > specifying the platform identifier as part of the larger stop name string.
> >  True, you could imagine translating these stop name strings directly, but
> > I'd argue that this gets pretty complex when you think about supporting

> > lots of different languages.****
>
> > ** **

>
> > What to do?  Ideally, we'd have that platform identifier as a stand-alone
> > field in the GTFS (just '6' in our example) so that we could localize as

> > need be.  What's the best way to accomplish this?  Here's is one idea:****
>
> > ** **

>
> > I propose adding a new stops.txt location_type 3 to indicate a transit
> > platform (recall that the default 0=just a stop, 1=station, 2=entrance
> > [proposed]).  For platform stops, a parent_station must be specified to
> > indicate that the platform is part of a larger station complex.
> >  Additionally, for platform stops, the 'stop_name' must be the standalone
> > platform identifier stripped of any language-specific terms for platform
> > (eg. require '2' instead of 'Platform 2', require 'B' instead of 'Pier B').
> >  Generally speaking, to construct the full name of the platform, one will
> > combine the stop_name of the parent station along with the language +

> > locale + route type specific word for platform.****
>
> > ** **

>
> > Obviously, that bit about "route type specific word for platform" is a bit
> > tricky.  If a stop is primarily serving boats vs buses vs trains vs
> > light-rail, the consumer of GTFS would need pick the appropriate word to
> > use, which moves the burden of word choice from the producer to consumer.
> >  There is an open question about whether providers of GTFS in the same
> > locale will use different words to "indicate platform" for the same vehicle
> > type and I welcome counter examples to indicate that my proposal is fraught

> > with peril.****
>
> > ** **
>
> > Thoughts on this?  Alternative proposals?****
>
> > ** **
>
> > Thanks,****
>
> > Brian****

>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "General Transit Feed Spec Changes" group.
> > To post to this group, send email to gtfs-c...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > gtfs-changes...@googlegroups.com.
> > For more options, visit this group at

> >http://groups.google.com/group/gtfs-changes?hl=en.****
>
> > --
> > You
>
> ...
>
> read more »

[Brian Ferris]

One of the guiding principles for extending GTFS (https://developers.google.com/transit/gtfs/changes) is that we (the community of GTFS producers and consumers) tend to discourage speculative additions to the specification.  Every new feature added to the spec increases the complexity of implementation for both producers and consumers of GTFS data.  Simply put, the new feature better be worth it ; )  This is a big reason why we highly encourage any new addition to the spec to have a working implementation for both data and code to make sure that the proposed feature works in practice.  In my mind, it's not worth the effort of considering every corner case of transit (and I acknowledge that there are many, some of which GTFS does not currently handle) if we don't have an agency who wants to provide data and a developer who wants to try it out.

That said, I certainly think it makes sense to build on the work of those who have thought about these issues in depth and I appreciate all the feedback you provide.  I'm hoping I'm not painting myself into a corner with the platform_code proposal.

Btw I've seen NaPTAN 3.0 is attempting to tackle a lot of these issues around stop-station hierarchies.  Is anyone publicly producing data to the 3.0 spec yet?

Thanks,

Brian

[Roger Slevin]

Brian

I strongly support Stuart’s proposition - the time is right not to make “speculative” developments but to take on board the experience of those who have modelled stops in complex transit systems for many years.   That is what Stuart is suggesting and what I am supporting.

I am not sure what aspect of NaPTAN 3.0 that you are referring to that was not in NaPTAN v1 and v2 - all versions of NaPTAN have had the hierarchy of stopareas with stop points .... and we have been using this approach in Europe for many years.  NaPTAN is just one national example of a stop model - the European IFOPT Technical Specification (which is about to be proposed as a full European Standard) extends the stop model set out originally in the Transmodel standard.  And NaPTAN is one of the standards underpinning the IFOPT work (along with models from several other European nations).   NaPTAN has existed now for more than 10 years.  The database contains more than 350,000 records nationwide, and it is in extensive everyday use in both regional and national journey planning and public transport information services.  It iss demonstrably a more powerful and flexible approach to stop modelling than that in GTFS.  It is, I believe, easy to see ways in which the principles of the stop model Stuart and I have described can be implemented in a backwardly-compatible manner within GTFS.

What GTFS means to those of us with experience of working with these more granular models is that we always have to step backwards to deliver something to GTFS which is less robust and less flexible than we use ourselves.  We would much prefer to be able to provide stop data in a more disaggregated way - recognising that some data suppliers may not take advantage of this additional flexibility immediately, but this should be possible in backwards compatibility is built into the approach (which I am sure it can be).  But where the disaggregated approach is followed then there are increasing options about how information is presented in different contexts.

I think one of the factors that may be in the back of your mind is that if these features are improved then Google, as a consumer of GTFS, would have to allow and implement the refinements - so that those of us who believe our data is more powerful if it is more granular and structured can make use of these features in the data we supply to Google Transit every week.  I hope this is not the case - General Transit Feed Specification should be general ... and not subject to undue influence from one (albeit important) consumer of data in this format.

If we can agree that this is worth taking forward, then I have already suggested one well-proven model ... and one which has found to have considerable common ground with other national standards within Europe.  Implementing this in GTFS will require careful consideration by those more familiar with the intricacies of GTFS than I am - but I am willing to engage in that process if there is a willingness within the community to see this aspect of GTFS enhanced in the way that Stuart and I have suggested.

Best wishes

Roger

[Brian Ferris]

I'm always happy to explore how we can leverage existing transit models to improve GTFS, especially when their are agencies and developers excited to use those features.  Additionally, I hope that the GTFS community never feels like they are being held back by me or by Google or by any other member when it comes to tackling new features.  If there is an agency with data and a developer who wants to use it, this community is here to help make that happen where it can.  Indeed, I can think of a number of applications that are using GTFS and extensions to GTFS in ways that Google does not, and I think that's a positive thing for GTFS.

In terms of NaPTAN 3.0, I was thinking of support for <quays> within a <StopPlace>.  I'll admit that I'm not an expert on the standard, but someone had mentioned to me that this was an addition to 3.0 and indeed I seemed to see more mention of it in the 3.0 documentation than I did in the 2.4 spec.  Maybe I'm misinformed here?

Thanks,

Brian

[Roger Slevin]

Brian

 

Sorry for the delay in replying.

 

I think we have made the point that there are those of us in Europe who would find value in having a richer and more granular way of describing/naming stops that follow the Transmodel and IFOPT principles.

 

The basic hierarchy of stopareas and stoppoints that I have described in previous postings have been fundamental in all  versions of NaPTAN.  NaPTAN v3 introduces further richness (derived from IFDOPT), as you say, by adding the concept of a Quay and various other elements which allow micro-modelling of interchanges.  Stuart and I have not proposed going to that level of detail for GTFS because there is no widespread application of this level of detail yet within Europe.  The standards are there to allow it when resources permit agencies to populate the relevant data.  It is not a trivial job - but if it is done, it now can be done to a consistent standard, which will be helpful for inter-operability.

 

Aspects of NaPTAN 3 are being used in the modelling for various aspects of the Olympic Games transport information systems - including not only public transport facilities but also the Games venues themselves.  But it is a special circumstance and whilst lessons will be learnt from the process, it is not yet seen as something that will be extended rapidly elsewhere because of the resource costs of capturing the extensive sets of data required.  There has to be a good business case for that effort to be justified.

[Nicholas Albion]

It would be good to see some concrete guidance such as "For platform stops, a parent_station must be specified to indicate that the platform is part of a larger station complex.  Additionally, for platform stops, the 'stop_name' must be the standalone platform identifier stripped of any language-specific terms for platform (eg. require '2' instead of 'Platform 2', require 'B' instead of 'Pier B')" published in the specs of style guide.

[Stefan de Konink]

One potential issue at station is that you will hit the validation
boundaries regarding maximum distance from parent stop. Obviously safe to
ignore, but might be annoying.

Stefan

[Brian Ferris]

Our current proposal is for agencies to include a "platform_code" field that specifies the standalone platform identifier.  Agencies would then be free to use "stop_name" as they see fit, which could include a localized term for platform (eg. "Platform 2").  That way, data consumers that don't care about localization (aka they just want to operate in the local language) can use the "stop_name" per normal to identify the platform, while apps that want to localize in multiple languages would use "platform_code".

Documentation for the proposed "platform_code" field is up on the Google Transit GTFS Extensions page:

http://support.google.com/transitpartners/answer/2450962?hl=en

Brian

On Mon, Feb 4, 2013 at 5:04 AM, Nicholas Albion <nal...@gmail.com> wrote:

It would be good to see some concrete guidance such as "For platform stops, a parent_station must be specified to indicate that the platform is part of a larger station complex.  Additionally, for platform stops, the 'stop_name' must be the standalone platform identifier stripped of any language-specific terms for platform (eg. require '2' instead of 'Platform 2', require 'B' instead of 'Pier B')" published in the specs of style guide.

--

You received this message because you are subscribed to the Google Groups "General Transit Feed Spec Changes" group.

To unsubscribe from this group and stop receiving emails from it, send an email to gtfs-changes...@googlegroups.com.

To post to this group, send email to gtfs-c...@googlegroups.com.

Visit this group at http://groups.google.com/group/gtfs-changes?hl=en.

For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Tim Cooper]

 I'm possibly coming a little late to this discussion.  Anyway, the motivation for "platform_code" is so you can translate it for tourists, right?  I'm not sure that's a good idea.  Tourists need to read signs, which will be written in the local language, and they'll need to ask directions from passerby's, and having the japanese translation of "Platform 6" or "Bay 6" won't be doing them any favours there.  

(I actually quite like the GTFS data in its original format.  There are a lot of proposals to extend it, in all different directions.  I find the fare information inadequate, but after studying the area I think you'll either need a massive spec to define all possible formulae, or as we've done, use Java to encode fare rules.)

[Nicholas Albion]

There are few applications which are consuming Sydney GTFS data for display on mobile devices.  Currently the Sydney GTFS feed only provides stand letters for bus stops embedded within the stop_name field.  The developers of each of the mobile apps have taken it upon themselves to parse the stop_name to extract the stand letter so that they can display it in a separate field on the screen, or in a badge/map marker.  Unfortunately, the assumptions made by the routines that do this parsing are not always perfect so occasionally the app will interpret the suburb name as the stand letter, display it incorrectly or miss the stand letter completely.

I have seen one app display the stop name as "Wynyard Station, York St - Stand..." ie, the stand letter was replaced by ellipses because the stop name would not fit on the screen.  

I agree with Brian that you'd only want "6" in this field rather than "Platform 6" so that:

- the platform/stand etc can be shown in a marker/badge on a map or prominently on a text-based screen

- "Stand I" can (if the developer/user wishes) be translated correctly and not as "je me tiens" for example

[Joe Hughes]

Yes, for our app we want the platform letters/numbers called out as a
distinct field in the data, as we display the platform number/letter
in a larger font than the rest of the info to make it easier to read.

Cheers,
Joe Hughes
Citymapper

[Andrew Byrd]

Nicholas, I think everyone is in agreement that if platform_ids are
included in a separate field, they should not include a platform-word
(because one major use of the platform_id field is localization). A
separate field whose data type is an enumeration of platform types was
suggested to facilitate localization of the platform-word, but this may
be unnecessary since the transport mode in use seems to suggest an
appropriate platform-word in most languages.

I agree with Tim Cooper that localizing the platform-word is more likely
to confuse than to help the traveler. Since it is obvious to a human
which part is the platform ID the passenger will immediately learn the
word in the foreign language for 'platform' and be better adapted to
their surroundings.

Of course if Google wants to do the localization that's still a valid
use for the platform field, but others seem more interested in using it
to split out the platform code into a separate column, put it in bold or
whatever.

I would therefore suggest that we drop the comment that platform_id is
for localization, and just say it is for unambiguously specifying the
platform separately from the stop name, for whatever purpose.

-Andrew

[Andrew Byrd]

On 03/20/2013 02:27 PM, Andrew Byrd wrote:
> Nicholas, I think everyone is in agreement that if platform_ids are
> included in a separate field, they should not include a platform-word

Sorry, replace platform_id with platform_code.