On Tue, Aug 5, 2008 at 11:07 PM, Frederik Ramm <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] ## N49°00'09" E008°23'33" > > _______________________________________________ > Tilesathome mailing list > [email protected] > http://lists.openstreetmap.org/listinfo/tilesathome >
_______________________________________________ Tilesathome mailing list [email protected] http://lists.openstreetmap.org/listinfo/tilesathome
