Editing items

[maxwell8888]

Example use cases

Can be easily done by manually updating individual fields

1. Changing the frequencies of a trip.

Would benefit from automation or specfic controls

1. Consolidating multiple routes into a single (existing or new) route.
2. Split a route into multiple routes.
3. Moving, removing, and adding stops/stop times.

Editing

Updates

All fields can be directly individually edited. Some will require format checking or specialised input controls, eg for dates, etc. Could even have user specified formats to enforce things like naming conventions for routes. Reference/relational fields like trip_id, stop_id, service_id, agency_id, route_id, shape_id, etc are updated by selecting from a list to ensure only valid ids are used.

For updating fields related to ordering like route_sort_order or stop_sequence, will need to update by moving the item to a new position (using keyboard shortcuts initially, but maybe drag and drop in the future), rather updating the numeric value directly to:

• avoid having to update every single numeric value in the list every time
• prevent creation of duplicate values for stop_sequence

Deletions

It would be useful to still see deleted items in the main item list, but greyed out. 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. This makes it easier to display deletions in context, easily see if there has been a deletion, and reuse/copy their data for other items.

Agencies, routes, trips

Deleting any of these will also delete all "child items" eg deleting a route also delete all it's trips.

Stop times, frequencies, and shapes

Can all be deleted directly with no knock on effect. Deleting a trip will delete all of it's stop_times, frequencies, and shapes.

Stops and calendar

Stops and calendar items cannot be deleted unless they are not referenced by any stop_times or trips respectively. When all referencing trips/stop_times are deleted, the referenced calendar/stops won't be automatically deleted, but will now be deletable individually. Will allso provide functionality to clean up all orphaned stops and calendars in one go. This cleanup functionality is related to validation functionality which should be reasonably distinct, and users can do it all in one big lump before saving/publishing.

Tracking edits

For each type of item, eg route, trip, stop, agency, etc, provide the following "edit types":
Create new
Delete
Update

It should be possible to delete edits, which will restore the app data to what is in the gtfs file.

If there are multiple types of edits for the same item, they will be all displayed together. Eg if an item has had a field updated, and was then subsequenttly delete, both edits should be displayed together. If a new item is created and then subsequently deleted, it makes no sense to delete the created edit with also deleting the delete edit. However, edits will need to be stored separately in order to function as an edit/undo stack.

Currently displaying edits in a separate list, but it probably makes sense to just show them in the actual item list and just provide a filter to only show items which have been edited as an equivalent to the edits list. Or at least have a flag for items in the item list to signal that they have been edited, with link to the edit. This might be better since we can't we display delete edits in the item list, unless we just displayed them greyed out or something, but would need to distinguish that from items that are simply deselected from the map.

[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!