Parking should lower speed used on shortcut algorithm

[dabreegster]

No description provided.

[dabreegster]

An idea from AIUK written down too quickly. Narrow two-way streets with parking are slow to drive through in both directions at once. If we can detect this situation in OSM, we should lower the effective speed used by the routing algorithms.

[XioNoX]

I was wondering if it would be possible to add an option to ignore parking_aisle, a bit like what I think happen for roads with access=private ?

[dabreegster]

Ah yes, those are currently pulled in and act like they allow through-traffic, right? Is there an example area that shows this doesn't make sense? Sometimes service roads might wind up being used as shortcuts, but probably not parking aisles.

[XioNoX]

Two examples here https://www.openstreetmap.org/way/152023124 and https://www.openstreetmap.org/way/51205420
I think it makes sens to not ignore them by default as they can be used as shortcuts in some ways. But won't most of the times. In that case showing them as potential shortcuts adds noise to the map. For now I just add a modal filter to "make it cleaner".

[dabreegster]

Just listing ideas, not sure what to do yet.

• Lower the speed of parking aisles and two-way streets with parking on both sides (the original idea of this issue), both with the idea that they should naturally have less shortcuts going through them. That actually requires first putting a concept of speed in this version -- in my haste originally porting, it's still just routing by distance only
• Add a new modal filter type to ignore a road for shortcuts. Users could apply it to things like parking aisles or small service roads that they know in practice are not practical for through-traffic. It could either act the same as any other filter and not allow anything that way, or just be used for this shortcuts heatmap visualization. A possible problem with the first option is that it might create some disconnected cells and cause warnings that're just noise.
• Add a setting to do the above automatically for all parking aisles. It'd be important to style the parking aisles a special way or at least indicate what they are when hovering, to make it more clear why nothing is going that way.

[TFCx]

All your ideas have merit :) :

• the whole concept of speed limits / duration of routing seems crutial to me. In LTN v1 the concept was present but couldn't be edited. A classic example of this configuration are "U routes" that enter/exit a district (especially if they are "back loops" in respect to the main borner street direction): those will never be used for ratruns. Even "U routes" in the same direction are usually useless). In LTN v1 I would sometimes wanted to dismiss some detected ratruns because I knew it would not gain time to the drivers)
• the new modal filter = it seems to be the creation of a "policy-based LTN" like in Paris. A few days after the first LTN was created, Gmaps / Apple maps were updated to avoid the district if both the starting point and destination were outside the LTN. Of course, LTN v2 is there to provide more "structurally sound" traffic limitations. Anyway, a tool to delimit "policy based" LTN (where we admit that drivers would respect them or be fined) seems useful. It could be used to delimit semi-private routes like parkways.

[XioNoX]

On your first point I opened #69