Try switching to Muv

[dabreegster]

https://gitlab.com/LeLuxNet/Muv/ is a new library that's doing the "osm2lanes" job of transforming OSM tags to lane data much better than the code currently used here or in the older https://github.com/a-b-street/osm2lanes experiment. We should try cutting over to it.

It could likely help with a number of bugs: #231, #230, #229, #223, #222, #91, #89.

It's a bigger project to try this cutover, but still somewhat self-contained. If anyone's interested in trying, please do!

[tordans]

@dabreegster do know of a place to learn more about Muv that that link? It does not give a lot of context or details :).

[dabreegster]

@ginnyTheCat is the author

[ginnyTheCat]

Hi,
I built a small example integrating muv-osm into osm2streets here with a live example being deployed on https://muv.lelux.net/osm2streets which helps a lot in checking how streets parsed compare to the osm2lanes variant. Another way to check the muv-osm output on a more technical level is running cargo r --example lanes -F lanes in the muv-osm directory, inputting the tags and getting a lane-by-lane output.

Looking at the issues above #230, #222 and #89 work in muv already. Both way directions as in #91 are supported on the muv side, but have no mapping to osm2streets yet.

I'm working on documenting muv more but at the example or the muv-osm to osm2lanes source code should help a bit. If there are any more questions I'm more than happy to answer them here or wherever you prefer.

[robhubi]

An excellent site for test cases: https://wiki.openstreetmap.org/wiki/Berlin/Verkehrswende/Radwege#Radfahrstreifen_in_Mittellage_.2F_Fahrradschleuse_.2F_Fahrradweichen

[ginnyTheCat]

Thanks a lot @robhubi.

When testing the examples I realized that due to the roads having both the bicycle:lanes and cycleway=lane (a fallback for data consumers not understanding the :lanes suffix) tags, the road would end up with two bike lanes instead of one. This behavior is now fixed, and the two examples with OSM links can be viewed in osm2streets (you might need to reload without cache for the new version to be loaded).

https://muv.lelux.net/osm2streets/#19.2/52.4776157/13.4265795
https://muv.lelux.net/osm2streets/#18.93/52.4685018/13.4418944

[dabreegster]

Hi @ginnyTheCat, one logistic question/request before we try integration: could you please set a license on the project?

[ginnyTheCat]

Of course. I was thinking of using the MPL 2.0 license, which would allow osm2streets and A/B Street to fully use it. If that's ok on your side I would go ahead with that.

[dabreegster]

Yep, anything compatible with Apache 2 is fine by me!

…

On Sun, Jan 28, 2024, 1:19 PM ginnyTheCat ***@***.***> wrote: Of course. I was thinking of using the MPL 2.0 license <https://www.mozilla.org/en-US/MPL/2.0/FAQ>, which would allow osm2streets and A/B Street to fully use it. If that's ok on your side I would go ahead with that. — Reply to this email directly, view it on GitHub <#232 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAMWLF6R4LGF2I2VYOPGN4LYQZF6VAVCNFSM6AAAAABCB5YZE6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMJTGU4TIMJQGU> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[robhubi]

When testing the examples I realized that due to the roads having both the bicycle:lanes and cycleway=lane (a fallback for data consumers not understanding the :lanes suffix) tags, the road would end up with two bike lanes instead of one.

I see the tags bicycle:lanes as a description of the access rights and cycleway=lane as a description of the structural design of the carriageway. The tags complement each other.

The examples look great.

[ginnyTheCat]

One recent addition to muv that could be interesting to osm2streets is the on road curb position. In case of a highway with cycleway=lane, sidewalk=yes, the kerb would be between the cycleway and the sidewalk. Change the cycleway into a cycleway=track and the curb now is between the cycleway and the roadway.

This information could be useful to align roads to barrier=kerb lines, as many ways without placement data are often misaligned to the center of the roadway, resulting in osm2streets overlapping the roadway with separately mapped sidewalks and cycleways next to the road. Aligning the kerbs would double up as a width estimate for roads with no width tagged.

[dabreegster]

That sounds fantastic; those overlap problems happen frequently. If you find any particular examples where this new approach would help, we should add them to the test cases in Street Explorer.

I'd like to pick this up, but with work right now, there's no way it's happening in the next few weeks. :\

[ginnyTheCat]

One example could be this road (https://a-b-street.github.io/osm2streets/#18.9/50.9283434/11.5841848 / https://muv.lelux.net/osm2streets/#19.2/50.928293/11.5843508) where a kerb is mapped but the road isn't fully centered and collides with the sidewalk, even enlarging the intersection.

[ginnyTheCat]

#231 is now supported on the muv side with priority implying lanes=1

https://muv.lelux.net/osm2streets/#18.97/48.60629/7.75187

[ginnyTheCat]

I'm planning on creating a clean implementation of osm2lanes using muv that would replace the messy demo. One thing i was wondering about however was the handling of curbs in half-on-sidewalk parking situations.
Muv represents those as normal lanes just with a kerb running in the middle of it.
The ways to translate this to the osm2lanes side I see are the following:

1. Don't convert curb data, as osm2lanes currently doesn't generate it as well
2. Split the parking lane in two lanes (each with a width of (width - kerb_width) / 2), with a kerb in the middle of the two. The problem with this is that while it looks closest to reality (which is why the demo does this), it would probably mess up the simulation.
3. Move the kerb left or right of parking lane. It would look like a regular sidewalk or street parking lane but at least the curb data would be mostly kept.

In my opinion, option 3. makes the most sense.

[robhubi]

In general, the higher-ranking mode of transport is favoured. This would be option 3 with a parking lane and a kerb at the very edge.

[ginnyTheCat]

In general, the higher-ranking mode of transport is favoured.

I don't really understand this part of the sentence, maybe you could explain that a bit more. The second part is makes sense.

[robhubi]

Imagine a road. No sidewalk. Pedestrians, cyclists and cars are on the road. What type of road is it: footpath, cycle path or street? In the case of shared use, the higher-ranking means of transport determines the type.

[ginnyTheCat]

Ah, yea ofc. That's how it's implemented in the demo right now and how I'm porting it to the final variant as well. osm2lanes's LaneType has a SharedUse type for shared bike/pedestrian ways. Maybe I'm gonna map that very specific type of shared use to that type but ofc with all ofter modes using the highest-ranking strategy.
I just got confused as I thought you were referring to the half-on-sidewalk parking mentioned above.

[dabreegster]

the handling of curbs in half-on-sidewalk parking situations

I'm still confused what this means -- any real-world examples? Is this a sidewalk where cars are allowed to park on half of it, and there's a curb marking the boundary? I'm not sure I've seen these before, so just trying to understand

[ginnyTheCat]

The cars basically have two wheels on the sidewalk and two wheels on the road surface.

Here on the left the cars are parking on the sidewalk, while on the right they are parking half on the sidewalk, half on the street.

This the sign used in Germany for such situations for example.

They're not super common which is why handling them just as fancy versions of on-sidewalk parking when converting them to osm2lanes makes sense.