>> 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
