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