<br><tt><font size=2>Michael Kugelmann <MichaelK_OSM@gmx.de> wrote
on 01/09/2011 04:19:41 PM:<br>
</font></tt>
<br><tt><font size=2>> we should replace the data not delete it! So
please remap the information that needs to be removed.<br>
</font></tt>
<br><tt><font size=2>Of course we should, but we need to gives ourselves
the tools which allow us to do this effectively and well.</font></tt>
<br>
<br><tt><font size=2>Lets think about the current process.</font></tt>
<br>
<br><tt><font size=2>When I have a v1 object that is non-CT compliant,
then we have to assume the further revisions may be derivatives.  If
CT-agreed mappers have added tags from a survey in later revisions, then
we can possibly grab those, but apart from that it is a remapping effort
that needs to be undertaken.  Given our tools are already designed
from remapping from scratch, with the modifications that have been made
to allow us to identify these objects, the remapping proceeds as per normal
(survey, imagery, etc), and the tools are good.</font></tt>
<br>
<br><tt><font size=2>However, when we have a v2 non-CT compliant object
based on a v1 CT-compliant one, it is a different story.  We can't
use the information added or changed in the v2 object, but sometimes the
information in the v1 object can be quite useful, and this could be used
as a base for the remapping.  Sometimes the v2 object is even a trivial
change, and the information in the v2 object isn't even a substantial improvement
on the v1 object, for example an addition of a default value, or movements
of an object less than the accuracy of even the best gps and imagery that
we have available.  In the first case, it would be useful to be able
to use an earlier (CT-compliant) version of a object as the basis for editing,
and make it apparent in the database this has happened (by hiding the non-CT
revision).  In the second case, we have to ask the question of whether
having these trivial "improvements" in the database actually
cause us substantial effort for little gain, especially if they may cause
us later (either by editing, or by automation) to discard work derived
from these releases that we really shouldn't have to.  Our tools are
designed to keep whatever history they can in a chain, and work with the
latest versions.  They aren't currently suited to this task.</font></tt>
<br>
<br><tt><font size=2>The objective is a CT-clean database, with the absolute
minimum data loss.</font></tt>
<br>
<br><tt><font size=2>The discussion is about the best way to accomplish
that, especially where we have CT-agreed versions of objects that we want
to leverage.</font></tt>
<br>
<br><tt><font size=2>Ian.</font></tt>