Editing items

[spstreets]

Editing items

[dabreegster]

Any initial thoughts about how to handle indirect consequences of deleting something? If I delete all of the stops from a route, should the route still be considered valid? If you choose to auto-cleanup the "orphaned" route and the user later undeletes one stop (possibly out of order from the original deletion sequence), would you try to restore the route?

This is a bit related to https://en.wikipedia.org/wiki/Undo#Undo_and_redo_models. I ask out of curiosity; I've waded through messes like this before with editing lanes and intersections that're inter-dependent. Maybe the simple approach is best -- display some kind of "object 1 refers to deleted/nonexistent object 2" warnings, and leave conflict resolution up to the user.

[maxwell8888]

Just on a point of terminology, where you talk about a route with stops, I'm assuming you are talking about what in the spec is called trips with stop_times?

I don't think there is anything in the spec about trips being required to have more than 0 stop_times, so probably wouldn't do auto-cleanup, to keep things simple and flexible. But say the user does delete all the stop times in a trip and then the trip itself, I think it would be best to force the user to undelete the trip first, then undelete the stop_time. It is for this kind of thing that it would be nice to display the edits in the actual item list (the hierarchical list of agencies -> routes -> trips -> stop_times), that way if a certain item is deleted it is easy to just grey out all of it's child items so they can't be further edited until the delete of the parent item is deleted. Not sure if that makes sense, not easy to put this stuff in words and i've made up a bunch of terminology! For actual stops, it definitely gets more complicated because ideally you want to allow a stop to be deleted, and then all stop_times that are for that stop, in all trips, to also be deleted. Which is fine, but then to delete this edit, do we just restore all related stop_times which have ever been deleted, or just the ones that were deleted as a consequence of the stop being deleted? But I haven't got to stops yet, but I don't think it will be much of a problem coming up with some heuristics.

[dabreegster]

Just on a point of terminology, where you talk about a route with stops, I'm assuming you are talking about what in the spec is called trips with stop_times?

Yep, sorry, I've gotten sloppy with terminology. I've been grouping all of the trips of a route together by (stop ID sequence, headsign, service, shape) and calling that a "variant", and doing most of my reasoning based on that.

I think it would be best to force the user to undelete the trip first, then undelete the stop_time.

Reasonable. A stop time can't really exist without its parent, and the other things in the hierarchy you listed seem like they could follow a similar rule.

For actual stops, it definitely gets more complicated because ideally you want to allow a stop to be deleted, and then all stop_times that are for that stop, in all trips, to also be deleted. Which is fine, but then to delete this edit, do we just restore all related stop_times which have ever been deleted, or just the ones that were deleted as a consequence of the stop being deleted?

I don't know what the UX should be... one answer is to punt and only all the "linear" undo, where you conceptually save the full state at every edit. You can only undo the most recent command, which just pops back to the previous state.

Maybe we need to think through some real-life scenarios for editing GTFS and figure out what would be appropriate. Maybe somebody realizes there are several similar routes that should be consolidated, and so they delete the entire route, and want to automatically clean up orphaned/unused stops. Then they adjust a similar route to visit one of the stops just deleted from the first route. Would it be helpful for them to still see the old deleted stop and be able to restore it? Probably... it may have physical assets like signage or a shelter that could be reused. So maybe there's an argument for always showing "orphaned" stops. When things change in reality, the GTFS is updated, and a later session has no reference at all to a truly decommissioned stop.

[maxwell8888]

I definitely think some real-life scenarios will be helpful. For adding an orphaned stop to a route, I'm that I simply won't automatically delete unused stops. I'm thinking about being reasonably flexible about allowing things like this, partly because I get the impression that GTFS data in the wild is not very rigorously validation for this kind of thing so would want the app to be able to handle this kind of thing, but also because I'm doing it would be good to provide some validation and cleanup functionality but for this functionality to be reasonably distinct, so users can do it all in one big lump for publishing if they want.

And yes it would definitely be useful to still see deleted stops, or probably any item. This is where something like deletes in the main item list, but greyed out or something would be particularly useful. In general, I see deleting more as a flag that the data has been removed (but is still accessible), until the updated data is actually exported from the app to a GTFS file, rather than actually removing the data and making it inaccessible until restored.

[Robinlovelace]

Real life scenarios should be forthcoming with meeting with @fred-r-ramos colleagues!