Le 03.07.19 à 17:36, Paul Allen a écrit :
> On Wed, 3 Jul 2019 at 16:16, marc marc wrote:
>     Le 03.07.19 à 16:55, Paul Allen a écrit :
>>> What "unsigned" doesn't do is identify how the mapper came 
>>> to any conclusion about the weight
>>> limit or how other mappers may verify it.
>>     unsigned just said "no info on the ground"
> The same can be achieved by omitting the tag.   

without a tag, you can't tell if somebody have already check
for a sign or if you need to survey it.
you cannot tell the difference between a lanes=2 road with road markings 
and a lanes=2 road without road markings (see previous thread)

> A fixme is better because quality tools can help mappers  
> see where more information is needed.

No sign on the ground is not an error in osm, it's a fact !
My neighbour did not put the regulatory sign on his new house,
unsigned=addr:housenumber changeset source=survey (so no more need
for other contributors to do a survey the next day)
another day, somebody may add addr:housenumber=<his number> changeset 
source=local knowledge or opendata
what do you want a contributor to correct in osm ?
fixme is fully wrong when nothing need to be fixe in osm

the same for a road without lanes marking
the same for a bridge without maxheight sign
none of them is an "stuff to fix in osm"

> an object can end up with maxweight=3.5 + unsigned=maxweight

Yes, it can happen.

> without telling anyone how or why the mapper decided 
> that the maxweight is, in fact, 3.5.

check the source of the changeset that add maxweight=3.5
unsigned=* doesn't try to replace the source tag

> you cannot deduce what the absent sign is about.

I think you read my message a little too quickly.
unsigned=maxspeed is about maxspeed
unsigned=maxheight is about maxheight.
unsigned=<the name of the key> is about this key

I just propose to replace a variety of inconsistent tags
by a structured schema for all, for exemple :

maxheight:sign=no (and maybe maxheight=default)-> unsigned=maxheight
lanes:marking=no and lanes:unmarked=yes-lanes=unmarked > unsigned=lanes
nosign=yes (but nobody known for witch sign) -> unsigned=<the key for 
the expected info>
marking=unmarked (but nobody known for witch sign) -> unsigned=<the 
expected info>
fixme/note/description=no <key> sign -> unsigned=key
info=unmarked -> unsigned=<the key for the expected info>

>>     Similarly, when I  do a survey and I notice that a house 
>>     does not have the USUAL sign indicating  
>>     its house number, I can said that the sign is not there.
> Which would be a little annoying around here, because maybe a tenth of 
> the houses do not have numbers, only names.
> Most of those name-only houses have never had numbers. 
> You think it sensible to tag unsigned=addr:housenumber for those?

I was saying "does not have the USUAL sign"
if it's common that houses don't have a addr:housenumber,
it's not very useful to put unsigned=addr:housenumber.
as it's not very useful to put it on a tree or a field.
an app/a contributor can use common sense to be satisfied
with addr:housenumber or addr:housename

I'm not proposing to decide WHEN a contributor should or should
not add the information of a missing sign.
I just propose a unified tag when it DOES add it.

> I don't think it actually solves any issues that are not better handled 
> with a fixme or a source tag, or simply omitting the tag.

do you propose that app like streetcomplete or that contributors who 
have added one of the many tags I listed above add a fixme "nosign, 
maybe something to fix, maybe not" just "in case of" ?
it's noise these fixme that indicates a fact and not a problem to solve.
or do you suggest that the contributors who add these tags don't add 
anything to make it uniform ? It seems to me a solution that has no 
chance of being accepted, check taginfo, some mapper add it.
so the question is: a different tag for each missing sign
or a tag for all ?

Regards,
Marc
_______________________________________________
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Reply via email to