Comments (5)
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.
from gtfs_manager.
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.
from gtfs_manager.
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.
from gtfs_manager.
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.
from gtfs_manager.
Real life scenarios should be forthcoming with meeting with @fred-r-ramos colleagues!
from gtfs_manager.
Related Issues (20)
- Grey out part of minimap outside viewfinder
- Panning drag which ends in minimap
- Improve speed of changing zoom levels
- Click blank space on map to deselect object
- Hovering highlights wrong stop when zoomed in HOT 1
- Edit trip shapes
- Keep trip shape after stop has been edited
- Bitmaps clip new paths outside original latlong coordinate bounds
- In the list, for a given route display all trips at the same time HOT 2
- Build failing HOT 1
- Tweet
- Slow performance in stop selection mode
- Provide additonal examples of sample data HOT 9
- Clean up code
- Fix known bugs and panics
- Add video or gif to README demoing app
- Update README
- Clean up UI
- Panic editing stops when zoomed into to immediate mode
- Reddit post HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from gtfs_manager.