On Thu, Aug 28, 2014 at 6:52 PM, John Packer <john.pack...@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. > > 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. But for example, every single client software of OSM that is out of control of OSM is assuming that contract. That's what I believe makes a reset (no NULLs in the database) plus semantic change for NULLs would not be possible. No way to synchronize all that client code unless that was somehow coordinated as in a major upgrade. _______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
