From szekerest at gmail.com Mon May 11 01:36:36 2026 From: szekerest at gmail.com (Tamas Szekeres) Date: Mon, 11 May 2026 10:36:36 +0200 Subject: [MapServer-dev] MapServer WMS client CRS:84 support Message-ID: Hi Devs, How can I set up a WMS client layer to send CRS:84 to the WMS server? I've tried "wms_srs" "CRS:84" in the LAYER metadata, but I'm getting the following error: msBuildWMSLayerURL(): WMS connection error. Layer must have an EPSG or AUTO projection code (in its PROJECTION object or wms_srs metadata) Best regards, Tamas -------------- next part -------------- An HTML attachment was scrubbed... URL: From sethg at geographika.co.uk Tue May 12 11:02:52 2026 From: sethg at geographika.co.uk (Seth G) Date: Tue, 12 May 2026 20:02:52 +0200 Subject: [MapServer-dev] MapServer WMS client CRS:84 support In-Reply-To: References: Message-ID: Hi Tamas, Having gone through the projection code recently I doubt this format is supported. Could you use PROJECTION "epsg:4326 END on the layer and then hard code the projection string? CONNECTIONTYPE WMS CONNECTION "https://demo.org/cgi-bin/wms?VERSION=1.1.0&LAYERS=bm&FORMAT=image/png&SRS=CRS:84" Seth -- web:https://geographika.net & https://mapserverstudio.net mastodon: @geographika at mastodon.social On Mon, May 11, 2026, at 10:36 AM, Tamas Szekeres via MapServer-dev wrote: > Hi Devs, > > How can I set up a WMS client layer to send CRS:84 to the WMS server? > I've tried "wms_srs" "CRS:84" in the LAYER metadata, but I'm getting the following error: > > msBuildWMSLayerURL(): WMS connection error. Layer must have an EPSG or AUTO projection code (in its PROJECTION object or wms_srs metadata) > > Best regards, > > Tamas > > _______________________________________________ > MapServer-dev mailing list > MapServer-dev at lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/mapserver-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From szekerest at gmail.com Sat May 16 10:38:59 2026 From: szekerest at gmail.com (Tamas Szekeres) Date: Sat, 16 May 2026 19:38:59 +0200 Subject: [MapServer-dev] Call for review: RFC-142: Scalebar Measurement Modes Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From even.rouault at spatialys.com Sat May 16 15:25:56 2026 From: even.rouault at spatialys.com (Even Rouault) Date: Sun, 17 May 2026 00:25:56 +0200 Subject: [MapServer-dev] Call for review: RFC-142: Scalebar Measurement Modes In-Reply-To: References: Message-ID: 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: From sethg at geographika.co.uk Sun May 17 04:18:38 2026 From: sethg at geographika.co.uk (Seth G) Date: Sun, 17 May 2026 13:18:38 +0200 Subject: [MapServer-dev] Call for review: RFC-142: Scalebar Measurement Modes In-Reply-To: References: Message-ID: <0b0ec0c5-0407-467d-8b9c-d61eb994de2e@app.fastmail.com> Hi Tamas, Thanks for the RFC and implementation. 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? 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. 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. Seth -- web:https://geographika.net & https://mapserverstudio.net mastodon: @geographika at mastodon.social On Sun, May 17, 2026, at 12:25 AM, Even Rouault via MapServer-dev wrote: > 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. > _______________________________________________ > MapServer-dev mailing list > MapServer-dev at lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/mapserver-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From szekerest at gmail.com Sun May 17 04:32:12 2026 From: szekerest at gmail.com (Tamas Szekeres) Date: Sun, 17 May 2026 13:32:12 +0200 Subject: [MapServer-dev] Call for review: RFC-142: Scalebar Measurement Modes In-Reply-To: References: Message-ID: Hi Even, Thank you for the detailed response, please find my comments inline below: (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) > That makes sense, I'll follow that policy in the subsequent efforts :-) > - 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. > 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. > - 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 ? > I can agree with the proposal. For MapServer?s first implementation, center-of-map matches the motivating OpenLayers-style use case (according to https://github.com/MapServer/MapServer/issues/7397) and avoids surprising changes when users move the scalebar visually. > > - 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 > 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. 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. > > Best regards, Tamas -------------- next part -------------- An HTML attachment was scrubbed... URL: From szekerest at gmail.com Sun May 17 04:48:38 2026 From: szekerest at gmail.com (Tamas Szekeres) Date: Sun, 17 May 2026 13:48:38 +0200 Subject: [MapServer-dev] Call for review: RFC-142: Scalebar Measurement Modes In-Reply-To: <0b0ec0c5-0407-467d-8b9c-d61eb994de2e@app.fastmail.com> References: <0b0ec0c5-0407-467d-8b9c-d61eb994de2e@app.fastmail.com> Message-ID: Hi Seth, Thank you for the feedback, see my comments inline: > 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? > > Geodesic measurement is likely the better default for most projected maps intended to show real-world ground distance, especially EPSG:3857. However, preserving cartesian measurement gives users a deterministic legacy-compatible option where the scalebar represents map units directly and remains stable across requests. This is useful for existing applications, tests, cached map output, or workflows where projected coordinates rather than ellipsoidal ground distance are the intended reference. > 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. > > The added cost should be negligible for normal embedded scalebars. A geodesic scalebar currently adds two coordinate transformations and one proj_geod() call per scalebar fitting iteration, usually only one or a few iterations per rendered map. This is tiny compared with a full map render, although we can mention that pathological scalebar-only or repeated-render benchmarks may show a measurable difference. > 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. > > I agree with this standpoint and adjust the RFC/implementation accordingly: geodesic mode should sample at the map center, while POSITION/OFFSET should remain purely visual layout controls. Best regards, Tamas -------------- next part -------------- An HTML attachment was scrubbed... URL: From sethg at geographika.co.uk Mon May 18 03:54:26 2026 From: sethg at geographika.co.uk (Seth G) Date: Mon, 18 May 2026 12:54:26 +0200 Subject: [MapServer-dev] Call for review: RFC-142: Scalebar Measurement Modes In-Reply-To: References: <0b0ec0c5-0407-467d-8b9c-d61eb994de2e@app.fastmail.com> Message-ID: <9d41e081-995f-42e3-9458-78d6bec066b0@app.fastmail.com> Hi Tamas, OK noted re-backwards compatibility and stability between requests - seems safest to make this a new keyword / option. If the performance cost is negligible then a user can pick whichever approach is most suitable without worrying about performance (which is good!). Middle-of the map seems the cleanest approach. Thanks for addressing my questions (and a pre-emptive +1 from me), Seth -- web:https://geographika.net & https://mapserverstudio.net mastodon: @geographika at mastodon.social On Sun, May 17, 2026, at 1:48 PM, Tamas Szekeres wrote: > Hi Seth, > > Thank you for the feedback, see my comments inline: > >> >> 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? >> > > Geodesic measurement is likely the better default for most projected maps intended to show real-world ground distance, especially EPSG:3857. However, preserving cartesian measurement gives users a deterministic legacy-compatible option where the scalebar represents map units directly and remains stable across requests. This is useful for existing applications, tests, cached map output, or workflows where projected coordinates rather than ellipsoidal ground distance are the intended reference. > >> >> 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. >> > > The added cost should be negligible for normal embedded scalebars. A geodesic scalebar currently adds two coordinate transformations and one proj_geod() call per scalebar fitting iteration, usually only one or a few iterations per rendered map. This is tiny compared with a full map render, although we can mention that pathological scalebar-only or repeated-render benchmarks may show a measurable difference. > >> >> 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. >> > > I agree with this standpoint and adjust the RFC/implementation accordingly: geodesic mode should sample at the map center, while POSITION/OFFSET should remain purely visual layout controls. > > Best regards, > > Tamas > -------------- next part -------------- An HTML attachment was scrubbed... URL: