[OSM-dev] [OSM-talk] Abstract on getting historic information about usage of a node

Peter Körner osm-lists at mazdermind.de
Wed Sep 16 15:17:22 BST 2009


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/...)




More information about the dev mailing list