[OSM-talk] Parking symbols: YUCK!

[Lester Caine]

Andy Allan wrote:
> Now I say this as an illustration of what each renderer does - they
> make their own decisions as to what to do. I don't even understand why
> you want consistency in the outputs - the main osmarender and mapnik
> layers are different, and much of it just comes down to cartographic
> style.

And there is nothing to distinguish between duplicate items contained in the 
underlying data. RENDERING is not the only use for the data but the problem of 
duplicate icons highlights the underlying problem - AND IT IS A PROBLEM !!!

> As to the specifics of how mapnik works, see osm2pgsql's
> "add_parking_node()" at
> http://trac.openstreetmap.org/browser/applications/utils/export/osm2pgsql/output-pgsql.c#L362
> for the code to auto-add a parking node. On the main map it has
> parking as non-overlapping as per
> http://trac.openstreetmap.org/browser/applications/rendering/mapnik/osm.xml#L154
> so the duplicate icon issue is "solved" by this overlap avoidance.

BUT that only works for 'parking' - add every other node/area duplicate 
problem! Add situations where there is no overlap avoidance such as actually 
processing the data .... someone is going to code each case individually?

> And if you think this is particularly onerous for the renderers to
> deal with, then you're probably unaware of how much other stuff needs
> to be taken care of too!

I KNOW the problem of dealing with the CURRENT data - in many cases it is 
unusable for anything OTHER than rendering and needs the sort of bodge being 
discussed to sort out the mess. Some people not be bothered by that problem, 
because they only want a simple map output, but 90% of the tagging information 
will allow us to search for WHICH area of the map to display. Having in 
essence to 'render' areas to find out if nodes are contained in them and then 
guess if a node IS a duplicate is not practical as the size of the DATA grows. 
I'm looking at some 50 other tags that may have node/area duplicates - 
personally how they are rendered does not bother me at all - I want to be able 
to navigate the data and produce CONSISTENT search results - which are then 
used to DISPLAY the correct area of a map or simply offer alternatives to 
select from.

A very simple fix for this problem is to display everything on the basis that 
the node IS different to the area. The renderers can worry about icons on top 
of one another - be they duplicate parking icons or school, public building or 
whatever. We then TIDY things up by the convention that there is only one 
entry for a tagged POI and if an existing node is upgraded to an area, then 
the node information becomes part of the area tags, and the node is deleted. 
No need for reams of processing and new bodge code for every node/area tag 
conflict?

We then don't have to worry about duplicates - they don't exist. If they do, 
then one or other needs to be merged to leave a single distinct entry?

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