Add best practices for cross street stop_name#285
Add best practices for cross street stop_name#285sccmcca wants to merge 1 commit intogoogle:masterfrom
Conversation
sccmcca
added
the
GTFS Schedule
|
Would you support it by just introducing a new field for this? |
sccmcca
changed the title
stop_name
|
I'm not sure I understand. Are you proposing an additional stop name field in stops.txt specifically for cross street stop names in place of providing a recommendation in the existing |
|
Exactly. NeTEx for example has a CrossingRoad. |
|
@mbta has |
|
@paulswartz Are |
|
On the proposition itself, I'm torn. This feels too much into the "best practice" realm. Is that the job of the spec to specify that? |
|
They're separate from the Some examples from our current feed:
|
|
@gcamp This is part of a larger RFC 2119 conversation. What is the difference between RFC spec recommendations ("should") and best practice recommendations? I see your point that a line may be drawn when we start dealing with special modelling cases such as cross streets, but can keep higher level recommendations as RFC spec recommendations. The strength to having recommendations in the spec is that it is official and canonical with GTFS, as opposed to a separate set of potentially arbitrary best practice documentation (which might reduce the amount of consumers and producers actually following them). Open to hearing other strategies to manage this. |
|
Adding something like on_street and cross_street fields was something I was going to suggest. I also had the idea of a stop_side field to indicate if the stop is near side, far side, opposite or maybe north, south, east or west side. Redundancy is a concern, but it allows a language independent way of describing stop locations which is useful for translations for different human languages and computer data structures. You can see in the TransSee stop list what can be done by separating the street names: https://www.transsee.ca/stoplist?a=mbta&r=59 |
|
In my opinion a stop_name should be equal what is physically on the stop, the rest is a matter of attributes for positioning. |
|
I agree with @skinkie and @gcamp but will re-state it in a slightly different way. This is starting to feel like dictating how an agency communicates about or markets their service, rather than defining a format to exchange that information with other computer systems. Various agencies may have various rules (or, sometimes, no rules at all) for how they name their stops -- and it's not the job of the GTFS spec to tell them how to do it. Stop name should be formatted however the agency formats it in their literature, signage, or other communication. |
Yes but...I think it is very useful to offer a "best practice" (which I believe is what is being proposed here) when dealing with some extremely common cases, including the case of "Main Street at East Road" or "Main Street opposite East Road". There is also a best practice to be said about spelling things out for an annunciator unless you add a tts field. |
I agree! But in both of these cases I don't think that the data spec is the place for a best practice like this. If an agency doesn't spell a name out in their literature elsewhere, or uses strange local abbreviations or acronyms, I don't think the data spec is the place to suggest they change that. Best practice documentation generally sits next to rather than inside the data spec and something may be completely valid from the standpoint that computer systems can transfer the data to/from each other even if the best practice (which might help make it accessible to and understandable by a wider variety of users) isn't followed. |
Where would a best practice exist, then? I thought there had been a global decision to move the best practices into the spec so there was "one place to look". I want to make it as easy as possible for everyone to know what the must/should/could for GTFS is. Having people go to multiple locations is asking for it not to be considered. |
I may have missed that. Is the idea that the Best Practices repositories would be deprecated and the info would be moved into here? If I did, I apologize! If that is the case, however, I think it's worth considering whether a best practice is one of "how to model your information" (in which case I'd say it's fair game for inclusion) or one of "what information to model." I don't think it's the place of the GTFS spec to give agencies best practices for how to name their stops (what information to model) but that the spec should accommodate however agencies name their stops. Advising on how to name stops is the job of a transit planner or consultant, not a data specification. While I personally agree that it makes more sense to list the street the bus is on first, followed by the cross street, we have customers who don't do it that way for whatever reason. Sometimes it's "list the more major street first" in general and sometimes it's random and makes no sense -- but the name of their stop is what it is. If an agency has signs, maps, schedules, or other information printed with stops named a particular way, then GTFS best practice should be limited to "match the way you name this stop on other resources, so that third party apps are consistent with the other information your riders have access to." |
|
Perhaps adding the additional columns would be a way to seperate the streets without the need to prescribe how the stop_name is formatted. |
There was a global decision to update GTFS Schedule to RFC 2119 in #277 to disambiguate requirement levels (including recommendations, or "best practices") of the spec, but certainly no global decision or promise to implement any particular best practices from other repos into the spec. I think @stevenmwhite makes a strong and clear case for what to include and what not to include as RFC 2119 recommendations:
|
|
There's a typo: "should contains the name of the boarding area" it should be "should contain the name of the boarding area" |
| | `stop_id` | ID | **Required** | Identifies a location: stop/platform, station, entrance/exit, generic node or boarding area (see `location_type`). <br><br>Multiple routes may use the same `stop_id`. | | ||
| | `stop_code` | Text | Optional | Short text or a number that identifies the location for riders. These codes are often used in phone-based transit information systems or printed on signage to make it easier for riders to get information for a particular location. The `stop_code` may be the same as `stop_id` if it is public facing. This field should be left empty for locations without a code presented to riders. | | ||
| | `stop_name` | Text | **Conditionally Required** | Name of the location. The `stop_name` should match the agency's rider-facing name for the location as printed on a timetable, published online, or represented on signage. For translations into other languages, use `translations.txt`.<br><br>When the location is a boarding area (`location_type=4`), the `stop_name` should contains the name of the boarding area as displayed by the agency. It could be just one letter (like on some European intercity railway stations), or text like “Wheelchair boarding area” (NYC’s Subway) or “Head of short trains” (Paris’ RER).<br><br>Conditionally Required:<br>- **Required** for locations which are stops (`location_type=0`), stations (`location_type=1`) or entrances/exits (`location_type=2`).<br>- Optional for locations which are generic nodes (`location_type=3`) or boarding areas (`location_type=4`).| | ||
| | `stop_name` | Text | **Conditionally Required** | Name of the location.<br><br> The `stop_name` should match the agency's rider-facing name for the location as printed on a timetable, published online, or represented on signage. For translations into other languages, use `translations.txt`.<br><br>Stops named after cross streets should separate street names by a single consistent separator within `stops.txt` (e.g., "at", "and", "&", "/"). The first street name should be the street that the vehicle is travelling on at the time of the stop, and the second street name should be the cross street (i.e., < first street name > < separator > < second street name >).<br><br>When the location is a boarding area (`location_type=4`), the `stop_name` should contains the name of the boarding area as displayed by the agency. It could be just one letter (like on some European intercity railway stations), or text like “Wheelchair boarding area” (NYC’s Subway) or “Head of short trains” (Paris’ RER).<br><br>Conditionally Required:<br>- **Required** for locations which are stops (`location_type=0`), stations (`location_type=1`) or entrances/exits (`location_type=2`).<br>- Optional for locations which are generic nodes (`location_type=3`) or boarding areas (`location_type=4`).| |
There was a problem hiding this comment.
| | `stop_name` | Text | **Conditionally Required** | Name of the location.<br><br> The `stop_name` should match the agency's rider-facing name for the location as printed on a timetable, published online, or represented on signage. For translations into other languages, use `translations.txt`.<br><br>Stops named after cross streets should separate street names by a single consistent separator within `stops.txt` (e.g., "at", "and", "&", "/"). The first street name should be the street that the vehicle is travelling on at the time of the stop, and the second street name should be the cross street (i.e., < first street name > < separator > < second street name >).<br><br>When the location is a boarding area (`location_type=4`), the `stop_name` should contains the name of the boarding area as displayed by the agency. It could be just one letter (like on some European intercity railway stations), or text like “Wheelchair boarding area” (NYC’s Subway) or “Head of short trains” (Paris’ RER).<br><br>Conditionally Required:<br>- **Required** for locations which are stops (`location_type=0`), stations (`location_type=1`) or entrances/exits (`location_type=2`).<br>- Optional for locations which are generic nodes (`location_type=3`) or boarding areas (`location_type=4`).| | |
| | `stop_name` | Text | **Conditionally Required** | Name of the location.<br><br> The `stop_name` should match the agency's rider-facing name for the location as printed on a timetable, published online, or represented on signage. For translations into other languages, use `translations.txt`.<br><br>Stops named after cross streets should separate street names by a single consistent separator within `stops.txt` (e.g., "at", "and", "&", "/"). The first street name should be the street that the vehicle is travelling on at the time of the stop, and the second street name should be the cross street (i.e., < first street name > < separator > < second street name >).<br><br>When the location is a boarding area (`location_type=4`), the `stop_name` should contain the name of the boarding area as displayed by the agency. It could be just one letter (like on some European intercity railway stations), or text like “Wheelchair boarding area” (NYC’s Subway) or “Head of short trains” (Paris’ RER).<br><br>Conditionally Required:<br>- **Required** for locations which are stops (`location_type=0`), stations (`location_type=1`) or entrances/exits (`location_type=2`).<br>- Optional for locations which are generic nodes (`location_type=3`) or boarding areas (`location_type=4`).| |
That was an existing typo. I agree it should be fixed but I don't think fixing typos from the spec is in scope here. |
Maybe not when it gets to fixing a random typo, but when you anyway change a sentence then I think we should fix. I haven't just stumbled uppon this typo but saw it in the diff. Also I don't see why shouldn't we fix it. Is there any disagreement in how this part of the sentence should be? |
|
This pull request has been inactive for some time. I think the major takeaways are:
This being said, I chose to abandon this PR as the advocate. If someone wants to propose codifying fields for cross streets as mentioned above, I would encourage them to advocate for that in a separate issue/PR. |
8 participants
As requested on a continued discussion at #282. Add best practices for
stop_namesnamed after cross streets.