<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Dear fellow-mappers,</p>
<p>In The Netherlands we went through this process 4 years ago. This
means we can talk from experience.</p>
<p>After the preparation period, we started the real import process
around march 2014 with a group of some 30 volunteers. At the end
of 2014, the initial import was finished. At the time, we decided
to import the building id's, but not the address id's. The address
id's we not available in the WFS data source we used and we
reasoned that the addresses can be identified by the address tags.<br>
</p>
<p>Since then, we are in the process of maintaining the imported
buildings and address. This concerns around 11.000 new buildings
and the same number of new addresses every month.<br>
The tooling we use in this process depends highly on the building
id's. Not having have the address id's seriously complicates the
maintenance of addresses, Even though the combination of postcode
and house number are unique in The Netherlands. Being official
government id's, the building and address id's in The Netherlands
get more and more official applications day by day. They are
already required in notarial acts and used by the chamber of
commerce. Leaving them out would not be an option in my opinion.</p>
<p>We have no issue with mappers being afraid to touch buildings
because of the building id's. Most people know where to find the
id, or file an import request on the forum for a building or a
block of buildings. Some complex buildings like Utrecht Central
station keep being mapped manually because the official data is
too complex.<br>
The main issue we have is with addresses being deleted, because
people delete a node instead of the poi tags. This is nothing new,
but it is detected more often because of the continuous comparison
between OSM and official building and address data.</p>
<p>Gertjan Idema<br>
</p>
<p><br>
</p>
<div class="moz-cite-prefix">On 01/11/2018 15:39, Pieter Vander
Vennet wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAM-CmFA5X3p-Ej1FeiWSTrsRjoA7mXwD99Gf2_wwM1rED=U+-g@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div id="gmail-magicdomid3" class="gmail-ace-line"><span
class="gmail-author-a-wz87zz90zz66zz82zt3itz84z5r8z80z4z69z">Hello
everyone</span><span
class="gmail-author-a-dz78zz77zz84z80jwz67z68t65f7">,</span></div>
<div class="gmail-ace-line"><span
class="gmail-author-a-dz78zz77zz84z80jwz67z68t65f7">Original
Poster here.<br>
</span></div>
<div id="gmail-magicdomid4" class="gmail-ace-line"><br>
</div>
<div id="gmail-magicdomid5" class="gmail-ace-line"><span
class="gmail-author-a-wz87zz90zz66zz82zt3itz84z5r8z80z4z69z">Thanks
for your remarks. A lot of people</span><span
class="gmail-author-a-dz78zz77zz84z80jwz67z68t65f7"> active</span><span
class="gmail-author-a-wz87zz90zz66zz82zt3itz84z5r8z80z4z69z">
in the Belgian community are following this discussion</span><span
class="gmail-author-a-cz67zz90zo5jz86zz83zz75zz85zz87zz82zz80zh99"> with
interest and some bewilderment</span><span
class="gmail-author-a-wz87zz90zz66zz82zt3itz84z5r8z80z4z69z">.</span><span
class="gmail-author-a-cz67zz90zo5jz86zz83zz75zz85zz87zz82zz80zh99"> Like
the first message, this is a reply that has been written by
several </span><span
class="gmail-author-a-dz78zz77zz84z80jwz67z68t65f7">members</span><span
class="gmail-author-a-cz67zz90zo5jz86zz83zz75zz85zz87zz82zz80zh99">
together. </span></div>
<div id="gmail-magicdomid6" class="gmail-ace-line"><span
class="gmail-author-a-cz67zz90zo5jz86zz83zz75zz85zz87zz82zz80zh99">We
did have a hard time filtering the actual discussion about
our import from the thread. We would kindly invite everyone
to take the discussion of other imports and the more philos</span><span
class="gmail-author-a-dz78zz77zz84z80jwz67z68t65f7">o</span><span
class="gmail-author-a-cz67zz90zo5jz86zz83zz75zz85zz87zz82zz80zh99">phical
points to a more appropriate place (e.g. the talk-list) and
stick to the topic of the Flemish bu</span><span
class="gmail-author-a-dz78zz77zz84z80jwz67z68t65f7">i</span><span
class="gmail-author-a-cz67zz90zo5jz86zz83zz75zz85zz87zz82zz80zh99">ldings
import.</span></div>
<div id="gmail-magicdomid7" class="gmail-ace-line"><br>
</div>
<div id="gmail-magicdomid8" class="gmail-ace-line"><span
class="gmail-author-a-cz67zz90zo5jz86zz83zz75zz85zz87zz82zz80zh99">We
have been working on this for two years and don't mind
working on it for a few more </span><span
class="gmail-author-a-dz78zz77zz84z80jwz67z68t65f7">months,
before running the actual integration</span><span
class="gmail-author-a-cz67zz90zo5jz86zz83zz75zz85zz87zz82zz80zh99">.
We</span><span
class="gmail-author-a-dz78zz77zz84z80jwz67z68t65f7"> are, in
the first place, looking for advice and guidance so as to
further improve our methods - together with with</span><span
class="gmail-author-a-cz67zz90zo5jz86zz83zz75zz85zz87zz82zz80zh99"> a
go-ahead </span><span
class="gmail-author-a-dz78zz77zz84z80jwz67z68t65f7">once all
issues are resolved.</span><span
class="gmail-author-a-cz67zz90zo5jz86zz83zz75zz85zz87zz82zz80zh99"> </span></div>
<div id="gmail-magicdomid9" class="gmail-ace-line"><br>
</div>
<div id="gmail-magicdomid10" class="gmail-ace-line"><span
class="gmail-author-a-cz67zz90zo5jz86zz83zz75zz85zz87zz82zz80zh99">In
case this was not clear befor</span><span
class="gmail-author-a-wz87zz90zz66zz82zt3itz84z5r8z80z4z69z">e:</span><span
class="gmail-author-a-cz67zz90zo5jz86zz83zz75zz85zz87zz82zz80zh99">
this is _not_ a flat import where all the data is dumped
into OSM automatically. This is an effort of the Belgian
community, where mappers select a subset of the data they
choose to integrate piecemeal, usually one street at a time.
The data is loaded in JOSM and checked against the aerial
imagery involving the mapper's common sense.</span></div>
<div id="gmail-magicdomid11" class="gmail-ace-line"><span
class="gmail-author-a-cz67zz90zo5jz86zz83zz75zz85zz87zz82zz80zh99">As
an example, this is a screenshot of the tool in action: </span><span
class="gmail-author-a-cz67zz90zo5jz86zz83zz75zz85zz87zz82zz80zh99
gmail-url"><a
href="https://matrix.org/_matrix/media/v1/download/matrix.org/WmemnfTQZOSfoKoIlByFBHmv"
moz-do-not-send="true">https://matrix.org/_matrix/media/v1/download/matrix.org/WmemnfTQZOSfoKoIlByFBHmv</a></span><span
class="gmail-author-a-cz67zz90zo5jz86zz83zz75zz85zz87zz82zz80zh99"> .
You can see that the tool reuses tags from OSM and is </span><span
class="gmail-author-a-cz67zz90zo5jz86zz83zz75zz85zz87zz82zz80zh99
gmail-comment gmail-c-byY8GXqDvvFz0dvd">offering the mapper
the choice</span><span
class="gmail-author-a-cz67zz90zo5jz86zz83zz75zz85zz87zz82zz80zh99">
which geometry should be used</span><span
class="gmail-author-a-dz78zz77zz84z80jwz67z68t65f7"> (by not
saving the import)</span><span
class="gmail-author-a-cz67zz90zo5jz86zz83zz75zz85zz87zz82zz80zh99">.
In combination with aerial imagery, this should cause little
to no problems</span><span
class="gmail-author-a-dz78zz77zz84z80jwz67z68t65f7"> in
regard with the original OSM-data</span><span
class="gmail-author-a-cz67zz90zo5jz86zz83zz75zz85zz87zz82zz80zh99">.</span></div>
<div id="gmail-magicdomid12" class="gmail-ace-line"><br>
</div>
<div id="gmail-magicdomid13" class="gmail-ace-line"><span
class="gmail-author-a-cz67zz90zo5jz86zz83zz75zz85zz87zz82zz80zh99">Mateusz
and Frederik, your points regarding documentation are being
addressed as we speak. </span></div>
<div id="gmail-magicdomid15" class="gmail-ace-line"><br>
</div>
<div id="gmail-magicdomid16" class="gmail-ace-line"><span
class="gmail-author-a-dz78zz77zz84z80jwz67z68t65f7">#
External IDs</span></div>
<div id="gmail-magicdomid17" class="gmail-ace-line"><br>
</div>
<div id="gmail-magicdomid297" class="gmail-ace-line"><span
class="gmail-author-a-wz87zz90zz66zz82zt3itz84z5r8z80z4z69z">The
most discussed point seems to be the IDs we wanted to
include. </span></div>
<div id="gmail-magicdomid19" class="gmail-ace-line"><span
class="gmail-author-a-dz78zz77zz84z80jwz67z68t65f7">We
believe the</span><span
class="gmail-author-a-wz87zz90zz66zz82zt3itz84z5r8z80z4z69z">
IDs</span><span
class="gmail-author-a-dz78zz77zz84z80jwz67z68t65f7"> will
significantly ease updates to our buildings when the GRB is
updated</span><span
class="gmail-author-a-wz87zz90zz66zz82zt3itz84z5r8z80z4z69z">,</span><span
class="gmail-author-a-dz78zz77zz84z80jwz67z68t65f7"> and
make the whole process more robust.</span></div>
<div id="gmail-magicdomid20" class="gmail-ace-line"><span
class="gmail-author-a-cz67zz90zo5jz86zz83zz75zz85zz87zz82zz80zh99
gmail-comment gmail-c-W8FTpN63EZVvaZMX">They</span><span
class="gmail-author-a-dz78zz77zz84z80jwz67z68t65f7
gmail-comment gmail-c-W8FTpN63EZVvaZMX"> provide a way to
update and cross</span><span
class="gmail-author-a-z80ziz85za1pez66zo0z71zz72zjz66zz65zz78z
gmail-comment gmail-c-W8FTpN63EZVvaZMX"> </span><span
class="gmail-author-a-dz78zz77zz84z80jwz67z68t65f7
gmail-comment gmail-c-W8FTpN63EZVvaZMX">reference the data </span><span
class="gmail-author-a-cz67zz90zo5jz86zz83zz75zz85zz87zz82zz80zh99
gmail-comment gmail-c-W8FTpN63EZVvaZMX">now and in the </span><span
class="gmail-author-a-dz78zz77zz84z80jwz67z68t65f7
gmail-comment gmail-c-W8FTpN63EZVvaZMX">future.</span><span
class="gmail-author-a-dz78zz77zz84z80jwz67z68t65f7"> Exactly
by keeping th</span><span
class="gmail-author-a-z80ziz85za1pez66zo0z71zz72zjz66zz65zz78z">e</span><span
class="gmail-author-a-dz78zz77zz84z80jwz67z68t65f7">s</span><span
class="gmail-author-a-z80ziz85za1pez66zo0z71zz72zjz66zz65zz78z">e</span><span
class="gmail-author-a-dz78zz77zz84z80jwz67z68t65f7"> IDs,
updating data down the road will be smoother and prevent
later changes </span><span
class="gmail-author-a-z80ziz85za1pez66zo0z71zz72zjz66zz65zz78z">from
OSM contributors </span><span
class="gmail-author-a-dz78zz77zz84z80jwz67z68t65f7">to be
overwritten. As </span><span
class="gmail-author-a-wz87zz90zz66zz82zt3itz84z5r8z80z4z69z">an
</span><span
class="gmail-author-a-dz78zz77zz84z80jwz67z68t65f7">added
benefit, keeping ID</span><span
class="gmail-author-a-z80ziz85za1pez66zo0z71zz72zjz66zz65zz78z">s</span><span
class="gmail-author-a-dz78zz77zz84z80jwz67z68t65f7"> makes
the import tool-agnostic</span><span
class="gmail-author-a-wz75zz89zaz68zz88ziz87z7z122zz83z95z83zwh">.
</span><span
class="gmail-author-a-cz67zz90zo5jz86zz83zz75zz85zz87zz82zz80zh99">It
will also make it much easier to flag errors in the source
data.</span></div>
<div id="gmail-magicdomid21" class="gmail-ace-line"><br>
</div>
<div id="gmail-magicdomid22" class="gmail-ace-line"><span
class="gmail-author-a-dz78zz77zz84z80jwz67z68t65f7">We
aren't afraid that people will refrain from editing
source-tagged objects: new users (using </span><span
class="gmail-author-a-wz87zz90zz66zz82zt3itz84z5r8z80z4z69z">the</span><span
class="gmail-author-a-cz67zz90zo5jz86zz83zz75zz85zz87zz82zz80zh99"> iD
editor</span><span
class="gmail-author-a-dz78zz77zz84z80jwz67z68t65f7">) will
probably not notice those tags in the first place; advanced
users will know about them. And intermediate users will
probably look them up. Merging and splitting are rather rare
operations </span><span
class="gmail-author-a-wz87zz90zz66zz82zt3itz84z5r8z80z4z69z">–</span><span
class="gmail-author-a-dz78zz77zz84z80jwz67z68t65f7"> once
the geometry is accurate, they should be</span><span
class="gmail-author-a-z80ziz85za1pez66zo0z71zz72zjz66zz65zz78z">come</span><span
class="gmail-author-a-dz78zz77zz84z80jwz67z68t65f7">
unnecessary operations. </span><span
class="gmail-author-a-wz87zz90zz66zz82zt3itz84z5r8z80z4z69z">Finally</span><span
class="gmail-author-a-dz78zz77zz84z80jwz67z68t65f7">, as the
data set is available for free under an open license, anyone
can verify the data independently (though </span><span
class="gmail-author-a-wz87zz90zz66zz82zt3itz84z5r8z80z4z69z">not</span><span
class="gmail-author-a-dz78zz77zz84z80jwz67z68t65f7"> </span><span
class="gmail-author-a-wz87zz90zz66zz82zt3itz84z5r8z80z4z69z">on
the ground</span><span
class="gmail-author-a-dz78zz77zz84z80jwz67z68t65f7">, </span><span
class="gmail-author-a-wz87zz90zz66zz82zt3itz84z5r8z80z4z69z">of
course</span><span
class="gmail-author-a-dz78zz77zz84z80jwz67z68t65f7">).</span></div>
<div id="gmail-magicdomid23" class="gmail-ace-line"><br>
</div>
<div id="gmail-magicdomid24" class="gmail-ace-line"><span
class="gmail-author-a-cz67zz90zo5jz86zz83zz75zz85zz87zz82zz80zh99">We
will address the worries about the external IDs on a point
by point basis below:</span></div>
<div id="gmail-magicdomid25" class="gmail-ace-line"><br>
</div>
<div id="gmail-magicdomid27" class="gmail-ace-line"><span
class="gmail-author-a-cz67zz90zo5jz86zz83zz75zz85zz87zz82zz80zh99">From
</span><span
class="gmail-author-a-cz67zz90zo5jz86zz83zz75zz85zz87zz82zz80zh99
gmail-b"><b>Frederik Ramm:</b></span></div>
<div id="gmail-magicdomid29" class="gmail-ace-line">
<ul class="gmail-list-indent1">
<li><span
class="gmail-author-a-cz67zz90zo5jz86zz83zz75zz85zz87zz82zz80zh99
gmail-i"><i>If you delete a building</i></span><span
class="gmail-author-a-wz75zz89zaz68zz88ziz87z7z122zz83z95z83zwh
gmail-i"><i> </i></span><span
class="gmail-author-a-cz67zz90zo5jz86zz83zz75zz85zz87zz82zz80zh99
gmail-i"><i>that has such an ID, how will you ensure i</i></span><span
class="gmail-author-a-z80zz86zz87zz77zikorz83zz78zwn61z89zj gmail-i"><i>t</i></span><span
class="gmail-author-a-cz67zz90zo5jz86zz83zz75zz85zz87zz82zz80zh99
gmail-i"><i> isn't brought in again</i></span><span
class="gmail-author-a-wz75zz89zaz68zz88ziz87z7z122zz83z95z83zwh
gmail-i"><i> </i></span><span
class="gmail-author-a-cz67zz90zo5jz86zz83zz75zz85zz87zz82zz80zh99
gmail-i"><i>through a later "update import"? Etc.</i></span><span
class="gmail-author-a-wz75zz89zaz68zz88ziz87z7z122zz83z95z83zwh gmail-i"><i>"</i></span></li>
</ul>
</div>
<div id="gmail-magicdomid31" class="gmail-ace-line"><br>
</div>
<div id="gmail-magicdomid32" class="gmail-ace-line"><span
class="gmail-author-a-cz67zz90zo5jz86zz83zz75zz85zz87zz82zz80zh99">There
will not be "an update import". The tool is built for
continuous use. It will improve the geometry of existing
buildings and already looks at the source tags. The tool is
buil</span><span
class="gmail-author-a-dz78zz77zz84z80jwz67z68t65f7">t</span><span
class="gmail-author-a-cz67zz90zo5jz86zz83zz75zz85zz87zz82zz80zh99"> for
heavy mappers who will be monitored by our closely knit
community. Importing and updating will be done street by
street</span><span
class="gmail-author-a-dz78zz77zz84z80jwz67z68t65f7"> or </span><span
class="gmail-author-a-cz67zz90zo5jz86zz83zz75zz85zz87zz82zz80zh99">block
by block</span><span
class="gmail-author-a-dz78zz77zz84z80jwz67z68t65f7"> basis</span><span
class="gmail-author-a-cz67zz90zo5jz86zz83zz75zz85zz87zz82zz80zh99">. We
believe we can</span><span
class="gmail-author-a-dz78zz77zz84z80jwz67z68t65f7"> trust</span><span
class="gmail-author-a-cz67zz90zo5jz86zz83zz75zz85zz87zz82zz80zh99">
these mappers to analy</span><span
class="gmail-author-a-dz78zz77zz84z80jwz67z68t65f7">z</span><span
class="gmail-author-a-cz67zz90zo5jz86zz83zz75zz85zz87zz82zz80zh99">e
situations like this on a case by case basis. In this case,
whether of not the deleted building had an ID does not
matter much.</span></div>
<div id="gmail-magicdomid33" class="gmail-ace-line"><br>
</div>
<div id="gmail-magicdomid34" class="gmail-ace-line"><br>
</div>
<div id="gmail-magicdomid35" class="gmail-ace-line"><span
class="gmail-author-a-cz67zz90zo5jz86zz83zz75zz85zz87zz82zz80zh99">These
points, respectively by Frederik Ramm, Christoph Hormann and
Mateusz Konieczny are quite similar. </span><span
class="gmail-author-a-cz67zz90zo5jz86zz83zz75zz85zz87zz82zz80zh99
gmail-b"><b>We'll answer them together.</b></span></div>
<div id="gmail-magicdomid36" class="gmail-ace-line">
<ul class="gmail-list-indent1">
<li><span
class="gmail-author-a-cz67zz90zo5jz86zz83zz75zz85zz87zz82zz80zh99
gmail-i"><i>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</i></span></li>
<li><span
class="gmail-author-a-cz67zz90zo5jz86zz83zz75zz85zz87zz82zz80zh99
gmail-i"><i> For this purpose it is completely
unnecessary to bother the OSM community with external
IDs. If you want to check if the data has been
unchanged since you added it then do exactly that -
check if there are any newer versions of the objects
that have originally been added in the import.</i></span></li>
</ul>
</div>
<div id="gmail-magicdomid48" class="gmail-ace-line">
<ul class="gmail-list-indent1">
<li><span
class="gmail-author-a-cz67zz90zo5jz86zz83zz75zz85zz87zz82zz80zh99
gmail-i"><i>* What is the point of adding tags like
source:geometry:entity given that like any other tags
they may be edited once added to OSM?</i></span></li>
</ul>
</div>
<div id="gmail-magicdomid49" class="gmail-ace-line"><br>
</div>
<div id="gmail-magicdomid50" class="gmail-ace-line"><span
class="gmail-author-a-cz67zz90zo5jz86zz83zz75zz85zz87zz82zz80zh99">It
is not, and has never been, the intention to fully automate
this. As we are trying to make clear, this info is needed
and used all the time, and not at some vague "maybe we do an
update sometime". We are not using the IDs to make a direct
(full database) comparison to see what exists in one and not
in the other on a gigantic scale. We are not looking for an
'auto update OSM with all new buildings added to GRB'. We
use the IDs, on a SINGLE BUILDING comparison basis only to
see what's changed (geometry touch-ups, or entirely
replacing a building).</span></div>
<div id="gmail-magicdomid51" class="gmail-ace-line"><br>
</div>
<div id="gmail-magicdomid52" class="gmail-ace-line"><span
class="gmail-author-a-cz67zz90zo5jz86zz83zz75zz85zz87zz82zz80zh99">"THEY
WON'T BE STABLE ANYWAY"</span></div>
<div id="gmail-magicdomid53" class="gmail-ace-line"><span
class="gmail-author-a-cz67zz90zo5jz86zz83zz75zz85zz87zz82zz80zh99">If
the external references are edited, the tool will flag the
building as needing an update. The only thing a (deliberate
or accidental) unneeded change of the ID would do, is alert
the tool's users that something doesn't add up. Either the
building has been replaced in reality (and thus having a new
UIDN), and you can improve the geometry of the new building.
If no apparent change to the physical building can be
traced, the UIDN can be restored. The amount of 'false
positives' due to unintended edits of the IDs is expect not
to come remotely close to the useful flaggings.</span></div>
<div id="gmail-magicdomid54" class="gmail-ace-line"><span
class="gmail-author-a-cz67zz90zo5jz86zz83zz75zz85zz87zz82zz80zh99">Without
the tags, it's hard to tell which buildings have been
imported: you would need complicated spatial heuristics
because we don't blindly copy buildings, we improve them
through other sources. Once mapped, the geometry changing
would happen more often than the tags changing, so we'd have
a lot more false positives. <br>
</span></div>
<div class="gmail-ace-line"><span
class="gmail-author-a-cz67zz90zo5jz86zz83zz75zz85zz87zz82zz80zh99"><br>
</span></div>
<div class="gmail-ace-line"><span
class="gmail-author-a-cz67zz90zo5jz86zz83zz75zz85zz87zz82zz80zh99"><br>
</span></div>
<div id="gmail-magicdomid56" class="gmail-ace-line"><span
class="gmail-author-a-cz67zz90zo5jz86zz83zz75zz85zz87zz82zz80zh99">"WHY
NOT JUST CREATE A DATABASE OF LINKS EXTERNALLY?"</span></div>
<div id="gmail-magicdomid57" class="gmail-ace-line"><span
class="gmail-author-a-cz67zz90zo5jz86zz83zz75zz85zz87zz82zz80zh99">In
theory it would be possible to have the tool keep a register
of which OSM ID maps to which ID in the GRB or to evaluate
changesets to get similar info. Some issues with this
approach:</span></div>
<div id="gmail-magicdomid451" class="gmail-ace-line">
<ul class="gmail-list-bullet1">
<li><span
class="gmail-author-a-cz67zz90zo5jz86zz83zz75zz85zz87zz82zz80zh99">Because
we aren't doing an automatic import but manually add the
buildings through JOSM, this would require us to copy
the OSM ID of each building manually, or rely on
heuristics.</span></li>
</ul>
</div>
<div id="gmail-magicdomid452" class="gmail-ace-line">
<ul class="gmail-list-bullet1">
<li><span
class="gmail-author-a-cz67zz90zo5jz86zz83zz75zz85zz87zz82zz80zh99">We
don't want to centralize the link between OSM and GRB.
There isn't one single person doing the import, it's
something several people in the community</span><span
class="gmail-author-a-wz75zz89zaz68zz88ziz87z7z122zz83z95z83zwh">
work on</span><span
class="gmail-author-a-cz67zz90zo5jz86zz83zz75zz85zz87zz82zz80zh99">.
Anyone could host the tool if its current maintainer
disappears. </span></li>
</ul>
</div>
<div id="gmail-magicdomid453" class="gmail-ace-line">
<ul class="gmail-list-bullet1">
<li><span
class="gmail-author-a-cz67zz90zo5jz86zz83zz75zz85zz87zz82zz80zh99">Pushing
the analysis of what exactly has happened towards a
changeset is an unnecessary burden on a mapper. The
changeset will not just contain "here be new buildings",
but also "in this case, we just used part of the
geometry of the GRB building, but we left part of the
building geometry intact because that was better in
OSM". After having analysed the changeset, the mapper
would still have to look up in an import database what
exactly the relationship between the OSM and GRB objects
was at the time of import</span><span
class="gmail-author-a-cz67zz90zo5jz86zz83zz75zz85zz87zz82zz80zh99
gmail-comment gmail-c-aprzMNVsJDa6ka9t">.</span></li>
</ul>
</div>
<div id="gmail-magicdomid454" class="gmail-ace-line">
<ul class="gmail-list-bullet1">
<li><span
class="gmail-author-a-cz67zz90zo5jz86zz83zz75zz85zz87zz82zz80zh99">An
external database providing the link between OSM and GRB
objects would be outdated after a day and almost
impossible to update with changes on the OSM side</span></li>
</ul>
</div>
<div id="gmail-magicdomid456" class="gmail-ace-line"><br>
</div>
<div id="gmail-magicdomid62" class="gmail-ace-line"><br>
</div>
<div id="gmail-magicdomid63" class="gmail-ace-line"><span
class="gmail-author-a-cz67zz90zo5jz86zz83zz75zz85zz87zz82zz80zh99">"WHY
NOT JUST COMPARE GEOMETRIES?"</span></div>
<div id="gmail-magicdomid64" class="gmail-ace-line"><span
class="gmail-author-a-cz67zz90zo5jz86zz83zz75zz85zz87zz82zz80zh99">Doing
a geometrical analysis to analyze differences would be
impractical, not just because this would be computationally
heavy, but also because it would lead to too much false
positives. For example because of tiny changes, but also
because we do not blindly use source geometries since we
first address overnoding.</span></div>
<div class="gmail-ace-line"><span
class="gmail-author-a-cz67zz90zo5jz86zz83zz75zz85zz87zz82zz80zh99"><br>
</span></div>
<div class="gmail-ace-line"><span
class="gmail-author-a-cz67zz90zo5jz86zz83zz75zz85zz87zz82zz80zh99"><br>
</span></div>
<div class="gmail-ace-line"><span
class="gmail-author-a-cz67zz90zo5jz86zz83zz75zz85zz87zz82zz80zh99"><br>
</span></div>
<div class="gmail-ace-line"><span
class="gmail-author-a-cz67zz90zo5jz86zz83zz75zz85zz87zz82zz80zh99">I
hope that all confusion is cleared now and that we can move
this issue forward.<br>
</span></div>
<div>
<div dir="ltr" class="gmail_signature"
data-smartmail="gmail_signature">
<div dir="ltr"><br>
</div>
<div>With Regards,</div>
<div>The Belgian Mappers,</div>
<div>Pieter Vander Vennet<br>
</div>
</div>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
Imports mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Imports@openstreetmap.org">Imports@openstreetmap.org</a>
<a class="moz-txt-link-freetext" href="https://lists.openstreetmap.org/listinfo/imports">https://lists.openstreetmap.org/listinfo/imports</a>
</pre>
</blockquote>
</body>
</html>