Proposed best practice: shapes.txt should be included

[e-lo]

In order to provide transparency into the route for both the end-user as well as arrival prediction engines, shapes.txt should be included as a file and provide "reasonable and feasible" shapes associated with each transit trip.

Current relevant best-practice:

Must be provided in both shapes.txt and stop_times.txt if an alignment includes looping or inlining (the vehicle crosses or travels over the same portion of alignment in one trip).

[scmcca]

I'd prefer a general statement in the "All Files" section that applies to all optional files and fields for data completeness (cc #45). Something like:

For data completeness, all optional files and fields should be provided if the information is available.

[e-lo]

I'm not opposed to this in principle, but in practice the information often isn't "available" unless it is created (this is particularly true of shapes.txt). I'd like a way to ensure that "following GTFS Best Practices" means investing in providing important files like shapes.

[scmcca]

In what sense are paths traveled by a vehicle not available by an agency?

[e-lo]

In what sense are paths traveled by a vehicle not available by an agency?

You'd be surprised 🥲

But in all seriousness, "availability" could be interpreted subjectively.

• Most of the time this may be available in some format (sometimes in paper turn-by-turn route directions) but the friction of going from "whatever format they are in" to shapes.txt costs $ and often isn't done unless it is "required".
• In other cases transit providers may dictate that a contact operator stop at certain stops, but not given certain streets/routes they need to travel. The streets/routes exist at the contracted operator somewhere...but since they aren't often required to give it in shapes.txt format they often do not.

[Sergiodero]

As GTFS Best Practices (BP) are currently in the process of being merged to the specification, MobilityData is migrating outstanding issues and PRs from this repository to google/transit. Thus, this issue will be closed and further discussion regarding this BP should take place in google/transit. Please refer to Issue #421 for a more detailed explanation of the migration process and the proposed next steps.

With this, we’re hoping to bring more visibility to outstanding BP issues and to restart the discussion around them, so that any improvement that the community finds valuable could be carried forward.