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

[Kevin Kenny]

Frederik Ramm:
> Keeping a link to the source signals to the mapper "don't touch this,
it's official data" or "your edits can be overwritten by a future import".

Andy Mabbett:
> That may be your interpretation; it is most certainly not mine. Do you
have any evidence that anyone other than you interprets links in this
bizarre manner?

Mateusz Konieczny:
> *raises hand*

Martin Koppenhoefer:

> I can confirm that for my mapping, having external ids is making editing
> significantly more complex, and often I don’t know how to deal with these
> when I do operations like merging or splitting or even just correcting a
> brand or operator tag.
>

Rest assured that if you are actually editing anything that I've imported,
you can feel free to edit the object without fear of being overwritten or
breaking things. Any foreign keys that I provide serve one of the two
purposes that I outlined: (1) as a bookmark so that I can find an object
that I imported - to make sure that a reimport is NOT overwriting another
mapper's work! - or (2) as a link to useful external data (some of which,
even in our time, is on paper, so paper file numbers that you can give to a
reference librarian come in handy).

In the first case, you won't get overwritten, or even make more work for
me. I'd be rather cross if you deleted the foreign key without making any
other changes, because that means that I'll be conflating the object
manually the next time I update. If you have some other reason for touching
the object, I know that I'm going to have to do manual work on the next
update to avoid damaging your work, so don't worry about the foreign keys,
that's my responsibility. If you have no other reason to edit the object,
please just leave the foreign keys alone, and I'll be happy.

In the second case, I'm simply presuming that anyone who, say, edits the
boundary of a historic site will preserve its 'heritage=2
heritage:operator=nrhp nrhp:nhl=yes ref:nrhp=72000840'. If that gets
broken, that's no better nor worse than breaking website=* or phone=*. Most
mappers don't break those, and it doesn't keep mappers from editing objects
that have contact information attached.

I also use a source=* tag on imports, simply as a courtesy to the data
source. While it may be lawful to import the data, as a scholar I would
surely feel that it would be plagiarism were I to fail to credit the source.

I'm willing to cope with virtually any edit, short of outright vandalism
[1], from another mapper, but I appreciate the courtesy of having my
foreign keys not deleted arbitrarily. Every such tag that I added was
documented in the import plan, and discussed on the mailing lists. If I
didn't use them, I wouldn't have added them!

I do concede that there appears to be a fairly large amount of detritus [2]
out there, mostly from old imports that certainly wouldn't be acceptable by
today's standards. I'd surely be willing to entertain a case that keys like
'gnis:county_name' or 'tiger:cfcc' add no value whatever, but only occupy
space on people's SSD's. Nevertheless, that particular question is above my
pay grade. I don't mess with tags that I don't understand. That means, for
instance, that if I find a node with gnis:*=* tags, and promote it to an
area, I retain the tagging.

If Frederik and the other board members, DWG members, server admins, want
to take on the task of sweeping up some of the debris, or at least
identifying which keys are thought to be useless, I'll cheer them on.
Still, I hope that they'll give people for whom foreign keys actually
assist with a workflow a chance to respond.


[1] I have had the experience of spending hours correcting data, only to
have it overwritten by someone else's undiscussed and undocumented import.
I very much appreciate the assistance of the DWG in setting it right again.
The guy who helped me even spotted another case that I needed to fix
manually. It got fixed, along with a note=* item containing a link to an
OSM diary item that describes a complicated issue affecting an
administrative boundary between a park and a military reservation.

[2] I'll plead guilty to a few rubbish tags - and probably at some point
ought to remove 'facility', 'NYCDEP:changed_fraction' and
'NYCDEP:prev_osm_id' in a mechanical edit. They don't participate in my
workflow, and leaked into OSM through a program bug. I'm simply deferring
that particular task until the next time I'm updating that particular
import I usually do it in the springtime, when outdoor recreationists are
starting to look at getting out again. That synchronizes fairly well with
upstream, too, since the state releases the updates in April.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/imports/attachments/20181029/5a4871b6/attachment-0001.html>