On 28-5-2010 14:55, numenor wrote:
Maybe the SQL extension function 'ST_PointOnSurface' can help you (at
least as a workaround), if you use PostGIS as data source. For a given
surface, this function returns a point which is guaranteed to lie on the
surface. It does not guarantee any more, but with PostGIS, for me for
convex shapes the labels appear similarly placed as when using ST_Centroid
(or mapnik's algorithm), more or less in the middle.
Sure, this works, but then again, as you say, only with data from PostGIS.
The other thing: don't try it with OSM data. You'll receive a very nasty
stream of invalid geometry warnings from geos and a hefty slowdown in
rendering while this is going on.
Is this problem solvable at all, in general? What if the outer polygon is
completely covered by smaller polygons?
Sort by size, label the biggest ones first? That won't make the label
for the smaller polygon appear, but it does make it more predictable
which one will show.
What's needed is a method of specifying alternate placements, when a
label is dropped due to a collision with a previous label. Part of the
alternate placement options could be a list of offsets to try
(n,s,e,w,nw,sw,ne,se for instance) and a percentage or pixel amount that
the label may be moved from the original placement, and whether a
polygon label may be placed outside the actual polygon, and if so, by
how much.
If you know which smaller polygons lie inside the bigger one, you could
subtract their area from the bigger one, and then use ST_PointOnSurface on
the result to get the point for placement of the label. This might of
course be computationally expensive ...
That's an interesting notion. You're right about the cost, but not every
map needs to render in a second.
--
Lennard
_______________________________________________
Mapnik-users mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/mapnik-users
