@BudgieInWA and I started discussing this. I think we do want to keep each component library small and focused, to encourage more people to jump into the codebase without being overwhelmed. osm2lanes probably will have nothing to do with geometry.

The next layer I want to split out (ETA on starting is the next few weeks) is osm2polygons (name pending), which will take in line-strings representing the road center and a total width (from osm2lanes), and output the road and intersection polygons. The name is pending, because this would not actually have anything directly to do with OSM -- somebody could make their own tool for drawing thick road lines, and plug this in to calculate intersection polygons. It's another small, very focused library that could get its own unit tests and be developed more easily than it has in the past.

... But I'm less and less sure that's the correct interface to try next. It doesn't leave a natural way of handling:

1. Placement tags, where the input line-string roads need to be adjusted first. Maybe this second library is aware of the OSM tags on each road?
2. Rendering markings on the road and intersection. Maybe a third library can handle that given the road or intersection polygon, osm2lanes output, and other OSM tags. Or maybe in the middle of producing intersection geometry is when we also need to emit markings.
3. Separate cycleways / footways close to the main road. In many cases these will physically overlap the main road based on current inferred widths.

Another idea I'm toying with is splitting out the layer of code that treats OSM as a graph structure (https://github.com/a-b-street/abstreet/tree/osm2lanes/raw_map/src). That's the place where it might be easiest to detect common patterns like a dual carriageway joining/forking, "dog-leg" intersections (4-way intersections with some of the directions slightly offset), and parallel ways. Maybe we start by faithfully loading this graph structure from OSM data, then apply a bunch of transformations to detect and simplify these situations, using some mix of osm2lanes and other split-out code for generating small pieces of geometry.

But Ben had some other ideas from a prior call that I haven't captured...

from osm2streets.

osm2lanes only handles tags, not geometries

Correct. The one exception I might make is for a utility function that stitches parallel ways together (e.g. things like https://www.openstreetmap.org/node/2582365497#map=19/51.94277/4.55587) into a single coherent lane spec.

ideal process to render the data on a map would be.

lanes2map

transform the lane-data into areas and paints those?

This will be the tricky part, but it will indeed need to be done by a different tool, just to avoid complicating this one. I am leaving starting this to @dabreegster.

use the lane-width to calculate lat/lng values with an offset based on the center line

Something like his was also going to be my first hacky 2d rendering solution. Turn the lanespec into some sort of brush, and then brush each way's path with it. The intersections will not be correct, but it would be a good start.

I think we can basically do this now (assuming center of lanespec is on the way's path) until we solve #6

from osm2streets.

Turn the lanespec into some sort of brush, and then brush each way's path with it.

I think this is a good way to think about it, but is only part of the solution. I have had some experience trying this out within the JOSM plugin BjornRasmussen/Lanes and can share some insight.

(Examples are left hand drive.)

First, the lane spec (with placement) treated as a brush is correct within the center of linestrings, but cannot be correct when roads split or intersect given the raw OSM way geometry. This is the "Lane and road attributes" paint style in JOSM which uses that approach (parsing OSM tags in mapcss!?!). Notice the overlapping and incorrect road width just after the road splits/joins on the east, west and north.

The Lanes plugin detects intersections, the overlapping areas, merges overlapping intersections and trims back the incoming ways and represents the area as an "intersection" to be drawn separately. These are the areas with curved white boundaries, instead of yellow, that can be seen in the main intersection, and at the split to the east. The green lines to the west and north replacement geometries that I was able to calculate over those "intersection" areas, in the simple case where the number of lanes doesn't change.

The workflow that I am imagining

• osm2lanes turns each way into a lanespec, with width and placement
• osm2streets turns the the graph of ways into a graph of unified street representation, with intersections classified and with proper reference geometry. It would use osm2lanes, and other OSM tags (the connectivity relation, highway=give_way, etc.).
• streets2geom turns streets into road area and lane marking geometry, that can be rendered directly.
• osm2map would be the complete tool, like Map Machine, that combines osm2streets streets2geom, osm2groundcover, etc. into an actual map :)

I can't see a way of breaking down osm2streets any smaller (i.e. treating the graph and the geometry separately), because classifying intersections requires looking at the geometry. The geometry also makes it easier to combine parallel ways: the main northbound and southbound carriageways get very close together when we look at the geometry, so it would be reasonable to merge them so that they use the same reference geometry.

But, the geometry that osm2streets would have to deal with is much more limited than streets2geom: it only needs the most conservative intersection areas (about what A/B Street currently calculates), and discontinuities in road width would be fine if the situation was described (like "lane added on the right").

streets2geom would take the streetspecs and follow well defined (locale specific) steps to construct the final geometry for rendering - with all of the fancy curves and whatnot. This process would be involved, but with the correct streetspec representation and reference geometry, should be completely "straight forward" and is probably described in excruciating detail in road standards documents like the MUTCD .

The diagram below shows the required reference geometry in red. Looking at the top example, osm2streets would product 2 street parts with those reference geometries (calculated like the green lines in the previous example), and a description of the changing conditions over the length of those geometries. Those two red lines with the details: "one lane on the top, left of line", "two lanes on the bottom, left of line, lane changing allowed", "stop line at A, with traffic storage (no lane changing) to A'", "road splits at B with overlap to B'" is the only info needed to construct all of the markings in blue.

The bottom example is the same idea with more details, and I have examples for intersections and all sorts of things, but that is getting way off topic for this discussion.

from osm2streets.

One thing that osm2lanes could do, to help with the combining of adjacent ways, is to implement the logic for combining adjacent lanespecs together, if the called has decided how the ways relate to each other. Something like ways_to_lanes(way_tags: &[Tags], way_seperation_widths: &[f64]). It would make assumptions about separators and their widths based on the distance between the ways.

As a demo, we could allow the user to draw a line across a street, detect intersections with all the highways that it crosses, calculate the distance between those intersections, and generate the lanespec for the full street! (Those yellow lines are hedges, so they could be part of the API too.)

from osm2streets.

@BudgieInWA, here's a brief guide to play with the RawMap editor. I'm looking into simplifying the code there and will file another issue with ideas...

Howto

1. Go through the "getting started" at https://a-b-street.github.io/docs//tech/dev/index.html
2. Build an existing map from scratch: ./import.sh --raw --city=us/phoenix
3. Then run the editor on it: cd apps/map_editor; cargo run --release -- ../../data/input/us/phoenix/maps/gilbert.bin

Or you can tradeoff importing yourself to download prebuilt files: https://a-b-street.github.io/docs//tech/dev/index.html#downloading-more-cities -- it'd be us/phoenix under input in this example

Or you can add a new place, https://a-b-street.github.io/docs/user/new_city.html. You'll wind up with data/input/zz/oneshot/raw_maps/imported_0.bin or similar.

Let me know if you have any trouble running stuff, or have any questions about the code.

from osm2streets.

This whole new repo is our attempt to answer this question, thanks for asking :) I'm looking forward to hearing more from everyone on the many questions that this raises!

from osm2streets.