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

[Mateusz Konieczny]

I think that better phrasing describing situation without making it insulting may be:
"they want to do doable part of import, without parts that are horrifically hard to
do and/or impossible".

I also think that at least it should be mentioned that importing foreign keys 
from various databases is of dubious use, causes confusion and is extremely rarely
actually useful.

Especially as you cannot assume match based on this database id being tagged
(mapper could move items or duplicate them)

wikipedia and wikidata are one of few in actual and real use

Oct 9, 2022, 17:13 by imports at openstreetmap.org:

> Greg, thanks for pointing this out. I hope you know I'm doing my best to meet the standards required for an import. I don't think it's very nice to imply that I'm trying to avoid the hard work and just do the fun part. 
> For this issue specifically I think your idea of updating the documentation to match your expectations would be best. That way future importers will know what will likely be expected. (Eg no foreign keys, etc. - Existing documentation seems to say that they are OK.)
>
>
> On October 9, 2022 5:38:56 AM MDT, Greg Troxel <gdt at lexort.com> wrote:
>
>>
>> jacob at cyptem.com writes:
>>
>>
>>>  	* Handling future updates - Use UGRC:import_uuid tag to
>>> maintain a unique identifier back to the original database. Later when
>>> updating, skip rows with IDs that already exist.
>>>
>>
>> I'm really unclear on consensus about foreign keys.  My impression is
>> that:
>>
>>   1) generally people on the list think they shouldn't be used, almost to
>>   the point of rough consensus
>>
>>   2) everyone who is doing an import for the first time thinks they are
>>   going to be useful later and wants to include them, even though the
>>   first import is often "I only want to do the easy part" and none of
>>   the difficult steps are implemented.
>>
>>   3) People who understand how difficult the difficult steps are don't
>>   see any real value in foreign keys in the database.
>>
>> We have recent data for point 2 :-)
>>
>> Does anybody think I'm off base about (1) and (3)?  If not, maybe we
>> should adjust the import guidelines to say "no foreign keys".  If so,
>> maybe we should say "a single foreign key is ok".
>>
>> I don't think foreign keys are terrible, but I think they aren't that
>> useful and the combination of people not wanting to do the hard
>> matching/checking I recently outlined and wanting foreign keys is not a
>> good outcome -- we get the bloat without whatever benefit there might
>> be.
>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/imports/attachments/20221009/f039b729/attachment.htm>