>>      GET /node/#id/#version/ways
>>
>> But i don't think this can go into the api without a major change..
> 
> There is no problem adding new methods to the API at any point in time.
Coooooooool thing!

> The problem here is that I doubt it is possible to implement such a 
> method in an efficient way - the necessary information just doesn't 
> exist in the database.


> You would basically have to do something like:
> 
>   - Find that node version in the nodes table
to get the timestamp (or changeset?), right?

>   - Find all way versions which have ever included that node
>     in the way_nodes table
As way_nodes does not contain timestamp (changeset) infos you'll have to 
find *all versions* of *all ways* that ever contained that node, but for 
most of the nodes this is not too much i think (guessed: <10 ways in <30 
versions, so in worst case 300 items to do an integer comparison on, 10 
in best case)

>   - Look up those way versions in the ways table and match
>     the timestamps against the node to see if they were using
>     that version of the node or not
You must go for all ways and get their timestamp (or changeset?) and 
compare it with the timestamp (changeset?) the version of that node was 
changed.

This is no trivial task, I see. However there are some optimizations 
that could be done to make this a little faster:
  - maybe you could use changeset-ids rather then timestamps? I know
    changesets are no transactions and therefore this would not be as
    accurate as with timestamps but if it's faster it would be good
    enough for me ;)
  - skip the last step, producing a way-history xml and let the client do
    the processing (GET /node/#id/ways/history)
  - do step three for each way, starting with the higest way-version.
    Doing this the call would be faster for higher node-versions and
    slower for old versions, what seems reasonable to me

My problem is that it is not possible to show an intelligent revert of 
the changes from Changeset #5, as it's impossible to find that it even 
touched way #10.

Peter

_______________________________________________
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev

Reply via email to