Google Summer of Code/2017/PT Assistant Plugin
Jump to navigation Jump to search
- 1 PT_Assistant
- 1.1 Export validator issues as JSON report
- 1.2 Proper detection of public_transport:version
- 1.3 Edge selecting Map Mode
- 1.4 Add functionality for foot, bicycle and horse route relations
- 1.5 Roundabout splitter
- 1.6 Route creator
- 1.7 Specialised version of the Relation Editor
- 1.8 Route Master relation change management
- 1.9 Create a function that reorders the stops/platforms based on the order of the ways sequence. Possibly with user interaction, asking whether stops found along the itinerary ought to be included
- 1.10 Smaller improvements
- 2 Road Signs
Export validator issues as JSON report
- Add possibility to export reported errors and warnings from validator
Proper detection of public_transport:version
- Some routes are erroneously tagged as version 2. Applying fixes on such routes breaks them completely. So detection on what they contain (stops for both directions? ways for both directions?) Suggest to retag to public_transport:version=1, or to convert them (later on when that becomes possible)
Edge selecting Map Mode
- A new map mode that selects a string of ways, respecting oneway traffic and possible ways for the mode of transport for the route relation Relation Editor currently has focus
Add functionality for foot, bicycle and horse route relations
- support for foot, bicycle and horse route relations, which have a somewhat differing semantics
- help with moving bicycle route relations to highway=cycleway, where they are mapped separately
- which detects automatically on which nodes to split and which removes those ways that don't belong the point of entry and the point of exit from all relations that pass the roundabout
- download bbox to make sure all ways connecting to the roundabout are present (I usually use Overpass API to only download route relation members)
- find points to split roundabout way(s)
- ask user if it's OK to make roundabout round (this also distributes the way nodes nicely)
- loop over all route relations and repair them
- For a relation which only contains platforms/stops, make it possible to detect nearby ways and connect those. At the moment the focus of the plugin is fixing existing itineraries, which is great as a foundation for creating new ones. When data from the operators is available, this will translate in sequences of stops for each variation.
Specialised version of the Relation Editor
- "Fork" a specialised version of the Relation Editor, which gets invoked when pressing the fix button in the validator, or possibly always when editing route relations.
- Make sure this can be merged into core, when it become stable enough
- This RE should assist in getting the route relation cleaned up (stops/platforms in correct order/long string of ways from beginning to end)
- Move stops/platforms to the beginning
- Order stops/platforms so they make a logical sequence if the ways in the route are continuous/ordered
- Add stops/platforms to the route (with user interaction)
- Show how many issues the validator found with this route
- Find all ways next to platforms
- Help make the route continuous (ways) by making suggestions taking care of oneway traffic.
Route Master relation change management
- Change management for route_master relations (in case the lines coming from upstream operator data change) (I'm doing this myself in Django atm https://github.com/osmbe/public_transport, http://polyglot.ulyssis.be/lines/ Work in progress)
Create a function that reorders the stops/platforms based on the order of the ways sequence. Possibly with user interaction, asking whether stops found along the itinerary ought to be included
- If the route is known (the ways are mapped), allow the user to add platforms/stop_positions automatically (interactively)
add a little delay after automatic changes (1.5 seconds), so the mapper gets to see what the plugin is doing. When proposing several options to fix a route, don't show the whole stretch between 2 stops, but only show the differences and maybe one way in common on both ends, instead.
- Route relations for which oneway issues are reported (or that have segments where this is the case) shouldn't be used as "templates" to suggest fixes
- If a route can be made continuous by adding 1 way or a string of ways, with no ambiguity, propose that as a fix to be reviewed, to the mapper.
Pressing the fix button on "Route should start and end with a stop_position" could zoom in on the problem, select the way and open the relation editor. Provide a way to reopen the relation editor on the route that is highlighted by the plugin. Sometimes it's needed to close the Relation Editor to make some changes to the data. But in the mean time the reported route relation is already gone from the validator pane. (Maybe a hot key to reopen the relation editor that was closed most recently?)
- differentiate between tags that should go on the traffic sign node and those that should go on the OSM objects (mostly ways) that are affected.
- Integrate with Mapillary plugin