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

[Greg Troxel]

Jacob <jacob at cyptem.com> writes:

> 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.

I didn't mean to say that.  I think it's perfectly ok to approach a
situation and do 20% of the work to get 90% of the benefit, as long as
everything that is done is done right.

My view is that doing an import correctly is difficult.  My experience
over the years is that people who are doing their first import tend to
underestimate how hard it is by a lot, maybe 10x.  I think it's
important not to caused other contributors later to have to do anything
remedial.  I helped someone do their first import and I think at first
they thought I was crazy for cautioning about difficulty.  By the end
they did not think I was crazy.

What I was trying to say is that without the benefit of experience of
getting all the way through an import, 2 years of living with it, and
contemplating an update import, foreign keys seem like they ought to be
broadly useful.  My impression from the list is that almost no one who
has that experience thinks so.  Certainly anyone who has found them
useful (when doing an update import, and really dealing with the hard
cases correctly) should speak up.

> 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.)

That's a totally fair point.  There is list consensus, and there is what
the wiki says, and it's a bug and a feature of OSM that they are at
times disconnected.

What the wiki at
  https://wiki.openstreetmap.org/wiki/Import/Guidelines
says is two things.   The main one is

  This doesn't include (for example) foreign keys from another database,
  unless those are absolutely necessary for maintaining the data in
  future.

and I don't think what I'm saying is really different from that.   I'm
just saying that "it seems like it will be useful" does not seem to
lead to "it will be useful" and it's a long way from "absolutely
necessary".

The other thing is

  You may have some metadata like the IDs used for your original
  data. If this metadata will be useful to OSM, then define your own
  prefix and use that on those metadata tags. The TIGER import for
  instance uses the "tiger:" prefix. The original ID of a TIGER object
  is tagged as "tiger:tlid".

which I think is leftover from when the TIGER import thought that was a
good idea.  It dates from the initial 2013-01-02 version of the wiki
page.  It is also qualified with "if this metadata will be useful to
OSM" which is a bit different than "if it would help you with a
re-import".

From being on this list for many years, I think the consensus has
evolved that foreign keys are not useful and don't belong.

I would really like to hear from people who have done imports and lived
with them on this point.


I propose to drop

  You may have some metadata like the IDs used for your original
  data. If this metadata will be useful to OSM, then define your own
  prefix and use that on those metadata tags. The TIGER import for
  instance uses the "tiger:" prefix. The original ID of a TIGER object
  is tagged as "tiger:tlid"

from the "Use the right tags" section because it is a description of
history, and I believe no longer the consensus view.

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