Define stop_lat & stop_lon as "where passengers are waiting"

[LeoFrachet]

GTFS producers are not all locating their stop lat/lon at the same place for buses:

• most of them are placing it on the sidewalk, where the passengers are waiting;
• a few of them are placing it on the roadway, where the bus stops (example: VVS in Stuttgart, Germany; you can see it in Google Maps or download the GTFS).

The specification is currently silent on this, it only says:

• stop_lat: "Latitude of the location."
• stop_lon: "Longitude of the location."

This proposal offers to specify it, choosing the most commonly use option: on the sidewalk, where passengers are waiting.

(To download the VRR dataset, follow this link, then click on "Herunterladen" — "Download" in German — then they will ask you if you're read the license agreement, click "Zustimmen" — "Agree" in German — if you agree to download it.)

Ping @aababilov

[flocsy]

+1

[tsherlockcraig]

This is very much needed, but two typos to fix and one question:

• "the coordinates must the ones" should read "the coordinates must be the ones"
• "For stops/platforms (location_type=1)" should be "For stops/platforms (location_type=0)"
• I wonder whether in some situations (larger platforms, bus stations with buildings where waiting is allowed far from the pickup location) this definition would encourage or allow locations that are too far from the roadway. What about a phrasing like "where travelers board and alight the bus" or "where the road and sidewalk meet and travelers board"? Potentially that type of phrase could remove the need for the parenthetical clarification too.

[LeoFrachet]

Hi @thomastrillium, thanks for the careful review.

I've fixed the two typos you pointed out.

Regarding waiting vs boarding, I agree that this is a tricky question (and I personally share your concerns).

I like the "where the road and sidewalk meet and travelers board".

As food-for-thoughts, I've just checked the PTv2 specification for bus stops (the data model used by OSM to describe public transit), they define two distinct objects:

• "Add a node at the location of the bus stop sign. "
• "If you choose to add a stop position node, place a node on the road where the bus stops."

And I'm starting to think that for bus stops, the current untold consensus is to put it at the bus pole, which is what passenger search when they search for the "bus stop", and which is technically neither where passengers wait (sometimes there is shelter nearby) nor where they board. (Sorry to complicate this).

So:

• Option 1 (the current one): where passengers wait.
• Option 2 (Thomas one): where passengers board.
• Option 3 (OSM one): where is the stop sign.

I have no strong opinion, but I agree with Thomas that the first one may lead to error in edge cases.

Thoughts? @thomastrillium @aababilov @gcamp @prhod @abyrd @paulswartz @devadvance @skinkie...

[skinkie]

Option 2 is what is commonly used in the EU. The OSM variant is a derivative of that, because if no stop sign exists, they still place a stopicon ;-) Anyway, for buses this is all easy, but what to do with trains?

[flocsy]

What are we talking about? Usually the difference between the "middle of the road, where the bus stops" is 2 meters away from "the bus pole" that is 2 meters away from the "shelter". All these together are way closer than the average GPS resolution for even a high-end phone (certainly in towns with high buildings). However if we were talking about an airport, where the airplane is about 100m from the point where they check the boarging card (within the terminal, where you can exit only if you have the matching boarding card) and you should usually sit "around" for a long time, then what would be the most convinient for the user? IMHO they should find the point where they check the boarding card for the specific flight. Pointing at the airplane would be useless in this case. And let's not decide for the user whether he "should" wailt standing in the line for 30 minutes before they open the boarding, or go 30m away to sit down. Now back to the bus and others: the sign (pole) would be the most convinient IMHO. There they can check that they're at the right stop (soon some apps will provide a way to check it by taking a picture). BTW: for train platforms (which are quiet long) it's a non-trivial decision. For terminals the "beginning" of the platform can be used probably, but for "go-through" stations... Not sure.

…

On Wed, Aug 7, 2019 at 5:33 PM Leo Frachet ***@***.***> wrote: Hi @thomastrillium <https://github.com/thomastrillium>, thanks for the careful review. I've fixed the two typos you pointed out. Regarding waiting vs boarding, I agree that this is a tricky question (and I personally share your concerns). I like the "where the road and sidewalk meet and travelers board". As food-for-thoughts, I've just checked the PTv2 specification for bus stops <https://wiki.openstreetmap.org/wiki/Public_transport#Buses> (the data model used by OSM to describe public transit), they define two objects: - "Add a node at the location of the bus stop sign. " - "If you choose to add a stop position node, place a node on the road where the bus stops." And I'm starting to think that for bus stops, the current untold consensus is to put it at the bus pole, which is what passenger search when they search for the "bus stop", and which is technically neither where passengers wait (sometimes there is shelter nearby) nor where they board. (Sorry to complicate this). So: - Option 1 (the current one): where passengers wait. - Option 2 (Thomas one): where passengers board. - Option 3 (OSM one): where is the stop sign. I have no strong opinion, but I agree with Thomas that the first one may lead to error in edge cases. Thoughts? @thomastrillium <https://github.com/thomastrillium> @aababilov <https://github.com/aababilov> @gcamp <https://github.com/gcamp> @prhod <https://github.com/prhod> @abryd @paulswartz <https://github.com/paulswartz> @devadvance <https://github.com/devadvance> @skinkie <https://github.com/skinkie>... — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#179?email_source=notifications&email_token=AAHI4REKKANSNAG2MBHQ5N3QDLMLDA5CNFSM4IKAVU52YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3YTLAI#issuecomment-519124353>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAHI4RCFRLUSXVSOZVI23Z3QDLMLDANCNFSM4IKAVU5Q> .

-- Gavriel Fleischer

[skinkie]

BTW: for train platforms (which are quiet long) it's a non-trivial decision. For terminals the "beginning" of the platform can be used probably, but for "go-through" stations... Not sure.

It is trivial for a transit standard that would support lines and surfaces, which GTFS does not, which is basically the problem here. There is a lot of momentum to rename GTFS into General Transit Frankenstein Specification, having every possible extension added to a too simplistic flat data model, while the industry already has a solution for it - or - and this is where Sean and Leo come in - try to define explicitly what things in GTFS should/must mean, while depending on context such things are now vaguely defined so they support a general definition how to model travel information could be exchanged. The stricter the definition the more extensions are required. And here we get into the self fulfilling prophesy that the standard is never finished. And we eventually arrive into a situation where people go ask "Is this an attribute, or a routable element?"

[botanize]

The policy at Metro Transit in Minneapolis is that operators stop at the transit sign. Sometimes they load one or two buses back from the sign, but they have to make sure there are no customers waiting at the sign before they can leave the stop. So even when a bus stops some distance from the sign, a customer should be guaranteed to board if they're at the sign. Thus option 3 best fits our policy and practice.

Waiting areas are adjacent to signs, so there's not really an issue with finding the waiting area. We have a few stops that are essentially at intersections and equidistant to two streets, however, the shape assigned to the trip serving the stop clears up any confusion about which street the stop serves.

We typically use the middle of our train platforms as the stop location, though that varies a little, apparently at random. Once a customer is at the middle of the platform they can easily follow signage if shorter trains are serving only part of the platform.

[barbeau]

And I'm starting to think that for bus stops, the current untold consensus is to put it at the bus pole,

This matches up with my personal experience talking with agencies that run buses. Often this comes directly from an asset inventory, which is based on the pole/sign position. All stops have signs, but not all of them have benches, sidewalks, etc.

It would be interesting to survey a large number of GTFS producers to see how this is currently being handled. It's certainly not a trivial thing to change in a dataset, so we might be better off trying to define the current practice rather than creating a standard ourselves.

[aababilov]

+1 from Google

The main thing we would like to avoid is getting a GTFS stop coordinates in the middle of the road. In this case, Google Maps navigate the user to a random side of the road. The user may cross the street, come to the wrong side of the road, realize that the instruction was wrong and see the bus departing from the other side.

[flocsy]

Some more thoughts about the bus stop position: - in narrow streets having the GPS coordinates of "where the bus stops" can cause some confusion if there are stops in both directions in the opposite side of the street. So from me this is one more +1 for the "bus pole's position" - poles are probably more constant than where the bus stops. As mentioned earlier if another bus is already occupying the nearest place on the road, then the next bus will stop 20m behind. So if it is so important to have a GPS coordinate with precision of less than a meter, then pole is better, it's fixed.

…

On Thu, Aug 8, 2019 at 9:08 PM Sean Barbeau ***@***.***> wrote: And I'm starting to think that for bus stops, the current untold consensus is to put it at the bus pole, This matches up with my personal experience talking with agencies that run buses. Often this comes directly from an asset inventory, which is based on the pole/sign position. All stops have signs, but not all of them have benches, sidewalks, etc. It would be interesting to survey a large number of GTFS producers to see how this is currently being handled. It's certainly not a trivial thing to change in a dataset, so we might be better off trying to define the current practice rather than creating a standard ourselves. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#179?email_source=notifications&email_token=AAHI4RGPI4NJQAGFENGHIB3QDROLHA5CNFSM4IKAVU52YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD34OMCA#issuecomment-519628296>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAHI4RB2GVTJHOCWX5LBY7LQDROLHANCNFSM4IKAVU5Q> .

-- Gavriel Fleischer

[tsherlockcraig]

In Saigon on a visit there last year I didn't find any bus stop signs, but came to realize 24 hours in that the diagonally crossed paint on the ground (which was usually somewhat faded) consistently indicated a bus stop. It's also common for rural American bus systems to have designated but unsigned stops.

I've used "right on top of the pole" before to describe to an agency what we were going for, but if it were used in the spec it would need to be as an example or in addition to another description.

[LeoFrachet]

Thanks for all your feedback! So maybe I should rephase by saying that:

the coordinates must be the ones of the bus pole — if exists — and otherwise of where the travelers are boarding the vehicle (on the sidewalk or the platform, and not on the roadway or the track where the vehicle stops).

[flocsy]

sounds clear

…

On Mon, Aug 12, 2019 at 6:21 PM Leo Frachet ***@***.***> wrote: Thanks for all your feedback! So maybe I should rephase by saying that: the coordinates must be the ones of the bus pole — if exists — and otherwise of where the travelers are boarding the vehicle (on the sidewalk or the platform, and not on the roadway or the track where the vehicle stops). — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#179?email_source=notifications&email_token=AAHI4RA7DQEZDCZH7POHTWTQEF5ZDA5CNFSM4IKAVU52YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4C4AYY#issuecomment-520470627>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAHI4RHOR6Y3ONIPSD3YJWDQEF5ZDANCNFSM4IKAVU5Q> .

-- Gavriel Fleischer

[aababilov]

+1 from Google

[prhod]

+1

[skinkie]

+1 OpenGeo

[harringtonp]

+1 YourStop

[gcamp]

+1

[LeoFrachet]

Since everybody seems to like the proposed phrasing I've just updated the proposal and we can open the vote.

The vote will be closed on Wednesday, August 21st at 23:59:59 UTC.

@gcamp, @harringtonp, @skinkie, @prhod, @aababilov and @flocsy could you please recast your vote, now that the vote is open?

Thanks!

[harringtonp]

+1

[gcamp]

+1

[mgilligan]

+1

[skinkie]

+1 (OpenGeo)

[LeoFrachet]

Vote closed. It passed by four +1 (MBTA, OpenGeo, Transit, YourStop)

[aababilov]

Late +1 from Google. I am happy to see this merged.