On shape_dist_traveled...

[Brian Ferris]

I was looking at a few edge-cases in some stop-to-shape matching code this week and I realized that I had made some assumptions about the "shape_dist_traveled" fields of stop_times.txt and shapes.txt that maybe weren't valid.  Most of the assumptions had to do with "partial" specification of shape_dist_traveled values.  Thoughts on the following?

1) In shapes.txt, is it valid to specify "shape_dist_traveled" values for a subset of the points of a particular shape?  For example, is the following valid:

shape_id,shape_pt_lat,shape_pt_lon,shape_pt_sequence,shape_dist_traveled

shape0,47.0,-122.0,0,0.0

shape0,47.1,-122.1,1,0.5

shape0,47.2,-122.2,2,

shape0,47.3,-122.3,2,0.75

Note how the third point doesn't specify a shape_dist_traveled value.

My initial reaction would be that this is an error.  That is, if you specify a shape_dist_traveled value for any of the points of a particular shape (identified by the same shape_id), then you should specify shape_dist_traveled values for ALL of the points.  The whole point of specifying shape_dist_traveled values is to allow an agency to precisely define how stops should match a trip's shape.  By leaving some of the shape_dist_traveled values empty, you are potentially falling back to client's interpretation of the best match.  Additionally, since most shape_dist_traveled values are generated as part of an automated export from a GIS or scheduling system, it seems strange to leave some points unspecified.

Indeed, I've only been able to find one or two feeds that partially specify shape_dist_traveled values for a shape.  If others agree that partially specifying shape_dist_traveled doesn't make sense, I would probably add a validation check for this.  Additionally, if we thought it worthwhile, I'd propose adding the following to the shapes.txt shape_dist_traveled spec:

"If the shape_dist_traveled field is specified for any points belonging to a shape, then it must be specified for all points belonging to the shape."

2) In stop_times.txt, is it valid to specify "shape_dist_traveled" values for a subset of the stop-times of a particular trip?  For example, is the following valid:

trip_id,arrival_time,departure_time,stop_id,stop_sequence,shape_dist_traveled

9345056,07:11:00,07:11:00,21758,1,0.000000

9345056,07:14:00,07:14:00,21749,2,0.650000

9345056,07:20:00,07:20:00,99496,3,1.692803

9345056,07:32:00,07:32:00,99473,4,

9345056,08:03:00,08:03:00,12049,5,24.0596591

9345056,08:05:00,08:05:00,40244,6,24.3607955

Note how the fourth stop-time of the trip doesn't specify a shape_dist_traveled value.

Like the shapes.txt discussion, my initial reaction was also that this is an error, mostly for the same reasons.  However, I've found more feeds that do this (~20).  For example, the above example was pulled directly from the San Diego MTS feed.  And I can see how GTFS consumers can work around such cases: if shape_dist_traveled is not specified for a stop-time, use standard stop-to-shape matching for that stop.

That said, it still surprises me that agencies are partially specifying shape_dist_traveled values.  I'm curious to hear from agencies producing GTFS.  Is this a "feature" you are taking advantage of?

Thanks,

Brian