[Tagging] default value for "oneway"

[Peter Wendorff]

Am 28.08.2014 um 19:10 schrieb Xavier Noria:
> On Thu, Aug 28, 2014 at 6:52 PM, John Packer <john.packer7 at gmail.com> wrote:
> 
>>> For a street, there is no practical difference nowadays between "no"
>>> and "unset", which is a smell for me. Either way means no.
>>
>> For the software? No, there isn't a difference.
>> For the mapper?  Yes, there is a difference.
> 
> The mapper can't tell unset from no either today.
> 
> If unset mean unset (as in the hypothetical proposal I am outlining),
> then it would mean something: I am gonna volunteer this value, this
> value is unknown, etc. Problem is people at large are using unset to
> mean no. So nowadays you can't tell.
> 
>>> Since nowadays NULL for a street means oneway=no a change in the
>>> semantics would be still be possible as far as the database is
>>> concerned. If you go today to the database and update all oneway
>>> attributes for streets which are blank to "no", the meaning of the
>>>
>>> database is equivalent.
No, it isn't.
The interpretation of the database, and the meaning, restricted to the
fact of the streets oneway-ness is the same, but no value at all does
not say "this is no oneway street", it says nothing more than "we don't
know if it's oneway or not".
If somewhere oneway=no is tagged, it says (or should say): "Someone
verified this street to be oneway."

For software there's a problem for any unknown value, so some assumption
has to be made. Assuming oneway=no is the best effort assumption as it
causes least harm (allows the right direction correctly, allows the
wrong correction incorrectly for untagged oneways; and works for
untagged non-oneways).
Adding oneway=no to any highway that is untagged currently removes the
information of the highway being verified, and adds no value with the
given assumption. Adding oneway=no by hand on a case by case basis where
you know a highway is not a oneway may be a solution; but I don't think
many people would do that.

Your UI proposals for a default value "no" to be actively unchecked by
the user is dangerous as often people keep the defaults without
knowledge or thinking about it, so better keep "unknown/unset" as the
default - just as we have it right now.

>>
>> Theorically speaking, yes, you could add oneway=no to every street, and get
>> a functionally equivalent database (from the software's POV).
>> But, in practice, people most likely wouldn't agree with that (this change
>> would be reverted).
> 
> Wouldn't agree with the equivalence of the database, or with the patch
> itself issuing a SQL statement?
> 
> Such a patch wouldn't make any sense unless it was part of a bigger
> plan. I explained that only as a way to say as far as the database is
> concerned the data is equivalent.
-1, as explained above.

regards
Peter