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

[jacob at cyptem.com]

OK, so it seems foreign keys are out. I am not a "master" programmer but 
I think I have enough experience to accomplish this import. Therefore I 
propose:

- Import data without foreign keys. Use previously described script, and 
JOSM Conflation plugin to automatically handle 99.9% of cases. 
Realistically this seems like the maximum that *any* automated system 
can manage, regardless of programming knowledge. An advanced script does 
not have local knowledge like I do. Both existing OSM data as well as 
reference dataset have errors and omissions. If a 100% automated import 
is required, then an import here is not possible.

- Use JOSM to manually handle the remaining 0.1% of conflation cases. 
For these remaining issues, the deviations from reference data which 
would cause problems with future updates are not marked using a foreign 
key. Where necessary, perform on-the-ground checks to resolve conflicts.

- For future updates, there are multiple options:
     - Only import areas which do not have existing good data. Since this 
import's scope is currently limited to Cache Valley, UT, that means new 
developments and expansion into farm land.
     - Alternatively, when updating areas with older data (for example 10 
years from now when parcels may have been divided, etc.), handle 
conflation with previously imported data using a combination of 
automatic matching and manual review, just like the initial import.

Thanks all for your input. I'll get to work right now updating the Wiki 
page. Let me know what you think of these ideas.

Jacob

On 2022-10-11 07:25, Martin Koppenhoefer wrote:

> sent from a phone
> 
>> On 10 Oct 2022, at 20:25, Greg Troxel <gdt at lexort.com> wrote:
>> 
>> 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.
> 
> foreign keys are also harmful, at the extreme they may prevent a 
> contributor from performing an update because they do not know how to 
> deal with it, or prevent simplifying things by combining the geometry 
> (if everything is the same except the foreign key).
> 
> Cheers Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/imports/attachments/20221011/e2026641/attachment.htm>