kfarr
commented
2 years ago Thanks Dustin, this concept sounds good in general and osm2lanes looks great!
Here are a few ideas for how this could work on the 3dstreet side:
There is an existing component called streetmix-loader which takes a streetmix URL and then retrieves the streetmix API response and finds just the "segments" part of the JSON response and feeds just that json into the street component.
Similarly we could create a component such as osm-way-loader which could take a way ID (if there is such a thing) and then use overpass > osm2lanes > json output which is fed into street component.
A separate UI exercise is then helping the user find a way ID using the slippy map method.
It would be least effort for 3dstreet team for v1 of osm2lanes to fit exactly the existing streetmix json format including its use of imperial units. (FYI the street component has "type" parameter of default value of "streetmixSegmentsFeet". It is useless, it doesn't actually do anything at the moment, but it's meant to call attention to dependency on Streetmix json format and imperial units.) In the future we could use different values for this parameter to trigger alternate parsing logic to experiment with different schema.
To state the obvious v1 would also only support a straight line, a way with 2 nodes, but could be a great forcing function to support ways with >2 nodes.
droogmic
dabreegster
@kfarr and I chatted a bit about this. Here's an end-user workflow:
1) Someone wants to visualize the current lane configuration of any street in the world 2) Through the 3dst UI, they select some import tool 3) They use a slippy web map to find and select a single road 4) In a few seconds, they see that street loaded in 3dst
Here's an idea how this could work:
1) Leaflet, MapboxGL, or similar could be used to let users pick a road. They should all have some kind of on-click handler for single points 2) We can query all OpenStreetMap ways within a small buffer around that point using the Overpass API and extract just the string key/values of a single way 3) Plug that into osm2lanes (which can be called through Javascript), which will return this JSON lane specification 4) Transform osm2lanes JSON into 3dst's format
One prerequisite: publish an npm package of osm2lanes. (Which forces us to start thinking about versioning at least a little bit -- we can create a 0.1, make a bunch of breaking changes, and sync again after the dust settles to update any code in 3dstreet)
Possible complication: the osm2lanes and 3dstreet / streetmix lane spec are different in ways that're hard to reconcile. I don't expect that's the case, but if we discover any gaps, better to learn that early!
Other slight challenge: osm2lanes needs a bit of extra context, like are we in a right-handed or left-handed driving area. That's less straightforward to get from OpenStreetMap, but there's a mapping from country codes to this kind of config somewhere in the Streetcomplete codebase -- I can dig up a link if needed. And getting the country code from a lat/lon should be a solveable problem.
Future idea: import into streetmix
Originally I wanted to wire up something like this into Streetmix, so people could start editing based on current OSM lane config. But Streetmix doesn't support a way of creating a new document and passing in the Streetmix-format JSON segments. I dunno the plans for 3D Street editing, but it should be able to tie in somehow.
Future idea: import road and intersection geometry too
I'll also soon be splitting out A/B Street's road and intersection geometry into a standalone library, which'll also be callable through Javascript. You'd pass in line-strings and widths for a bunch of road segments, and it would generate a 2D road polygon and intersection polygon based on that. The intersection geometry is often imperfect, but pretty decent.
The idea here would be to instead let people select an entire area on the slippy map, and import all of that into 3D Street. Extract the road points from Overpass too. And to get widths of each road,
osm2laneswill soon also include an estimate of lane widths, which we can add up.CC @droogmic for all of this, who's driving osm2lanes development currently