On Thu, Mar 27, 2008 at 10:01 PM, Frederik Ramm <[EMAIL PROTECTED]> wrote:
> Hi, > > I have built a very primitive "collision avoidance" into or/p. It's > not yet in SVN because I wanted to await some feedback, but I'll make > it available in a few days. > > You can see the results (compared with the standard [EMAIL PROTECTED] > slippymap) at > http://openstreetmap.gryph.de/slippymap/. A typical result is > something like this: > > > http://openstreetmap.gryph.de/slippymap/index.html?mt0=orp&mt1=tah&lon=8.4451469&lat=49.0033785&z=15 > > What it does is the following: Whenever it writes a text along a path > (usually that's road names or refs), it stores that in a hash table: > "wrote string <x> along a path that went from node <a> to node <b>" > (where <a> and <b> are the end nodes if the way and are swapped so > that <a> is on the left and <b> on the right). > > Before it writes a text along a path, it checks whether there is an > entry in the hash table for the same text and a path whose end nodes > are within 100 metres of the end nodes of the current path. If yes, it > silently ignores the text instruction. > > This method has many shortcomings, most of all it simply writes the > first text it encounters and ignores the later ones, and because it > only ignores text that's basically on the same path, it is still > possible to have overlapping labels. There's also some potential for > wrongfully weeding out labels that could have been placed without > problem, if you imagine an U shaped way and another way that connects > the two legs of the U, and both had the same labels - the algorithm > would say "start and end node within 100m of each other, so discard > one of the labels". > > However, for the very common case of a dual carriageway or similar > construct inside a city, where both ways in OSM are roughly the same > just a bit displaced, this method nicely avoids the double-printing of > names/refs. > > I am a bit unsure how I should build this into or/p. I could make it > so that you enable/disable the collision avoidance by placing an extra > attribute on the text instruction. That would make it very > controllable but bloat the rules file. Or I could make it a global > config option in or/p so that when you switch it on, it works for all > labels (that's what I did in my test script that generated the demo > slippy map). > > One could also make the "100 metre" setting configurable. And lastly, > the algorithm could of course be widened to not look at the text, i.e. > ignore > *anything* that is written along a way when *anything else* has been > written along a similar way. It could also be changed to better > compare the ways (perhaps take first and last and middle point or so), > or tons of other things. > > Also, I haven't looked too closely at the existing "proximity" code in > Osmarender/XSLT and I don't know if that basically does the same. > The Osmarender proximity code is currently only applicable to nodes. It filters at the <rule> level rather than at the <text> level so it can, potentially, be used to de-clutter symbols and other things, not just place names. The algorithm iterates through all the nodes in the current selection set, and discards any that are closer than the proximity setting to any other node in the selection set. This process is repeated several times starting with small proximity values and increasing them on each iteration, this produces a less biased de-cluttering. I'm not sure whether the same algorithm could be adapted to operate on text on ways. It would need to make some assumptions about where the text is going to appear along the path of the way. 80n > > Bye > Frederik > > -- > Frederik Ramm ## eMail [EMAIL PROTECTED] ## N49°00'09" E008°23'33" > > > _______________________________________________ > Tilesathome mailing list > [email protected] > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/tilesathome >
_______________________________________________ Tilesathome mailing list [email protected] http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/tilesathome
