[Imports] Import of Flemish Government data (building footprints and addresses)
kevin.b.kenny at gmail.com
Mon Oct 29 22:55:40 UTC 2018
On Mon, Oct 29, 2018 at 6:06 PM Christoph Hormann <osm at imagico.de> wrote:
> Again i completely understand you motivation but as said i don't think
> OSM should burden itself with this for the convenience of a few import
And again, you offer no concrete alternative. Should I be asking the DWG
for assistance in reverting my existing imports, or would you prefer to
have them continue in OSM as 'dead' data that cannot readily be maintained?
> And ultimately this is not really a relavant subject for the discussion
> here because adding proprietary IDs is clearly not compatible with the
> verifiability principle so you would need to lobby for abolishing
> verifiability before we could seriously discuss this.
By 'proprietary ID's' you appear to include 'ID's that are present in open
data sets that the state government has released to the public domain.'
Since the external data sets are open and public, you appear to be
asserting that 'verifiability' is limited, sensu stricto, to 'can be
directly observed with the eyeball in the field.' Otherwise, anyone can
consult the external data set and verify that the object is indeed there as
Presuming that is indeed the case, let me ask:
Is it permissible to enter the phone number, email or website address for a
business if it isn't on the sign at the storefront? Is it permissible to
have a national park on the map if some mapper, personally, hasn't walked
its entire boundary, locating the survey pins, cairns and witness trees to
recover the survey line? Is it permissible to have administrative
boundaries in OSM at all, when we recognize that many of them are entirely
imaginary lines? (Some of them are even, for instance, imaginary lines
across water bodies, having no physical existence at all).
More germane to the argument, can I record the name of a lake, if there is
no sign at the lakefront telling me what it is? Or the name of a mountain,
likewise unsigned? Because that's really what these foreign keys are: an
assertion that "in the filing system of the National Register of Historic
Places, this object goes by the file number '780000284';" "in the New York
State Department of Environmental Conservation list of state lands, this
object goes by the facility number, '1615';" "in the cataloguing of the US
Geological Survey, this stream goes by the reach code, '08040023000601'."
Programmers adopt these arbitrary names because natural-language ones are
so frequently misspelt, miscapitalized, ambiguous, ..., and so another
naming method is needed to provide a solid identity for an object. They are
still names, even if their appearance is odd. I think that we've long
recognized that not all objects in the field have their names written on
them, and that the lack of a writing does not keep us from naming the
object in OSM.
Weird keys like the ones that arrived in the TIGER import, I would agree,
add negative value. They do not provide direct information to the user, and
do not provide a locator for useful external information, either. But I'm
finding it much harder to understand the aversion to a foreign key that
actually provides a link to external knowledge. How is it any different in
principle from a telephone number, URL or email address for a business?
I see that as I was typing this, you asserted that ID's in public database
are not permissible because they are not subject to 'independent'
How do I 'independently' verify a telephone number? I suppose I call it up
and see who answers - but an authoritative answer could come only from the
telephone company and cannot be 'independently' verified. By the same
token, a great many computers have downloaded the public data sets in
question; any of them can 'independently' verify a foreign key, even if the
authoritative answer could come only from the database publisher. This is
'independent' in exactly the same sense as that there are many copies of
the telephone directory in existence, even if the identifier was assigned
by the telephone company.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Imports