From sethg at geographika.co.uk Sun May 2 02:32:40 2021 From: sethg at geographika.co.uk (Seth G) Date: Sun, 02 May 2021 11:32:40 +0200 Subject: [mapserver-users] Mapfile syntax changes and XML support Message-ID: Hi all, The MS RFC 133: Mapfile Syntax Cleanup [1] proposes the removal of a number of deprecated Mapfile keywords. Once in place these keywords will no longer be valid and will throw errors in the Mapfile parser. Some of these keywords no longer have an effect, and the others have a better alternative. We are interested in finding out how much usage there is of the Mapfile XML support [2], introduced via RFC 51 in MapServer 6.0 [3], and whether the Mapfile XSD [4] and Mapfile XSL [5] files need continued maintenance. There is also a Mapfile DTD [5] which is likely to be removed, and has not been keep up to date over the years. Seth [1] https://mapserver.org/development/rfc/ms-rfc-133.html [2] https://mapserver.org/mapfile/xml_mapfile.html [3] https://mapserver.org/development/rfc/ms-rfc-51.html [4] https://github.com/MapServer/MapServer/blob/main/xmlmapfile/mapfile.xsd [5] https://github.com/MapServer/MapServer/blob/main/xmlmapfile/mapfile.xsl [6] https://github.com/MapServer/MapServer/blob/main/mapfile.dtd -- web:http://geographika.co.uk twitter: @geographika From bob.basques at ci.stpaul.mn.us Mon May 3 09:14:41 2021 From: bob.basques at ci.stpaul.mn.us (Basques, Bob (CI-StPaul)) Date: Mon, 3 May 2021 16:14:41 +0000 Subject: [mapserver-users] TCMUG Meeting for May 12th, 2021 Message-ID: Calling for virtual presenters for the Local OSGeo Chapter (aka TCMUG) meeting next week on May 12th. Anything Geo related. Just reply and I'll set it up. Meet from 4:30 to 6:00 generally, but you don't need to fill all of that time. Thanks Bobb -------------- next part -------------- An HTML attachment was scrubbed... URL: From bob.basques at ci.stpaul.mn.us Wed May 5 06:55:52 2021 From: bob.basques at ci.stpaul.mn.us (Basques, Bob (CI-StPaul)) Date: Wed, 5 May 2021 13:55:52 +0000 Subject: [mapserver-users] OSGeo Twin Cities (aka TCMUG) Local Chapter Meeting - May. 12th Message-ID: All, A good presentation by Perry N. last month on Drones and Open Source software. Lot's of interest on the topic too. Re-live the presentation from the recording that is posted at the link below. Upcoming Meeting: Title: Howard Bulter - Headless OpenDroneMap in the Cloud Description: Howard Butler will present how to use the Serverless framework and AWS to create a data-driven S3 bucket that manages ODM processing. By combining AWS Batch, S3, Lambda, and Docker, one can construct a piece of cloud infrastructure that handles the task of processing drone imagery into ODM products such as orthophotos, point clouds, and meshes. Users are notified via email upon completion or failure of the job, and compute resource management is delegated to AWS Batch. Here is the connection info: https://meet.jit.si/osgeo_tcmug When: May. 12th, 4:30 PM CDT Bobb OSGeo, Twin Cities (aka TCMUG), MN, USA Local Chapter Page. -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomaschristian at gmail.com Wed May 5 12:07:34 2021 From: thomaschristian at gmail.com (Tom Christian) Date: Wed, 5 May 2021 12:07:34 -0700 Subject: [mapserver-users] FastCGI connection pool parameters Message-ID: The MapServer LAYER documentation says the following on connection pooling in combination with FastCGI: "Additionally, if you have FastCGI enabled, the connection handle will stay open indefinitely, or according to the options specified in the FastCGI configuration" I'm using MapServer with PostGIS and FastCGI, and I'm very interested in learning more about this, however I cannot find any information about how connection pooling should be configured in FastCGI. Can anybody clarify here? How should connection pooling be controlled by FastCGI config? Thanks, Tom -------------- next part -------------- An HTML attachment was scrubbed... URL: From jmckenna at gatewaygeomatics.com Wed May 5 12:21:53 2021 From: jmckenna at gatewaygeomatics.com (Jeff McKenna) Date: Wed, 5 May 2021 16:21:53 -0300 Subject: [mapserver-users] FastCGI connection pool parameters In-Reply-To: References: Message-ID: <7fac387a-53e9-490a-9c3c-730315c393a5@gatewaygeomatics.com> Hi Tom, For MS4W users on Windows, the documentation (https://ms4w.com/README_INSTALL.html#fastcgi) gives more specific examples, such as: FcgidMinProcessesPerClass 0 FcgidIdleScanInterval 1 FcgidProcessLifeTime 10 and also points to the mod_fcgid page where each of these directives is defined in detail: https://httpd.apache.org/mod_fcgid/mod/mod_fcgid.html Personally I always start with those settings, but others will have their favorite preferences for settings. Hope that helps, -jeff -- Jeff McKenna GatewayGeo: Developers of MS4W, MapServer Consulting and Training co-founder of FOSS4G http://gatewaygeo.com/ On 2021-05-05 4:07 p.m., Tom Christian wrote: > The MapServer LAYER documentation > says the > following on connection pooling in combination with FastCGI: > > "Additionally, if you have FastCGI enabled, the connection handle will > stay open indefinitely, or according to the options specified in the > FastCGI > ?configuration" > > I'm using MapServer with PostGIS and FastCGI, and I'm very interested in > learning more about this, however I cannot find any information about > how connection pooling should be configured in FastCGI. > > Can anybody clarify here? How should connection pooling be controlled by > FastCGI config? > > Thanks, > Tom > From bob.basques at ci.stpaul.mn.us Tue May 11 16:10:54 2021 From: bob.basques at ci.stpaul.mn.us (Basques, Bob (CI-StPaul)) Date: Tue, 11 May 2021 23:10:54 +0000 Subject: [mapserver-users] [REMINDER] OSGeo Twin Cities (aka TCMUG) Local Chapter Meeting - May. 12th Message-ID: All, A good presentation by Perry N. last month on Drones and Open Source software. Lot?s of interest on the topic too. Re-live the presentation from the recording that is posted at the link below. Upcoming Meeting: Title: Howard Bulter ? Headless OpenDroneMap in the Cloud Description: Howard Butler will present how to use the Serverless framework and AWS to create a data-driven S3 bucket that manages ODM processing. By combining AWS Batch, S3, Lambda, and Docker, one can construct a piece of cloud infrastructure that handles the task of processing drone imagery into ODM products such as orthophotos, point clouds, and meshes. Users are notified via email upon completion or failure of the job, and compute resource management is delegated to AWS Batch. Here is the connection info: https://meet.jit.si/osgeo_tcmug When: May. 12th, 4:30 PM CDT Bobb OSGeo, Twin Cities (aka TCMUG), MN, USA Local Chapter Page. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Anton.Bakker at kadaster.nl Wed May 12 05:49:39 2021 From: Anton.Bakker at kadaster.nl (Bakker, Anton) Date: Wed, 12 May 2021 12:49:39 +0000 Subject: [mapserver-users] Next link missing WFS 2.0 getfeature response for specific bbox Message-ID: Hi all, I am running into a problem with WFS 2.0 paged GetFeature request. The problem is that for a particular boundingbox a series of paged WFS 2.0 GetFeature requests fails to retrieve all the features. The geometry type of the layer is of `MULTILINESTRING`, the datasource is a GeoPackage file. Running on version 7.6.2. The problem is that the second paged response (https://geodata.nationaalgeoregister.nl/rioned/gwsw/wfs/v1_0?SERVICE=WFS&SERVICE=WFS&version=2.0.0&service=wfs&request=Getfeature&bbox=80034.6,452005.1,81976.8,453965.8&outputformat=gml3&srsname=EPSG%3A28992&typename=gwsw%3Abeheer_leiding&STARTINDEX=1000 ) is missing the next link. The missing next link does actually produces the expected features (https://geodata.nationaalgeoregister.nl/rioned/gwsw/wfs/v1_0?SERVICE=WFS&SERVICE=WFS&version=2.0.0&service=wfs&request=Getfeature&bbox=80034.6,452005.1,81976.8,453965.8&outputformat=gml3&srsname=EPSG%3A28992&typename=gwsw%3Abeheer_leiding&STARTINDEX=2000 ) and contains a next link itself. In the MapServer logs, when requesting the page with the missing next link, I see the following log output: `msOGRFileNextShape: Returning MS_DONE (no more shapes)`. This log output also shows when requesting the last page of results, of a paged WFS request. The interesting thing is that this behaviour does not occur when requesting a slightly bigger bbox: https://geodata.nationaalgeoregister.nl/rioned/gwsw/wfs/v1_0?SERVICE=WFS&SERVICE=WFS&version=2.0.0&service=wfs&request=Getfeature&bbox=80034.6%2C452005.1%2C81976.8%2C453965.8&outputformat=gml3&srsname=EPSG%3A28992&typename=gwsw%3Abeheer_leiding The SQL query used by Mapserver when requesting the page (https://geodata.nationaalgeoregister.nl/rioned/gwsw/wfs/v1_0?SERVICE=WFS&SERVICE=WFS&version=2.0.0&service=wfs&request=Getfeature&bbox=80034.6,452005.1,81976.8,453965.8&outputformat=gml3&srsname=EPSG%3A28992&typename=gwsw%3Abeheer_leiding&STARTINDEX=1000 ) with the missing next link is: ``` SELECT "beheer_leiding"."uri" AS "uri", "beheer_leiding"."geometry" AS "geometry" FROM "beheer_leiding" JOIN "rtree_beheer_leiding_geometry" ms_spat_idx ON "beheer_leiding".ROWID = ms_spat_idx.id AND ms_spat_idx.minx <= 81976.8 AND ms_spat_idx.maxx >= 80034.6 AND ms_spat_idx.miny <= 453965.8 AND ms_spat_idx.maxy >= 452005.1 ORDER BY "beheer_leiding".ROWID LIMIT 1001 OFFSET 1000 ``` This query actually produces 1001 features as expected (other paged requests with more features to come have the same result). So not sure why MapServer decides there are no more results left. The MS_DONE value is returned from here (7.6.2 release) in the MapServer source code. The problem seems to be caused by an interaction between the data, the requested bbox and a (by me) suspected bug in MapServer. In particul in the code that determines if there are any features left in the result set. Or maybe I am missing something obvious and there is a mistake in the mapfile causing the issue. Did anyone see this behaviour before? Btw when changing the datasource to a GeoJSON file this behaviour does not occur, but it does occur with a PostGIS datasource. I created a repo (https://github.com/arbakker/debug-ms-bbox-issue) with a minimal example to reproduce the issue. The repo contains the mapfile, docker-compose, test script, data and a README describing steps in more detail to reproduce the issue. Cheers, Anton Bakker Software Engineer IT | Geo- en Vastgoedinformatie en Advies |PDOK 06-29 73 73 51 | anton.bakker at kadaster.nl [cid:image001.png at 01D7473E.086BB5A0] [cid:image002.png at 01D7473E.086BB5A0] [cid:image003.png at 01D7473E.086BB5A0] [cid:image004.png at 01D7473E.086BB5A0] [cid:image005.png at 01D7473E.086BB5A0] [cid:image006.png at 01D7473E.086BB5A0] [cid:image007.png at 01D7473E.086BB5A0] Disclaimer: De inhoud van dit bericht is uitsluitend bestemd voor geadresseerde. Gebruik van de inhoud van dit bericht door anderen zonder toestemming van het Kadaster is onrechtmatig. Mocht dit bericht ten onrechte bij u terecht komen, dan verzoeken wij u dit direct te melden aan de verzender en het bericht te vernietigen. Aan de inhoud van dit bericht kunnen geen rechten worden ontleend. Disclaimer: The content of this message is meant to be received by the addressee only. Use of the content of this message by anyone other than the addressee without the consent of the Kadaster is unlawful. If you have received this message, but are not the addressee, please contact the sender immediately and destroy the message. No rights can be derived from the content of this message. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 9195 bytes Desc: image001.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 2315 bytes Desc: image002.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.png Type: image/png Size: 1017 bytes Desc: image003.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image004.png Type: image/png Size: 967 bytes Desc: image004.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image005.png Type: image/png Size: 959 bytes Desc: image005.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image006.png Type: image/png Size: 1009 bytes Desc: image006.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image007.png Type: image/png Size: 1232 bytes Desc: image007.png URL: From even.rouault at spatialys.com Wed May 12 06:56:47 2021 From: even.rouault at spatialys.com (Even Rouault) Date: Wed, 12 May 2021 15:56:47 +0200 Subject: [mapserver-users] Next link missing WFS 2.0 getfeature response for specific bbox In-Reply-To: References: Message-ID: Anton, > > I created a repo (https://github.com/arbakker/debug-ms-bbox-issue > ) > Did you ? I can't access it. Please file an issue with all elements you mentioned. This might be at least slightly related to https://github.com/MapServer/MapServer/issues/6181 ,although perhaps specific to the OGR GeoPackage backend. I suspect a mismatch between bounding box test and exact intersection that confuses the logic that decides if there's a next page. When we have a COUNT of 1000, we actually ask for 1001 features. If there are 1001 features, then we now there's a next page. If there are <= 1000 one, there's none. Something must eliminate one or several features out of the 1001 initial ones. Even -- http://www.spatialys.com My software is free, but my time generally not. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Anton.Bakker at kadaster.nl Wed May 12 07:17:07 2021 From: Anton.Bakker at kadaster.nl (Bakker, Anton) Date: Wed, 12 May 2021 14:17:07 +0000 Subject: [mapserver-users] Next link missing WFS 2.0 getfeature response for specific bbox In-Reply-To: References: Message-ID: Hi Even, Thanks for taking a look. I did not notice the visibility of the repo I created was set to private. I just set it to public, should be accessible now. I suspect a mismatch between bounding box test and exact intersection that confuses the logic that decides if there's a next page. When we have a COUNT of 1000, we actually ask for 1001 features. If there are 1001 features, then we now there's a next page. If there are <= 1000 one, there's none. Something must eliminate one or several features out of the 1001 initial ones. Good to hear I am not the only one with a suspicion. I will file the issue on the issue tracker on GH. I actually tried checking for exact intersections by exploding all the line geometries to points, and check for intersections with the bbox edges. But could not find any points intersecting with the bbox edge. Intersection between line and point should work, no? ogr2ogr -f GPKG points.gpkg data.gpkg -explodecollections -unsetFID -sql "select asgpb(DissolvePoints(GeomFromGPB(geometry))) as geometry, geo_id, uri from beheer_leiding" -nln beheer_leiding ogrinfo points.gpkg -sql "select * from beheer_leiding where Intersects(GeomFromGPB(geometry), MakeLine(MakePoint(80034.6,452005.1,28992), MakePoint(80034.6,453965.8,28992)))" Cheers, Anton Van: Even Rouault Verzonden: woensdag 12 mei 2021 15:57 Aan: Bakker, Anton ; mapserver-users at lists.osgeo.org Onderwerp: Re: [mapserver-users] Next link missing WFS 2.0 getfeature response for specific bbox Anton, I created a repo (https://secure-web.cisco.com/1y8LpfF5hS18UqK5XUee3MEdOipp-FGiiQbtnDYL4Bgwq7Vnmqi3HunXZvukVs_2PH0wFJj3M9NNzU3w8PRyiUcooO02YOE2TjF8SKH2ADv8Q4s67_p3zREQw6dmMDyjew2kMyzecxkc2GMVJnaXOe9WEpWTYWKeJ1M-kxC22-wLWsywAHWTYFCV6vC92dN-NiP65KpE-O8nmPa1-qqUX4IwAISE9rUJgKLJHt2HRxB_tDjoyLGA_JSoYg1Pq-TeW/https%3A%2F%2Fgithub.com%2Farbakker%2Fdebug-ms-bbox-issue) Did you ? I can't access it. Please file an issue with all elements you mentioned. This might be at least slightly related to https://secure-web.cisco.com/1UjKo9o1slMlOr5t3AdHpWyenYMkKsq_95vtfjB_RznEJv9Kj6OlpXrzlYuD01pSXRLRgAGVkDJXJNZdqeCIORN9UdPFXJZY19fDEuJeFuANaQ7fyFLMfW2f5JyR9GZ0F0SUh5HBgmMOUOt0DSp_5u05M1Rwo1LCdJ7pBQp9ZvPjF-rxDA_N4W3m1iJAifjJjMia1IaeEsQ7MgAoh_fB4NwKDg9Hfv1fPT7msizf1_x6seEeSGVEfmK51P8Q3mu-b/https%3A%2F%2Fgithub.com%2FMapServer%2FMapServer%2Fissues%2F6181 ,although perhaps specific to the OGR GeoPackage backend. I suspect a mismatch between bounding box test and exact intersection that confuses the logic that decides if there's a next page. When we have a COUNT of 1000, we actually ask for 1001 features. If there are 1001 features, then we now there's a next page. If there are <= 1000 one, there's none. Something must eliminate one or several features out of the 1001 initial ones. Even -- http://secure-web.cisco.com/1awtwwweOuwd2S2Ja6CXMJ78vPouzTkWZgA0MI6wnnrRZAk7RS6SoFsiBlgK0eIhR6_nek8OZWweoPPM86kXqM37Znah7vBJ7EDhe0eCjS0i7dqliDynbln9qVkuLlQYRlagC0gBWwqDw2IkT8vyQjHMrAX2OUks4FM1HWLVDHS5o9PNw_CY_cVcawTKN_ErG9x2WGI4Eo44vCDq4I3fjlQHVclVplg1_jRfsUXCXFXPLD4WPxP3mczXJwOX0bEqX/http%3A%2F%2Fwww.spatialys.com My software is free, but my time generally not. Disclaimer: De inhoud van dit bericht is uitsluitend bestemd voor geadresseerde. Gebruik van de inhoud van dit bericht door anderen zonder toestemming van het Kadaster is onrechtmatig. Mocht dit bericht ten onrechte bij u terecht komen, dan verzoeken wij u dit direct te melden aan de verzender en het bericht te vernietigen. Aan de inhoud van dit bericht kunnen geen rechten worden ontleend. Disclaimer: The content of this message is meant to be received by the addressee only. Use of the content of this message by anyone other than the addressee without the consent of the Kadaster is unlawful. If you have received this message, but are not the addressee, please contact the sender immediately and destroy the message. No rights can be derived from the content of this message. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sdlime at gmail.com Thu May 13 08:24:07 2021 From: sdlime at gmail.com (Steve Lime) Date: Thu, 13 May 2021 10:24:07 -0500 Subject: [mapserver-users] Docker for AWS S3 and Mapserver 7 on OSGeo Github? In-Reply-To: <0ee48da3-de99-6a7e-5479-a9103865c004@light42.com> References: <3b56ec70-ca3b-17e3-0782-517f88c10657@light42.com> <0ee48da3-de99-6a7e-5479-a9103865c004@light42.com> Message-ID: It's not a docker image I'm familiar with. It looks to be pinned to a very specific version of MapServer - one that shouldn't be used given its age and subsequent releases so I wouldn't include it "as is". Not sure what the interest would be in developing a project-sanctioned image that was kept current with the most recent version of MapServer and other dependencies such as GDAL, PROJ, etc... On Wed, May 12, 2021 at 9:22 AM Brian M Hamlin wrote: > Hi Steve, Mapserver PSC and All - > > First, please know that *OSGeo dot org* is delivering the 14th edition > of the *OSGeoLive Linux* based on Ubuntu/Debian/GNU OS. Release candidate > 5 is built today and we at OSGeoLive team are soliciting feedback. (details > on request) > > I want to ask the *Mapserver* team and users for feedback on a somewhat > random find on Github, starting with a YNews thread recently. An employee > of MAXAR posted that they use a Mapserver-in-Docker to provide WMS endpoint > for large sat imagery on AWS in S3 buckets -- without having to handle the > data, essentially "on demand" > > https://github.com/OSGeo/mapserver-docker > > Is this Docker image familiar ? Is it worth including in a fairly-small > group of repos on the official OSGeo Github ? other feeback or leads? > > thanks and very best regards --Brian M Hamlin / MAPLABS / > Berkeley, Calif. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From richard.greenwood at gmail.com Sat May 15 08:43:03 2021 From: richard.greenwood at gmail.com (Richard Greenwood) Date: Sat, 15 May 2021 09:43:03 -0600 Subject: [mapserver-users] differing image size with different mapserver versions Message-ID: I get significantly different image sizes between MapServer 6.4 and 7.6 with the same output format definition. I've tried many variations of the following. OUTPUTFORMAT NAME "png-test" DRIVER "AGG/PNG" # GD driver is same (6.4 only) MIMETYPE "image/png; mode=8bit" IMAGEMODE PC256 FORMATOPTION "QUANTIZE_FORCE=on" FORMATOPTION "QUANTIZE_COLORS=256" EXTENSION "png" # TRANSPARENT on or off makes little difference END MapServer 6.4 is 90kB, MapServer 7.6 is 320kB. Any suggestions as to how I can get my MapServer 7.6 image sizes down closer to what I'm getting in MapServer 6.4? Thanks, Rich -- Richard W. Greenwood, PLS www.greenwoodmap.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From even.rouault at spatialys.com Sat May 15 08:59:06 2021 From: even.rouault at spatialys.com (Even Rouault) Date: Sat, 15 May 2021 17:59:06 +0200 Subject: [mapserver-users] differing image size with different mapserver versions In-Reply-To: References: Message-ID: <050a7d00-7d51-93bb-503f-67104e826900@spatialys.com> Richard, your 6.4 image is a interlaced PNG, whereas the 7.6 is a non-interlaced one. I see in the git history a relevant commit: $ git show 9984b39cc8f74d60eb240728df660a172a118aad commit 9984b39cc8f74d60eb240728df660a172a118aad Author: Thomas Bonfort Date:?? Sun Oct 5 15:59:44 2008 +0000 ??? rgba_png: don't interlace by default ??? git-svn-id: http://svn.osgeo.org/mapserver/trunk at 7960 7532c77e-422f-0410-93f4-f0b67bdd69e2 diff --git a/maprgbapng.c b/maprgbapng.c index 105d8d61..c3615edd 100644 --- a/maprgbapng.c +++ b/maprgbapng.c @@ -357,10 +357,13 @@ int msSaveImageRGBAQuantized(gdImagePtr img, gdIOCtx *ctx, outputFormatObj *form ???? int bot_idx, top_idx; ???? int remap[256]; ???? int reqcolors = atoi(msGetOutputFormatOption( format, "QUANTIZE_COLORS", "256")); +??? const char *interlace; ???? ms_png_info info; ???? info.width = gdImageSX(img); ???? info.height = gdImageSY(img); -??? if( strcasecmp("ON", msGetOutputFormatOption( format, "INTERLACE", "ON" )) == 0 ) +??? interlace = msGetOutputFormatOption( format, "INTERLACE", "OFF" ); +??? if( strcasecmp("ON", interlace) == 0 || strcasecmp("YES", interlace) == 0 +??????????? || strcasecmp("1", interlace) == 0) ???????? info.interlaced=1; ???? else ???????? info.interlaced=0; But this predates 6.4 release by several years, so this doesn't explain why you see a different behavior, unless something in 6.4 still turned on interlacing on in that configuration. From what I can see in the doc, the interlacing mode was removed in the 7.0 release when GD went off, so I don't think you can do much. I guess that could be re-added but would require some coding. Even Le 15/05/2021 ? 17:43, Richard Greenwood a ?crit?: > I get significantly different image sizes between MapServer 6.4 and > 7.6 with the same output format definition. I've tried many variations > of the following. > > OUTPUTFORMAT > ? NAME "png-test" > ? DRIVER "AGG/PNG"? # GD driver is same (6.4 only) > ? MIMETYPE "image/png; mode=8bit" > ? IMAGEMODE PC256 > ? FORMATOPTION "QUANTIZE_FORCE=on" > ? FORMATOPTION "QUANTIZE_COLORS=256" > ? EXTENSION "png" > ? # TRANSPARENT on or off makes little difference > END > > MapServer 6.4 is 90kB, > MapServer 7.6 is 320kB. Any > suggestions?as to how I can get my MapServer 7.6 image sizes down > closer to what I'm getting in MapServer 6.4? > > Thanks, > Rich > > -- > Richard W. Greenwood, PLS > www.greenwoodmap.com > > _______________________________________________ > mapserver-users mailing list > mapserver-users at lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/mapserver-users -- http://www.spatialys.com My software is free, but my time generally not. -------------- next part -------------- An HTML attachment was scrubbed... URL: From richard.greenwood at gmail.com Sat May 15 10:07:56 2021 From: richard.greenwood at gmail.com (Richard Greenwood) Date: Sat, 15 May 2021 11:07:56 -0600 Subject: [mapserver-users] differing image size with different mapserver versions In-Reply-To: <050a7d00-7d51-93bb-503f-67104e826900@spatialys.com> References: <050a7d00-7d51-93bb-503f-67104e826900@spatialys.com> Message-ID: Even, Thank you. I had ignored the difference in the interlacing of the two images because I didn't think it would have affected the size. The maprgbapng.c file no longer exists in MapServer 6.4 or 7.6. There is an "if ( interlaced ..." code block in mapoutput.c that is the same in 6.4 and 7.6. I tried forcing it ON and rebuilding 7.6 but the output image still is not interlaced. Maybe that code is just a left over. Or maybe AGG doesn't support interlacing as https://www.mapserver.org/mapfile/outputformat.html seems to suggest. In any case, thanks again. Rich On Sat, May 15, 2021 at 9:59 AM Even Rouault wrote: > Richard, > > your 6.4 image is a interlaced PNG, whereas the 7.6 is a non-interlaced > one. > > I see in the git history a relevant commit: > > $ git show 9984b39cc8f74d60eb240728df660a172a118aad > commit 9984b39cc8f74d60eb240728df660a172a118aad > Author: Thomas Bonfort > > Date: Sun Oct 5 15:59:44 2008 +0000 > > rgba_png: don't interlace by default > > > git-svn-id: http://svn.osgeo.org/mapserver/trunk at 7960 > 7532c77e-422f-0410-93f4-f0b67bdd69e2 > > diff --git a/maprgbapng.c b/maprgbapng.c > index 105d8d61..c3615edd 100644 > --- a/maprgbapng.c > +++ b/maprgbapng.c > @@ -357,10 +357,13 @@ int msSaveImageRGBAQuantized(gdImagePtr img, gdIOCtx > *ctx, outputFormatObj *form > int bot_idx, top_idx; > int remap[256]; > int reqcolors = atoi(msGetOutputFormatOption( format, > "QUANTIZE_COLORS", "256")); > + const char *interlace; > ms_png_info info; > info.width = gdImageSX(img); > info.height = gdImageSY(img); > - if( strcasecmp("ON", msGetOutputFormatOption( format, "INTERLACE", > "ON" )) == 0 ) > + interlace = msGetOutputFormatOption( format, "INTERLACE", "OFF" ); > + if( strcasecmp("ON", interlace) == 0 || strcasecmp("YES", interlace) > == 0 > + || strcasecmp("1", interlace) == 0) > info.interlaced=1; > else > info.interlaced=0; > > But this predates 6.4 release by several years, so this doesn't explain > why you see a different behavior, unless something in 6.4 still turned on > interlacing on in that configuration. > > From what I can see in the doc, the interlacing mode was removed in the > 7.0 release when GD went off, so I don't think you can do much. I guess > that could be re-added but would require some coding. > > Even > > > Le 15/05/2021 ? 17:43, Richard Greenwood a ?crit : > > I get significantly different image sizes between MapServer 6.4 and 7.6 > with the same output format definition. I've tried many variations of the > following. > > OUTPUTFORMAT > NAME "png-test" > DRIVER "AGG/PNG" # GD driver is same (6.4 only) > MIMETYPE "image/png; mode=8bit" > IMAGEMODE PC256 > FORMATOPTION "QUANTIZE_FORCE=on" > FORMATOPTION "QUANTIZE_COLORS=256" > EXTENSION "png" > # TRANSPARENT on or off makes little difference > END > > MapServer 6.4 is 90kB, MapServer > 7.6 is 320kB. Any suggestions as > to how I can get my MapServer 7.6 image sizes down closer to what I'm > getting in MapServer 6.4? > > Thanks, > Rich > > -- > Richard W. Greenwood, PLS > www.greenwoodmap.com > > _______________________________________________ > mapserver-users mailing listmapserver-users at lists.osgeo.orghttps://lists.osgeo.org/mailman/listinfo/mapserver-users > > -- http://www.spatialys.com > My software is free, but my time generally not. > > -- Richard W. Greenwood, PLS www.greenwoodmap.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From even.rouault at spatialys.com Sat May 15 10:21:13 2021 From: even.rouault at spatialys.com (Even Rouault) Date: Sat, 15 May 2021 19:21:13 +0200 Subject: [mapserver-users] differing image size with different mapserver versions In-Reply-To: References: <050a7d00-7d51-93bb-503f-67104e826900@spatialys.com> Message-ID: <43545f85-5cd6-6f4c-45e7-c9ef8e3e2a95@spatialys.com> Actually, I just tried to open mapserv64.png with gimp, and export it as a non-interlaced or interlaced PNG. And the non-interlaced version is 60 kB vs 96 kB for interlaced. So interlacing vs non-interlacing isn't the cause here. Looking more closely at mapserv64.png? vs mapserv76.png , they are visually different. I suspect the rendering to be of higher quality in 7.6 due to anti-aliasing and perhaps better quantization to 8-bit. You could perhaps try to turn off antialiasing in your CLASS.STYLE. This has been re-vived very recently for AGG line rendering. It is master only however. Le 15/05/2021 ? 19:07, Richard Greenwood a ?crit?: > Even, > > Thank?you. I had ignored the difference in the interlacing of the two > images because I didn't think it would have affected the size. > > The maprgbapng.c file no longer exists in MapServer 6.4 or 7.6. There > is an "if ( interlaced ..." code block in mapoutput.c that is the same > in 6.4 and 7.6. I tried forcing it ON and rebuilding 7.6 but the > output image still is not interlaced. Maybe that code is just a left > over. Or maybe AGG doesn't support interlacing as > https://www.mapserver.org/mapfile/outputformat.html > seems to suggest. > > In any case, thanks again. > Rich > > > > On Sat, May 15, 2021 at 9:59 AM Even Rouault > > wrote: > > Richard, > > your 6.4 image is a interlaced PNG, whereas the 7.6 is a > non-interlaced one. > > I see in the git history a relevant commit: > > $ git show 9984b39cc8f74d60eb240728df660a172a118aad > commit 9984b39cc8f74d60eb240728df660a172a118aad > Author: Thomas Bonfort > > Date:?? Sun Oct 5 15:59:44 2008 +0000 > > ??? rgba_png: don't interlace by default > > > ??? git-svn-id: http://svn.osgeo.org/mapserver/trunk at 7960 > > 7532c77e-422f-0410-93f4-f0b67bdd69e2 > > diff --git a/maprgbapng.c b/maprgbapng.c > index 105d8d61..c3615edd 100644 > --- a/maprgbapng.c > +++ b/maprgbapng.c > @@ -357,10 +357,13 @@ int msSaveImageRGBAQuantized(gdImagePtr img, > gdIOCtx *ctx, outputFormatObj *form > ???? int bot_idx, top_idx; > ???? int remap[256]; > ???? int reqcolors = atoi(msGetOutputFormatOption( format, > "QUANTIZE_COLORS", "256")); > +??? const char *interlace; > ???? ms_png_info info; > ???? info.width = gdImageSX(img); > ???? info.height = gdImageSY(img); > -??? if( strcasecmp("ON", msGetOutputFormatOption( format, > "INTERLACE", "ON" )) == 0 ) > +??? interlace = msGetOutputFormatOption( format, "INTERLACE", > "OFF" ); > +??? if( strcasecmp("ON", interlace) == 0 || strcasecmp("YES", > interlace) == 0 > +??????????? || strcasecmp("1", interlace) == 0) > ???????? info.interlaced=1; > ???? else > ???????? info.interlaced=0; > > But this predates 6.4 release by several years, so this doesn't > explain why you see a different behavior, unless something in 6.4 > still turned on interlacing on in that configuration. > > From what I can see in the doc, the interlacing mode was removed > in the 7.0 release when GD went off, so I don't think you can do > much. I guess that could be re-added but would require some coding. > > Even > > > Le 15/05/2021 ? 17:43, Richard Greenwood a ?crit?: >> I get significantly different image sizes between MapServer 6.4 >> and 7.6 with the same output format definition. I've tried many >> variations of the following. >> >> OUTPUTFORMAT >> ? NAME "png-test" >> ? DRIVER "AGG/PNG"? # GD driver is same (6.4 only) >> ? MIMETYPE "image/png; mode=8bit" >> ? IMAGEMODE PC256 >> ? FORMATOPTION "QUANTIZE_FORCE=on" >> ? FORMATOPTION "QUANTIZE_COLORS=256" >> ? EXTENSION "png" >> ? # TRANSPARENT on or off makes little difference >> END >> >> MapServer 6.4 is 90kB, >> MapServer 7.6 is 320kB. >> Any suggestions?as to how I can get my MapServer 7.6 image sizes >> down closer to what I'm getting in MapServer 6.4? >> >> Thanks, >> Rich >> >> -- >> Richard W. Greenwood, PLS >> www.greenwoodmap.com >> >> _______________________________________________ >> mapserver-users mailing list >> mapserver-users at lists.osgeo.org >> https://lists.osgeo.org/mailman/listinfo/mapserver-users > > -- > http://www.spatialys.com > My software is free, but my time generally not. > > > > -- > Richard W. Greenwood, PLS > www.greenwoodmap.com -- http://www.spatialys.com My software is free, but my time generally not. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lars.schylberg at blixtmail.se Sat May 15 10:24:23 2021 From: lars.schylberg at blixtmail.se (Lars Schylberg) Date: Sat, 15 May 2021 19:24:23 +0200 Subject: [mapserver-users] differing image size with different mapserver versions In-Reply-To: References: Message-ID: <1f7d66d9-fe2b-79c2-3de0-02a7bf235b1d@blixtmail.se> Hi, When I look at the images it seems like the 7.6 have anti-aliasing but the 6.4 does not have it.? The 7.6 is more fuzzy and the 6.4 image You could that the river is not as smooth. /Lars S. Den 2021-05-15 kl. 17:43, skrTo ev Richard Greenwood: > I get significantly different image sizes between MapServer 6.4 and > 7.6 with the same output format definition. I've tried many variations > of the following. > > OUTPUTFORMAT > ? NAME "png-test" > ? DRIVER "AGG/PNG"? # GD driver is same (6.4 only) > ? MIMETYPE "image/png; mode=8bit" > ? IMAGEMODE PC256 > ? FORMATOPTION "QUANTIZE_FORCE=on" > ? FORMATOPTION "QUANTIZE_COLORS=256" > ? EXTENSION "png" > ? # TRANSPARENT on or off makes little difference > END > > MapServer 6.4 is 90kB, > MapServer 7.6 is 320kB. Any > suggestions?as to how I can get my MapServer 7.6 image sizes down > closer to what I'm getting in MapServer 6.4? > > Thanks, > Rich > > -- > Richard W. Greenwood, PLS > www.greenwoodmap.com > > _______________________________________________ > 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 richard.greenwood at gmail.com Sat May 15 11:00:06 2021 From: richard.greenwood at gmail.com (Richard Greenwood) Date: Sat, 15 May 2021 12:00:06 -0600 Subject: [mapserver-users] differing image size with different mapserver versions In-Reply-To: <43545f85-5cd6-6f4c-45e7-c9ef8e3e2a95@spatialys.com> References: <050a7d00-7d51-93bb-503f-67104e826900@spatialys.com> <43545f85-5cd6-6f4c-45e7-c9ef8e3e2a95@spatialys.com> Message-ID: I built from main and tested with ANTIALIAS ON and ANTIALIAS OFF. Assuming that my mapfile syntax below is correct, there is no difference in size and the resulting PNG is still approximately 3x larger than the MapServer 6.4 one. CLASS STYLE COLOR 255 255 208 ANTIALIAS ON END END Again, thank you for your suggestions. Rich On Sat, May 15, 2021 at 11:21 AM Even Rouault wrote: > Actually, I just tried to open mapserv64.png with gimp, and export it as > a non-interlaced or interlaced PNG. And the non-interlaced version is 60 kB > vs 96 kB for interlaced. So interlacing vs non-interlacing isn't the cause > here. > > Looking more closely at mapserv64.png vs mapserv76.png , they are > visually different. I suspect the rendering to be of higher quality in 7.6 > due to anti-aliasing and perhaps better quantization to 8-bit. You could > perhaps try to turn off antialiasing in your CLASS.STYLE. This has been > re-vived very recently for AGG line rendering. It is master only however. > Le 15/05/2021 ? 19:07, Richard Greenwood a ?crit : > > Even, > > Thank you. I had ignored the difference in the interlacing of the two > images because I didn't think it would have affected the size. > > The maprgbapng.c file no longer exists in MapServer 6.4 or 7.6. There is > an "if ( interlaced ..." code block in mapoutput.c that is the same in 6.4 > and 7.6. I tried forcing it ON and rebuilding 7.6 but the output image > still is not interlaced. Maybe that code is just a left over. Or maybe AGG > doesn't support interlacing as > https://www.mapserver.org/mapfile/outputformat.html seems to suggest. > > In any case, thanks again. > Rich > > > > On Sat, May 15, 2021 at 9:59 AM Even Rouault > wrote: > >> Richard, >> >> your 6.4 image is a interlaced PNG, whereas the 7.6 is a non-interlaced >> one. >> >> I see in the git history a relevant commit: >> >> $ git show 9984b39cc8f74d60eb240728df660a172a118aad >> commit 9984b39cc8f74d60eb240728df660a172a118aad >> Author: Thomas Bonfort >> >> Date: Sun Oct 5 15:59:44 2008 +0000 >> >> rgba_png: don't interlace by default >> >> >> git-svn-id: http://svn.osgeo.org/mapserver/trunk at 7960 >> 7532c77e-422f-0410-93f4-f0b67bdd69e2 >> >> diff --git a/maprgbapng.c b/maprgbapng.c >> index 105d8d61..c3615edd 100644 >> --- a/maprgbapng.c >> +++ b/maprgbapng.c >> @@ -357,10 +357,13 @@ int msSaveImageRGBAQuantized(gdImagePtr img, >> gdIOCtx *ctx, outputFormatObj *form >> int bot_idx, top_idx; >> int remap[256]; >> int reqcolors = atoi(msGetOutputFormatOption( format, >> "QUANTIZE_COLORS", "256")); >> + const char *interlace; >> ms_png_info info; >> info.width = gdImageSX(img); >> info.height = gdImageSY(img); >> - if( strcasecmp("ON", msGetOutputFormatOption( format, "INTERLACE", >> "ON" )) == 0 ) >> + interlace = msGetOutputFormatOption( format, "INTERLACE", "OFF" ); >> + if( strcasecmp("ON", interlace) == 0 || strcasecmp("YES", interlace) >> == 0 >> + || strcasecmp("1", interlace) == 0) >> info.interlaced=1; >> else >> info.interlaced=0; >> >> But this predates 6.4 release by several years, so this doesn't explain >> why you see a different behavior, unless something in 6.4 still turned on >> interlacing on in that configuration. >> >> From what I can see in the doc, the interlacing mode was removed in the >> 7.0 release when GD went off, so I don't think you can do much. I guess >> that could be re-added but would require some coding. >> >> Even >> >> >> Le 15/05/2021 ? 17:43, Richard Greenwood a ?crit : >> >> I get significantly different image sizes between MapServer 6.4 and 7.6 >> with the same output format definition. I've tried many variations of the >> following. >> >> OUTPUTFORMAT >> NAME "png-test" >> DRIVER "AGG/PNG" # GD driver is same (6.4 only) >> MIMETYPE "image/png; mode=8bit" >> IMAGEMODE PC256 >> FORMATOPTION "QUANTIZE_FORCE=on" >> FORMATOPTION "QUANTIZE_COLORS=256" >> EXTENSION "png" >> # TRANSPARENT on or off makes little difference >> END >> >> MapServer 6.4 is 90kB, MapServer >> 7.6 is 320kB. Any >> suggestions as to how I can get my MapServer 7.6 image sizes down closer to >> what I'm getting in MapServer 6.4? >> >> Thanks, >> Rich >> >> -- >> Richard W. Greenwood, PLS >> www.greenwoodmap.com >> >> _______________________________________________ >> mapserver-users mailing listmapserver-users at lists.osgeo.orghttps://lists.osgeo.org/mailman/listinfo/mapserver-users >> >> -- http://www.spatialys.com >> My software is free, but my time generally not. >> >> > > -- > Richard W. Greenwood, PLS > www.greenwoodmap.com > > -- http://www.spatialys.com > My software is free, but my time generally not. > > -- Richard W. Greenwood, PLS www.greenwoodmap.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From sethg at geographika.co.uk Mon May 17 01:26:30 2021 From: sethg at geographika.co.uk (Seth G) Date: Mon, 17 May 2021 10:26:30 +0200 Subject: [mapserver-users] =?utf-8?q?differing_image_size_with_different_?= =?utf-8?q?mapserver_versions?= In-Reply-To: References: <050a7d00-7d51-93bb-503f-67104e826900@spatialys.com> <43545f85-5cd6-6f4c-45e7-c9ef8e3e2a95@spatialys.com> Message-ID: <399f98d4-94c5-41c1-92ff-678d4bf9f4d9@www.fastmail.com> Hi Richard, In your OUTPUTFORMAT declaration maybe try setting the DRIVER to *AGG/PNG8* Also IMAGEMODE PC256 was only for GD support that was removed in 7.0. Try IMAGEMODE RGB (or RGBA if you want transparency). Seth -- web:http://geographika.co.uk twitter: @geographika On Sat, May 15, 2021, at 8:00 PM, Richard Greenwood wrote: > I built from main and tested with ANTIALIAS ON and ANTIALIAS OFF. Assuming that my mapfile syntax below is correct, there is no difference in size and the resulting PNG is still approximately 3x larger than the MapServer 6.4 one. > CLASS > STYLE > COLOR 255 255 208 > ANTIALIAS ON > END > END > Again, thank you for your suggestions. > Rich > > On Sat, May 15, 2021 at 11:21 AM Even Rouault wrote: >> Actually, I just tried to open mapserv64.png with gimp, and export it as a non-interlaced or interlaced PNG. And the non-interlaced version is 60 kB vs 96 kB for interlaced. So interlacing vs non-interlacing isn't the cause here. >> Looking more closely at mapserv64.png vs mapserv76.png , they are visually different. I suspect the rendering to be of higher quality in 7.6 due to anti-aliasing and perhaps better quantization to 8-bit. You could perhaps try to turn off antialiasing in your CLASS.STYLE. This has been re-vived very recently for AGG line rendering. It is master only however. >> Le 15/05/2021 ? 19:07, Richard Greenwood a ?crit : >>> Even, >>> >>> Thank you. I had ignored the difference in the interlacing of the two images because I didn't think it would have affected the size. >>> >>> The maprgbapng.c file no longer exists in MapServer 6.4 or 7.6. There is an "if ( interlaced ..." code block in mapoutput.c that is the same in 6.4 and 7.6. I tried forcing it ON and rebuilding 7.6 but the output image still is not interlaced. Maybe that code is just a left over. Or maybe AGG doesn't support interlacing as https://www.mapserver.org/mapfile/outputformat.html seems to suggest. >>> >>> In any case, thanks again. >>> Rich >>> >>> >>> >>> On Sat, May 15, 2021 at 9:59 AM Even Rouault wrote: >>>> Richard, >>>> your 6.4 image is a interlaced PNG, whereas the 7.6 is a non-interlaced one. >>>> I see in the git history a relevant commit: >>>> >>>> $ git show 9984b39cc8f74d60eb240728df660a172a118aad >>>> commit 9984b39cc8f74d60eb240728df660a172a118aad >>>> Author: Thomas Bonfort >>>> Date: Sun Oct 5 15:59:44 2008 +0000 >>>> >>>> rgba_png: don't interlace by default >>>> >>>> >>>> git-svn-id: http://svn.osgeo.org/mapserver/trunk at 7960 7532c77e-422f-0410-93f4-f0b67bdd69e2 >>>> >>>> diff --git a/maprgbapng.c b/maprgbapng.c >>>> index 105d8d61..c3615edd 100644 >>>> --- a/maprgbapng.c >>>> +++ b/maprgbapng.c >>>> @@ -357,10 +357,13 @@ int msSaveImageRGBAQuantized(gdImagePtr img, gdIOCtx *ctx, outputFormatObj *form >>>> int bot_idx, top_idx; >>>> int remap[256]; >>>> int reqcolors = atoi(msGetOutputFormatOption( format, "QUANTIZE_COLORS", "256")); >>>> + const char *interlace; >>>> ms_png_info info; >>>> info.width = gdImageSX(img); >>>> info.height = gdImageSY(img); >>>> - if( strcasecmp("ON", msGetOutputFormatOption( format, "INTERLACE", "ON" )) == 0 ) >>>> + interlace = msGetOutputFormatOption( format, "INTERLACE", "OFF" ); >>>> + if( strcasecmp("ON", interlace) == 0 || strcasecmp("YES", interlace) == 0 >>>> + || strcasecmp("1", interlace) == 0) >>>> info.interlaced=1; >>>> else >>>> info.interlaced=0; >>>> >>>> But this predates 6.4 release by several years, so this doesn't explain why you see a different behavior, unless something in 6.4 still turned on interlacing on in that configuration. >>>> From what I can see in the doc, the interlacing mode was removed in the 7.0 release when GD went off, so I don't think you can do much. I guess that could be re-added but would require some coding. >>>> Even >>>> >>>> Le 15/05/2021 ? 17:43, Richard Greenwood a ?crit : >>>>> I get significantly different image sizes between MapServer 6.4 and 7.6 with the same output format definition. I've tried many variations of the following. >>>>> >>>>> OUTPUTFORMAT >>>>> NAME "png-test" >>>>> DRIVER "AGG/PNG" # GD driver is same (6.4 only) >>>>> MIMETYPE "image/png; mode=8bit" >>>>> IMAGEMODE PC256 >>>>> FORMATOPTION "QUANTIZE_FORCE=on" >>>>> FORMATOPTION "QUANTIZE_COLORS=256" >>>>> EXTENSION "png" >>>>> # TRANSPARENT on or off makes little difference >>>>> END >>>>> >>>>> MapServer 6.4 is 90kB, MapServer 7.6 is 320kB. Any suggestions as to how I can get my MapServer 7.6 image sizes down closer to what I'm getting in MapServer 6.4? >>>>> >>>>> Thanks, >>>>> Rich >>>>> >>>>> -- >>>>> >>>>> Richard W. Greenwood, PLS >>>>> www.greenwoodmap.com >>>>> >>>>> _______________________________________________ mapserver-users mailing list >>>>> mapserver-users at lists.osgeo.org >>>>> https://lists.osgeo.org/mailman/listinfo/mapserver-users >>>>> >>>> -- >>>> http://www.spatialys.com My software is free, but my time generally not. >>> >>> >>> -- >>> >>> Richard W. Greenwood, PLS >>> www.greenwoodmap.com >> -- >> http://www.spatialys.com My software is free, but my time generally not. > > > -- > Richard W. Greenwood, PLS > www.greenwoodmap.com > _______________________________________________ > 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 jukka.rahkonen at maanmittauslaitos.fi Mon May 17 02:40:41 2021 From: jukka.rahkonen at maanmittauslaitos.fi (Rahkonen Jukka (MML)) Date: Mon, 17 May 2021 09:40:41 +0000 Subject: [mapserver-users] differing image size with different mapserver versions Message-ID: <945ec5ebf881401a8cf7e72d1892ff7a@maanmittauslaitos.fi> Hi, I made a few tests with IrfanView and Gimp and it seems that the both images are antialized but the mapserv76 version is more fine-grained. The mapserv64 version has also less unique colors, 217 vs 250 colors. Saving the mapserv76 image with IrfanView or Gimp by using different settings does not reduce the file size much so the image obviously really has more details. Interlace mode (adam7) in Gimp made the image even bigger. The visual quality of mapserv76.png is not so much better that it would justify the doubled file size. At least the area with dense rectangles on the right look better in mapserv64.png. But I fear that for any systematic further studies you should prepare a test case with source data and mapfile. There are very many small rectangles in the image and it may be that different antializing near the narrow black lines makes the difference. It would be interesting to test the output size with more typical maps. -Jukka Rahkonen- L?hett?j?: mapserver-users Puolesta Seth G L?hetetty: maanantai 17. toukokuuta 2021 11.27 Vastaanottaja: Richard Greenwood Kopio: mapserver-users at lists.osgeo.org Aihe: Re: [mapserver-users] differing image size with different mapserver versions Hi Richard, In your OUTPUTFORMAT declaration maybe try setting the DRIVER to AGG/PNG8 Also IMAGEMODE PC256 was only for GD support that was removed in 7.0. Try IMAGEMODE RGB (or RGBA if you want transparency). Seth -- web:http://geographika.co.uk twitter: @geographika On Sat, May 15, 2021, at 8:00 PM, Richard Greenwood wrote: I built from main and tested with ANTIALIAS ON and ANTIALIAS OFF. Assuming that my mapfile syntax below is correct, there is no difference in size and the resulting PNG is still approximately 3x larger than the MapServer 6.4 one. CLASS STYLE COLOR 255 255 208 ANTIALIAS ON END END Again, thank you for your suggestions. Rich On Sat, May 15, 2021 at 11:21 AM Even Rouault > wrote: Actually, I just tried to open mapserv64.png with gimp, and export it as a non-interlaced or interlaced PNG. And the non-interlaced version is 60 kB vs 96 kB for interlaced. So interlacing vs non-interlacing isn't the cause here. Looking more closely at mapserv64.png vs mapserv76.png , they are visually different. I suspect the rendering to be of higher quality in 7.6 due to anti-aliasing and perhaps better quantization to 8-bit. You could perhaps try to turn off antialiasing in your CLASS.STYLE. This has been re-vived very recently for AGG line rendering. It is master only however. Le 15/05/2021 ? 19:07, Richard Greenwood a ?crit : Even, Thank you. I had ignored the difference in the interlacing of the two images because I didn't think it would have affected the size. The maprgbapng.c file no longer exists in MapServer 6.4 or 7.6. There is an "if ( interlaced ..." code block in mapoutput.c that is the same in 6.4 and 7.6. I tried forcing it ON and rebuilding 7.6 but the output image still is not interlaced. Maybe that code is just a left over. Or maybe AGG doesn't support interlacing as https://www.mapserver.org/mapfile/outputformat.html seems to suggest. In any case, thanks again. Rich On Sat, May 15, 2021 at 9:59 AM Even Rouault > wrote: Richard, your 6.4 image is a interlaced PNG, whereas the 7.6 is a non-interlaced one. I see in the git history a relevant commit: $ git show 9984b39cc8f74d60eb240728df660a172a118aad commit 9984b39cc8f74d60eb240728df660a172a118aad Author: Thomas Bonfort Date: Sun Oct 5 15:59:44 2008 +0000 rgba_png: don't interlace by default git-svn-id: http://svn.osgeo.org/mapserver/trunk at 7960 7532c77e-422f-0410-93f4-f0b67bdd69e2 diff --git a/maprgbapng.c b/maprgbapng.c index 105d8d61..c3615edd 100644 --- a/maprgbapng.c +++ b/maprgbapng.c @@ -357,10 +357,13 @@ int msSaveImageRGBAQuantized(gdImagePtr img, gdIOCtx *ctx, outputFormatObj *form int bot_idx, top_idx; int remap[256]; int reqcolors = atoi(msGetOutputFormatOption( format, "QUANTIZE_COLORS", "256")); + const char *interlace; ms_png_info info; info.width = gdImageSX(img); info.height = gdImageSY(img); - if( strcasecmp("ON", msGetOutputFormatOption( format, "INTERLACE", "ON" )) == 0 ) + interlace = msGetOutputFormatOption( format, "INTERLACE", "OFF" ); + if( strcasecmp("ON", interlace) == 0 || strcasecmp("YES", interlace) == 0 + || strcasecmp("1", interlace) == 0) info.interlaced=1; else info.interlaced=0; But this predates 6.4 release by several years, so this doesn't explain why you see a different behavior, unless something in 6.4 still turned on interlacing on in that configuration. From what I can see in the doc, the interlacing mode was removed in the 7.0 release when GD went off, so I don't think you can do much. I guess that could be re-added but would require some coding. Even Le 15/05/2021 ? 17:43, Richard Greenwood a ?crit : I get significantly different image sizes between MapServer 6.4 and 7.6 with the same output format definition. I've tried many variations of the following. OUTPUTFORMAT NAME "png-test" DRIVER "AGG/PNG" # GD driver is same (6.4 only) MIMETYPE "image/png; mode=8bit" IMAGEMODE PC256 FORMATOPTION "QUANTIZE_FORCE=on" FORMATOPTION "QUANTIZE_COLORS=256" EXTENSION "png" # TRANSPARENT on or off makes little difference END MapServer 6.4 is 90kB, MapServer 7.6 is 320kB. Any suggestions as to how I can get my MapServer 7.6 image sizes down closer to what I'm getting in MapServer 6.4? Thanks, Rich -- Richard W. Greenwood, PLS www.greenwoodmap.com _______________________________________________ mapserver-users mailing list mapserver-users at lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/mapserver-users -- http://www.spatialys.com My software is free, but my time generally not. -- Richard W. Greenwood, PLS www.greenwoodmap.com -- http://www.spatialys.com My software is free, but my time generally not. -- Richard W. Greenwood, PLS www.greenwoodmap.com _______________________________________________ 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 richard.greenwood at gmail.com Mon May 17 05:26:14 2021 From: richard.greenwood at gmail.com (Richard Greenwood) Date: Mon, 17 May 2021 06:26:14 -0600 Subject: [mapserver-users] differing image size with different mapserver versions In-Reply-To: <945ec5ebf881401a8cf7e72d1892ff7a@maanmittauslaitos.fi> References: <945ec5ebf881401a8cf7e72d1892ff7a@maanmittauslaitos.fi> Message-ID: Thanks for the suggestions. The consensus seems to be that anti-aliasing is causing the increased size. The documentation here says "*Since version 6.0, MapServer will produce aliased output for the ?gd/? drivers, and antialiased output for the ?agg/? and ?cairo/? ones*" and it's also mentioned here in Thomas Bonfort's reply. I actually found that 6.4 produced small, aliased images with both the GD and AGG drivers and regardless of my ANTIALIAS true/false setting. Would anyone consider re-enabling the ANTIALIAS true/false option? Thanks, Rich On Mon, May 17, 2021 at 3:40 AM Rahkonen Jukka (MML) < jukka.rahkonen at maanmittauslaitos.fi> wrote: > Hi, > > > > I made a few tests with IrfanView and Gimp and it seems that the both > images are antialized but the mapserv76 version is more fine-grained. The > mapserv64 version has also less unique colors, 217 vs 250 colors. Saving > the mapserv76 image with IrfanView or Gimp by using different settings does > not reduce the file size much so the image obviously really has more > details. Interlace mode (adam7) in Gimp made the image even bigger. > > > > The visual quality of mapserv76.png is not so much better that it would > justify the doubled file size. At least the area with dense rectangles on > the right look better in mapserv64.png. But I fear that for any systematic > further studies you should prepare a test case with source data and > mapfile. There are very many small rectangles in the image and it may be > that different antializing near the narrow black lines makes the > difference. It would be interesting to test the output size with more > typical maps. > > > > -Jukka Rahkonen- > > > > *L?hett?j?:* mapserver-users *Puolesta > *Seth G > *L?hetetty:* maanantai 17. toukokuuta 2021 11.27 > *Vastaanottaja:* Richard Greenwood > *Kopio:* mapserver-users at lists.osgeo.org > *Aihe:* Re: [mapserver-users] differing image size with different > mapserver versions > > > > Hi Richard, > > > > In your OUTPUTFORMAT declaration maybe try setting the DRIVER to > *AGG/PNG8* > > Also IMAGEMODE PC256 was only for GD support that was removed in 7.0. Try > IMAGEMODE RGB (or RGBA if you want transparency). > > > > Seth > > > > -- > > web:http://geographika.co.uk > > twitter: @geographika > > > > > > On Sat, May 15, 2021, at 8:00 PM, Richard Greenwood wrote: > > I built from main and tested with ANTIALIAS ON and ANTIALIAS OFF. Assuming > that my mapfile syntax below is correct, there is no difference in size and > the resulting PNG is still approximately 3x larger than the MapServer 6.4 > one. > > CLASS > STYLE > COLOR 255 255 208 > ANTIALIAS ON > END > END > > Again, thank you for your suggestions. > > Rich > > > > On Sat, May 15, 2021 at 11:21 AM Even Rouault > wrote: > > Actually, I just tried to open mapserv64.png with gimp, and export it as a > non-interlaced or interlaced PNG. And the non-interlaced version is 60 kB > vs 96 kB for interlaced. So interlacing vs non-interlacing isn't the cause > here. > > Looking more closely at mapserv64.png vs mapserv76.png , they are > visually different. I suspect the rendering to be of higher quality in 7.6 > due to anti-aliasing and perhaps better quantization to 8-bit. You could > perhaps try to turn off antialiasing in your CLASS.STYLE. This has been > re-vived very recently for AGG line rendering. It is master only however. > > Le 15/05/2021 ? 19:07, Richard Greenwood a ?crit : > > Even, > > > > Thank you. I had ignored the difference in the interlacing of the two > images because I didn't think it would have affected the size. > > > > The maprgbapng.c file no longer exists in MapServer 6.4 or 7.6. There is > an "if ( interlaced ..." code block in mapoutput.c that is the same in 6.4 > and 7.6. I tried forcing it ON and rebuilding 7.6 but the output image > still is not interlaced. Maybe that code is just a left over. Or maybe AGG > doesn't support interlacing as > https://www.mapserver.org/mapfile/outputformat.html seems to suggest. > > > > In any case, thanks again. > > Rich > > > > > > > > On Sat, May 15, 2021 at 9:59 AM Even Rouault > wrote: > > Richard, > > your 6.4 image is a interlaced PNG, whereas the 7.6 is a non-interlaced > one. > > I see in the git history a relevant commit: > > > > $ git show 9984b39cc8f74d60eb240728df660a172a118aad > > commit 9984b39cc8f74d60eb240728df660a172a118aad > > Author: Thomas Bonfort > > > Date: Sun Oct 5 15:59:44 2008 +0000 > > > > rgba_png: don't interlace by default > > > > > > git-svn-id: http://svn.osgeo.org/mapserver/trunk at 7960 > 7532c77e-422f-0410-93f4-f0b67bdd69e2 > > > > diff --git a/maprgbapng.c b/maprgbapng.c > > index 105d8d61..c3615edd 100644 > > --- a/maprgbapng.c > > +++ b/maprgbapng.c > > @@ -357,10 +357,13 @@ int msSaveImageRGBAQuantized(gdImagePtr img, gdIOCtx > *ctx, outputFormatObj *form > > int bot_idx, top_idx; > > int remap[256]; > > int reqcolors = atoi(msGetOutputFormatOption( format, > "QUANTIZE_COLORS", "256")); > > + const char *interlace; > > ms_png_info info; > > info.width = gdImageSX(img); > > info.height = gdImageSY(img); > > - if( strcasecmp("ON", msGetOutputFormatOption( format, "INTERLACE", > "ON" )) == 0 ) > > + interlace = msGetOutputFormatOption( format, "INTERLACE", "OFF" ); > > + if( strcasecmp("ON", interlace) == 0 || strcasecmp("YES", interlace) > == 0 > > + || strcasecmp("1", interlace) == 0) > > info.interlaced=1; > > else > > info.interlaced=0; > > > > But this predates 6.4 release by several years, so this doesn't explain > why you see a different behavior, unless something in 6.4 still turned on > interlacing on in that configuration. > > From what I can see in the doc, the interlacing mode was removed in the > 7.0 release when GD went off, so I don't think you can do much. I guess > that could be re-added but would require some coding. > > Even > > > > Le 15/05/2021 ? 17:43, Richard Greenwood a ?crit : > > I get significantly different image sizes between MapServer 6.4 and 7.6 > with the same output format definition. I've tried many variations of the > following. > > > > OUTPUTFORMAT > > NAME "png-test" > > DRIVER "AGG/PNG" # GD driver is same (6.4 only) > > MIMETYPE "image/png; mode=8bit" > > IMAGEMODE PC256 > > FORMATOPTION "QUANTIZE_FORCE=on" > > FORMATOPTION "QUANTIZE_COLORS=256" > > EXTENSION "png" > > # TRANSPARENT on or off makes little difference > > END > > > > MapServer 6.4 is 90kB, MapServer > 7.6 is 320kB. Any suggestions as > to how I can get my MapServer 7.6 image sizes down closer to what I'm > getting in MapServer 6.4? > > > > Thanks, > > Rich > > > > -- > > > > Richard W. Greenwood, PLS > > www.greenwoodmap.com > > > > _______________________________________________ > > mapserver-users mailing list > > mapserver-users at lists.osgeo.org > > https://lists.osgeo.org/mailman/listinfo/mapserver-users > > > > -- > > http://www.spatialys.com > > My software is free, but my time generally not. > > > > > > -- > > > > Richard W. Greenwood, PLS > > www.greenwoodmap.com > > -- > > http://www.spatialys.com > > My software is free, but my time generally not. > > > > > > -- > > Richard W. Greenwood, PLS > > www.greenwoodmap.com > > _______________________________________________ > > mapserver-users mailing list > > mapserver-users at lists.osgeo.org > > https://lists.osgeo.org/mailman/listinfo/mapserver-users > > > > > -- Richard W. Greenwood, PLS www.greenwoodmap.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From jukka.rahkonen at maanmittauslaitos.fi Mon May 17 06:05:32 2021 From: jukka.rahkonen at maanmittauslaitos.fi (Rahkonen Jukka (MML)) Date: Mon, 17 May 2021 13:05:32 +0000 Subject: [mapserver-users] differing image size with different mapserver versions Message-ID: <5719284580db4df78e24079ecf197558@maanmittauslaitos.fi> Hi, (Re-sent as edited to mailing list because the body was originally too long. Are you sure about ?I actually found that 6.4 produced small, aliased images with both the GD and AGG drivers?. Originally the AGG library could only do anti-aliasing and that affected also Mapserver 5 https://lists.osgeo.org/pipermail/mapserver-users/2007-September/025467.html. I guess that Mapnik folks have since that added support for controlling anti-aliasing with gamma setting http://mapnik.org/mapnik-reference/. I can see that gamma can be used also with Mapserver https://www.mapserver.org/mapfile/outputformat.html Have a try with gamma=0. However, Even wrote that turning off antialiasing is possible only in master, so perhaps gamma=0 does not work. The documentation for Mapserver 5 tells that ?All ANTIALIAS keywords are now ignored". But the keyword still appears in quite a many places: https://mapserver.org/search.html?q=antialias Would it be time to remove them as well as now not useful references to GD renderer (removed by RFC 99 in 2013)? -Jukka Rahkonen- L?hett?j?: mapserver-users > Puolesta Richard Greenwood L?hetetty: maanantai 17. toukokuuta 2021 15.26 Kopio: mapserver-users at lists.osgeo.org Aihe: Re: [mapserver-users] differing image size with different mapserver versions Thanks for the suggestions. The consensus seems to be that anti-aliasing is causing the increased size. The documentation here says "Since version 6.0, MapServer will produce aliased output for the ?gd/? drivers, and antialiased output for the ?agg/? and ?cairo/? ones" and it's also mentioned here in Thomas Bonfort's reply. I actually found that 6.4 produced small, aliased images with both the GD and AGG drivers and regardless of my ANTIALIAS true/false setting. Would anyone consider re-enabling the ANTIALIAS true/false option? Thanks, Rich -------------- next part -------------- An HTML attachment was scrubbed... URL: From jukka.rahkonen at maanmittauslaitos.fi Mon May 17 06:25:39 2021 From: jukka.rahkonen at maanmittauslaitos.fi (Rahkonen Jukka (MML)) Date: Mon, 17 May 2021 13:25:39 +0000 Subject: [mapserver-users] differing image size with different mapserver versions Message-ID: Hi, Here is a long thread about turning off antialias http://osgeo-org.1560.x6.nabble.com/Draw-roads-WITHOUT-anti-aliasing-td5338614.html. I had the same wrong idea about gamma=0 back then but perhaps gamma=0.01 could work. -Jukka Rahkonen- L?hett?j?: mapserver-users Puolesta Rahkonen Jukka (MML) L?hetetty: maanantai 17. toukokuuta 2021 16.06 Vastaanottaja: Mapserver-Users (mapserver-users at lists.osgeo.org) Aihe: Re: [mapserver-users] differing image size with different mapserver versions Hi, (Re-sent as edited to mailing list because the body was originally too long. Are you sure about ?I actually found that 6.4 produced small, aliased images with both the GD and AGG drivers?. Originally the AGG library could only do anti-aliasing and that affected also Mapserver 5 https://lists.osgeo.org/pipermail/mapserver-users/2007-September/025467.html. I guess that Mapnik folks have since that added support for controlling anti-aliasing with gamma setting http://mapnik.org/mapnik-reference/. I can see that gamma can be used also with Mapserver https://www.mapserver.org/mapfile/outputformat.html Have a try with gamma=0. However, Even wrote that turning off antialiasing is possible only in master, so perhaps gamma=0 does not work. The documentation for Mapserver 5 tells that ?All ANTIALIAS keywords are now ignored". But the keyword still appears in quite a many places: https://mapserver.org/search.html?q=antialias Would it be time to remove them as well as now not useful references to GD renderer (removed by RFC 99 in 2013)? -Jukka Rahkonen- L?hett?j?: mapserver-users > Puolesta Richard Greenwood L?hetetty: maanantai 17. toukokuuta 2021 15.26 Kopio: mapserver-users at lists.osgeo.org Aihe: Re: [mapserver-users] differing image size with different mapserver versions Thanks for the suggestions. The consensus seems to be that anti-aliasing is causing the increased size. The documentation here says "Since version 6.0, MapServer will produce aliased output for the ?gd/? drivers, and antialiased output for the ?agg/? and ?cairo/? ones" and it's also mentioned here in Thomas Bonfort's reply. I actually found that 6.4 produced small, aliased images with both the GD and AGG drivers and regardless of my ANTIALIAS true/false setting. Would anyone consider re-enabling the ANTIALIAS true/false option? Thanks, Rich -------------- next part -------------- An HTML attachment was scrubbed... URL: From richard.greenwood at gmail.com Mon May 17 06:49:30 2021 From: richard.greenwood at gmail.com (Richard Greenwood) Date: Mon, 17 May 2021 07:49:30 -0600 Subject: [mapserver-users] differing image size with different mapserver versions In-Reply-To: <5719284580db4df78e24079ecf197558@maanmittauslaitos.fi> References: <5719284580db4df78e24079ecf197558@maanmittauslaitos.fi> Message-ID: On Mon, May 17, 2021 at 7:05 AM Rahkonen Jukka (MML) < jukka.rahkonen at maanmittauslaitos.fi> wrote: > Hi, > > > > Are you sure about ?I actually found that 6.4 produced small, aliased > images with both the GD and AGG drivers?. > Yes, I just tested again. In 6.4 I get identical (visually and size) images with: OUTPUTFORMAT DRIVER "AGG/PNG" or "GD/PNG". . . . Interestingly, "GD/PNG" does not throw an error in mapserver 7.6 or main (MapServer 7.7). > Originally the AGG library could only do anti-aliasing and that affected > also Mapserver 5 > https://lists.osgeo.org/pipermail/mapserver-users/2007-September/025467.html > . > > > > I guess that Mapnik folks have since that added support for controlling > anti-aliasing with gamma setting http://mapnik.org/mapnik-reference/. > > I can see that gamma can be used also with Mapserver > https://www.mapserver.org/mapfile/outputformat.html > > > > Have a try with gamma=0. However, Even wrote that turning off antialiasing > is possible only in master, so perhaps gamma=0 does not work. > I tried OUTPUTFORMAT FORMATOPTION "GAMMA=0" . . . I see no difference in the output image in 7.7 (main) or 7.6 or 6.4. Is my syntax correct? > > The documentation for Mapserver 5 tells that ?All ANTIALIAS keywords are > now ignored". But the keyword still appears in quite a many places: > > https://mapserver.org/search.html?q=antialias > > > > Would it be time to remove them as well as now not useful references to GD > renderer (removed by RFC 99 in 2013)? > >From my testing it seems that <=6.4 is aliased and >=7.0 is antialiased regardless of ANTIALIAS options. > -Jukka Rahkonen- > > > > > > *L?hett?j?:* mapserver-users *Puolesta > *Richard Greenwood > *L?hetetty:* maanantai 17. toukokuuta 2021 15.26 > *Kopio:* mapserver-users at lists.osgeo.org > *Aihe:* Re: [mapserver-users] differing image size with different > mapserver versions > > > > Thanks for the suggestions. The consensus seems to be that anti-aliasing > is causing the increased size. The documentation here > says "*Since version 6.0, > MapServer will produce aliased output for the ?gd/? drivers, and > antialiased output for the ?agg/? and ?cairo/? ones*" and it's also > mentioned here > in > Thomas Bonfort's reply. I actually found that 6.4 produced small, aliased > images with both the GD and AGG drivers and regardless of my ANTIALIAS > true/false setting. > > > > Would anyone consider re-enabling the ANTIALIAS true/false option? > > > > Thanks, > > Rich > > > > > > > > > _______________________________________________ > mapserver-users mailing list > mapserver-users at lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/mapserver-users > -- Richard W. Greenwood, PLS www.greenwoodmap.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From Andreas.Eichner at sid.sachsen.de Mon May 17 06:53:13 2021 From: Andreas.Eichner at sid.sachsen.de (Eichner, Andreas - SID) Date: Mon, 17 May 2021 13:53:13 +0000 Subject: [mapserver-users] differing image size with different mapserver versions In-Reply-To: References: Message-ID: Hi Jukka, as a result of the discussion IMO Erik created a patch to be able to switch AGGs anti-aliasing on and off using the ANTIALIAS keyword. This was merged by Even Rouault in https://github.com/MapServer/MapServer/pull/6225 It originally worked IMHO only for lines styles. But GAMMA is __not__ the way to turn anti-aliasing off. Greets, Andreas -----Urspr?ngliche Nachricht----- Von: mapserver-users Im Auftrag von Rahkonen Jukka (MML) Gesendet: Montag, 17. Mai 2021 15:26 An: Rahkonen Jukka (MML) ; Mapserver-Users (mapserver-users at lists.osgeo.org) Betreff: Re: [mapserver-users] differing image size with different mapserver versions Hi, Here is a long thread about turning off antialias http://osgeo-org.1560.x6.nabble.com/Draw-roads-WITHOUT-anti-aliasing-td5338614.html . I had the same wrong idea about gamma=0 back then but perhaps gamma=0.01 could work. -Jukka Rahkonen- L?hett?j?: mapserver-users Puolesta Rahkonen Jukka (MML) L?hetetty: maanantai 17. toukokuuta 2021 16.06 Vastaanottaja: Mapserver-Users (mapserver-users at lists.osgeo.org) Aihe: Re: [mapserver-users] differing image size with different mapserver versions Hi, (Re-sent as edited to mailing list because the body was originally too long. Are you sure about ?I actually found that 6.4 produced small, aliased images with both the GD and AGG drivers?. Originally the AGG library could only do anti-aliasing and that affected also Mapserver 5 https://lists.osgeo.org/pipermail/mapserver-users/2007-September/025467.html . I guess that Mapnik folks have since that added support for controlling anti-aliasing with gamma setting http://mapnik.org/mapnik-reference/. I can see that gamma can be used also with Mapserver https://www.mapserver.org/mapfile/outputformat.html Have a try with gamma=0. However, Even wrote that turning off antialiasing is possible only in master, so perhaps gamma=0 does not work. The documentation for Mapserver 5 tells that ?All ANTIALIAS keywords are now ignored". But the keyword still appears in quite a many places: https://mapserver.org/search.html?q=antialias Would it be time to remove them as well as now not useful references to GD renderer (removed by RFC 99 in 2013)? -Jukka Rahkonen- L?hett?j?: mapserver-users > Puolesta Richard Greenwood L?hetetty: maanantai 17. toukokuuta 2021 15.26 Kopio: mapserver-users at lists.osgeo.org Aihe: Re: [mapserver-users] differing image size with different mapserver versions Thanks for the suggestions. The consensus seems to be that anti-aliasing is causing the increased size. The documentation here says "Since version 6.0, MapServer will produce aliased output for the ?gd/? drivers, and antialiased output for the ?agg/? and ?cairo/? ones" and it's also mentioned here in Thomas Bonfort's reply. I actually found that 6.4 produced small, aliased images with both the GD and AGG drivers and regardless of my ANTIALIAS true/false setting. Would anyone consider re-enabling the ANTIALIAS true/false option? Thanks, Rich From richard.greenwood at gmail.com Mon May 17 07:11:02 2021 From: richard.greenwood at gmail.com (Richard Greenwood) Date: Mon, 17 May 2021 08:11:02 -0600 Subject: [mapserver-users] differing image size with different mapserver versions In-Reply-To: References: Message-ID: Progress! Using Andreas' suggestion: *changing the typedef in line 91 of mapagg.cpp from typedef mapserver::renderer_scanline_aa_solid renderer_scanline;to typedef mapserver::renderer_scanline_bin_solid renderer_scanline;* My test image went from 127kB down to 23.3kB! Rich On Mon, May 17, 2021 at 7:58 AM Eichner, Andreas - SID < Andreas.Eichner at sid.sachsen.de> wrote: > Hi Jukka, > > as a result of the discussion IMO Erik created a patch to be able to > switch AGGs anti-aliasing on and off using the ANTIALIAS keyword. This was > merged by Even Rouault in https://github.com/MapServer/MapServer/pull/6225 > It originally worked IMHO only for lines styles. But GAMMA is __not__ the > way to turn anti-aliasing off. > > Greets, Andreas > > -----Urspr?ngliche Nachricht----- > Von: mapserver-users Im Auftrag > von Rahkonen Jukka (MML) > Gesendet: Montag, 17. Mai 2021 15:26 > An: Rahkonen Jukka (MML) ; > Mapserver-Users (mapserver-users at lists.osgeo.org) < > mapserver-users at lists.osgeo.org> > Betreff: Re: [mapserver-users] differing image size with different > mapserver versions > > Hi, > > > > Here is a long thread about turning off antialias > http://osgeo-org.1560.x6.nabble.com/Draw-roads-WITHOUT-anti-aliasing-td5338614.html > < > http://osgeo-org.1560.x6.nabble.com/Draw-roads-WITHOUT-anti-aliasing-td5338614.html> > . > > > > I had the same wrong idea about gamma=0 back then but perhaps gamma=0.01 > could work. > > > > -Jukka Rahkonen- > > > > L?hett?j?: mapserver-users > Puolesta Rahkonen Jukka (MML) > L?hetetty: maanantai 17. toukokuuta 2021 16.06 > Vastaanottaja: Mapserver-Users (mapserver-users at lists.osgeo.org) < > mapserver-users at lists.osgeo.org> > Aihe: Re: [mapserver-users] differing image size with different mapserver > versions > > > > Hi, > > > > (Re-sent as edited to mailing list because the body was originally too > long. > > > > Are you sure about ?I actually found that 6.4 produced small, aliased > images with both the GD and AGG drivers?. Originally the AGG library could > only do anti-aliasing and that affected also Mapserver 5 > https://lists.osgeo.org/pipermail/mapserver-users/2007-September/025467.html > < > https://lists.osgeo.org/pipermail/mapserver-users/2007-September/025467.html> > . > > > > I guess that Mapnik folks have since that added support for controlling > anti-aliasing with gamma setting http://mapnik.org/mapnik-reference/. > > I can see that gamma can be used also with Mapserver > https://www.mapserver.org/mapfile/outputformat.html > > > > Have a try with gamma=0. However, Even wrote that turning off antialiasing > is possible only in master, so perhaps gamma=0 does not work. > > > > The documentation for Mapserver 5 tells that ?All ANTIALIAS keywords are > now ignored". But the keyword still appears in quite a many places: > > https://mapserver.org/search.html?q=antialias > > > > Would it be time to remove them as well as now not useful references to GD > renderer (removed by RFC 99 in 2013)? > > > > -Jukka Rahkonen- > > > > > > L?hett?j?: mapserver-users > Puolesta Richard > Greenwood > L?hetetty: maanantai 17. toukokuuta 2021 15.26 > Kopio: mapserver-users at lists.osgeo.org mapserver-users at lists.osgeo.org> > Aihe: Re: [mapserver-users] differing image size with different mapserver > versions > > > > Thanks for the suggestions. The consensus seems to be that anti-aliasing > is causing the increased size. The documentation here < > https://mapserver.org/output/antialias.html> says "Since version 6.0, > MapServer will produce aliased output for the ?gd/? drivers, and > antialiased output for the ?agg/? and ?cairo/? ones" and it's also > mentioned here < > https://lists.osgeo.org/pipermail/mapserver-users/2012-April/072011.html> > in Thomas Bonfort's reply. I actually found that 6.4 produced small, > aliased images with both the GD and AGG drivers and regardless of my > ANTIALIAS true/false setting. > > > > Would anyone consider re-enabling the ANTIALIAS true/false option? > > > > Thanks, > > Rich > > > > > > > > > > _______________________________________________ > mapserver-users mailing list > mapserver-users at lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/mapserver-users > -- Richard W. Greenwood, PLS www.greenwoodmap.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From jukka.rahkonen at maanmittauslaitos.fi Mon May 17 07:14:01 2021 From: jukka.rahkonen at maanmittauslaitos.fi (Rahkonen Jukka (MML)) Date: Mon, 17 May 2021 14:14:01 +0000 Subject: [mapserver-users] differing image size with different mapserver versions Message-ID: <9539ffca11a04648af408c3dfde80824@maanmittauslaitos.fi> Hi, Does it mean that Mapnik is using the many settings called *-gamma with range 0-1 for a shortcut to adjust both the gamma and corresponding gamma method by the same http://mapnik.org/mapnik-reference/? The goal of this thread is not actually to turn of antialiasing but to create smaller files and decreasing the antialiasing effect could probably do that. The original sample image "mapserv64.png" is antialiased to my eyes. Do you think that adjusting the gamma value alone could have an effect on the file size? -Jukka Rahkonen- -----Alkuper?inen viesti----- L?hett?j?: Eichner, Andreas - SID L?hetetty: maanantai 17. toukokuuta 2021 16.53 Vastaanottaja: Rahkonen Jukka (MML) ; Mapserver-Users (mapserver-users at lists.osgeo.org) Aihe: AW: [mapserver-users] differing image size with different mapserver versions Hi Jukka, as a result of the discussion IMO Erik created a patch to be able to switch AGGs anti-aliasing on and off using the ANTIALIAS keyword. This was merged by Even Rouault in https://github.com/MapServer/MapServer/pull/6225 It originally worked IMHO only for lines styles. But GAMMA is __not__ the way to turn anti-aliasing off. Greets, Andreas -----Urspr?ngliche Nachricht----- Von: mapserver-users Im Auftrag von Rahkonen Jukka (MML) Gesendet: Montag, 17. Mai 2021 15:26 An: Rahkonen Jukka (MML) ; Mapserver-Users (mapserver-users at lists.osgeo.org) Betreff: Re: [mapserver-users] differing image size with different mapserver versions Hi, Here is a long thread about turning off antialias http://osgeo-org.1560.x6.nabble.com/Draw-roads-WITHOUT-anti-aliasing-td5338614.html . I had the same wrong idea about gamma=0 back then but perhaps gamma=0.01 could work. -Jukka Rahkonen- L?hett?j?: mapserver-users Puolesta Rahkonen Jukka (MML) L?hetetty: maanantai 17. toukokuuta 2021 16.06 Vastaanottaja: Mapserver-Users (mapserver-users at lists.osgeo.org) Aihe: Re: [mapserver-users] differing image size with different mapserver versions Hi, (Re-sent as edited to mailing list because the body was originally too long. Are you sure about ?I actually found that 6.4 produced small, aliased images with both the GD and AGG drivers?. Originally the AGG library could only do anti-aliasing and that affected also Mapserver 5 https://lists.osgeo.org/pipermail/mapserver-users/2007-September/025467.html . I guess that Mapnik folks have since that added support for controlling anti-aliasing with gamma setting http://mapnik.org/mapnik-reference/. I can see that gamma can be used also with Mapserver https://www.mapserver.org/mapfile/outputformat.html Have a try with gamma=0. However, Even wrote that turning off antialiasing is possible only in master, so perhaps gamma=0 does not work. The documentation for Mapserver 5 tells that ?All ANTIALIAS keywords are now ignored". But the keyword still appears in quite a many places: https://mapserver.org/search.html?q=antialias Would it be time to remove them as well as now not useful references to GD renderer (removed by RFC 99 in 2013)? -Jukka Rahkonen- L?hett?j?: mapserver-users > Puolesta Richard Greenwood L?hetetty: maanantai 17. toukokuuta 2021 15.26 Kopio: mapserver-users at lists.osgeo.org Aihe: Re: [mapserver-users] differing image size with different mapserver versions Thanks for the suggestions. The consensus seems to be that anti-aliasing is causing the increased size. The documentation here says "Since version 6.0, MapServer will produce aliased output for the ?gd/? drivers, and antialiased output for the ?agg/? and ?cairo/? ones" and it's also mentioned here in Thomas Bonfort's reply. I actually found that 6.4 produced small, aliased images with both the GD and AGG drivers and regardless of my ANTIALIAS true/false setting. Would anyone consider re-enabling the ANTIALIAS true/false option? Thanks, Rich From jukka.rahkonen at maanmittauslaitos.fi Mon May 17 07:24:20 2021 From: jukka.rahkonen at maanmittauslaitos.fi (Rahkonen Jukka (MML)) Date: Mon, 17 May 2021 14:24:20 +0000 Subject: [mapserver-users] differing image size with different mapserver versions Message-ID: Good news. There seems to be more to fix in the documentation about ANTIALIAS but who understands how it works now in master with lines, polygons, and labels? -Jukka Rahkonen- L?hett?j?: Richard Greenwood L?hetetty: maanantai 17. toukokuuta 2021 17.11 Vastaanottaja: Eichner, Andreas - SID Kopio: Rahkonen Jukka (MML) ; Mapserver-Users (mapserver-users at lists.osgeo.org) Aihe: Re: [mapserver-users] differing image size with different mapserver versions Progress! Using Andreas' suggestion: changing the typedef in line 91 of mapagg.cpp from typedef mapserver::renderer_scanline_aa_solid renderer_scanline; to typedef mapserver::renderer_scanline_bin_solid renderer_scanline; My test image went from 127kB down to 23.3kB! Rich On Mon, May 17, 2021 at 7:58 AM Eichner, Andreas - SID > wrote: Hi Jukka, as a result of the discussion IMO Erik created a patch to be able to switch AGGs anti-aliasing on and off using the ANTIALIAS keyword. This was merged by Even Rouault in https://github.com/MapServer/MapServer/pull/6225 It originally worked IMHO only for lines styles. But GAMMA is __not__ the way to turn anti-aliasing off. Greets, Andreas -----Urspr?ngliche Nachricht----- Von: mapserver-users > Im Auftrag von Rahkonen Jukka (MML) Gesendet: Montag, 17. Mai 2021 15:26 An: Rahkonen Jukka (MML) >; Mapserver-Users (mapserver-users at lists.osgeo.org) > Betreff: Re: [mapserver-users] differing image size with different mapserver versions Hi, Here is a long thread about turning off antialias http://osgeo-org.1560.x6.nabble.com/Draw-roads-WITHOUT-anti-aliasing-td5338614.html . I had the same wrong idea about gamma=0 back then but perhaps gamma=0.01 could work. -Jukka Rahkonen- L?hett?j?: mapserver-users > Puolesta Rahkonen Jukka (MML) L?hetetty: maanantai 17. toukokuuta 2021 16.06 Vastaanottaja: Mapserver-Users (mapserver-users at lists.osgeo.org) > Aihe: Re: [mapserver-users] differing image size with different mapserver versions Hi, (Re-sent as edited to mailing list because the body was originally too long. Are you sure about ?I actually found that 6.4 produced small, aliased images with both the GD and AGG drivers?. Originally the AGG library could only do anti-aliasing and that affected also Mapserver 5 https://lists.osgeo.org/pipermail/mapserver-users/2007-September/025467.html . I guess that Mapnik folks have since that added support for controlling anti-aliasing with gamma setting http://mapnik.org/mapnik-reference/. I can see that gamma can be used also with Mapserver https://www.mapserver.org/mapfile/outputformat.html Have a try with gamma=0. However, Even wrote that turning off antialiasing is possible only in master, so perhaps gamma=0 does not work. The documentation for Mapserver 5 tells that ?All ANTIALIAS keywords are now ignored". But the keyword still appears in quite a many places: https://mapserver.org/search.html?q=antialias Would it be time to remove them as well as now not useful references to GD renderer (removed by RFC 99 in 2013)? -Jukka Rahkonen- L?hett?j?: mapserver-users > > Puolesta Richard Greenwood L?hetetty: maanantai 17. toukokuuta 2021 15.26 Kopio: mapserver-users at lists.osgeo.org > Aihe: Re: [mapserver-users] differing image size with different mapserver versions Thanks for the suggestions. The consensus seems to be that anti-aliasing is causing the increased size. The documentation here says "Since version 6.0, MapServer will produce aliased output for the ?gd/? drivers, and antialiased output for the ?agg/? and ?cairo/? ones" and it's also mentioned here in Thomas Bonfort's reply. I actually found that 6.4 produced small, aliased images with both the GD and AGG drivers and regardless of my ANTIALIAS true/false setting. Would anyone consider re-enabling the ANTIALIAS true/false option? Thanks, Rich _______________________________________________ mapserver-users mailing list mapserver-users at lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/mapserver-users -- Richard W. Greenwood, PLS www.greenwoodmap.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From Andreas.Eichner at sid.sachsen.de Mon May 17 07:53:26 2021 From: Andreas.Eichner at sid.sachsen.de (Eichner, Andreas - SID) Date: Mon, 17 May 2021 14:53:26 +0000 Subject: [mapserver-users] differing image size with different mapserver versions In-Reply-To: <9539ffca11a04648af408c3dfde80824@maanmittauslaitos.fi> References: <9539ffca11a04648af408c3dfde80824@maanmittauslaitos.fi> Message-ID: <00302813d36342e698ddf240df2514bd@sid.sachsen.de> Hi, Mapniks *-gamma-method defaults to "power" which means the transform pow(x, gamma) is applied to the original pixel value. I'd guess this is done before merging the color value to draw and the value currently stored in the pixel buffer. It's described as "producing slightly smoother line". I think technically this results in color values that are more nearby which might mean they computationally collapse to the same quantization value or are at least better compressable and therefore result in smaller image files. But might be wrong... Greets, Andreas -----Urspr?ngliche Nachricht----- Von: Rahkonen Jukka (MML) Gesendet: Montag, 17. Mai 2021 16:14 An: Eichner, Andreas - SID ; Mapserver-Users (mapserver-users at lists.osgeo.org) Betreff: Re: [mapserver-users] differing image size with different mapserver versions Hi, Does it mean that Mapnik is using the many settings called *-gamma with range 0-1 for a shortcut to adjust both the gamma and corresponding gamma method by the same http://mapnik.org/mapnik-reference/? The goal of this thread is not actually to turn of antialiasing but to create smaller files and decreasing the antialiasing effect could probably do that. The original sample image "mapserv64.png" is antialiased to my eyes. Do you think that adjusting the gamma value alone could have an effect on the file size? -Jukka Rahkonen- -----Alkuper?inen viesti----- L?hett?j?: Eichner, Andreas - SID L?hetetty: maanantai 17. toukokuuta 2021 16.53 Vastaanottaja: Rahkonen Jukka (MML) ; Mapserver-Users (mapserver-users at lists.osgeo.org) Aihe: AW: [mapserver-users] differing image size with different mapserver versions Hi Jukka, as a result of the discussion IMO Erik created a patch to be able to switch AGGs anti-aliasing on and off using the ANTIALIAS keyword. This was merged by Even Rouault in https://github.com/MapServer/MapServer/pull/6225 It originally worked IMHO only for lines styles. But GAMMA is __not__ the way to turn anti-aliasing off. Greets, Andreas -----Urspr?ngliche Nachricht----- Von: mapserver-users Im Auftrag von Rahkonen Jukka (MML) Gesendet: Montag, 17. Mai 2021 15:26 An: Rahkonen Jukka (MML) ; Mapserver-Users (mapserver-users at lists.osgeo.org) Betreff: Re: [mapserver-users] differing image size with different mapserver versions Hi, Here is a long thread about turning off antialias http://osgeo-org.1560.x6.nabble.com/Draw-roads-WITHOUT-anti-aliasing-td5338614.html . I had the same wrong idea about gamma=0 back then but perhaps gamma=0.01 could work. -Jukka Rahkonen- L?hett?j?: mapserver-users Puolesta Rahkonen Jukka (MML) L?hetetty: maanantai 17. toukokuuta 2021 16.06 Vastaanottaja: Mapserver-Users (mapserver-users at lists.osgeo.org) Aihe: Re: [mapserver-users] differing image size with different mapserver versions Hi, (Re-sent as edited to mailing list because the body was originally too long. Are you sure about ?I actually found that 6.4 produced small, aliased images with both the GD and AGG drivers?. Originally the AGG library could only do anti-aliasing and that affected also Mapserver 5 https://lists.osgeo.org/pipermail/mapserver-users/2007-September/025467.html . I guess that Mapnik folks have since that added support for controlling anti-aliasing with gamma setting http://mapnik.org/mapnik-reference/. I can see that gamma can be used also with Mapserver https://www.mapserver.org/mapfile/outputformat.html Have a try with gamma=0. However, Even wrote that turning off antialiasing is possible only in master, so perhaps gamma=0 does not work. The documentation for Mapserver 5 tells that ?All ANTIALIAS keywords are now ignored". But the keyword still appears in quite a many places: https://mapserver.org/search.html?q=antialias Would it be time to remove them as well as now not useful references to GD renderer (removed by RFC 99 in 2013)? -Jukka Rahkonen- L?hett?j?: mapserver-users > Puolesta Richard Greenwood L?hetetty: maanantai 17. toukokuuta 2021 15.26 Kopio: mapserver-users at lists.osgeo.org Aihe: Re: [mapserver-users] differing image size with different mapserver versions Thanks for the suggestions. The consensus seems to be that anti-aliasing is causing the increased size. The documentation here says "Since version 6.0, MapServer will produce aliased output for the ?gd/? drivers, and antialiased output for the ?agg/? and ?cairo/? ones" and it's also mentioned here in Thomas Bonfort's reply. I actually found that 6.4 produced small, aliased images with both the GD and AGG drivers and regardless of my ANTIALIAS true/false setting. Would anyone consider re-enabling the ANTIALIAS true/false option? Thanks, Rich From pschmitt at gmail.com Mon May 17 09:52:23 2021 From: pschmitt at gmail.com (Peter Schmitt) Date: Mon, 17 May 2021 10:52:23 -0600 Subject: [mapserver-users] Docker for AWS S3 and Mapserver 7 on OSGeo Github? In-Reply-To: References: <3b56ec70-ca3b-17e3-0782-517f88c10657@light42.com> <0ee48da3-de99-6a7e-5479-a9103865c004@light42.com> Message-ID: Hi Steve & Brian, I made the source repo https://github.com/pedros007/mapserver-docker a few years ago. I think one of my colleagues must have shared a link to it somewhere on YNews. I have a more updated Dockerfile based on the osgeo/gdal:ubuntu-full-3.3.0 docker image that I could submit a PR to MapServer if anyone else would find it useful. It's similar to what's on that mapserver-docker repo: MapServer runs with supervisord listening on a unix socket. Requests are reverse proxied by Nginx. It has worked pretty well for us. Pete On Thu, May 13, 2021 at 9:24 AM Steve Lime wrote: > It's not a docker image I'm familiar with. It looks to be pinned to a very > specific version of MapServer - one that shouldn't be used given its age > and subsequent releases so I wouldn't include it "as is". Not sure what the > interest would be in developing a project-sanctioned image that was kept > current with the most recent version of MapServer and other dependencies > such as GDAL, PROJ, etc... > > On Wed, May 12, 2021 at 9:22 AM Brian M Hamlin > wrote: > >> Hi Steve, Mapserver PSC and All - >> >> First, please know that *OSGeo dot org* is delivering the 14th edition >> of the *OSGeoLive Linux* based on Ubuntu/Debian/GNU OS. Release >> candidate 5 is built today and we at OSGeoLive team are soliciting >> feedback. (details on request) >> >> I want to ask the *Mapserver* team and users for feedback on a >> somewhat random find on Github, starting with a YNews thread recently. An >> employee of MAXAR posted that they use a Mapserver-in-Docker to provide WMS >> endpoint for large sat imagery on AWS in S3 buckets -- without having to >> handle the data, essentially "on demand" >> >> https://github.com/OSGeo/mapserver-docker >> >> Is this Docker image familiar ? Is it worth including in a >> fairly-small group of repos on the official OSGeo Github ? other feeback >> or leads? >> >> thanks and very best regards --Brian M Hamlin / MAPLABS / >> Berkeley, Calif. >> >> >> _______________________________________________ > mapserver-users mailing list > mapserver-users at lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/mapserver-users > -- Pete -------------- next part -------------- An HTML attachment was scrubbed... URL: From richard.greenwood at gmail.com Tue May 18 09:50:01 2021 From: richard.greenwood at gmail.com (Richard Greenwood) Date: Tue, 18 May 2021 10:50:01 -0600 Subject: [mapserver-users] anti-aliasing (was differing image size with different mapserver versions) Message-ID: Thanks to several helpful replies to my previous thread I know that the increased image size between MapServer 6 with the GD driver and MapServer 7 with the AGG driver is due to differences in anti-aliasing (and lack of) in the two drivers. (AGG features anti-aliasing and sub-pixel resolution ). Gamma setting from 0-1 affects the size of a filled polygon layer by a factor of almost 3x. But gamma has no effect on text, lines, and polygon outlines. So images comprised of these types of features are approximately 2x larger with the AGG/PNG8 driver than with the GD/GIF driver. Where else should I be looking to reduce my images sizes? I serve rural areas with poor internet so in my case, smaller image sizes are more important than higher quality images. Thanks, Rich -- Richard W. Greenwood, PLS www.greenwoodmap.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From bob.basques at ci.stpaul.mn.us Tue May 18 10:16:32 2021 From: bob.basques at ci.stpaul.mn.us (Basques, Bob (CI-StPaul)) Date: Tue, 18 May 2021 17:16:32 +0000 Subject: [mapserver-users] anti-aliasing (was differing image size with different mapserver versions) In-Reply-To: References: Message-ID: <81C48FBA-ACC5-43C5-AE03-2F7788064133@ci.stpaul.mn.us> All, I know the GD stuff has been a long running conversation in the MapServer realm, but does this indicate that maybe discussing something on adding GD back in might be prudent? Or are there methods to get down to these previous files sizes with the newer approaches? I have the same concerns related to image size from the performance side, and running on Mobile in our case. Bobb From: mapserver-users on behalf of Richard Greenwood Date: Tuesday, May 18, 2021 at 11:50 AM To: "mapserver-users at lists.osgeo.org" Subject: [mapserver-users] anti-aliasing (was differing image size with different mapserver versions) Think Before You Click: This email originated outside our organization. Thanks to several helpful replies to my previous thread I know that the increased image size between MapServer 6 with the GD driver and MapServer 7 with the AGG driver is due to differences in anti-aliasing (and lack of) in the two drivers. (AGG features anti-aliasing and sub-pixel resolution). Gamma setting from 0-1 affects the size of a filled polygon layer by a factor of almost 3x. But gamma has no effect on text, lines, and polygon outlines. So images comprised of these types of features are approximately 2x larger with the AGG/PNG8 driver than with the GD/GIF driver. Where else should I be looking to reduce my images sizes? I serve rural areas with poor internet so in my case, smaller image sizes are more important than higher quality images. Thanks, Rich -- Richard W. Greenwood, PLS www.greenwoodmap.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From sethg at geographika.co.uk Tue May 18 10:30:57 2021 From: sethg at geographika.co.uk (Seth G) Date: Tue, 18 May 2021 19:30:57 +0200 Subject: [mapserver-users] =?utf-8?q?anti-aliasing_=28was_differing_image?= =?utf-8?q?_size_with_different_mapserver_versions=29?= In-Reply-To: <81C48FBA-ACC5-43C5-AE03-2F7788064133@ci.stpaul.mn.us> References: <81C48FBA-ACC5-43C5-AE03-2F7788064133@ci.stpaul.mn.us> Message-ID: <0ebd32c2-993c-4d63-9d0b-8df4f9af55dc@www.fastmail.com> I've not used it but the following might help for the AGG/PNG driver: FORMATOPTION "COMPRESSION=9" https://mapserver.org/mapfile/outputformat.html The default is 6. -- web:http://geographika.co.uk twitter: @geographika On Tue, May 18, 2021, at 7:16 PM, Basques, Bob (CI-StPaul) wrote: > All, > > I know the GD stuff has been a long running conversation in the MapServer realm, but does this indicate that maybe discussing something on adding GD back in might be prudent? Or are there methods to get down to these previous files sizes with the newer approaches? > > I have the same concerns related to image size from the performance side, and running on Mobile in our case. > > Bobb > > > *From: *mapserver-users on behalf of Richard Greenwood > *Date: *Tuesday, May 18, 2021 at 11:50 AM > *To: *"mapserver-users at lists.osgeo.org" > *Subject: *[mapserver-users] anti-aliasing (was differing image size with different mapserver versions) > > *Think Before You Click: *This email originated *outside *our organization. > > Thanks to several helpful replies to my previous thread I know that the increased image size between MapServer 6 with the GD driver and MapServer 7 with the AGG driver is due to differences in anti-aliasing (and lack of) in the two drivers. (AGG features anti-aliasing and sub-pixel resolution ). > > Gamma setting from 0-1 affects the size of a filled polygon layer by a factor of almost 3x. But gamma has no effect on text, lines, and polygon outlines. So images comprised of these types of features are approximately 2x larger with the AGG/PNG8 driver than with the GD/GIF driver. > > Where else should I be looking to reduce my images sizes? I serve rural areas with poor internet so in my case, smaller image sizes are more important than higher quality images. > > Thanks, > Rich > > -- > > Richard W. Greenwood, PLS > www.greenwoodmap.com > > _______________________________________________ > 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 even.rouault at spatialys.com Tue May 18 10:42:47 2021 From: even.rouault at spatialys.com (Even Rouault) Date: Tue, 18 May 2021 19:42:47 +0200 Subject: [mapserver-users] anti-aliasing (was differing image size with different mapserver versions) In-Reply-To: <0ebd32c2-993c-4d63-9d0b-8df4f9af55dc@www.fastmail.com> References: <81C48FBA-ACC5-43C5-AE03-2F7788064133@ci.stpaul.mn.us> <0ebd32c2-993c-4d63-9d0b-8df4f9af55dc@www.fastmail.com> Message-ID: Forcing paletted images using QUANTIZE_FORCE=on and decreasing the number of colors with QUANTIZE_COLORS can also help: FORMATOPTION "QUANTIZE_FORCE=on" FORMATOPTION "QUANTIZE_COLORS=200" Le 18/05/2021 ? 19:30, Seth G a ?crit?: > I've not used it but the following might help for the AGG/PNG driver: > > FORMATOPTION "COMPRESSION=9" > > https://mapserver.org/mapfile/outputformat.html > > > The default is 6. > > -- > web:http://geographika.co.uk > twitter: @geographika > > > On Tue, May 18, 2021, at 7:16 PM, Basques, Bob (CI-StPaul) wrote: >> >> All, >> >> >> I know the GD stuff has been a long running conversation in the >> MapServer realm, but does this indicate that maybe discussing >> something on adding GD back in might be prudent?? Or are there >> methods to get down to these previous files sizes with the newer >> approaches? >> >> >> I have the same concerns related to image size from the performance >> side, and running on Mobile in our case. >> >> >> Bobb >> >> >> >> *From: *mapserver-users on >> behalf of Richard Greenwood >> *Date: *Tuesday, May 18, 2021 at 11:50 AM >> *To: *"mapserver-users at lists.osgeo.org" >> *Subject: *[mapserver-users] anti-aliasing (was differing image size >> with different mapserver versions) >> >> >> *Think Before You Click: *This email originated *outside *our >> organization. >> >> >> Thanks to several helpful replies to my previous thread I know that >> the increased image size between MapServer 6 with the GD driver and >> MapServer 7 with the AGG driver is due?to differences in >> anti-aliasing (and lack of) in the two drivers. (AGG features >> anti-aliasing and sub-pixel resolution >> ). >> >> >> Gamma setting from 0-1 affects the size of a filled polygon layer by >> a factor of almost 3x. But gamma has no effect?on?text, lines, and >> polygon outlines. So images comprised of these types of features are >> approximately 2x larger with?the AGG/PNG8 driver than with the GD/GIF >> driver. >> >> >> Where else should I be looking to reduce my images sizes? I serve >> rural areas with poor internet so in my?case, smaller image sizes are >> more important than higher?quality?images. >> >> >> Thanks, >> >> Rich >> >> >> -- >> >> >> Richard W. Greenwood, PLS >> www.greenwoodmap.com >> >> >> _______________________________________________ >> 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 -- http://www.spatialys.com My software is free, but my time generally not. -------------- next part -------------- An HTML attachment was scrubbed... URL: From richard.greenwood at gmail.com Tue May 18 11:11:21 2021 From: richard.greenwood at gmail.com (Richard Greenwood) Date: Tue, 18 May 2021 12:11:21 -0600 Subject: [mapserver-users] anti-aliasing (was differing image size with different mapserver versions) In-Reply-To: References: <81C48FBA-ACC5-43C5-AE03-2F7788064133@ci.stpaul.mn.us> <0ebd32c2-993c-4d63-9d0b-8df4f9af55dc@www.fastmail.com> Message-ID: Bob - I think GD was quite unpopular with the developers. Thomas Bonfort was pretty adamant about removing it. I'm hoping that there may be options in AGG. Seth - FORMATOPTION "COMPRESSION=9" only reduced the size by about 3% in my lines and text test case. Even - the default AGG/PNG8 has QUANTIZE_FORCE=on and QUANTIZE_COLORS=256. I think I remember you saying somewhere that reducing the number of colors mostly just reduced the pallet size and that's pretty much what I see. e.g. reducing the pallet from 256 to 15 colors reduces the image size by about 15% in my lines and text test. Thanks all for the suggestions. Rich On Tue, May 18, 2021 at 11:49 AM Even Rouault wrote: > Forcing paletted images using QUANTIZE_FORCE=on and decreasing the number of colors with QUANTIZE_COLORS can also help: > > FORMATOPTION "QUANTIZE_FORCE=on" > FORMATOPTION "QUANTIZE_COLORS=200" > > Le 18/05/2021 ? 19:30, Seth G a ?crit : > > I've not used it but the following might help for the AGG/PNG driver: > > FORMATOPTION "COMPRESSION=9" > > https://mapserver.org/mapfile/outputformat.html > > The default is 6. > > -- > web:http://geographika.co.uk > twitter: @geographika > > > On Tue, May 18, 2021, at 7:16 PM, Basques, Bob (CI-StPaul) wrote: > > All, > > > > I know the GD stuff has been a long running conversation in the MapServer > realm, but does this indicate that maybe discussing something on adding GD > back in might be prudent? Or are there methods to get down to these > previous files sizes with the newer approaches? > > > > I have the same concerns related to image size from the performance side, > and running on Mobile in our case. > > > > Bobb > > > > > > *From: *mapserver-users > on behalf of Richard Greenwood > > *Date: *Tuesday, May 18, 2021 at 11:50 AM > *To: *"mapserver-users at lists.osgeo.org" > > *Subject: *[mapserver-users] anti-aliasing (was differing image size with > different mapserver versions) > > > > *Think Before You Click: *This email originated *outside *our > organization. > > > > Thanks to several helpful replies to my previous thread I know that the > increased image size between MapServer 6 with the GD driver and MapServer 7 > with the AGG driver is due to differences in anti-aliasing (and lack of) in > the two drivers. (AGG features anti-aliasing and sub-pixel resolution > ). > > > > Gamma setting from 0-1 affects the size of a filled polygon layer by a > factor of almost 3x. But gamma has no effect on text, lines, and polygon > outlines. So images comprised of these types of features are approximately > 2x larger with the AGG/PNG8 driver than with the GD/GIF driver. > > > > Where else should I be looking to reduce my images sizes? I serve rural > areas with poor internet so in my case, smaller image sizes are more > important than higher quality images. > > > > Thanks, > > Rich > > > > -- > > > Richard W. Greenwood, PLS > www.greenwoodmap.com > > > _______________________________________________ > mapserver-users mailing list > mapserver-users at lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/mapserver-users > > > > _______________________________________________ > mapserver-users mailing listmapserver-users at lists.osgeo.orghttps://lists.osgeo.org/mailman/listinfo/mapserver-users > > -- http://www.spatialys.com > My software is free, but my time generally not. > > _______________________________________________ > mapserver-users mailing list > mapserver-users at lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/mapserver-users > -- Richard W. Greenwood, PLS www.greenwoodmap.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From richard.greenwood at gmail.com Tue May 18 11:12:39 2021 From: richard.greenwood at gmail.com (Richard Greenwood) Date: Tue, 18 May 2021 12:12:39 -0600 Subject: [mapserver-users] anti-aliasing (was differing image size with different mapserver versions) In-Reply-To: References: <81C48FBA-ACC5-43C5-AE03-2F7788064133@ci.stpaul.mn.us> <0ebd32c2-993c-4d63-9d0b-8df4f9af55dc@www.fastmail.com> Message-ID: Oops - typo there, reducing the colors from 256 to *125* reduced the image size by about 15%. On Tue, May 18, 2021 at 12:11 PM Richard Greenwood < richard.greenwood at gmail.com> wrote: > Bob - I think GD was quite unpopular with the developers. Thomas Bonfort > was pretty adamant about removing it. I'm hoping that there may be options > in AGG. > > Seth - FORMATOPTION "COMPRESSION=9" only reduced the size by about 3% in > my lines and text test case. > > Even - the default AGG/PNG8 has QUANTIZE_FORCE=on and QUANTIZE_COLORS=256. > I think I remember you saying somewhere that reducing the number of colors > mostly just reduced the pallet size and that's pretty much what I see. e.g. > reducing the pallet from 256 to 15 colors reduces the image size by about > 15% in my lines and text test. > > Thanks all for the suggestions. > Rich > > > On Tue, May 18, 2021 at 11:49 AM Even Rouault > wrote: > >> Forcing paletted images using QUANTIZE_FORCE=on and decreasing the number of colors with QUANTIZE_COLORS can also help: >> >> FORMATOPTION "QUANTIZE_FORCE=on" >> FORMATOPTION "QUANTIZE_COLORS=200" >> >> Le 18/05/2021 ? 19:30, Seth G a ?crit : >> >> I've not used it but the following might help for the AGG/PNG driver: >> >> FORMATOPTION "COMPRESSION=9" >> >> https://mapserver.org/mapfile/outputformat.html >> >> The default is 6. >> >> -- >> web:http://geographika.co.uk >> twitter: @geographika >> >> >> On Tue, May 18, 2021, at 7:16 PM, Basques, Bob (CI-StPaul) wrote: >> >> All, >> >> >> >> I know the GD stuff has been a long running conversation in the MapServer >> realm, but does this indicate that maybe discussing something on adding GD >> back in might be prudent? Or are there methods to get down to these >> previous files sizes with the newer approaches? >> >> >> >> I have the same concerns related to image size from the performance side, >> and running on Mobile in our case. >> >> >> >> Bobb >> >> >> >> >> >> *From: *mapserver-users >> on behalf of Richard Greenwood >> >> *Date: *Tuesday, May 18, 2021 at 11:50 AM >> *To: *"mapserver-users at lists.osgeo.org" >> >> *Subject: *[mapserver-users] anti-aliasing (was differing image size >> with different mapserver versions) >> >> >> >> *Think Before You Click: *This email originated *outside *our >> organization. >> >> >> >> Thanks to several helpful replies to my previous thread I know that the >> increased image size between MapServer 6 with the GD driver and MapServer 7 >> with the AGG driver is due to differences in anti-aliasing (and lack of) in >> the two drivers. (AGG features anti-aliasing and sub-pixel resolution >> ). >> >> >> >> Gamma setting from 0-1 affects the size of a filled polygon layer by a >> factor of almost 3x. But gamma has no effect on text, lines, and polygon >> outlines. So images comprised of these types of features are approximately >> 2x larger with the AGG/PNG8 driver than with the GD/GIF driver. >> >> >> >> Where else should I be looking to reduce my images sizes? I serve rural >> areas with poor internet so in my case, smaller image sizes are more >> important than higher quality images. >> >> >> >> Thanks, >> >> Rich >> >> >> >> -- >> >> >> Richard W. Greenwood, PLS >> www.greenwoodmap.com >> >> >> _______________________________________________ >> mapserver-users mailing list >> mapserver-users at lists.osgeo.org >> https://lists.osgeo.org/mailman/listinfo/mapserver-users >> >> >> >> _______________________________________________ >> mapserver-users mailing listmapserver-users at lists.osgeo.orghttps://lists.osgeo.org/mailman/listinfo/mapserver-users >> >> -- http://www.spatialys.com >> My software is free, but my time generally not. >> >> _______________________________________________ >> mapserver-users mailing list >> mapserver-users at lists.osgeo.org >> https://lists.osgeo.org/mailman/listinfo/mapserver-users >> > > > -- > Richard W. Greenwood, PLS > www.greenwoodmap.com > -- Richard W. Greenwood, PLS www.greenwoodmap.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From sdlime at gmail.com Tue May 18 12:29:52 2021 From: sdlime at gmail.com (Steve Lime) Date: Tue, 18 May 2021 14:29:52 -0500 Subject: [mapserver-users] anti-aliasing (was differing image size with different mapserver versions) In-Reply-To: References: <81C48FBA-ACC5-43C5-AE03-2F7788064133@ci.stpaul.mn.us> <0ebd32c2-993c-4d63-9d0b-8df4f9af55dc@www.fastmail.com> Message-ID: If you don't care about quality then JPEG is an option... ;-) I also wonder if there are ways to create true 8-bit output in other ways. No way GD comes back. On Tue, May 18, 2021 at 1:12 PM Richard Greenwood < richard.greenwood at gmail.com> wrote: > Oops - typo there, reducing the colors from 256 to *125* reduced the > image size by about 15%. > > On Tue, May 18, 2021 at 12:11 PM Richard Greenwood < > richard.greenwood at gmail.com> wrote: > >> Bob - I think GD was quite unpopular with the developers. Thomas Bonfort >> was pretty adamant about removing it. I'm hoping that there may be options >> in AGG. >> >> Seth - FORMATOPTION "COMPRESSION=9" only reduced the size by about 3% in >> my lines and text test case. >> >> Even - the default AGG/PNG8 has QUANTIZE_FORCE=on >> and QUANTIZE_COLORS=256. I think I remember you saying somewhere that >> reducing the number of colors mostly just reduced the pallet size and >> that's pretty much what I see. e.g. reducing the pallet from 256 to 15 >> colors reduces the image size by about 15% in my lines and text test. >> >> Thanks all for the suggestions. >> Rich >> >> >> On Tue, May 18, 2021 at 11:49 AM Even Rouault >> wrote: >> >>> Forcing paletted images using QUANTIZE_FORCE=on and decreasing the number of colors with QUANTIZE_COLORS can also help: >>> >>> FORMATOPTION "QUANTIZE_FORCE=on" >>> FORMATOPTION "QUANTIZE_COLORS=200" >>> >>> Le 18/05/2021 ? 19:30, Seth G a ?crit : >>> >>> I've not used it but the following might help for the AGG/PNG driver: >>> >>> FORMATOPTION "COMPRESSION=9" >>> >>> https://mapserver.org/mapfile/outputformat.html >>> >>> The default is 6. >>> >>> -- >>> web:http://geographika.co.uk >>> twitter: @geographika >>> >>> >>> On Tue, May 18, 2021, at 7:16 PM, Basques, Bob (CI-StPaul) wrote: >>> >>> All, >>> >>> >>> >>> I know the GD stuff has been a long running conversation in the >>> MapServer realm, but does this indicate that maybe discussing something on >>> adding GD back in might be prudent? Or are there methods to get down to >>> these previous files sizes with the newer approaches? >>> >>> >>> >>> I have the same concerns related to image size from the performance >>> side, and running on Mobile in our case. >>> >>> >>> >>> Bobb >>> >>> >>> >>> >>> >>> *From: *mapserver-users >>> on behalf of Richard >>> Greenwood >>> *Date: *Tuesday, May 18, 2021 at 11:50 AM >>> *To: *"mapserver-users at lists.osgeo.org" >>> >>> >>> *Subject: *[mapserver-users] anti-aliasing (was differing image size >>> with different mapserver versions) >>> >>> >>> >>> *Think Before You Click: *This email originated *outside *our >>> organization. >>> >>> >>> >>> Thanks to several helpful replies to my previous thread I know that the >>> increased image size between MapServer 6 with the GD driver and MapServer 7 >>> with the AGG driver is due to differences in anti-aliasing (and lack of) in >>> the two drivers. (AGG features anti-aliasing and sub-pixel resolution >>> ). >>> >>> >>> >>> Gamma setting from 0-1 affects the size of a filled polygon layer by a >>> factor of almost 3x. But gamma has no effect on text, lines, and polygon >>> outlines. So images comprised of these types of features are approximately >>> 2x larger with the AGG/PNG8 driver than with the GD/GIF driver. >>> >>> >>> >>> Where else should I be looking to reduce my images sizes? I serve rural >>> areas with poor internet so in my case, smaller image sizes are more >>> important than higher quality images. >>> >>> >>> >>> Thanks, >>> >>> Rich >>> >>> >>> >>> -- >>> >>> >>> Richard W. Greenwood, PLS >>> www.greenwoodmap.com >>> >>> >>> _______________________________________________ >>> mapserver-users mailing list >>> mapserver-users at lists.osgeo.org >>> https://lists.osgeo.org/mailman/listinfo/mapserver-users >>> >>> >>> >>> _______________________________________________ >>> mapserver-users mailing listmapserver-users at lists.osgeo.orghttps://lists.osgeo.org/mailman/listinfo/mapserver-users >>> >>> -- http://www.spatialys.com >>> My software is free, but my time generally not. >>> >>> _______________________________________________ >>> mapserver-users mailing list >>> mapserver-users at lists.osgeo.org >>> https://lists.osgeo.org/mailman/listinfo/mapserver-users >>> >> >> >> -- >> Richard W. Greenwood, PLS >> www.greenwoodmap.com >> > > > -- > Richard W. Greenwood, PLS > www.greenwoodmap.com > _______________________________________________ > 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 richard.greenwood at gmail.com Tue May 18 12:47:25 2021 From: richard.greenwood at gmail.com (Richard Greenwood) Date: Tue, 18 May 2021 13:47:25 -0600 Subject: [mapserver-users] anti-aliasing (was differing image size with different mapserver versions) In-Reply-To: References: <81C48FBA-ACC5-43C5-AE03-2F7788064133@ci.stpaul.mn.us> <0ebd32c2-993c-4d63-9d0b-8df4f9af55dc@www.fastmail.com> Message-ID: I do automatically switch to JPEG when there's imagery or similar content and could use JPEG more except where I need transparency, like when overlaying a tiled background layer in OpenLayers. I messed with the Cairo driver a little but it seems less flexible than AGG. I haven't been too happy with vector tiles. And yeah, I know GD isn't an option. Thanks Steve. On Tue, May 18, 2021 at 1:30 PM Steve Lime wrote: > If you don't care about quality then JPEG is an option... ;-) I also > wonder if there are ways to create true 8-bit output in other ways. No way > GD comes back. > > On Tue, May 18, 2021 at 1:12 PM Richard Greenwood < > richard.greenwood at gmail.com> wrote: > >> Oops - typo there, reducing the colors from 256 to *125* reduced the >> image size by about 15%. >> >> On Tue, May 18, 2021 at 12:11 PM Richard Greenwood < >> richard.greenwood at gmail.com> wrote: >> >>> Bob - I think GD was quite unpopular with the developers. Thomas Bonfort >>> was pretty adamant about removing it. I'm hoping that there may be options >>> in AGG. >>> >>> Seth - FORMATOPTION "COMPRESSION=9" only reduced the size by about 3% in >>> my lines and text test case. >>> >>> Even - the default AGG/PNG8 has QUANTIZE_FORCE=on >>> and QUANTIZE_COLORS=256. I think I remember you saying somewhere that >>> reducing the number of colors mostly just reduced the pallet size and >>> that's pretty much what I see. e.g. reducing the pallet from 256 to 15 >>> colors reduces the image size by about 15% in my lines and text test. >>> >>> Thanks all for the suggestions. >>> Rich >>> >>> >>> On Tue, May 18, 2021 at 11:49 AM Even Rouault < >>> even.rouault at spatialys.com> wrote: >>> >>>> Forcing paletted images using QUANTIZE_FORCE=on and decreasing the number of colors with QUANTIZE_COLORS can also help: >>>> >>>> FORMATOPTION "QUANTIZE_FORCE=on" >>>> FORMATOPTION "QUANTIZE_COLORS=200" >>>> >>>> Le 18/05/2021 ? 19:30, Seth G a ?crit : >>>> >>>> I've not used it but the following might help for the AGG/PNG driver: >>>> >>>> FORMATOPTION "COMPRESSION=9" >>>> >>>> https://mapserver.org/mapfile/outputformat.html >>>> >>>> The default is 6. >>>> >>>> -- >>>> web:http://geographika.co.uk >>>> twitter: @geographika >>>> >>>> >>>> On Tue, May 18, 2021, at 7:16 PM, Basques, Bob (CI-StPaul) wrote: >>>> >>>> All, >>>> >>>> >>>> >>>> I know the GD stuff has been a long running conversation in the >>>> MapServer realm, but does this indicate that maybe discussing something on >>>> adding GD back in might be prudent? Or are there methods to get down to >>>> these previous files sizes with the newer approaches? >>>> >>>> >>>> >>>> I have the same concerns related to image size from the performance >>>> side, and running on Mobile in our case. >>>> >>>> >>>> >>>> Bobb >>>> >>>> >>>> >>>> >>>> >>>> *From: *mapserver-users >>>> on behalf of Richard >>>> Greenwood >>>> *Date: *Tuesday, May 18, 2021 at 11:50 AM >>>> *To: *"mapserver-users at lists.osgeo.org" >>>> >>>> >>>> *Subject: *[mapserver-users] anti-aliasing (was differing image size >>>> with different mapserver versions) >>>> >>>> >>>> >>>> *Think Before You Click: *This email originated *outside *our >>>> organization. >>>> >>>> >>>> >>>> Thanks to several helpful replies to my previous thread I know that the >>>> increased image size between MapServer 6 with the GD driver and MapServer 7 >>>> with the AGG driver is due to differences in anti-aliasing (and lack of) in >>>> the two drivers. (AGG features anti-aliasing and sub-pixel resolution >>>> ). >>>> >>>> >>>> >>>> Gamma setting from 0-1 affects the size of a filled polygon layer by a >>>> factor of almost 3x. But gamma has no effect on text, lines, and polygon >>>> outlines. So images comprised of these types of features are approximately >>>> 2x larger with the AGG/PNG8 driver than with the GD/GIF driver. >>>> >>>> >>>> >>>> Where else should I be looking to reduce my images sizes? I serve rural >>>> areas with poor internet so in my case, smaller image sizes are more >>>> important than higher quality images. >>>> >>>> >>>> >>>> Thanks, >>>> >>>> Rich >>>> >>>> >>>> >>>> -- >>>> >>>> >>>> Richard W. Greenwood, PLS >>>> www.greenwoodmap.com >>>> >>>> >>>> _______________________________________________ >>>> mapserver-users mailing list >>>> mapserver-users at lists.osgeo.org >>>> https://lists.osgeo.org/mailman/listinfo/mapserver-users >>>> >>>> >>>> >>>> _______________________________________________ >>>> mapserver-users mailing listmapserver-users at lists.osgeo.orghttps://lists.osgeo.org/mailman/listinfo/mapserver-users >>>> >>>> -- http://www.spatialys.com >>>> My software is free, but my time generally not. >>>> >>>> _______________________________________________ >>>> mapserver-users mailing list >>>> mapserver-users at lists.osgeo.org >>>> https://lists.osgeo.org/mailman/listinfo/mapserver-users >>>> >>> >>> >>> -- >>> Richard W. Greenwood, PLS >>> www.greenwoodmap.com >>> >> >> >> -- >> Richard W. Greenwood, PLS >> www.greenwoodmap.com >> _______________________________________________ >> mapserver-users mailing list >> mapserver-users at lists.osgeo.org >> https://lists.osgeo.org/mailman/listinfo/mapserver-users >> > -- Richard W. Greenwood, PLS www.greenwoodmap.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From Andreas.Eichner at sid.sachsen.de Wed May 19 04:38:31 2021 From: Andreas.Eichner at sid.sachsen.de (Eichner, Andreas - SID) Date: Wed, 19 May 2021 11:38:31 +0000 Subject: [mapserver-users] anti-aliasing (was differing image size with different mapserver versions) In-Reply-To: References: Message-ID: <1bd16f5cf38d4f8d836ecb5d7ec079d5@sid.sachsen.de> What AGG does with it's sub-pixel accuracy can be viewed as computing the contribution of the pixels of a virtually larger image to the pixels of the final image. It uses a gamma function to translate the amount of virtual pixels into an amount of visual impact on the final pixel - both expressed as a value in the range 0..1. AGG's default is a linear function that proportionally maps the range 0..1 onto 0..1 (i.e. y=x). MapServer (where applied) uses a linear gamma function that proportionally maps the range 0..gamma onto 0..1. All this results in intermediate color values giving a smoother and visually improved result as in this example: https://commons.wikimedia.org/wiki/File:Antialiasing.png#/media/Datei:Antialiasing.png As PNG uses lossless compression these additional information enlarges the resulting files. So to reduce the size of your map image files it's best to turn anti-aliasing off. One way is to compile a special version with modified typedefs in mapagg.cpp to turn AA off. With Cairo you could use the method cairo_set_antialias(cairo_t*, CAIRO_ANTIALIAS_NONE) to switch it off. But then you would loose paletted image and compression control. With the modified AGG you should still apply the other suggestions with reduced palette and maximum compression. HTH -----Urspr?ngliche Nachricht----- Von: mapserver-users Im Auftrag von Richard Greenwood Gesendet: Dienstag, 18. Mai 2021 18:50 An: mapserver Betreff: [mapserver-users] anti-aliasing (was differing image size with different mapserver versions) Thanks to several helpful replies to my previous thread I know that the increased image size between MapServer 6 with the GD driver and MapServer 7 with the AGG driver is due to differences in anti-aliasing (and lack of) in the two drivers. (AGG features anti-aliasing and sub-pixel resolution ). Gamma setting from 0-1 affects the size of a filled polygon layer by a factor of almost 3x. But gamma has no effect on text, lines, and polygon outlines. So images comprised of these types of features are approximately 2x larger with the AGG/PNG8 driver than with the GD/GIF driver. Where else should I be looking to reduce my images sizes? I serve rural areas with poor internet so in my case, smaller image sizes are more important than higher quality images. Thanks, Rich -- Richard W. Greenwood, PLS www.greenwoodmap.com From jukka.rahkonen at maanmittauslaitos.fi Wed May 19 06:49:02 2021 From: jukka.rahkonen at maanmittauslaitos.fi (Rahkonen Jukka (MML)) Date: Wed, 19 May 2021 13:49:02 +0000 Subject: [mapserver-users] anti-aliasing (was differing image size with different mapserver versions) Message-ID: Hi, Can someone say if the issue is already fixed or not by https://github.com/MapServer/MapServer/pull/6225/files that adds: typedef mapserver::renderer_scanline_bin_solid renderer_scanline_aliased; Is this enough for turning antialiasing off and making png files with lots of linework smaller? Should/could there be something more for polygons which are rendered with plain fill without borderlines? -Jukka Rahkonen- -----Alkuper?inen viesti----- L?hett?j?: mapserver-users Puolesta Eichner, Andreas - SID L?hetetty: keskiviikko 19. toukokuuta 2021 14.39 Vastaanottaja: Richard Greenwood ; mapserver Aihe: Re: [mapserver-users] anti-aliasing (was differing image size with different mapserver versions) What AGG does with it's sub-pixel accuracy can be viewed as computing the contribution of the pixels of a virtually larger image to the pixels of the final image. It uses a gamma function to translate the amount of virtual pixels into an amount of visual impact on the final pixel - both expressed as a value in the range 0..1. AGG's default is a linear function that proportionally maps the range 0..1 onto 0..1 (i.e. y=x). MapServer (where applied) uses a linear gamma function that proportionally maps the range 0..gamma onto 0..1. All this results in intermediate color values giving a smoother and visually improved result as in this example: https://commons.wikimedia.org/wiki/File:Antialiasing.png#/media/Datei:Antialiasing.png As PNG uses lossless compression these additional information enlarges the resulting files. So to reduce the size of your map image files it's best to turn anti-aliasing off. One way is to compile a special version with modified typedefs in mapagg.cpp to turn AA off. With Cairo you could use the method cairo_set_antialias(cairo_t*, CAIRO_ANTIALIAS_NONE) to switch it off. But then you would loose paletted image and compression control. With the modified AGG you should still apply the other suggestions with reduced palette and maximum compression. HTH -----Urspr?ngliche Nachricht----- Von: mapserver-users Im Auftrag von Richard Greenwood Gesendet: Dienstag, 18. Mai 2021 18:50 An: mapserver Betreff: [mapserver-users] anti-aliasing (was differing image size with different mapserver versions) Thanks to several helpful replies to my previous thread I know that the increased image size between MapServer 6 with the GD driver and MapServer 7 with the AGG driver is due to differences in anti-aliasing (and lack of) in the two drivers. (AGG features anti-aliasing and sub-pixel resolution ). Gamma setting from 0-1 affects the size of a filled polygon layer by a factor of almost 3x. But gamma has no effect on text, lines, and polygon outlines. So images comprised of these types of features are approximately 2x larger with the AGG/PNG8 driver than with the GD/GIF driver. Where else should I be looking to reduce my images sizes? I serve rural areas with poor internet so in my case, smaller image sizes are more important than higher quality images. Thanks, Rich -- Richard W. Greenwood, PLS www.greenwoodmap.com _______________________________________________ mapserver-users mailing list mapserver-users at lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/mapserver-users From richard.greenwood at gmail.com Wed May 19 07:11:39 2021 From: richard.greenwood at gmail.com (Richard Greenwood) Date: Wed, 19 May 2021 08:11:39 -0600 Subject: [mapserver-users] anti-aliasing (was differing image size with different mapserver versions) In-Reply-To: <1bd16f5cf38d4f8d836ecb5d7ec079d5@sid.sachsen.de> References: <1bd16f5cf38d4f8d836ecb5d7ec079d5@sid.sachsen.de> Message-ID: Andreas, I have built a version of MapServer without AA enabled in mapagg.cpp as you have suggested. The reduction in file size is remarkable. In some cases it is 1/2 the size of a GD/GIF or an optimized AGG/PNG8. Aesthetically the images are pretty bad at first, but by softening the colors in the map file and reducing the color contrast between adjacent features I'm getting images that are acceptable. I will try experimenting with Cairo driver modifications next. Thank you very much for your suggestion and detailed explanation. Rich On Wed, May 19, 2021 at 5:38 AM Eichner, Andreas - SID < Andreas.Eichner at sid.sachsen.de> wrote: > What AGG does with it's sub-pixel accuracy can be viewed as computing the > contribution of the pixels of a virtually larger image to the pixels of the > final image. It uses a gamma function to translate the amount of virtual > pixels into an amount of visual impact on the final pixel - both expressed > as a value in the range 0..1. AGG's default is a linear function that > proportionally maps the range 0..1 onto 0..1 (i.e. y=x). MapServer (where > applied) uses a linear gamma function that proportionally maps the range > 0..gamma onto 0..1. All this results in intermediate color values giving a > smoother and visually improved result as in this example: > https://commons.wikimedia.org/wiki/File:Antialiasing.png#/media/Datei:Antialiasing.png > > As PNG uses lossless compression these additional information enlarges the > resulting files. So to reduce the size of your map image files it's best to > turn anti-aliasing off. One way is to compile a special version with > modified typedefs in mapagg.cpp to turn AA off. With Cairo you could use > the method cairo_set_antialias(cairo_t*, CAIRO_ANTIALIAS_NONE) to switch it > off. But then you would loose paletted image and compression control. > > With the modified AGG you should still apply the other suggestions with > reduced palette and maximum compression. > > HTH > > > -----Urspr?ngliche Nachricht----- > Von: mapserver-users Im Auftrag > von Richard Greenwood > Gesendet: Dienstag, 18. Mai 2021 18:50 > An: mapserver > Betreff: [mapserver-users] anti-aliasing (was differing image size with > different mapserver versions) > > Thanks to several helpful replies to my previous thread I know that the > increased image size between MapServer 6 with the GD driver and MapServer 7 > with the AGG driver is due to differences in anti-aliasing (and lack of) in > the two drivers. (AGG features anti-aliasing and sub-pixel resolution < > https://en.wikipedia.org/wiki/Anti-Grain_Geometry> ). > > Gamma setting from 0-1 affects the size of a filled polygon layer by a > factor of almost 3x. But gamma has no effect on text, lines, and polygon > outlines. So images comprised of these types of features are approximately > 2x larger with the AGG/PNG8 driver than with the GD/GIF driver. > > Where else should I be looking to reduce my images sizes? I serve rural > areas with poor internet so in my case, smaller image sizes are more > important than higher quality images. > > Thanks, > Rich > > -- > > Richard W. Greenwood, PLS > www.greenwoodmap.com > -- Richard W. Greenwood, PLS www.greenwoodmap.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From Andreas.Eichner at sid.sachsen.de Wed May 19 07:21:49 2021 From: Andreas.Eichner at sid.sachsen.de (Eichner, Andreas - SID) Date: Wed, 19 May 2021 14:21:49 +0000 Subject: [mapserver-users] anti-aliasing (was differing image size with different mapserver versions) In-Reply-To: References: Message-ID: This should make the keyword ANTIALIAS in line styles work as expected and draw linestrings aliased if set to FALSE. But this works not only be adding another typedef. It also adds another member of that type and to use it the agg2Render*-methods need to selectively switch between the both according to the value set in the style. Currently only agg2RenderLine() does that. Others like agg2RenderPolygon() or agg2RenderGlyphsPath() for rendering polygons and text simply ignore that value and simply use the anti-aliasing one. -----Urspr?ngliche Nachricht----- Von: Rahkonen Jukka (MML) Gesendet: Mittwoch, 19. Mai 2021 15:49 An: Eichner, Andreas - SID ; Richard Greenwood ; mapserver Betreff: Re: [mapserver-users] anti-aliasing (was differing image size with different mapserver versions) Hi, Can someone say if the issue is already fixed or not by https://github.com/MapServer/MapServer/pull/6225/files that adds: typedef mapserver::renderer_scanline_bin_solid renderer_scanline_aliased; Is this enough for turning antialiasing off and making png files with lots of linework smaller? Should/could there be something more for polygons which are rendered with plain fill without borderlines? -Jukka Rahkonen- -----Alkuper?inen viesti----- L?hett?j?: mapserver-users Puolesta Eichner, Andreas - SID L?hetetty: keskiviikko 19. toukokuuta 2021 14.39 Vastaanottaja: Richard Greenwood ; mapserver Aihe: Re: [mapserver-users] anti-aliasing (was differing image size with different mapserver versions) What AGG does with it's sub-pixel accuracy can be viewed as computing the contribution of the pixels of a virtually larger image to the pixels of the final image. It uses a gamma function to translate the amount of virtual pixels into an amount of visual impact on the final pixel - both expressed as a value in the range 0..1. AGG's default is a linear function that proportionally maps the range 0..1 onto 0..1 (i.e. y=x). MapServer (where applied) uses a linear gamma function that proportionally maps the range 0..gamma onto 0..1. All this results in intermediate color values giving a smoother and visually improved result as in this example: https://commons.wikimedia.org/wiki/File:Antialiasing.png#/media/Datei:Antialiasing.png As PNG uses lossless compression these additional information enlarges the resulting files. So to reduce the size of your map image files it's best to turn anti-aliasing off. One way is to compile a special version with modified typedefs in mapagg.cpp to turn AA off. With Cairo you could use the method cairo_set_antialias(cairo_t*, CAIRO_ANTIALIAS_NONE) to switch it off. But then you would loose paletted image and compression control. With the modified AGG you should still apply the other suggestions with reduced palette and maximum compression. HTH -----Urspr?ngliche Nachricht----- Von: mapserver-users Im Auftrag von Richard Greenwood Gesendet: Dienstag, 18. Mai 2021 18:50 An: mapserver Betreff: [mapserver-users] anti-aliasing (was differing image size with different mapserver versions) Thanks to several helpful replies to my previous thread I know that the increased image size between MapServer 6 with the GD driver and MapServer 7 with the AGG driver is due to differences in anti-aliasing (and lack of) in the two drivers. (AGG features anti-aliasing and sub-pixel resolution ). Gamma setting from 0-1 affects the size of a filled polygon layer by a factor of almost 3x. But gamma has no effect on text, lines, and polygon outlines. So images comprised of these types of features are approximately 2x larger with the AGG/PNG8 driver than with the GD/GIF driver. Where else should I be looking to reduce my images sizes? I serve rural areas with poor internet so in my case, smaller image sizes are more important than higher quality images. Thanks, Rich -- Richard W. Greenwood, PLS www.greenwoodmap.com _______________________________________________ mapserver-users mailing list mapserver-users at lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/mapserver-users From Andreas.Eichner at sid.sachsen.de Wed May 19 08:15:05 2021 From: Andreas.Eichner at sid.sachsen.de (Eichner, Andreas - SID) Date: Wed, 19 May 2021 15:15:05 +0000 Subject: [mapserver-users] anti-aliasing (was differing image size with different mapserver versions) In-Reply-To: References: <1bd16f5cf38d4f8d836ecb5d7ec079d5@sid.sachsen.de> Message-ID: <567bba35f96346a789582ff4d0e71d46@sid.sachsen.de> If you want to give Cairo a try, you could modify mapcairo.c like this: diff --git a/mapcairo.c b/mapcairo.c index 0f4cc094..d28947d6 100644 --- a/mapcairo.c +++ b/mapcairo.c @@ -517,6 +517,12 @@ imageObj* createImageCairo(int width, int height, outputFormatObj *format,colorO cairo_set_line_cap (r->cr,CAIRO_LINE_CAP_ROUND); cairo_set_line_join(r->cr,CAIRO_LINE_JOIN_ROUND); + { + const char* antialias = msGetOutputFormatOption(format, "ANTIALIAS", "TRUE"); + if (EQUAL(antialias, "OFF") || EQUAL(antialias, "FALSE") || EQUAL(antialias, "0")) { + cairo_set_antialias(r->cr, CAIRO_ANTIALIAS_NONE); + } + } image->img.plugin = (void*)r; } else { msSetError(MS_RENDERERERR, "Cannot create cairo image of size %dx%d.", This adds a FORMATOPTION "ANTIALIAS" to the CAIRO/*-Drivers that defaults to TRUE. But when explicitly set to 0/OFF/FALSE it calls cairo_set_antialias() to disable it. The raster buffer created by the CAIRO renderer is passed to the PNG writer which enables COMPRESSION, PALETTE_FORCE, QUANTIZE_FORCE. So you can combine it: OUTPUTFORMAT NAME "cairopng" DRIVER CAIRO/PNG MIMETYPE "image/png" IMAGEMODE RGB EXTENSION "png" FORMATOPTION "ANTIALIAS=FALSE" FORMATOPTION "QUANTIZE_FORCE=ON" FORMATOPTION "QUANTIZE_COLORS=256" FORMATOPTION "COMPRESSION=9" END I used the msautotest/renderers/line_simple.map example to test and that crushed the resulting png from 5920 bytes down to 947 bytes. HTH, Andreas -----Urspr?ngliche Nachricht----- Von: Richard Greenwood Gesendet: Mittwoch, 19. Mai 2021 16:12 An: Eichner, Andreas - SID Cc: mapserver Betreff: Re: [mapserver-users] anti-aliasing (was differing image size with different mapserver versions) Andreas, I have built a version of MapServer without AA enabled in mapagg.cpp as you have suggested. The reduction in file size is remarkable. In some cases it is 1/2 the size of a GD/GIF or an optimized AGG/PNG8. Aesthetically the images are pretty bad at first, but by softening the colors in the map file and reducing the color contrast between adjacent features I'm getting images that are acceptable. I will try experimenting with Cairo driver modifications next. Thank you very much for your suggestion and detailed explanation. Rich On Wed, May 19, 2021 at 5:38 AM Eichner, Andreas - SID > wrote: What AGG does with it's sub-pixel accuracy can be viewed as computing the contribution of the pixels of a virtually larger image to the pixels of the final image. It uses a gamma function to translate the amount of virtual pixels into an amount of visual impact on the final pixel - both expressed as a value in the range 0..1. AGG's default is a linear function that proportionally maps the range 0..1 onto 0..1 (i.e. y=x). MapServer (where applied) uses a linear gamma function that proportionally maps the range 0..gamma onto 0..1. All this results in intermediate color values giving a smoother and visually improved result as in this example: https://commons.wikimedia.org/wiki/File:Antialiasing.png#/media/Datei:Antialiasing.png As PNG uses lossless compression these additional information enlarges the resulting files. So to reduce the size of your map image files it's best to turn anti-aliasing off. One way is to compile a special version with modified typedefs in mapagg.cpp to turn AA off. With Cairo you could use the method cairo_set_antialias(cairo_t*, CAIRO_ANTIALIAS_NONE) to switch it off. But then you would loose paletted image and compression control. With the modified AGG you should still apply the other suggestions with reduced palette and maximum compression. HTH -----Urspr?ngliche Nachricht----- Von: mapserver-users > Im Auftrag von Richard Greenwood Gesendet: Dienstag, 18. Mai 2021 18:50 An: mapserver > Betreff: [mapserver-users] anti-aliasing (was differing image size with different mapserver versions) Thanks to several helpful replies to my previous thread I know that the increased image size between MapServer 6 with the GD driver and MapServer 7 with the AGG driver is due to differences in anti-aliasing (and lack of) in the two drivers. (AGG features anti-aliasing and sub-pixel resolution ). Gamma setting from 0-1 affects the size of a filled polygon layer by a factor of almost 3x. But gamma has no effect on text, lines, and polygon outlines. So images comprised of these types of features are approximately 2x larger with the AGG/PNG8 driver than with the GD/GIF driver. Where else should I be looking to reduce my images sizes? I serve rural areas with poor internet so in my case, smaller image sizes are more important than higher quality images. Thanks, Rich -- Richard W. Greenwood, PLS www.greenwoodmap.com -- Richard W. Greenwood, PLS www.greenwoodmap.com From sdlime at gmail.com Wed May 19 09:24:11 2021 From: sdlime at gmail.com (Steve Lime) Date: Wed, 19 May 2021 11:24:11 -0500 Subject: [mapserver-users] anti-aliasing (was differing image size with different mapserver versions) In-Reply-To: <567bba35f96346a789582ff4d0e71d46@sid.sachsen.de> References: <1bd16f5cf38d4f8d836ecb5d7ec079d5@sid.sachsen.de> <567bba35f96346a789582ff4d0e71d46@sid.sachsen.de> Message-ID: Worth adding to main? On Wed, May 19, 2021 at 10:15 AM Eichner, Andreas - SID < Andreas.Eichner at sid.sachsen.de> wrote: > If you want to give Cairo a try, you could modify mapcairo.c like this: > > diff --git a/mapcairo.c b/mapcairo.c > index 0f4cc094..d28947d6 100644 > --- a/mapcairo.c > +++ b/mapcairo.c > @@ -517,6 +517,12 @@ imageObj* createImageCairo(int width, int height, > outputFormatObj *format,colorO > > cairo_set_line_cap (r->cr,CAIRO_LINE_CAP_ROUND); > cairo_set_line_join(r->cr,CAIRO_LINE_JOIN_ROUND); > + { > + const char* antialias = msGetOutputFormatOption(format, > "ANTIALIAS", "TRUE"); > + if (EQUAL(antialias, "OFF") || EQUAL(antialias, "FALSE") || > EQUAL(antialias, "0")) { > + cairo_set_antialias(r->cr, CAIRO_ANTIALIAS_NONE); > + } > + } > image->img.plugin = (void*)r; > } else { > msSetError(MS_RENDERERERR, "Cannot create cairo image of size %dx%d.", > > This adds a FORMATOPTION "ANTIALIAS" to the CAIRO/*-Drivers that defaults > to TRUE. But when explicitly set to 0/OFF/FALSE it calls > cairo_set_antialias() to disable it. The raster buffer created by the CAIRO > renderer is passed to the PNG writer which enables COMPRESSION, > PALETTE_FORCE, QUANTIZE_FORCE. So you can combine it: > > OUTPUTFORMAT > NAME "cairopng" > DRIVER CAIRO/PNG > MIMETYPE "image/png" > IMAGEMODE RGB > EXTENSION "png" > FORMATOPTION "ANTIALIAS=FALSE" > FORMATOPTION "QUANTIZE_FORCE=ON" > FORMATOPTION "QUANTIZE_COLORS=256" > FORMATOPTION "COMPRESSION=9" > END > > I used the msautotest/renderers/line_simple.map example to test and that > crushed the resulting png from 5920 bytes down to 947 bytes. > > HTH, Andreas > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From richard.greenwood at gmail.com Wed May 19 14:12:00 2021 From: richard.greenwood at gmail.com (Richard Greenwood) Date: Wed, 19 May 2021 15:12:00 -0600 Subject: [mapserver-users] anti-aliasing (was differing image size with different mapserver versions) In-Reply-To: <567bba35f96346a789582ff4d0e71d46@sid.sachsen.de> References: <1bd16f5cf38d4f8d836ecb5d7ec079d5@sid.sachsen.de> <567bba35f96346a789582ff4d0e71d46@sid.sachsen.de> Message-ID: Andreas, Very interesting. Your Cairo driver modifications create an image the same size as your AGG driver modification that disables AA, but with strikingly different appearance. Links to examples below. (The examples are pretty ugly but with some work on the styles in the map file they could significantly be improved) I have not tested performance yet. Again - thank you for your suggestions. https://greenwoodmap.com/cairo-aliased.png CAIRO/PNG ANTIALIAS=FALSE https://greenwoodmap.com/agg-aliased.png AGG/PNG8 renderer_scanline_bin_solid On Wed, May 19, 2021 at 9:15 AM Eichner, Andreas - SID < Andreas.Eichner at sid.sachsen.de> wrote: > If you want to give Cairo a try, you could modify mapcairo.c like this: > > diff --git a/mapcairo.c b/mapcairo.c > index 0f4cc094..d28947d6 100644 > --- a/mapcairo.c > +++ b/mapcairo.c > @@ -517,6 +517,12 @@ imageObj* createImageCairo(int width, int height, > outputFormatObj *format,colorO > > cairo_set_line_cap (r->cr,CAIRO_LINE_CAP_ROUND); > cairo_set_line_join(r->cr,CAIRO_LINE_JOIN_ROUND); > + { > + const char* antialias = msGetOutputFormatOption(format, > "ANTIALIAS", "TRUE"); > + if (EQUAL(antialias, "OFF") || EQUAL(antialias, "FALSE") || > EQUAL(antialias, "0")) { > + cairo_set_antialias(r->cr, CAIRO_ANTIALIAS_NONE); > + } > + } > image->img.plugin = (void*)r; > } else { > msSetError(MS_RENDERERERR, "Cannot create cairo image of size %dx%d.", > > This adds a FORMATOPTION "ANTIALIAS" to the CAIRO/*-Drivers that defaults > to TRUE. But when explicitly set to 0/OFF/FALSE it calls > cairo_set_antialias() to disable it. The raster buffer created by the CAIRO > renderer is passed to the PNG writer which enables COMPRESSION, > PALETTE_FORCE, QUANTIZE_FORCE. So you can combine it: > > OUTPUTFORMAT > NAME "cairopng" > DRIVER CAIRO/PNG > MIMETYPE "image/png" > IMAGEMODE RGB > EXTENSION "png" > FORMATOPTION "ANTIALIAS=FALSE" > FORMATOPTION "QUANTIZE_FORCE=ON" > FORMATOPTION "QUANTIZE_COLORS=256" > FORMATOPTION "COMPRESSION=9" > END > > I used the msautotest/renderers/line_simple.map example to test and that > crushed the resulting png from 5920 bytes down to 947 bytes. > > HTH, Andreas > > -----Urspr?ngliche Nachricht----- > Von: Richard Greenwood > Gesendet: Mittwoch, 19. Mai 2021 16:12 > An: Eichner, Andreas - SID > Cc: mapserver > Betreff: Re: [mapserver-users] anti-aliasing (was differing image size > with different mapserver versions) > > Andreas, > > I have built a version of MapServer without AA enabled in mapagg.cpp as > you have suggested. The reduction in file size is remarkable. In some cases > it is 1/2 the size of a GD/GIF or an optimized AGG/PNG8. Aesthetically the > images are pretty bad at first, but by softening the colors in the map file > and reducing the color contrast between adjacent features I'm getting > images that are acceptable. I will try experimenting with Cairo driver > modifications next. Thank you very much for your suggestion and detailed > explanation. > > Rich > > On Wed, May 19, 2021 at 5:38 AM Eichner, Andreas - SID < > Andreas.Eichner at sid.sachsen.de > > wrote: > > > What AGG does with it's sub-pixel accuracy can be viewed as > computing the contribution of the pixels of a virtually larger image to the > pixels of the final image. It uses a gamma function to translate the amount > of virtual pixels into an amount of visual impact on the final pixel - both > expressed as a value in the range 0..1. AGG's default is a linear function > that proportionally maps the range 0..1 onto 0..1 (i.e. y=x). MapServer > (where applied) uses a linear gamma function that proportionally maps the > range 0..gamma onto 0..1. All this results in intermediate color values > giving a smoother and visually improved result as in this example: > https://commons.wikimedia.org/wiki/File:Antialiasing.png#/media/Datei:Antialiasing.png > > As PNG uses lossless compression these additional information > enlarges the resulting files. So to reduce the size of your map image files > it's best to turn anti-aliasing off. One way is to compile a special > version with modified typedefs in mapagg.cpp to turn AA off. With Cairo you > could use the method cairo_set_antialias(cairo_t*, CAIRO_ANTIALIAS_NONE) to > switch it off. But then you would loose paletted image and compression > control. > > With the modified AGG you should still apply the other suggestions > with reduced palette and maximum compression. > > HTH > > > -----Urspr?ngliche Nachricht----- > Von: mapserver-users > Im Auftrag von Richard > Greenwood > Gesendet: Dienstag, 18. Mai 2021 18:50 > An: mapserver mapserver-users at lists.osgeo.org> > > Betreff: [mapserver-users] anti-aliasing (was differing image size > with different mapserver versions) > > Thanks to several helpful replies to my previous thread I know > that the increased image size between MapServer 6 with the GD driver and > MapServer 7 with the AGG driver is due to differences in anti-aliasing (and > lack of) in the two drivers. (AGG features anti-aliasing and sub-pixel > resolution ). > > Gamma setting from 0-1 affects the size of a filled polygon layer > by a factor of almost 3x. But gamma has no effect on text, lines, and > polygon outlines. So images comprised of these types of features are > approximately 2x larger with the AGG/PNG8 driver than with the GD/GIF > driver. > > Where else should I be looking to reduce my images sizes? I serve > rural areas with poor internet so in my case, smaller image sizes are more > important than higher quality images. > > Thanks, > Rich > > -- > > Richard W. Greenwood, PLS > www.greenwoodmap.com < > http://www.greenwoodmap.com> > > > > > -- > > Richard W. Greenwood, PLS > www.greenwoodmap.com > -- Richard W. Greenwood, PLS www.greenwoodmap.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From Andreas.Eichner at sid.sachsen.de Thu May 20 01:58:25 2021 From: Andreas.Eichner at sid.sachsen.de (Eichner, Andreas - SID) Date: Thu, 20 May 2021 08:58:25 +0000 Subject: [mapserver-users] anti-aliasing (was differing image size with different mapserver versions) In-Reply-To: References: <1bd16f5cf38d4f8d836ecb5d7ec079d5@sid.sachsen.de> <567bba35f96346a789582ff4d0e71d46@sid.sachsen.de> Message-ID: Well, anti-aliased maps look much better and are basically the way to go. But in some corner cases it would be great to be able to turn this feature off. Cairo provides a single switch to do that and a patch that enables control over that from within MapServer can be simple and straight forward. With a little more effort this can be extended to switch between all possible CAIRO_ANTIALIAS_* values. So IMHO integrating this option for the Cairo renderer seems to be a good idea. For the AGG renderer it requires more work to make this runtime controllable. @Richard: The difference between both renderers is impressive. Since you are using this with much more complex maps can you give some feedback which one which one looks "better" (with tuning applied) and how usable the result is? Regards, Andreas -----Urspr?ngliche Nachricht----- Von: Steve Lime Gesendet: Mittwoch, 19. Mai 2021 18:24 An: Eichner, Andreas - SID Cc: Richard Greenwood ; mapserver Betreff: Re: [mapserver-users] anti-aliasing (was differing image size with different mapserver versions) Worth adding to main? On Wed, May 19, 2021 at 10:15 AM Eichner, Andreas - SID > wrote: If you want to give Cairo a try, you could modify mapcairo.c like this: diff --git a/mapcairo.c b/mapcairo.c index 0f4cc094..d28947d6 100644 --- a/mapcairo.c +++ b/mapcairo.c @@ -517,6 +517,12 @@ imageObj* createImageCairo(int width, int height, outputFormatObj *format,colorO cairo_set_line_cap (r->cr,CAIRO_LINE_CAP_ROUND); cairo_set_line_join(r->cr,CAIRO_LINE_JOIN_ROUND); + { + const char* antialias = msGetOutputFormatOption(format, "ANTIALIAS", "TRUE"); + if (EQUAL(antialias, "OFF") || EQUAL(antialias, "FALSE") || EQUAL(antialias, "0")) { + cairo_set_antialias(r->cr, CAIRO_ANTIALIAS_NONE); + } + } image->img.plugin = (void*)r; } else { msSetError(MS_RENDERERERR, "Cannot create cairo image of size %dx%d.", This adds a FORMATOPTION "ANTIALIAS" to the CAIRO/*-Drivers that defaults to TRUE. But when explicitly set to 0/OFF/FALSE it calls cairo_set_antialias() to disable it. The raster buffer created by the CAIRO renderer is passed to the PNG writer which enables COMPRESSION, PALETTE_FORCE, QUANTIZE_FORCE. So you can combine it: OUTPUTFORMAT NAME "cairopng" DRIVER CAIRO/PNG MIMETYPE "image/png" IMAGEMODE RGB EXTENSION "png" FORMATOPTION "ANTIALIAS=FALSE" FORMATOPTION "QUANTIZE_FORCE=ON" FORMATOPTION "QUANTIZE_COLORS=256" FORMATOPTION "COMPRESSION=9" END I used the msautotest/renderers/line_simple.map example to test and that crushed the resulting png from 5920 bytes down to 947 bytes. HTH, Andreas From jmssnyder at ucdavis.edu Thu May 20 19:36:09 2021 From: jmssnyder at ucdavis.edu (Jason Snyder) Date: Thu, 20 May 2021 19:36:09 -0700 Subject: [mapserver-users] php map script for Centos Message-ID: How do I go about installing the php version of mapscript on a centos 7 or 8 machine? The manuals on how to do that are not 100 % clear. Thanks, Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: From jmssnyder at ucdavis.edu Fri May 21 14:12:09 2021 From: jmssnyder at ucdavis.edu (Jason Snyder) Date: Fri, 21 May 2021 14:12:09 -0700 Subject: [mapserver-users] php map script build/map server build Message-ID: To Whom it May Concern, I am encountering several issues with building mapserver and also the mapscript php utility. 1). When attempting to build mapserver I keep getting the error message: CheckFunctionExists.c:(.text+0x10): undefined reference to `strrstr' How do I resolve this issue? I noticed that string.h is being called by the utilities that use strrstr but why am I getting this weird error message? I tried to search for this error but cannot find any solid solutions to resolve this issue? Any ideas? 2) I am also trying to build the php mapscript but I do not see any make files or such for configuring the php mapscript. There is also no readme for building this in centos 7 or centos 8. How do I build php mapscript on centos 7 or centos 8? Thank you for your time. Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: From jmckenna at gatewaygeomatics.com Fri May 21 16:40:18 2021 From: jmckenna at gatewaygeomatics.com (Jeff McKenna) Date: Fri, 21 May 2021 20:40:18 -0300 Subject: [mapserver-users] php map script build/map server build In-Reply-To: References: Message-ID: <384d77d7-b13f-e146-76a7-4fd01e553f9d@gatewaygeomatics.com> Hi Jason, I'll try to respond, comments inline below: On 2021-05-21 6:12 p.m., Jason Snyder via mapserver-users wrote: > To Whom it May Concern, > > I am encountering several issues with building mapserver and also the > mapscript php utility. > > 1). When attempting to build mapserver I keep getting the error message: > > CheckFunctionExists.c:(.text+0x10): undefined reference to `strrstr' > > How do I resolve this issue?? I noticed that string.h is being called by > the utilities that use strrstr but why am I getting this weird error > message?? I tried to search for this error but cannot find any solid > solutions to resolve this issue?? Any ideas? When do you get that error? I assume this is during your 'cmake' command, if so I think there are some checks for strrstr and it should move on past that, and still generate a cmake log. Or is that error from the 'make' command instead? > > > 2) I am also trying to build the php mapscript but I do not see any make > files or such for configuring the php mapscript.? There is also > no?readme for building this in centos?7 or centos 8.? How do I build php > mapscript on centos 7 or centos 8? > Likely no readme or docs exist for CentOS, because no one has contributed that (or someone like me, who used to build on CentOS, has moved onto Ubuntu). So, contributions are welcomed, as you travel down this path (contribute at https://github.com/MapServer/MapServer-documentation ) But, make sure that you specify "-DWITH_PHPNG=1" in your cmake command, and that you have SWIG installed on that system (preferably SWIG >= 4). After you 'make' and then 'make install', you should follow the steps for PHP 7 at : https://mapserver.org/MIGRATION_GUIDE.html#mapserver-7-2-to-7-4-migration (regarding installing PHP7 on CentOS, you might also be required to install something like 'php-devel', but that's only a guess) Also, please be sure to build from a stable release archive, such as MapServer 7.6.3 Well I hope those notes give you a little help. Maybe others can jump in here as well to help. Wishing you a nice long weekend (it's a long weekend in Canada). Gotta think positive sometimes, even in the worst of times :) -jeff -- Jeff McKenna GatewayGeo: Developers of MS4W, MapServer Consulting and Training co-founder of FOSS4G http://gatewaygeo.com/ From richard.greenwood at gmail.com Sun May 23 13:06:25 2021 From: richard.greenwood at gmail.com (Richard Greenwood) Date: Sun, 23 May 2021 14:06:25 -0600 Subject: [mapserver-users] anti-aliasing (was differing image size with different mapserver versions) In-Reply-To: References: <1bd16f5cf38d4f8d836ecb5d7ec079d5@sid.sachsen.de> <567bba35f96346a789582ff4d0e71d46@sid.sachsen.de> Message-ID: I did some testing and summarized my results in this Google spreadsheet . My initial goal was to switch from MapServer 6 to 7, and thus from GIF to PNG since the GD/GIF driver is gone in MapServer 7. I'm looking for a palleted PNG format similar in size to GIF. PNG uses sub-pixel anti-aliasing which makes images larger than GIFs which uses color interpolation to anti-alias. MapServer 7 does not have a built-in mechanism to disable anti-aliasing in either the AGG or Cairo drivers but with minor modifications to the source code it can be disabled. The spreadsheet compares five output formats: GD/GIF, AGG/PNG8, AGG/PNG8 w/o anti-aliasing, Cairo/PNG8, and Cairo/PNG8 w/o anti-aliasing. I used three different source maps with significantly different content (they're linked in the spreadsheet). Not surprisingly, the PNG8 images look the best, GIF looks okay, and images without anti-aliasing look pretty poor. The size of the images generally corresponds to the visual quality. In other words, I did not find any magic way to consistently make really nice, really small images. But depending on the content there are some ways to significantly reduce size and still get a nice looking image. The spreadsheet includes some timing tests. I did these with Apache Bench, they're not especially rigorous. Thanks to all who commented on this thread, I learned quite a bit. Rich On Thu, May 20, 2021 at 2:58 AM Eichner, Andreas - SID < Andreas.Eichner at sid.sachsen.de> wrote: > Well, anti-aliased maps look much better and are basically the way to go. > But in some corner cases it would be great to be able to turn this feature > off. Cairo provides a single switch to do that and a patch that enables > control over that from within MapServer can be simple and straight forward. > With a little more effort this can be extended to switch between all > possible CAIRO_ANTIALIAS_* values. So IMHO integrating this option for the > Cairo renderer seems to be a good idea. For the AGG renderer it requires > more work to make this runtime controllable. > > @Richard: The difference between both renderers is impressive. Since you > are using this with much more complex maps can you give some feedback which > one which one looks "better" (with tuning applied) and how usable the > result is? > > Regards, Andreas > > -----Urspr?ngliche Nachricht----- > Von: Steve Lime > Gesendet: Mittwoch, 19. Mai 2021 18:24 > An: Eichner, Andreas - SID > Cc: Richard Greenwood ; mapserver < > mapserver-users at lists.osgeo.org> > Betreff: Re: [mapserver-users] anti-aliasing (was differing image size > with different mapserver versions) > > Worth adding to main? > > On Wed, May 19, 2021 at 10:15 AM Eichner, Andreas - SID < > Andreas.Eichner at sid.sachsen.de > > wrote: > > > If you want to give Cairo a try, you could modify mapcairo.c like > this: > > diff --git a/mapcairo.c b/mapcairo.c > index 0f4cc094..d28947d6 100644 > --- a/mapcairo.c > +++ b/mapcairo.c > @@ -517,6 +517,12 @@ imageObj* createImageCairo(int width, int > height, outputFormatObj *format,colorO > > cairo_set_line_cap (r->cr,CAIRO_LINE_CAP_ROUND); > cairo_set_line_join(r->cr,CAIRO_LINE_JOIN_ROUND); > + { > + const char* antialias = msGetOutputFormatOption(format, > "ANTIALIAS", "TRUE"); > + if (EQUAL(antialias, "OFF") || EQUAL(antialias, "FALSE") > || EQUAL(antialias, "0")) { > + cairo_set_antialias(r->cr, CAIRO_ANTIALIAS_NONE); > + } > + } > image->img.plugin = (void*)r; > } else { > msSetError(MS_RENDERERERR, "Cannot create cairo image of size > %dx%d.", > > This adds a FORMATOPTION "ANTIALIAS" to the CAIRO/*-Drivers that > defaults to TRUE. But when explicitly set to 0/OFF/FALSE it calls > cairo_set_antialias() to disable it. The raster buffer created by the CAIRO > renderer is passed to the PNG writer which enables COMPRESSION, > PALETTE_FORCE, QUANTIZE_FORCE. So you can combine it: > > OUTPUTFORMAT > NAME "cairopng" > DRIVER CAIRO/PNG > MIMETYPE "image/png" > IMAGEMODE RGB > EXTENSION "png" > FORMATOPTION "ANTIALIAS=FALSE" > FORMATOPTION "QUANTIZE_FORCE=ON" > FORMATOPTION "QUANTIZE_COLORS=256" > FORMATOPTION "COMPRESSION=9" > END > > I used the msautotest/renderers/line_simple.map example to test > and that crushed the resulting png from 5920 bytes down to 947 bytes. > > HTH, Andreas > > > > -- Richard W. Greenwood, PLS www.greenwoodmap.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From sethg at geographika.co.uk Mon May 24 13:42:13 2021 From: sethg at geographika.co.uk (Seth G) Date: Mon, 24 May 2021 22:42:13 +0200 Subject: [mapserver-users] Embedded LEGEND Transparency Message-ID: <847dc4b7-d8f7-463c-a188-8983b6bd4de4@www.fastmail.com> Hi all, The LEGEND TRANSPARENT keyword [1] has been deprecated since version 4.6 of MapServer and was planned to be removed for version 8.0. However, there is a use case which I can't recreate using the OUTPUTFORMAT TRANSPARENT ON setting. The MAP itself has an IMAGECOLOR e.g. 255 200 0 (yellow), however an embeded LEGEND should be TRANSPARENT. Setting TRANSPARENT ON in the OUTPUTFORMAT makes both map and legend transparent. Leaving it off and the map and legend both have yellow backgrounds, and the area under the legend is no longer visible. This is one of the test cases [2] in msautotest. A similar issue seems to apply to SCALEBAR. Does anyone have a way to recreate this? If not then it probably makes sense to un-deprecate the TRANPARENT keywork for LEGEND and SCALEBAR. Seth [1] https://mapserver.org/mapfile/legend.html#mapfile-legend-transparent [2] https://github.com/MapServer/MapServer/blob/main/msautotest/renderers/embed_legend_tr.map -- web:http://geographika.co.uk twitter: @geographika From mgrudzien7 at gmail.com Tue May 25 01:55:58 2021 From: mgrudzien7 at gmail.com (=?UTF-8?Q?Marcin_Grudzie=C5=84?=) Date: Tue, 25 May 2021 10:55:58 +0200 Subject: [mapserver-users] Setting up a template for custom WFS GetFeature response Message-ID: Hello, I have been trying to set up INSPIRE WFS service publishing data in GML that validates against INSPIRE GML application schemas. To achieve that I use template-driven output, basically following https://mapserver.org/fr/output/template_output.html. However, I am not able to force MapServer to use my GetFeature response template. GetFeature response always returns ?standard? MapServer GML, which of course, is not INSPIRE compliant. Below you can find my configuration details. I am using 7.6.3 version build on Ubuntu 20.04 LTR mapserv -v returns MapServer version 7.6.3 OUTPUT=PNG OUTPUT=JPEG SUPPORTS=PROJ SUPPORTS=AGG SUPPORTS=FREETYPE SUPPORTS=CAIRO SUPPORTS=ICONV SUPPORTS=FRIBIDI SUPPORTS=WMS_SERVER SUPPORTS=WFS_SERVER SUPPORTS=WCS_SERVER SUPPORTS=FASTCGI SUPPORTS=GEOS SUPPORTS=POINT_Z_M SUPPORTS=PBF INPUT=JPEG INPUT=POSTGIS INPUT=OGR INPUT=GDAL INPUT=SHAPEFILE My mapfile looks like this MAP NAME "LandCover" STATUS ON EXTENT 160828.34326572 98928.8977745594 876029.97009323 796521.669409553 UNITS meters SIZE 100 100 MAXSIZE 4000 FONTSET "/srv/Fonts/Fontset.txt" CONFIG "MS_ERRORFILE" "/srv/lc/error_lc_wfs.txt" DEBUG 5 PROJECTION "init=epsg:2180" END OUTPUTFORMAT NAME "gml" DRIVER "TEMPLATE" #MIMETYPE "text/xml; subtype=gml/3.2.1" FORMATOPTION "FILE=LC_template.gml" END WEB METADATA "ows_inspire_capabilities" "url" "ows_languages" "pol,eng" "ows_title" "Title PL" "ows_title.eng" "WFS service with INSPIRE Land Cover" "ows_abstract" "Abstract PL" "ows_abstract.eng" "WMS service publishes harmonised INSPIRE Land Cover data set derrived from BDOT10k as-is data set " "ows_fees" "Brak op?at" "ows_fees.eng" "No fee applies" WFS_ONLINERESOURCE "http://localhost/cgi-bin/LC_WFS" "wfs_getfeature_formatlist" "gml" "wfs_inspire_metadataurl_href" "someurl" "wfs_inspire_metadataurl_format" "application/vnd.ogc.csw.GetRecordByIdResponse_xml" "ows_inspire_dsid_code" "LC " "ows_inspire_dsid_ns" "LC.3.2" "wfs_enable_request" "*" "wfs_srs" "EPSG:2180 EPSG:4326 EPSG:3857 EPSG:4528" END END #WEB LAYER NAME "LC.LandCoverUnit" STATUS ON CONNECTIONTYPE POSTGIS CONNECTION "host=localhost dbname=postgis_db user=user password=password port=5432" DATA "geom from bdot.landcoversurface using unique objectid using srid=2180" PROJECTION "init=epsg:2180" END TYPE POLYGON PROCESSING "CLOSE_CONNECTION=DEFER" TEMPLATE "LC_template.gml" METADATA "ows_title.pol" "LC.LandCoverUnit" "ows_title.eng" "LC.LandCoverUnit" WFS_EXTENT "160828.34326572 98928.8977745594 876029.97009323 796521.669409553" "gml_include_items" "all" "gml_featureid" "objectid" "wfs_getfeature_formatlist" "gml" "wfs_enable_request" "*" "wfs_connectiontimeout" "120" "wfs_maxfeatures" "10000" "wfs_srs" "EPSG:2180 EPSG:4326 EPSG:3857 EPSG:4528" "wfs_metadataurl_href" "someurl" "wfs_inspire_metadataurl_format" "application/xml" "wfs_metadataurl_type" "TC211" END #METADATA END #LAYER END #MAP I tried different OUTPUTFORMAT configurations with different NAME, MIMETYPE parameter values. And nothing has worked. On the same machine, I successfully published WMS service returning HTML GetFeatureInfo response customized utilizing the very same template-driven output concept. I suspect that I may be missing something in the configuration file. I would be grateful for any suggestions. Best regards, Marcin -------------- next part -------------- An HTML attachment was scrubbed... URL: From sethg at geographika.co.uk Tue May 25 02:02:52 2021 From: sethg at geographika.co.uk (Seth G) Date: Tue, 25 May 2021 11:02:52 +0200 Subject: [mapserver-users] =?utf-8?q?Setting_up_a_template_for_custom_WFS?= =?utf-8?q?_GetFeature_response?= In-Reply-To: References: Message-ID: Hi Marcin, What does your GetFeature request look like? Seth -- web:http://geographika.co.uk twitter: @geographika On Tue, May 25, 2021, at 10:55 AM, Marcin Grudzie? wrote: > Hello, > > I have been trying to set up INSPIRE WFS service publishing data in GML that validates against INSPIRE GML application schemas. To achieve that I use template-driven output, basically following https://mapserver.org/fr/output/template_output.html. However, I am not able to force MapServer to use my GetFeature response template. GetFeature response always returns ?standard? MapServer GML, which of course, is not INSPIRE compliant. > > Below you can find my configuration details. > I am using 7.6.3 version build on Ubuntu 20.04 LTR > mapserv -v returns > MapServer version 7.6.3 OUTPUT=PNG OUTPUT=JPEG SUPPORTS=PROJ SUPPORTS=AGG SUPPORTS=FREETYPE SUPPORTS=CAIRO SUPPORTS=ICONV SUPPORTS=FRIBIDI SUPPORTS=WMS_SERVER SUPPORTS=WFS_SERVER SUPPORTS=WCS_SERVER SUPPORTS=FASTCGI SUPPORTS=GEOS SUPPORTS=POINT_Z_M SUPPORTS=PBF INPUT=JPEG INPUT=POSTGIS INPUT=OGR INPUT=GDAL INPUT=SHAPEFILE > > My mapfile looks like this > MAP > NAME "LandCover" > STATUS ON > EXTENT 160828.34326572 98928.8977745594 876029.97009323 796521.669409553 > UNITS meters > SIZE 100 100 > MAXSIZE 4000 > FONTSET "/srv/Fonts/Fontset.txt" > CONFIG "MS_ERRORFILE" "/srv/lc/error_lc_wfs.txt" > DEBUG 5 > > PROJECTION > "init=epsg:2180" > > END > > OUTPUTFORMAT > NAME "gml" > DRIVER "TEMPLATE" > #MIMETYPE "text/xml; subtype=gml/3.2.1" > FORMATOPTION "FILE=LC_template.gml" > END > > WEB > METADATA > "ows_inspire_capabilities" "url" > "ows_languages" "pol,eng" > "ows_title" "Title PL" > "ows_title.eng" "WFS service with INSPIRE Land Cover" > "ows_abstract" "Abstract PL" > "ows_abstract.eng" "WMS service publishes harmonised INSPIRE Land Cover data set derrived from BDOT10k as-is data set " > "ows_fees" "Brak op?at" > "ows_fees.eng" "No fee applies" > WFS_ONLINERESOURCE "http://localhost/cgi-bin/LC_WFS" > "wfs_getfeature_formatlist" "gml" > "wfs_inspire_metadataurl_href" "someurl" > "wfs_inspire_metadataurl_format" "application/vnd.ogc.csw.GetRecordByIdResponse_xml" > > "ows_inspire_dsid_code" "LC " > "ows_inspire_dsid_ns" "LC.3.2" > > "wfs_enable_request" "*" > "wfs_srs" "EPSG:2180 EPSG:4326 EPSG:3857 EPSG:4528" > END > > END #WEB > > LAYER > NAME "LC.LandCoverUnit" > STATUS ON > CONNECTIONTYPE POSTGIS > CONNECTION "host=localhost dbname=postgis_db user=user password=password port=5432" > DATA "geom from bdot.landcoversurface using unique objectid using srid=2180" > > PROJECTION > "init=epsg:2180" > END > > TYPE POLYGON > PROCESSING "CLOSE_CONNECTION=DEFER" > TEMPLATE "LC_template.gml" > METADATA > "ows_title.pol" "LC.LandCoverUnit" > "ows_title.eng" "LC.LandCoverUnit" > WFS_EXTENT "160828.34326572 98928.8977745594 876029.97009323 796521.669409553" > "gml_include_items" "all" > "gml_featureid" "objectid" > "wfs_getfeature_formatlist" "gml" > "wfs_enable_request" "*" > "wfs_connectiontimeout" "120" > "wfs_maxfeatures" "10000" > "wfs_srs" "EPSG:2180 EPSG:4326 EPSG:3857 EPSG:4528" > "wfs_metadataurl_href" "someurl" > "wfs_inspire_metadataurl_format" "application/xml" > "wfs_metadataurl_type" "TC211" > END #METADATA > > END #LAYER > > END #MAP > > I tried different OUTPUTFORMAT configurations with different NAME, MIMETYPE parameter values. And nothing has worked. > On the same machine, I successfully published WMS service returning HTML GetFeatureInfo response customized utilizing the very same template-driven output concept. > I suspect that I may be missing something in the configuration file. I would be grateful for any suggestions. > > Best regards, > Marcin > > _______________________________________________ > 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 jpass at bgs.ac.uk Tue May 25 02:16:27 2021 From: jpass at bgs.ac.uk (Passmore, James H.) Date: Tue, 25 May 2021 09:16:27 +0000 Subject: [mapserver-users] Setting up a template for custom WFS Message-ID: Hi Marcin, As far as I am aware, it is not possible to serve up an INSPIRE compliant (complex feature) WFS with MapServer. James Passmore ------------------------------- British Geological Survey, Environmental Science Centre, KEYWORTH, United Kingdom, NG12 5GG orcid: https://orcid.org/0000-0002-9891-6265 ------------------------------- Phone: +44 (0)115 936 3125 ------------------------------- Skype: BGSjames This email and any attachments are intended solely for the use of the named recipients. If you are not the intended recipient you must not use, disclose, copy or distribute this email or any of its attachments and should notify the sender immediately and delete this email from your system. UK Research and Innovation (UKRI) has taken every reasonable precaution to minimise risk of this email or any attachments containing viruses or malware but the recipient should carry out its own virus and malware checks before opening the attachments. UKRI does not accept any liability for any losses or damages which the recipient may sustain due to presence of any viruses. Opinions, conclusions or other information in this message and attachments that are not related directly to UKRI business are solely those of the author and do not represent the views of UKRI. From mgrudzien7 at gmail.com Tue May 25 02:20:29 2021 From: mgrudzien7 at gmail.com (=?UTF-8?Q?Marcin_Grudzie=C5=84?=) Date: Tue, 25 May 2021 11:20:29 +0200 Subject: [mapserver-users] mapserver-users Digest, Vol 160, Issue 28 In-Reply-To: References: Message-ID: Hi Seth, It is very basic WFS GetFeature request http://localhost/cgi-bin/mapserv?map=/srv/lc/LC_wfs.map&SERVICE=WFS&REQUEST=GetFeature&VERSION=2.0.0&COUNT=10&TYPENAMES=LC.LandCoverUnit On Tue, 25 May 2021 at 11:03, wrote: > Send mapserver-users mailing list submissions to > mapserver-users at lists.osgeo.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.osgeo.org/mailman/listinfo/mapserver-users > or, via email, send a message with subject or body 'help' to > mapserver-users-request at lists.osgeo.org > > You can reach the person managing the list at > mapserver-users-owner at lists.osgeo.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of mapserver-users digest..." > > > Today's Topics: > > 1. Re: Setting up a template for custom WFS GetFeature response > (Seth G) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 25 May 2021 11:02:52 +0200 > From: "Seth G" > To: mapserver-users at lists.osgeo.org > Subject: Re: [mapserver-users] Setting up a template for custom WFS > GetFeature response > Message-ID: > Content-Type: text/plain; charset="utf-8" > > Hi Marcin, > > What does your GetFeature request look like? > > Seth > > -- > web:http://geographika.co.uk > twitter: @geographika > > > On Tue, May 25, 2021, at 10:55 AM, Marcin Grudzie? wrote: > > Hello, > > > > > > I have been trying to set up INSPIRE WFS service publishing data in GML > that validates against INSPIRE GML application schemas. To achieve that I > use template-driven output, basically following > https://mapserver.org/fr/output/template_output.html. However, I am not > able to force MapServer to use my GetFeature response template. GetFeature > response always returns ?standard? MapServer GML, which of course, is not > INSPIRE compliant. > > > > > > Below you can find my configuration details. > > > I am using 7.6.3 version build on Ubuntu 20.04 LTR > > > mapserv -v returns > > > MapServer version 7.6.3 OUTPUT=PNG OUTPUT=JPEG SUPPORTS=PROJ > SUPPORTS=AGG SUPPORTS=FREETYPE SUPPORTS=CAIRO SUPPORTS=ICONV > SUPPORTS=FRIBIDI SUPPORTS=WMS_SERVER SUPPORTS=WFS_SERVER > SUPPORTS=WCS_SERVER SUPPORTS=FASTCGI SUPPORTS=GEOS SUPPORTS=POINT_Z_M > SUPPORTS=PBF INPUT=JPEG INPUT=POSTGIS INPUT=OGR INPUT=GDAL INPUT=SHAPEFILE > > > > > > My mapfile looks like this > > > MAP > > > NAME "LandCover" > > > STATUS ON > > > EXTENT 160828.34326572 98928.8977745594 876029.97009323 796521.669409553 > > > UNITS meters > > > SIZE 100 100 > > > MAXSIZE 4000 > > > FONTSET "/srv/Fonts/Fontset.txt" > > > CONFIG "MS_ERRORFILE" "/srv/lc/error_lc_wfs.txt" > > > DEBUG 5 > > > > > > PROJECTION > > > "init=epsg:2180" > > > > > > END > > > > > > OUTPUTFORMAT > > > NAME "gml" > > > DRIVER "TEMPLATE" > > > #MIMETYPE "text/xml; subtype=gml/3.2.1" > > > FORMATOPTION "FILE=LC_template.gml" > > > END > > > > > > WEB > > > METADATA > > > "ows_inspire_capabilities" "url" > > > "ows_languages" "pol,eng" > > > "ows_title" "Title PL" > > > "ows_title.eng" "WFS service with INSPIRE Land Cover" > > > "ows_abstract" "Abstract PL" > > > "ows_abstract.eng" "WMS service publishes harmonised INSPIRE Land Cover > data set derrived from BDOT10k as-is data set " > > > "ows_fees" "Brak op?at" > > > "ows_fees.eng" "No fee applies" > > > WFS_ONLINERESOURCE "http://localhost/cgi-bin/LC_WFS" > > > "wfs_getfeature_formatlist" "gml" > > > "wfs_inspire_metadataurl_href" "someurl" > > > "wfs_inspire_metadataurl_format" > "application/vnd.ogc.csw.GetRecordByIdResponse_xml" > > > > > > "ows_inspire_dsid_code" "LC " > > > "ows_inspire_dsid_ns" "LC.3.2" > > > > > > "wfs_enable_request" "*" > > > "wfs_srs" "EPSG:2180 EPSG:4326 EPSG:3857 EPSG:4528" > > > END > > > > > > END #WEB > > > > > > LAYER > > > NAME "LC.LandCoverUnit" > > > STATUS ON > > > CONNECTIONTYPE POSTGIS > > > CONNECTION "host=localhost dbname=postgis_db user=user > password=password port=5432" > > > DATA "geom from bdot.landcoversurface using unique objectid > using srid=2180" > > > > > > PROJECTION > > > "init=epsg:2180" > > > END > > > > > > TYPE POLYGON > > > PROCESSING "CLOSE_CONNECTION=DEFER" > > > TEMPLATE "LC_template.gml" > > > METADATA > > > "ows_title.pol" "LC.LandCoverUnit" > > > "ows_title.eng" "LC.LandCoverUnit" > > > WFS_EXTENT "160828.34326572 98928.8977745594 > 876029.97009323 796521.669409553" > > > "gml_include_items" "all" > > > "gml_featureid" "objectid" > > > "wfs_getfeature_formatlist" "gml" > > > "wfs_enable_request" "*" > > > "wfs_connectiontimeout" "120" > > > "wfs_maxfeatures" "10000" > > > "wfs_srs" "EPSG:2180 EPSG:4326 EPSG:3857 > EPSG:4528" > > > "wfs_metadataurl_href" "someurl" > > > "wfs_inspire_metadataurl_format" > "application/xml" > > > "wfs_metadataurl_type" "TC211" > > > END #METADATA > > > > > > END #LAYER > > > > > > END #MAP > > > > > > I tried different OUTPUTFORMAT configurations with different NAME, > MIMETYPE parameter values. And nothing has worked. > > > On the same machine, I successfully published WMS service returning HTML > GetFeatureInfo response customized utilizing the very same template-driven > output concept. > > > I suspect that I may be missing something in the configuration file. I > would be grateful for any suggestions. > > > > > > Best regards, > > > Marcin > > > > > > _______________________________________________ > > mapserver-users mailing list > > mapserver-users at lists.osgeo.org mapserver-users%40lists.osgeo.org> > > https://lists.osgeo.org/mailman/listinfo/mapserver-users > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://lists.osgeo.org/pipermail/mapserver-users/attachments/20210525/41fcc396/attachment.html > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > mapserver-users mailing list > mapserver-users at lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/mapserver-users > > > ------------------------------ > > End of mapserver-users Digest, Vol 160, Issue 28 > ************************************************ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sethg at geographika.co.uk Tue May 25 03:24:29 2021 From: sethg at geographika.co.uk (Seth G) Date: Tue, 25 May 2021 12:24:29 +0200 Subject: [mapserver-users] mapserver-users Digest, Vol 160, Issue 28 In-Reply-To: References: Message-ID: <0602fb51-00c1-49df-859c-749e492ad8c1@www.fastmail.com> If you add &OUTPUTFORMAT=gml do you get a different result? -- web:http://geographika.co.uk twitter: @geographika On Tue, May 25, 2021, at 11:20 AM, Marcin Grudzie? wrote: > Hi Seth, > > It is very basic WFS GetFeature request http://localhost/cgi-bin/mapserv?map=/srv/lc/LC_wfs.map&SERVICE=WFS&REQUEST=GetFeature&VERSION=2.0.0&COUNT=10&TYPENAMES=LC.LandCoverUnit > > On Tue, 25 May 2021 at 11:03, wrote: >> Send mapserver-users mailing list submissions to >> mapserver-users at lists.osgeo.org >> >> To subscribe or unsubscribe via the World Wide Web, visit >> https://lists.osgeo.org/mailman/listinfo/mapserver-users >> or, via email, send a message with subject or body 'help' to >> mapserver-users-request at lists.osgeo.org >> >> You can reach the person managing the list at >> mapserver-users-owner at lists.osgeo.org >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of mapserver-users digest..." >> >> >> Today's Topics: >> >> 1. Re: Setting up a template for custom WFS GetFeature response >> (Seth G) >> >> >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Tue, 25 May 2021 11:02:52 +0200 >> From: "Seth G" >> To: mapserver-users at lists.osgeo.org >> Subject: Re: [mapserver-users] Setting up a template for custom WFS >> GetFeature response >> Message-ID: >> Content-Type: text/plain; charset="utf-8" >> >> Hi Marcin, >> >> What does your GetFeature request look like? >> >> Seth >> >> -- >> web:http://geographika.co.uk >> twitter: @geographika >> >> >> On Tue, May 25, 2021, at 10:55 AM, Marcin Grudzie? wrote: >> > Hello, >> >> > >> >> > I have been trying to set up INSPIRE WFS service publishing data in GML that validates against INSPIRE GML application schemas. To achieve that I use template-driven output, basically following https://mapserver.org/fr/output/template_output.html. However, I am not able to force MapServer to use my GetFeature response template. GetFeature response always returns ?standard? MapServer GML, which of course, is not INSPIRE compliant. >> >> > >> >> > Below you can find my configuration details. >> >> > I am using 7.6.3 version build on Ubuntu 20.04 LTR >> >> > mapserv -v returns >> >> > MapServer version 7.6.3 OUTPUT=PNG OUTPUT=JPEG SUPPORTS=PROJ SUPPORTS=AGG SUPPORTS=FREETYPE SUPPORTS=CAIRO SUPPORTS=ICONV SUPPORTS=FRIBIDI SUPPORTS=WMS_SERVER SUPPORTS=WFS_SERVER SUPPORTS=WCS_SERVER SUPPORTS=FASTCGI SUPPORTS=GEOS SUPPORTS=POINT_Z_M SUPPORTS=PBF INPUT=JPEG INPUT=POSTGIS INPUT=OGR INPUT=GDAL INPUT=SHAPEFILE >> >> > >> >> > My mapfile looks like this >> >> > MAP >> >> > NAME "LandCover" >> >> > STATUS ON >> >> > EXTENT 160828.34326572 98928.8977745594 876029.97009323 796521.669409553 >> >> > UNITS meters >> >> > SIZE 100 100 >> >> > MAXSIZE 4000 >> >> > FONTSET "/srv/Fonts/Fontset.txt" >> >> > CONFIG "MS_ERRORFILE" "/srv/lc/error_lc_wfs.txt" >> >> > DEBUG 5 >> >> > >> >> > PROJECTION >> >> > "init=epsg:2180" >> >> > >> >> > END >> >> > >> >> > OUTPUTFORMAT >> >> > NAME "gml" >> >> > DRIVER "TEMPLATE" >> >> > #MIMETYPE "text/xml; subtype=gml/3.2.1" >> >> > FORMATOPTION "FILE=LC_template.gml" >> >> > END >> >> > >> >> > WEB >> >> > METADATA >> >> > "ows_inspire_capabilities" "url" >> >> > "ows_languages" "pol,eng" >> >> > "ows_title" "Title PL" >> >> > "ows_title.eng" "WFS service with INSPIRE Land Cover" >> >> > "ows_abstract" "Abstract PL" >> >> > "ows_abstract.eng" "WMS service publishes harmonised INSPIRE Land Cover data set derrived from BDOT10k as-is data set " >> >> > "ows_fees" "Brak op?at" >> >> > "ows_fees.eng" "No fee applies" >> >> > WFS_ONLINERESOURCE "http://localhost/cgi-bin/LC_WFS" >> >> > "wfs_getfeature_formatlist" "gml" >> >> > "wfs_inspire_metadataurl_href" "someurl" >> >> > "wfs_inspire_metadataurl_format" "application/vnd.ogc.csw.GetRecordByIdResponse_xml" >> >> > >> >> > "ows_inspire_dsid_code" "LC " >> >> > "ows_inspire_dsid_ns" "LC.3.2" >> >> > >> >> > "wfs_enable_request" "*" >> >> > "wfs_srs" "EPSG:2180 EPSG:4326 EPSG:3857 EPSG:4528" >> >> > END >> >> > >> >> > END #WEB >> >> > >> >> > LAYER >> >> > NAME "LC.LandCoverUnit" >> >> > STATUS ON >> >> > CONNECTIONTYPE POSTGIS >> >> > CONNECTION "host=localhost dbname=postgis_db user=user password=password port=5432" >> >> > DATA "geom from bdot.landcoversurface using unique objectid using srid=2180" >> >> > >> >> > PROJECTION >> >> > "init=epsg:2180" >> >> > END >> >> > >> >> > TYPE POLYGON >> >> > PROCESSING "CLOSE_CONNECTION=DEFER" >> >> > TEMPLATE "LC_template.gml" >> >> > METADATA >> >> > "ows_title.pol" "LC.LandCoverUnit" >> >> > "ows_title.eng" "LC.LandCoverUnit" >> >> > WFS_EXTENT "160828.34326572 98928.8977745594 876029.97009323 796521.669409553" >> >> > "gml_include_items" "all" >> >> > "gml_featureid" "objectid" >> >> > "wfs_getfeature_formatlist" "gml" >> >> > "wfs_enable_request" "*" >> >> > "wfs_connectiontimeout" "120" >> >> > "wfs_maxfeatures" "10000" >> >> > "wfs_srs" "EPSG:2180 EPSG:4326 EPSG:3857 EPSG:4528" >> >> > "wfs_metadataurl_href" "someurl" >> >> > "wfs_inspire_metadataurl_format" "application/xml" >> >> > "wfs_metadataurl_type" "TC211" >> >> > END #METADATA >> >> > >> >> > END #LAYER >> >> > >> >> > END #MAP >> >> > >> >> > I tried different OUTPUTFORMAT configurations with different NAME, MIMETYPE parameter values. And nothing has worked. >> >> > On the same machine, I successfully published WMS service returning HTML GetFeatureInfo response customized utilizing the very same template-driven output concept. >> >> > I suspect that I may be missing something in the configuration file. I would be grateful for any suggestions. >> >> > >> >> > Best regards, >> >> > Marcin >> >> > >> >> > _______________________________________________ >> > 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: >> >> ------------------------------ >> >> Subject: Digest Footer >> >> _______________________________________________ >> mapserver-users mailing list >> mapserver-users at lists.osgeo.org >> https://lists.osgeo.org/mailman/listinfo/mapserver-users >> >> >> ------------------------------ >> >> End of mapserver-users Digest, Vol 160, Issue 28 >> ************************************************ > _______________________________________________ > 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 mgrudzien7 at gmail.com Tue May 25 04:06:46 2021 From: mgrudzien7 at gmail.com (=?utf-8?Q?Marcin_Grudzie=C5=84?=) Date: Tue, 25 May 2021 13:06:46 +0200 Subject: [mapserver-users] mapserver-users Digest, Vol 160, Issue 28 In-Reply-To: <0602fb51-00c1-49df-859c-749e492ad8c1@www.fastmail.com> References: <0602fb51-00c1-49df-859c-749e492ad8c1@www.fastmail.com> Message-ID: N?w it works, thank you. I must have done something wrong, when I was testing it before. However, the ?gml" as a possible output format is not mentioned in GetCapabilities response. The server returns ?standard? list of supported formats application/gml+xml; version=3.2 text/xml; subtype=gml/3.2.1 text/xml; subtype=gml/3.1.1 text/xml; subtype=gml/2.1.2 Secondly, is it possible to setup MapServer to return customized GML in GetFeature responses using default value (according to OGC WFS 2.0.0 specification) of OUTPUTFORMAT parameter ?application/gml+xml; version=3.2?? > Wiadomo?? napisana przez Seth G w dniu 25.05.2021, o godz. 12:24: > > If you add &OUTPUTFORMAT=gml do you get a different result? > > -- > web:http://geographika.co.uk > twitter: @geographika > > > On Tue, May 25, 2021, at 11:20 AM, Marcin Grudzie? wrote: >> Hi Seth, >> >> It is very basic WFS GetFeature request http://localhost/cgi-bin/mapserv?map=/srv/lc/LC_wfs.map&SERVICE=WFS&REQUEST=GetFeature&VERSION=2.0.0&COUNT=10&TYPENAMES=LC.LandCoverUnit >> >> On Tue, 25 May 2021 at 11:03, > wrote: >> Send mapserver-users mailing list submissions to >> mapserver-users at lists.osgeo.org >> >> To subscribe or unsubscribe via the World Wide Web, visit >> https://lists.osgeo.org/mailman/listinfo/mapserver-users >> or, via email, send a message with subject or body 'help' to >> mapserver-users-request at lists.osgeo.org >> >> You can reach the person managing the list at >> mapserver-users-owner at lists.osgeo.org >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of mapserver-users digest..." >> >> >> Today's Topics: >> >> 1. Re: Setting up a template for custom WFS GetFeature response >> (Seth G) >> >> >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Tue, 25 May 2021 11:02:52 +0200 >> From: "Seth G" > >> To: mapserver-users at lists.osgeo.org >> Subject: Re: [mapserver-users] Setting up a template for custom WFS >> GetFeature response >> Message-ID: > >> Content-Type: text/plain; charset="utf-8" >> >> Hi Marcin, >> >> What does your GetFeature request look like? >> >> Seth >> >> -- >> web:http://geographika.co.uk >> twitter: @geographika >> >> >> On Tue, May 25, 2021, at 10:55 AM, Marcin Grudzie? wrote: >> > Hello, >> >> > >> >> > I have been trying to set up INSPIRE WFS service publishing data in GML that validates against INSPIRE GML application schemas. To achieve that I use template-driven output, basically following https://mapserver.org/fr/output/template_output.html . However, I am not able to force MapServer to use my GetFeature response template. GetFeature response always returns ?standard? MapServer GML, which of course, is not INSPIRE compliant. >> >> > >> >> > Below you can find my configuration details. >> >> > I am using 7.6.3 version build on Ubuntu 20.04 LTR >> >> > mapserv -v returns >> >> > MapServer version 7.6.3 OUTPUT=PNG OUTPUT=JPEG SUPPORTS=PROJ SUPPORTS=AGG SUPPORTS=FREETYPE SUPPORTS=CAIRO SUPPORTS=ICONV SUPPORTS=FRIBIDI SUPPORTS=WMS_SERVER SUPPORTS=WFS_SERVER SUPPORTS=WCS_SERVER SUPPORTS=FASTCGI SUPPORTS=GEOS SUPPORTS=POINT_Z_M SUPPORTS=PBF INPUT=JPEG INPUT=POSTGIS INPUT=OGR INPUT=GDAL INPUT=SHAPEFILE >> >> > >> >> > My mapfile looks like this >> >> > MAP >> >> > NAME "LandCover" >> >> > STATUS ON >> >> > EXTENT 160828.34326572 98928.8977745594 876029.97009323 796521.669409553 >> >> > UNITS meters >> >> > SIZE 100 100 >> >> > MAXSIZE 4000 >> >> > FONTSET "/srv/Fonts/Fontset.txt" >> >> > CONFIG "MS_ERRORFILE" "/srv/lc/error_lc_wfs.txt" >> >> > DEBUG 5 >> >> > >> >> > PROJECTION >> >> > "init=epsg:2180" >> >> > >> >> > END >> >> > >> >> > OUTPUTFORMAT >> >> > NAME "gml" >> >> > DRIVER "TEMPLATE" >> >> > #MIMETYPE "text/xml; subtype=gml/3.2.1" >> >> > FORMATOPTION "FILE=LC_template.gml" >> >> > END >> >> > >> >> > WEB >> >> > METADATA >> >> > "ows_inspire_capabilities" "url" >> >> > "ows_languages" "pol,eng" >> >> > "ows_title" "Title PL" >> >> > "ows_title.eng" "WFS service with INSPIRE Land Cover" >> >> > "ows_abstract" "Abstract PL" >> >> > "ows_abstract.eng" "WMS service publishes harmonised INSPIRE Land Cover data set derrived from BDOT10k as-is data set " >> >> > "ows_fees" "Brak op?at" >> >> > "ows_fees.eng" "No fee applies" >> >> > WFS_ONLINERESOURCE "http://localhost/cgi-bin/LC_WFS " >> >> > "wfs_getfeature_formatlist" "gml" >> >> > "wfs_inspire_metadataurl_href" "someurl" >> >> > "wfs_inspire_metadataurl_format" "application/vnd.ogc.csw.GetRecordByIdResponse_xml" >> >> > >> >> > "ows_inspire_dsid_code" "LC " >> >> > "ows_inspire_dsid_ns" "LC.3.2" >> >> > >> >> > "wfs_enable_request" "*" >> >> > "wfs_srs" "EPSG:2180 EPSG:4326 EPSG:3857 EPSG:4528" >> >> > END >> >> > >> >> > END #WEB >> >> > >> >> > LAYER >> >> > NAME "LC.LandCoverUnit" >> >> > STATUS ON >> >> > CONNECTIONTYPE POSTGIS >> >> > CONNECTION "host=localhost dbname=postgis_db user=user password=password port=5432" >> >> > DATA "geom from bdot.landcoversurface using unique objectid using srid=2180" >> >> > >> >> > PROJECTION >> >> > "init=epsg:2180" >> >> > END >> >> > >> >> > TYPE POLYGON >> >> > PROCESSING "CLOSE_CONNECTION=DEFER" >> >> > TEMPLATE "LC_template.gml" >> >> > METADATA >> >> > "ows_title.pol" "LC.LandCoverUnit" >> >> > "ows_title.eng" "LC.LandCoverUnit" >> >> > WFS_EXTENT "160828.34326572 98928.8977745594 876029.97009323 796521.669409553" >> >> > "gml_include_items" "all" >> >> > "gml_featureid" "objectid" >> >> > "wfs_getfeature_formatlist" "gml" >> >> > "wfs_enable_request" "*" >> >> > "wfs_connectiontimeout" "120" >> >> > "wfs_maxfeatures" "10000" >> >> > "wfs_srs" "EPSG:2180 EPSG:4326 EPSG:3857 EPSG:4528" >> >> > "wfs_metadataurl_href" "someurl" >> >> > "wfs_inspire_metadataurl_format" "application/xml" >> >> > "wfs_metadataurl_type" "TC211" >> >> > END #METADATA >> >> > >> >> > END #LAYER >> >> > >> >> > END #MAP >> >> > >> >> > I tried different OUTPUTFORMAT configurations with different NAME, MIMETYPE parameter values. And nothing has worked. >> >> > On the same machine, I successfully published WMS service returning HTML GetFeatureInfo response customized utilizing the very same template-driven output concept. >> >> > I suspect that I may be missing something in the configuration file. I would be grateful for any suggestions. >> >> > >> >> > Best regards, >> >> > Marcin >> >> > >> >> > _______________________________________________ >> > 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: > >> >> ------------------------------ >> >> Subject: Digest Footer >> >> _______________________________________________ >> mapserver-users mailing list >> mapserver-users at lists.osgeo.org >> https://lists.osgeo.org/mailman/listinfo/mapserver-users >> >> >> ------------------------------ >> >> End of mapserver-users Digest, Vol 160, Issue 28 >> ************************************************ >> _______________________________________________ >> 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 mgrudzien7 at gmail.com Tue May 25 07:14:52 2021 From: mgrudzien7 at gmail.com (=?UTF-8?Q?Marcin_Grudzie=C5=84?=) Date: Tue, 25 May 2021 16:14:52 +0200 Subject: [mapserver-users] Setting up a template for custom WFS In-Reply-To: References: Message-ID: Dear James, Thank you for your answer. Do you know what are the specific limitations of MapServer in this regard? Can you suggest any FOSS alternatives for publishing complex features via WFS e.g. GeoServer? Best regards, Marcin On Tue, 25 May 2021 at 11:16, Passmore, James H. wrote: > Hi Marcin, > > As far as I am aware, it is not possible to serve up an INSPIRE compliant > (complex feature) WFS with MapServer. > > > James Passmore > ------------------------------- > British Geological Survey, > Environmental Science Centre, > KEYWORTH, > United Kingdom, > NG12 5GG > > orcid: https://orcid.org/0000-0002-9891-6265 > ------------------------------- > Phone: +44 (0)115 936 3125 > ------------------------------- > Skype: BGSjames > > > > > This email and any attachments are intended solely for the use of the > named recipients. If you are not the intended recipient you must not use, > disclose, copy or distribute this email or any of its attachments and > should notify the sender immediately and delete this email from your > system. UK Research and Innovation (UKRI) has taken every reasonable > precaution to minimise risk of this email or any attachments containing > viruses or malware but the recipient should carry out its own virus and > malware checks before opening the attachments. UKRI does not accept any > liability for any losses or damages which the recipient may sustain due to > presence of any viruses. Opinions, conclusions or other information in this > message and attachments that are not related directly to UKRI business are > solely those of the author and do not represent the views of UKRI. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jpass at bgs.ac.uk Tue May 25 08:10:56 2021 From: jpass at bgs.ac.uk (Passmore, James H.) Date: Tue, 25 May 2021 15:10:56 +0000 Subject: [mapserver-users] Setting up a template for custom WFS In-Reply-To: References: Message-ID: It's a while since I looked to be honest, but this archived thread suggests similar. See http://osgeo-org.1560.x6.nabble.com/Mapserver-and-Complex-Feature-support-td5232994.html I don't know if MapServer now supports GDAL/OGR GMLAS (https://gdal.org/drivers/vector/gmlas.html), if so it may now be possible to provide complex features. For other FOSS, you can use deegree, and GeoServer (in combination with App-Schema plugin or now/in the near future the Templating plugin). James -----Original Message----- From: Marcin Grudzie? Sent: 25 May 2021 15:15 To: Passmore, James H. Cc: mapserver-users at lists.osgeo.org Subject: Re: [mapserver-users] Setting up a template for custom WFS Dear James, Thank you for your answer. Do you know what are the specific limitations of MapServer in this regard? Can you suggest any FOSS alternatives for publishing complex features via WFS e.g. GeoServer? Best regards, Marcin On Tue, 25 May 2021 at 11:16, Passmore, James H. > wrote: Hi Marcin, As far as I am aware, it is not possible to serve up an INSPIRE compliant (complex feature) WFS with MapServer. James Passmore ------------------------------- British Geological Survey, Environmental Science Centre, KEYWORTH, United Kingdom, NG12 5GG orcid: https://orcid.org/0000-0002-9891-6265 ------------------------------- Phone: +44 (0)115 936 3125 ------------------------------- Skype: BGSjames This email and any attachments are intended solely for the use of the named recipients. If you are not the intended recipient you must not use, disclose, copy or distribute this email or any of its attachments and should notify the sender immediately and delete this email from your system. UK Research and Innovation (UKRI) has taken every reasonable precaution to minimise risk of this email or any attachments containing viruses or malware but the recipient should carry out its own virus and malware checks before opening the attachments. UKRI does not accept any liability for any losses or damages which the recipient may sustain due to presence of any viruses. Opinions, conclusions or other information in this message and attachments that are not related directly to UKRI business are solely those of the author and do not represent the views of UKRI. From lars.fricke at skendata.de Wed May 26 23:51:14 2021 From: lars.fricke at skendata.de (Lars Fricke) Date: Thu, 27 May 2021 08:51:14 +0200 Subject: [mapserver-users] WFS Client returns data at random with very same call Message-ID: <80957dc0-4a01-bac5-b1fd-84300aebba39@skendata.de> An HTML attachment was scrubbed... URL: From joerg.thomsen at wheregroup.com Thu May 27 00:04:44 2021 From: joerg.thomsen at wheregroup.com (=?UTF-8?Q?J=c3=b6rg_Thomsen_=28WhereGroup=29?=) Date: Thu, 27 May 2021 09:04:44 +0200 Subject: [mapserver-users] WFS Client returns data at random with very same call In-Reply-To: <80957dc0-4a01-bac5-b1fd-84300aebba39@skendata.de> References: <80957dc0-4a01-bac5-b1fd-84300aebba39@skendata.de> Message-ID: <07e507fc-1e23-561b-3c89-2885d71dcd2f@wheregroup.com> Hello Lars, maxfeatures was my first guess... have you also turned ist it off (no maxfeatures)? J?rg Am 27.05.21 um 08:51 schrieb Lars Fricke: > Dear All, > > as this list is a source of much deeper insight than I have into > Mapserver, I would like to ask about a very strange issue I am facing. > > I am calling on a public WFS server I can query "by hand" fast and > successfully every single time. Now I defined a Mapserver layer (see > below) as an OGR layer in my WFS map-file and it does - on the same call > - return data. But not reliably, more at random. I played with the > connection-timeout and the maxfeatures and it seemed to have some > influence but again, not reliably. I'll post the relevant parts of my > mapfile (all my other layers with other sources are working fine): > """ > MAP > ? NAME "WFS_Test" > ? SHAPEPATH "/data" > ? STATUS ON > ? UNITS METERS > ? EXTENT -2851663 2776500 5630523 9970363 > > ? PROJECTION > ??? "init=epsg:3857" > ? END # PROJECTION > > ? WEB > ??? FOOTER "TestServer" > ??? IMAGEPATH "/tmp/" > ??? TEMPPATH "/tmp/" > ??? IMAGEURL "/tmp/" > ??? METADATA > ????? "wfs_title"????????? "Test" > ????? "ows_onlineresource"??? > "http://my_server.de/cgi-bin/mapserv?map=/var/www/html/wfs.map" > ????? "ows_enable_request"??? "*" > ????? "ows_srs"??? "EPSG:3857 EPSG:4326 EPSG:25832" > ????? "wfs_srs"??? "EPSG:3857 EPSG:4326 EPSG:25832" > ????? "wfs_getfeature_formatlist" "jsonp,ogrgml" > ????? "wfs_encoding" "UTF-8" > ????? "wfs_connectiontimeout" "20" > ????? #"wfs_request_method"?? "GET" > ??? END # METADATA > ??? VALIDATION > ??? ??? callback ".*" > ??? END > ? END # WEB > > ? OUTPUTFORMAT > ?? NAME "jsonp" > ?? DRIVER "OGR/GEOJSON" > ?? MIMETYPE "application/json; subtype=geojson; charset=utf-8" > ?? FORMATOPTION "STORAGE=stream" > ?? FORMATOPTION "FORM=SIMPLE" > ?? FORMATOPTION "LCO:COORDINATE_PRECISION=10" > ?? FORMATOPTION "JSONP=%callback%" > ? END > > ? OUTPUTFORMAT > ?? NAME "OGRGML" > ?? DRIVER "OGR/GML" > ?? FORMATOPTION "STORAGE=filesystem" > ?? FORMATOPTION "FORM=multipart" > ?? FORMATOPTION "FILENAME=result.gml" > ? END > > ? SYMBOL > ??? NAME "circle_filled" > ??? TYPE ELLIPSE > ??? FILLED TRUE > ??? POINTS > ????? 1 1 > ??? END > ? END > > ? LAYER > ??? NAME "TestLayer" > ??? CONNECTION "wfs-request-testlayer.xml" > ??? EXTENT 84710 5210905 1163008 6125425 > ??? CONNECTIONTYPE OGR > ??? STATUS ON > ??? DATA "dop" > ??? METADATA > ????? "wfs_version"??? "2.0.0" > ????? "wfs_title"??? "TestLayer_WFS" > ????? "wfs_connectiontimeout" "100" > ????? "wfs_typename"??? "TestLayer_WFS_int" > ????? "wfs_maxfeatures"?????? "600" > > ??? END # METADATA > ??? PROJECTION > ????? "init=epsg:25832" > ??? END # PROJECTION > ??? TYPE POLYGON > ??? CLASS > ????? NAME "aerial_image_footprint" > ????? STYLE > ??????? OUTLINECOLOR 255 0 0 > ??????? WIDTH 0.7 > ????? END # STYLE > ??? END # CLASS > ? END # LAYER > """ > I made the xml-file wit ogrinfo as I did for many other layers that work. > The call is: > """ > http://localhost:8181/cgi-bin/mapserv?map=/var/www/html/wfs.map& > SERVICE=WFS&VERSION=2.0.0&REQUEST=GetFeature&SRSNAME=EPSG:3857&BBOX=1292610.86313433,6822730.62911591,1293128.57472490,6823169.70765144&TYPENAME=TestLayer > """ > If I replace the Server name with the public server, it works like a > breeze (even it is 3857). > The public server has: > """ > urn:ogc:def:crs:EPSG:6.9:25832 > urn:ogc:def:crs:EPSG:6.9:4326 > """ > > I see the following response in the browser: > """ > ? > """ > And in the log: > """ > [warn] [pid 26] mod_fcgid: stderr: msQueryByRect(): Search returned no > results. No matching record(s) found. > ?[warn] [pid 26] mod_fcgid: stderr: freeLayer(): freeing layer at 0x131f120. > 3169463 - 172.17.0.1 - - [27/May/2021:06:30:35 +0000] "GET > /cgi-bin/mapserv?map=/var/www/html/wfs.map&SERVICE=WFS&VERSION=2.0.0&REQUEST=GetFeature&SRSNAME=EPSG:3857&BBOX=1292610.86313433,6822730.62911591,1293128.57472490,6823169.70765144&TYPENAME=TestLayer > HTTP/1.1" 200 793 "-" "Mozilla/5.0 (X11; Linux x86_64) > AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.212 Safari/537.36" > 330 - 172.17.0.1 - - [27/May/2021:06:30:38 +0000] "GET /favicon.ico > HTTP/1.1" 200 414 > "http://localhost:8181/cgi-bin/mapserv?map=/var/www/html/wfs.map&SERVICE=WFS&VERSION=2.0.0&REQUEST=GetFeature&SRSNAME=EPSG:3857&BBOX=1292610.86313433,6822730.62911591,1293128.57472490,6823169.70765144&TYPENAME=TestLayer" > "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) > Chrome/90.0.4430.212 Safari/537.36" > """ > I will be grateful for any clue on what is going on. Thank you for your > trouble! > > Best > > Lars > SkenData Email Signatur > > _______________________________________________ > mapserver-users mailing list > mapserver-users at lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/mapserver-users > Viele Gr??e, J?rg Thomsen -- ---------------------------------------------------- Aufwind durch Wissen! Web-Seminare und Online-Schulungen bei der www.foss-academy.com ---------------------------------------------------- J?rg Thomsen WhereGroup GmbH Bundesallee 23 10717 Berlin Germany Fon: +49 (0)30 / 5130 278 74 Fax: +49 (0)30 / 5130 278 11 joerg.thomsen at wheregroup.com www.wheregroup.com Gesch?ftsf?hrer: Olaf Knopp, Peter Stamm Amtsgericht Bonn, HRB 9885 ------------------------------- Folgen Sie der WhereGroup auf twitter: http://twitter.com/WhereGroup_com From lars.fricke at skendata.de Thu May 27 00:31:12 2021 From: lars.fricke at skendata.de (Lars Fricke) Date: Thu, 27 May 2021 09:31:12 +0200 Subject: [mapserver-users] WFS Client returns data at random with very same call In-Reply-To: <07e507fc-1e23-561b-3c89-2885d71dcd2f@wheregroup.com> References: <80957dc0-4a01-bac5-b1fd-84300aebba39@skendata.de> <07e507fc-1e23-561b-3c89-2885d71dcd2f@wheregroup.com> Message-ID: <64abda67-c094-a56b-6a7d-08061ff0f08f@skendata.de> An HTML attachment was scrubbed... URL: From lars.fricke at skendata.de Thu May 27 01:25:05 2021 From: lars.fricke at skendata.de (Lars Fricke) Date: Thu, 27 May 2021 10:25:05 +0200 Subject: [mapserver-users] WFS Client returns data at random with very same call In-Reply-To: <07e507fc-1e23-561b-3c89-2885d71dcd2f@wheregroup.com> References: <80957dc0-4a01-bac5-b1fd-84300aebba39@skendata.de> <07e507fc-1e23-561b-3c89-2885d71dcd2f@wheregroup.com> Message-ID: <57a93832-2e9f-550e-f10a-7d9540f96906@skendata.de> An HTML attachment was scrubbed... URL: From jelmerbaas at nedgraphics.nl Thu May 27 01:39:21 2021 From: jelmerbaas at nedgraphics.nl (Jelmer Baas) Date: Thu, 27 May 2021 08:39:21 +0000 Subject: [mapserver-users] Mapscript C# and OWSRequest parameters Message-ID: Hello, For a new project, I've decided to pickup MapScript again to function as an internal (back-end) WFS server. I use the OWSRequest class, which works fine when I fill it with loadParamsFromURL() - in the case of Get requests. I can't seem to figure out a way to get my POST data into this object, though. It has a loadParams method, but because I'm not running as a CGI application (back-end app without a webserver), this doesn't do anything. I also tried setting postrequest property and then calling the loadParams, setting Environment variables, etc. No error, no exception, just -1 value from NumParams. Any suggestions on how to proceed? Regards, Jelmer Baas -------------- next part -------------- An HTML attachment was scrubbed... URL: From lars.fricke at skendata.de Thu May 27 02:37:50 2021 From: lars.fricke at skendata.de (Lars Fricke) Date: Thu, 27 May 2021 11:37:50 +0200 Subject: [mapserver-users] WFS Client returns data at random with very same call In-Reply-To: <07e507fc-1e23-561b-3c89-2885d71dcd2f@wheregroup.com> References: <80957dc0-4a01-bac5-b1fd-84300aebba39@skendata.de> <07e507fc-1e23-561b-3c89-2885d71dcd2f@wheregroup.com> Message-ID: <2feef91c-3ba6-dc98-93db-81717e920913@skendata.de> An HTML attachment was scrubbed... URL: From lars.fricke at skendata.de Thu May 27 03:17:22 2021 From: lars.fricke at skendata.de (Lars Fricke) Date: Thu, 27 May 2021 12:17:22 +0200 Subject: [mapserver-users] WFS Client returns data at random with very same call In-Reply-To: <07e507fc-1e23-561b-3c89-2885d71dcd2f@wheregroup.com> References: <80957dc0-4a01-bac5-b1fd-84300aebba39@skendata.de> <07e507fc-1e23-561b-3c89-2885d71dcd2f@wheregroup.com> Message-ID: An HTML attachment was scrubbed... URL: From lars.fricke at skendata.de Thu May 27 04:59:22 2021 From: lars.fricke at skendata.de (Lars Fricke) Date: Thu, 27 May 2021 13:59:22 +0200 Subject: [mapserver-users] WFS Client returns data at random with very same call In-Reply-To: <07e507fc-1e23-561b-3c89-2885d71dcd2f@wheregroup.com> References: <80957dc0-4a01-bac5-b1fd-84300aebba39@skendata.de> <07e507fc-1e23-561b-3c89-2885d71dcd2f@wheregroup.com> Message-ID: <46f0ac89-1adb-95f7-f684-b95f29cc7d5b@skendata.de> An HTML attachment was scrubbed... URL: From jukka.rahkonen at maanmittauslaitos.fi Thu May 27 09:28:43 2021 From: jukka.rahkonen at maanmittauslaitos.fi (Rahkonen Jukka (MML)) Date: Thu, 27 May 2021 16:28:43 +0000 Subject: [mapserver-users] WFS Client returns data at random with very same call Message-ID: Hi, Have you already tried to use WFS connection instead of OGR connection? -Jukka Rahkonen- L?hett?j?: mapserver-users Puolesta Lars Fricke L?hetetty: torstai 27. toukokuuta 2021 14.59 Vastaanottaja: mapserver-users at lists.osgeo.org Aihe: Re: [mapserver-users] WFS Client returns data at random with very same call Dear all, I apologize for finding and posting bits and pieces not all at one time. I fired up 'CONFIG "CPL_DEBUG" "ON"' and there I see, that """ HTTP: Fetch(http://url-to-external-server?SERVICE=WFS&VERSION=1.1.0&MAXFEATURES=1000&REQUEST=GetFeature&TYPENAME=dop) """ So there is no BBOX. On other layers I see """ GDALOpen(/vsicurl_streaming/https:... """ with BBOX. No wonder I do not get reliable results if the server is calling some 1000 whatsoever result objects and starts filtering the bbox after. Any idea what is happening? Or is this something for a GDAL thread? Best Lars -------------- next part -------------- An HTML attachment was scrubbed... URL: From sethg at geographika.co.uk Thu May 27 11:35:02 2021 From: sethg at geographika.co.uk (Seth G) Date: Thu, 27 May 2021 20:35:02 +0200 Subject: [mapserver-users] Mapscript C# and OWSRequest parameters In-Reply-To: References: Message-ID: Hi Jelmer, I think you'd have to use mapscript.msIO_installStdinFromBuffer to read data in. See https://mapserver.org/development/rfc/ms-rfc-16.html#io-hooking although I'm not sure if the approach works or was fully implemented. Let us know how you get on, Seth -- web:http://geographika.co.uk twitter: @geographika On Thu, May 27, 2021, at 10:39 AM, Jelmer Baas wrote: > Hello, > > For a new project, I?ve decided to pickup MapScript again to function as an internal (back-end) WFS server. I use the OWSRequest class, which works fine when I fill it with loadParamsFromURL() ? in the case of Get requests. > > I can?t seem to figure out a way to get my POST data into this object, though. It has a loadParams method, but because I?m not running as a CGI application (back-end app without a webserver), this doesn?t do anything. I also tried setting postrequest property and then calling the loadParams, setting Environment variables, etc. No error, no exception, just -1 value from NumParams. > > Any suggestions on how to proceed? > > Regards, > Jelmer Baas > > > _______________________________________________ > 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 dmorissette at mapgears.com Thu May 27 12:36:15 2021 From: dmorissette at mapgears.com (Daniel Morissette) Date: Thu, 27 May 2021 15:36:15 -0400 Subject: [mapserver-users] WFS Client returns data at random with very same call In-Reply-To: <80957dc0-4a01-bac5-b1fd-84300aebba39@skendata.de> References: <80957dc0-4a01-bac5-b1fd-84300aebba39@skendata.de> Message-ID: <64c9652a-95c4-f42a-0729-18e6f940fac4@mapgears.com> Since you use CONNECTIONTYPE OGR, none of the MapServer WFS Client logic takes place. Is there any reason why you cannot use CONNECTIONTYPE WFS as documented here: https://mapserver.org/ogc/wfs_client.html On 2021-05-27 02:51, Lars Fricke wrote: > Dear All, > > as this list is a source of much deeper insight than I have into > Mapserver, I would like to ask about a very strange issue I am facing. > > I am calling on a public WFS server I can query "by hand" fast and > successfully every single time. Now I defined a Mapserver layer (see > below) as an OGR layer in my WFS map-file and it does - on the same call > - return data. But not reliably, more at random. I played with the > connection-timeout and the maxfeatures and it seemed to have some > influence but again, not reliably. I'll post the relevant parts of my > mapfile (all my other layers with other sources are working fine): > """ > MAP > ? NAME "WFS_Test" > ? SHAPEPATH "/data" > ? STATUS ON > ? UNITS METERS > ? EXTENT -2851663 2776500 5630523 9970363 > > ? PROJECTION > ??? "init=epsg:3857" > ? END # PROJECTION > > ? WEB > ??? FOOTER "TestServer" > ??? IMAGEPATH "/tmp/" > ??? TEMPPATH "/tmp/" > ??? IMAGEURL "/tmp/" > ??? METADATA > ????? "wfs_title"????????? "Test" > ????? "ows_onlineresource" > "http://my_server.de/cgi-bin/mapserv?map=/var/www/html/wfs.map" > ????? "ows_enable_request"??? "*" > ????? "ows_srs"??? "EPSG:3857 EPSG:4326 EPSG:25832" > ????? "wfs_srs"??? "EPSG:3857 EPSG:4326 EPSG:25832" > ????? "wfs_getfeature_formatlist" "jsonp,ogrgml" > ????? "wfs_encoding" "UTF-8" > ????? "wfs_connectiontimeout" "20" > ????? #"wfs_request_method"?? "GET" > ??? END # METADATA > ??? VALIDATION > ??? ??? callback ".*" > ??? END > ? END # WEB > > ? OUTPUTFORMAT > ?? NAME "jsonp" > ?? DRIVER "OGR/GEOJSON" > ?? MIMETYPE "application/json; subtype=geojson; charset=utf-8" > ?? FORMATOPTION "STORAGE=stream" > ?? FORMATOPTION "FORM=SIMPLE" > ?? FORMATOPTION "LCO:COORDINATE_PRECISION=10" > ?? FORMATOPTION "JSONP=%callback%" > ? END > > ? OUTPUTFORMAT > ?? NAME "OGRGML" > ?? DRIVER "OGR/GML" > ?? FORMATOPTION "STORAGE=filesystem" > ?? FORMATOPTION "FORM=multipart" > ?? FORMATOPTION "FILENAME=result.gml" > ? END > > ? SYMBOL > ??? NAME "circle_filled" > ??? TYPE ELLIPSE > ??? FILLED TRUE > ??? POINTS > ????? 1 1 > ??? END > ? END > > ? LAYER > ??? NAME "TestLayer" > ??? CONNECTION "wfs-request-testlayer.xml" > ??? EXTENT 84710 5210905 1163008 6125425 > ??? CONNECTIONTYPE OGR > ??? STATUS ON > ??? DATA "dop" > ??? METADATA > ????? "wfs_version"??? "2.0.0" > ????? "wfs_title"??? "TestLayer_WFS" > ????? "wfs_connectiontimeout" "100" > ????? "wfs_typename"??? "TestLayer_WFS_int" > ????? "wfs_maxfeatures"?????? "600" > > ??? END # METADATA > ??? PROJECTION > ????? "init=epsg:25832" > ??? END # PROJECTION > ??? TYPE POLYGON > ??? CLASS > ????? NAME "aerial_image_footprint" > ????? STYLE > ??????? OUTLINECOLOR 255 0 0 > ??????? WIDTH 0.7 > ????? END # STYLE > ??? END # CLASS > ? END # LAYER > """ > I made the xml-file wit ogrinfo as I did for many other layers that work. > The call is: > """ > http://localhost:8181/cgi-bin/mapserv?map=/var/www/html/wfs.map& > SERVICE=WFS&VERSION=2.0.0&REQUEST=GetFeature&SRSNAME=EPSG:3857&BBOX=1292610.86313433,6822730.62911591,1293128.57472490,6823169.70765144&TYPENAME=TestLayer > """ > If I replace the Server name with the public server, it works like a > breeze (even it is 3857). > The public server has: > """ > urn:ogc:def:crs:EPSG:6.9:25832 > urn:ogc:def:crs:EPSG:6.9:4326 > """ > > I see the following response in the browser: > """ > > """ > And in the log: > """ > [warn] [pid 26] mod_fcgid: stderr: msQueryByRect(): Search returned no > results. No matching record(s) found. > ?[warn] [pid 26] mod_fcgid: stderr: freeLayer(): freeing layer at > 0x131f120. > 3169463 - 172.17.0.1 - - [27/May/2021:06:30:35 +0000] "GET > /cgi-bin/mapserv?map=/var/www/html/wfs.map&SERVICE=WFS&VERSION=2.0.0&REQUEST=GetFeature&SRSNAME=EPSG:3857&BBOX=1292610.86313433,6822730.62911591,1293128.57472490,6823169.70765144&TYPENAME=TestLayer > HTTP/1.1" 200 793 "-" "Mozilla/5.0 (X11; Linux x86_64) > AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.212 Safari/537.36" > 330 - 172.17.0.1 - - [27/May/2021:06:30:38 +0000] "GET /favicon.ico > HTTP/1.1" 200 414 > "http://localhost:8181/cgi-bin/mapserv?map=/var/www/html/wfs.map&SERVICE=WFS&VERSION=2.0.0&REQUEST=GetFeature&SRSNAME=EPSG:3857&BBOX=1292610.86313433,6822730.62911591,1293128.57472490,6823169.70765144&TYPENAME=TestLayer" > "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) > Chrome/90.0.4430.212 Safari/537.36" > """ > I will be grateful for any clue on what is going on. Thank you for your > trouble! > > Best > > Lars > SkenData Email Signatur > > _______________________________________________ > mapserver-users mailing list > mapserver-users at lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/mapserver-users > -- Daniel Morissette Mapgears Inc T: +1 418-696-5056 #201 From even.rouault at spatialys.com Thu May 27 13:03:49 2021 From: even.rouault at spatialys.com (Even Rouault) Date: Thu, 27 May 2021 22:03:49 +0200 Subject: [mapserver-users] WFS Client returns data at random with very same call In-Reply-To: <46f0ac89-1adb-95f7-f684-b95f29cc7d5b@skendata.de> References: <80957dc0-4a01-bac5-b1fd-84300aebba39@skendata.de> <07e507fc-1e23-561b-3c89-2885d71dcd2f@wheregroup.com> <46f0ac89-1adb-95f7-f684-b95f29cc7d5b@skendata.de> Message-ID: <8c7a8ada-84d7-842d-bf62-448d80eaa6e8@spatialys.com> It might be a bug in the OGR WFS driver (I see optimizations in the code to avoid adding a BBOX if we have already fetched the layer, that could be faulty), but we'd need a full reproducer to be able to investigate. Le 27/05/2021 ? 13:59, Lars Fricke a ?crit?: > Dear all, > I apologize for finding and posting bits and pieces not all at one time. > I fired up 'CONFIG "CPL_DEBUG" "ON"' and there I see, that > """ > SkenData Email Signatur > HTTP: > Fetch(http://url-to-external-server?SERVICE=WFS&VERSION=1.1.0&MAXFEATURES=1000&REQUEST=GetFeature&TYPENAME=dop) > """ > So there is no BBOX. On other layers I see > """ > GDALOpen(/vsicurl_streaming/https:... > """ > with BBOX. > No wonder I do not get reliable results if the server is calling some > 1000 whatsoever result objects and starts filtering the bbox after. > > Any idea what is happening? Or is this something for a GDAL thread? > > Best > Lars > > Am 27.05.21 um 09:04 schrieb J?rg Thomsen (WhereGroup): >> Hello Lars, >> >> maxfeatures was my first guess... have you also turned ist it off (no >> maxfeatures)? >> >> J?rg >> >> >> Am 27.05.21 um 08:51 schrieb Lars Fricke: >>> Dear All, >>> >>> as this list is a source of much deeper insight than I have into >>> Mapserver, I would like to ask about a very strange issue I am facing. >>> >>> I am calling on a public WFS server I can query "by hand" fast and >>> successfully every single time. Now I defined a Mapserver layer (see >>> below) as an OGR layer in my WFS map-file and it does - on the same call >>> - return data. But not reliably, more at random. I played with the >>> connection-timeout and the maxfeatures and it seemed to have some >>> influence but again, not reliably. I'll post the relevant parts of my >>> mapfile (all my other layers with other sources are working fine): >>> """ >>> MAP >>> ? NAME "WFS_Test" >>> ? SHAPEPATH "/data" >>> ? STATUS ON >>> ? UNITS METERS >>> ? EXTENT -2851663 2776500 5630523 9970363 >>> >>> ? PROJECTION >>> ??? "init=epsg:3857" >>> ? END # PROJECTION >>> >>> ? WEB >>> ??? FOOTER "TestServer" >>> ??? IMAGEPATH "/tmp/" >>> ??? TEMPPATH "/tmp/" >>> ??? IMAGEURL "/tmp/" >>> ??? METADATA >>> ????? "wfs_title"????????? "Test" >>> ????? "ows_onlineresource" >>> "http://my_server.de/cgi-bin/mapserv?map=/var/www/html/wfs.map" >>> ????? "ows_enable_request"??? "*" >>> ????? "ows_srs"??? "EPSG:3857 EPSG:4326 EPSG:25832" >>> ????? "wfs_srs"??? "EPSG:3857 EPSG:4326 EPSG:25832" >>> ????? "wfs_getfeature_formatlist" "jsonp,ogrgml" >>> ????? "wfs_encoding" "UTF-8" >>> ????? "wfs_connectiontimeout" "20" >>> ????? #"wfs_request_method"?? "GET" >>> ??? END # METADATA >>> ??? VALIDATION >>> ??? ??? callback ".*" >>> ??? END >>> ? END # WEB >>> >>> ? OUTPUTFORMAT >>> ?? NAME "jsonp" >>> ?? DRIVER "OGR/GEOJSON" >>> ?? MIMETYPE "application/json; subtype=geojson; charset=utf-8" >>> ?? FORMATOPTION "STORAGE=stream" >>> ?? FORMATOPTION "FORM=SIMPLE" >>> ?? FORMATOPTION "LCO:COORDINATE_PRECISION=10" >>> ?? FORMATOPTION "JSONP=%callback%" >>> ? END >>> >>> ? OUTPUTFORMAT >>> ?? NAME "OGRGML" >>> ?? DRIVER "OGR/GML" >>> ?? FORMATOPTION "STORAGE=filesystem" >>> ?? FORMATOPTION "FORM=multipart" >>> ?? FORMATOPTION "FILENAME=result.gml" >>> ? END >>> >>> ? SYMBOL >>> ??? NAME "circle_filled" >>> ??? TYPE ELLIPSE >>> ??? FILLED TRUE >>> ??? POINTS >>> ????? 1 1 >>> ??? END >>> ? END >>> >>> ? LAYER >>> ??? NAME "TestLayer" >>> ??? CONNECTION "wfs-request-testlayer.xml" >>> ??? EXTENT 84710 5210905 1163008 6125425 >>> ??? CONNECTIONTYPE OGR >>> ??? STATUS ON >>> ??? DATA "dop" >>> ??? METADATA >>> ????? "wfs_version"??? "2.0.0" >>> ????? "wfs_title"??? "TestLayer_WFS" >>> ????? "wfs_connectiontimeout" "100" >>> ????? "wfs_typename"??? "TestLayer_WFS_int" >>> ????? "wfs_maxfeatures"?????? "600" >>> >>> ??? END # METADATA >>> ??? PROJECTION >>> ????? "init=epsg:25832" >>> ??? END # PROJECTION >>> ??? TYPE POLYGON >>> ??? CLASS >>> ????? NAME "aerial_image_footprint" >>> ????? STYLE >>> ??????? OUTLINECOLOR 255 0 0 >>> ??????? WIDTH 0.7 >>> ????? END # STYLE >>> ??? END # CLASS >>> ? END # LAYER >>> """ >>> I made the xml-file wit ogrinfo as I did for many other layers that work. >>> The call is: >>> """ http://localhost:8181/cgi-bin/mapserv?map=/var/www/html/wfs.map& >>> SERVICE=WFS&VERSION=2.0.0&REQUEST=GetFeature&SRSNAME=EPSG:3857&BBOX=1292610.86313433,6822730.62911591,1293128.57472490,6823169.70765144&TYPENAME=TestLayer >>> """ >>> If I replace the Server name with the public server, it works like a >>> breeze (even it is 3857). >>> The public server has: >>> """ >>> urn:ogc:def:crs:EPSG:6.9:25832 >>> urn:ogc:def:crs:EPSG:6.9:4326 >>> """ >>> >>> I see the following response in the browser: >>> """ >>> ? >>> """ >>> And in the log: >>> """ >>> [warn] [pid 26] mod_fcgid: stderr: msQueryByRect(): Search returned no >>> results. No matching record(s) found. >>> ?[warn] [pid 26] mod_fcgid: stderr: freeLayer(): freeing layer at 0x131f120. >>> 3169463 - 172.17.0.1 - - [27/May/2021:06:30:35 +0000] "GET >>> /cgi-bin/mapserv?map=/var/www/html/wfs.map&SERVICE=WFS&VERSION=2.0.0&REQUEST=GetFeature&SRSNAME=EPSG:3857&BBOX=1292610.86313433,6822730.62911591,1293128.57472490,6823169.70765144&TYPENAME=TestLayer >>> HTTP/1.1" 200 793 "-" "Mozilla/5.0 (X11; Linux x86_64) >>> AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.212 Safari/537.36" >>> 330 - 172.17.0.1 - - [27/May/2021:06:30:38 +0000] "GET /favicon.ico >>> HTTP/1.1" 200 414 >>> "http://localhost:8181/cgi-bin/mapserv?map=/var/www/html/wfs.map&SERVICE=WFS&VERSION=2.0.0&REQUEST=GetFeature&SRSNAME=EPSG:3857&BBOX=1292610.86313433,6822730.62911591,1293128.57472490,6823169.70765144&TYPENAME=TestLayer" >>> "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) >>> Chrome/90.0.4430.212 Safari/537.36" >>> """ >>> I will be grateful for any clue on what is going on. Thank you for your >>> trouble! >>> >>> Best >>> >>> Lars >>> SkenData Email Signatur >>> >>> _______________________________________________ >>> mapserver-users mailing list >>> mapserver-users at lists.osgeo.org >>> https://lists.osgeo.org/mailman/listinfo/mapserver-users >>> >> Viele Gr??e, >> J?rg Thomsen >> > > > _______________________________________________ > mapserver-users mailing list > mapserver-users at lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/mapserver-users -- http://www.spatialys.com My software is free, but my time generally not. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lars.fricke at skendata.de Thu May 27 23:28:54 2021 From: lars.fricke at skendata.de (Lars Fricke) Date: Fri, 28 May 2021 08:28:54 +0200 Subject: [mapserver-users] WFS Client returns data at random with very same call In-Reply-To: <64c9652a-95c4-f42a-0729-18e6f940fac4@mapgears.com> References: <80957dc0-4a01-bac5-b1fd-84300aebba39@skendata.de> <64c9652a-95c4-f42a-0729-18e6f940fac4@mapgears.com> Message-ID: <0cd5d375-d0d1-db17-1f20-47f83edc984f@skendata.de> An HTML attachment was scrubbed... URL: From lars.fricke at skendata.de Thu May 27 23:30:07 2021 From: lars.fricke at skendata.de (Lars Fricke) Date: Fri, 28 May 2021 08:30:07 +0200 Subject: [mapserver-users] WFS Client returns data at random with very same call In-Reply-To: <8c7a8ada-84d7-842d-bf62-448d80eaa6e8@spatialys.com> References: <80957dc0-4a01-bac5-b1fd-84300aebba39@skendata.de> <07e507fc-1e23-561b-3c89-2885d71dcd2f@wheregroup.com> <46f0ac89-1adb-95f7-f684-b95f29cc7d5b@skendata.de> <8c7a8ada-84d7-842d-bf62-448d80eaa6e8@spatialys.com> Message-ID: <241cc62d-9580-f346-660c-0ab0fd44f52f@skendata.de> An HTML attachment was scrubbed... URL: From lars.fricke at skendata.de Fri May 28 02:17:29 2021 From: lars.fricke at skendata.de (Lars Fricke) Date: Fri, 28 May 2021 11:17:29 +0200 Subject: [mapserver-users] WFS Client returns data at random with very same call In-Reply-To: <64c9652a-95c4-f42a-0729-18e6f940fac4@mapgears.com> References: <80957dc0-4a01-bac5-b1fd-84300aebba39@skendata.de> <64c9652a-95c4-f42a-0729-18e6f940fac4@mapgears.com> Message-ID: An HTML attachment was scrubbed... URL: From lars.fricke at skendata.de Fri May 28 03:24:08 2021 From: lars.fricke at skendata.de (Lars Fricke) Date: Fri, 28 May 2021 12:24:08 +0200 Subject: [mapserver-users] WFS Client returns data at random with very same call In-Reply-To: References: Message-ID: An HTML attachment was scrubbed... URL: From lars.fricke at skendata.de Fri May 28 04:13:38 2021 From: lars.fricke at skendata.de (Lars Fricke) Date: Fri, 28 May 2021 13:13:38 +0200 Subject: [mapserver-users] WFS Client returns data at random with very same call In-Reply-To: References: Message-ID: <2d0c3bab-d3a8-972a-13da-b07a24baa8e9@skendata.de> An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: issue_mapserver_files.zip Type: application/zip Size: 6115 bytes Desc: not available URL: From even.rouault at spatialys.com Fri May 28 04:43:53 2021 From: even.rouault at spatialys.com (Even Rouault) Date: Fri, 28 May 2021 13:43:53 +0200 Subject: [mapserver-users] WFS Client returns data at random with very same call In-Reply-To: <2d0c3bab-d3a8-972a-13da-b07a24baa8e9@skendata.de> References: <2d0c3bab-d3a8-972a-13da-b07a24baa8e9@skendata.de> Message-ID: Please include your mapfile and the wfs-request-testlayer.xml file to reproduce. I'm confused by the mapfile you posted yesterday that uses epsg:25832 and the fact that GDAL through mapserver would issue a GetFeature in EPSG:3857 as suggested below. I can't see how that could happen (given the MapServer/GDAL integration, GDAL should always request in the native SRS of the layer and MapServer will do the reprojection to the SRSNAME of the WFS request) But as Daniel suggested using the CONNECTION WFS is probably a better way of doing what you want Le 28/05/2021 ? 13:13, Lars Fricke via mapserver-users a ?crit?: > So here is the working not working setup. Unfortunately the working > OGR WFS client layers are all private so I can not share them. > > This call delivers objects as expected: > http://localhost:8181/cgi-bin/mapserv?map=/var/www/html/wfs.map&SRSNAME=EPSG:3857&SERVICE=WFS&VERSION=1.1.0&REQUEST=GetFeature&Maxfeatures=10&TYPENAME=TestLayer > This one, too: > http://localhost:8181/cgi-bin/mapserv?map=/var/www/html/wfs.map&SRSNAME=EPSG:3857&SERVICE=WFS&VERSION=1.1.0&REQUEST=GetFeature&Maxfeatures=10&TYPENAME=TestLayer > > Data is delivered in the correct srs (verified manually with QGIS). > > This call doesn't work as described before as BBOX is not transmitted > to external server: > http://localhost:8181/cgi-bin/mapserv?map=/var/www/html/wfs.map&SRSNAME=EPSG:3857&SERVICE=WFS&VERSION=1.0.0&REQUEST=GetFeature&BBOX=791880.72463009,6321925.37255709,792929.63787777,6322786.10157277&TYPENAME=TestLayer > > While the same direct call works: > http://sg.geodatenzentrum.de/wfs_info?SRSNAME=EPSG:3857&SERVICE=WFS&VERSION=1.0.0&REQUEST=GetFeature&BBOX=791880.72463009,6321925.37255709,792929.63787777,6322786.10157277&TYPENAME=info:dop > (funny, epsg 3857 is not in the capabilities but works anyhow) > > I hope you can find out what is going wrong. Thanks so much for > looking into this! > > Best > > Lars > SkenData Email Signatur > > > Am 27.05.21 um 18:28 schrieb Rahkonen Jukka (MML): >> SkenData Email Signatur >> >> Hi, >> >> Have you already tried to use WFS connection instead of OGR connection? >> >> -Jukka Rahkonen- >> >> *L?hett?j?:* mapserver-users >> *Puolesta *Lars Fricke >> *L?hetetty:* torstai 27. toukokuuta 2021 14.59 >> *Vastaanottaja:* mapserver-users at lists.osgeo.org >> *Aihe:* Re: [mapserver-users] WFS Client returns data at random with >> very same call >> >> Dear all, >> I apologize for finding and posting bits and pieces not all at one time. >> I fired up 'CONFIG "CPL_DEBUG" "ON"' and there I see, that >> """ >> >> HTTP: >> Fetch(http://url-to-external-server?SERVICE=WFS&VERSION=1.1.0&MAXFEATURES=1000&REQUEST=GetFeature&TYPENAME=dop >> ) >> """ >> So there is no BBOX. On other layers I see >> """ >> GDALOpen(/vsicurl_streaming/https:... >> """ >> with BBOX. >> No wonder I do not get reliable results if the server is calling some >> 1000 whatsoever result objects and starts filtering the bbox after. >> >> Any idea what is happening? Or is this something for a GDAL thread? >> >> Best >> Lars >> > > > _______________________________________________ > mapserver-users mailing list > mapserver-users at lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/mapserver-users -- http://www.spatialys.com My software is free, but my time generally not. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lars.fricke at skendata.de Fri May 28 04:52:35 2021 From: lars.fricke at skendata.de (Lars Fricke) Date: Fri, 28 May 2021 13:52:35 +0200 Subject: [mapserver-users] WFS Client returns data at random with very same call In-Reply-To: References: <2d0c3bab-d3a8-972a-13da-b07a24baa8e9@skendata.de> Message-ID: <10b1dc3f-ed06-33d2-f2d1-15def00d5ac7@skendata.de> An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: issue_mapserver_files.zip Type: application/zip Size: 6115 bytes Desc: not available URL: From even.rouault at spatialys.com Fri May 28 04:55:12 2021 From: even.rouault at spatialys.com (Even Rouault) Date: Fri, 28 May 2021 13:55:12 +0200 Subject: [mapserver-users] WFS Client returns data at random with very same call In-Reply-To: <10b1dc3f-ed06-33d2-f2d1-15def00d5ac7@skendata.de> References: <2d0c3bab-d3a8-972a-13da-b07a24baa8e9@skendata.de> <10b1dc3f-ed06-33d2-f2d1-15def00d5ac7@skendata.de> Message-ID: <4fa6a6c7-38a4-76d9-f49c-6870eb97471b@spatialys.com> oops, sorry, didn't notice ? Le 28/05/2021 ? 13:52, Lars Fricke a ?crit?: > I put in the files as attach. Is that filtered? > SkenData Email Signatur > > Am 28.05.21 um 13:43 schrieb Even Rouault: >> >> Please include your mapfile and the wfs-request-testlayer.xml file to >> reproduce. I'm confused by the mapfile you posted yesterday that uses >> epsg:25832 and the fact that GDAL through mapserver would issue a >> GetFeature in EPSG:3857 as suggested below. I can't see how that >> could happen (given the MapServer/GDAL integration, GDAL should >> always request in the native SRS of the layer and MapServer will do >> the reprojection to the SRSNAME of the WFS request) >> >> But as Daniel suggested using the CONNECTION WFS is probably a better >> way of doing what you want >> >> Le 28/05/2021 ? 13:13, Lars Fricke via mapserver-users a ?crit?: >>> So here is the working not working setup. Unfortunately the working >>> OGR WFS client layers are all private so I can not share them. >>> >>> This call delivers objects as expected: >>> http://localhost:8181/cgi-bin/mapserv?map=/var/www/html/wfs.map&SRSNAME=EPSG:3857&SERVICE=WFS&VERSION=1.1.0&REQUEST=GetFeature&Maxfeatures=10&TYPENAME=TestLayer >>> This one, too: >>> http://localhost:8181/cgi-bin/mapserv?map=/var/www/html/wfs.map&SRSNAME=EPSG:3857&SERVICE=WFS&VERSION=1.1.0&REQUEST=GetFeature&Maxfeatures=10&TYPENAME=TestLayer >>> >>> Data is delivered in the correct srs (verified manually with QGIS). >>> >>> This call doesn't work as described before as BBOX is not >>> transmitted to external server: >>> http://localhost:8181/cgi-bin/mapserv?map=/var/www/html/wfs.map&SRSNAME=EPSG:3857&SERVICE=WFS&VERSION=1.0.0&REQUEST=GetFeature&BBOX=791880.72463009,6321925.37255709,792929.63787777,6322786.10157277&TYPENAME=TestLayer >>> >>> While the same direct call works: >>> http://sg.geodatenzentrum.de/wfs_info?SRSNAME=EPSG:3857&SERVICE=WFS&VERSION=1.0.0&REQUEST=GetFeature&BBOX=791880.72463009,6321925.37255709,792929.63787777,6322786.10157277&TYPENAME=info:dop >>> (funny, epsg 3857 is not in the capabilities but works anyhow) >>> >>> I hope you can find out what is going wrong. Thanks so much for >>> looking into this! >>> >>> Best >>> >>> Lars >>> SkenData Email Signatur >>> >>> >>> Am 27.05.21 um 18:28 schrieb Rahkonen Jukka (MML): >>>> SkenData Email Signatur >>>> >>>> Hi, >>>> >>>> Have you already tried to use WFS connection instead of OGR connection? >>>> >>>> -Jukka Rahkonen- >>>> >>>> *L?hett?j?:* mapserver-users >>>> *Puolesta *Lars Fricke >>>> *L?hetetty:* torstai 27. toukokuuta 2021 14.59 >>>> *Vastaanottaja:* mapserver-users at lists.osgeo.org >>>> *Aihe:* Re: [mapserver-users] WFS Client returns data at random >>>> with very same call >>>> >>>> Dear all, >>>> I apologize for finding and posting bits and pieces not all at one >>>> time. >>>> I fired up 'CONFIG "CPL_DEBUG" "ON"' and there I see, that >>>> """ >>>> >>>> HTTP: >>>> Fetch(http://url-to-external-server?SERVICE=WFS&VERSION=1.1.0&MAXFEATURES=1000&REQUEST=GetFeature&TYPENAME=dop >>>> ) >>>> """ >>>> So there is no BBOX. On other layers I see >>>> """ >>>> GDALOpen(/vsicurl_streaming/https:... >>>> """ >>>> with BBOX. >>>> No wonder I do not get reliable results if the server is calling >>>> some 1000 whatsoever result objects and starts filtering the bbox >>>> after. >>>> >>>> Any idea what is happening? Or is this something for a GDAL thread? >>>> >>>> Best >>>> Lars >>>> >>> >>> >>> _______________________________________________ >>> mapserver-users mailing list >>> mapserver-users at lists.osgeo.org >>> https://lists.osgeo.org/mailman/listinfo/mapserver-users >> -- >> http://www.spatialys.com >> My software is free, but my time generally not. > -- http://www.spatialys.com My software is free, but my time generally not. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lars.fricke at skendata.de Fri May 28 05:11:47 2021 From: lars.fricke at skendata.de (Lars Fricke) Date: Fri, 28 May 2021 14:11:47 +0200 Subject: [mapserver-users] WFS Client returns data at random with very same call In-Reply-To: <4fa6a6c7-38a4-76d9-f49c-6870eb97471b@spatialys.com> References: <2d0c3bab-d3a8-972a-13da-b07a24baa8e9@skendata.de> <10b1dc3f-ed06-33d2-f2d1-15def00d5ac7@skendata.de> <4fa6a6c7-38a4-76d9-f49c-6870eb97471b@spatialys.com> Message-ID: An HTML attachment was scrubbed... URL: From even.rouault at spatialys.com Fri May 28 05:32:42 2021 From: even.rouault at spatialys.com (Even Rouault) Date: Fri, 28 May 2021 14:32:42 +0200 Subject: [mapserver-users] WFS Client returns data at random with very same call In-Reply-To: References: <2d0c3bab-d3a8-972a-13da-b07a24baa8e9@skendata.de> <10b1dc3f-ed06-33d2-f2d1-15def00d5ac7@skendata.de> <4fa6a6c7-38a4-76d9-f49c-6870eb97471b@spatialys.com> Message-ID: <2eb4a26b-2483-d46b-17ac-cd6d52d6d7ed@spatialys.com> Lars, I believe the service you request doesn't implement WFS 1.1 properly. Trying this ./mapserv QUERY_STRING="map=wfs.map&SRSNAME=EPSG:3857&SERVICE=WFS&VERSION=1.1.0&REQUEST=GetFeature&BBOX=791880.72463009,6321925.37255709,792929.63787777,6322786.10157277&TYPENAME=TestLayer" I see that GDAL does: VSICURL: Start download for http://sg.geodatenzentrum.de/wfs_info?SERVICE=WFS&VERSION=1.1.0&MAXFEATURES=500&REQUEST=GetFeature&TYPENAME=info:dop&FILTER=%3CFilter%20xmlns%3D%22http:%2F%2Fwww.opengis.net%2Fogc%22%20xmlns:gml%3D%22http:%2F%2Fwww.opengis.net%2Fgml%22%3E%3CBBOX%3E%3CPropertyName%3Egeom%3C%2FPropertyName%3E%3Cgml:Box%3E%3Cgml:coordinates%3E362792.2015953020309098,5459899.7109905285760760%20363491.4383923375280574,5460477.4964771848171949%3C%2Fgml:coordinates%3E%3C%2Fgml:Box%3E%3C%2FBBOX%3E%3C%2FFilter%3E So Mapserver has transmitted to GDAL a BBOX filter in epsg:25832 (which is the native SRS of the layer) that is the reprojection of your source BBOX from EPSG:3857. All things are good up to that point. But the server returns an empty response. Tweaking it manually to include a srsName="EPSG:25832" attribute in gml:Box returns a response with 2 features http://sg.geodatenzentrum.de/wfs_info?SERVICE=WFS&VERSION=1.1.0&MAXFEATURES=500&REQUEST=GetFeature&TYPENAME=info:dop&FILTER=%3CFilter%20xmlns%3D%22http:%2F%2Fwww.opengis.net%2Fogc%22%20xmlns:gml%3D%22http:%2F%2Fwww.opengis.net%2Fgml%22%3E%3CBBOX%3E%3CPropertyName%3Egeom%3C%2FPropertyName%3E%3Cgml:Box%20srsName=%22EPSG:25832%22%3E%3Cgml:coordinates%3E362792.2015953020309098,5459899.7109905285760760%20363491.4383923375280574,5460477.4964771848171949%3C%2Fgml:coordinates%3E%3C%2Fgml:Box%3E%3C%2FBBOX%3E%3C%2FFilter%3E But we shouldn't have to do this has a missing srsName should be interpretated as the defaultSRS according to my understand of the WFS 1.1 spec You can however tweak the element in wfs-request-dop-bkg-age and add "&SRSNAME=EPSG:25832" to it (since it is the defaultSRS of all the layers of the service), and then GDAL will forward it. Even Le 28/05/2021 ? 14:11, Lars Fricke a ?crit?: > No problem. Unfortunately, testing native WFS did not work because it > does not properly support cascading wfs with different srs (see my > other post). > > Thanks for looking into this. > SkenData Email Signatur > > Am 28.05.21 um 13:55 schrieb Even Rouault: >> >> oops, sorry, didn't notice ? >> >> Le 28/05/2021 ? 13:52, Lars Fricke a ?crit?: >>> I put in the files as attach. Is that filtered? >>> SkenData Email Signatur >>> >>> Am 28.05.21 um 13:43 schrieb Even Rouault: >>>> >>>> Please include your mapfile and the wfs-request-testlayer.xml file >>>> to reproduce. I'm confused by the mapfile you posted yesterday that >>>> uses epsg:25832 and the fact that GDAL through mapserver would >>>> issue a GetFeature in EPSG:3857 as suggested below. I can't see how >>>> that could happen (given the MapServer/GDAL integration, GDAL >>>> should always request in the native SRS of the layer and MapServer >>>> will do the reprojection to the SRSNAME of the WFS request) >>>> >>>> But as Daniel suggested using the CONNECTION WFS is probably a >>>> better way of doing what you want >>>> >>>> Le 28/05/2021 ? 13:13, Lars Fricke via mapserver-users a ?crit?: >>>>> So here is the working not working setup. Unfortunately the >>>>> working OGR WFS client layers are all private so I can not share them. >>>>> >>>>> This call delivers objects as expected: >>>>> http://localhost:8181/cgi-bin/mapserv?map=/var/www/html/wfs.map&SRSNAME=EPSG:3857&SERVICE=WFS&VERSION=1.1.0&REQUEST=GetFeature&Maxfeatures=10&TYPENAME=TestLayer >>>>> This one, too: >>>>> http://localhost:8181/cgi-bin/mapserv?map=/var/www/html/wfs.map&SRSNAME=EPSG:3857&SERVICE=WFS&VERSION=1.1.0&REQUEST=GetFeature&Maxfeatures=10&TYPENAME=TestLayer >>>>> >>>>> Data is delivered in the correct srs (verified manually with QGIS). >>>>> >>>>> This call doesn't work as described before as BBOX is not >>>>> transmitted to external server: >>>>> http://localhost:8181/cgi-bin/mapserv?map=/var/www/html/wfs.map&SRSNAME=EPSG:3857&SERVICE=WFS&VERSION=1.0.0&REQUEST=GetFeature&BBOX=791880.72463009,6321925.37255709,792929.63787777,6322786.10157277&TYPENAME=TestLayer >>>>> >>>>> While the same direct call works: >>>>> http://sg.geodatenzentrum.de/wfs_info?SRSNAME=EPSG:3857&SERVICE=WFS&VERSION=1.0.0&REQUEST=GetFeature&BBOX=791880.72463009,6321925.37255709,792929.63787777,6322786.10157277&TYPENAME=info:dop >>>>> (funny, epsg 3857 is not in the capabilities but works anyhow) >>>>> >>>>> I hope you can find out what is going wrong. Thanks so much for >>>>> looking into this! >>>>> >>>>> Best >>>>> >>>>> Lars >>>>> SkenData Email Signatur >>>>> >>>>> >>>>> Am 27.05.21 um 18:28 schrieb Rahkonen Jukka (MML): >>>>>> SkenData Email Signatur >>>>>> >>>>>> Hi, >>>>>> >>>>>> Have you already tried to use WFS connection instead of OGR >>>>>> connection? >>>>>> >>>>>> -Jukka Rahkonen- >>>>>> >>>>>> *L?hett?j?:* mapserver-users >>>>>> *Puolesta *Lars Fricke >>>>>> *L?hetetty:* torstai 27. toukokuuta 2021 14.59 >>>>>> *Vastaanottaja:* mapserver-users at lists.osgeo.org >>>>>> *Aihe:* Re: [mapserver-users] WFS Client returns data at random >>>>>> with very same call >>>>>> >>>>>> Dear all, >>>>>> I apologize for finding and posting bits and pieces not all at >>>>>> one time. >>>>>> I fired up 'CONFIG "CPL_DEBUG" "ON"' and there I see, that >>>>>> """ >>>>>> >>>>>> HTTP: >>>>>> Fetch(http://url-to-external-server?SERVICE=WFS&VERSION=1.1.0&MAXFEATURES=1000&REQUEST=GetFeature&TYPENAME=dop >>>>>> ) >>>>>> """ >>>>>> So there is no BBOX. On other layers I see >>>>>> """ >>>>>> GDALOpen(/vsicurl_streaming/https:... >>>>>> """ >>>>>> with BBOX. >>>>>> No wonder I do not get reliable results if the server is calling >>>>>> some 1000 whatsoever result objects and starts filtering the bbox >>>>>> after. >>>>>> >>>>>> Any idea what is happening? Or is this something for a GDAL thread? >>>>>> >>>>>> Best >>>>>> Lars >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> mapserver-users mailing list >>>>> mapserver-users at lists.osgeo.org >>>>> https://lists.osgeo.org/mailman/listinfo/mapserver-users >>>> -- >>>> http://www.spatialys.com >>>> My software is free, but my time generally not. >>> >> -- >> http://www.spatialys.com >> My software is free, but my time generally not. > -- http://www.spatialys.com My software is free, but my time generally not. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jelmerbaas at nedgraphics.nl Sun May 30 23:24:29 2021 From: jelmerbaas at nedgraphics.nl (Jelmer Baas) Date: Mon, 31 May 2021 06:24:29 +0000 Subject: [mapserver-users] Mapscript C# and OWSRequest parameters In-Reply-To: References: Message-ID: Hi all, I had some issues getting subscribed. Did this email arrive? If so, does anyone have some insights, even if it's just a pointer to a place to continue my search? Regards, Jelmer Baas From: mapserver-users On Behalf Of Jelmer Baas Sent: donderdag 27 mei 2021 10:39 To: mapserver-users at lists.osgeo.org Subject: [mapserver-users] Mapscript C# and OWSRequest parameters Hello, For a new project, I've decided to pickup MapScript again to function as an internal (back-end) WFS server. I use the OWSRequest class, which works fine when I fill it with loadParamsFromURL() - in the case of Get requests. I can't seem to figure out a way to get my POST data into this object, though. It has a loadParams method, but because I'm not running as a CGI application (back-end app without a webserver), this doesn't do anything. I also tried setting postrequest property and then calling the loadParams, setting Environment variables, etc. No error, no exception, just -1 value from NumParams. Any suggestions on how to proceed? Regards, Jelmer Baas -------------- next part -------------- An HTML attachment was scrubbed... URL: From jelmerbaas at nedgraphics.nl Mon May 31 00:16:34 2021 From: jelmerbaas at nedgraphics.nl (Jelmer Baas) Date: Mon, 31 May 2021 07:16:34 +0000 Subject: [mapserver-users] Mapscript C# and OWSRequest parameters In-Reply-To: References: Message-ID: Hi Seth, Thanks for the pointer, I?ll give this a try. (Your mail got caught in a spam filter; apologies) Regards, Jelmer Baas From: mapserver-users On Behalf Of Seth G Sent: donderdag 27 mei 2021 20:35 To: mapserver-users at lists.osgeo.org Subject: Re: [mapserver-users] Mapscript C# and OWSRequest parameters Hi Jelmer, I think you'd have to use mapscript.msIO_installStdinFromBuffer to read data in. See https://mapserver.org/development/rfc/ms-rfc-16.html#io-hooking although I'm not sure if the approach works or was fully implemented. Let us know how you get on, Seth -- web:http://geographika.co.uk twitter: @geographika On Thu, May 27, 2021, at 10:39 AM, Jelmer Baas wrote: Hello, For a new project, I?ve decided to pickup MapScript again to function as an internal (back-end) WFS server. I use the OWSRequest class, which works fine when I fill it with loadParamsFromURL() ? in the case of Get requests. I can?t seem to figure out a way to get my POST data into this object, though. It has a loadParams method, but because I?m not running as a CGI application (back-end app without a webserver), this doesn?t do anything. I also tried setting postrequest property and then calling the loadParams, setting Environment variables, etc. No error, no exception, just -1 value from NumParams. Any suggestions on how to proceed? Regards, Jelmer Baas _______________________________________________ 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 lars.fricke at skendata.de Mon May 31 00:37:29 2021 From: lars.fricke at skendata.de (Lars Fricke) Date: Mon, 31 May 2021 09:37:29 +0200 Subject: [mapserver-users] WFS Client returns data at random with very same call In-Reply-To: <2eb4a26b-2483-d46b-17ac-cd6d52d6d7ed@spatialys.com> References: <2d0c3bab-d3a8-972a-13da-b07a24baa8e9@skendata.de> <10b1dc3f-ed06-33d2-f2d1-15def00d5ac7@skendata.de> <4fa6a6c7-38a4-76d9-f49c-6870eb97471b@spatialys.com> <2eb4a26b-2483-d46b-17ac-cd6d52d6d7ed@spatialys.com> Message-ID: <7d299738-5336-92d0-1ace-d80a4a06ec11@skendata.de> An HTML attachment was scrubbed... URL: From jelmerbaas at nedgraphics.nl Mon May 31 01:45:25 2021 From: jelmerbaas at nedgraphics.nl (Jelmer Baas) Date: Mon, 31 May 2021 08:45:25 +0000 Subject: [mapserver-users] Mapscript C# and OWSRequest parameters In-Reply-To: References: Message-ID: Hi all, Well, that route was a short one. Yes, I can call installStdinFromBuffer, but actually reading something via bufferRead: int msIO_bufferRead( void *cbData, void *data, int byteCount ) { (void)cbData; (void)data; (void)byteCount; /* not implemented yet. */ return 0; } Unless I?m missing something, this isn?t possible, yet. I find it hard to believe no-one uses MapServer to handle WFS Post requests, so I?m pretty sure I?m missing something? Regards, Jelmer Baas From: mapserver-users On Behalf Of Seth G Sent: donderdag 27 mei 2021 20:35 To: mapserver-users at lists.osgeo.org Subject: Re: [mapserver-users] Mapscript C# and OWSRequest parameters Hi Jelmer, I think you'd have to use mapscript.msIO_installStdinFromBuffer to read data in. See https://mapserver.org/development/rfc/ms-rfc-16.html#io-hooking although I'm not sure if the approach works or was fully implemented. Let us know how you get on, Seth -- web:http://geographika.co.uk twitter: @geographika On Thu, May 27, 2021, at 10:39 AM, Jelmer Baas wrote: Hello, For a new project, I?ve decided to pickup MapScript again to function as an internal (back-end) WFS server. I use the OWSRequest class, which works fine when I fill it with loadParamsFromURL() ? in the case of Get requests. I can?t seem to figure out a way to get my POST data into this object, though. It has a loadParams method, but because I?m not running as a CGI application (back-end app without a webserver), this doesn?t do anything. I also tried setting postrequest property and then calling the loadParams, setting Environment variables, etc. No error, no exception, just -1 value from NumParams. Any suggestions on how to proceed? Regards, Jelmer Baas _______________________________________________ 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 Mon May 31 03:10:58 2021 From: sethg at geographika.co.uk (Seth G) Date: Mon, 31 May 2021 12:10:58 +0200 Subject: [mapserver-users] Mapscript C# and OWSRequest parameters In-Reply-To: References: Message-ID: <07514a32-9741-4a25-961a-3986ca90845b@www.fastmail.com> Hi Jelmer, There is no issue using MapServer to handle WFS POST requests, but it seems as though this functionality was never implemented for the MapScript bindings. See links: https://github.com/MapServer/MapServer/issues/1788#issuecomment-42658553 > To implement this, we would need to actually implement the msIO_bufferRead() > function in mapio.c, and add a function to push data into this buffer > (something roughly like msIO_getStdoutBufferString() and > msIO_getStdoutBufferBytes() from mapscript/swiginc/msio.i but in the > opposite direction). > And also https://github.com/MapServer/MapServer/issues/2681#issue-3960720 So two options - 1) add in the functionality for msIO_bufferRead (which would be a nice addition to MapServer), or 2) use the other MapScript querying mechanisms as documented at https://geographika.github.io/MapServer-documentation/mapscript/querying.html Seth -- web:http://geographika.co.uk twitter: @geographika On Mon, May 31, 2021, at 10:45 AM, Jelmer Baas wrote: > Hi all, > > Well, that route was a short one. Yes, I can call installStdinFromBuffer, but actually reading something via bufferRead: > > int msIO_bufferRead( void *cbData, void *data, int byteCount ) > > { > (void)cbData; > (void)data; > (void)byteCount; > /* not implemented yet. */ > return 0; > } > > Unless I?m missing something, this isn?t possible, yet. I find it hard to believe no-one uses MapServer to handle WFS Post requests, so I?m pretty sure I?m missing something? > > Regards, > Jelmer Baas > > *From:* mapserver-users *On Behalf Of *Seth G > *Sent:* donderdag 27 mei 2021 20:35 > *To:* mapserver-users at lists.osgeo.org > *Subject:* Re: [mapserver-users] Mapscript C# and OWSRequest parameters > > Hi Jelmer, > > I think you'd have to use mapscript.msIO_installStdinFromBuffer to read data in. > See https://mapserver.org/development/rfc/ms-rfc-16.html#io-hooking although I'm not sure if the approach works or was fully implemented. > Let us know how you get on, > > Seth > > -- > web:http://geographika.co.uk > twitter: @geographika > > > On Thu, May 27, 2021, at 10:39 AM, Jelmer Baas wrote: >> Hello, >> >> For a new project, I?ve decided to pickup MapScript again to function as an internal (back-end) WFS server. I use the OWSRequest class, which works fine when I fill it with loadParamsFromURL() ? in the case of Get requests. >> >> I can?t seem to figure out a way to get my POST data into this object, though. It has a loadParams method, but because I?m not running as a CGI application (back-end app without a webserver), this doesn?t do anything. I also tried setting postrequest property and then calling the loadParams, setting Environment variables, etc. No error, no exception, just -1 value from NumParams. >> >> Any suggestions on how to proceed? >> >> Regards, >> Jelmer Baas >> >> >> _______________________________________________ >> 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 mathias.cunault at inrap.fr Mon May 31 03:20:42 2021 From: mathias.cunault at inrap.fr (mathias cunault) Date: Mon, 31 May 2021 12:20:42 +0200 Subject: [mapserver-users] Styling a WFS ? or not ? Message-ID: Hello, It seems that styling a WFS is nonsense according to what I found on the net (?). And I couldn't do it until now. But in Mapserver doc there is an example with a WFS and a style https://www.mapserver.org/ogc/wfs_server.html . So I am a bit confused : is there a way to stylize a WFS layer or I misunderstand the doc ? Thanks -- *----------* *Mathias Cunault* *r?f?rent SIG / Admin Caviar* *Inrap Tours - 148 av. Maginot37000 TOURS06 32 05 98 96mathias.cunault at inrap.fr * www.inrap.fr abonnez-vous ? la lettre d'information de l'Inrap : http://www.inrap.fr/newsletter.php -------------- next part -------------- An HTML attachment was scrubbed... URL: From sethg at geographika.co.uk Mon May 31 03:59:21 2021 From: sethg at geographika.co.uk (Seth G) Date: Mon, 31 May 2021 12:59:21 +0200 Subject: [mapserver-users] Mapscript C# and OWSRequest parameters In-Reply-To: References: Message-ID: <4a9dd68d-9ef8-4615-be23-696b31ee6fe8@www.fastmail.com> Actually as there are no URL limits with MapScript you should be able to add your filter as a WFS GET parameter and skip using POST requests altogether. https://www.mapserver.org/fr/ogc/filter_encoding.html#tests -- web:http://geographika.co.uk twitter: @geographika On Mon, May 31, 2021, at 10:45 AM, Jelmer Baas wrote: > Hi all, > > Well, that route was a short one. Yes, I can call installStdinFromBuffer, but actually reading something via bufferRead: > > int msIO_bufferRead( void *cbData, void *data, int byteCount ) > > { > (void)cbData; > (void)data; > (void)byteCount; > /* not implemented yet. */ > return 0; > } > > Unless I?m missing something, this isn?t possible, yet. I find it hard to believe no-one uses MapServer to handle WFS Post requests, so I?m pretty sure I?m missing something? > > Regards, > Jelmer Baas > > *From:* mapserver-users *On Behalf Of *Seth G > *Sent:* donderdag 27 mei 2021 20:35 > *To:* mapserver-users at lists.osgeo.org > *Subject:* Re: [mapserver-users] Mapscript C# and OWSRequest parameters > > Hi Jelmer, > > I think you'd have to use mapscript.msIO_installStdinFromBuffer to read data in. > See https://mapserver.org/development/rfc/ms-rfc-16.html#io-hooking although I'm not sure if the approach works or was fully implemented. > Let us know how you get on, > > Seth > > -- > web:http://geographika.co.uk > twitter: @geographika > > > On Thu, May 27, 2021, at 10:39 AM, Jelmer Baas wrote: >> Hello, >> >> For a new project, I?ve decided to pickup MapScript again to function as an internal (back-end) WFS server. I use the OWSRequest class, which works fine when I fill it with loadParamsFromURL() ? in the case of Get requests. >> >> I can?t seem to figure out a way to get my POST data into this object, though. It has a loadParams method, but because I?m not running as a CGI application (back-end app without a webserver), this doesn?t do anything. I also tried setting postrequest property and then calling the loadParams, setting Environment variables, etc. No error, no exception, just -1 value from NumParams. >> >> Any suggestions on how to proceed? >> >> Regards, >> Jelmer Baas >> >> >> _______________________________________________ >> 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 jmckenna at gatewaygeomatics.com Mon May 31 05:36:04 2021 From: jmckenna at gatewaygeomatics.com (Jeff McKenna) Date: Mon, 31 May 2021 09:36:04 -0300 Subject: [mapserver-users] Styling a WFS ? or not ? In-Reply-To: References: Message-ID: <005fd269-da95-87f5-d9ff-befada3bba12@gatewaygeomatics.com> Hi Mathias, Styling of WFS services happens on the client-side. For example, see this WFS-client layer example, where you can set any color that you wish for this 'continents' layer that is served through a remote WFS service : https://www.mapserver.org/ogc/wfs_client.html#example-wfs-layer You can copy/paste that entire layer into your own mapfile (and change the COLOR values) and then execute it with a shp2img command, to see what I mean. Hope that helps, -jeff -- Jeff McKenna GatewayGeo: Developers of MS4W, MapServer Consulting and Training co-founder of FOSS4G http://gatewaygeo.com/ On 2021-05-31 7:20 a.m., mathias cunault via mapserver-users wrote: > Hello, > It seems that styling a WFS is nonsense according to what I found on the > net (?). And I couldn't do it until now. But in Mapserver doc there is > an example with a WFS and a style > https://www.mapserver.org/ogc/wfs_server.html > . > So I am a bit confused : is there a way to stylize a WFS layer or I > misunderstand the doc ? > Thanks > > -- > /----------/ > /Mathias Cunault/ > /r?f?rent SIG / Admin Caviar > ///Inrap Tours - /148 av. Maginot > 37000 TOURS > 06 32 05 98 96 > _mathias.cunault at inrap.fr _/ > www.inrap.fr > abonnez-vous ? la lettre d'information de l'Inrap : > http://www.inrap.fr/newsletter.php > > _______________________________________________ > mapserver-users mailing list > mapserver-users at lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/mapserver-users > From jukka.rahkonen at maanmittauslaitos.fi Mon May 31 05:40:42 2021 From: jukka.rahkonen at maanmittauslaitos.fi (Rahkonen Jukka (MML)) Date: Mon, 31 May 2021 12:40:42 +0000 Subject: [mapserver-users] Styling a WFS ? or not ? Message-ID: Hi, Mapserver can serve a layers through different services. STYLE is not for WFS but it can be used in &mode=map or in the WMS service. Similarly Geoserver can deliver GML data http://demo.geo-solutions.it/geoserver/topp/ows?service=WFS&version=1.0.0&request=GetFeature&typeName=topp:states&maxFeatures=50 or the same data as styled through WMS http://demo.geo-solutions.it/geoserver/topp/wms?service=WMS&version=1.1.0&request=GetMap&layers=topp:states&styles=&bbox=-124.73142200000001,24.955967,-66.969849,49.371735&width=768&height=330&srs=EPSG:4326&format=application/openlayers -Jukka Rahkonen- L?hett?j?: mapserver-users > Puolesta mathias cunault via mapserver-users L?hetetty: maanantai 31. toukokuuta 2021 13.21 Vastaanottaja: mapserver-users at lists.osgeo.org Aihe: [mapserver-users] Styling a WFS ? or not ? Hello, It seems that styling a WFS is nonsense according to what I found on the net (?). And I couldn't do it until now. But in Mapserver doc there is an example with a WFS and a style https://www.mapserver.org/ogc/wfs_server.html. So I am a bit confused : is there a way to stylize a WFS layer or I misunderstand the doc ? Thanks -- ---------- Mathias Cunault r?f?rent SIG / Admin Caviar Inrap Tours - 148 av. Maginot 37000 TOURS 06 32 05 98 96 mathias.cunault at inrap.fr www.inrap.fr abonnez-vous ? la lettre d'information de l'Inrap : http://www.inrap.fr/newsletter.php -------------- next part -------------- An HTML attachment was scrubbed... URL: From joerg.thomsen at wheregroup.com Mon May 31 06:02:00 2021 From: joerg.thomsen at wheregroup.com (=?UTF-8?Q?J=c3=b6rg_Thomsen_=28WhereGroup=29?=) Date: Mon, 31 May 2021 15:02:00 +0200 Subject: [mapserver-users] Styling a WFS ? or not ? In-Reply-To: References: Message-ID: <7e1e5588-9799-2d17-ccf7-9bb9fc1bd74f@wheregroup.com> BUT... (more as an anwser to jeff): Mathias is right, WFS needs no style information on server-side. The wohle class-section of the example is not necessary (useless if only used f?r wfs-requests). shp2img might use it but a wfs-request doesn't and a wms-request should not work, because the examples only configures a wfs. (or is it me woh is confused?) J?rg Am 31.05.21 um 14:40 schrieb Rahkonen Jukka (MML) via mapserver-users: > Hi, > > ? > > Mapserver can serve a layers through different services. STYLE is not > for WFS but it can be used in &mode=map or in the WMS service. > > ? > > Similarly Geoserver can deliver GML data > http://demo.geo-solutions.it/geoserver/topp/ows?service=WFS&version=1.0.0&request=GetFeature&typeName=topp:states&maxFeatures=50 > > > ? > > or the same data as styled through WMS > > http://demo.geo-solutions.it/geoserver/topp/wms?service=WMS&version=1.1.0&request=GetMap&layers=topp:states&styles=&bbox=-124.73142200000001,24.955967,-66.969849,49.371735&width=768&height=330&srs=EPSG:4326&format=application/openlayers > > > ? > > -Jukka Rahkonen- > > ? > > ? > > *L?hett?j?:* mapserver-users > *Puolesta *mathias > cunault via mapserver-users > *L?hetetty:* maanantai 31. toukokuuta 2021 13.21 > *Vastaanottaja:* mapserver-users at lists.osgeo.org > > *Aihe:* [mapserver-users] Styling a WFS ? or not ? > > ? > > Hello, > > It seems that styling a WFS is nonsense according to what I found on the > net (?). And I couldn't do it until now. But in Mapserver doc there is > an example with a WFS and a style > https://www.mapserver.org/ogc/wfs_server.html > . > > So I am a bit confused : is there a way to stylize a WFS layer or I > misunderstand the doc ? > > Thanks > > > -- > > /----------/ > > /Mathias Cunault/ > > /r?f?rent SIG / Admin Caviar > Inrap Tours - 148 av. Maginot > 37000 TOURS > 06 32 05 98 96 > //mathias.cunault at inrap.fr/ > > www.inrap.fr > abonnez-vous ? la lettre d'information de l'Inrap : > http://www.inrap.fr/newsletter.php > > > _______________________________________________ > mapserver-users mailing list > mapserver-users at lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/mapserver-users > Viele Gr??e, J?rg Thomsen -- ---------------------------------------------------- Aufwind durch Wissen! Web-Seminare und Online-Schulungen bei der www.foss-academy.com ---------------------------------------------------- J?rg Thomsen WhereGroup GmbH Bundesallee 23 10717 Berlin Germany Fon: +49 (0)30 / 5130 278 74 Fax: +49 (0)30 / 5130 278 11 joerg.thomsen at wheregroup.com www.wheregroup.com Gesch?ftsf?hrer: Olaf Knopp, Peter Stamm Amtsgericht Bonn, HRB 9885 ------------------------------- Folgen Sie der WhereGroup auf twitter: http://twitter.com/WhereGroup_com From stephane.brunner at camptocamp.com Mon May 31 07:32:43 2021 From: stephane.brunner at camptocamp.com (=?UTF-8?Q?St=C3=A9phane_Brunner?=) Date: Mon, 31 May 2021 16:32:43 +0200 Subject: [mapserver-users] Fwd: WFS query on WFS layer is very slow In-Reply-To: References: Message-ID: Hello, I have a layer configured like this: LAYER NAME "borne_hydrante" GROUP "borne_hydrante_gr" TYPE POINT TEMPLATE "ttt" CONNECTIONTYPE WFS CONNECTION "https://bdbh.eca-vaud.ch/ows?" METADATA "wfs_title" "borne_hydrante" "wfs_typename" "ms:borne_hydrante" "ows_title" "ms:borne_hydrante" "wms_title" "borne_hydrante" "wfs_srs" "EPSG:2056" "wfs_enable_request" "*" "ows_geom_type" "point" "ows_geometries" "geom" "wms_srs" "EPSG:2056" "wms_server_version" "1.1.1" "wfs_version" "1.0.0" "wms_format" "image/png" "wms_name" "ms:borne_hydrante" "gml_featureid" "id" "gml_types" "auto" "gml_include_items" "all" END DUMP FALSE PROJECTION "init=epsg:2056" END CLASS NAME "borne hydrante ECA" STYLE SYMBOL "circle" SIZE 12 OUTLINECOLOR 0 210 0 COLOR 255 255 255 END STYLE SYMBOL "circle" SIZE 6 OUTLINECOLOR 0 210 0 COLOR 0 210 0 END END END It's working well on WMS but on WFS it's relay slow: Example of WFS query geom2560925 1131734.99999999982560940 1131749.9999999998 When I have a look on the logs I see that the query is done 3 times... logs Is there a configuration That I can do to have better performances? Sincerely, St?phane Brunner -- *St?phane Brunner* Geospatial Solutions Software Developer *camptocamp* INNOVATIVE SOLUTIONS BY OPEN SOURCE EXPERTS camptocamp.com mapfish.org -- *St?phane Brunner* Geospatial Solutions Software Developer *camptocamp* INNOVATIVE SOLUTIONS BY OPEN SOURCE EXPERTS camptocamp.com mapfish.org -------------- next part -------------- An HTML attachment was scrubbed... URL: