Vào lúc 01:07 2022-10-29, Tobias Knerr đã viết:
On 29.10.22 07:13 easbar.m...@posteo.net
wrote:
I like your idea of not using the except tag but rather something like
restriction:value=unrestricted. Actually that would be the first
useful combination of restriction and restriction:vehicle that I have
heard of. But unfortunately this is neither mentioned in the wiki nor
does it seem to be used that way.
Yes, this is something that would require a proposal to introduce, it's
not established practice at this point. The reason I mention it in this
discussion is indeed that it would be one example where restriction and
restriction:vehicle on the same relation could meaningfully coexist. So
I wonder if a wording could be used that would leave this door open for
the future, e.g. by discouraging "different types of restriction on the
same relation" (or some better wording to the same effect).
I'm still wondering: Do we ever need different restriction values for
different vehicles, or for different conditions, for the same relation?
No, with the exception of the "unrestricted" concept I mentioned, this
should never be necessary. Even if there is an obscure real-world
situation with different restrictions on the same turn (same
from-via-to) for different vehicles, it could be modelled with separate
relations.
For context, this question came up the other day in the iD bug tracker.
[1] It was unclear how an editor should depict a mixed-restriction
relation. If it's unclear for editors, it's certainly unclear for routers.
In a sense, this is actually a common phenomenon: trucks must exit to a
weigh station but cars may not. Or cyclists must turn right from a bike
lane to a bike path but cars may not. However, these restrictions are
already represented by access restrictions on the ways themselves -- no
need for relations. Normally, way-based restriction tagging breaks down
when the restriction depends on the direction of approach, but that
would require separate relations anyhow.
One potential issue with relying on separate relations is that there's
no way to indicate an order of precedence explicitly. For example, at
one of San Francisco's most prominent intersections, an "except Muni"
sign modifies a no left turn sign, exempting one bus operator that comes
from the west, but not AC Transit. [2] At the same intersection, "no
right turn except Muni and SamTrans" exempts both bus operators that
routinely come from the south. [3]
Most of the bus routes in this part of town follow strict paths, so I
just coined an obscure except:network=* tag and called it a day. [4] But
this experience leads me to suspect there may be places where the
real-world restrictions turn our usual access key hierarchy [5] on its
head. Unfortunately, there's nothing to say that one relation takes
precedence over another relation with the same members. (Incidentally,
this is why I've shied away from proposing that we use relations to
track overlapping parking lane restrictions.)
[1] https://github.com/openstreetmap/iD/issues/9337#issuecomment-1283492156
[2]
https://commons.wikimedia.org/wiki/File:City_of_San_Francisco_(Unsplash).jpg
[3] https://www.mapillary.com/app/?pKey=4265238293573050
[4] https://www.openstreetmap.org/relation/10650926
[5] https://wiki.openstreetmap.org/wiki/Key:access#Land-based_transportation
--
m...@nguyen.cincinnati.oh.us
_______________________________________________
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
