[Imports] United States Poultry Import

[Greg Troxel]

Martin Koppenhoefer <dieterdreist at gmail.com> writes:

> this is an open question, we can't say for sure what would have happened
> "if", but the slow growth of the US community in the early years was
> attributed by some people to the debt created with the TIGER roads import,
> which basically left such a mess that it (eventually) made many people stay
> away. Generally, an active community of people is much more important than
> the data, because if nobody maintains the data it becomes stale and
> therefore unreliable and consequently useless. On the other hand, with a
> sufficient number of people on the ground we can recreate any data in short
> time. People tend to feel more responsible for data they have entered
> themselves, with respect to data they have taken from someone else. They
> feel that they "own" the data and feel compelled to care for it.

A lot of people think that, but my early enthusiasm for OSM was
*increased* by imported data, because it made the map locally useful.  I
don't think the "TIGER is what is wrong with the US community" is valid,
and I don't think there's any evidence for it.

I feel responsible for data that is in my community.  I don't think I
feel particularly responsible about data I entered vs others.  Often I
have no idea who entered it until I look at history in JOSM -- which I
do only because I feel far more free to make changes to tagging when I
set the original tags, vs asking someone if I think it's iffy.

I agree however that an active community is very important.

> It is also generally much better to have fewer and reliable data (i.e.
> things missing) than wrong data, because wrong data is much harder to
> detect than missing data. Missing data is often apparent, you see that the
> data is not complete, and can draw your clues (and can at least rely on
> what _is_ there), while you will not see if the data is simply wrong, you
> will probably run into problems with wrong data, and if it is too much of
> it, you will likely turn away. On the other hand, for many applications
> incomplete data is still useful.

I agree that wrong data is bad, especially now that the map has a lot of
things on it.

For any import, I would ask the question: Of all the things to be added,
if a local mapper looked at each one (a different local mapper), what
fraction of them would that local mapper say "this is ok and I don't
need to change it" vs "this is wrong and needs fixing".  I don't mean
"could I add even more micromapping" -- I really mean is it correct.

And secondarily, would the local mapper say: If I fix up a few things
that aren't quite right, am I happy  with the overal change of import
and fixing as 1) an improvement to the map and 2) a reasonable
expenditure of fixing time relative to improvement.

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.

As an example MassDOT street data was imported in massachusetts.  In my
town, I've found one street that was in the database but has never
existed, and one street that was misnamed.  And a few where there are
slightly different forms of name and I as a local still am not sure
which is right.  Everything else was basically right in terms of
geometry and names.  So I consider that a huge win, and I was happy to
fix the minor issues.  Same with the buildings import.  Out of probably
3000 buildings a few seemed to be phantom and I've deleted them.

I haven't seen an assessment of how that % is for this import.  That's
easy to do; pick a subset and hand-verify.  Make sure not to pick a
subset fo good data if the dataset has a hetergeneous
creation/maintenance process.

And if you can't hand verify a subset, with help from others, that's a
clue that the import doesn't have local support and shouldn't happen.
That's separate from it being bad to do an import that isn't known to
have high accuracy.

-------------- 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/35096260/attachment.sig>