[Tilesathome] Avoiding name duplications on dual carriageways

[Knut Arne Bjørndal]

On Thu, Aug 21, 2008 at 01:34:24AM +0200, Frederik Ramm wrote:
> 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.

Well, to do any kind of collision avoidance you have to take font size
into account, IMHO it's better to put that in some piece of software
that's supposed to handle SVG anyway.

The edit case is an excellent reason for this to be a postprocessor,
it could possibly be run iteratively to help hand-craft a nice map in
between manual edits in inkscape (or whatever).

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

Not that I said "real", not "total". Some things overlap unless the
area is very sparse, and that's just the way it is. Having 5
overlapping parking icons or whatever doesn't look good though.

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

If, in the future, osmarender/xsl and or/p diverges enough in features
and somebody wants some xsl-only features and also collision
avoidance, they might do this.

Heck, I'd probably do that right at the moment to get a better
center-finding algorithm than the simple BBOX thing.

It might even be feasible to plug it into something like
osmarender-frontend by running the perl postprocessor as a server-side
svg, I doubt a reasonably coded perl CGI would take too many
resources.

-- 
Knut Arne Bjørndal
aka Bob Kåre
bob+osm at cakebox.net
bobkare at irc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4167 bytes
Desc: not available
URL: <http://lists.openstreetmap.org/pipermail/tilesathome/attachments/20080821/6b96c294/attachment.bin>