[OSM-dev] API 0.7+: Split node concept?

Andy Allan gravitystorm at gmail.com
Tue Oct 12 21:22:09 BST 2010

On Tue, Oct 12, 2010 at 8:45 PM, Chris Browet <cbro at semperpax.com> wrote:
> I am wondering (I wonder a lot lately ;-)) if some have already given a
> thought to the fact that nodes actually represent 2 different concepts in
> the current api:
> - a node in the geometrical sense, i.e. used to define a linestring/way
> - a POI
> Wouldn't keep the "node" element only for POI (i.e. with tags) a better
> idea? E.g something like this:
>>   <node version="0" lon="3.5348711" lat="54.1945783"
>> timestamp="2010-10-12T12:35:18Z" user="" id="-9" >
>>     <tag k="highway" v="traffic_light"/>
>>   </node>
>>   <way version="0" timestamp="2010-10-12T12:35:02Z" user="" id="-2">
>>     <point lon="3.5317073" lat="54.1929773"/>
>>     <nd ref="-9"/>
>>     <point lon="3.5377391" lat="54.1960297"/>
>>   </way>
> Seems to me that it would:
> - be less confusing, both for consumers and editors
> - save db space
> - save memory/CPU cycle on the consumer side
> What do you think?

I think it makes it harder for the editing software, which needs to
(magically) convert the "points" into proper nodes and vice versa as
the points get used for a junction (or removed from a junction, or
tagged, or whatnot). It also doesn't allow us to model anything that
we can't model at the moment.

If you're going to use these "points" then all sorts of things
involving history get more convoluted, since everything would need to
be implemented once for nodes-in-way and then again, with different
logic, for tracking points-in-way. Detecting a point being moved
becomes a bit more tricky I think. Unfortunately you'd still be in the
position that geometry changes to a way aren't reflected in the way
history; sure, more changes would, but some dereferencing would be
needed for checking nodes.

I don't think it's less confusing either, tbh, so I think mainly it
saves on DB space and processing cycles. I think you'd need to move
entirely to points and use one of the (nasty) GIS industry
topographical-connection-assumption models to see any real benefit
from adding them.


More information about the dev mailing list