On Jul 28, 2011, at 1:48 PM, Mikel Maron wrote: > Hi > > We've run into a unique situation here in Jerusalem, and I wanted some advice > for a recommendation for rendering rules to present to the managers of OSM's > mapnik style sheets > > To resolve a dispute over the name of Jerusalem (in Hebrew, vs Al Quds in > Arabic) the local mapping community decided that two nodes would be placed, > one in the East side of Jerusalem, and the other in the West. They'd pretty > much have the same tagging, except for the default name. Both would be tagged > as capitals. For the rendering, this works fine a high zoom levels, but at > low zoom level, the assumption is that label collision would result in one or > the other unpredictably being rendered. That's unacceptable to all, and the > preference is to show neither at low zoom level (or de-collide them). > > Is it possible to have a collision on a certain class object result in > neither being rendered? I would suggest setting this up for all capitals.
Unfortunately there is no perfect/existing parameter to handle this that I know of. The collision logic right now, as you've noticed, will allow the first capital to be placed based on the order in the postgis table (which does not appear to have an order by applied in the osm.xml). To prevent both objects from being places if neither can "fit" given collision avoidance is definitely something we need and would like to support, but will require a large re-working of label placement to support "multiple passes" (basically a first pass to collect positions and then another pass to render vs the check/render for each feature approach used right now). Hermann Kraus and I have discussed this a bit but there is not a plan of action yet. I realize it is not ideal, but an easy solution would be to allow both capitals to overlap - and this could be done for just these two if needed, by using a <Filter> to match them by name and setting allow-overlap="true". Beyond that I'll continue pondering a more clever solution as I recognize how important this is! Dane _______________________________________________ Mapnik-users mailing list [email protected] https://lists.berlios.de/mailman/listinfo/mapnik-users
