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

[Jacob]

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/fea86c00/attachment.htm>