-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Discuss adding geometries to osm2lanes #5
Comments
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.
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.
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 |
@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. 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 ... But I'm less and less sure that's the correct interface to try next. It doesn't leave a natural way of handling:
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 But Ben had some other ideas from a prior call that I haven't captured... |
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 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
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 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. |
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 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.) |
@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
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 Or you can add a new place, https://a-b-street.github.io/docs/user/new_city.html. You'll wind up with Let me know if you have any trouble running stuff, or have any questions about the code. |
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! |
(More of a question/discussion/know how share-issue.)
The output at https://a-b-street.github.io/osm2lanes/ does not include geometries. I assume that the idea is, that osm2lanes only handles tags, not geometries?
I wonder, what the ideal process to render the data on a map would be. And if this might require a secondary shared project lanes2map.
What are your thought on how to render the data on a map.
I assume ab-street transform the lane-data into areas and paints those?
Is there a feasible way to instead use the lane-width to calculate lat/lng values with an offset based on the center line (respecting #6).
Both approaches require to handle curves properly (but I have no idea how ;-)).
The text was updated successfully, but these errors were encountered: