On 2017-05-21 13:36, Martin Koppenhoefer wrote:
> 2017-05-21 13:15 GMT+02:00 Colin Smale <colin.sm...@xs4all.nl>:
> this can depend on legislation. Usually the end of the restriction should be
> signed (or the restriction will already have indications when it will end/to
> where it applies, e.g. a sharp bend), some jurisdictions also require that it
> will be repeated at every crossing, or it will end automatically.
Which is exactly why we need a way of making this explicit, because we
are not able to discuss having documented "territorial defaults" without
the discussion getting nasty. OSM has to work for everyone. Using words
like "usually" serves to emphasise the need for a model that also caters
for the "unusual." Other countries may do things very differently to
what you are used to.
>> European traffic law is full of cases where a sign applies until the next
>> junction, but what counts as the "next junction" may not be unambiguously
>> obvious from the OSM data. And a give-way sign must be unambiguously linked
>> to the junction and road segment to which it applies.
>
>> I am convinced that geometry alone is not able to resolve this in all cases,
>> so an explicit model is also required.
>
> feel free to come up with something, just because something can not resolve
> all cases does not mean that all cases have to be made complicated. I have so
> far never encountered a situation where I would have needed a relation to say
> what I think to where a sign applies (surely these will exist, but not in
> "masses", at least not around here). Many signs are also very redundant
> (IMHO) for mapping purposes, e.g. the turn restriction signs before entering
> into a oneway street are complemented by the oneway signs and the no-entry
> signs in the opposite direction. A lot of signs (and work) for what can
> usually be mapped unambigously with a simple oneway=yes tag in OSM.
First we start with a data model, using node/way/relation/polygon
primitives together with tagging, possibly leveraging the "namespace
model" to allow some kind of grouping and hierarchy in the tags. We
ensure it is as simple as possible while remaining fit-for-purpose. If
it too verbose, we document defaults to reduce the tagging required or
we agree to drop certain capabilities. But of course this will require a
statement of purpose, otherwise you cannot judge if the proposal is a
valid solution. So, in simple language, WHY do we put traffic signs into
OSM? Let's have this frame of reference on the table. Only then can we
make value judgments about this or that proposal as to HOW.
//colin
_______________________________________________
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
