Conversation
gtfs/spec/en/reference.md
Outdated
| | Field Name | Required | Details | | ||
| | ------ | ------ | ------ | | ||
| | level_id | **Required** | The **level_id** field contains an ID that identifies a level. The **level_id** is dataset unique. | | ||
| | level_index | **Required** | The **from_stop_id** field contains a numeric index of the level that indicates relative position of this level in relation to other levels (levels with higher indices are assumed to be located above levels with lower indices). Ground level should have index 0, with levels above ground indicated by positive indices and levels below ground by negative indices. | |
There was a problem hiding this comment.
I think this is meant to be level_index here (in details)?
There was a problem hiding this comment.
Fixed. My bad. Thanks.
gtfs/spec/en/reference.md
Outdated
| | | | Note: The approximation of 1 floor = 15 stairs (or 12 for an escalator) can be used to generate approximative values. | | ||
| | pathway_name | Optional | The **pathway_name** field contains the name of the pathway, if any. Please use a name that people will understand in the local and tourist vernacular. | | ||
| | pathway_code | Optional | The **pathway_code** field contains a short text or a number that uniquely identifies the pathway for passengers. The **pathway_code** can be the same as pathway_id if it is passenger-facing. This field should be left blank for pathway without a code presented to passengers. Example: Elevator “A”. | | ||
| | signposted_as | Optional | The **signposted_as** field helps to generate schematic directions like 'follow signs to <signposted as>' where <signposted as> part represents specific text on the signs that should remain unaffected by translation into other languages. | |
There was a problem hiding this comment.
Did you mean "semantic directions" rather than "schematic directions" here?
There was a problem hiding this comment.
Apologies, I am not a native speaker, so writing well-formed English sentences can be quite a challenge for me.
A native speaker I asked to take a look at this sentence suggested ditching the whole thing in favour of:
"The signposted_as field is an exact string of text from physical signage visible to transit riders. The string can be used to provide textual directions to users, such as 'follow signs to '. The language as printed on the signs should not be translated in this field."
|
About the beta implementations: @dbabramov: Can we say that Google has already implemented most of this proposal, and that we have a beta consumer? @DaveBarker for MBTA, @kurtraschke for NYMTA, @antrim for Trillium or @sdjacobs for CS: Is one of you planning to release a test GTFS with those fields in the close future? |
|
We have not implemented the full spec yet. |
|
Quick update, we are currently working with the STM (Montréal, CA-QC) to have a beta implementation of this proposal in theirs GTFS. They already have the station entrances in their GTFS. |
| | | | * **(empty)** - Unknown travel time. | | ||
| | | | * **-1** - Pathway not wheelchair accessible. | | ||
| | | | * **(non-negative integer)** - Number of seconds needed to travers this pathway in a wheelchair. | | ||
| | ramp_slope | Optional | The **ramp_slope** field specifies the slope ratio of the pathway. Valid values for this field are: | |
There was a problem hiding this comment.
How exactly is ramp_slope calculated? Is it the steepest slope between stops?
After some discussion with @astein6 who lead a research center on accessible transportation it sounds like this may need to be split into two values - steepest incline and decline, or perhaps positive and negative elevation change.
Here's how Google shows elevation change in walking directions:
Do we have any producers providing the slope data yet? I'm interested to see how this translates to real data.
There was a problem hiding this comment.
True.
My assumption was that Pathways would only describe paths inside a human-made construction, and that therefore they wouldn't be any complex slope.
But now I'm thinking about those _/ slopes you find when tunnel go under tracks... Either we modelize them with two distinct ramps, or we need indeed two values.
Do you have an example where this could be needed, knowing that this is just for a pathway and not for a full 40min journey?
There was a problem hiding this comment.
@LeoFrachet I (unfortunately) don't have an exact real-world example off the top of my head, which is why I was curious to see real producer data for slope values.
barbeau
added
the
GTFS Schedule
5 participants
The goal is to describe the inside of a station, so that a trip planner could process the impact of an elevator being down on the accessibility (for example).
This proposal contains two new files:
Pathways describes "ways" within the stations (which can be seen as edges in a graph where the stop/station/entrance/node are the vertices), with a description of their physical characteristics (stairs vs elevator, slope, length) and on their descriptive characteristics (name, code, indication).
Levels describes the vertical distribution of a station. In most complex stations, the platforms are layered, without any indication in the current GTFS specification of this repartition.