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 _______________________________________________ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk