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

[Greg Troxel]

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