<div dir="ltr"><div>Hi Even,</div><div><br></div><div>Thank you for the detailed response, please find my comments inline below:</div><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
<p>(I'd appreciate if RFCs could also be kept proportional (=small)
in length to the change being discussed to remain accessible to
humans that don't use LLMs)</p></div></blockquote><div>That makes sense, I'll follow that policy in the subsequent efforts :-) </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
<p>- I'm wondering if we really need the Cartesian behavior to be
preserved. Does it make sense at all ? if not this could save us
and users from handling an extra configuration parameter. I'd say
if the project has a CRS use the geodetic scale, otherwise
fallback to Cartesian method. </p></div></blockquote>Yes, it makes sense as a product/API simplification, but I would be cautious about removing the configurability entirely. I'm quite afraid of breaking backwards compatibility for a minor release like 8.8. Existing MapServer users may have scalebars in projected CRSs where the current cartesian behavior is expected, visually tested, or intentionally tied to projected coordinates. Switching all projected maps to geodesic by default could change rendered output in a minor-looking but user-visible way. That is especially sensitive for regression tests, printed map workflows etc. I think the geodesic default might be the right long term direction for the next major release, where the backwards compatibility is not so important.<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
<p>- I'm not sure it makes sense to correlate the sample position
with the location of the scale bar. Looking at QGIS scalebar in
layout, it has the following options "average top , middle and
bottom scales", "top of map", "middle of map", "bottom of map",
"always at the equator". We don't necessarily need to offer all
that complexity, so perhaps just middle of the map ?</p></div></blockquote>I can agree with the proposal. For MapServer’s first implementation, center-of-map matches the motivating OpenLayers-style use case (according to <a href="https://github.com/MapServer/MapServer/issues/7397">https://github.com/MapServer/MapServer/issues/7397</a>) and avoids surprising changes when users move the scalebar visually.<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
<p>- the geodesic mode, if taking into account distances along the X
axis, as I see in
<a href="https://github.com/MapServer/MapServer/pull/7507/changes#diff-968c7ca959d226116368f37b62faf245fff8049e3e29fd03ab6914766d61d3d5R238" target="_blank">https://github.com/MapServer/MapServer/pull/7507/changes#diff-968c7ca959d226116368f37b62faf245fff8049e3e29fd03ab6914766d61d3d5R238</a> doesn't
always make sense because the scale, even when mapping locally can
be very different along the horizontal and vertical axis.
Conformal projections (Mercator, Transverse Mercator, LCC, etc.)
have indeed identical scale in both directions, but if you use
let's say Equal Earth that can be very different. Maybe we should
use the geometric average sqrt ( scale_along_x * scale_along_y )
which should yield at least something better if doing area
measurement, which will also often be the Cartesian distance. If
we don't do that, we should be very clear in the documentation
that the value only makes sense in the horizontal direction. </p>
<p>Ex: Equal Earth, 10 km in projected distance along X and Y:</p>
<p>$ echo 0 7700000 | gdaltransform -s_srs +proj=eqearth -t_srs
<a>EPSG:4326</a><br>
0 70.1915580220322 0<br>
$ echo 0 7710000 | gdaltransform -s_srs +proj=eqearth -t_srs
<a>EPSG:4326</a><br>
0 70.3458420298602 0<br>
$ echo 10000 7700000 | gdaltransform -s_srs +proj=eqearth -t_srs
<a>EPSG:4326</a><br>
0.153998673719061 70.1915580220322 0<br>
$ echo 70.1915580220322 0 70.3458420298602 0 | geod -I
+ellps=WGS84<br>
0d -180d 17212.757<br>
$ echo 70.1915580220322 0 70.1915580220322 0.153998673719061 |
geod -I +ellps=WGS84<br>
89d55'39.204" -89d55'39.204" 5826.666</p>
<p>So the 10 km have become 17.2 along X and 5.83 along Y. But
sqrt(17.2 * 5.83) = 10.0 km</p></div></blockquote>This is a reasonable point technically, but it would open up further technical considerations and decision requirements. With the current solution, I just wanted to address the common web mapping use cases, like the Web Mercator/local-map use case where a horizontal scalebar should reflect the real ground distance at the current map location, instead of using distorted projected units. For that purpose, measuring geodesic distance along the scalebar’s horizontal axis is natural, because it keeps the rendered bar literal: its on-screen length corresponds to the ground distance between its left and right endpoints.<br>Using a geometric average of horizontal and vertical scale could be useful as a representative or area-oriented scale, especially for non-conformal projections, but it would no longer describe the actual horizontal length of the scalebar. So if we keep the current approach, we should document clearly that geodesic scalebars represent horizontal distance at the sample point, not vertical distance or general area scale.<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
</div>
</blockquote></div><div class="gmail_quote gmail_quote_container"><br></div><div class="gmail_quote gmail_quote_container">Best regards,</div><div class="gmail_quote gmail_quote_container"><br></div><div class="gmail_quote gmail_quote_container">Tamas</div><div class="gmail_quote gmail_quote_container"><br></div></div>