[Imports] Proposed Import - Cache Valley, UT Address Points

[Greg Troxel]

Mike Thompson <miketho16 at gmail.com> writes:

> On Thu, Oct 6, 2022 at 2:07 PM <jacob at cyptem.com> wrote:
>
>> Oh, that makes sense - thanks for the explanation. So the idea is to never
>> let known issues into the main dataset in the first place.
>>
> Opinions may differ in a project as big as OSM, but that is my
> understanding of the consensus.

Yes, it's my understanding of consensus too, in addition to my opinion.

Note that there are two sets of standards for OSM.  One is for how a
person doing mapping is judged, when they are mapping at human speed in
an editor.  We tend to have notions of the right way, but be pretty
lenient about things going wrong and getting fixed later, because new
people get things wrong, but we need new people to have more people and
that's how later experienced people start.

The other set of standards is for importsa and mechanical edits,
basically anything at scale.  There, we basically insist that everything
is done fully meets standards of "done right".  Yes, it means it is
harder to do an import, and takes more time to write code, but if that's
what it takes to do it right, that's how it is.  We don't have any
notion that it's better to let deficient imports happen because it makes
it easier for people to do them.

Generally I think people agree that if an import is slowed down or even
doesn't happen because it's too hard to do it right, that's ok.

>> And thanks to all for your patience, understanding, and expertise!
>>
> Thanks for listening to community input!

Agreed - that's what this list is for and it's great to see it working,
which it doesn't always seem to.
-------------- 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/20221007/833fb1e3/attachment-0001.sig>