Well, one rule could be to also take boundaries into the equation. Not the easiest thing to do, but not impossible either.
In the case of Bruggesteenweg/Brugsesteenweg it's the 2 municipalities who made a different decision on composing Noun-noun versus Adjective-noun (more common in Dutch). So it's OK if this happens on the border. For Ooststraat/Weststraat (Oost/West) can be added to the 'synonyms' list in the source code or the user's preferences, once the source code uses those. Liersebaan / Vierselbaan should be different enough by themselves. A tag in the data shows that a contributor actually actively checked this (or at least that should be the case). I don't see it as pollution, but I'm apparently in the minority camp with many of my views, so I'm used to not being 'right'. :-) I still think the validator should heed the noname tag though (for objects/ways which really don't have a name), but that's another discussion. Unfortunately the ignore button doesn't work on my side. Even during the same session I get the same message about the same object again. And I don't want to switch the validator off entirely. That's what I did in the past, but that's not very productive and it shifts the work to other contributors, when I can do it just as well, creating only one version of the object in its history, as I'm already working on it anyway. Jo 2015-01-06 11:42 GMT+01:00 Nelson A. de Oliveira <nao...@gmail.com>: > On Tue, Jan 6, 2015 at 5:11 AM, Jo <winfi...@gmail.com> wrote: > > Lease don't get me wrong. The validator allowed me to fix an actual > problem > > in the data. Once it's solved though it would be nice to have a way to > > indicate it's reporting a false positive. This would only be needed on > nodes > > which connect 2 similarly named ways. There aren't 1000s of those. So > it's > > hardly polluting the data, but it would save human editors time. And > that is > > more important ultimately, than a few bytes of data to help QC. > > A validation rule is basically a test to classify something. > Unless somebody creates something very magical (and gets rich with > it), there will always be false positives (an object that is > triggering an invalid warning) and false negatives (an incorrect > object that isn't being catch by the validation). > > It's a trade-off between catching valid errors and false/unwanted warnings. > > Instead discussing ways to workaround this (and adding complexity to > the data), it's more advantageous to discuss better rules, tests or > algorithms. > _______________________________________________ josm-dev mailing list josm-dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/josm-dev
