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

[Kevin Kenny]

Comments on two things:  foreign keys related to imports, and other foreign
keys:
----
1. Foreign keys related to imports.

I do retain foreign ID's for two imports that I curate: 'New York State
Department of Environmental Conservation Lands and Campgrounds' and 'New
York City Department of Environmental Protection Watershed Recreation
Lands'.

In both cases, it's to be able easily to check, when a new version of the
external data comes out, whether anything has happened to a particular
object. I retrieve it by its ID, then test whether the last modifying user
was me. (Yes, I start with multipolygons, and recurse into ways and
points.) If I can't find an object with the ID, or if another mapper has
modified the object, then I know that I have to treat the state of the
object as unknown and conflate by hand.  If, on the other hand, I'm the
last modifier, then I know that the object has not changed since the last
import, and needs no intervention whatsoever. Being able to say, "nope,
nobody's touched this (large!) set of objects since the last time I
imported them, I just have to examine this (much smaller!) set," saves a
tremendous amount of work!

In this mode of operation, I am not warning that a mapper can't modify the
object, or that it will be overwritten on the next import. I don't suppress
or overwrite the work of other mappers! It's simply an aid for me to find
the object again and be able to skip it in the common case where nobody's
touched it. I don't care if a mapper modifies the object - I'll conflate
manually. I don't care whether the mapper retains the ID or not when
modifying it - I'll detect the modification either way. It's just a
bookmark so that I can find the object again.

I'd be quite cross if anyone were to do a mechanical edit that removed the
foreign ID's in a wholesale fashion, but do not care at all what happens to
the ID if a mapper happens to edit an object for another reason - if a
mapper edits the object, it's my responsibility to respect the mapper when
updating the import.
----
2. Other foreign keys

I routinely place other foreign identifiers in OSM, as 'places to go for
more information. For historic places, for instance, I enter key sets such
as those on https://www.openstreetmap.org/way/429545226: 'heritage=2
heritage:operator=nhl ref:nhl=7200840' - which announces 'this site  has
designation as a National Historic Landmark whose reference number is
7200840'. I do that in accordance with the guidelines in
https://wiki.openstreetmap.org/wiki/Key:heritage#United_States. Once again,
this tagging is not an announcement that a future import will overwrite the
data, nor a warning to mappers not to overwrite it. It is a link to an
authoritative source where more information may be found. That source
happens to be identified by a *paper* file number, although certain of the
documents
<https://catalog.archives.gov/scripts/assets/pdfjs/web/viewer.html?file=https://catalog.archives.gov/catalogmedia/lz/electronic-records/rg-079/NPS_NY/72000840_NHL.pdf>
contained therein appear to be available scanned and digitized. Not all
National Historic Landmarks appear to have their files online, and the
search facility for them is rather broken, so I'm not always able to do
this with just a URL. Still, any competent research librarian could manage
to retrieve a copy of the file for a patron. Here, the foreign key did not
arise from an import. I added it by hand. Surely having a link available to
a rich set of additional information benefits map users. I personally see
it as no different in principle from adding a contact telephone, e-mail or
URL.

Denigrating such a link as 'bloat' and stating that linking to external
open data is outside our purview, is disheartening, particularly coming as
it does from a board member! I urge you to reconsider your blanket
pronouncement on external links. It comes across as saying to me, "the work
that you do to try to make objects informative is not welcome here."
Perhaps the dossier that presents the significance of the historic site and
preserves a record of the deliberations that led to its listing as a
National Historic Landmark does not interest you. In that case, there are
surely mappers whose interests you do not share.
----
Having corresponded with you in the past, I strongly suspect that neither
of these will constitute a 'solid use case.' I urge you to clarify whether
you are speaking for yourself or in one of your official capacities. If
your declaration is indeed official, then I have to give serious
consideration to the technical details of how to revert the offending data,
and what data it is permissible to retain moving forward. In that case, I
also request that you give some sort of guideline as to what constitutes an
acceptable use case and what the scope of the project is, because the
project guidelines as stated on the Wiki, for example, the "What not to
map" section of https://wiki.openstreetmap.org/wiki/Any_tags_you_like, or
the page https://wiki.openstreetmap.org/wiki/Good_practice, offer little
guidance as to the strength of the required the use case when adding any
given tag.

On Mon, Oct 29, 2018 at 10:12 AM Frederik Ramm <frederik at remote.org> wrote:

> Hi,
>
> On 10/29/18 11:34, Andy Mabbett wrote:
> > I *strongly* recommend including links (or IDs, that can be used in
> > links) to external databases. This is vital for two reasons: it
> > indicates the *precise* provenance of the sourced data; and it makes
> > OSM a better able to function as part of the web of linked-, open-,
> > data.
>
> OSM isn't the world's geodata melting pot, nor does it have the goal to
> be "able to function as part of the web of linked open data".
>
> The ideal building footprint in OSM is one that is surveyed or traced by
> an individual member of our project. We are content creators, not
> content re-users and distributors. We can occasionally incorporate a
> third-party data set but if we do, the version in OSM becomes our master
> version that we own, edit, modify, delete at will. We don't serve as a
> "cache" for foreign data sets, where copies are stored in OSM and
> updated whenever the foreign data source updates. Therefore, I find such
> links an unnecessary bloat.
>
> The idea of having an "audit trail" for every single geometry by way of
> an Id for that individual geometry is interesting, but I think that it
> is totally sufficient if a changeset carries the information that this
> changeset has been imported from XYZ data source at time stamp T;
> everything else can be researched down the line if the need should arise.
>
> If someone wants to import this kind of foreign IDs into OSM they should
> be able to present a solid use case - why is this good *for OSM*.
> Neither the original poster nor you have been able to do so.
>
> Bye
> Frederik
>
> --
> Frederik Ramm  ##  eMail frederik at remote.org  ##  N49°00'09" E008°23'33"
>
> _______________________________________________
> Imports mailing list
> Imports at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/imports
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/imports/attachments/20181029/f635bfd5/attachment.html>