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

Ian Dees ian.dees at gmail.com
Wed Sep 16 20:28:57 BST 2009


On Wed, Sep 16, 2009 at 2:19 PM, Peter Körner <osm-lists at mazdermind.de>wrote:

> What's the problem with that? If way 10 did not ever use node 50v3, then it
>> should not be included in the "give me all ways that use node 50v3" call,
>> right?
>>
>> (semi-ASCII-art ahead, arm your fixed-width photos)
>>
>> Here's way 10v1 (numbers are nodes):
>>
>> 50v1----51v1----52v2
>>
>> ...and a history table like this:
>> way_id  way_rev  node_id   node_rev
>> 10      1        50        1
>> 10      1        51        1
>> 10      1        52        2
>>
>> I come along and move node 52, causing a rev on the way and a rev on the
>> node:
>>
> And that's the point: atm. moving a node does not increase a ways version.
>
> The data stored for a way is not it's geometry but only the nodes it
> consists of. So changing the geometry of a way does not change it's version,
> removing or adding a node to it does.
>
> So when a node is moved a new node-id/node-ver-pair springs into live but
> its the ways are not updated.


And Tom's good point is that if we were to track that information, we would
have to insert W new rows into my fictitious history table where W is the
number of ways that contain the node every time we change the node.

How much slower would that make the node change code? I see (in my naive SQL
knowledge) 1+W SQL calls (1 being a SELECT to find the way_id's and W being
one INSERT into my history table for every way containing that node).

That doesn't seem TOO bad... of course, node manipulation is the most
prevalent call in the API I'm sure.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20090916/38e353fd/attachment.html>


More information about the dev mailing list