[OSM-talk] How to start to remove non-CT compliant data..
Ian Sergeant
isergean at hih.com.au
Thu Sep 1 07:57:23 BST 2011
Michael Kugelmann <MichaelK_OSM at gmx.de> wrote on 01/09/2011 04:19:41 PM:
> we should replace the data not delete it! So please remap the
information that needs to be removed.
Of course we should, but we need to gives ourselves the tools which allow
us to do this effectively and well.
Lets think about the current process.
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.
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.
The objective is a CT-clean database, with the absolute minimum data loss.
The discussion is about the best way to accomplish that, especially where
we have CT-agreed versions of objects that we want to leverage.
Ian.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk/attachments/20110901/4e1951bb/attachment.html>
More information about the talk
mailing list