Hi, Knut Arne Bjørndal wrote: > I've been thinking we may want to do real collision avoidance, or at > least put what effort we spend on it into something that may one day > do it properly.
> I think it makes sense to do that as a post-processor, yes it will > have to handle some stuff like labels that are drawn in two rounds > (core&casing-like), but that shouldn't be /too/ hard. This will allow > it to be used where it's feasible to run perl (or whatever it ends up > being written in), and it will be a reasonably separate component. I think it's a bit ugly to make assumptions about font sizes. The SVG renderer is the one who decides how big a certain letter will be, depending on available fonts; even after we have generated our SVG output, the user could still fiddle with the font sizes in his editor. I view this as an advantage compared to the Mapnik-Cairo-SVG output which has all fonts rendered as paths and thus completely unchangeable. Also, I don't even like total collision avoidance (like in Mapnik where it tends to drop the name of a road because there's a pub there or the other way round). If anything, it would have to be finely controllable (even "professional" maps allow text overlaps if the font sizes/colors are different enough for the eye to follow one or the other). > Real collision avoidance in XSLT will probably never happen, and I'd > love for this to be available to osmarender/xsl output as well. Mmh... on a platform where Perl is readily available, one could just use or/p. And on a platform where one doesn't have Perl, a collision avoidance postprocessor written in Perl will not be of any use? Bye Frederik -- Frederik Ramm ## eMail [EMAIL PROTECTED] ## N49°00'09" E008°23'33" _______________________________________________ Tilesathome mailing list [email protected] http://lists.openstreetmap.org/listinfo/tilesathome
