RFC: mandatory shape_pt at at most 2m from stop

[skinkie]

Describe the problem

GTFS shapes.txt allows a very funky description of the route over the road. I'll here give two valid examples.

1. Two shape points are defined a kilometer apart, the straight line follows a straight road, a stop is in the center, description within GTFS can be correctly positioned using shape_dist_traveled (in stop_times.txt)
2. Two shape points are defined two kilometers apart, following as the crow flies this is only one kilometer, correctly positioned using shape_dist_traveled (in shapes.txt)

Use cases

Any system that segments shapes from stop to stop.

Proposed solution

A new best practise for shapes.txt. When shapes.txt are in use the minimum is a false node as shape_point in the direct neighborhood of the stops.txt entry, at most 2 meters from that position.

Additional information

No response

[felixguendling]

The alternative would be that consumers create this artificial node internally (which could also be made a "best practice").

Since MOTIS currently does not do this, we would definitely benefit from the best practice you propose.

If the majority of consumers would not handle the Variant A correctly, the question is: why only a best practice and not a requirement in the spec?

The distance of 2m is very strict. In most cases, a higher distance would still work (depending on the use case).

[skinkie]

@felixguendling situation B cannot be done from client perspective using the shape_dist_traveled, unless the client would scale the as the crow flies distance, or ignore the shape_dist_traveled altogether, or do some kind of map matching. I find it technically very interesting and well thought that GTFS has the option to express a longer distance than as-the-crow-flies between two shape points, since it allows for generatisation.

The "problem" within GTFS is that this calculation might be different for all trips. There is no normalisation for shape_dist_traveled.

I am all for making this a requirement in the spec, but the 2 meter would be a best practice.

[MichaelKutzner]

@skinkie As far as I understand the specifications, shape_dist_traveled can use any unit. So having a direct distance of 1000 meters, while the difference between both shape points is 2000 should be totally fine. I'm not even sure, the "distance" needs to be consistent on one trip. (At least I didn't read anything about that.)

I'm not sure, if I understand example 2 correctly, as we only know two shape points and nothing in between. (If we would know more, there had to be more point as well.) So the only assumption we can make is, that any stop on that segment needs to on the direct connection between those. Using shape_dist_traveled, we can interpolate and guess its location. But I would prefer, if there were any shape points nearby. Making it a requirement would therefore help us, too.

[skinkie]

@MichaelKutzner think implementations can do a lot of things, like taking the nearest shape point before the stop, and draw a straight line from stop location, do an nearest point to the linestring. All fine for me, but I hope that everyone would agree it would get a lot easier if stop-to-stop shapes.txt would be the result of this change.

[felixguendling]

I am all for making this a requirement in the spec, but the 2 meter would be a best practice.

I agree with both:

• spec: there should be at a minimum of one shape point associated with one stop in the proximity of the respective stop
• best practice: proximity = <2min

[gcamp]

Do you have examples where it's reasonable to have stops relatively far away from the shape?

I can't think of an example but open to be proven wrong. I'm also assuming :

• the shape is where the vehicle travels
• the stop location is where riders and board/alight the vehicle. The stop location should not be 1) the center of a station (that should be a location_type=1 2) entrance location (should be location_type=2).

I think 2m is very small and should be expanded. The quite common and valid case of shape going in the middle of the street and stop on the curb doesn't fit that 2m requirement.

[skinkie]

@gcamp examples where the shape point is independent of the stop are plenty. I have personally solved these cases by assuming that to shape points form a line, and, if no distance is available, the stop can be projected orthogonality to that segment, otherwise it is projected towards the same shape_dist_traveled.

I guess in Europe 2 meters should work, as the width of the road is 3.25-3.50m, center would then be 1.75m from the curb.

[MichaelKutzner]

@MichaelKutzner think implementations can do a lot of things, like taking the nearest shape point before the stop, and draw a straight line from stop location, do an nearest point to the linestring. All fine for me, but I hope that everyone would agree it would get a lot easier if stop-to-stop shapes.txt would be the result of this change.

I agree, there are many things implementations can do. I just wanted to make clear, that we are missing information in these cases and then have to make a guess, that can be arbitrary wrong.