propose location_type=4 (Internal timing point)

[antrim]

A proposed field, stops.hidden, indicates if a stop, station, or other facility is relevant for display in passenger-facing applications.

• 0 or blank - passenger-relevant facility should be shown in maps and other applications.
• 1 - an internal-only location or facility such as timing point that does not allow passengers to board or alight.

Currently, internal timing points are sometimes published in GTFS datasets. stop_times.drop_off_type and stop_times.pickup_type are not adequate to indicate there is not service to those location because a stop that is temporarily closed might still be useful to show in a map.

[Update, 2017-January-4: The proposal for a stops.hidden field has been withdrawn and replaced by a new location_type=4.]

[antrim]

Important note: There are no consuming or publishing applications for this field right now, so before this can be accepted we will need to application developers and data suppliers to support this field.

[barbeau]

It should also be noted that, as proposed, this could be considered a breaking change for existing consumers. If producers start adding hidden stops to stops.txt and existing consumers aren't updated to consume this field, those consumers will show these hidden stops to users as if they were normal stops.

[barbeau]

I prefer adding a new location_type solution to adding the hidden field. IMHO this is a better distinction that these items are logically different, and also is a better step towards backwards compatibility. Consumers at least have some indication that the data is different if a new field value for location_type is detected, vs. ignoring a new hidden field and the data otherwise appearing identical.

[antrim]

I removed stops.hidden and added location_type=4
Trillium-Solutions@ff5ad2e

[mmorang]

Shouldn't all stops be "passenger-relevant locations"? I mean, if they're not relevant to passengers, shouldn't they not be included in GTFS, for which the primary purpose is routing applications? I am concerned that agencies might be tempted to clog up their GTFS feeds with asset management type stuff.

[antrim]

Hi @mmorang : The thinking here is that feed producers are already including non-passenger-relevant locations in their feeds (usually AVL timing points) and this information is useful for arrival prediction systems that consume GTFS. Non-passenger-relevant locations can and should be marked with pickup_type and drop_off_type values of 1 (no passenger boarding alighting) but it's also useful to designate that the location should not appear on a map (stops.location_type=4). It's not perfect, but it's the best compromise to adapt to existing practice and need without completely breaking backwards compatibility.

[barbeau]

@mmorang I have some of the same concerns. However, things like timepoints that may not be co-located with stops are definitely needed in GTFS - without them you can't even calculate on-time performance from GTFS data (see page 87 and 100 in this report for details).

After thinking about this more, I think we should add a location_type=4 that is specifically for schedule timepoints, vs. a more general catch-all for "non-passenger relevant location". This is the primary use case for this field anyway (as far as I'm aware - someone correct me if there are others), and it would constrain usage so that producers and consumers have better guidance and consistency for what this element represents. If we do this, there should also be some language added surrounding stop_times.timepoint - if a stop is location_type=4, then all occurences of that stop_id for records in stop_times.txt the stop_times.timepoint field, if provided, should be set to 1.

[LeoFrachet]

+1 for the location_type=4 meaning "Internal timing point. A timing point location where passengers cannot board or alight. When referenced in stop_times.txt, pickup_type and drop_off_type values must be 1 for an internal timing point."

[mgilligan]

+1, location_type=4 with Leo's language. No hidden field.

[abyrd]

I agree, no hidden field. location_type=4 seems like the right approach. I prefer the narrow definition stated above by @leofr, which can be expanded in the future if some other use case comes up.

[antrim]

This is operational data that is relevant to the discussion of runs in GTFS. See #195.

[antrim]

Another use for a "not a stop" location type: designating the start or end of "continuous stops" sections ("flag stops" or "hail-and-ride") along a trip when those points are not also published stops (see GTFS-ContinuousStops, #208). Like internal timing points, this can currently be indicated by setting drop_off_type and pickup_type to 1, but the meaning could be made less ambiguous for consuming applications.

Below are examples of flag stop and "no stop" zones:

• MVRTA (http://www.mvrta.com/routes/route-54/)
• GATRA (https://www.gatra.org/routes/route-6/)

[abyrd]

It looks like there was a fair amount of agreement on this proposal. Should we revise and vote on it? Is anyone in a position to start including location_type=4 in their feeds so we have a producer?

[davidlewis-ito]

I think location_type=4 is already taken as a Boarding Area.

[timMillet]

Indeed, location_type=4 is a boarding area.

Also, just a heads-up: according to MobilityData's GTFS-Vehicles proposal, location_type=5 would be a head boarding area, i.e a boarding area that allows sequencing the other boarding areas of the platform (goal: matching vehicle doors with boarding areas, useful on train and subway routes to tell the user where to wait on the platform). This proposal may evolve, though.

[stale]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This pull request has been closed due to inactivity. Pull requests can always be reopened after they have been closed. See the Specification Amendment Process.