[OSM-dev] possible changes to osmarender.xsl
80n80n at gmail.com
Sat Sep 29 17:24:40 BST 2007
On 9/29/07, Mark Huizer <xaa+openstreetmap at dohd.org> wrote:
> 80n wrote:
> > DVC! Cool.
> Hmm, my 5 minute googling for DVC was not really successful, but I'll
> assume it's good :-)
DVC = divide-and-conquer which is a name often used for the algorithm you
have implemented. See:
> I was adviced to see if the osmarender 5 code had already fixed this or
> might need this as well. Maybe you can tell?
It would be applicable to Osmarender 5. I assumed you were working on the
Osmarender 5 code base. I'm not maintaining any of the previous versions.
As far as getPathLength is concerned, I have two questions
> a. the calculation there seems wrong to me, but it could be on purpose
> since the real calculation might be hard with xsl's math inabilities. it's
> * totLat = (sum of absolute lat difference per segment)
> * totLon = (sum of absolute lon difference per segment)
> * totalLength^2 = totLat^2+totLon^2
> A simple example shows that that is wrong: take a way of segments with
> coordinates (0,0),(3,4),(7,7). The length can easily be seen (3-4-5
> triangles to the rescue :-) ) 10, but osmarender will result in sqrt(98),
> which makes the road slightly shorter. Could be on purpose since
> getPathLength will probably always be less than the real length.
It's just an approximation. The calculation of the text length is equally
approximate. The end result works well enough to be useful. If you can
devise a more accurate algorithm then it wouldn't do any harm, but would
probably not make much of a noticeable difference.
b. I'm trying to also make this recursion treeshaped, instead of using tail
> recursion so the depth is less, but I don't see a way to return 2 values
> from a call-template call. Any hints?
It might be better to take a different approach. Calculate the length of
the text first and then walk the segments until the enough length has been
processed and then stop. If you also build in a back-stop of, say, 200
iterations then the stack problem would also be avoided.
This would be much quicker than measuring the full length of every path and
then doing the comparison.
> dev mailing list
> dev at openstreetmap.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the dev