Propagating changes

[dabreegster]

There are a few cases today where it's the caller's responsibility to restore invariants after one operation:

1. After remove_road, it's possible an intersection will be left orphaned, with no roads pointing to it. Those must be removed.

   osm2streets/osm2streets/src/transform/collapse_intersections.rs

   Line 123 in a902134

   // We may have created orphaned intersections. Clean up here.

   is one place I just added to manually fix this.
2. update_movements has to be called when anything connected to an intersection changes
3. update_center_line needs to happen when reference_line changes
4. collapse_short_road may produce a loop-road that should get removed later.

   osm2streets/osm2streets/src/operations/collapse_short_road.rs

   Line 119 in a902134

   // Consider when two dual carriageways intersect. After collapsing 3 of the short

I'm working on a 5th, regenerating intersection geometry + trims.

Relatedly, I forgot where, but there's some branch where I can improve final geometry, but only by rerunning some transformations after generating intersection geometry. That process calculates trims, discovers roads too short to exist, and then we collapse short roads again. There's a case where if we CollapseDegenerateIntersections after that, we make even more progress somewhere.

An idea that's arisen somewhere before is to do more granular change tracking. Low-level operations like remove_road and collapse_intersection can precisely say which roads and intersections they touch. We could make a helper track those changes, and re-run transformations and operations on modified things. How exactly should that work? Should every transformation right now be re-expressed to operate on just a piece of the network, and we have some rules about retrying all transforms when something changes? Just starting this issue to brainstorm

[dabreegster]

#136 (comment) was the description

[dabreegster]

Just dumping raw notes related to this:

    - first look at whole network, then do dirty bit things
    - geometry says this looks like u-turn, fix it up
            - what changes now that we determine that?
    - transformations are like rawmap editor actions, higher level
    - cycleway snapping is a case where the collapsing might happen too early
            - how should collapsing actually work? keep the graph the same
            - low-level street network OSM node
            - Junction with 1+ nodes, uses pretrimmed distances
            - DC join needs to radically alter reference line of the Y shape
            
            - 3 levels of stuff?
                    - Junction is a full subgraph of stuff
                    - the intermediate thing is just where we currently collapse. movements here?
                            - the geometry for pretrimmed case is higher level, has access to lower level thing
                            - less state? the collapsed road isnt gone. just views on top of stuff
            - or simplify. if the transformation needs OSM level stuff, just do it before we collapse.

In the short term to move forward on #136, I think that last idea is the key -- front-load transformations that need to see something closer to OSM graph

[BudgieInWA]

On the topic of reordering transformations, I didn't get to mentioning this during the meeting:

I think for the purposes of testing/evaluating osm2streets we should stop inferring sidewalks everywhere, and should disable the shrink_roads transformation as it is too-blunt an instrument.

[dabreegster]

2023 will be the year of ripping of all the old bandages! I'd be happy for both changes. The first will start forcing us to reckon with separate sidewalks finally. Within osm2streets, the goal for correctness is sane geometry / rendering. For traffic simulation and road-space reallocation over in A/B Street, parallel ways without any kind of higher-level Corridor will still be a problem, but I'll just keep enabling the option in the meantime.