[josm-dev] Similarly named ways

Jo winfixit at gmail.com
Tue Jan 6 12:08:20 UTC 2015


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 <naoliv at gmail.com>:

> On Tue, Jan 6, 2015 at 5:11 AM, Jo <winfixit at 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.
>


More information about the josm-dev mailing list