<br><br><div><span class="gmail_quote">On 9/29/07, <b class="gmail_sendername">Mark Huizer</b> <<a href="mailto:xaa+openstreetmap@dohd.org">xaa+openstreetmap@dohd.org</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
80n wrote:<br>> DVC!  Cool.<br><br><br>Hmm, my 5 minute googling for DVC was not really successful, but I'll assume it's good :-)</blockquote><div><br>DVC = divide-and-conquer which is a name often used for the algorithm you have implemented.  See: 
<a href="http://www.topxml.com/snippetcentral/main.asp?view=viewsnippet&lang=codelib&id=v20020107050418">http://www.topxml.com/snippetcentral/main.asp?view=viewsnippet&lang=codelib&id=v20020107050418</a><br>
<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I was adviced to see if the osmarender 5 code had already fixed this or might need this as well. Maybe you can tell?
</blockquote><div><br>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.<br> </div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
As far as getPathLength is concerned, I have two questions<br><br>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 calculated:
<br><br>  * totLat = (sum of absolute lat difference per segment)<br>  * totLon = (sum of absolute lon difference per segment)<br>  * totalLength^2 = totLat^2+totLon^2<br><br>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.
</blockquote><div><br>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.
<br><br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">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?
</blockquote><div><br>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.
<br><br>This would be much quicker than measuring the full length of every path and then doing the comparison.<br> </div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Mark<br><br>_______________________________________________<br>dev mailing list<br><a href="mailto:dev@openstreetmap.org">dev@openstreetmap.org</a><br><a href="http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev">
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev</a><br></blockquote></div><br>