<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /></head><body style='font-size: 10pt; font-family: Helvetica,Arial,sans-serif'>
<p>OK, I've made some updates to the procedure. Please see the updated <a href="https://github.com/lint3/cachevalley-address-import-osm#procedure">readme section</a>. Summary of issues and their proposed resolutions:</p>
<ul>
<li>Deduplication of existing and new data - Use the JOSM Conflation plugin to auto-merge. Then manually review the rest <em>before</em> uploading.
<ul>
<li>Using the temporary <span style="font-family: 'andale mono', monospace;">UGRC:address_type</span> tag to only merge "primary" addresses to buildings (ie, not "apt 4", etc. Leave those as points.) (<a href="https://raw.githubusercontent.com/lint3/cachevalley-address-import-osm/main/imgs/conflation_example.png">Example screenshot</a>)- This tag should probably be removed before upload.</li>
</ul>
</li>
<li>Handling future updates - Use <span style="font-family: 'andale mono', monospace;">UGRC:import_uuid</span> tag to maintain a unique identifier back to the original database. Later when updating, skip rows with IDs that already exist.</li>
<li>Other discussion topics in <a href="https://wiki.openstreetmap.org/wiki/Talk:Utah/CacheValleyAddressImport">wiki talk page</a></li>
<li>I've added some <a href="https://github.com/lint3/cachevalley-address-import-osm/tree/main/sample_data">sample data</a> to the git repository. Perhaps someone can go over that to see if it meets import standards.
<ul>
<li>There are indeed still some issues with the data, mainly points one on top of another. From what I've seen, they are detected pretty well by the JOSM Validator, to be fixed before upload.</li>
</ul>
</li>
</ul>
<p>Jacob</p>
<p id="reply-intro">On 2022-10-07 10:47, Greg Troxel wrote:</p>
<blockquote type="cite" style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0">
<div class="pre" style="margin: 0; padding: 0; font-family: monospace"><br />Mike Thompson <<a href="mailto:miketho16@gmail.com">miketho16@gmail.com</a>> writes:<br /><br />
<blockquote type="cite" style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0">On Thu, Oct 6, 2022 at 2:07 PM <<a href="mailto:jacob@cyptem.com">jacob@cyptem.com</a>> wrote:<br /><br />
<blockquote type="cite" style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0">Oh, that makes sense - thanks for the explanation. So the idea is to never<br />let known issues into the main dataset in the first place.<br /><br /></blockquote>
Opinions may differ in a project as big as OSM, but that is my<br />understanding of the consensus.</blockquote>
<br />Yes, it's my understanding of consensus too, in addition to my opinion.<br /><br />Note that there are two sets of standards for OSM. One is for how a<br />person doing mapping is judged, when they are mapping at human speed in<br />an editor. We tend to have notions of the right way, but be pretty<br />lenient about things going wrong and getting fixed later, because new<br />people get things wrong, but we need new people to have more people and<br />that's how later experienced people start.<br /><br />The other set of standards is for importsa and mechanical edits,<br />basically anything at scale. There, we basically insist that everything<br />is done fully meets standards of "done right". Yes, it means it is<br />harder to do an import, and takes more time to write code, but if that's<br />what it takes to do it right, that's how it is. We don't have any<br />notion that it's better to let deficient imports happen because it makes<br />it easier for people to do them.<br /><br />Generally I think people agree that if an import is slowed down or even<br />doesn't happen because it's too hard to do it right, that's ok.<br /><br />
<blockquote type="cite" style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0">
<blockquote type="cite" style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0">And thanks to all for your patience, understanding, and expertise!<br /><br /></blockquote>
Thanks for listening to community input!</blockquote>
<br />Agreed - that's what this list is for and it's great to see it working,<br />which it doesn't always seem to.</div>
</blockquote>
</body></html>