Get transit shapes and stops to be stored as geodataframes

[e-lo]

This feature was ripped out when ripping out partridge, but the functionality was useful and should be restored.

[josiekre]

It was ripped out because Partridge's shape DataFrame collapses 1 shape into 1 row with a LineString (dropping the ID field if I remember correctly). This is helpful for shapes when it is actual shape information, but made it hard to search and swap model node IDs when editing the shape.

It's totally possible to use it again, but it'll probably require a re-write of the route/shape editing. The best thing would be to have the model nodes IDs be a list like column, using .map() or .apply() methods to search and edit them. Then shapes is free to just be a list of lat/lon.

[e-lo]

Just to be clear - that issue shouldn't affect the stops, right? If so then we can just go ahead and re-implement GDFs for that at some point w/out affecting the shape editing.

[e-lo]

And then for the shapes, I remember now why it is so much more straightforward to have them "long-form" rather than collapsing it into a shapely geometry. Given that, it might make more sense to store the shape geometry (as a shapely object) with the associated trips? Thoughts?

[josiekre]

Just to be clear - that issue shouldn't affect the stops, right? If so then we can just go ahead and re-implement GDFs for that at some point w/out affecting the shape editing.

Correct. The stops table stands alone without geographic information, so Partridge does not try to convert it to a GeoDataFrame.

Given that, it might make more sense to store the shape geometry (as a shapely object) with the associated trips? Thoughts?

In theory, yes. If I were to design GTFS, I would put each trip's shape geometry into the trip table directly. However, if we are trying to stick with GTFS convention, I would think it would make more sense to keep the shape table as it is intended to be used (as drawn lat/lon shapes, not necessarily network data). I would put the network data into a new table/file OR better yet I might rewrite the shape table to have a JSON column for its geometry (carry along variable not used inside NetworkWrangler) and a JSON column for a list of nodes traversed (used by NetworkWrangler).

id,shape,node_ids
93412,'{"type":"Feature",...}','[2464,346436,23423]'

[e-lo]

NOw implemented as an alternative query in v1 branch: #327