Determine road geometry before path geometry about osm2streets HOT 4 CLOSED

Road trimming and intersection shapes should be calculated by looking just at vehicle lanes.

Nitpick: More specifically, it should ignore non-vehicle lanes on the outer sides of the road. Sometimes a cycle lane is in the middle of the regular paved road (like when a turn lane is the outermost lane, and the cycle lane isn't). I feel I've also seen some kind of exotic footpath in the middle of a road before, or at the very least, when we zip parallel roads together, boulevards with center paths on grass medians, we might see this.

Does the idea of defining "road width" and "center" relative to the curbs, not the edge of the footpaths sound ok?

I'm warming up to it after understanding your point in #130. It feels like it adds complexity to the data model and API. It would make lane_specs_ltr less easy to understand geometrically, since some of the outer lanes would be special-cased. I guess nothing stops us from writing curb_to_curb_width(), right_of_way_width(), get_left_curb() -> PolyLine, etc. It would also make non-driveable roads more confusing, because some of these definitions wouldn't make any sense. But that needs to happen already for some cases.

I guess I don't yet see what the advantages to this shift in thinking buy us yet. The intersection geometry routine could also be the one place that handles this special case of only matching up the outermost vehicle lanes for calculating trim.

This matches up with the OSM definition (as best as I can tell; we'd have to do a survey to confirm that mappers place the way at the center of the road width instead of the dividing line, when those don't coincide).

I believe what untrimmed_road_geometry is doing with sidewalks is trying to account for this, based on some examples I checked in OSM (and didn't comment...). We can pick the simplest representation to work with internally, and map whatever's in OSM to that. So, maybe this could make sense

from osm2streets.

Thanks for your input.

The intersection geometry routine could also be the one place that handles this special case of only matching up the outermost vehicle lanes for calculating trim.

I am definitely convinced now that we should implement helpers to work with the curb-to-curb "roadway" while leaving the actual representation alone. It sounds like you've understood the general thrust of the idea, and incorporating it into the geometry calculation code in isolation sounds like the best way to explore further.

I'm right in the guts of implementing the shifting logic for the placement which is one place curb-to-curb is relevant. The incoming placement PR will let us explore this in context. Here is an introduction to that particular can of worms:

Keeping the untrimmed, unshifted geometry as the source of truth, and reapplying the placement gets more difficult when we have zipped together multiple roads. Maybe we can use the concept of "curb-to-curb roadway" in the early stages of the process (for placement shifting and trim calculations), then switch to treating the trimmed geometry as the source of truth before we do certain transformation like zipping. The zipping transformation would then need to update the trimmed geometry properly, instead of updating the untrimmed geometry.

Maybe we go for a Corridor type that represents a list of adjacent Roads so that we can keep the scope of a single Road smaller (similar to Junction vs Intersection). If we're trying to represent a big boulevards as a single Road then it feels like we need to treat the median area as a special case. But if the median is wide enough, with winding paths, benches etc, it feels like working with two Roads and letting the median be a normal "non-road" area might be easier. Depends how median handling turns out I suppose. I'm worried about being forced to merge Intersections that shouldn't be merged, that sort of thing...

from osm2streets.

Right, the question of Corridor and Junction goes back to earlier questions about whether we should try to merge the raw/primitive Roads and Intersections together, or add additional structure and abstraction on top. This also feels relevant in the dog-leg PR conversation. I'm still not sure the right approach, and it almost feels early to figure it out... the cycleway snapping transformation barely works.

It sounds like your work with placement will reveal more info about the pain of working with current assumptions. Maybe it'd also be worth trying to group/label corridors and junctions without any attempt to merge or transform them yet. That'll give us more understanding about what raw data the lowest layer should store and about any difficulties maintaining it during more complex operations.

from osm2streets.

It feels like IntersectionKind::Intersection needs to be represented by an atom of nodes, so merging feels useful, but maybe it is easier to split into RoadNode with Intersection referencing a subgraph of Roads and RoadNodes, so merging becomes a set union on references, not a process of merging underlying data.

from osm2streets.