[Imports] Import of Flemish Government data (building footprints and addresses)

[Kevin Kenny]

(Reposting without quoted message to avoid message length limitation)

Those of us who do imports have been improving our tools continually, in
order to be able to import responsibly according to current import
guidelines and current mapping practice.

Pieter Vander Vennet describes virtually the identical process to the one I
use in updating the boundaries of New York State public lands. In my case
as well as that of the Belgian mappers, the update is continuous, at least
in concept. (I tend to run updates only about annually, but work on them
sporadically over a period of weeks or months.) The Belgians are dealing
with a much larger number of objects than I address, although mine are much
larger and have much more complex topology (which makes the idea of 'just'
matching the geometry even harder!)

In both use cases, the major purpose of the foreign key is to avoid manual
review in the case where OSM will not be updated. If an object (retrieved
by key) is unchanged since the last import, in both OSM and the external
database, then there is no work to be done. (This is the case for the
overwheming majority of managed objects.) Otherwise, whatever is done gets
manual review. This process is impossible without some tag that follows the
imported object, because without one there's no handle by which it can be
grasped. The only effect that having a mapper modify the tag or modify the
tagged object will be that it will trigger manual review. Since the manual
review is work, removing the tag for no reason is impolite, but it won't
trigger any cascade of bad data, cause changes made by human mappers to be
overwritten, or any of the disasters that some posters appear to envision.

Because in my pipeline every imported object is reviewed manually, there's
no issue with a deleted object reappearing. I've already observed this case
in practice in my workflow with the New York State public lands. I have
repeatedlyu done manual review of the Lake George Islands State Campground
https://www.openstreetmap.org/relation/6385471 (*), because it includes
several islets that were washed away in a hurricane in 2011. The fact that
I do *not* find an individual item is itself cause for performing a manual
review, not cause for automatically reinserting it. (I also, for this case,
insert ways like https://www.openstreetmap.org/way/542355389 to warn
mappers away from tracing the destroyed islet from orthoimages.)

I agree with the Belgian mappers in every particular.

(*) Side note: I do not agree with all the tagging on that particular
relation, but local mappers have requested that
  a. I refrain from putting 'name=*' on it, since that causes at least one
renderer that they care about to render that name in preference to the
names of individual islets.
  b. I refrain from marking the whole area 'amenity=camping_site' even
though it is designated as a campground, and refrain from using
'leisure=nature_reserve' tagging for legacy renderers, because the locals
wish to map individual tent sites and picnic areas within it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/imports/attachments/20181101/12e78b81/attachment.html>