Thanks for the explanations.
I missed a very important detail: I didn't accept CT with this account. However
one of the Polish community members promised to mark all my changeset that were
not imports as CT-compatible.
From this point of view, a lot of my data is clean starting from some commit,
perhaps except of those which were imported already tagged properly
(paradoxically...), and those with untouched name.
In other areas, I edited data imported by other people in the same way.
My main hope is that, since I can precisely and automatically extract data
pieces that I created from scratch, the data in question is not considered to
be derived from CC data and therefore not bound by CC.
Regardless of the decision of UMP members, I don't want to rely solely on it in
order to keep months of my work alive - that's why I'm asking for an
alternative resolution here.
On a side note, relying on such a decision would be ironic - a lot of data I
imported were only a copy of a PD map :)
Cheers,
rhn
The v0 rule essentially states that allocating an object in the DB
doesn't create IP, so if you have an object that has lost all of the
attributes it originally had it is essentially a new object.
However in your case that really doesn't apply (IMHO), because what I've
seen from your examples is that you actually imported the data yourself
and at least some of the original tags have survived. Note that the data
would actually survive the redaction process at this point in time, but
naturally you shouldn't have agreed to the CTs in the first place.
The preferred way to proceed would be for you to get permission to
release the data you imported under the ODBL from the original creator
in the UMP project, as you probably know there is an effort under way to
organize exactly that in Poland.
Simon
Am 28.03.2012 22:43, schrieb rhn:
Three different examples; all of them were remapped verified in respect
to location and tags (except of name=* in most cases). That doesn't mean
the tags have changed though, sometimes they were imported just right.
http://www.openstreetmap.org/browse/way/28099536/history
http://www.openstreetmap.org/browse/way/28099539/history
http://www.openstreetmap.org/browse/way/28099452/history
Could you point me to the v0 rule you're referring to?
Cheers,
rhn
If you essentially remapped the objects it may be that some or most of
your data would be safe due to the v0 rule (regardless of any other
developments wrt UMP). It is difficult to answer this more definitely
we would need to see some examples.
Simon
Am 28.03.2012 22:12, schrieb rhn:
Hello,
Please excuse me if my question has been asked before, I don't follow
this list.
Today I found information about the way data is going to be marked as
incompatible - the way I understood it, all ways and nodes are going to
be reverted to the latest compatible version (i.e. the one before first
CC-only changeset).
This worries me, as it seems the bulk of my changesets will be deleted.
I focused on an area with data coming nearly exclusively from an
incompatible source (UMP). Before a license change was even in plans, I
managed to replace the road network almost completely with GPS traces and
some landuse data with WMS and traces.
The problem is, I never bothered too much with replacing the actual
database objects (takes too much time), thinking removal of source=*
would be enough. Let me mention that I removed source only from nodes
and ways that I had precise data about (and would have deleted if it
wasn't a hassle).
My questions are: Is it acceptable to copy the snapshot of my current
data that would otherwise get deleted and restore it as CT-compatible?
If yes, should the backup be performed now or is there going to be a way
to access CC data after the license change?
If not, is there any other way to preserve the data?
Cheers,
rhn
___
legal-talk mailing list
legal-talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/legal-talk
___
legal-talk mailing list
legal-talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/legal-talk
___
legal-talk mailing list
legal-talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/legal-talk
___
legal-talk mailing list
legal-talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/legal-talk
___
legal-talk mailing list
legal-talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/legal-talk
