<!DOCTYPE html><html><head><title></title></head><body><div>Hi Tamas,</div><div><br></div><div>Thanks for the RFC and implementation. </div><div><br></div><div>I'd agree with Even's point that using the "geodesic" approach for any projected map would make sense - or is there a situation where you'd want a Cartesiam scalebar drawn? Maybe to have consistency between requests?</div><div><br></div><div>I guess the new approach could slow down the generation of the scalebar, but as embedded scalebars are part of full Map requests (and not WFS etc.), it wouldn't affect most uses of MapServer. </div><div><br></div><div>Using the middle of the map for the scale seems the simplest option. If a user renders a world-wide Web Mercator map, and the scalebar is in the top-left of the map, then using pixels at this location would create a scalebar based on pixels with high latitudes and a 100 KM scalebar could represent 50 KM on the ground. Using the map center would produce a scalebar, only accurate at the equator, but at least consistent with the current implementation.</div><div><br></div><div>Seth</div><div><br></div><div id="sig62266145"><div class="signature">--</div><div class="signature">web:<a href="https://geographika.net">https://geographika.net</a> & <a href="https://mapserverstudio.net">https://mapserverstudio.net</a></div><div class="signature">mastodon: @<a href="mailto:geographika@mastodon.social">geographika@mastodon.social</a></div></div><div><br></div><div>On Sun, May 17, 2026, at 12:25 AM, Even Rouault via MapServer-dev wrote:</div><blockquote type="cite" id="qt" style=""><p>Tamas,</p><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><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><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><p>- the geodesic mode, if taking into account distances along the X
axis, as I see in <a class="qt-moz-txt-link-freetext" href="https://github.com/MapServer/MapServer/pull/7507/changes#diff-968c7ca959d226116368f37b62faf245fff8049e3e29fd03ab6914766d61d3d5R238">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 class="qt-moz-txt-link-freetext" href="EPSG:4326">EPSG:4326</a><br> 0 70.1915580220322 0<br> $ echo 0 7710000 | gdaltransform -s_srs +proj=eqearth -t_srs <a class="qt-moz-txt-link-freetext" href="EPSG:4326">EPSG:4326</a><br> 0 70.3458420298602 0<br> $ echo 10000 7700000 | gdaltransform -s_srs +proj=eqearth -t_srs <a class="qt-moz-txt-link-freetext" href="EPSG:4326">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><p>Even</p><div class="qt-moz-cite-prefix">Le 16/05/2026 à 19:38, Tamas Szekeres
via MapServer-dev a écrit :</div><blockquote type="cite" cite="mid:CACALY+QcCBfPF2C1dTStigDcCZ1_1XxTV1X6O=txpvMy9sk_Kg@mail.gmail.com"><div dir="ltr"><div><span style="color:rgb(0, 0, 0);">Hi Devs,</span></div><div> <br></div><div> <span style="color:rgb(0, 0, 0);">I've prepared an RFC to </span>add
explicit measurement modes to the MapServer</div><div> SCALEBAR object. The goal is to preserve the current Cartesian
scalebar</div><div> behavior by default while allowing users to request local
geodesic ground</div><div> distance measurement for projections where projected map units
are not equal to ground distance.</div><div> The main motivating case is Web Mercator / <a class="qt-moz-txt-link-freetext" href="EPSG:3857">EPSG:3857</a>. In that
projection, coordinates are expressed in meters, but projected
meters increasingly differ from local ground meters away from
the equator. The current scalebar implementation treats
projected coordinate units as a flat Cartesian plane, so metric
scalebars can overstate local ground distance in <a class="qt-moz-txt-link-freetext" href="EPSG:3857">EPSG:3857</a> and
similar projections.</div><div><br></div><div><div><div><span style="color:rgb(0, 0, 0);">Links:</span></div><div> <br></div><div> <span style="color:rgb(0, 0, 0);">- RFC text: </span><a href="https://mapserver.org/development/rfc/ms-rfc-142.html" class="qt-moz-txt-link-freetext">https://mapserver.org/development/rfc/ms-rfc-142.html</a></div><div> <br></div><div> <span style="color:rgb(0, 0, 0);">- Candidate implementation: </span><a href="https://github.com/MapServer/MapServer/pull/7507" class="qt-moz-txt-link-freetext">https://github.com/MapServer/MapServer/pull/7507</a><span class="color" style="color:rgb(136, 136, 136);"><br> </span></div><div> - Issue targeted: <a href="https://github.com/MapServer/MapServer/issues/7397" class="qt-moz-txt-link-freetext">https://github.com/MapServer/MapServer/issues/7397</a></div><div> <br></div><div> Tamas</div></div></div></div><div><br></div><pre class="qt-moz-quote-pre">_______________________________________________
MapServer-dev mailing list
<a class="qt-moz-txt-link-abbreviated" href="mailto:MapServer-dev@lists.osgeo.org">MapServer-dev@lists.osgeo.org</a>
<a class="qt-moz-txt-link-freetext" href="https://lists.osgeo.org/mailman/listinfo/mapserver-dev">https://lists.osgeo.org/mailman/listinfo/mapserver-dev</a>
</pre></blockquote><div class="qt-moz-signature"><div>-- </div><div> <a class="qt-moz-txt-link-freetext" href="http://www.spatialys.com">http://www.spatialys.com</a> My software is free, but my time generally not.</div></div><div>_______________________________________________</div><div>MapServer-dev mailing list</div><div><a href="mailto:MapServer-dev@lists.osgeo.org">MapServer-dev@lists.osgeo.org</a></div><div><a href="https://lists.osgeo.org/mailman/listinfo/mapserver-dev">https://lists.osgeo.org/mailman/listinfo/mapserver-dev</a></div><div><br></div></blockquote><div><br></div></body></html>