On Wed, Sep 16, 2009 at 2:19 PM, Peter Körner <osm-li...@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.
_______________________________________________ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
