<html>
  <head>
    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
  </head>
  <body>
<div>I think that better phrasing describing situation without making it insulting may be:<br></div><div dir="auto">"they want to do doable part of import, without parts that are horrifically hard to<br></div><div dir="auto">do and/or impossible".<br></div><div dir="auto"><br></div><div dir="auto">I also think that at least it should be mentioned that importing foreign keys <br></div><div dir="auto">from various databases is of dubious use, causes confusion and is extremely rarely<br></div><div dir="auto">actually useful.<br></div><div dir="auto"><br></div><div dir="auto">Especially as you cannot assume match based on this database id being tagged<br></div><div dir="auto">(mapper could move items or duplicate them)<br></div><div dir="auto"><br></div><div dir="auto">wikipedia and wikidata are one of few in actual and real use<br></div><div><br></div><div>Oct 9, 2022, 17:13 by imports@openstreetmap.org:<br></div><blockquote class="tutanota_quote" style="border-left: 1px solid #93A3B8; padding-left: 10px; margin-left: 5px;"><div>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. <br></div><div>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.)<br></div><div><br></div><div><br></div><div class=""><div>On October 9, 2022 5:38:56 AM MDT, Greg Troxel <gdt@lexort.com> wrote:<br></div><blockquote style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class=""><pre class="" dir="auto"><div><br></div><div>jacob@cyptem.com writes:<br></div><div><br></div><blockquote style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;" class=""><div>   * Handling future updates - Use UGRC:import_uuid tag to<br></div><div>maintain a unique identifier back to the original database. Later when<br></div><div>updating, skip rows with IDs that already exist.<br></div></blockquote><div><br></div><div>I'm really unclear on consensus about foreign keys.  My impression is<br></div><div>that:<br></div><div><br></div><div>  1) generally people on the list think they shouldn't be used, almost to<br></div><div>  the point of rough consensus<br></div><div><br></div><div>  2) everyone who is doing an import for the first time thinks they are<br></div><div>  going to be useful later and wants to include them, even though the<br></div><div>  first import is often "I only want to do the easy part" and none of<br></div><div>  the difficult steps are implemented.<br></div><div><br></div><div>  3) People who understand how difficult the difficult steps are don't<br></div><div>  see any real value in foreign keys in the database.<br></div><div><br></div><div>We have recent data for point 2 :-)<br></div><div><br></div><div>Does anybody think I'm off base about (1) and (3)?  If not, maybe we<br></div><div>should adjust the import guidelines to say "no foreign keys".  If so,<br></div><div>maybe we should say "a single foreign key is ok".<br></div><div><br></div><div>I don't think foreign keys are terrible, but I think they aren't that<br></div><div>useful and the combination of people not wanting to do the hard<br></div><div>matching/checking I recently outlined and wanting foreign keys is not a<br></div><div>good outcome -- we get the bloat without whatever benefit there might<br></div><div>be.<br></div></pre></blockquote></div></blockquote><div dir="auto"><br></div>  </body>
</html>