Doru-Julian Bugariu wrote:
> Robert (Jamie) Munro schrieb:
> 
>> Relationships are designed for grouping things together. Doing nothing 
>> is really option 2 - Dave Stubbs has proved it's possible to extract 
>> the data easily, I'm prepared to write the code to add the 
>> relationships if no one else will.
> 
> Please, please use relations for it and don't delete data entered by
> people. Maybe there is a reason why the node is exactly on that position.

Since there is nothing to stop people MOVING a node later, that argument fails.
The more I think about it, a SIMPLE rule that any uniquely identifiable POI on 
the ground should only have one set of tags becomes more attractive. As long 
as information contained within previous copies of that POI, be they nodes or 
previous instances of the area are maintained, then nothing need be lost.
Any tool that ONLY looks at nodes and ignores areas has a problem anyway, 
since some POI's WILL only be areas?

>> If a renderer doesn't want to use the relationship, they don't have 
>> to. If they need it and it isn't there, we're going to be stuck with
>> double symbols.
> 
> I think using relations is the right way to solve this problem. And of 
> course all cases where something can be expressed by a node and an area 
> at the same time: if there is a display_hint node (or howerver it will 
> be called in the relation) a renderer can use it directly, else it can 
> decide itself where to put the icon.

THAT was the way I was thinking originally, but in the general rule - since 
most POI type data can be defined as node or area - then requiring a second 
node entry for every area is wrong, so providing a fix INCASE an area also has 
a node is also wrong.

-- 
Lester Caine - G8HFL
-----------------------------
Contact - http://home.lsces.co.uk/lsces/wiki/?page=contact
L.S.Caine Electronic Services - http://home.lsces.co.uk
MEDW - http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/
Firebird - http://www.firebirdsql.org/index.php

_______________________________________________
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Reply via email to