Add field stops.relative_position

[LeoFrachet]

Current issue

Currently some agencies put in stops.stop_name the information about the relative position of the stop (near side, far side, ...) because they feel that this information is relevant for the end user, even if it isn't included in the stop_name displayed in the street, on the maps or in the bus.

Examples:

• Valley Metro (Phoenix, US-AZ):
  • EB W VAN BUREN AV NS N 87TH AV,
  • SB N 67TH AV FS W CORRINE DR.
• Halifax Transit (Halifax, CA-NS):
  • Mt Edward Rd After Gerald St,
  • Mt Edward Rd Before John Cross Dr,
  • Mt Edward Rd Opposite John Cross Dr.
• RIPTA (Providence, US-RI):
  • BOON NS CONGDON,
  • S PIER OPP 172 S PIER.
• LTC (London, CA-ON):
  • Adelaide & Kipps Lane FS NB,
  • Adelaide & Kipps Lane NS SB.

Some agencies put this information in an extra field, which isn't part of the spec, which complicate the use of that data for GTFS consumers.

Examples:

• Madison Metro Transit (Madison, US-WI) uses a field stops.position which contains: "nearside", "opposite", "adjacent" or "farside".
• TriMet (Portland, US-OR) uses also a field stops.position, but the values are "Nearside", "At", "Opposite" and "Farside".

Goals

1. Allow the agencies to provide a clean stop_name, by providing the stop location in another field.
2. Allow the blind users to have standardized information about the stop position.

Proposal

(Optional) The relative_position field contains the relative position of the stop to the stop name. Allowed values are:

• blank: no position defined (default value);
• NS: near side of the intersection;
• FS: far side of the intersection;
• AT: stop is at position;
• OP: stop is across the street.

This pull request is a merge of different sources:

• The GTFS+ proposal of a stop_attributes.relative_position: http://www.transitwiki.org/TransitWiki/images/e/e7/GTFS+_Additional_Files_Format_Ver_1.7.pdf
• The TriMet proposal (Portland, US-OR) of a stops.position: https://groups.google.com/forum/#!topic/gtfs-changes/LlduFqXj9pg

[Edited 2017-02-16 20:19 EST: add "Current issue" and "Goals" sections]

[skinkie]

I find this so United States street layout specific, that I first want to have a discussion on the values in relative_position.

[barbeau]

@skinkie What values would you suggest?

[skinkie]

Stop names in The Netherlands are typically based on the name street perpendicular to the road the vehicle is traveling on. This would not allow to define relative positions.

[LeoFrachet]

@skinkie Is your point that it is not needed in the Netherlands, or that it is needed but the value currently defined do not describe properly the reality?

The way I would understand the current spec with stop_name beeing just the name of the perpendicular street, is that either it is NS, so the stop is just before the street, or FS, so the stop is just after the street.

But we can definitely add new values if you think there is countries where we would need them.

[abyrd]

I had a similar initial reaction to @skinkie, that this may too closely reflect a practice that is very specific to certain agencies or towns. Even riding transit in the US I don't recall ever seeing a stop designated this way (near-side, far-side). However, it does seem like a useful piece of information that is potentially applicable anywhere landmarks and street intersections are used as stop names, and could be helpful to riders even in places where this is not a common naming scheme.

@skinkie, naming a bus stop "Street X" with the additional field relative_position=FS means the bus stop is after the perpendicular Street X in the direction of travel; relative_position=NS means that the bus stops before the perpendicular Street X in the direction of travel. This seems meaningful any time a cross street is used as a station name.

The only other place I've seen this is in Singapore where it's very common to name bus stops "OPP X Park" or "OPP BLK 298B" to mean "across the street from" the named landmark, but the OPP is part of the stop name that everyone would know.

[barbeau]

Adding some context to this proposal - the stop position information is very important for blind riders. University of Washington prototyped crowd-sourcing this type of information as part of OneBusAway in the StopInfo project. It would be great if we could get producers to add this information themselves (along with readable stop names in #49).

@leofr You shared some examples from existing producers stop_names with me earlier - could you add them to this thread as well?

[tesobota]

Our agency currently uses free-text values to populate earlier referenced fields for both "position" (nearside, opposite, adjacent, farside) and "direction" (eastbound, northbound, etc. - as best can describe cardinal heading of vehicle when stopped).
Would be happy to truncate our existing "position" field text values into the abbreviated codes suggested, for addition of this new "relative_position" field.
Our agency has also coordinated in the past with Sendero group towards these attribute fields, to the extent this orientation information did improve wayfinding for individuals with sight restrictions.

[LeoFrachet]

@abyrd @skinkie Yeah, I should explain the context.

The goal is not really to push the agencies to provide that information. The issue is that currently there are many agencies who want to provide the information, and who put it in the stop_name fields. And as GTFS consumer, it is not the best option, because, as @abyrd pointed out, this is not on the stop name sign on the street. And often we do not want to display it as part of the stop name.

So the goal is to provide a field for the agencies which want to provide that information, so that they could remove it from the stop_name but still provide it.

Here are some example of what agencies currently do:
• Valley Metro (Phoenix, US-AZ) uses the bounds and the FS/NS pretty extensively:

9320,17474,EB W VAN BUREN AV NS N 87TH AV,,33.450915,-112.247178,,,0,
9321,14413,SB N 67TH AV FS W CORRINE DR,,33.600346,-112.202802,,,0,

• Halifax Transit (Halifax, CA-NS) uses words like "Opposite", "After" or "Before" (an also put the stop code in the stop name):

44.688365,0,7267,-63.507274,,,,,Mt Edward Rd After Gerald St (7267),0,7267,
44.680763,0,7261,-63.523808,,,,,Mt Edward Rd Before John Cross Dr (7261),0,7261,
44.680389,0,7260,-63.524155,,,,,Mt Edward Rd Opposite John Cross Dr (7260),0,7260,

• LTC (London, CA-ON) also uses a combination of bounds and NS/FS, with the stop_code postfixed.

43.018099,0,43,-81.246148,,,,,Adelaide & Kipps Lane FS NB - #43,0,1161,
43.01775,0,44,-81.24618,,,,,Adelaide & Kipps Lane NS SB - #44,0,1162,

• RIPTA (Providence, US-RI) uses abbreviation like "OPP" or "NS"

90,,"BOON NS CONGDON",,  41.425519, -71.460099,,,0,
95,,"S PIER OPP 172 S PIER",,  41.426203, -71.467536,,,0,

[LeoFrachet]

@tesobota Perfect, thanks! Sorry I didn't include Madison in the list of example. As food for thought for the other reader, here is was you do:

stop_id,stop_code,stop_name,stop_desc,stop_lat,stop_lon,agency_id,stop_jurisdiction,location_type,parent_station,position,direction,wheelchair_boarding
1111,1111,DOTY & M L K JR (EB),This EVENT/DETOUR ONLY stop (#1111) is eastbound on the 1 block of W DOTY ST nearside of MARTIN LUTHER KING JR BLVD,43.072938,-89.382354,MMT,CMAD,0,,nearside,eastbound,1
1135,1135,WEBSTER & MIFFLIN (NB),This EVENT/DETOUR ONLY stop (#1135) is northbound on the 101 block of N WEBSTER ST farside of E MIFFLIN ST,43.077272,-89.383413,MMT,CMAD,0,,farside,northbound,1

[abyrd]

Thanks @leofr for the additional context. Clearly we don't want this (nonetheless useful) information in the stop name field unless passengers understand it. Even seasoned transit riders might not guess what NS NB means and just see it as visual noise. I'm pretty sold on the relative position field, but I still don't quite get the cardinal direction field. This seems very specific to compass aligned street grids, and I don't see how it adds much information over the headsign, which is more flexible.

I now remember that Singapore also has Bef/Aft as well as Opp in tons of passenger-facing stop names. There should definitely be language explaining when these terms should be left in the stop name field, even if they are duplicated in the relative position field.

[skinkie]

Maybe an out of the box thought, why wouldn't you use this as a location description? As in a text field, not an enumeration? And yes, I understand the problem with localisation.

[LeoFrachet]

@abyrd I have not included the cardinal_direction field in my pull request. I have only included the relative_position one. Therefore I won't start the conversation about the cardinal_direction field in this thread.

@skinkie The four options are the ones which always appear in all the cases I saw. I didn't know that Madison was doing it, and the values that @tesobota gave us are those exact 4 ones.

The pro for an ENUM instead of a STRING are:

• field translation and localization;
• no need for a "readable" (or tts) version of the field;
• consistency between the producers ("adjacent" vs "at position" or "NS" vs "Near Side");
• the choice between showing abbreviation or desabbreviation is up to the GTFS-consumer.

=> Therefore I would tend to keep it as an ENUM.

But I may be missing cases that it won't handle. What do you have in mind when you say that a localization description would be better?

[tesobota]

ENUM would seem to have better internationalization, perhaps moreover with actual numerals for each eventual item (as opposed to English abbreviations?) Below would be a somewhat mnemonic clockwise clockface ordering:

1 Farside/beyond named cross-street, on a named street
2. Adjacent named landmark, on a named street
3. Nearside/before named cross-street, on a named street
4. Opposite named landmark, on a named street
5. "Offstreet" facility (i.e. terminal on a private driveway, not on any named street]
etc.

[barbeau]

I'd vote for an enumeration - it's easier for consumers to interpret and intelligently communicate to the user.

[mmorang]

I'm finding this whole discussion a bit confusing. I think I understand the problem the proposal is trying to solve, and it's an important one, but I don't think the proposal is the best way to solve it.

The stop "position" is defined by stop_lat and stop_lon. That's where the stop definitively is. I think what this proposal is trying to do is to find a way to describe where the stop is in relation to the closest intersection or street. That seems like a useful thing to do.

However, the proposal is assuming that stop_name is describing this street or intersection, but that assumption may not always be true. The name of a stop is pretty free-form, right? Agencies can name their stops anything which may or may not reflect the nearby street or intersection. Adding another field that describes the stop's location in relation to the stop_name field specifically doesn't seem like a good idea.

Rather, what GTFS really needs is some kind of information linking the stop's location to the street grid itself. In routing applications, you would use this street grid location as the start/end point of routes. Currently, I'm guessing most applications "snap" the stop lat/lon to the nearest street centerline on whatever street network is being used by the application. The closest street centerline may not always be the correct location where the bus actually pulls over and lets people on and off. This is because either the lat/lon is off a bit, or because (often) the bus travels on a major road with a wide right-of-way, and the stop sits on a corner with a smaller, narrower street, so the stop "snaps" to the centerline of the narrow side street instead of to the main road where it belongs.

So, if GTFS had definitive information about what street the stop should snap to, we would then actually know something about the nearby streets and intersections. So, we need some kind of street_location or location_relative_to_street field.

The trouble is that GTFS does not have any relationship with any particular street grid. You can use whatever street network you want, and it would be hard to maintain something like, say, an OpenStreetMap ID field. I don't really have a good suggestion on how to solve this problem, but I think this is the root of the problem underlying the proposal.

[skinkie]

@mmorang well written. The first thing with my technical brain was "we need OpenLR here", but the hole field is for human consumption hence my "location description". But maybe we should ask some input from our target audience that may use this information.

[LeoFrachet]

@mmorang I agree.

1. This information can be deduced by matching the GTFS with OSM, since the lat/lon of the stop (according to the spec) should be on the sidewalk.
2. As a regular public transit consumer, I just look on the map where the stop is, therefore I do not need such information.

But my issue is that many agencies keep putting NS and FS in the stop_name. Each time we ask them to remove it from there (because it doesn't belong there according to the spec) they answer that they need a way to provide that information to the transit riders, and that stop_name is the best place they have.

Do the users really need such information? I personally never used it, but some people do. Here is an example of email we got from blind people, asking why we do not display that information in the app:

I am a visually impaired person who benefits greatly from the Transit app in the city of Milwaukee WI. The visually impaired community is attempting to determine if it is possible for our local transit company to provide information about the location of the bus stops to the transit app so that a person who is blind could learn the proper location of the bus stop such is far side or near side stop or stop is on the northeast corner of such and such streets. Are there any Transit systems that have been able to provide this information that the Transit app could display? Our local bus system Milwaukee County Transit System claims they don’t know how this could be done.

So my goals are:

1. I want a clean stop_name, not a corrupted field, deviating from the spec. I want the stop name as it is displayed at the bus stop.
2. I want to improve the transit experience for blind users.

[barbeau]

I think the proposal would work as written, although it does rely on the producer giving good data in their stop_name field, and the consumer wouldn't really be able to reliably extract the specific street that the information is relative to. Another option would be to split out the cross street into it's own field cross_street (or something), with the relative_position being relative to that field.

So:

• stop_name = Adelaide & Kipps Lane FS NB

...turns into something like:

• stop_name = Adelaide & Kipps Lane NB
• cross_street = Kipps Lane
• relative_position = FS

You could go one step further and define the street for direction of travel too:

• primary_street = Adelaide

[LeoFrachet]

@barbeau There would be a lot of things to be said about your proposal. It would be awesome to have all that data, but I think it is way too bus specific and would create way too many edge cases (like a stop at a crossing where the bus change of primary street...).

I will update my first message to better explain the issue I wanna solve (aka copy/paste portions of my previous message), as a tl;dr for the people who will arrive late in the conversation and will skip the whole exchange.

[LeoFrachet]

First message edited.

[abyrd]

@mmorang makes good points here. Stops have coordinates, and the main missing piece of information is which street the stop is "attached" to. If we had that, it seems like the rest of these abbreviations would be irrelevant because apps could easily provide better guidance to blind riders. And trip planners would benefit generally from attaching stops to the right streets.