Shapes.geojson

[skinkie]

No description provided.

[github-actions]

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.

[skinkie]

Keep open.

[github-actions]

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.

[tsherlockcraig]

We'd need to get producers and consumers to go along, but for what I use GTFS for internally at WSDOT I'd support this change due simply to the ease at which I could visualize shapes.

One question: in shapes.txt there is a shape_dist_traveled value attached to every point in the line string, but in this proposal, it looks like there's just the one shape_dist_traveled total for the entire line string. Does this need to be adjusted to somehow attach a shape_dist_traveled to every point in the linestring array, or, is that unnecessary because it's actually only stop_times.shape_dist_traveled which needs to be used in order to disambiguate stops within loops?

[skinkie]

One question: in shapes.txt there is a shape_dist_traveled value attached to every point in the line string, but in this proposal, it looks like there's just the one shape_dist_traveled total for the entire line string. Does this need to be adjusted to somehow attach a shape_dist_traveled to every point in the linestring array, or, is that unnecessary because it's actually only stop_times.shape_dist_traveled which needs to be used in order to disambiguate stops within loops?

This is something you can only do if you would split the shape up in sub-stop-stop-pieces, which completely defeats the purpose of simplicity. Technically the representation within the current shapes.txt format allows for a higher precision than as the crow flies between two points, allowing to generate abstract shapes (for example for long distance busses and rail) but retaining the ability to attach the correct distance. Since we have a stop-stop-distance it does not interfere with average driving speed checks. So it might well be that shapes.geojson is most effectively used with a percentage, or would require a shape to be split up between two stops, opposed to the full journey with shapes.txt.

[github-actions]

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.

[skinkie]

Keep open.

[github-actions]

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.

[skinkie]

Keep open.

[doconnoronca]

The GTFS real-time specification already has an experimental specification for a Google encoded polylines. Having lines encoded using two different formats in the same specification is probably not a good idea.

[skinkie]

That argument did not make it for GTFS-Flex.

[github-actions]

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.

[github-actions]

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.