dabreegster
commented
1 year ago @BudgieInWA had asked by email:
In the course of implementing the editing capabilities, it seems like you will be writing
reorder_lanes(...), but alsoadd_lane_at_positionandremove_lane_at_positionetc., evenadd_sidewalk,add_bus_lanes, etc. It occurs to me that those logical modifications to an existing road are the same sorts of modifications that osm2lanes wants to make during the "building" stage of the process. I wonder if one of the goals of osm2lanes should be a mutableRoadtype with an API designed for editor applications s to use interactively. That way, the current state (list of lanes) can be returned from wasm to JS, the current state can be rendered based on it, then the editor can capture the intent to make some change that is supported -- such asreorder,remove_lane,add_sidewalk-- which can be sent back to wasm, to let osm2lanes figure out the nuances of that change, before returning the new state to update the UI accordingly.
100% agree. I've already hit this problem with the prototype -- if you drag a "new driving lane" card somewhere, we need to auto-set the direction based on its position, and preferably use the locale's default width. Some of this code already exists actually, but in perhaps the "wrong" layer: https://github.com/a-b-street/osm2streets/tree/main/street_network/src/edit.
I'm thinking through some options for moving it. The main friction is that A/B Street and osm2streets use a LaneSpec definition unrelated to osm2lanes. I've had trouble pushing through #71. One possible smaller step is to make the osm2streets StreetNetwork layer directly use osm2lanes definitions of lanes, and then transform to A/B Street's LaneSpec later on in that codebase. This would be a slightly easier migration maybe.
BudgieInWA
I have now started a very minimal prototype in https://github.com/a-b-street/osm2lanes/tree/web_editor to make a new web app that lets people select an OSM way, see the rendered lanes in a cross-section view, edit those lanes (adding, deleting, reordering, modifying width, etc), generate the OSM tags for the changes, and upload to OSM. This is a step towards making it easier to edit lane data in OSM.
@BudgieInWA and I discussed some of the complications that'll come up. Two of the big ones:
1) When a road is split into multiple parallel ways, what do we do? The lane editor as I'm building it operates on a single way. We could maybe ask the user to draw a line and select all of the ways they want to edit, then present a unified cross section across all of them, and make it very clear which way is getting edited. Of course it won't be that simple, so to start, my goal is just to handle simple cases where one way corresponds to the "entire" road.
2) The left-to-right order of the draggable lane cards of course depends how the way in OSM is oriented. We need to display the way on the map and make it clear what's happening. Even better, leverage osm2streets + some rendering to draw the lanes on the 2D map at the same time.
I'm building using vanilla JS, which is new to me (this is a learning project!).
When I get something minimally decent open, I'll open a PR -- hopefully a few days if I can keep dodging other responsibilities. :)