Hopefully you don't kill me right off but I re-created this Testcase in
the OSM db.
I only used a comment tag on each element so they won't get rendered and
are identifiable in the history as Testcase later. I also created them
near my home where I'm the only active mapper I now of.
== Testcase ==
1. In Changeset #2502021 I created Way #40896886, v1 with it's five nodes
#497779713, v1
#497779710, v1
#497779707, v1
#497779704, v1
#497779695, v1
2. In Changeset #2502042 I moved node #497779713, v2
3. In Changeset #2502049 I deleted node #497779713, v3, thus modifying
way #40896886, v2
4. In Changeset #2502062 I deleted the rest.
== Issues ==
When I now lookt at the 2nd changeset I only see node #497779713 and I'm
umable to find out if a way was modified at all. This is issue #1.
Once I know the ID of the way (e.g. in the 1st, 3rd and 4th Changeset)
and the time it was modified (also from the Changeset) The Client is
able to reconstruct the geometry of the way by fetching the history of
all it's nodes and comparing the timestamps in the Client. This does not
scale very well - issue #2.
== Solutions, Client perspective ==
For issue #1: a new API call: GET /api/0.6/node/#id/#version/ways
For issue #2:
either a new API call: GET /api/0.6/way/#id/#version/full
or extending the nd-tags of following calls with version numbers:
GET /api/0.6/way/#id
GET /api/0.6/way/#id/#version
GET /api/0.6/way/#id/history
== Solutions, Server perspective ==
Either implement the new call with on-demand searching on a Timestamp
basis, as Tom explains in [0], or extend the way_nodes table somehow, as
explained by Ian in [1], thus making the needed calls less expensive.
This is true for both issues.
== Decisions ==
The Choice that is up to be made now is between the following three
possibilities
a) do not implement these calls
b) implement them on demand
c) implement them with a new column/index
== Impacts ==
a) without these calls it's not possible to do intelligent diffs from
changesets, as they would be needed to do high-quality reverts with
dirty data. We need such revert-tools to encounter upcoming
vandalism (which we'll face with rising popularity.
b) this will cost CPU time on the API server, but regarding issue 2 it
would possibly be better than a bunch of history requests.
c) this will cost disk-space and memory for the index. The CPU time
will be consumed only once.
== further proceedings ==
First the maintainers of the API have to decide whih way to go. Ian
already volunteered for implementing way c (see end of [1]).
Peter
[0] http://bit.ly/139XK1 (http://lists.openstreetmap.org/...)
[1] http://bit.ly/ozrBN (http://lists.openstreetmap.org/...)
_______________________________________________
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev
