[OSM-talk] Downsides of storing QA data in OSM data, Way ids! | Re: iD invents nosquare=yes for buildings which should not be squared

[Rory McCann]

There certainly is benefit to piggybacking QA data on the OSM databases,
but there are downsides. Moving a node will not change the way's version
id. This change can make the building square/notsqure/overlap/whatever.
The way needs to be rechecked by the QA tool. But it can't know know
that from the way version.

On 10.05.19 22:17, Yuri Astrakhan wrote:
> On Fri, May 10, 2019 at 3:39 PM Yves <yvecai at mailbox.org 
> <mailto:yvecai at mailbox.org>> wrote:
> 
>     Some validation tools, like Osmose, make great efforts to maintain a
>     'false positive' database.
> 
> 
> If the same validation is done by multiple tools, they need to share the 
> "false positive" data, otherwise only one tool would know not to change 
> something, while another tool will encourage the user to make the same 
> mistake.
> 
> So we either have to set up an OSM shadow database that contains all 
> exceptions, e.g. "object NNNN is exempt from validation XXXX", or this 
> data should be stored in the object itself, which seems to be a far more 
> robust approach (same data store allows data consistency / versioning / 
> user management / tracking / consistency between tools / same processing 
> pipeline / ...).
> 
> If the objection to this is that users don't want to see junk data, I 
> agree -- but we could simply dedicate a key namespace to validations, 
> and hide it by default in JOSM and iD.
> 
> _______________________________________________
> talk mailing list
> talk at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>