[OSM-talk] Parking symbols: YUCK!

Lester Caine lester at lsces.co.uk
Sun Feb 24 12:07:42 GMT 2008


Christoph Eckert wrote:
>> Maybe that person is using the data 
>> from the DB to keep a POI record of parking lots.
> 
> I do POIs and my tool currently only can do nodes. If parking lots are 
> replaced by areas, I need to fix my tool.

This is the point I am at as well!

We need to be consistent in the way POI's, what ever they are, are identified, 
and a node is currently easier to tabulate than an area. So perhaps we REQUIRE 
a node attached to every area which has the tag information. Ignoring the 
rendering inconsistencies and just looking at the raw data, how do we produce 
a list of 'parking lots' or any other area/node defined data.

In order to fix POI type tools we end up having to process graphical data when 
a simple set of rules could remove the problem? I keep coming back to the 
is_in problem and this is just another example of it. WHEN an area is created 
and the original node is_in it then an automatic is_in with a unique 
identifier could be created which flags that there is an area that superceds 
the node. We can then simply read the data and when we find nodes with area 
is_in tags we can simply ignore them if appropriate leaving just the area POI 
tags.

PERSONALLY I would like to be able to process the raw data without having to 
ALSO carry out complex area checks every time I find an 'area'. If we need to 
maintain matching nodes to go with that area, then there should be some 
flagging to at least indicate that there is an alternative. David's 
'parking:redundant' could better be tagged 'parking:see_area' although I will 
keep hammering the simple concept of a unique is_in identifier so we get 
'parking:is_in:<element_id>'. A concept that will tidy ALL of the area/data 
information tree. I know this is not liked by the XML purists, but being able 
to jump directly to related data will always speed up data mapping?

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




More information about the talk mailing list