Google Summer of Code/2018/PT Assistant Plugin
- 1 PT_Assistant
- 1.1 Proper detection of public_transport:version
- 1.2 Edge selecting Map Mode
- 1.3 Add functionality for foot, bicycle and horse route relations
- 1.4 Roundabout splitter
- 1.5 Route creator
- 1.6 Specialised version of the Relation Editor
- 1.7 Route Master relation change management
- 1.8 Smaller improvements
- 2 Road Signs
===When detecting a problem with oneway traffic flow, look further. If this happens on the ways of a roundabout, or the ways on one side of a dual carriageway, propose to go around the roundabout the other way, or use the other 'leg' of the dual carrriageway. This kind of fix proposal should go in a separate category, as the way to fix it differs from what is done now for issues with oneway traffic (opening a relation editor with the 'offending' ways selected).
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
- Improve on the existing functionality, by making it possible to add and remove ways by making use of Shift and Ctrl in combination with left mouse button.
Add functionality for foot, bicycle and horse route relations
- At the moment interruptions are detected in foot, bicycle and horse route relations. For bicycle route relations it also makes sense to detect when the route goes against oneway traffic flow.
- help with moving bicycle route relations to highway=cycleway ways, where they are mapped separately. Usually the highway=* has a bicycle=use_sidepath in that case.
- The roundabout splitter works nicely for public transport route relations of version 2 at the moment
- It doesn't do well for PT v1 and it doesn't work properly for bicycle and foot route relations.
- For a route 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
- Reorder stops/platforms so they make a logical sequence if the ways in the route are continuous/ordered (the functionality was coded in 2017)
- 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.
- Give an indication of v1 or v2 and make it easy to (re)tag to v1 or v2
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)
- If the route is known (the ways are mapped), allow the user to add platforms/stop_positions automatically (interactively)
- If a route can be made continuous by adding a string of suitable ways, with no ambiguity and without going against oneway traffic flow for the mode of transport, propose that as a fix to be reviewed, to the mapper.
- Detect that the same stop is in the sequence more than once (with no other stops in between), fix by removing the duplicates.
- There seems to be a bug in the functionality to reorder the stops. It should take into account right hand or left hand traffic (MapCSS can do this, so it must be available to JOSM) and only add stops once to the route relations in case of 'spoons' (the itinerary uses the same sequence of ways to go to a loop as it does in reverse to come back to the main route)
- Compare route_ref on the stops with the list of ref tags in the route relations (functionality exists already to compile that list). The user can either modify route_ref based on the routes in OSM, or they will know that not all routes are mapped yet for that stop. Maybe information level, instead of warning.
- 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