[Tilesathome] lowzoom

[80n]

On Thu, Jul 31, 2008 at 8:45 AM, Frederik Ramm <frederik at remote.org> wrote:

> Hi,
>
> > On the negative side: either the captions are done with XSLT osmarender
> which has projection issues in lowzoom (see how city names get moved in z6)
> or we use or/p which gets projection right but cannot suppress text labels
> when there are too many. Both issues are something that a potential
> developer could/should have a look at.
>
> I'm very much willing to build overlap detection into or/p. However I'm
> unsure whether the method choosen by 80n for Osmarender/XSLT is really
> the way to go. As far as I can see, it does not take projection into
> account and will thus yield a different object spacing on different
> latitudes. Has it given good results in practice? Then I'll just copy
> his algorithm and be done with it. (Or even better, someone else could ;-)
>

The method I used was very primitive.

For each caption suppress it if there would be another caption within a
given rectangular distance.

The result was generally an improvement over no suppression at all, which to
me meant it was Good Enough (tm) to be worth deploying.  However I don't
think it is the perfect solution and I expect there are other approaches
that would yield better results.


> The algorithm also seems to allow proximity spacing only within one
> rule, i.e. it would not be possible to, say, first add all city captions
> and then add towns if there is still room or so.
>

This is definitely an area that needs some work.  Particularly if you want
to declutter at high zoom levels where you have lots of different things
(pubs, restaurants, ATMs, post boxes, etc) all competing for the same
space.  The main problem here is how to express what you want to achieve
within the current structure of a rules file.


> The way you'd normally do this is simply place the text, record the
> bounding box, and before placing any other text, check whether it
> overlaps with an existing bbox. (Really good software would, on
> detecting an overlap, probably try to move the text around a bit to fit
> it in.) You would make sure to sort your objects in descending order of
> importance, so you drop the less important objects near the important ones.
>
> The problem with this approach is that you can only make rough guesses
> at how many pixels wide and high a certain text will be, because you
> don't have access to proper font metrics at this point in processing. It
> is only at a later stage, during SVG rendering, that the font name is
> resolved and the font selected. I don't know if the SVG JavaScript
> support is so exhaustive that you could actually do this in SVG-embedded
> JavaScript but anyway I wouldn't want to go there.
>
> 80n's current approach solves this by making sure that the centre points
> of labels are spaced a minimum distance apart; it doesn't look at the
> extents of a label. Probably a reasonable workaround?
>

It works suprisingly well.  A refinement would be to adjust the distance by
some factor relating to the length of the caption.  Although you don't know
the exact size the caption will be when it is rendered, you can choose
conservative values that will only fail for pathological cases.

80n


>
> Also,
>

As well,


>
> Bye
> Frederik
>
> _______________________________________________
> Tilesathome mailing list
> Tilesathome at openstreetmap.org
> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/tilesathome
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tilesathome/attachments/20080731/9d90b445/attachment.html>