Update also stop locations

[fcornelius]

Thank you for your work, the shape matching works really well. It would be nice though, if the GTFS stop locations inside stops.txt were being filled or updated with the ones from OSM as well. For my specific use-case, I need to find the path between two stops from a GTFS file. This is hard if the stop locations don't line up with shape coordinates and some stop coordinates do not appear in the shapes (location differences between OSM and GTFS). So basically the other way around as GO_Sync does it.

So when matching a trip to a route relation, not only save way elements but also the "stop"/"halt" nodes. Update stops.txt entries for stops inside the trip with the respective location of OSM stop nodes. Shortened trips that differ from the standard route as it is described in the OSM relation can maybe even be ignored, as they should be covered by the "default trip".

What do you think of this?

[patrickbr]

Yup, I considered this for a while back in 2018. Those were my thoughts back then:

1. The biggest problem is that many, many feeds only have a single stop with a position at the station center for all lines serving the stop. In general, there is no 1:1 relation between a stop and a shape, which is also why shape_dist_traveled for stops is stored in stop_times.txt per trip, not in stops.txt. So you either would have to use the location on the shape of a specific trip serving the station as the new stop location, or you would have to introduce new child stops which are directly on the track. The latter is too much semantic change in my opinion. It is also a bad idea because of my second point:
2. GTFS has no location_type which describes the exact position a vehicle stops. There a location_types for entire stations, for a "location where passenger board or disembark", for station entrances/exits, for boarding areas and for generic nodes inside stations, but not for "position where a vehicle comes to a halt". Such a location_type is indeed not necessary, because of my third point:
3. You can exactly encode where a trip comes to a stop on a shape by the value of shape_dist_traveled in stop_times.txt. pfaedle should correctly update the shape_dist_traveled value after map-matching, so you can very easily get the position on a shape where the vehicle stops at a station.

[patrickbr]

Did you have any success using shape_dist_traveled for the task you described? I am leaving this issue open, because your last sentence, if I understood it correctly, is actually something I wanted to implement for a few months now:

Shortened trips that differ from the standard route as it is described in the OSM relation can maybe even be ignored, as they should be covered by the "default trip".

I am reading this as "don't redundantly store shapes which are covered by other shapes".