[MapServer-dev] Call for review: RFC-142: Scalebar Measurement Modes

Even Rouault even.rouault at spatialys.com
Sat May 16 15:25:56 PDT 2026


Tamas,

(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)

- 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.

- 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 ?

- the geodesic mode, if taking into account distances along the X axis, 
as I see in 
https://github.com/MapServer/MapServer/pull/7507/changes#diff-968c7ca959d226116368f37b62faf245fff8049e3e29fd03ab6914766d61d3d5R238 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.

Ex: Equal Earth, 10 km in projected distance along X and Y:

$ echo  0 7700000 | gdaltransform  -s_srs +proj=eqearth  -t_srs EPSG:4326
0 70.1915580220322 0
$ echo  0 7710000 | gdaltransform -s_srs +proj=eqearth  -t_srs EPSG:4326
0 70.3458420298602 0
$ echo 10000 7700000 | gdaltransform -s_srs +proj=eqearth  -t_srs EPSG:4326
0.153998673719061 70.1915580220322 0
$ echo 70.1915580220322 0 70.3458420298602 0 | geod -I +ellps=WGS84
0d    -180d    17212.757
$ echo 70.1915580220322 0 70.1915580220322 0.153998673719061  | geod -I 
+ellps=WGS84
89d55'39.204"    -89d55'39.204"    5826.666

So the 10 km have become 17.2 along X and 5.83 along Y.    But sqrt(17.2 
* 5.83) = 10.0 km

Even

Le 16/05/2026 à 19:38, Tamas Szekeres via MapServer-dev a écrit :
> Hi Devs,
>
> I've prepared an RFC to add explicit measurement modes to the MapServer
> SCALEBAR object. The goal is to preserve the current Cartesian scalebar
> behavior by default while allowing users to request local geodesic ground
> distance measurement for projections where projected map units are not 
> equal to ground distance.
> The main motivating case is Web Mercator / EPSG:3857. 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 EPSG:3857 and similar projections.
>
> Links:
>
> - RFC text: https://mapserver.org/development/rfc/ms-rfc-142.html
>
> - Candidate implementation: 
> https://github.com/MapServer/MapServer/pull/7507
>
> - Issue targeted: https://github.com/MapServer/MapServer/issues/7397
>
> Tamas
>
> _______________________________________________
> MapServer-dev mailing list
> MapServer-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/mapserver-dev
-- 
http://www.spatialys.com My software is free, but my time generally not.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mapserver-dev/attachments/20260517/b2fbc53b/attachment-0001.htm>


More information about the MapServer-dev mailing list