From yves.jacolin at camptocamp.com Mon Jan 5 01:10:36 2026 From: yves.jacolin at camptocamp.com (Yves Jacolin) Date: Mon, 5 Jan 2026 10:10:36 +0100 Subject: [MapServer-users] docker image In-Reply-To: References: Message-ID: Hello, Which MapServer Docker image are you referring to? There is no official image in the MapServer repository. Basemaps are using Docker image from Camptocamp which has not sudo in it. Y. Le mer. 24 d?c. 2025 ? 17:59, Atlanta Geek via MapServer-users < mapserver-users at lists.osgeo.org> a ?crit : > I'm trying to run the latest docker image and get complaints that its > trying to do a sudo command in the docker file. Anyone have the same > issue. Which mapserver docker image is best. Im running on a mac fyi > > -- > http://www.atlantageek.com > _______________________________________________ > MapServer-users mailing list > MapServer-users at lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/mapserver-users > -- Yves Jacolin Training and support manager - Team Manager Camptocamp Tel (France) : +33 4 58 48 20 43 Tel (Switzerland) : +41 21 619 10 43 Mob. : +33 6 18 75 42 21 email : yves.jacolin at camptocamp.com http://www.camptocamp.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From oliver.eberli at bd.zh.ch Tue Jan 6 08:09:05 2026 From: oliver.eberli at bd.zh.ch (oliver.eberli at bd.zh.ch) Date: Tue, 6 Jan 2026 16:09:05 +0000 Subject: [MapServer-users] =?windows-1252?q?OGC_API_=96_Features_Part_3_?= =?windows-1252?q?=28Filtering=29_implementation_status?= Message-ID: Hi all, We would like to offer OGC API Features for our organization and the public. Since we already use MapServer in production, it would be the natural choice to provide this service via MapServer as well. While evaluating the current OGC API Features implementation, we noticed that filtering capabilities as defined in OGC API ? Features Part 3 (Filtering) are not yet implemented. According to the documentation from 2021, the status is still marked as ?not in progress.? (https://www.mapserver.org/development/rfc/ms-rfc-134.html or https://www.mapserver.org/ogc/ogc_api.html#ogcapi) Could you please let us know whether there is any updated roadmap or timeline for the implementation of Part 3 (Filtering) in MapServer? Any information on planned development stages or priorities would be greatly appreciated. Thank you very much for your time and effort. Cheers Oli -------------- next part -------------- An HTML attachment was scrubbed... URL: From public at postholer.com Tue Jan 6 08:32:33 2026 From: public at postholer.com (Scott) Date: Tue, 6 Jan 2026 08:32:33 -0800 Subject: [MapServer-users] =?utf-8?q?OGC_API_=E2=80=93_Features_Part_3_?= =?utf-8?q?=28Filtering=29_implementation_status?= In-Reply-To: References: Message-ID: Hey Oli, What many people do is create a wrapper around the mapserv binary and filter that way. It's flexibility is limited only by your imagination. It's also a great way to perform security on uri's/requests, especially in a public facing environment. Hope that helps! Scott On 1/6/26 08:09, oliver.eberli--- via MapServer-users wrote: > Hi all, > > We would like to offer OGC API Features for our organization and the > public. Since we already use MapServer in production, it would be the > natural choice to provide this service via MapServer as well. > > While evaluating the current OGC API Features implementation, we noticed > that filtering capabilities as defined in OGC API ? Features Part 3 > (Filtering) are not yet implemented. According to the documentation from > 2021, the status is still marked as ?not in progress.? (https:// > www.mapserver.org/development/rfc/ms-rfc-134.html www.mapserver.org/development/rfc/ms-rfc-134.html> or https:// > www.mapserver.org/ogc/ogc_api.html#ogcapi ogc/ogc_api.html#ogcapi>) > > Could you please let us know whether there is any updated roadmap or > timeline for the implementation of Part 3 (Filtering) in MapServer? Any > information on planned development stages or priorities would be greatly > appreciated. > > Thank you very much for your time and effort. > > Cheers > > Oli > > > _______________________________________________ > MapServer-users mailing list > MapServer-users at lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/mapserver-users From justb4 at gmail.com Tue Jan 6 16:52:33 2026 From: justb4 at gmail.com (Just van den Broecke) Date: Wed, 7 Jan 2026 01:52:33 +0100 Subject: [MapServer-users] =?utf-8?q?OGC_API_=E2=80=93_Features_Part_3_?= =?utf-8?q?=28Filtering=29_implementation_status?= In-Reply-To: References: Message-ID: Another workaround: "We are using your open source product for free, in production, but missing feature X. Can we help, like sponsor development?". Just On Tue, Jan 6, 2026, 18:18 Scott via MapServer-users < mapserver-users at lists.osgeo.org> wrote: > Hey Oli, > > What many people do is create a wrapper around the mapserv binary and > filter that way. It's flexibility is limited only by your imagination. > It's also a great way to perform security on uri's/requests, especially > in a public facing environment. > > Hope that helps! > Scott > > On 1/6/26 08:09, oliver.eberli--- via MapServer-users wrote: > > Hi all, > > > > We would like to offer OGC API Features for our organization and the > > public. Since we already use MapServer in production, it would be the > > natural choice to provide this service via MapServer as well. > > > > While evaluating the current OGC API Features implementation, we noticed > > that filtering capabilities as defined in OGC API ? Features Part 3 > > (Filtering) are not yet implemented. According to the documentation from > > 2021, the status is still marked as ?not in progress.? (https:// > > www.mapserver.org/development/rfc/ms-rfc-134.html > www.mapserver.org/development/rfc/ms-rfc-134.html> or https:// > > www.mapserver.org/ogc/ogc_api.html#ogcapi > ogc/ogc_api.html#ogcapi>) > > > > Could you please let us know whether there is any updated roadmap or > > timeline for the implementation of Part 3 (Filtering) in MapServer? Any > > information on planned development stages or priorities would be greatly > > appreciated. > > > > Thank you very much for your time and effort. > > > > Cheers > > > > Oli > > > > > > _______________________________________________ > > MapServer-users mailing list > > MapServer-users at lists.osgeo.org > > https://lists.osgeo.org/mailman/listinfo/mapserver-users > > _______________________________________________ > MapServer-users mailing list > MapServer-users at lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/mapserver-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sethg at geographika.co.uk Wed Jan 7 00:46:46 2026 From: sethg at geographika.co.uk (Seth G) Date: Wed, 07 Jan 2026 09:46:46 +0100 Subject: [MapServer-users] =?utf-8?q?OGC_API_=E2=80=93_Features_Part_3_?= =?utf-8?q?=28Filtering=29_implementation_status?= In-Reply-To: References: Message-ID: Hi Oli, I am unaware of any work being undertaken on this feature. Without funding, or a requirement for this from a core developer, it likely won't be implemented. The most recent work on the OGC Features API (implementation of Part 2 [1]) was written by Spatialys, listed under https://mapserver.org/community/service_providers.html. If any other organisations are interested in the feature, then maybe reply to this thread to combine resources. Seth [1] https://github.com/MapServer/MapServer/pull/6893 -- web:https://geographika.net & https://mapserverstudio.net mastodon: @geographika at mastodon.social On Tue, Jan 6, 2026, at 5:09 PM, oliver.eberli--- via MapServer-users wrote: > Hi all, > > We would like to offer OGC API Features for our organization and the public. Since we already use MapServer in production, it would be the natural choice to provide this service via MapServer as well. > > While evaluating the current OGC API Features implementation, we noticed that filtering capabilities as defined in OGC API ? Features Part 3 (Filtering) are not yet implemented. According to the documentation from 2021, the status is still marked as ?not in progress.? (https://www.mapserver.org/development/rfc/ms-rfc-134.html or https://www.mapserver.org/ogc/ogc_api.html#ogcapi) > > Could you please let us know whether there is any updated roadmap or timeline for the implementation of Part 3 (Filtering) in MapServer? Any information on planned development stages or priorities would be greatly appreciated. > Thank you very much for your time and effort. > > Cheers > Oli > _______________________________________________ > MapServer-users mailing list > MapServer-users at lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/mapserver-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Dierk.Linsenmaier at regiodata-gmbh.de Tue Jan 13 00:29:35 2026 From: Dierk.Linsenmaier at regiodata-gmbh.de (Linsenmaier, Dierk) Date: Tue, 13 Jan 2026 08:29:35 +0000 Subject: [MapServer-users] Issue with line colors in mapserver 8.4.0 In-Reply-To: References: Message-ID: Hello mapserver community, Since we switched from mapserver version 7.6.4 to version 8.4.0, I have an issue with colors in line layers. All dynamic color definitions (color is defined by a variable) are rendered with the same color. No matter if we use RGB- or HEX-Color values. COLOR [VAR] The values for the color variable are defined by an oracle SQL querry. Example SQL: DATA "geom FROM (SELECT id,status,zeitraum, case when Zeitraum in ( 2023) then '166 206 227' when Zeitraum in ( 2024) then '31 120 180' when Zeitraum in ( 2025) then '227 26 28' when Zeitraum in ( 2026) the n '255 127 0' when Zeitraum in ( 2027) then '253 191 111' when Zeitraum in ( 2028,2029,2030) then '251 154 153' when Zeitraum in ( 2031,2032,2033,2034,2035) then '51 160 44' when Zeitraum in ( 2036,2037,2038,2039,2040) then '178 223 138' END as color, geom,'Status: '||STATUS__LL||'
Trassenlänge: '||trassenlaenge||'m' AS banner FROM my_oracle_table WHERE 1=1 ) USING UNIQUE ID SRID 25832 FILTER" CLASS definition: CLASS NAME "CLASS 1" EXPRESSION ("[STATUS]" IN "in_ausfuehrung") STYLE OPACITY 90 OUTLINECOLOR 255 255 255 WIDTH 7 LINECAP butt END#STYLE STYLE OPACITY 100 COLOR [COLOR]#28 22 63 WIDTH 4 LINECAP butt END #STYLE END #CLASS CLASS NAME "CLASS 2" EXPRESSION ("[STATUS]" IN "geplant_genehm_gut") STYLE OPACITY 90 OUTLINECOLOR 255 255 255 WIDTH 7 LINECAP butt END#STYLE STYLE OPACITY 100 PATTERN 12 6 12 6 END COLOR [COLOR]#28 22 63 WIDTH 4 LINECAP butt END #STYLE END #CLASS CLASS NAME "CLASS 3" EXPRESSION ("[STATUS]" IN "geplant_n_genehm") STYLE OPACITY 90 OUTLINECOLOR 255 255 255 WIDTH 7 LINECAP butt END#STYLE STYLE OPACITY 100 PATTERN 12 6 4 6 END COLOR [COLOR]#28 22 63 WIDTH 4 LINECAP butt END #STYLE END #CLASS Is this a know issue or do you have any hint for me to solve it? Mit freundlichen Gr??en Dierk Linsenmaier -- Dierk Linsenmaier Team GIS Informationstechnik regioDATA Tullastr. 61 79108 Freiburg i. Brsg. Telefon 07621 91943-477 Telefax 07621 91943-465 dierk.linsenmaier at regiodata-gmbh.de www.regiodata-gmbh.de regioDATA GmbH Sitz L?rrach, Amtsgericht Freiburg HRB 412719 Gesch?ftsf?hrer: Michael Schade From jukka.rahkonen at maanmittauslaitos.fi Tue Jan 13 00:54:18 2026 From: jukka.rahkonen at maanmittauslaitos.fi (Rahkonen Jukka) Date: Tue, 13 Jan 2026 08:54:18 +0000 Subject: [MapServer-users] Issue with line colors in mapserver 8.4.0 In-Reply-To: References: Message-ID: Hi, What is the color that gets used? Is it some of the ones that you have defined in the CASE query? -Jukka Rahkonen- ________________________________________ L?hett?j?: MapServer-users k?ytt?j?n Linsenmaier, Dierk via MapServer-users puolesta L?hetetty: Tiistai 13. tammikuuta 2026 10.29 Vastaanottaja: mapserver-users at lists.osgeo.org Aihe: [MapServer-users] Issue with line colors in mapserver 8.4.0 Hello mapserver community, Since we switched from mapserver version 7.6.4 to version 8.4.0, I have an issue with colors in line layers. All dynamic color definitions (color is defined by a variable) are rendered with the same color. No matter if we use RGB- or HEX-Color values. COLOR [VAR] The values for the color variable are defined by an oracle SQL querry. Example SQL: DATA "geom FROM (SELECT id,status,zeitraum, case when Zeitraum in ( 2023) then '166 206 227' when Zeitraum in ( 2024) then '31 120 180' when Zeitraum in ( 2025) then '227 26 28' when Zeitraum in ( 2026) the n '255 127 0' when Zeitraum in ( 2027) then '253 191 111' when Zeitraum in ( 2028,2029,2030) then '251 154 153' when Zeitraum in ( 2031,2032,2033,2034,2035) then '51 160 44' when Zeitraum in ( 2036,2037,2038,2039,2040) then '178 223 138' END as color, geom,'Status: '||STATUS__LL||'
Trassenlänge: '||trassenlaenge||'m' AS banner FROM my_oracle_table WHERE 1=1 ) USING UNIQUE ID SRID 25832 FILTER" CLASS definition: CLASS NAME "CLASS 1" EXPRESSION ("[STATUS]" IN "in_ausfuehrung") STYLE OPACITY 90 OUTLINECOLOR 255 255 255 WIDTH 7 LINECAP butt END#STYLE STYLE OPACITY 100 COLOR [COLOR]#28 22 63 WIDTH 4 LINECAP butt END #STYLE END #CLASS CLASS NAME "CLASS 2" EXPRESSION ("[STATUS]" IN "geplant_genehm_gut") STYLE OPACITY 90 OUTLINECOLOR 255 255 255 WIDTH 7 LINECAP butt END#STYLE STYLE OPACITY 100 PATTERN 12 6 12 6 END COLOR [COLOR]#28 22 63 WIDTH 4 LINECAP butt END #STYLE END #CLASS CLASS NAME "CLASS 3" EXPRESSION ("[STATUS]" IN "geplant_n_genehm") STYLE OPACITY 90 OUTLINECOLOR 255 255 255 WIDTH 7 LINECAP butt END#STYLE STYLE OPACITY 100 PATTERN 12 6 4 6 END COLOR [COLOR]#28 22 63 WIDTH 4 LINECAP butt END #STYLE END #CLASS Is this a know issue or do you have any hint for me to solve it? Mit freundlichen Gr??en Dierk Linsenmaier -- Dierk Linsenmaier Team GIS Informationstechnik regioDATA Tullastr. 61 79108 Freiburg i. Brsg. Telefon 07621 91943-477 Telefax 07621 91943-465 dierk.linsenmaier at regiodata-gmbh.de http://www.regiodata-gmbh.de/ regioDATA GmbH Sitz L?rrach, Amtsgericht Freiburg HRB 412719 Gesch?ftsf?hrer: Michael Schade _______________________________________________ MapServer-users mailing list MapServer-users at lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/mapserver-users From sethg at geographika.co.uk Tue Jan 13 03:07:38 2026 From: sethg at geographika.co.uk (Seth G) Date: Tue, 13 Jan 2026 12:07:38 +0100 Subject: [MapServer-users] Issue with line colors in mapserver 8.4.0 In-Reply-To: References: Message-ID: <49848f10-83a4-4cae-84e2-4539e6aaf489@app.fastmail.com> Hi Dierk, Does your use case match the issue at https://github.com/MapServer/MapServer/issues/7167 ? I think adding a new PROCESSING directive to MapServer could be used here to switch between the two different use cases. Seth -- web:https://geographika.net & https://mapserverstudio.net mastodon: @geographika at mastodon.social On Tue, Jan 13, 2026, at 9:29 AM, Linsenmaier, Dierk via MapServer-users wrote: > Hello mapserver community, > > Since we switched from mapserver version 7.6.4 to version 8.4.0, I have > an issue with colors in line layers. > All dynamic color definitions (color is defined by a variable) are > rendered with the same color. No matter if we use RGB- or HEX-Color > values. > COLOR [VAR] > > The values for the color variable are defined by an oracle SQL querry. > > > Example SQL: > DATA "geom FROM (SELECT id,status,zeitraum, case > when Zeitraum in ( 2023) then '166 206 227' when Zeitraum in ( 2024) > then '31 120 180' when Zeitraum in ( 2025) then '227 26 28' when > Zeitraum in ( 2026) the > n '255 127 0' when Zeitraum in ( 2027) then '253 191 111' when Zeitraum > in ( 2028,2029,2030) then '251 154 153' when Zeitraum in ( > 2031,2032,2033,2034,2035) then '51 160 44' when Zeitraum in ( > 2036,2037,2038,2039,2040) then '178 223 138' > END as color, geom,'Status: '||STATUS__LL||'
Trassenlänge: > '||trassenlaenge||'m' AS banner FROM my_oracle_table WHERE 1=1 ) USING > UNIQUE ID SRID 25832 FILTER" > > > CLASS definition: > CLASS > NAME "CLASS 1" > EXPRESSION ("[STATUS]" IN "in_ausfuehrung") > STYLE > OPACITY 90 > OUTLINECOLOR 255 255 255 > WIDTH 7 > LINECAP butt > END#STYLE > STYLE > OPACITY 100 > COLOR [COLOR]#28 22 63 > WIDTH 4 > LINECAP butt > END #STYLE > END #CLASS > CLASS > NAME "CLASS 2" > EXPRESSION ("[STATUS]" IN "geplant_genehm_gut") > STYLE > OPACITY 90 > OUTLINECOLOR 255 255 255 > WIDTH 7 > LINECAP butt > END#STYLE > STYLE > OPACITY 100 > PATTERN 12 6 12 6 END > COLOR [COLOR]#28 22 63 > WIDTH 4 > LINECAP butt > END #STYLE > END #CLASS > > CLASS > NAME "CLASS 3" > EXPRESSION ("[STATUS]" IN "geplant_n_genehm") > STYLE > OPACITY 90 > OUTLINECOLOR 255 255 255 > WIDTH 7 > LINECAP butt > END#STYLE > STYLE > OPACITY 100 > PATTERN 12 6 4 6 END > COLOR [COLOR]#28 22 63 > WIDTH 4 > LINECAP butt > END #STYLE > END #CLASS > > > Is this a know issue or do you have any hint for me to solve it? > > > Mit freundlichen Gr??en > Dierk Linsenmaier > > -- > > Dierk Linsenmaier > > Team GIS > Informationstechnik > > regioDATA > Tullastr. 61 > 79108 Freiburg i. Brsg. > Telefon 07621 91943-477 > Telefax 07621 91943-465 > dierk.linsenmaier at regiodata-gmbh.de > www.regiodata-gmbh.de > > regioDATA GmbH > Sitz L?rrach, Amtsgericht Freiburg HRB 412719 > Gesch?ftsf?hrer: Michael Schade > > _______________________________________________ > MapServer-users mailing list > MapServer-users at lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/mapserver-users From Dierk.Linsenmaier at regiodata-gmbh.de Tue Jan 13 04:11:44 2026 From: Dierk.Linsenmaier at regiodata-gmbh.de (Linsenmaier, Dierk) Date: Tue, 13 Jan 2026 12:11:44 +0000 Subject: [MapServer-users] Issue with line colors in mapserver 8.4.0 In-Reply-To: References: Message-ID: Hi Jukka, it is always one of the colors defined in the query and it differs from request to request. Mit freundlichen Gr??en Dierk Linsenmaier -- Dierk Linsenmaier Team GIS Informationstechnik regioDATA Tullastr. 61 79108 Freiburg i. Brsg. Telefon 07621 91943-477 Telefax 07621 91943-465 dierk.linsenmaier at regiodata-gmbh.de www.regiodata-gmbh.de regioDATA GmbH Sitz L?rrach, Amtsgericht Freiburg HRB 412719 Gesch?ftsf?hrer: Michael Schade -----Urspr?ngliche Nachricht----- Von: Rahkonen Jukka Gesendet: Dienstag, 13. Januar 2026 09:54 An: mapserver-users at lists.osgeo.org; Linsenmaier, Dierk Betreff: Re: Issue with line colors in mapserver 8.4.0 Hi, What is the color that gets used? Is it some of the ones that you have defined in the CASE query? -Jukka Rahkonen- ________________________________________ L?hett?j?: MapServer-users k?ytt?j?n Linsenmaier, Dierk via MapServer-users puolesta L?hetetty: Tiistai 13. tammikuuta 2026 10.29 Vastaanottaja: mapserver-users at lists.osgeo.org Aihe: [MapServer-users] Issue with line colors in mapserver 8.4.0 From Dierk.Linsenmaier at regiodata-gmbh.de Tue Jan 13 04:12:11 2026 From: Dierk.Linsenmaier at regiodata-gmbh.de (Linsenmaier, Dierk) Date: Tue, 13 Jan 2026 12:12:11 +0000 Subject: [MapServer-users] Issue with line colors in mapserver 8.4.0 In-Reply-To: References: <49848f10-83a4-4cae-84e2-4539e6aaf489@app.fastmail.com> Message-ID: Hello Seth, I'm not sure. I found a link to this thread there: https://github.com/MapServer/MapServer/issues/7241 And this seems obviously to be the same problem. I then tried to fix it with this workaround: PROCESSING "RENDERMODE=ALL_MATCHING_CLASSES" In the LAYER section. But it doesn't work for me. Maybe I misunderstood something. Regards Dierk Linsenmaier -- Dierk Linsenmaier Team GIS Informationstechnik regioDATA Tullastr. 61 79108 Freiburg i. Brsg. Telefon 07621 91943-477 Telefax 07621 91943-465 dierk.linsenmaier at regiodata-gmbh.de www.regiodata-gmbh.de regioDATA GmbH Sitz L?rrach, Amtsgericht Freiburg HRB 412719 Gesch?ftsf?hrer: Michael Schade -----Urspr?ngliche Nachricht----- Von: Seth G Gesendet: Dienstag, 13. Januar 2026 12:08 An: Linsenmaier, Dierk ; MapServer Users Betreff: Re: [MapServer-users] Issue with line colors in mapserver 8.4.0 Hi Dierk, Does your use case match the issue at https://github.com/MapServer/MapServer/issues/7167 ? I think adding a new PROCESSING directive to MapServer could be used here to switch between the two different use cases. Seth -- web:https://geographika.net & https://mapserverstudio.net mastodon: @geographika at mastodon.social From philippe.ghesquiere at airbus.com Fri Jan 16 09:35:07 2026 From: philippe.ghesquiere at airbus.com (Philippe Ghesquiere) Date: Fri, 16 Jan 2026 18:35:07 +0100 Subject: [MapServer-users] WCS 2.0 : scaling extension and exceptions Message-ID: Dear all, I am testing WCS 2.0 GetCoverage requests. I have some questions about the following requirements, concerning scaling extension (see OGC 12-039) 1) Req 4 getCoverage-mutually-exclusive A *GetCoverage *request containing a scaling operation *shall *contain exactly one of: - Scal::scaleByFactor, - Scal::scaleAxesByFactor, - Scal::scaleToSize, - and Scal::scaleToExtent If a request contains more than one scaling operator, Mapserver does not complain and takes the first one it checks (see mapwcs20.cpp#L1097 ). Shouldn't it send an exception ? 2) Req 18 getCoverage-exception: When a WCS server encounters an error while evaluating a scaleFactor or scaleExtent parameter in a GetCoverage operation it shall return an exception report message chosen as indicated in Table 7 with a locator parameter value as specified in the right column of Table 7 for each exceptionCode listed. Exception values in table 7 are : InvalidCoverageType, InvalidScaleFactor, InvalidExtent or ScaleAxisUndefined If a request contains a negative value for a scale factor, Mapserver returns an exception : msWCSParseRequest20_XMLGetCoverage(): WCS server error. Invalid scaleFactor '-0.2'. However, the exception type is InvalidParameterValue, which is not in table 7. Why doesn't it report the expected exception type : InvalidScaleFactor ? Sincerely Philippe The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jukka.rahkonen at maanmittauslaitos.fi Tue Jan 20 00:58:29 2026 From: jukka.rahkonen at maanmittauslaitos.fi (Rahkonen Jukka) Date: Tue, 20 Jan 2026 08:58:29 +0000 Subject: [MapServer-users] WCS 2.0 : scaling extension and exceptions In-Reply-To: References: Message-ID: Hi, I think that you are reading the scaling extension standard correctly and a valid GetCoverage request can contain only one of the four alternative scaling operator. What is not clear to me, not by the scaling extension nor by the WCS 2.0.1 core, is what error the server should give in such case. InvalidParameterValue error is defined in OGC Common standard to mean "Operation request contains an invalid parameter value". You are right that the scaling extension defines a more exact error message for invalid scaleFactor. It is wrong on the server side, but if the WCS client follows the OGC Common standard it should still not fail "Because a client may not always know what set of exceptionCode values are being used by a server, all clients should be coded to allow exceptionCode values that it does not recognize." I think I have been running the WCS 2.0 CITE tests https://github.com/opengeospatial/ets-wcs20 with MapServer a few years ago and I believe that some tests were failing. From GitHub I found only this 12 years old ticket, that is resolved https://github.com/MapServer/MapServer/pull/4737. If you want to run the CITE tests and create an issue into GitHub about the failures it would be nice. If your company would appreciate the OGC WCS Compliant tag, we would appreciate all help that you can offer for achieving it. Generally speaking I would say that despite probably not being fully complient, MapServer WCS 2.0 works well for us at the National Land Survey of Finland. -Jukka Rahkonen- ________________________________________ L?hett?j?: MapServer-users k?ytt?j?n Philippe Ghesquiere via MapServer-users puolesta L?hetetty: Perjantai 16. tammikuuta 2026 19.35 Vastaanottaja: MapServer Users Aihe: [MapServer-users] WCS 2.0 : scaling extension and exceptions Dear all,I am testing WCS 2.0 GetCoverage requests.I have some questions about the following requirements, concerning scaling extension (see?OGC 12-039)1) Req 4?getCoverage-mutually-exclusiveA?GetCoverage?request containing a scaling operation?shall?contain exactly one of:Scal::scaleByFactor,Scal::scaleAxesByFactor,Scal::scaleToSize,and?Scal::scaleToExtentIf a request contains more than one scaling operator, Mapserver?does not complain and takes the first one it checks (see mapwcs20.cpp#L1097).Shouldn't it send an exception ?2) Req 18?getCoverage-exception:When a WCS server encounters an error while evaluating a scaleFactor or scaleExtentparameter in a GetCoverage operation it shall return an exception report message chosenas indicated in Table 7 with a locator parameter value as specified in the right columnof Table 7 for each exceptionCode listed.Exception values in table 7 are :?InvalidCoverageType, InvalidScaleFactor, InvalidExtent or ScaleAxisUndefinedIf a request contains a negative value for a scale factor, Mapserver returns an exception :? ?msWCSParseRequest20_XMLGetCoverage(): WCS server error. Invalid scaleFactor '-0.2'.However, the exception type is InvalidParameterValue, which is not in table 7.Why doesn't it report the expected exception type :?InvalidScaleFactor ?SincerelyPhilippeThe information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised.If you are not the intended recipient, please notify Airbus immediately and delete this e-mail.Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately.All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. From philippe.ghesquiere at airbus.com Tue Jan 20 06:41:39 2026 From: philippe.ghesquiere at airbus.com (Philippe Ghesquiere) Date: Tue, 20 Jan 2026 15:41:39 +0100 Subject: [MapServer-users] WCS 2.0 : scaling extension and exceptions In-Reply-To: References: Message-ID: Hi Jukka, Thanks for your comprehensive explanations. I agree that Mapserver is pretty close to be 100% OGC-compliant. My questions are a bit pedantic, because we have requirements for the application we develop to be OGC compliant. Your answers give me solid arguments to defend the fact that Mapserver (and our application) has a correct behaviour. And I will use them with our client :-) As of running the WCS 2.0 CITE tests against our application, I do not know if we can do it easily : it runs on private premises. Thanks for your help Philippe On Tue, Jan 20, 2026 at 9:58?AM Rahkonen Jukka < jukka.rahkonen at maanmittauslaitos.fi> wrote: > Hi, > > I think that you are reading the scaling extension standard correctly and > a valid GetCoverage request can contain only one of the four alternative > scaling operator. What is not clear to me, not by the scaling extension nor > by the WCS 2.0.1 core, is what error the server should give in such case. > > InvalidParameterValue error is defined in OGC Common standard to mean > "Operation request contains an invalid parameter value". You are right that > the scaling extension defines a more exact error message for invalid > scaleFactor. It is wrong on the server side, but if the WCS client follows > the OGC Common standard it should still not fail "Because a client may not > always know what set of exceptionCode values are being used by a server, > all clients should be coded to allow exceptionCode values that it does not > recognize." > > I think I have been running the WCS 2.0 CITE tests > https://github.com/opengeospatial/ets-wcs20 with MapServer a few years > ago and I believe that some tests were failing. From GitHub I found only > this 12 years old ticket, that is resolved > https://github.com/MapServer/MapServer/pull/4737. If you want to run the > CITE tests and create an issue into GitHub about the failures it would be > nice. If your company would appreciate the OGC WCS Compliant tag, we would > appreciate all help that you can offer for achieving it. > > Generally speaking I would say that despite probably not being fully > complient, MapServer WCS 2.0 works well for us at the National Land Survey > of Finland. > > -Jukka Rahkonen- > > ________________________________________ > L?hett?j?: MapServer-users > k?ytt?j?n Philippe Ghesquiere via MapServer-users < > mapserver-users at lists.osgeo.org> puolesta > L?hetetty: Perjantai 16. tammikuuta 2026 19.35 > Vastaanottaja: MapServer Users > Aihe: [MapServer-users] WCS 2.0 : scaling extension and exceptions > > Dear all,I am testing WCS 2.0 GetCoverage requests.I have some questions > about the following requirements, concerning scaling extension (see OGC > 12-039)1) Req 4 getCoverage-mutually-exclusiveA GetCoverage request > containing a scaling operation shall contain exactly one > of:Scal::scaleByFactor,Scal::scaleAxesByFactor,Scal::scaleToSize,and Scal::scaleToExtentIf > a request contains more than one scaling operator, Mapserver does not > complain and takes the first one it checks (see > mapwcs20.cpp#L1097).Shouldn't it send an exception ?2) Req > 18 getCoverage-exception:When a WCS server encounters an error while > evaluating a scaleFactor or scaleExtentparameter in a GetCoverage operation > it shall return an exception report message chosenas indicated in Table 7 > with a locator parameter value as specified in the right columnof Table 7 > for each exceptionCode listed.Exception values in table 7 are > : InvalidCoverageType, InvalidScaleFactor, InvalidExtent or > ScaleAxisUndefinedIf a request contains a negative value for a scale > factor, Mapserver returns an exception : exceptionCode="InvalidParameterValue" locator="request"> > msWCSParseRequest20_XMLGetCoverage(): WCS server error. > Invalid scaleFactor '-0.2'.However, the > exception type is InvalidParameterValue, which is not in table 7.Why > doesn't it report the expected exception type : InvalidScaleFactor > ?SincerelyPhilippeThe information in this e-mail is confidential. The > contents may not be disclosed or used by anyone other than the addressee. > Access to this e-mail by anyone else is unauthorised.If you are not the > intended recipient, please notify Airbus immediately and delete this > e-mail.Airbus cannot accept any responsibility for the accuracy or > completeness of this e-mail as it has been sent over public networks. If > you have any concerns over the content of this message or its Accuracy or > Integrity, please contact Airbus immediately.All outgoing e-mails from > Airbus are checked using regularly updated virus scanning software but you > should take whatever measures you deem to be appropriate to ensure that > this message and any attachments are virus free. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jukka.rahkonen at maanmittauslaitos.fi Tue Jan 20 07:34:36 2026 From: jukka.rahkonen at maanmittauslaitos.fi (Rahkonen Jukka) Date: Tue, 20 Jan 2026 15:34:36 +0000 Subject: [MapServer-users] WCS 2.0 : scaling extension and exceptions In-Reply-To: References: Message-ID: Hi Philippe, I think that the WCS 2.0 standard is probably the best and least ambiguous of all OGC W*S standards. However, the rule about mutually exclusive parameters is somewhat fuzzy. But it is similarly fuzzy in WFS that also has mutually exclusive parameters, but no other advise about what should happen if client sends an invalid request than this: "Only one of a set of mutually exclusive parameters shall be specified in a KVP-encoded request" I fear you are on your own when you decide what error to throw if the client sends &SCALEFACTOR=2.0&SCALEAXES=i(3.5),j(3.5),k(2.0&SCALESIZE=i(1000),j(1000),k(10)&SCALEEXTENT=i(10:20),j(20:30) By the same you can decide what to do for an error that is not covered by the standard &SCALEFACTOR=2.0&SCALEFACTOR=3.0 If you want, you can run the CITE tests also locally with teamengine https://github.com/opengeospatial/teamengine. There are also Docker images but I have not used them. One seems to be here https://hub.docker.com/r/ogccite/teamengine-beta. -Jukka Rahkonen- ________________________________________ L?hett?j?: Philippe Ghesquiere L?hetetty: Tiistai 20. tammikuuta 2026 16.41 Vastaanottaja: Rahkonen Jukka Kopio: MapServer Users Aihe: Re: [MapServer-users] WCS 2.0 : scaling extension and exceptions Hi Jukka,Thanks for your comprehensive?explanations.I agree that Mapserver is pretty close to be 100% OGC-compliant.?My questions are a bit pedantic, because we have requirements for the application we develop to be OGC compliant.?Your answers?give me solid arguments to defend the fact that Mapserver (and our application) has a correct behaviour. And I will use them with our client :-)As of running the WCS 2.0 CITE tests against our application, I do not know?if we can do it easily : it runs on private premises.Thanks for your helpPhilippeOn Tue, Jan 20, 2026 at 9:58?AM Rahkonen Jukka wrote:Hi,I think that you are reading the scaling extension standard correctly and a valid GetCoverage request can contain only one of the four alternative scaling operator. What is not clear to me, not by the scaling extension nor by the WCS 2.0.1 core, is what error the server should give in such case.InvalidParameterValue error is defined in OGC Common standard to mean "Operation request contains an invalid parameter value". You are right that the scaling extension defines a more exact error message for invalid scaleFactor. It is wrong on the server side, but if the WCS client follows the OGC Common standard it should still not fail "Because a client may not always know what set of exceptionCode values are being used by a server, all clients should be coded to allow exceptionCode values that it does not recognize."I think I have been running the WCS 2.0 CITE tests https://github.com/opengeospatial/ets-wcs20 with MapServer a few years ago and I believe that some tests were failing. From GitHub I found only this 12 years old ticket, that is resolved https://github.com/MapServer/MapServer/pull/4737. If you want to run the CITE tests and create an issue into GitHub about the failures it would be nice. If your company would appreciate the OGC WCS Compliant tag, we would appreciate all help that you can offer for achieving it.Generally speaking I would say that despite probably not being fully complient, MapServer WCS 2.0 works well for us at the National Land Survey of Finland.-Jukka Rahkonen-________________________________________L?hett?j?: MapServer-users k?ytt?j?n Philippe Ghesquiere via MapServer-users puolestaL?hetetty: Perjantai 16. tammikuuta 2026 19.35Vastaanottaja: MapServer Users Aihe: [MapServer-users] WCS 2.0 : scaling extension and exceptionsDear all,I am testing WCS 2.0 GetCoverage requests.I have some questions about the following requirements, concerning scaling extension (see?OGC 12-039)1) Req 4?getCoverage-mutually-exclusiveA?GetCoverage?request containing a scaling operation?shall?contain exactly one of:Scal::scaleByFactor,Scal::scaleAxesByFactor,Scal::scaleToSize,and?Scal::scaleToExtentIf a request contains more than one scaling operator, Mapserver?does not complain and takes the first one it checks (see mapwcs20.cpp#L1097).Shouldn't it send an exception ?2) Req 18?getCoverage-exception:When a WCS server encounters an error while evaluating a scaleFactor or scaleExtentparameter in a GetCoverage operation it shall return an exception report message chosenas indicated in Table 7 with a locator parameter value as specified in the right columnof Table 7 for each exceptionCode listed.Exception values in table 7 are :?InvalidCoverageType, InvalidScaleFactor, InvalidExtent or ScaleAxisUndefinedIf a request contains a negative value for a scale factor, Mapserver returns an exception :? ?msWCSParseRequest20_XMLGetCoverage(): WCS server error. Invalid scaleFactor '-0.2'.However, the exception type is InvalidParameterValue, which is not in table 7.Why doesn't it report the expected exception type :?InvalidScaleFactor ?SincerelyPhilippeThe information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised.If you are not the intended recipient, please notify Airbus immediately and delete this e-mail.Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately.All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free.The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised.If you are not the intended recipient, please notify Airbus immediately and delete this e-mail.Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately.All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. From philippe.ghesquiere at airbus.com Tue Jan 20 08:36:01 2026 From: philippe.ghesquiere at airbus.com (Philippe Ghesquiere) Date: Tue, 20 Jan 2026 17:36:01 +0100 Subject: [MapServer-users] WCS 2.0 : scaling extension and exceptions In-Reply-To: References: Message-ID: Hi Jukka, I agree that the requirements are not always clear about how to deal with such errors. Thanks for the pointers to the docker image Philippe On Tue, Jan 20, 2026 at 4:34?PM Rahkonen Jukka < jukka.rahkonen at maanmittauslaitos.fi> wrote: > Hi Philippe, > > I think that the WCS 2.0 standard is probably the best and least ambiguous > of all OGC W*S standards. However, the rule about mutually exclusive > parameters is somewhat fuzzy. But it is similarly fuzzy in WFS that also > has mutually exclusive parameters, but no other advise about what should > happen if client sends an invalid request than this: "Only one of a set of > mutually exclusive parameters shall be specified in a KVP-encoded request" > > I fear you are on your own when you decide what error to throw if the > client sends > > &SCALEFACTOR=2.0&SCALEAXES=i(3.5),j(3.5),k(2.0&SCALESIZE=i(1000),j(1000),k(10)&SCALEEXTENT=i(10:20),j(20:30) > > By the same you can decide what to do for an error that is not covered by > the standard &SCALEFACTOR=2.0&SCALEFACTOR=3.0 > > If you want, you can run the CITE tests also locally with teamengine > https://github.com/opengeospatial/teamengine. There are also Docker > images but I have not used them. One seems to be here > https://hub.docker.com/r/ogccite/teamengine-beta. > > -Jukka Rahkonen- > ________________________________________ > L?hett?j?: Philippe Ghesquiere > L?hetetty: Tiistai 20. tammikuuta 2026 16.41 > Vastaanottaja: Rahkonen Jukka > Kopio: MapServer Users > Aihe: Re: [MapServer-users] WCS 2.0 : scaling extension and exceptions > > Hi Jukka,Thanks for your comprehensive explanations.I agree that Mapserver > is pretty close to be 100% OGC-compliant. My questions are a bit pedantic, > because we have requirements for the application we develop to be OGC > compliant. Your answers give me solid arguments to defend the fact that > Mapserver (and our application) has a correct behaviour. And I will use > them with our client :-)As of running the WCS 2.0 CITE tests against our > application, I do not know if we can do it easily : it runs on private > premises.Thanks for your helpPhilippeOn Tue, Jan 20, 2026 at 9:58?AM > Rahkonen Jukka wrote:Hi,I think > that you are reading the scaling extension standard correctly and a valid > GetCoverage request can contain only one of the four alternative scaling > operator. What is not clear to me, not by the scaling extension nor by the > WCS 2.0.1 core, is what error the server should give in such > case.InvalidParameterValue error is defined in OGC Common standard to mean > "Operation request contains an invalid parameter value". You are right that > the scaling extension defines a more exact error message for invalid > scaleFactor. It is wrong on the server side, but if the WCS client follows > the OGC Common standard it should still not fail "Because a client may not > always know what set of exceptionCode values are being used by a server, > all clients should be coded to allow exceptionCode values that it does not > recognize."I think I have been running the WCS 2.0 CITE tests > https://github.com/opengeospatial/ets-wcs20 with MapServer a few years > ago and I believe that some tests were failing. From GitHub I found only > this 12 years old ticket, that is resolved > https://github.com/MapServer/MapServer/pull/4737. If you want to run the > CITE tests and create an issue into GitHub about the failures it would be > nice. If your company would appreciate the OGC WCS Compliant tag, we would > appreciate all help that you can offer for achieving it.Generally speaking > I would say that despite probably not being fully complient, MapServer WCS > 2.0 works well for us at the National Land Survey of Finland.-Jukka > Rahkonen-________________________________________L?hett?j?: MapServer-users > k?ytt?j?n Philippe Ghesquiere > via MapServer-users puolestaL?hetetty: > Perjantai 16. tammikuuta 2026 19.35Vastaanottaja: MapServer Users < > mapserver-users at lists.osgeo.org>Aihe: [MapServer-users] WCS 2.0 : scaling > extension and exceptionsDear all,I am testing WCS 2.0 GetCoverage > requests.I have some questions about the following requirements, concerning > scaling extension (see OGC 12-039)1) Req > 4 getCoverage-mutually-exclusiveA GetCoverage request containing a scaling > operation shall contain exactly one > of:Scal::scaleByFactor,Scal::scaleAxesByFactor,Scal::scaleToSize,and Scal::scaleToExtentIf > a request contains more than one scaling operator, Mapserver does not > complain and takes the first one it checks (see > mapwcs20.cpp#L1097).Shouldn't it send an exception ?2) Req > 18 getCoverage-exception:When a WCS server encounters an error while > evaluating a scaleFactor or scaleExtentparameter in a GetCoverage operation > it shall return an exception report message chosenas indicated in Table 7 > with a locator parameter value as specified in the right columnof Table 7 > for each exceptionCode listed.Exception values in table 7 are > : InvalidCoverageType, InvalidScaleFactor, InvalidExtent or > ScaleAxisUndefinedIf a request contains a negative value for a scale > factor, Mapserver returns an exception : exceptionCode="InvalidParameterValue" locator="request"> > msWCSParseRequest20_XMLGetCoverage(): WCS server error. > Invalid scaleFactor '-0.2'.However, the > exception type is InvalidParameterValue, which is not in table 7.Why > doesn't it report the expected exception type : InvalidScaleFactor > ?SincerelyPhilippeThe information in this e-mail is confidential. The > contents may not be disclosed or used by anyone other than the addressee. > Access to this e-mail by anyone else is unauthorised.If you are not the > intended recipient, please notify Airbus immediately and delete this > e-mail.Airbus cannot accept any responsibility for the accuracy or > completeness of this e-mail as it has been sent over public networks. If > you have any concerns over the content of this message or its Accuracy or > Integrity, please contact Airbus immediately.All outgoing e-mails from > Airbus are checked using regularly updated virus scanning software but you > should take whatever measures you deem to be appropriate to ensure that > this message and any attachments are virus free.The information in this > e-mail is confidential. The contents may not be disclosed or used by anyone > other than the addressee. Access to this e-mail by anyone else is > unauthorised.If you are not the intended recipient, please notify Airbus > immediately and delete this e-mail.Airbus cannot accept any responsibility > for the accuracy or completeness of this e-mail as it has been sent over > public networks. If you have any concerns over the content of this message > or its Accuracy or Integrity, please contact Airbus immediately.All > outgoing e-mails from Airbus are checked using regularly updated virus > scanning software but you should take whatever measures you deem to be > appropriate to ensure that this message and any attachments are virus free. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. -------------- next part -------------- An HTML attachment was scrubbed... URL: From oliver.eberli at bd.zh.ch Mon Jan 26 05:29:57 2026 From: oliver.eberli at bd.zh.ch (oliver.eberli at bd.zh.ch) Date: Mon, 26 Jan 2026 13:29:57 +0000 Subject: [MapServer-users] =?utf-8?q?OGC_API_=E2=80=93_Features_Part_3_?= =?utf-8?q?=28Filtering=29_implementation_status?= In-Reply-To: References: Message-ID: Hi all, Hi Seth, thank you very much for your replies and the helpful pointers. We are very interested in seeing this feature developed. In that context, I?d also like to understand what kind of budget would typically be required for such an implementation? Could you advise on the appropriate point of contact to discuss potential funding or sponsorship for this work? If other organizations are interested as well, please feel free to join the discussion, we?d be happy to explore combining resources. Thanks again, and best regards, Oli Von: Seth G Gesendet: Mittwoch, 7. Januar 2026 09:47 An: Oliver Eberli ; MapServer Users Betreff: [EXTERN] Re: [MapServer-users] OGC API ? Features Part 3 (Filtering) implementation status Hi Oli, I am unaware of any work being undertaken on this feature. Without funding, or a requirement for this from a core developer, it likely won't be implemented. The most recent work on the OGC Features API (implementation of Part 2 [1]) was written by Spatialys, listed under https://mapserver.org/community/service_providers.html. If any other organisations are interested in the feature, then maybe reply to this thread to combine resources. Seth [1] https://github.com/MapServer/MapServer/pull/6893 -- web:https://geographika.net & https://mapserverstudio.net mastodon: @geographika at mastodon.social On Tue, Jan 6, 2026, at 5:09 PM, oliver.eberli--- via MapServer-users wrote: Hi all, We would like to offer OGC API Features for our organization and the public. Since we already use MapServer in production, it would be the natural choice to provide this service via MapServer as well. While evaluating the current OGC API Features implementation, we noticed that filtering capabilities as defined in OGC API ? Features Part 3 (Filtering) are not yet implemented. According to the documentation from 2021, the status is still marked as ?not in progress.? (https://www.mapserver.org/development/rfc/ms-rfc-134.html or https://www.mapserver.org/ogc/ogc_api.html#ogcapi) Could you please let us know whether there is any updated roadmap or timeline for the implementation of Part 3 (Filtering) in MapServer? Any information on planned development stages or priorities would be greatly appreciated. Thank you very much for your time and effort. Cheers Oli _______________________________________________ MapServer-users mailing list MapServer-users at lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/mapserver-users -------------- next part -------------- An HTML attachment was scrubbed... URL: