[Tilesathome] or/p now with proximity filter

80n 80n80n at gmail.com
Tue Aug 5 23:18:12 BST 2008


On Tue, Aug 5, 2008 at 11:07 PM, Frederik Ramm <frederik at remote.org> wrote:

> Hi,
>
>    I have added a proximity filter to or/p that uses the same syntax as
> the original Osmarender.
>
> The logic is a bit different however: or/p simply processes all objects,
> draws those whose "box" is not yet occupied (and marks the box as
> occupied), and ignores the others. This gives good results but the
> choice of labels is different than with Osmarender/XSLT, and probably
> even different if the data changes slightly.
>
> Could someone with a better understanding of Osmarender/XSLT (bobkare?
> 80n?) tell me whether the way it is done XSLT (somehow it seems to
> search for "pairs" of nearby objects and then discard one?) circumvents
> this problem and leads to more stable results?
>

The XSLT algorithm starts by looking for captions that are very close
together and discarding one of them at random.  It then repeats this for a
slightly larger "box".  That way there is a bias towards removing captions
that are very near to each other and leading to an even distribution.

I don't know whether this is more or less stable than your algorithm.  I
suspect any algorithm is going to be highly sensitive to small changes.


>
> My implementation supports an extra parameter called "proximityClass".
> If multiple selection rules share the same value for this optional
> parameter, they use the same "box space", i.e. objects selected by the
> first rule will still be known as "used" by the second rule.
>

Great!  This is a very desirable feature.


> (There's a slight caveat here, in that any object selected by a
> proximity rule is assumed to have "used" its space, even if the object
> should be deselected by a nested selection rule; and also proximity
> filters won't work properly with <else> branches.)
>
> I was thinking that if we added to this a numerical comparison operator
> for tag values, then we could achieve a rendering of largest cities
> first, like so:
>

This would be very nice to have.


>
> <select k="place" v="city">
>    <select k="population" v=">1000000" horizontalProximity="0.6"
> verticalProximity="0.4" proximityClass="caption">
>       ... render ...
>    </select>
>    <select k="population" v=">200000" horizontalProximity="0.6"
> verticalProximity="0.4" proximityClass="caption">
>       ... render ...
>    </select>
>    <select k="population" v="*" horizontalProximity="0.6"
> verticalProximity="0.4" proximityClass="caption">
>       ... render ...
>    </select>
> </select>
>
> But that numerical comparison operator doesn't exist yet, I don't know
> if this would be a good way to do it. Another possibility would be to
> introduce sorted selection results, like so:
>
> <select k="place" v="city" descending_sort="population"
> horizontalProximity="0.6" verticalProximity="0.4">
>       ... render ...
> </select>
>
> Bye
> Frederik
>
> --
> Frederik Ramm  ##  eMail frederik at remote.org  ##  N49°00'09" E008°23'33"
>
> _______________________________________________
> Tilesathome mailing list
> Tilesathome at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/tilesathome
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tilesathome/attachments/20080805/0a62f3fc/attachment.html>


More information about the Tilesathome mailing list