[Imports] United States Poultry Import

[Greg Troxel]

Martin Koppenhoefer <dieterdreist at gmail.com> writes:

> Am Fr., 22. Apr. 2022 um 14:13 Uhr schrieb Greg Troxel <gdt at lexort.com>:
>
>> When that answer is around 98% right, imports seem ok.  Even 90% right
>> is way too low.  This means the database has to be recent relative to
>> the rate of change.
>
> it really depends on the kind of problems. For example, typos in road names
> are not nice, but much less important than for example roads or paths that
> do not exist. If from 100 roads 2 would not exist (98% correct), it would
> not be wise to add the data with the errors, but if from 100 streets 2 have
> small typos in their names, it would be acceptable (IMHO).

Agreed that 98% is probably not always right, and for data that causes
more trouble, a higher % is needed.   In my road case, there was one
phantom road, and because of where it was relative to others, it would
never have caused anyone problems, just mild amusement.  That's out of
probably hundreds.

> For hiking, you
> would probably be much happier with a few paths that are sure to exist
> (like 10% of all existing paths in the area), compared to a map with too
> many paths, where you might rely on a connection that is nonexistent and
> you discover 1 hour before sunset that you will have to backup and will
> arrive 3 hours later than you thought ;-)

I basically agree that bad data is not a good thing.  Again this is one
of these particularly important things.

> I generally agree with what you wrote, but would like to add to it, because
> IMHO these experiences are not comparable to the import we are discussing
> here.

I agree that they aren't comparable -- that's the point I was trying to make.

> importing "in your town", with the motivation to check and fix problems, is
> very different from performing a nationwide import, where you are sure that
> you cannot verify most of it on the ground. You may be able to do local
> checks, or remote checks via websearch and similar, but even if your local
> checks seem to indicate the data is ok, it may well be that it is much
> worse in a different state and that there are systematic problems related
> to how the dataset was compiled (there may be different sources in
> nationwide datasets)

Yes, I tried to point out that a database with multiple input types is
cannot reliably be checked in one region.

In the cases I talked about, the imports were a US state (7 million
people).  But, there was a statewide group for buildings, and the
datasets were generated using the same process for the whole state.


So in the present case, I'd like to see the results of the QA process
that shows the data is overwhelmingly correct.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://lists.openstreetmap.org/pipermail/imports/attachments/20220422/7a917fc3/attachment.sig>