From aperi2007 at gmail.com Mon Aug 3 02:02:43 2015 From: aperi2007 at gmail.com (Andrea Peri) Date: Mon, 3 Aug 2015 11:02:43 +0200 Subject: [mapserver-users] processing scale=auto with float multibands rasters Message-ID: Hi, I have a geotiff multibands with float64 values to serve with a wms mapserver service. With this kind of rasters, is affordable the directive PROCESSING "BANDS=4,3,2" PROCESSING "SCALE=AUTO" (the 4,3,2 are the red,green,blue channels) Infact it seem do nothing. Instead all work well if I set: PROCESSING "BANDS=4,3,2" PROCESSING "SCALE_1=0.01,0.2" PROCESSING "SCALE_2=0.01,0.2" PROCESSING "SCALE_3=0.01,0.2" where ii use the min=0.01 and max=0.2 But I like to have the exact values of min/max for every raster. Thx. -- ----------------- Andrea Peri . . . . . . . . . qwerty ????? ----------------- From raffaele.morelli at gmail.com Mon Aug 3 05:16:27 2015 From: raffaele.morelli at gmail.com (Raffaele Morelli) Date: Mon, 3 Aug 2015 14:16:27 +0200 Subject: [mapserver-users] html legend not working Message-ID: <20150803121627.GA1597@gmail.com> Short story: I can't get html legend to work... legend.html file is in the same directory of the mapfile, as you can see the LABEL block is a verbatim copy from Mapserver documentation. The INCLUDE layer is a point layer with CLASS correctly defined. This my request to test http://localhost/cgi-bin/mapserv?MAP=/home/www/geomoose-2.8.0/maps/cen_default//cen_default.map&FORMAT=image/png&TRANSPARENT=TRUE&SERVICE=WMS&VERSION=1.1.1&REQUEST=GetLegendGraphic&_OLSALT=0.9622128666378558&SRS=EPSG:3857&SCALE=6933486.650500195&WIDTH=250&STYLE=&LAYER=sostegni The legend is returned a png file, just like TEMPLATE statement wasn't taken into account. Any hint? Mapfile: MAP NAME 'XXX' UNITS meters EXTENT 728034.319166294 4193385.80350739 2183515.00526018 5960168.11180283 CONFIG 'MS_ERRORFILE' '/var/log/ms_error.log' DEBUG 1 SIZE 800 600 SYMBOLSET "/home/www/geomoose-2.8.0/maps/symbols/symbols-catasto.sym" FONTSET "/home/www/geomoose-2.8.0/maps/fonts/msfontset.txt" RESOLUTION 72 PROJECTION #"init=epsg:32632" #"init=epsg:4326" "init=epsg:3857" #"init=epsg:900913" END OUTPUTFORMAT NAME "png" DRIVER AGG/PNG MIMETYPE "image/png" IMAGEMODE RGB EXTENSION "png" FORMATOPTION "GAMMA=0.75" END OUTPUTFORMAT NAME "gif" DRIVER GD/GIF MIMETYPE "image/gif" IMAGEMODE PC256 EXTENSION "gif" END OUTPUTFORMAT NAME "png8" DRIVER AGG/PNG8 MIMETYPE "image/png; mode=8bit" IMAGEMODE RGB EXTENSION "png" FORMATOPTION "QUANTIZE_FORCE=on" FORMATOPTION "QUANTIZE_COLORS=256" FORMATOPTION "GAMMA=0.75" END OUTPUTFORMAT NAME "jpeg" DRIVER AGG/JPEG MIMETYPE "image/jpeg" IMAGEMODE RGB EXTENSION "jpg" FORMATOPTION "GAMMA=0.75" END OUTPUTFORMAT NAME "svg" DRIVER CAIRO/SVG MIMETYPE "image/svg+xml" IMAGEMODE RGB EXTENSION "svg" END OUTPUTFORMAT NAME "pdf" DRIVER CAIRO/PDF MIMETYPE "application/x-pdf" IMAGEMODE RGB EXTENSION "pdf" END OUTPUTFORMAT NAME "GTiff" DRIVER GDAL/GTiff MIMETYPE "image/tiff" IMAGEMODE RGB EXTENSION "tif" END OUTPUTFORMAT NAME "kml" DRIVER KML MIMETYPE "application/vnd.google-earth.kml.xml" IMAGEMODE RGB EXTENSION "kml" END OUTPUTFORMAT NAME "kmz" DRIVER KMZ MIMETYPE "application/vnd.google-earth.kmz" IMAGEMODE RGB EXTENSION "kmz" END OUTPUTFORMAT NAME "cairopng" DRIVER CAIRO/PNG MIMETYPE "image/png" IMAGEMODE RGB EXTENSION "png" END WEB IMAGEPATH "/home/www/tmp/" IMAGEURL "/ms_tmp/" METADATA "wms_title" "CEN" "wms_onlineresource" "http://localhost/cgi-bin/cen?SERVICE=WMS&VERSION=1.1.1&REQUEST=GetCapabilities" "wms_enable_request" "*" "wms_srs" "EPSG:32632 EPSG:4326 EPSG:900913 EPSG:3857" END # Metadata END # Web LEGEND STATUS ON KEYSIZE 18 12 # LABEL object LABEL TYPE BITMAP SIZE MEDIUM COLOR 0 0 89 END TEMPLATE "legend.html" ### HTML template file END INCLUDE 'sostegni_italia.map' END -- ?My mama said to get things done You'd better not mess with Major Tom? From jukka.rahkonen at maanmittauslaitos.fi Mon Aug 3 05:26:03 2015 From: jukka.rahkonen at maanmittauslaitos.fi (Rahkonen Jukka (MML)) Date: Mon, 3 Aug 2015 12:26:03 +0000 Subject: [mapserver-users] html legend not working Message-ID: <2db39ad317954e098bd9e38eab7441c1@C119S212VM022.msvyvi.vaha.local> Hi, By a quick look at http://mapserver.org/ogc/wms_server.html you should probably add text/html as a GetLegendGraphic format: wms_getlegendgraphic_formatlist Description: (Optional) A comma-separated list of valid formats for a WMS GetLegendGraphic request. and then use &format=text/html in your request. However, I have not tried that myself but this is just my best guess. -Jukka Rahkonen- Raffaele Morelli wrote: > Short story: I can't get html legend to work... > legend.html file is in the same directory of the mapfile, as you can see the LABEL block is a verbatim copy from Mapserver documentation. > The INCLUDE layer is a point layer with CLASS correctly defined. > This my request to test http://localhost/cgi-bin/mapserv?MAP=/home/www/geomoose-2.8.0/maps/cen_default//cen_default.map&FORMAT=image/png&TRANSPARENT=TRUE&SERVICE=WMS&VERSION=1.1.1&REQUEST=GetLegendGraphic&_OLSALT=0.9622128666378558&SRS=EPSG:3857&SCALE=6933486.650500195&WIDTH=250&STYLE=&LAYER=sostegni The legend is returned a png file, just like TEMPLATE statement wasn't taken into account. Any hint? Mapfile: MAP NAME 'XXX' UNITS meters EXTENT 728034.319166294 4193385.80350739 2183515.00526018 5960168.11180283 CONFIG 'MS_ERRORFILE' '/var/log/ms_error.log' DEBUG 1 SIZE 800 600 SYMBOLSET "/home/www/geomoose-2.8.0/maps/symbols/symbols-catasto.sym" FONTSET "/home/www/geomoose-2.8.0/maps/fonts/msfontset.txt" RESOLUTION 72 PROJECTION #"init=epsg:32632" #"init=epsg:4326" "init=epsg:3857" #"init=epsg:900913" END OUTPUTFORMAT NAME "png" DRIVER AGG/PNG MIMETYPE "image/png" IMAGEMODE RGB EXTENSION "png" FORMATOPTION "GAMMA=0.75" END OUTPUTFORMAT NAME "gif" DRIVER GD/GIF MIMETYPE "image/gif" IMAGEMODE PC256 EXTENSION "gif" END OUTPUTFORMAT NAME "png8" DRIVER AGG/PNG8 MIMETYPE "image/png; mode=8bit" IMAGEMODE RGB EXTENSION "png" FORMATOPTION "QUANTIZE_FORCE=on" FORMATOPTION "QUANTIZE_COLORS=256" FORMATOPTION "GAMMA=0.75" END OUTPUTFORMAT NAME "jpeg" DRIVER AGG/JPEG MIMETYPE "image/jpeg" IMAGEMODE RGB EXTENSION "jpg" FORMATOPTION "GAMMA=0.75" END OUTPUTFORMAT NAME "svg" DRIVER CAIRO/SVG MIMETYPE "image/svg+xml" IMAGEMODE RGB EXTENSION "svg" END OUTPUTFORMAT NAME "pdf" DRIVER CAIRO/PDF MIMETYPE "application/x-pdf" IMAGEMODE RGB EXTENSION "pdf" END OUTPUTFORMAT NAME "GTiff" DRIVER GDAL/GTiff MIMETYPE "image/tiff" IMAGEMODE RGB EXTENSION "tif" END OUTPUTFORMAT NAME "kml" DRIVER KML MIMETYPE "application/vnd.google-earth.kml.xml" IMAGEMODE RGB EXTENSION "kml" END OUTPUTFORMAT NAME "kmz" DRIVER KMZ MIMETYPE "application/vnd.google-earth.kmz" IMAGEMODE RGB EXTENSION "kmz" END OUTPUTFORMAT NAME "cairopng" DRIVER CAIRO/PNG MIMETYPE "image/png" IMAGEMODE RGB EXTENSION "png" END WEB IMAGEPATH "/home/www/tmp/" IMAGEURL "/ms_tmp/" METADATA "wms_title" "CEN" "wms_onlineresource" "http://localhost/cgi-bin/cen?SERVICE=WMS&VERSION=1.1.1&REQUEST=GetCapabilities" "wms_enable_request" "*" "wms_srs" "EPSG:32632 EPSG:4326 EPSG:900913 EPSG:3857" END # Metadata END # Web LEGEND STATUS ON KEYSIZE 18 12 # LABEL object LABEL TYPE BITMAP SIZE MEDIUM COLOR 0 0 89 END TEMPLATE "legend.html" ### HTML template file END INCLUDE 'sostegni_italia.map' END -- _______________________________________________ mapserver-users mailing list mapserver-users at lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users From raffaele.morelli at gmail.com Mon Aug 3 05:55:48 2015 From: raffaele.morelli at gmail.com (Raffaele Morelli) Date: Mon, 3 Aug 2015 14:55:48 +0200 Subject: [mapserver-users] html legend not working In-Reply-To: <2db39ad317954e098bd9e38eab7441c1@C119S212VM022.msvyvi.vaha.local> References: <2db39ad317954e098bd9e38eab7441c1@C119S212VM022.msvyvi.vaha.local> Message-ID: <20150803125548.GA23108@gmail.com> On 03/08/15 at 12:26pm, Rahkonen Jukka (MML) wrote: > Hi, > > By a quick look at http://mapserver.org/ogc/wms_server.html you should probably add text/html as a GetLegendGraphic format: > wms_getlegendgraphic_formatlist > > Description: (Optional) A comma-separated list of valid formats for a WMS GetLegendGraphic request. > > and then use &format=text/html in your request. However, I have not tried that myself but this is just my best guess. > > -Jukka Rahkonen- > > Raffaele Morelli wrote: > > > Short story: I can't get html legend to work... > > > legend.html file is in the same directory of the mapfile, as you can see the LABEL block is a verbatim copy from Mapserver documentation. > > > The INCLUDE layer is a point layer with CLASS correctly defined. > > > This my request to test > http://localhost/cgi-bin/mapserv?MAP=/home/www/geomoose-2.8.0/maps/cen_default//cen_default.map&FORMAT=image/png&TRANSPARENT=TRUE&SERVICE=WMS&VERSION=1.1.1&REQUEST=GetLegendGraphic&_OLSALT=0.9622128666378558&SRS=EPSG:3857&SCALE=6933486.650500195&WIDTH=250&STYLE=&LAYER=sostegni > > The legend is returned a png file, just like TEMPLATE statement wasn't taken into account. > > > Any hint? > Added, but it doesn't work. I got this error: msWMSGetLegendGraphic(): Image handling error. Unsupported output format (text/html). PS please do not top post -- ?My mama said to get things done You'd better not mess with Major Tom? From jukka.rahkonen at maanmittauslaitos.fi Mon Aug 3 06:55:47 2015 From: jukka.rahkonen at maanmittauslaitos.fi (Rahkonen Jukka (MML)) Date: Mon, 3 Aug 2015 13:55:47 +0000 Subject: [mapserver-users] html legend not working Message-ID: Hi, I am not sure if HTML legends really work with WMS. The demo site that is mentioned in the html legend manual page must support html legends. http://demo.mapserver.org/cgi-bin/mapserv?map=%2Fosgeo%2Fmapserver%2Fitasca_legend%2Fmap%2Fitasca1.map&layers=all&zoomsize=2&zoomdir=1&map_size=600+400 However, I could not find any way for reading the html legend through WMS. Format image/png does work for me http://demo.mapserver.org/cgi-bin/mapserv?map=%2Fosgeo%2Fmapserver%2Fitasca_legend%2Fmap%2Fitasca1.map&service=wms&version=1.1.1&request=getlegendgraphic&layer=ctyrdln3&format=image/png The site is advertising these formats for GetLegendGraphic, notice that html does not appear on the list even the service itself does support html legends if they are read with native Mapserver methods: image/gif image/png image/png; mode=24bit image/jpeg image/vnd.wap.wbmp I also tested the effect of adding this WEB object metadata item into some of our Mapserver 7.0 RC1 services: "wms_getlegendgraphic_formatlist" "text/html" This change does not have any effect on the advertised GetLegendGraphic formats of our server. They are always image/png image/jpeg image/gif image/png; mode=8bit However, if I use "wms_getlegendgraphic_formatlist" "image/jpeg" then I can't read the legend as image/png even it does still show in GetCapabilities. So this setting works with the image formats as described in the documentation but there is a bug because the setting does not reflect to GetCapabilities. When it comes to top posting, I always top post but I also try to include some useful information into my mails for compensating the irritation. And I know that bottom posting is irritating at least as many people as top posting. I apologize also that my mail program does poor job with quoting previous mails. Regards, -Jukka Rahkonen- Raffaele Morelli wrote: On 03/08/15 at 12:26pm, Rahkonen Jukka (MML) wrote: > Hi, > > By a quick look at http://mapserver.org/ogc/wms_server.html you should probably add text/html as a GetLegendGraphic format: > wms_getlegendgraphic_formatlist > > Description: (Optional) A comma-separated list of valid formats for a WMS GetLegendGraphic request. > > and then use &format=text/html in your request. However, I have not tried that myself but this is just my best guess. > > -Jukka Rahkonen- > > Raffaele Morelli wrote: > > > Short story: I can't get html legend to work... > > > legend.html file is in the same directory of the mapfile, as you can see the LABEL block is a verbatim copy from Mapserver documentation. > > > The INCLUDE layer is a point layer with CLASS correctly defined. > > > This my request to test > http://localhost/cgi-bin/mapserv?MAP=/home/www/geomoose-2.8.0/maps/cen_default//cen_default.map&FORMAT=image/png&TRANSPARENT=TRUE&SERVICE=WMS&VERSION=1.1.1&REQUEST=GetLegendGraphic&_OLSALT=0.9622128666378558&SRS=EPSG:3857&SCALE=6933486.650500195&WIDTH=250&STYLE=&LAYER=sostegni > > The legend is returned a png file, just like TEMPLATE statement wasn't taken into account. > > > Any hint? > Added, but it doesn't work. I got this error: msWMSGetLegendGraphic(): Image handling error. Unsupported output format (text/html). PS please do not top post -- From raffaele.morelli at gmail.com Mon Aug 3 07:05:46 2015 From: raffaele.morelli at gmail.com (Raffaele Morelli) Date: Mon, 3 Aug 2015 16:05:46 +0200 Subject: [mapserver-users] html legend not working In-Reply-To: References: Message-ID: 2015-08-03 15:55 GMT+02:00 Rahkonen Jukka (MML) < jukka.rahkonen at maanmittauslaitos.fi>: > Hi, > > > I am not sure if HTML legends really work with WMS. The demo site that is > mentioned in the html legend manual page must support html legends. > > http://demo.mapserver.org/cgi-bin/mapserv?map=%2Fosgeo%2Fmapserver%2Fitasca_legend%2Fmap%2Fitasca1.map&layers=all&zoomsize=2&zoomdir=1&map_size=600+400 > > However, I could not find any way for reading the html legend through WMS. > Format image/png does work for me > > http://demo.mapserver.org/cgi-bin/mapserv?map=%2Fosgeo%2Fmapserver%2Fitasca_legend%2Fmap%2Fitasca1.map&service=wms&version=1.1.1&request=getlegendgraphic&layer=ctyrdln3&format=image/png > > The site is advertising these formats for GetLegendGraphic, notice that > html does not appear on the list even the service itself does support html > legends if they are read with native Mapserver methods: > > > image/gif > image/png > image/png; mode=24bit > image/jpeg > image/vnd.wap.wbmp > > I also tested the effect of adding this WEB object metadata item into some > of our Mapserver 7.0 RC1 services: > "wms_getlegendgraphic_formatlist" "text/html" > ?The WMS request is the same my webapp (geomoose) is actually doing and which "fails" in returning html legend?. > > This change does not have any effect on the advertised GetLegendGraphic > formats of our server. They are always > > image/png > image/jpeg > image/gif > image/png; mode=8bit > > However, if I use "wms_getlegendgraphic_formatlist" "image/jpeg" then I > can't read the legend as image/png even it does still show in > GetCapabilities. So this setting works with the image formats as described > in the documentation but there is a bug because the setting does not > reflect to GetCapabilities. > > When it comes to top posting, I always top post but I also try to include > some useful information into my mails for compensating the irritation. And > I know that bottom posting is irritating at least as many people as top > posting. I apologize also that my mail program does poor job with quoting > previous mails. > ?I am not irritated, it's just a matter of logic and top posting simply doesn't work for conversation sequencing. ;-)? > > Regards, > > -Jukka Rahkonen- > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jukka.rahkonen at maanmittauslaitos.fi Mon Aug 3 07:57:45 2015 From: jukka.rahkonen at maanmittauslaitos.fi (Rahkonen Jukka (MML)) Date: Mon, 3 Aug 2015 14:57:45 +0000 Subject: [mapserver-users] Setting wms_getlegendgraphic_formatlist does not alter GetCapabilities Message-ID: <6c3dc30c01fc4eb38104580e24327e0d@C119S212VM022.msvyvi.vaha.local> Hi, It seems that setting the WEB metadata object "wms_getlegendgraphic_formatlist" as described in http://mapserver.org/ogc/wms_server.html does not change the list of advertised GetLegendGraphic formats in GetCapabilities. For example, if I set that only image/jpeg is supported my GetCapabilities is still showing the default list which is image/png image/jpeg image/gif image/png; mode=8bit Setting works as supposed for me and GetLegendGraphic succeeds only with image/jpeg but clients can't know that other formats do nor work because they are still advertised. . The "LegendURL" elements are not changed to suit the wms_getlegendgraphic_formatlist but the default image/png format is still advertised for all the layers in this way: LegendURL width="95" height="21">image/png I think that LegendURL should take the first format from the wms_getlegendgraphic_formatlist if it is set. I have only Mapserver 7.0 RC installed and It would be nice if someone who runs released 7.0 could confirm the issue before I make a bug report. Testing is easy: by just adding into any properly configured WMS mapfile this line into MAP-WEB level: "wms_getlegendgraphic_formatlist" "image/jpeg" and then check the GetCapabilities. -Jukka Rahkonen- -------------- next part -------------- An HTML attachment was scrubbed... URL: From raffaele.morelli at gmail.com Mon Aug 3 22:27:16 2015 From: raffaele.morelli at gmail.com (Raffaele Morelli) Date: Tue, 4 Aug 2015 07:27:16 +0200 Subject: [mapserver-users] html legend not working In-Reply-To: <20150803121627.GA1597@gmail.com> References: <20150803121627.GA1597@gmail.com> Message-ID: 2015-08-03 14:16 GMT+02:00 Raffaele Morelli : > Short story: I can't get html legend to work... > > legend.html file is in the same directory of the mapfile, as you can see > the LABEL block is > a verbatim copy from Mapserver documentation. > > The INCLUDE layer is a point layer with CLASS correctly defined. > > This my request to test > > http://localhost/cgi-bin/mapserv?MAP=/home/www/geomoose-2.8.0/maps/cen_default//cen_default.map&FORMAT=image/png&TRANSPARENT=TRUE&SERVICE=WMS&VERSION=1.1.1&REQUEST=GetLegendGraphic&_OLSALT=0.9622128666378558&SRS=EPSG:3857&SCALE=6933486.650500195&WIDTH=250&STYLE=&LAYER=sostegni > > The legend is returned a png file, just like TEMPLATE statement wasn't > taken into account. > > ?Reply to myself because I've found it's not a mapserver related issue but a geomoose one (no matter about LEGEND and TEMPLATE statements it always produces a png image) . ?/r? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jukka.rahkonen at maanmittauslaitos.fi Tue Aug 4 01:34:11 2015 From: jukka.rahkonen at maanmittauslaitos.fi (Rahkonen Jukka (MML)) Date: Tue, 4 Aug 2015 08:34:11 +0000 Subject: [mapserver-users] html legend not working Message-ID: <289cec6dfae74db880be15fda45d683f@C119S212VM022.msvyvi.vaha.local> Raffaele Morelli wrote: > Reply to myself because I've found it's not a mapserver related issue but a geomoose one (no matter about LEGEND and TEMPLATE statements it always produces a png image) . I don't quite agree. If GeoMoose is always making the GetLegendGraphic request by using image/png as a format then it is naturally getting a png image back. But so far I have not discovered how to make Mapserver to support html as one of the supported WMS GetLegendGraphic formats and what the WMS client should then use as a format in &format= parameter so there is also a Mapserver related aspect. -Jukka Rahkonen- ? From raffaele.morelli at gmail.com Tue Aug 4 02:28:36 2015 From: raffaele.morelli at gmail.com (Raffaele Morelli) Date: Tue, 4 Aug 2015 11:28:36 +0200 Subject: [mapserver-users] html legend not working In-Reply-To: <289cec6dfae74db880be15fda45d683f@C119S212VM022.msvyvi.vaha.local> References: <289cec6dfae74db880be15fda45d683f@C119S212VM022.msvyvi.vaha.local> Message-ID: <20150804092836.GA1605@gmail.com> On 04/08/15 at 08:34am, Rahkonen Jukka (MML) wrote: > Raffaele Morelli wrote: > > > > Reply to myself because I've found it's not a mapserver related issue but a geomoose one (no matter about LEGEND and TEMPLATE statements it always produces a png image) . > > I don't quite agree. If GeoMoose is always making the GetLegendGraphic request by using image/png as a format then it is naturally getting a png image back. But so far I have not discovered how to make Mapserver to support html as one of the supported WMS GetLegendGraphic formats and what the WMS client should then use as a format in &format= parameter so there is also a Mapserver related aspect. I won't say that, doc is very clear about WMS request returning an image: [quote] GetLegendGraphic: returns a legend image (icon) for the requested layer, with label(s). More information on this request can be found in the GetLegendGraphic section later in this doc. GetLegendGraphic Request This request returns a legend image (icon) for the specified layer. The request will draw an icon and a label for all classes defined on the layer. If the requested layername is a GROUP-name, all included layers will be returned in the legend-icon. [/quote] GeoMoose is doing a WMS request so no error on Mapserver side (and after all) nor on the GeoMoose one. TEMPLATE statement works well (returning html legend) when doin a cgi request. /raffaele -- ?My mama said to get things done You'd better not mess with Major Tom? From jukka.rahkonen at maanmittauslaitos.fi Tue Aug 4 03:00:27 2015 From: jukka.rahkonen at maanmittauslaitos.fi (Rahkonen Jukka (MML)) Date: Tue, 4 Aug 2015 10:00:27 +0000 Subject: [mapserver-users] html legend not working Message-ID: <58aba725f1ec45ec95d39023c0895875@C119S212VM022.msvyvi.vaha.local> Hi Raffaele, After doing some research, you are right and html legends do not belong to WMS but only to Mapserver CGI which I have never used myself. Reasoning: 1) From WMS 1.1.1 specification OGC 01-068r3, page 54: 7.5 GetLegendGraphic (SLD WMS only) The optional GetLegendGraphic operation applies only to a Styled Layer Descriptor WMS. See the SLD specification [3] for this operation. 2) From Styled Layer Descriptor Implementation Specification (v. 1.0.0), OGC 02-070, page 72: FORMAT: This gives the MIME type of the file format in which to return the legend graphic. Allowed values are the same as for the FORMAT= parameter of the WMS GetMap request. Same text is in SLD 1.1.0 specification. Because html is not a possible format for GetMap it is not possible to use is for GetLegendGraphic either. What remains is a small Mapserver bug with the wms_getlegendgraphic_formatlist metadata item because GetCapabilities may advertise different formats than those which are really supported. -Jukka Rahkonen- -----Alkuper?inen viesti----- L?hett?j?: mapserver-users-bounces at lists.osgeo.org [mailto:mapserver-users-bounces at lists.osgeo.org] Puolesta Raffaele Morelli L?hetetty: 4. elokuuta 2015 12:29 Vastaanottaja: mapserver-users at lists.osgeo.org Aihe: Re: [mapserver-users] html legend not working On 04/08/15 at 08:34am, Rahkonen Jukka (MML) wrote: > Raffaele Morelli wrote: > > > > Reply to myself because I've found it's not a mapserver related issue but a geomoose one (no matter about LEGEND and TEMPLATE statements it always produces a png image) . > > I don't quite agree. If GeoMoose is always making the GetLegendGraphic request by using image/png as a format then it is naturally getting a png image back. But so far I have not discovered how to make Mapserver to support html as one of the supported WMS GetLegendGraphic formats and what the WMS client should then use as a format in &format= parameter so there is also a Mapserver related aspect. I won't say that, doc is very clear about WMS request returning an image: [quote] GetLegendGraphic: returns a legend image (icon) for the requested layer, with label(s). More information on this request can be found in the GetLegendGraphic section later in this doc. GetLegendGraphic Request This request returns a legend image (icon) for the specified layer. The request will draw an icon and a label for all classes defined on the layer. If the requested layername is a GROUP-name, all included layers will be returned in the legend-icon. [/quote] GeoMoose is doing a WMS request so no error on Mapserver side (and after all) nor on the GeoMoose one. TEMPLATE statement works well (returning html legend) when doin a cgi request. /raffaele -- ?My mama said to get things done You'd better not mess with Major Tom? _______________________________________________ mapserver-users mailing list mapserver-users at lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users From yves.jacolin at camptocamp.com Tue Aug 4 06:12:15 2015 From: yves.jacolin at camptocamp.com (Yves Jacolin) Date: Tue, 04 Aug 2015 15:12:15 +0200 Subject: [mapserver-users] Mapserver wms and Openlayers 3 In-Reply-To: <1437766012001-5216956.post@n6.nabble.com> References: <1437766012001-5216956.post@n6.nabble.com> Message-ID: <3279999.G0pblvEVcC@tatras> Jordan, Your problem come from probably to a wrong configuration in your ol3 code. If you can see your WMS working in QGIS you should see the layer in ol3. If notn that's meant that your javascript code is incorrect. Can you show your javascript code? Could you check the request sent by your client to MapServer using Firebug (http://getfirebug.com) and check if the url is working in your navigator? check the url if it doesnt work and try to understand where the misconfiguration come from. Y. On Friday, July 24, 2015 12:26:52 jordan wrote: > Hope you can guide me in this issue I have. My aim is to connect to a > Postgis database from Openlayers 3 using Mapserver WMS. > > Apparently all is set up in my mapfile for WMS service(postgres connection > inside). I have tested and validated the getmap request, no errors found. > > Here is my URL: > http://localhost/cgi-bin/mapserv.exe?map=C:/ms4w/Apache/htdocs/maquetado/map > files/demo3.map&SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&LAYERS=agave_01_gcs > ,agave_02_gcs&STYLES=&SRS=EPSG:4326&BBOX=-103.809,20.8419,-103.716,20.8878&W > IDTH=105&HEIGHT=22&FORMAT=image/png > > After that I change the path inside the "http.conf" file as follows: > SetEnv myMap "C:/ms4w/Apache/htdocs/maquetado/mapfiles/demo3.map" > > Here is my final URL: http://localhost/cgi-bin/mapserv.exe?map=myMap > > I have tested it in GIS clients as a QGIS and ArcGIS and all is ok but when > I try to use it in OL3 no layers are shown. > > I think that probably something is wrong with my WMS url that OL3 can not > read.. > So it is possible to change the "mapserv.exe" in my URL specifically omit > the "exe" ?? > > I need something like this: http://localhost/cgi-bin/mapserv?map=myMap > > Best regards > Jordan > > > > > > > > > > -- > View this message in context: > http://osgeo-org.1560.x6.nabble.com/Mapserver-wms-and-Openlayers-3-tp521695 > 6.html Sent from the Mapserver - User mailing list archive at Nabble.com. > _______________________________________________ > mapserver-users mailing list > mapserver-users at lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/mapserver-users -- Responsable Formation et Support Camptocamp France SAS Savoie Technolac, BP 352 73377 Le Bourget du Lac, Cedex Tel (France) : +33 4 58 48 20 43 (new !) Tel (Suisse) : +41 21 619 10 43 Mob. : +33 6 18 75 42 21 Fax : 04 79 70 15 81 Mail : yves.jacolin at camptocamp.com http://www.camptocamp.com From even.rouault at spatialys.com Tue Aug 4 07:01:31 2015 From: even.rouault at spatialys.com (Even Rouault) Date: Tue, 04 Aug 2015 16:01:31 +0200 Subject: [mapserver-users] processing scale=auto with float multibands rasters In-Reply-To: References: Message-ID: <2517346.DpaaPlVSEC@even-n550jk> On Monday 03 August 2015 11:02:43 Andrea Peri wrote: > Hi, > I have a geotiff multibands with float64 values to serve with a wms > mapserver service. > > With this kind of rasters, > is affordable the directive > > PROCESSING "BANDS=4,3,2" > PROCESSING "SCALE=AUTO" > > (the 4,3,2 are the red,green,blue channels) > > Infact it seem do nothing. > > Instead all work well if I set: > > PROCESSING "BANDS=4,3,2" > PROCESSING "SCALE_1=0.01,0.2" > PROCESSING "SCALE_2=0.01,0.2" > PROCESSING "SCALE_3=0.01,0.2" > > where ii use the min=0.01 and max=0.2 > But I like to have the exact values of min/max for every raster. Andrea, SCALE=AUTO should work but looking at the actual implementation I can see it computes the min/max on the pixel values intersecting the requested area, and not on the whole raster as I'd have expected. So in a tiling context, it will likely not produce the expected result. Even -- Spatialys - Geospatial professional services http://www.spatialys.com From aperi2007 at gmail.com Tue Aug 4 10:07:04 2015 From: aperi2007 at gmail.com (Andrea Peri) Date: Tue, 4 Aug 2015 19:07:04 +0200 Subject: [mapserver-users] processing scale=auto with float multibands rasters In-Reply-To: <2517346.DpaaPlVSEC@even-n550jk> References: <2517346.DpaaPlVSEC@even-n550jk> Message-ID: Hi Even, thx for response. Please can you help me to better understand the question ? My raster is effectively a 18000 x 24000 px image with tiles. it have a tile size of 1024 x 1024 produced from gdalwarp: gdalwarp -s_srs EPSG:32632 -t_srs EPSG:32632 -overwrite --config GDAL_CACHEMAX 1000 -wm 1000 -co TILED=YES -co COMPRESS=NONE -co BLOCKXSIZE=1024 -co BLOCKYSIZE=1024 -co BIGTIFF=YES -co SPARSE_OK=TRUE ....... and also have overviews from gdaladdo --config GDAL_CACHEMAX 1500 -ro -r average ..... 2 4 8 16 32 64 128 256 512 1024 If I understand correctly your info. The mapserver could search the min/max using only the first tile ? This mean that it more probably found always only 0 values or near 0 values beacuse these could be the values in the first tile. And so it return a white image because the min/max is always min=0/ max=0 (or something quite like this) I understand correct ? thx, A. 2015-08-04 16:01 GMT+02:00 Even Rouault : > On Monday 03 August 2015 11:02:43 Andrea Peri wrote: >> Hi, >> I have a geotiff multibands with float64 values to serve with a wms >> mapserver service. >> >> With this kind of rasters, >> is affordable the directive >> >> PROCESSING "BANDS=4,3,2" >> PROCESSING "SCALE=AUTO" >> >> (the 4,3,2 are the red,green,blue channels) >> >> Infact it seem do nothing. >> >> Instead all work well if I set: >> >> PROCESSING "BANDS=4,3,2" >> PROCESSING "SCALE_1=0.01,0.2" >> PROCESSING "SCALE_2=0.01,0.2" >> PROCESSING "SCALE_3=0.01,0.2" >> >> where ii use the min=0.01 and max=0.2 >> But I like to have the exact values of min/max for every raster. > > Andrea, > > SCALE=AUTO should work but looking at the actual implementation I can see it > computes the min/max on the pixel values intersecting the requested area, and > not on the whole raster as I'd have expected. So in a tiling context, it will > likely not produce the expected result. > > Even > > -- > Spatialys - Geospatial professional services > http://www.spatialys.com -- ----------------- Andrea Peri . . . . . . . . . qwerty ????? ----------------- From jukka.rahkonen at maanmittauslaitos.fi Tue Aug 4 10:50:18 2015 From: jukka.rahkonen at maanmittauslaitos.fi (Rahkonen Jukka (MML)) Date: Tue, 4 Aug 2015 17:50:18 +0000 Subject: [mapserver-users] processing scale=auto with float multibands rasters Message-ID: Hi, I suppose that Even means that with AUTO setting Mapserver is analyzing the min/max pixel values from inside the BBOX of each GetMap and then scales pixel values to 0-256 for the output. One totally black or white pixel within the BBOX can make the result from 64bit source very bad. I would try to use LUT instead of SCALE http://www.mapserver.org/input/raster.html#special-processing-directives. -Jukka Rahkonen- -----Alkuper?inen viesti-----l L?hett?j?: mapserver-users-bounces at lists.osgeo.org [mailto:mapserver-users-bounces at lists.osgeo.org] Puolesta Andrea Peri L?hetetty: 4. elokuuta 2015 20:07 Vastaanottaja: Even Rouault Kopio: mapserver-users at lists.osgeo.org Aihe: Re: [mapserver-users] processing scale=auto with float multibands rasters Hi Even, thx for response. Please can you help me to better understand the question ? My raster is effectively a 18000 x 24000 px image with tiles. it have a tile size of 1024 x 1024 produced from gdalwarp: gdalwarp -s_srs EPSG:32632 -t_srs EPSG:32632 -overwrite --config GDAL_CACHEMAX 1000 -wm 1000 -co TILED=YES -co COMPRESS=NONE -co BLOCKXSIZE=1024 -co BLOCKYSIZE=1024 -co BIGTIFF=YES -co SPARSE_OK=TRUE ....... and also have overviews from gdaladdo --config GDAL_CACHEMAX 1500 -ro -r average ..... 2 4 8 16 32 64 128 256 512 1024 If I understand correctly your info. The mapserver could search the min/max using only the first tile ? This mean that it more probably found always only 0 values or near 0 values beacuse these could be the values in the first tile. And so it return a white image because the min/max is always min=0/ max=0 (or something quite like this) I understand correct ? thx, A. 2015-08-04 16:01 GMT+02:00 Even Rouault : > On Monday 03 August 2015 11:02:43 Andrea Peri wrote: >> Hi, >> I have a geotiff multibands with float64 values to serve with a wms >> mapserver service. >> >> With this kind of rasters, >> is affordable the directive >> >> PROCESSING "BANDS=4,3,2" >> PROCESSING "SCALE=AUTO" >> >> (the 4,3,2 are the red,green,blue channels) >> >> Infact it seem do nothing. >> >> Instead all work well if I set: >> >> PROCESSING "BANDS=4,3,2" >> PROCESSING "SCALE_1=0.01,0.2" >> PROCESSING "SCALE_2=0.01,0.2" >> PROCESSING "SCALE_3=0.01,0.2" >> >> where ii use the min=0.01 and max=0.2 But I like to have the exact >> values of min/max for every raster. > > Andrea, > > SCALE=AUTO should work but looking at the actual implementation I can > see it computes the min/max on the pixel values intersecting the > requested area, and not on the whole raster as I'd have expected. So > in a tiling context, it will likely not produce the expected result. > > Even > > -- > Spatialys - Geospatial professional services http://www.spatialys.com -- ----------------- Andrea Peri . . . . . . . . . qwerty ????? ----------------- _______________________________________________ mapserver-users mailing list mapserver-users at lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users From aperi2007 at gmail.com Tue Aug 4 11:14:58 2015 From: aperi2007 at gmail.com (Andrea Peri) Date: Tue, 4 Aug 2015 20:14:58 +0200 Subject: [mapserver-users] processing scale=auto with float multibands rasters In-Reply-To: References: Message-ID: HI Jukka, unfortunatelly, I cannot use the LUT because the raster I use is update weekly and every week it could change the min/max values for every bands (it has 11 bands). Hovewer if it work using the min/max from get map , probably it could be ok form me. The question s that even when the getmap request the entire bbox the image reported seem to be empty without no error log. 2015-08-04 19:50 GMT+02:00 Rahkonen Jukka (MML) : > Hi, > > I suppose that Even means that with AUTO setting Mapserver is analyzing the min/max pixel values from inside the BBOX of each GetMap and then scales pixel values to 0-256 for the output. One totally black or white pixel within the BBOX can make the result from 64bit source very bad. > > I would try to use LUT instead of SCALE http://www.mapserver.org/input/raster.html#special-processing-directives. > > -Jukka Rahkonen- > > > > > -----Alkuper?inen viesti-----l > L?hett?j?: mapserver-users-bounces at lists.osgeo.org [mailto:mapserver-users-bounces at lists.osgeo.org] Puolesta Andrea Peri > L?hetetty: 4. elokuuta 2015 20:07 > Vastaanottaja: Even Rouault > Kopio: mapserver-users at lists.osgeo.org > Aihe: Re: [mapserver-users] processing scale=auto with float multibands rasters > > Hi Even, > > thx for response. > > Please can you help me to better understand the question ? > > My raster is effectively a 18000 x 24000 px image with tiles. > > it have a tile size of 1024 x 1024 produced from gdalwarp: > > gdalwarp -s_srs EPSG:32632 -t_srs EPSG:32632 -overwrite --config GDAL_CACHEMAX 1000 -wm 1000 -co TILED=YES -co COMPRESS=NONE -co > BLOCKXSIZE=1024 -co BLOCKYSIZE=1024 -co BIGTIFF=YES -co SPARSE_OK=TRUE ....... > > and also have overviews from > > gdaladdo --config GDAL_CACHEMAX 1500 -ro -r average ..... 2 4 8 16 32 > 64 128 256 512 1024 > > If I understand correctly your info. > The mapserver could search the min/max using only the first tile ? > > This mean that it more probably found always only 0 values or near 0 values beacuse these could be the values in the first tile. > > And so it return a white image because the min/max is always min=0/ > max=0 (or something quite like this) > I understand correct ? > > thx, > > A. > > > 2015-08-04 16:01 GMT+02:00 Even Rouault : >> On Monday 03 August 2015 11:02:43 Andrea Peri wrote: >>> Hi, >>> I have a geotiff multibands with float64 values to serve with a wms >>> mapserver service. >>> >>> With this kind of rasters, >>> is affordable the directive >>> >>> PROCESSING "BANDS=4,3,2" >>> PROCESSING "SCALE=AUTO" >>> >>> (the 4,3,2 are the red,green,blue channels) >>> >>> Infact it seem do nothing. >>> >>> Instead all work well if I set: >>> >>> PROCESSING "BANDS=4,3,2" >>> PROCESSING "SCALE_1=0.01,0.2" >>> PROCESSING "SCALE_2=0.01,0.2" >>> PROCESSING "SCALE_3=0.01,0.2" >>> >>> where ii use the min=0.01 and max=0.2 But I like to have the exact >>> values of min/max for every raster. >> >> Andrea, >> >> SCALE=AUTO should work but looking at the actual implementation I can >> see it computes the min/max on the pixel values intersecting the >> requested area, and not on the whole raster as I'd have expected. So >> in a tiling context, it will likely not produce the expected result. >> >> Even >> >> -- >> Spatialys - Geospatial professional services http://www.spatialys.com > > > > -- > ----------------- > Andrea Peri > . . . . . . . . . > qwerty ????? > ----------------- > _______________________________________________ > mapserver-users mailing list > mapserver-users at lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/mapserver-users -- ----------------- Andrea Peri . . . . . . . . . qwerty ????? ----------------- From jukka.rahkonen at maanmittauslaitos.fi Tue Aug 4 11:29:25 2015 From: jukka.rahkonen at maanmittauslaitos.fi (Rahkonen Jukka (MML)) Date: Tue, 4 Aug 2015 18:29:25 +0000 Subject: [mapserver-users] processing scale=auto with float multibands rasters Message-ID: <7f7cbbb2e0bd4dbeaadadc33cb46e086@C119S212VM022.msvyvi.vaha.local> Hi Andrea, For viewing purposes it is rather common to do LUT stretch by standard deviation which is not so sensible as min-max stretch. Consider making a feature request for a new enhanced PROCESSING AUTO directive which would do the STD stretch, possibly with an optional multiplication. 2 x STD might be a good default value. -Jukka Rahkonen- Andrea Peri wrote: > HI Jukka, > unfortunatelly, I cannot use the LUT because the raster I use is update weekly and every week it could change the min/max values for every bands (it has 11 bands). > Hovewer if it work using the min/max from get map , probably it could be ok form me. > The question s that even when the getmap request the entire bbox the image reported seem to be empty without no error log. 2015-08-04 19:50 GMT+02:00 Rahkonen Jukka (MML) : > Hi, > > I suppose that Even means that with AUTO setting Mapserver is analyzing the min/max pixel values from inside the BBOX of each GetMap and then scales pixel values to 0-256 for the output. One totally black or white pixel within the BBOX can make the result from 64bit source very bad. > > I would try to use LUT instead of SCALE http://www.mapserver.org/input/raster.html#special-processing-directives. > > -Jukka Rahkonen- > > > > > -----Alkuper?inen viesti-----l > L?hett?j?: mapserver-users-bounces at lists.osgeo.org > [mailto:mapserver-users-bounces at lists.osgeo.org] Puolesta Andrea Peri > L?hetetty: 4. elokuuta 2015 20:07 > Vastaanottaja: Even Rouault > Kopio: mapserver-users at lists.osgeo.org > Aihe: Re: [mapserver-users] processing scale=auto with float > multibands rasters > > Hi Even, > > thx for response. > > Please can you help me to better understand the question ? > > My raster is effectively a 18000 x 24000 px image with tiles. > > it have a tile size of 1024 x 1024 produced from gdalwarp: > > gdalwarp -s_srs EPSG:32632 -t_srs EPSG:32632 -overwrite --config > GDAL_CACHEMAX 1000 -wm 1000 -co TILED=YES -co COMPRESS=NONE -co > BLOCKXSIZE=1024 -co BLOCKYSIZE=1024 -co BIGTIFF=YES -co SPARSE_OK=TRUE ....... > > and also have overviews from > > gdaladdo --config GDAL_CACHEMAX 1500 -ro -r average ..... 2 4 8 16 32 > 64 128 256 512 1024 > > If I understand correctly your info. > The mapserver could search the min/max using only the first tile ? > > This mean that it more probably found always only 0 values or near 0 values beacuse these could be the values in the first tile. > > And so it return a white image because the min/max is always min=0/ > max=0 (or something quite like this) > I understand correct ? > > thx, > > A. > > > 2015-08-04 16:01 GMT+02:00 Even Rouault : >> On Monday 03 August 2015 11:02:43 Andrea Peri wrote: >>> Hi, >>> I have a geotiff multibands with float64 values to serve with a wms >>> mapserver service. >>> >>> With this kind of rasters, >>> is affordable the directive >>> >>> PROCESSING "BANDS=4,3,2" >>> PROCESSING "SCALE=AUTO" >>> >>> (the 4,3,2 are the red,green,blue channels) >>> >>> Infact it seem do nothing. >>> >>> Instead all work well if I set: >>> >>> PROCESSING "BANDS=4,3,2" >>> PROCESSING "SCALE_1=0.01,0.2" >>> PROCESSING "SCALE_2=0.01,0.2" >>> PROCESSING "SCALE_3=0.01,0.2" >>> >>> where ii use the min=0.01 and max=0.2 But I like to have the exact >>> values of min/max for every raster. >> >> Andrea, >> >> SCALE=AUTO should work but looking at the actual implementation I can >> see it computes the min/max on the pixel values intersecting the >> requested area, and not on the whole raster as I'd have expected. So >> in a tiling context, it will likely not produce the expected result. >> >> Even >> >> -- >> Spatialys - Geospatial professional services http://www.spatialys.com > > > > -- > ----------------- > Andrea Peri > . . . . . . . . . > qwerty ????? > ----------------- > _______________________________________________ > mapserver-users mailing list > mapserver-users at lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/mapserver-users -- ----------------- Andrea Peri . . . . . . . . . qwerty ????? ----------------- From aperi2007 at gmail.com Tue Aug 4 12:27:08 2015 From: aperi2007 at gmail.com (Andrea Peri) Date: Tue, 4 Aug 2015 21:27:08 +0200 Subject: [mapserver-users] processing scale=auto with float multibands rasters In-Reply-To: <7f7cbbb2e0bd4dbeaadadc33cb46e086@C119S212VM022.msvyvi.vaha.local> References: <7f7cbbb2e0bd4dbeaadadc33cb46e086@C119S212VM022.msvyvi.vaha.local> Message-ID: Hi Jukka, I could open a feature request for this, but before I need to understand if the results with this strategy are affordable for us. Infact I do some test with a domain min/max lesser than 2x and it results unaccepatable for our users. The raster are too poor contrasted as reported me from our users. So I'm not sure that an AUTO with a STD stretch and a multiplicator 2x could be instead an acceptable solution. I should do more tests... Thx. 2015-08-04 20:29 GMT+02:00 Rahkonen Jukka (MML) : > Hi Andrea, > > For viewing purposes it is rather common to do LUT stretch by standard deviation which is not so sensible as min-max stretch. Consider making a feature request for a new enhanced PROCESSING AUTO directive which would do the STD stretch, possibly with an optional multiplication. 2 x STD might be a good default value. > > -Jukka Rahkonen- > > Andrea Peri wrote: > >> HI Jukka, >> unfortunatelly, I cannot use the LUT because the raster I use is update weekly and every week it could change the min/max values for every bands (it has 11 bands). > >> Hovewer if it work using the min/max from get map , probably it could be ok form me. >> The question s that even when the getmap request the entire bbox the image reported seem to be empty without no error log. > > > > 2015-08-04 19:50 GMT+02:00 Rahkonen Jukka (MML) > : >> Hi, >> >> I suppose that Even means that with AUTO setting Mapserver is analyzing the min/max pixel values from inside the BBOX of each GetMap and then scales pixel values to 0-256 for the output. One totally black or white pixel within the BBOX can make the result from 64bit source very bad. >> >> I would try to use LUT instead of SCALE http://www.mapserver.org/input/raster.html#special-processing-directives. >> >> -Jukka Rahkonen- >> >> >> >> >> -----Alkuper?inen viesti-----l >> L?hett?j?: mapserver-users-bounces at lists.osgeo.org >> [mailto:mapserver-users-bounces at lists.osgeo.org] Puolesta Andrea Peri >> L?hetetty: 4. elokuuta 2015 20:07 >> Vastaanottaja: Even Rouault >> Kopio: mapserver-users at lists.osgeo.org >> Aihe: Re: [mapserver-users] processing scale=auto with float >> multibands rasters >> >> Hi Even, >> >> thx for response. >> >> Please can you help me to better understand the question ? >> >> My raster is effectively a 18000 x 24000 px image with tiles. >> >> it have a tile size of 1024 x 1024 produced from gdalwarp: >> >> gdalwarp -s_srs EPSG:32632 -t_srs EPSG:32632 -overwrite --config >> GDAL_CACHEMAX 1000 -wm 1000 -co TILED=YES -co COMPRESS=NONE -co >> BLOCKXSIZE=1024 -co BLOCKYSIZE=1024 -co BIGTIFF=YES -co SPARSE_OK=TRUE ....... >> >> and also have overviews from >> >> gdaladdo --config GDAL_CACHEMAX 1500 -ro -r average ..... 2 4 8 16 32 >> 64 128 256 512 1024 >> >> If I understand correctly your info. >> The mapserver could search the min/max using only the first tile ? >> >> This mean that it more probably found always only 0 values or near 0 values beacuse these could be the values in the first tile. >> >> And so it return a white image because the min/max is always min=0/ >> max=0 (or something quite like this) >> I understand correct ? >> >> thx, >> >> A. >> >> >> 2015-08-04 16:01 GMT+02:00 Even Rouault : >>> On Monday 03 August 2015 11:02:43 Andrea Peri wrote: >>>> Hi, >>>> I have a geotiff multibands with float64 values to serve with a wms >>>> mapserver service. >>>> >>>> With this kind of rasters, >>>> is affordable the directive >>>> >>>> PROCESSING "BANDS=4,3,2" >>>> PROCESSING "SCALE=AUTO" >>>> >>>> (the 4,3,2 are the red,green,blue channels) >>>> >>>> Infact it seem do nothing. >>>> >>>> Instead all work well if I set: >>>> >>>> PROCESSING "BANDS=4,3,2" >>>> PROCESSING "SCALE_1=0.01,0.2" >>>> PROCESSING "SCALE_2=0.01,0.2" >>>> PROCESSING "SCALE_3=0.01,0.2" >>>> >>>> where ii use the min=0.01 and max=0.2 But I like to have the exact >>>> values of min/max for every raster. >>> >>> Andrea, >>> >>> SCALE=AUTO should work but looking at the actual implementation I can >>> see it computes the min/max on the pixel values intersecting the >>> requested area, and not on the whole raster as I'd have expected. So >>> in a tiling context, it will likely not produce the expected result. >>> >>> Even >>> >>> -- >>> Spatialys - Geospatial professional services http://www.spatialys.com >> >> >> >> -- >> ----------------- >> Andrea Peri >> . . . . . . . . . >> qwerty ????? >> ----------------- >> _______________________________________________ >> mapserver-users mailing list >> mapserver-users at lists.osgeo.org >> http://lists.osgeo.org/mailman/listinfo/mapserver-users > > > > -- > ----------------- > Andrea Peri > . . . . . . . . . > qwerty ????? > ----------------- -- ----------------- Andrea Peri . . . . . . . . . qwerty ????? ----------------- From jukka.rahkonen at maanmittauslaitos.fi Tue Aug 4 13:52:53 2015 From: jukka.rahkonen at maanmittauslaitos.fi (Rahkonen Jukka (MML)) Date: Tue, 4 Aug 2015 20:52:53 +0000 Subject: [mapserver-users] processing scale=auto with float multibands rasters Message-ID: <0ecfddd8b12b472890ff08cabb2c5e35@C119S212VM022.msvyvi.vaha.local> Hi, Do we talk about the same thing? If gdalinfo -stats shows Minimum=2.000, Maximum=255.000, Mean=96.297, StdDev=37.015 you should put min at 96.297-(2*37.015) You can test the effect with QGIS as described here http://gis.stackexchange.com/questions/87914/how-to-perform-a-standard-deviation-stretch-on-a-raster-in-qgis However, I have not really used 64-bit images and don't know what kind of histograms they usually have. In Mapserver 2.0 the PROCESSING stuff should be possible to set via variable substitution and your users could make the adjustment on-the-fly. Perhaps they could accept that? -Jukka- Andrea Peri wrote: > Hi Jukka, I could open a feature request for this, but before I need to understand if the results with this strategy are affordable for us. > Infact I do some test with a domain min/max lesser than 2x and it results unaccepatable for our users. The raster are too poor contrasted as reported me from our users. > So I'm not sure that an AUTO with a STD stretch and a multiplicator 2x could be instead an acceptable solution. I should do more tests... Thx. 2015-08-04 20:29 GMT+02:00 Rahkonen Jukka (MML) : > Hi Andrea, > > For viewing purposes it is rather common to do LUT stretch by standard deviation which is not so sensible as min-max stretch. Consider making a feature request for a new enhanced PROCESSING AUTO directive which would do the STD stretch, possibly with an optional multiplication. 2 x STD might be a good default value. > > -Jukka Rahkonen- > > Andrea Peri wrote: > >> HI Jukka, >> unfortunatelly, I cannot use the LUT because the raster I use is update weekly and every week it could change the min/max values for every bands (it has 11 bands). > >> Hovewer if it work using the min/max from get map , probably it could be ok form me. >> The question s that even when the getmap request the entire bbox the image reported seem to be empty without no error log. > > > > 2015-08-04 19:50 GMT+02:00 Rahkonen Jukka (MML) > : >> Hi, >> >> I suppose that Even means that with AUTO setting Mapserver is analyzing the min/max pixel values from inside the BBOX of each GetMap and then scales pixel values to 0-256 for the output. One totally black or white pixel within the BBOX can make the result from 64bit source very bad. >> >> I would try to use LUT instead of SCALE http://www.mapserver.org/input/raster.html#special-processing-directives. >> >> -Jukka Rahkonen- >> >> >> >> >> -----Alkuper?inen viesti-----l >> L?hett?j?: mapserver-users-bounces at lists.osgeo.org >> [mailto:mapserver-users-bounces at lists.osgeo.org] Puolesta Andrea Peri >> L?hetetty: 4. elokuuta 2015 20:07 >> Vastaanottaja: Even Rouault >> Kopio: mapserver-users at lists.osgeo.org >> Aihe: Re: [mapserver-users] processing scale=auto with float >> multibands rasters >> >> Hi Even, >> >> thx for response. >> >> Please can you help me to better understand the question ? >> >> My raster is effectively a 18000 x 24000 px image with tiles. >> >> it have a tile size of 1024 x 1024 produced from gdalwarp: >> >> gdalwarp -s_srs EPSG:32632 -t_srs EPSG:32632 -overwrite --config >> GDAL_CACHEMAX 1000 -wm 1000 -co TILED=YES -co COMPRESS=NONE -co >> BLOCKXSIZE=1024 -co BLOCKYSIZE=1024 -co BIGTIFF=YES -co SPARSE_OK=TRUE ....... >> >> and also have overviews from >> >> gdaladdo --config GDAL_CACHEMAX 1500 -ro -r average ..... 2 4 8 16 32 >> 64 128 256 512 1024 >> >> If I understand correctly your info. >> The mapserver could search the min/max using only the first tile ? >> >> This mean that it more probably found always only 0 values or near 0 values beacuse these could be the values in the first tile. >> >> And so it return a white image because the min/max is always min=0/ >> max=0 (or something quite like this) >> I understand correct ? >> >> thx, >> >> A. >> >> >> 2015-08-04 16:01 GMT+02:00 Even Rouault : >>> On Monday 03 August 2015 11:02:43 Andrea Peri wrote: >>>> Hi, >>>> I have a geotiff multibands with float64 values to serve with a wms >>>> mapserver service. >>>> >>>> With this kind of rasters, >>>> is affordable the directive >>>> >>>> PROCESSING "BANDS=4,3,2" >>>> PROCESSING "SCALE=AUTO" >>>> >>>> (the 4,3,2 are the red,green,blue channels) >>>> >>>> Infact it seem do nothing. >>>> >>>> Instead all work well if I set: >>>> >>>> PROCESSING "BANDS=4,3,2" >>>> PROCESSING "SCALE_1=0.01,0.2" >>>> PROCESSING "SCALE_2=0.01,0.2" >>>> PROCESSING "SCALE_3=0.01,0.2" >>>> >>>> where ii use the min=0.01 and max=0.2 But I like to have the exact >>>> values of min/max for every raster. >>> >>> Andrea, >>> >>> SCALE=AUTO should work but looking at the actual implementation I >>> can see it computes the min/max on the pixel values intersecting the >>> requested area, and not on the whole raster as I'd have expected. So >>> in a tiling context, it will likely not produce the expected result. >>> >>> Even >>> >>> -- >>> Spatialys - Geospatial professional services >>> http://www.spatialys.com >> >> >> >> -- >> ----------------- >> Andrea Peri >> . . . . . . . . . >> qwerty ????? >> ----------------- >> _______________________________________________ >> mapserver-users mailing list >> mapserver-users at lists.osgeo.org >> http://lists.osgeo.org/mailman/listinfo/mapserver-users > > > > -- > ----------------- > Andrea Peri > . . . . . . . . . > qwerty ????? > ----------------- -- ----------------- Andrea Peri . . . . . . . . . qwerty ????? ----------------- From aperi2007 at gmail.com Tue Aug 4 14:43:59 2015 From: aperi2007 at gmail.com (Andrea Peri) Date: Tue, 4 Aug 2015 23:43:59 +0200 Subject: [mapserver-users] processing scale=auto with float multibands rasters In-Reply-To: <0ecfddd8b12b472890ff08cabb2c5e35@C119S212VM022.msvyvi.vaha.local> References: <0ecfddd8b12b472890ff08cabb2c5e35@C119S212VM022.msvyvi.vaha.local> Message-ID: Hi Jukka, The value I use for test was retrieve using qgis defaults so I don't know if your formula was the same. So I do a quick test these are the values for my test raster: Band 1 Minimum=0.038, Maximum=1.584, Mean=0.135, StdDev=0.026 Band 2 Minimum=0.004, Maximum=1.567, Mean=0.115, StdDev=0.027 Band 3 Minimum=0.003, Maximum=1.636, Mean=0.096, StdDev=0.031 Band 4 Minimum=-0.016, Maximum=1.796, Mean=0.082, StdDev=0.042 Band 5 Minimum=-0.311, Maximum=4.486, Mean=0.256, StdDev=0.138 Band 6 Minimum=-0.197, Maximum=3.277, Mean=0.161, StdDev=0.098 Band 7 Minimum=-0.118, Maximum=2.295, Mean=0.088, StdDev=0.063 Band 8 Minimum=0.039, Maximum=1.366, Mean=0.090, StdDev=0.035 Band 9 Minimum=-0.039, Maximum=0.413, Mean=0.003, StdDev=0.010 Band 10 Minimum=240.580, Maximum=524.602, Mean=299.351, StdDev=6.342 Band 11 Minimum=249.037, Maximum=514.462, Mean=297.375, StdDev=5.855 Using you formula: (I hope to understand it correctly) PROCESSING "BANDS=4,3,2" (the red,green,blue channels) the values should be: Band 4: 0.082 - (-0.016 * 0.042) = 0.082672 0.082 + (1.796 * 0.042) = 0.157432 Band 3: 0.096 - (0.003 * 0.031) = 0.095907 0.096 + (1.636 * 0.031) = 0.146716 Band 2: 0.115 - (0.004 * 0.027) = 0.114892 0.115 + (1.567 * 0.027) = 0.157309 so the setting should be: PROCESSING "SCALE_1= 0.082672 , 0.157432" PROCESSING "SCALE_2= 0.095907 , 0.146716" PROCESSING "SCALE_3= 0.114892 , 0.157309" With this values the image is not correct . I add a link to a sample images of what the mapserver will produce with these values. https://www.dropbox.com/s/izleegjbp18j81f/sample-mapserver-with-values.gif?dl=0 A. 2015-08-04 22:52 GMT+02:00 Rahkonen Jukka (MML) : > Hi, > > Do we talk about the same thing? If gdalinfo -stats shows > Minimum=2.000, Maximum=255.000, Mean=96.297, StdDev=37.015 > you should put min at 96.297-(2*37.015) > You can test the effect with QGIS as described here http://gis.stackexchange.com/questions/87914/how-to-perform-a-standard-deviation-stretch-on-a-raster-in-qgis > However, I have not really used 64-bit images and don't know what kind of histograms they usually have. > > In Mapserver 2.0 the PROCESSING stuff should be possible to set via variable substitution and your users could make the adjustment on-the-fly. Perhaps they could accept that? > > -Jukka- > > Andrea Peri wrote: > >> Hi Jukka, I could open a feature request for this, but before I need to understand if the results with this strategy are affordable for us. > >> Infact I do some test with a domain min/max lesser than 2x and it results unaccepatable for our users. The raster are too poor contrasted as reported me from our users. >> So I'm not sure that an AUTO with a STD stretch and a multiplicator 2x could be instead an acceptable solution. > > I should do more tests... > > Thx. > > > > 2015-08-04 20:29 GMT+02:00 Rahkonen Jukka (MML) > : >> Hi Andrea, >> >> For viewing purposes it is rather common to do LUT stretch by standard deviation which is not so sensible as min-max stretch. Consider making a feature request for a new enhanced PROCESSING AUTO directive which would do the STD stretch, possibly with an optional multiplication. 2 x STD might be a good default value. >> >> -Jukka Rahkonen- >> >> Andrea Peri wrote: >> >>> HI Jukka, >>> unfortunatelly, I cannot use the LUT because the raster I use is update weekly and every week it could change the min/max values for every bands (it has 11 bands). >> >>> Hovewer if it work using the min/max from get map , probably it could be ok form me. >>> The question s that even when the getmap request the entire bbox the image reported seem to be empty without no error log. >> >> >> >> 2015-08-04 19:50 GMT+02:00 Rahkonen Jukka (MML) >> : >>> Hi, >>> >>> I suppose that Even means that with AUTO setting Mapserver is analyzing the min/max pixel values from inside the BBOX of each GetMap and then scales pixel values to 0-256 for the output. One totally black or white pixel within the BBOX can make the result from 64bit source very bad. >>> >>> I would try to use LUT instead of SCALE http://www.mapserver.org/input/raster.html#special-processing-directives. >>> >>> -Jukka Rahkonen- >>> >>> >>> >>> >>> -----Alkuper?inen viesti-----l >>> L?hett?j?: mapserver-users-bounces at lists.osgeo.org >>> [mailto:mapserver-users-bounces at lists.osgeo.org] Puolesta Andrea Peri >>> L?hetetty: 4. elokuuta 2015 20:07 >>> Vastaanottaja: Even Rouault >>> Kopio: mapserver-users at lists.osgeo.org >>> Aihe: Re: [mapserver-users] processing scale=auto with float >>> multibands rasters >>> >>> Hi Even, >>> >>> thx for response. >>> >>> Please can you help me to better understand the question ? >>> >>> My raster is effectively a 18000 x 24000 px image with tiles. >>> >>> it have a tile size of 1024 x 1024 produced from gdalwarp: >>> >>> gdalwarp -s_srs EPSG:32632 -t_srs EPSG:32632 -overwrite --config >>> GDAL_CACHEMAX 1000 -wm 1000 -co TILED=YES -co COMPRESS=NONE -co >>> BLOCKXSIZE=1024 -co BLOCKYSIZE=1024 -co BIGTIFF=YES -co SPARSE_OK=TRUE ....... >>> >>> and also have overviews from >>> >>> gdaladdo --config GDAL_CACHEMAX 1500 -ro -r average ..... 2 4 8 16 32 >>> 64 128 256 512 1024 >>> >>> If I understand correctly your info. >>> The mapserver could search the min/max using only the first tile ? >>> >>> This mean that it more probably found always only 0 values or near 0 values beacuse these could be the values in the first tile. >>> >>> And so it return a white image because the min/max is always min=0/ >>> max=0 (or something quite like this) >>> I understand correct ? >>> >>> thx, >>> >>> A. >>> >>> >>> 2015-08-04 16:01 GMT+02:00 Even Rouault : >>>> On Monday 03 August 2015 11:02:43 Andrea Peri wrote: >>>>> Hi, >>>>> I have a geotiff multibands with float64 values to serve with a wms >>>>> mapserver service. >>>>> >>>>> With this kind of rasters, >>>>> is affordable the directive >>>>> >>>>> PROCESSING "BANDS=4,3,2" >>>>> PROCESSING "SCALE=AUTO" >>>>> >>>>> (the 4,3,2 are the red,green,blue channels) >>>>> >>>>> Infact it seem do nothing. >>>>> >>>>> Instead all work well if I set: >>>>> >>>>> PROCESSING "BANDS=4,3,2" >>>>> PROCESSING "SCALE_1=0.01,0.2" >>>>> PROCESSING "SCALE_2=0.01,0.2" >>>>> PROCESSING "SCALE_3=0.01,0.2" >>>>> >>>>> where ii use the min=0.01 and max=0.2 But I like to have the exact >>>>> values of min/max for every raster. >>>> >>>> Andrea, >>>> >>>> SCALE=AUTO should work but looking at the actual implementation I >>>> can see it computes the min/max on the pixel values intersecting the >>>> requested area, and not on the whole raster as I'd have expected. So >>>> in a tiling context, it will likely not produce the expected result. >>>> >>>> Even >>>> >>>> -- >>>> Spatialys - Geospatial professional services >>>> http://www.spatialys.com >>> >>> >>> >>> -- >>> ----------------- >>> Andrea Peri >>> . . . . . . . . . >>> qwerty ????? >>> ----------------- >>> _______________________________________________ >>> mapserver-users mailing list >>> mapserver-users at lists.osgeo.org >>> http://lists.osgeo.org/mailman/listinfo/mapserver-users >> >> >> >> -- >> ----------------- >> Andrea Peri >> . . . . . . . . . >> qwerty ????? >> ----------------- > > > > -- > ----------------- > Andrea Peri > . . . . . . . . . > qwerty ????? > ----------------- -- ----------------- Andrea Peri . . . . . . . . . qwerty ????? ----------------- From klassen.js at gmail.com Tue Aug 4 19:47:53 2015 From: klassen.js at gmail.com (Jim Klassen) Date: Tue, 04 Aug 2015 21:47:53 -0500 Subject: [mapserver-users] processing scale=auto with float multibands rasters In-Reply-To: References: <0ecfddd8b12b472890ff08cabb2c5e35@C119S212VM022.msvyvi.vaha.local> Message-ID: <55C17959.2010202@gmail.com> Generally the formula for this is: Mean +/- (userSelectedScaleFactor * StdDev) So Band 4 (with userSelectedScaleFactor = 2) would be: min = 0.082 - (2 * 0.042) = -0.002 max = 0.082 + (2 * 0.042) = 0.166 On 08/04/2015 04:43 PM, Andrea Peri wrote: > Hi Jukka, > > The value I use for test was retrieve using qgis defaults so I don't > know if your formula was the same. > > So I do a quick test > these are the values for my test raster: > > Band 1 Minimum=0.038, Maximum=1.584, Mean=0.135, StdDev=0.026 > Band 2 Minimum=0.004, Maximum=1.567, Mean=0.115, StdDev=0.027 > Band 3 Minimum=0.003, Maximum=1.636, Mean=0.096, StdDev=0.031 > Band 4 Minimum=-0.016, Maximum=1.796, Mean=0.082, StdDev=0.042 > Band 5 Minimum=-0.311, Maximum=4.486, Mean=0.256, StdDev=0.138 > Band 6 Minimum=-0.197, Maximum=3.277, Mean=0.161, StdDev=0.098 > Band 7 Minimum=-0.118, Maximum=2.295, Mean=0.088, StdDev=0.063 > Band 8 Minimum=0.039, Maximum=1.366, Mean=0.090, StdDev=0.035 > Band 9 Minimum=-0.039, Maximum=0.413, Mean=0.003, StdDev=0.010 > Band 10 Minimum=240.580, Maximum=524.602, Mean=299.351, StdDev=6.342 > Band 11 Minimum=249.037, Maximum=514.462, Mean=297.375, StdDev=5.855 > > Using you formula: > (I hope to understand it correctly) > > PROCESSING "BANDS=4,3,2" (the red,green,blue channels) > > the values should be: > > Band 4: > 0.082 - (-0.016 * 0.042) = 0.082672 > 0.082 + (1.796 * 0.042) = 0.157432 > > Band 3: > 0.096 - (0.003 * 0.031) = 0.095907 > 0.096 + (1.636 * 0.031) = 0.146716 > > Band 2: > 0.115 - (0.004 * 0.027) = 0.114892 > 0.115 + (1.567 * 0.027) = 0.157309 > > so the setting should be: > > PROCESSING "SCALE_1= 0.082672 , 0.157432" > PROCESSING "SCALE_2= 0.095907 , 0.146716" > PROCESSING "SCALE_3= 0.114892 , 0.157309" > > With this values the image is not correct . > > I add a link to a sample images of what the mapserver will produce > with these values. > > https://www.dropbox.com/s/izleegjbp18j81f/sample-mapserver-with-values.gif?dl=0 > > > A. > > 2015-08-04 22:52 GMT+02:00 Rahkonen Jukka (MML) > : >> Hi, >> >> Do we talk about the same thing? If gdalinfo -stats shows >> Minimum=2.000, Maximum=255.000, Mean=96.297, StdDev=37.015 >> you should put min at 96.297-(2*37.015) >> You can test the effect with QGIS as described here http://gis.stackexchange.com/questions/87914/how-to-perform-a-standard-deviation-stretch-on-a-raster-in-qgis >> However, I have not really used 64-bit images and don't know what kind of histograms they usually have. >> >> In Mapserver 2.0 the PROCESSING stuff should be possible to set via variable substitution and your users could make the adjustment on-the-fly. Perhaps they could accept that? >> >> -Jukka- >> >> Andrea Peri wrote: >> >>> Hi Jukka, I could open a feature request for this, but before I need to understand if the results with this strategy are affordable for us. >>> Infact I do some test with a domain min/max lesser than 2x and it results unaccepatable for our users. The raster are too poor contrasted as reported me from our users. >>> So I'm not sure that an AUTO with a STD stretch and a multiplicator 2x could be instead an acceptable solution. >> I should do more tests... >> >> Thx. >> >> >> >> 2015-08-04 20:29 GMT+02:00 Rahkonen Jukka (MML) >> : >>> Hi Andrea, >>> >>> For viewing purposes it is rather common to do LUT stretch by standard deviation which is not so sensible as min-max stretch. Consider making a feature request for a new enhanced PROCESSING AUTO directive which would do the STD stretch, possibly with an optional multiplication. 2 x STD might be a good default value. >>> >>> -Jukka Rahkonen- >>> >>> Andrea Peri wrote: >>> >>>> HI Jukka, >>>> unfortunatelly, I cannot use the LUT because the raster I use is update weekly and every week it could change the min/max values for every bands (it has 11 bands). >>>> Hovewer if it work using the min/max from get map , probably it could be ok form me. >>>> The question s that even when the getmap request the entire bbox the image reported seem to be empty without no error log. >>> >>> >>> 2015-08-04 19:50 GMT+02:00 Rahkonen Jukka (MML) >>> : >>>> Hi, >>>> >>>> I suppose that Even means that with AUTO setting Mapserver is analyzing the min/max pixel values from inside the BBOX of each GetMap and then scales pixel values to 0-256 for the output. One totally black or white pixel within the BBOX can make the result from 64bit source very bad. >>>> >>>> I would try to use LUT instead of SCALE http://www.mapserver.org/input/raster.html#special-processing-directives. >>>> >>>> -Jukka Rahkonen- >>>> >>>> >>>> >>>> >>>> -----Alkuper?inen viesti-----l >>>> L?hett?j?: mapserver-users-bounces at lists.osgeo.org >>>> [mailto:mapserver-users-bounces at lists.osgeo.org] Puolesta Andrea Peri >>>> L?hetetty: 4. elokuuta 2015 20:07 >>>> Vastaanottaja: Even Rouault >>>> Kopio: mapserver-users at lists.osgeo.org >>>> Aihe: Re: [mapserver-users] processing scale=auto with float >>>> multibands rasters >>>> >>>> Hi Even, >>>> >>>> thx for response. >>>> >>>> Please can you help me to better understand the question ? >>>> >>>> My raster is effectively a 18000 x 24000 px image with tiles. >>>> >>>> it have a tile size of 1024 x 1024 produced from gdalwarp: >>>> >>>> gdalwarp -s_srs EPSG:32632 -t_srs EPSG:32632 -overwrite --config >>>> GDAL_CACHEMAX 1000 -wm 1000 -co TILED=YES -co COMPRESS=NONE -co >>>> BLOCKXSIZE=1024 -co BLOCKYSIZE=1024 -co BIGTIFF=YES -co SPARSE_OK=TRUE ....... >>>> >>>> and also have overviews from >>>> >>>> gdaladdo --config GDAL_CACHEMAX 1500 -ro -r average ..... 2 4 8 16 32 >>>> 64 128 256 512 1024 >>>> >>>> If I understand correctly your info. >>>> The mapserver could search the min/max using only the first tile ? >>>> >>>> This mean that it more probably found always only 0 values or near 0 values beacuse these could be the values in the first tile. >>>> >>>> And so it return a white image because the min/max is always min=0/ >>>> max=0 (or something quite like this) >>>> I understand correct ? >>>> >>>> thx, >>>> >>>> A. >>>> >>>> >>>> 2015-08-04 16:01 GMT+02:00 Even Rouault : >>>>> On Monday 03 August 2015 11:02:43 Andrea Peri wrote: >>>>>> Hi, >>>>>> I have a geotiff multibands with float64 values to serve with a wms >>>>>> mapserver service. >>>>>> >>>>>> With this kind of rasters, >>>>>> is affordable the directive >>>>>> >>>>>> PROCESSING "BANDS=4,3,2" >>>>>> PROCESSING "SCALE=AUTO" >>>>>> >>>>>> (the 4,3,2 are the red,green,blue channels) >>>>>> >>>>>> Infact it seem do nothing. >>>>>> >>>>>> Instead all work well if I set: >>>>>> >>>>>> PROCESSING "BANDS=4,3,2" >>>>>> PROCESSING "SCALE_1=0.01,0.2" >>>>>> PROCESSING "SCALE_2=0.01,0.2" >>>>>> PROCESSING "SCALE_3=0.01,0.2" >>>>>> >>>>>> where ii use the min=0.01 and max=0.2 But I like to have the exact >>>>>> values of min/max for every raster. >>>>> Andrea, >>>>> >>>>> SCALE=AUTO should work but looking at the actual implementation I >>>>> can see it computes the min/max on the pixel values intersecting the >>>>> requested area, and not on the whole raster as I'd have expected. So >>>>> in a tiling context, it will likely not produce the expected result. >>>>> >>>>> Even >>>>> >>>>> -- >>>>> Spatialys - Geospatial professional services >>>>> http://www.spatialys.com >>>> >>>> >>>> -- >>>> ----------------- >>>> Andrea Peri >>>> . . . . . . . . . >>>> qwerty ????? >>>> ----------------- >>>> _______________________________________________ >>>> mapserver-users mailing list >>>> mapserver-users at lists.osgeo.org >>>> http://lists.osgeo.org/mailman/listinfo/mapserver-users >>> >>> >>> -- >>> ----------------- >>> Andrea Peri >>> . . . . . . . . . >>> qwerty ????? >>> ----------------- >> >> >> -- >> ----------------- >> Andrea Peri >> . . . . . . . . . >> qwerty ????? >> ----------------- > > From ankuriimt at gmail.com Tue Aug 4 23:52:34 2015 From: ankuriimt at gmail.com (ankur chitranshi) Date: Wed, 5 Aug 2015 12:22:34 +0530 Subject: [mapserver-users] where to file .htaccess file Message-ID: where to find .htacess find in map sever for using of rewrites URL -- thanks & regards Ankur Chitranshi -------------- next part -------------- An HTML attachment was scrubbed... URL: From aperi2007 at gmail.com Wed Aug 5 01:57:27 2015 From: aperi2007 at gmail.com (Andrea Peri) Date: Wed, 5 Aug 2015 10:57:27 +0200 Subject: [mapserver-users] processing scale=auto with float multibands rasters In-Reply-To: <55C17959.2010202@gmail.com> References: <0ecfddd8b12b472890ff08cabb2c5e35@C119S212VM022.msvyvi.vaha.local> <55C17959.2010202@gmail.com> Message-ID: Hi Jim thx for explain correct formula. I try it. The result is surely better, but again it seem a too much smoothing. But these is the right direction. I try also with lower values of userSelectedScaleFactor rather than 2. Meanwhile I try also using directly the min/max retrieved from statistics and see the the result is absolutelly not usefule. The rasters have some spikes values (due to noise) that produce an image with a color dynamic too compress. Thx, A. 2015-08-05 4:47 GMT+02:00 Jim Klassen : > Generally the formula for this is: > Mean +/- (userSelectedScaleFactor * StdDev) > > So Band 4 (with userSelectedScaleFactor = 2) would be: > min = 0.082 - (2 * 0.042) = -0.002 > max = 0.082 + (2 * 0.042) = 0.166 > > On 08/04/2015 04:43 PM, Andrea Peri wrote: >> Hi Jukka, >> >> The value I use for test was retrieve using qgis defaults so I don't >> know if your formula was the same. >> >> So I do a quick test >> these are the values for my test raster: >> >> Band 1 Minimum=0.038, Maximum=1.584, Mean=0.135, StdDev=0.026 >> Band 2 Minimum=0.004, Maximum=1.567, Mean=0.115, StdDev=0.027 >> Band 3 Minimum=0.003, Maximum=1.636, Mean=0.096, StdDev=0.031 >> Band 4 Minimum=-0.016, Maximum=1.796, Mean=0.082, StdDev=0.042 >> Band 5 Minimum=-0.311, Maximum=4.486, Mean=0.256, StdDev=0.138 >> Band 6 Minimum=-0.197, Maximum=3.277, Mean=0.161, StdDev=0.098 >> Band 7 Minimum=-0.118, Maximum=2.295, Mean=0.088, StdDev=0.063 >> Band 8 Minimum=0.039, Maximum=1.366, Mean=0.090, StdDev=0.035 >> Band 9 Minimum=-0.039, Maximum=0.413, Mean=0.003, StdDev=0.010 >> Band 10 Minimum=240.580, Maximum=524.602, Mean=299.351, StdDev=6.342 >> Band 11 Minimum=249.037, Maximum=514.462, Mean=297.375, StdDev=5.855 >> >> Using you formula: >> (I hope to understand it correctly) >> >> PROCESSING "BANDS=4,3,2" (the red,green,blue channels) >> >> the values should be: >> >> Band 4: >> 0.082 - (-0.016 * 0.042) = 0.082672 >> 0.082 + (1.796 * 0.042) = 0.157432 >> >> Band 3: >> 0.096 - (0.003 * 0.031) = 0.095907 >> 0.096 + (1.636 * 0.031) = 0.146716 >> >> Band 2: >> 0.115 - (0.004 * 0.027) = 0.114892 >> 0.115 + (1.567 * 0.027) = 0.157309 >> >> so the setting should be: >> >> PROCESSING "SCALE_1= 0.082672 , 0.157432" >> PROCESSING "SCALE_2= 0.095907 , 0.146716" >> PROCESSING "SCALE_3= 0.114892 , 0.157309" >> >> With this values the image is not correct . >> >> I add a link to a sample images of what the mapserver will produce >> with these values. >> >> https://www.dropbox.com/s/izleegjbp18j81f/sample-mapserver-with-values.gif?dl=0 >> >> >> A. >> >> 2015-08-04 22:52 GMT+02:00 Rahkonen Jukka (MML) >> : >>> Hi, >>> >>> Do we talk about the same thing? If gdalinfo -stats shows >>> Minimum=2.000, Maximum=255.000, Mean=96.297, StdDev=37.015 >>> you should put min at 96.297-(2*37.015) >>> You can test the effect with QGIS as described here http://gis.stackexchange.com/questions/87914/how-to-perform-a-standard-deviation-stretch-on-a-raster-in-qgis >>> However, I have not really used 64-bit images and don't know what kind of histograms they usually have. >>> >>> In Mapserver 2.0 the PROCESSING stuff should be possible to set via variable substitution and your users could make the adjustment on-the-fly. Perhaps they could accept that? >>> >>> -Jukka- >>> >>> Andrea Peri wrote: >>> >>>> Hi Jukka, I could open a feature request for this, but before I need to understand if the results with this strategy are affordable for us. >>>> Infact I do some test with a domain min/max lesser than 2x and it results unaccepatable for our users. The raster are too poor contrasted as reported me from our users. >>>> So I'm not sure that an AUTO with a STD stretch and a multiplicator 2x could be instead an acceptable solution. >>> I should do more tests... >>> >>> Thx. >>> >>> >>> >>> 2015-08-04 20:29 GMT+02:00 Rahkonen Jukka (MML) >>> : >>>> Hi Andrea, >>>> >>>> For viewing purposes it is rather common to do LUT stretch by standard deviation which is not so sensible as min-max stretch. Consider making a feature request for a new enhanced PROCESSING AUTO directive which would do the STD stretch, possibly with an optional multiplication. 2 x STD might be a good default value. >>>> >>>> -Jukka Rahkonen- >>>> >>>> Andrea Peri wrote: >>>> >>>>> HI Jukka, >>>>> unfortunatelly, I cannot use the LUT because the raster I use is update weekly and every week it could change the min/max values for every bands (it has 11 bands). >>>>> Hovewer if it work using the min/max from get map , probably it could be ok form me. >>>>> The question s that even when the getmap request the entire bbox the image reported seem to be empty without no error log. >>>> >>>> >>>> 2015-08-04 19:50 GMT+02:00 Rahkonen Jukka (MML) >>>> : >>>>> Hi, >>>>> >>>>> I suppose that Even means that with AUTO setting Mapserver is analyzing the min/max pixel values from inside the BBOX of each GetMap and then scales pixel values to 0-256 for the output. One totally black or white pixel within the BBOX can make the result from 64bit source very bad. >>>>> >>>>> I would try to use LUT instead of SCALE http://www.mapserver.org/input/raster.html#special-processing-directives. >>>>> >>>>> -Jukka Rahkonen- >>>>> >>>>> >>>>> >>>>> >>>>> -----Alkuper?inen viesti-----l >>>>> L?hett?j?: mapserver-users-bounces at lists.osgeo.org >>>>> [mailto:mapserver-users-bounces at lists.osgeo.org] Puolesta Andrea Peri >>>>> L?hetetty: 4. elokuuta 2015 20:07 >>>>> Vastaanottaja: Even Rouault >>>>> Kopio: mapserver-users at lists.osgeo.org >>>>> Aihe: Re: [mapserver-users] processing scale=auto with float >>>>> multibands rasters >>>>> >>>>> Hi Even, >>>>> >>>>> thx for response. >>>>> >>>>> Please can you help me to better understand the question ? >>>>> >>>>> My raster is effectively a 18000 x 24000 px image with tiles. >>>>> >>>>> it have a tile size of 1024 x 1024 produced from gdalwarp: >>>>> >>>>> gdalwarp -s_srs EPSG:32632 -t_srs EPSG:32632 -overwrite --config >>>>> GDAL_CACHEMAX 1000 -wm 1000 -co TILED=YES -co COMPRESS=NONE -co >>>>> BLOCKXSIZE=1024 -co BLOCKYSIZE=1024 -co BIGTIFF=YES -co SPARSE_OK=TRUE ....... >>>>> >>>>> and also have overviews from >>>>> >>>>> gdaladdo --config GDAL_CACHEMAX 1500 -ro -r average ..... 2 4 8 16 32 >>>>> 64 128 256 512 1024 >>>>> >>>>> If I understand correctly your info. >>>>> The mapserver could search the min/max using only the first tile ? >>>>> >>>>> This mean that it more probably found always only 0 values or near 0 values beacuse these could be the values in the first tile. >>>>> >>>>> And so it return a white image because the min/max is always min=0/ >>>>> max=0 (or something quite like this) >>>>> I understand correct ? >>>>> >>>>> thx, >>>>> >>>>> A. >>>>> >>>>> >>>>> 2015-08-04 16:01 GMT+02:00 Even Rouault : >>>>>> On Monday 03 August 2015 11:02:43 Andrea Peri wrote: >>>>>>> Hi, >>>>>>> I have a geotiff multibands with float64 values to serve with a wms >>>>>>> mapserver service. >>>>>>> >>>>>>> With this kind of rasters, >>>>>>> is affordable the directive >>>>>>> >>>>>>> PROCESSING "BANDS=4,3,2" >>>>>>> PROCESSING "SCALE=AUTO" >>>>>>> >>>>>>> (the 4,3,2 are the red,green,blue channels) >>>>>>> >>>>>>> Infact it seem do nothing. >>>>>>> >>>>>>> Instead all work well if I set: >>>>>>> >>>>>>> PROCESSING "BANDS=4,3,2" >>>>>>> PROCESSING "SCALE_1=0.01,0.2" >>>>>>> PROCESSING "SCALE_2=0.01,0.2" >>>>>>> PROCESSING "SCALE_3=0.01,0.2" >>>>>>> >>>>>>> where ii use the min=0.01 and max=0.2 But I like to have the exact >>>>>>> values of min/max for every raster. >>>>>> Andrea, >>>>>> >>>>>> SCALE=AUTO should work but looking at the actual implementation I >>>>>> can see it computes the min/max on the pixel values intersecting the >>>>>> requested area, and not on the whole raster as I'd have expected. So >>>>>> in a tiling context, it will likely not produce the expected result. >>>>>> >>>>>> Even >>>>>> >>>>>> -- >>>>>> Spatialys - Geospatial professional services >>>>>> http://www.spatialys.com >>>>> >>>>> >>>>> -- >>>>> ----------------- >>>>> Andrea Peri >>>>> . . . . . . . . . >>>>> qwerty ????? >>>>> ----------------- >>>>> _______________________________________________ >>>>> mapserver-users mailing list >>>>> mapserver-users at lists.osgeo.org >>>>> http://lists.osgeo.org/mailman/listinfo/mapserver-users >>>> >>>> >>>> -- >>>> ----------------- >>>> Andrea Peri >>>> . . . . . . . . . >>>> qwerty ????? >>>> ----------------- >>> >>> >>> -- >>> ----------------- >>> Andrea Peri >>> . . . . . . . . . >>> qwerty ????? >>> ----------------- >> >> > > _______________________________________________ > mapserver-users mailing list > mapserver-users at lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/mapserver-users -- ----------------- Andrea Peri . . . . . . . . . qwerty ????? ----------------- From jukka.rahkonen at maanmittauslaitos.fi Wed Aug 5 02:43:14 2015 From: jukka.rahkonen at maanmittauslaitos.fi (Rahkonen Jukka (MML)) Date: Wed, 5 Aug 2015 09:43:14 +0000 Subject: [mapserver-users] What resourse blocks any bigger GeoTIFF output from WCS? Message-ID: <0b62c5e06b6740d2a7baea7ba02ab930@C119S212VM022.msvyvi.vaha.local> Hi, I started to experiment with WCS 2.0.1 with Mapserver 7.1-dev and I managed to get WCS to work rather easily. However, I can only get data with rather small GetCoverage requests when using image/tiff format. My environment: MapServer 7.1-dev which I installed from the 32-bit Windows binaries from gisinternals http://download.gisinternals.com/sdk/downloads/release-1600-gdal-mapserver.zip. For installation I used existing MS4W installation by making a new cgi-bin directory where I dropped the new binaries (dll files and mapserv.exe). My computer is 64-bit Windows 7 with 8 GB of memory. I am stuck with 32-bit Mapserver because using MS4W on the bottom is the only way to install that I can handle. Output is successful when the resulting image is 8000x8000 pixels (192 MB) but if I try to get an image with 10000x10000 pixels (300 MB) I am receiving an error: msWCSWriteFile20(): General error message. msSaveImage() failed msSaveImageGDAL(): General error message. Failed to create output GTiff file. TIFFAppendToStrip:Write error at scanline 6500 I have no problem at all with output size of 12000x12000 pixels if I use image/png or image/jpeg. If I play with subset ranges I can see that the GeoTIFF write error happens at different scanlines. It makes me think that it could be some memory problem. But how could I give more resources for GDAL so it could make its job? I have not yet thought how big images I will need from WCS but lets say the aim is at 50000x50000 pixels which would make 7.5 gigabyte GeoTIFF as an uncompressed, 8-bit, 3-band image. -Jukka Rahkonen- From yves.jacolin at camptocamp.com Wed Aug 5 04:38:01 2015 From: yves.jacolin at camptocamp.com (Yves Jacolin) Date: Wed, 05 Aug 2015 13:38:01 +0200 Subject: [mapserver-users] using sld on the server In-Reply-To: References: Message-ID: <2568068.yVH7TGmv1Z@tatras> On Saturday, June 27, 2015 10:57:46 Jachym Cepicky wrote: > Hi all, > > is there possibility to style layer using SLD file configured in MapScript? > Idea would be, instead of using CLASS for configuration, you would just > pass the SLD and things would magically happen (just like it works in > GeoServer). > > Generating MapFiles from QGIS would than be next logical step .. > > I assume, I've missed something and there must be solution for this lying > around for couple of years, but did not find anything > > thanks for any hint > Jachym, Take care of (probably) some difference between QGIS, GeoServer and MapServer on how to understand SLD information. See my test from mapserver to QGIS and GeoServer: * MapSever: https://twitter.com/yjacolin/status/464456432461828096 * GeoServer (same data, Style from MapServer SLD) https://twitter.com/yjacolin/status/464456796548390912 * QGIS : https://twitter.com/yjacolin/status/464477708622503937 It wil be interesting to test SLD export/import in other direction (GS to QGIS and MS, QGIS to GS and MS). Y. -- Responsable Formation et Support Camptocamp France SAS Savoie Technolac, BP 352 73377 Le Bourget du Lac, Cedex Tel (France) : +33 4 58 48 20 43 (new !) Tel (Suisse) : +41 21 619 10 43 Mob. : +33 6 18 75 42 21 Fax : 04 79 70 15 81 Mail : yves.jacolin at camptocamp.com http://www.camptocamp.com From jukka.rahkonen at maanmittauslaitos.fi Wed Aug 5 04:56:43 2015 From: jukka.rahkonen at maanmittauslaitos.fi (Rahkonen Jukka (MML)) Date: Wed, 5 Aug 2015 11:56:43 +0000 Subject: [mapserver-users] using sld on the server Message-ID: <0d950d4aa35145ca993c1a5f19e34506@C119S212VM022.msvyvi.vaha.local> Hi, Could you do one more test: read SLD out from Mapserver and push it back with WMS SLD or SLD_BODY. I suppose you will see a different map again at least if the styles are not very simple. -Jukka Rahkonen- Yves Jacolin wrote: On Saturday, June 27, 2015 10:57:46 Jachym Cepicky wrote: >> Hi all, >> >> is there possibility to style layer using SLD file configured in MapScript? >> Idea would be, instead of using CLASS for configuration, you would >> just pass the SLD and things would magically happen (just like it >> works in GeoServer). >> >> Generating MapFiles from QGIS would than be next logical step .. >> >> I assume, I've missed something and there must be solution for this >> lying around for couple of years, but did not find anything >> >> thanks for any hint >> > Jachym, > Take care of (probably) some difference between QGIS, GeoServer and MapServer on how to understand SLD information. > See my test from mapserver to QGIS and GeoServer: > * MapSever: https://twitter.com/yjacolin/status/464456432461828096 > * GeoServer (same data, Style from MapServer SLD) > https://twitter.com/yjacolin/status/464456796548390912 > * QGIS : https://twitter.com/yjacolin/status/464477708622503937 > It wil be interesting to test SLD export/import in other direction (GS to QGIS and MS, QGIS to GS and MS). Y. -- Responsable Formation et Support Camptocamp France SAS Savoie Technolac, BP 352 73377 Le Bourget du Lac, Cedex Tel (France) : +33 4 58 48 20 43 (new !) Tel (Suisse) : +41 21 619 10 43 Mob. : +33 6 18 75 42 21 Fax : 04 79 70 15 81 Mail : yves.jacolin at camptocamp.com http://www.camptocamp.com _______________________________________________ mapserver-users mailing list mapserver-users at lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users From even.rouault at spatialys.com Wed Aug 5 05:04:23 2015 From: even.rouault at spatialys.com (Even Rouault) Date: Wed, 05 Aug 2015 14:04:23 +0200 Subject: [mapserver-users] What resourse blocks any bigger GeoTIFF output from WCS? In-Reply-To: <0b62c5e06b6740d2a7baea7ba02ab930@C119S212VM022.msvyvi.vaha.local> References: <0b62c5e06b6740d2a7baea7ba02ab930@C119S212VM022.msvyvi.vaha.local> Message-ID: <2401129.t5K6WIMEoM@even-n550jk> On Wednesday 05 August 2015 09:43:14 Rahkonen Jukka wrote: > Hi, > > I started to experiment with WCS 2.0.1 with Mapserver 7.1-dev and I managed > to get WCS to work rather easily. However, I can only get data with rather > small GetCoverage requests when using image/tiff format. > > My environment: > MapServer 7.1-dev which I installed from the 32-bit Windows binaries from > gisinternals > http://download.gisinternals.com/sdk/downloads/release-1600-gdal-mapserver. > zip. For installation I used existing MS4W installation by making a new > cgi-bin directory where I dropped the new binaries (dll files and > mapserv.exe). My computer is 64-bit Windows 7 with 8 GB of memory. I am > stuck with 32-bit Mapserver because using MS4W on the bottom is the only > way to install that I can handle. > > Output is successful when the resulting image is 8000x8000 pixels (192 MB) > but if I try to get an image with 10000x10000 pixels (300 MB) I am > receiving an error: > > msWCSWriteFile20(): General error message. msSaveImage() > failed msSaveImageGDAL(): General error message. Failed to create output > GTiff file. TIFFAppendToStrip:Write error at scanline 6500 > I have no problem at all with output size of 12000x12000 pixels if I use > image/png or image/jpeg. > > If I play with subset ranges I can see that the GeoTIFF write error happens > at different scanlines. It makes me think that it could be some memory > problem. But how could I give more resources for GDAL so it could make its > job? I have not yet thought how big images I will need from WCS but lets > say the aim is at 50000x50000 pixels which would make 7.5 gigabyte GeoTIFF > as an uncompressed, 8-bit, 3-band image. Jukka, My understanding on what is involved is the following. MapServer will first allocate a memory buffer for the whole resulting image, do the rendering on it, create a GDAL MEM dataset with the content of the mapserver image, and then CreateCopy() it to the final in-memory image file and then stream it out through HTTP. So in the case of the 10K x 10K image, you'll have a 300 MB buffer for the mapserver image + 300 MB for the GDAL MEM dataset + 300 MB for the resulting TIFF stored in a /vsimem/ file. Due to the way the TIFF writer works, by appending data and growing the /vsimem/ file progressively by successive realloc(), I suspect that heap memory fragmentation occurs and that on the available 2 GB of the 32 bit process, much more than the theoretically 3x300 MB needed is consumed, reaching the 2 GB limit. I don't see any easy workaround, but a few possible improvements: - (GDAL) In the case of uncompressed TIFF where the final file size is known the GDAL GTiff writer could perhaps be improved to actually pre-allocate the whole buffer instead of growing it progressively, so as to avoid heap fragmentation. - (MapServer) Another/complementary option would be in the case of GTiff, and other formats that supports the GDALCreate() API, to avoid the use of the MEM dataset. - (MapServer) Another/complementary option would be to offer an option to have a on-disk temporary file to save some RAM. For non-virtual enabled GDAL formats, such as netCDF, this is what is used. - (MapServer) Another/complementary option would be to use in MapServer the new capability in GDAL 2.0 of the GTiff driver to generate directly streamable file in the case of a uncompressed file. But even in the best case (just the mapserver image buffer), the maximum file you could produce would be 2 GB with a 32bit MapServer build. In theory, I believe that WCS GetCoverage could generite arbitrary file size with modest RAM requirements but that would likely require major architectural changes in MapServer. Even > > -Jukka Rahkonen- > _______________________________________________ > mapserver-users mailing list > mapserver-users at lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/mapserver-users -- Spatialys - Geospatial professional services http://www.spatialys.com From jukka.rahkonen at maanmittauslaitos.fi Wed Aug 5 05:16:49 2015 From: jukka.rahkonen at maanmittauslaitos.fi (Rahkonen Jukka (MML)) Date: Wed, 5 Aug 2015 12:16:49 +0000 Subject: [mapserver-users] What resourse blocks any bigger GeoTIFF output from WCS? Message-ID: <26e88c43f2a0412290b5c0ee8c690f3e@C119S212VM022.msvyvi.vaha.local> Hi, Thank you very much about the information. How much about the troubles remain if 64-bit system is used, and would there be any difference between Windows and Linux then? 2 GB outputs are not unrealistically small for a web service but WCS coverages can be very large and as far as I know WCS has no standard way for paging. I don't even feel very relaxed with paging by making subsequent GetCoverages by sliding the subset range without checking carefully how the pixels at the seams behave. -Jukka Rahkonen- Even Rouault wrote: On Wednesday 05 August 2015 09:43:14 Rahkonen Jukka wrote: > Hi, > > I started to experiment with WCS 2.0.1 with Mapserver 7.1-dev and I > managed to get WCS to work rather easily. However, I can only get data > with rather small GetCoverage requests when using image/tiff format. > > My environment: > MapServer 7.1-dev which I installed from the 32-bit Windows binaries > from gisinternals > http://download.gisinternals.com/sdk/downloads/release-1600-gdal-mapserver. > zip. For installation I used existing MS4W installation by making a > new cgi-bin directory where I dropped the new binaries (dll files and > mapserv.exe). My computer is 64-bit Windows 7 with 8 GB of memory. I > am stuck with 32-bit Mapserver because using MS4W on the bottom is the > only way to install that I can handle. > > Output is successful when the resulting image is 8000x8000 pixels (192 > MB) but if I try to get an image with 10000x10000 pixels (300 MB) I am > receiving an error: > > msWCSWriteFile20(): General error message. > msSaveImage() failed msSaveImageGDAL(): General error message. Failed > to create output GTiff file. TIFFAppendToStrip:Write error at scanline > 6500 I have no problem at all with output size of 12000x12000 pixels > if I use image/png or image/jpeg. > > If I play with subset ranges I can see that the GeoTIFF write error > happens at different scanlines. It makes me think that it could be > some memory problem. But how could I give more resources for GDAL so > it could make its job? I have not yet thought how big images I will > need from WCS but lets say the aim is at 50000x50000 pixels which > would make 7.5 gigabyte GeoTIFF as an uncompressed, 8-bit, 3-band image. Jukka, My understanding on what is involved is the following. MapServer will first allocate a memory buffer for the whole resulting image, do the rendering on it, create a GDAL MEM dataset with the content of the mapserver image, and then CreateCopy() it to the final in-memory image file and then stream it out through HTTP. So in the case of the 10K x 10K image, you'll have a 300 MB buffer for the mapserver image + 300 MB for the GDAL MEM dataset + 300 MB for the resulting TIFF stored in a /vsimem/ file. Due to the way the TIFF writer works, by appending data and growing the /vsimem/ file progressively by successive realloc(), I suspect that heap memory fragmentation occurs and that on the available 2 GB of the 32 bit process, much more than the theoretically 3x300 MB needed is consumed, reaching the 2 GB limit. I don't see any easy workaround, but a few possible improvements: - (GDAL) In the case of uncompressed TIFF where the final file size is known the GDAL GTiff writer could perhaps be improved to actually pre-allocate the whole buffer instead of growing it progressively, so as to avoid heap fragmentation. - (MapServer) Another/complementary option would be in the case of GTiff, and other formats that supports the GDALCreate() API, to avoid the use of the MEM dataset. - (MapServer) Another/complementary option would be to offer an option to have a on-disk temporary file to save some RAM. For non-virtual enabled GDAL formats, such as netCDF, this is what is used. - (MapServer) Another/complementary option would be to use in MapServer the new capability in GDAL 2.0 of the GTiff driver to generate directly streamable file in the case of a uncompressed file. But even in the best case (just the mapserver image buffer), the maximum file you could produce would be 2 GB with a 32bit MapServer build. In theory, I believe that WCS GetCoverage could generite arbitrary file size with modest RAM requirements but that would likely require major architectural changes in MapServer. Even > > -Jukka Rahkonen- > _______________________________________________ > mapserver-users mailing list > mapserver-users at lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/mapserver-users -- Spatialys - Geospatial professional services http://www.spatialys.com From even.rouault at spatialys.com Wed Aug 5 05:33:26 2015 From: even.rouault at spatialys.com (Even Rouault) Date: Wed, 05 Aug 2015 14:33:26 +0200 Subject: [mapserver-users] What resourse blocks any bigger GeoTIFF output from WCS? In-Reply-To: <26e88c43f2a0412290b5c0ee8c690f3e@C119S212VM022.msvyvi.vaha.local> References: <26e88c43f2a0412290b5c0ee8c690f3e@C119S212VM022.msvyvi.vaha.local> Message-ID: <2206504.jbraLcDO2P@even-n550jk> On Wednesday 05 August 2015 12:16:49 Rahkonen Jukka wrote: > Hi, > > Thank you very much about the information. How much about the troubles > remain if 64-bit system is used, With a 64 bit system, you would still need to be able to allocate 3 times the size of the output file, either from RAM only or RAM + swap space. > and would there be any difference between > Windows and Linux then? On 64 bit probably little. On 32 bit, the Linux memory allocator could potentially be better at limiting fragmentation, but I'm not sure of that. > 2 GB outputs are not unrealistically small for a > web service but WCS coverages can be very large and as far as I know WCS > has no standard way for paging. I don't even feel very relaxed with paging > by making subsequent GetCoverages by sliding the subset range without > checking carefully how the pixels at the seams behave. There might indeed be border effects if resampling is involved, although ideally MapServer should query a bit more than the requested area (I think it does) > > -Jukka Rahkonen- > > > Even Rouault wrote: > > On Wednesday 05 August 2015 09:43:14 Rahkonen Jukka wrote: > > Hi, > > > > I started to experiment with WCS 2.0.1 with Mapserver 7.1-dev and I > > managed to get WCS to work rather easily. However, I can only get data > > with rather small GetCoverage requests when using image/tiff format. > > > > My environment: > > MapServer 7.1-dev which I installed from the 32-bit Windows binaries > > from gisinternals > > http://download.gisinternals.com/sdk/downloads/release-1600-gdal-mapserver > > . > > zip. For installation I used existing MS4W installation by making a > > new cgi-bin directory where I dropped the new binaries (dll files and > > mapserv.exe). My computer is 64-bit Windows 7 with 8 GB of memory. I > > am stuck with 32-bit Mapserver because using MS4W on the bottom is the > > only way to install that I can handle. > > > > Output is successful when the resulting image is 8000x8000 pixels (192 > > MB) but if I try to get an image with 10000x10000 pixels (300 MB) I am > > receiving an error: > > > > msWCSWriteFile20(): General error message. > > msSaveImage() failed msSaveImageGDAL(): General error message. Failed > > to create output GTiff file. TIFFAppendToStrip:Write error at scanline > > 6500 I have no problem at all with output size of 12000x12000 pixels > > if I use image/png or image/jpeg. > > > > If I play with subset ranges I can see that the GeoTIFF write error > > happens at different scanlines. It makes me think that it could be > > some memory problem. But how could I give more resources for GDAL so > > it could make its job? I have not yet thought how big images I will > > need from WCS but lets say the aim is at 50000x50000 pixels which > > would make 7.5 gigabyte GeoTIFF as an uncompressed, 8-bit, 3-band image. > > Jukka, > > My understanding on what is involved is the following. MapServer will first > allocate a memory buffer for the whole resulting image, do the rendering on > it, create a GDAL MEM dataset with the content of the mapserver image, and > then CreateCopy() it to the final in-memory image file and then stream it > out through HTTP. So in the case of the 10K x 10K image, you'll have a 300 > MB buffer for the mapserver image + 300 MB for the GDAL MEM dataset + 300 > MB for the resulting TIFF stored in a /vsimem/ file. Due to the way the > TIFF writer works, by appending data and growing the /vsimem/ file > progressively by successive realloc(), I suspect that heap memory > fragmentation occurs and that on the available 2 GB of the 32 bit process, > much more than the theoretically 3x300 MB needed is consumed, reaching the > 2 GB limit. I don't see any easy workaround, but a few possible > improvements: > - (GDAL) In the case of uncompressed TIFF where the final file size is known > the GDAL GTiff writer could perhaps be improved to actually pre-allocate > the whole buffer instead of growing it progressively, so as to avoid heap > fragmentation. - (MapServer) Another/complementary option would be in the > case of GTiff, and other formats that supports the GDALCreate() API, to > avoid the use of the MEM dataset. - (MapServer) Another/complementary > option would be to offer an option to have a on-disk temporary file to save > some RAM. For non-virtual enabled GDAL formats, such as netCDF, this is > what is used. - (MapServer) Another/complementary option would be to use in > MapServer the new capability in GDAL 2.0 of the GTiff driver to generate > directly streamable file in the case of a uncompressed file. > > But even in the best case (just the mapserver image buffer), the maximum > file you could produce would be 2 GB with a 32bit MapServer build. In > theory, I believe that WCS GetCoverage could generite arbitrary file size > with modest RAM requirements but that would likely require major > architectural changes in MapServer. > > Even > > > -Jukka Rahkonen- > > _______________________________________________ > > mapserver-users mailing list > > mapserver-users at lists.osgeo.org > > http://lists.osgeo.org/mailman/listinfo/mapserver-users > > -- > Spatialys - Geospatial professional services http://www.spatialys.com -- Spatialys - Geospatial professional services http://www.spatialys.com From jukka.rahkonen at maanmittauslaitos.fi Wed Aug 5 05:48:53 2015 From: jukka.rahkonen at maanmittauslaitos.fi (Rahkonen Jukka (MML)) Date: Wed, 5 Aug 2015 12:48:53 +0000 Subject: [mapserver-users] What resourse blocks any bigger GeoTIFF output from WCS? Message-ID: <94c2fa191a6d4286ab10b07d636ddfe0@C119S212VM022.msvyvi.vaha.local> Even Rouault wrote: > On Wednesday 05 August 2015 12:16:49 Rahkonen Jukka wrote: >> Hi, >> >> Thank you very much about the information. How much about the troubles >> remain if 64-bit system is used, > With a 64 bit system, you would still need to be able to allocate 3 times the size of the output file, either from RAM only or RAM + swap space. Doesn't it mean that if WCS server happens to get lots of users who would make for example 500 MB requests on average the result could be huge RAM usage, lots of swapping and perhaps not so good service level? -Jukka- From even.rouault at spatialys.com Wed Aug 5 06:02:57 2015 From: even.rouault at spatialys.com (Even Rouault) Date: Wed, 05 Aug 2015 15:02:57 +0200 Subject: [mapserver-users] What resourse blocks any bigger GeoTIFF output from WCS? In-Reply-To: <94c2fa191a6d4286ab10b07d636ddfe0@C119S212VM022.msvyvi.vaha.local> References: <94c2fa191a6d4286ab10b07d636ddfe0@C119S212VM022.msvyvi.vaha.local> Message-ID: <4815141.Dd7zQLsi9g@even-n550jk> On Wednesday 05 August 2015 12:48:53 Rahkonen Jukka wrote: > Even Rouault wrote: > > On Wednesday 05 August 2015 12:16:49 Rahkonen Jukka wrote: > >> Hi, > >> > >> Thank you very much about the information. How much about the troubles > >> remain if 64-bit system is used, > > > > With a 64 bit system, you would still need to be able to allocate 3 times > > the size of the output file, either from RAM only or RAM + swap space. > Doesn't it mean that if WCS server happens to get lots of users who would > make for example 500 MB requests on average the result could be huge RAM > usage, lots of swapping and perhaps not so good service level? Yes. Ideally if there are requests being processed consuming a lot of RAM, new big requests should be put in standbye until the RAM usage decreases, but I'm not sure how that can be addressed. Perhaps that HTTP servers have options to do things like that (they cannot know how much RAM a new request will consume for sure, so the best they could do would be to standbye all new requests). Wondering if MapServer itself couldn't do that (it could evaluate the memory needed for the current request and check the RAM usage), but not sure it is really its business. > > -Jukka- -- Spatialys - Geospatial professional services http://www.spatialys.com From pc at educ.ar Wed Aug 5 06:33:43 2015 From: pc at educ.ar (Pablo Cecconi) Date: Wed, 5 Aug 2015 10:33:43 -0300 Subject: [mapserver-users] using sld on the server In-Reply-To: <0d950d4aa35145ca993c1a5f19e34506@C119S212VM022.msvyvi.vaha.local> References: <0d950d4aa35145ca993c1a5f19e34506@C119S212VM022.msvyvi.vaha.local> Message-ID: Hi, we are using SLDs generated by QGIS with Mapserver through the WMS SLD parameter with very good results. You can even pass the parameter to a mapcache instance to get a tile cache styled with SLDs. Nevertheless, you should be aware of a few things: - QGIS only allows you to specify sizes (i.e.: for symbols) in map units or millimeters and Mapserver doesn't support Millimeters as a unit. So if you use millimeters you will get very different symbol sizes on the Mapserver render than what you see in QGIS. Our solution is to automatically apply a factor to scale symbol sizes on our import SLD tool. - QGIS allows you to define labels for a layer but the label styles are NOT exported to the SLD file. Although Mapserver does support labels on SLD files and works pretty well. - We experienced some segmentation faults trying to use SLDs through Mapscript so we ended up using the WMS parameter which works very well. Hope these helps. Cheers from Argentina! Pablo On Wed, Aug 5, 2015 at 8:56 AM, Rahkonen Jukka (MML) < jukka.rahkonen at maanmittauslaitos.fi> wrote: > Hi, > > Could you do one more test: read SLD out from Mapserver and push it back > with WMS SLD or SLD_BODY. I suppose you will see a different map again at > least if the styles are not very simple. > > -Jukka Rahkonen- > > Yves Jacolin wrote: > > On Saturday, June 27, 2015 10:57:46 Jachym Cepicky wrote: > >> Hi all, > >> > >> is there possibility to style layer using SLD file configured in > MapScript? > >> Idea would be, instead of using CLASS for configuration, you would > >> just pass the SLD and things would magically happen (just like it > >> works in GeoServer). > >> > >> Generating MapFiles from QGIS would than be next logical step .. > >> > >> I assume, I've missed something and there must be solution for this > >> lying around for couple of years, but did not find anything > >> > >> thanks for any hint > >> > > Jachym, > > > Take care of (probably) some difference between QGIS, GeoServer and > MapServer on how to understand SLD information. > > > See my test from mapserver to QGIS and GeoServer: > > * MapSever: https://twitter.com/yjacolin/status/464456432461828096 > > * GeoServer (same data, Style from MapServer SLD) > > https://twitter.com/yjacolin/status/464456796548390912 > > * QGIS : https://twitter.com/yjacolin/status/464477708622503937 > > > It wil be interesting to test SLD export/import in other direction (GS > to QGIS and MS, QGIS to GS and MS). > > Y. > -- > Responsable Formation et Support > Camptocamp France SAS > Savoie Technolac, BP 352 > 73377 Le Bourget du Lac, Cedex > Tel (France) : +33 4 58 48 20 43 (new !) Tel (Suisse) : +41 21 619 10 43 > Mob. : +33 6 18 75 42 21 Fax : 04 79 70 15 81 Mail : > yves.jacolin at camptocamp.com http://www.camptocamp.com > _______________________________________________ > mapserver-users mailing list > mapserver-users at lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/mapserver-users > _______________________________________________ > mapserver-users mailing list > mapserver-users at lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/mapserver-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Steve.Lime at state.mn.us Wed Aug 5 09:56:27 2015 From: Steve.Lime at state.mn.us (Lime, Steve D (MNIT)) Date: Wed, 5 Aug 2015 16:56:27 +0000 Subject: [mapserver-users] What resourse blocks any bigger GeoTIFF output from WCS? In-Reply-To: <4815141.Dd7zQLsi9g@even-n550jk> References: <94c2fa191a6d4286ab10b07d636ddfe0@C119S212VM022.msvyvi.vaha.local> <4815141.Dd7zQLsi9g@even-n550jk> Message-ID: Sounds messy... I do like the idea of controlling the use disk storage for scratch files or streaming through configuration. -----Original Message----- From: mapserver-users-bounces at lists.osgeo.org [mailto:mapserver-users-bounces at lists.osgeo.org] On Behalf Of Even Rouault Sent: Wednesday, August 05, 2015 8:03 AM To: Rahkonen Jukka (MML) Cc: mapserver-users at lists.osgeo.org Subject: Re: [mapserver-users] What resourse blocks any bigger GeoTIFF output from WCS? On Wednesday 05 August 2015 12:48:53 Rahkonen Jukka wrote: > Even Rouault wrote: > > On Wednesday 05 August 2015 12:16:49 Rahkonen Jukka wrote: > >> Hi, > >> > >> Thank you very much about the information. How much about the troubles > >> remain if 64-bit system is used, > > > > With a 64 bit system, you would still need to be able to allocate 3 times > > the size of the output file, either from RAM only or RAM + swap space. > Doesn't it mean that if WCS server happens to get lots of users who would > make for example 500 MB requests on average the result could be huge RAM > usage, lots of swapping and perhaps not so good service level? Yes. Ideally if there are requests being processed consuming a lot of RAM, new big requests should be put in standbye until the RAM usage decreases, but I'm not sure how that can be addressed. Perhaps that HTTP servers have options to do things like that (they cannot know how much RAM a new request will consume for sure, so the best they could do would be to standbye all new requests). Wondering if MapServer itself couldn't do that (it could evaluate the memory needed for the current request and check the RAM usage), but not sure it is really its business. > > -Jukka- -- Spatialys - Geospatial professional services http://www.spatialys.com _______________________________________________ mapserver-users mailing list mapserver-users at lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users From satpal82bhandari at gmail.com Mon Aug 10 02:56:37 2015 From: satpal82bhandari at gmail.com (satpal bhandari) Date: Mon, 10 Aug 2015 15:26:37 +0530 Subject: [mapserver-users] Mapserver support on Sun Solaris sparc platform Message-ID: Hi All, We are planning to use ?mapserver? on Sun Solaris sparc (Solaris version 10 and 11). As per Mapserver web page (http://mapserver.org/), it is support on all major platform (Windows, Linux, Mac OS X). But did mentions Sun Solaris sparc platform. If mapserver is supported on Sun Solaris sparc platform, Please share the steps for installing the mapserver on Sun Solaris sparc platform. Thanks and regards Satpal +919582398818 -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.smith.erdc at gmail.com Mon Aug 10 03:30:17 2015 From: michael.smith.erdc at gmail.com (michael.smith.erdc at gmail.com) Date: Mon, 10 Aug 2015 06:30:17 -0400 Subject: [mapserver-users] Mapserver support on Sun Solaris sparc platform In-Reply-To: References: Message-ID: Satpal, I have compiled MapServer on Solaris Sparc. The main thing you'll need is the gcc compilers for Solaris Sparc. The other main issue with Solaris Sparc was getting some dependencies to compile. I had a lot of difficulty with libkml for GDAL as a component of MapServer and never did get that component to build. So as long as your dependency needs are modest, you definitely can compile and use MapServer on Solaris Sparc. But not very many people use Sparc so getting help when there is a problem is difficult. Michael Smith Remote Sensing/GIS Center US Army Corps of Engineers > On Aug 10, 2015, at 5:56 AM, satpal bhandari wrote: > > Hi All, > > > > We are planning to use ?mapserver? on Sun Solaris sparc (Solaris version 10 and 11). > > As per Mapserver web page (http://mapserver.org/), it is support on all major platform (Windows, Linux, Mac OS X). > > But did mentions Sun Solaris sparc platform. > > > > If mapserver is supported on Sun Solaris sparc platform, Please share the steps for installing the mapserver on Sun Solaris sparc platform. > > > > Thanks and regards > > Satpal > > +919582398818 > > > _______________________________________________ > mapserver-users mailing list > mapserver-users at lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/mapserver-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From edouard.giudice at gmail.com Wed Aug 12 02:47:25 2015 From: edouard.giudice at gmail.com (EdouardG) Date: Wed, 12 Aug 2015 02:47:25 -0700 (PDT) Subject: [mapserver-users] Some queries return blank Images Message-ID: <1439372845260-5219503.post@n6.nabble.com> Hello, I am running mapserver 6.0.1 trought a cgi script with apache on a debian VM. I am trying to visualise images through WMS using a custom app I developped based on the WorldWind API. I prepared the images with gdal, tiled them, created a shapefile index and overviews. I configured Apache, redacted the mapfile etc. Everything works almost fine. The problem is that when requesting my tiles i can see some of them but others are returned blank. I tried in ArcGIS, my WorldWind App and a browser. Some of the Images and their associated tiles are always blank (always the same ones). I displayed the images (that generate the blank images) and their tiles without any problem in ArcMap but when going through mapserver something I dont know is happening and messing up some of them. I put my Layer in Debug and noticed something in the logfile : When the tile is working I have : [Wed Aug 12 09:58:22 2015].426335 msResampleGDALToMap in effect: cellsize = 0.000007 [Wed Aug 12 09:58:22 2015].426380 msDrawGDAL(Pipes_Layer): using RAW_WINDOW=0 0 1639 1442, dst=0,0,8,7 [Wed Aug 12 09:58:22 2015].426390 msDrawRasterLayerGDAL(): red,green,blue,alpha bands = 1,0,0,0 When its not I have : [Wed Aug 12 09:58:22 2015].424930 msResampleGDALToMap in effect: cellsize = 0.000000 [Wed Aug 12 09:58:22 2015].424973 msDrawGDAL(Pipes_Layer): using RAW_WINDOW=0 0 1 1, dst=0,0,1,1 [Wed Aug 12 09:58:22 2015].424984 msDrawRasterLayerGDAL(): red,green,blue,alpha bands = 1,0,0,0 [Wed Aug 12 09:58:22 2015].425405 msInitProjTransformer() returned NULL. So I can deduce something is wrong here, but I dont really understand why... I am pretty new in this thing and my knowledge stops here... All the Images come from the same survey and have been through the same processing. I will gladly give you any information you might need to investigate this issue. I hope I have been clear enough... Thank you in advance for your help. -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Some-queries-return-blank-Images-tp5219503.html Sent from the Mapserver - User mailing list archive at Nabble.com. From jukka.rahkonen at maanmittauslaitos.fi Wed Aug 12 03:36:19 2015 From: jukka.rahkonen at maanmittauslaitos.fi (Rahkonen Jukka (MML)) Date: Wed, 12 Aug 2015 10:36:19 +0000 Subject: [mapserver-users] Some queries return blank Images Message-ID: <62467d4f08df4e4a9e82ad622adc8de7@C119S212VM022.msvyvi.vaha.local> Hi, The error " msInitProjTransformer() returned NULL." makes me think that something goes wrong with projections. Or then the main point is in RAW_WINDOW=0 0 1 1, dst=0,0,1,1 which probably means that one single pixel is read from the source image for further processing. Showing a simplified but complete mapfile with PROJECTION blocks, gdalinfo from the source image and perhaps also the WMS request that the client is generating would make it much easier to help you. The request can be found from the Apache log and you probably know also how to capture it from your custom app. -Jukka Rahkonen- Puolesta EdouardG wrote: > Hello, > I am running mapserver 6.0.1 trought a cgi script with apache on a debian VM. > I am trying to visualise images through WMS using a custom app I developped based on the WorldWind API. > I prepared the images with gdal, tiled them, created a shapefile index and overviews. > I configured Apache, redacted the mapfile etc. Everything works almost fine. > The problem is that when requesting my tiles i can see some of them but others are returned blank. > I tried in ArcGIS, my WorldWind App and a browser. Some of the Images and their associated tiles are always blank (always the same ones). I displayed the images (that generate > the blank images) and their tiles without any problem in ArcMap but when going through mapserver something I dont know is happening and messing up some of them. > I put my Layer in Debug and noticed something in the logfile : > When the tile is working I have : [Wed Aug 12 09:58:22 2015].426335 msResampleGDALToMap in effect: cellsize = 0.000007 [Wed Aug 12 09:58:22 2015].426380 msDrawGDAL(Pipes_Layer): using RAW_WINDOW=0 0 1639 1442, dst=0,0,8,7 [Wed Aug 12 09:58:22 2015].426390 msDrawRasterLayerGDAL(): red,green,blue,alpha bands = 1,0,0,0 > When its not I have : [Wed Aug 12 09:58:22 2015].424930 msResampleGDALToMap in effect: cellsize = 0.000000 [Wed Aug 12 09:58:22 2015].424973 msDrawGDAL(Pipes_Layer): using RAW_WINDOW=0 0 1 1, dst=0,0,1,1 [Wed Aug 12 09:58:22 2015].424984 msDrawRasterLayerGDAL(): red,green,blue,alpha bands = 1,0,0,0 [Wed Aug 12 09:58:22 2015].425405 msInitProjTransformer() returned NULL. > So I can deduce something is wrong here, but I dont really understand why... > I am pretty new in this thing and my knowledge stops here... > All the Images come from the same survey and have been through the same processing. > I will gladly give you any information you might need to investigate this issue. > I hope I have been clear enough... > Thank you in advance for your help. -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Some-queries-return-blank-Images-tp5219503.html Sent from the Mapserver - User mailing list archive at Nabble.com. _______________________________________________ mapserver-users mailing list mapserver-users at lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users From edouard.giudice at gmail.com Wed Aug 12 04:32:21 2015 From: edouard.giudice at gmail.com (EdouardG) Date: Wed, 12 Aug 2015 04:32:21 -0700 (PDT) Subject: [mapserver-users] Some queries return blank Images In-Reply-To: <62467d4f08df4e4a9e82ad622adc8de7@C119S212VM022.msvyvi.vaha.local> References: <1439372845260-5219503.post@n6.nabble.com> <62467d4f08df4e4a9e82ad622adc8de7@C119S212VM022.msvyvi.vaha.local> Message-ID: <1439379141378-5219514.post@n6.nabble.com> First, thank you for this quick answer. I have been struggling quite a bit with this. I agree with you on the projection problem, the error made me think that at first. The problem is all my data is in EPSG 4326 and all the request are in this CRS too. So I would think no reprojection is necessary. My mapfile is as follow : MAP NAME "Pipes_Angola_WMS" EXTENT 11.660069 -7.637100 11.665110 -7.622088 PROJECTION "init=epsg:4326" END OUTPUTFORMAT NAME "GTiff" DRIVER GDAL/GTiff MIMETYPE "image/tiff" IMAGEMODE RGB EXTENSION "tif" END CONFIG "MS_ERRORFILE" "/data_local/mapdata/ms_error.txt" WEB METADATA "wms_title" "Pipes Angola Server" "wms_onlineresource" "http://10.57.168.114/wms" "wms_srs" "EPSG:4326" "wms_enable_request" "*" END END LAYER NAME "Pipes_Layer" STATUS ON TYPE RASTER DEBUG 5 TILEINDEX "/data_local/mapdata/data/index.shp" TILEITEM "location" METADATA "wms_title" "WMS Pipe Angola" "wms_srs" "EPSG:4326" END PROJECTION "init=epsg:4326" END END END The requests I used in my browser where "cutomised" from those I found in the log made by WolrdWind and Arcmap : /wms?SERVICE=WMS&VERSION=1.3.0&REQUEST=GetMap&CRS=EPSG:4326&BBOX=-7.6344002188000681,11.660860157323178,-7.6343547473002458,11.660909269398337&WIDTH=1376&HEIGHT=1274&LAYERS=Pipes_Layer&STYLES=&EXCEPTIONS=XML&FORMAT=image/png&BGCOLOR=0xFEFFFF&TRANSPARENT=TRUE The result of this request is an image cointaining a working image and a ghost image also. I tried gdalinfo on a working and not working image and i got : for a working image : Driver: GTiff/GeoTIFF Files: 20141215-161415.338-026880.tif Size is 1633, 1431 Coordinate System is: GEOGCS["WGS 84", DATUM["WGS_1984", SPHEROID["WGS 84",6378137,298.257223563, AUTHORITY["EPSG","7030"]], AUTHORITY["EPSG","6326"]], PRIMEM["Greenwich",0], UNIT["degree",0.0174532925199433], AUTHORITY["EPSG","4326"]] Origin = (11.660858092114065,-7.634358707092891) Pixel Size = (0.000000031665310,-0.000000031665310) Metadata: AREA_OR_POINT=Area Image Structure Metadata: INTERLEAVE=BAND Corner Coordinates: Upper Left ( 11.6608581, -7.6343587) ( 11d39'39.09"E, 7d38' 3.69"S) Lower Left ( 11.6608581, -7.6344040) ( 11d39'39.09"E, 7d38' 3.85"S) Upper Right ( 11.6609098, -7.6343587) ( 11d39'39.28"E, 7d38' 3.69"S) Lower Right ( 11.6609098, -7.6344040) ( 11d39'39.28"E, 7d38' 3.85"S) Center ( 11.6608839, -7.6343814) ( 11d39'39.18"E, 7d38' 3.77"S) Band 1 Block=256x256 Type=Byte, ColorInterp=Gray Minimum=84.000, Maximum=255.000, Mean=128.986, StdDev=9.596 NoData Value=0 Overviews: 817x716, 409x358, 205x179, 103x90, 52x45, 26x23, 13x12 Metadata: STATISTICS_MAXIMUM=255 STATISTICS_MEAN=128.98649616133 STATISTICS_MINIMUM=84 STATISTICS_STDDEV=9.5962094258965 for a not working image : Driver: GTiff/GeoTIFF Files: 20141215-161416.853-026881.tif Size is 1633, 1430 Coordinate System is: GEOGCS["WGS 84", DATUM["WGS_1984", SPHEROID["WGS 84",6378137,298.257223563, AUTHORITY["EPSG","7030"]], AUTHORITY["EPSG","6326"]], PRIMEM["Greenwich",0], UNIT["degree",0.0174532925199433], AUTHORITY["EPSG","4326"]] Origin = (11.660866469734488,-7.634335714785948) Pixel Size = (0.000000031279575,-0.000000031279575) Metadata: AREA_OR_POINT=Area Image Structure Metadata: INTERLEAVE=BAND Corner Coordinates: Upper Left ( 11.6608665, -7.6343357) ( 11d39'39.12"E, 7d38' 3.61"S) Lower Left ( 11.6608665, -7.6343804) ( 11d39'39.12"E, 7d38' 3.77"S) Upper Right ( 11.6609175, -7.6343357) ( 11d39'39.30"E, 7d38' 3.61"S) Lower Right ( 11.6609175, -7.6343804) ( 11d39'39.30"E, 7d38' 3.77"S) Center ( 11.6608920, -7.6343581) ( 11d39'39.21"E, 7d38' 3.69"S) Band 1 Block=256x256 Type=Byte, ColorInterp=Gray Minimum=79.000, Maximum=219.000, Mean=126.598, StdDev=10.897 NoData Value=0 Overviews: 817x715, 409x358, 205x179, 103x90, 52x45, 26x23, 13x12 Metadata: STATISTICS_MAXIMUM=219 STATISTICS_MEAN=126.59779535671 STATISTICS_MINIMUM=79 STATISTICS_STDDEV=10.897325852031 The differences are in the pixel size and the dimensions of the image itself but others with other pixel values and dimensions work perfectly fine. Mapserver seems to digest those differences for some cases but not for others... An otherthing I forgot to tell you is that there is some kind of pattern in thoses holes. I am supposed to get a coninuous line of pictures overlapping but the holes are not random, I have something like 5 holes made by continuous images (which number can be different). But from the survey log, the two images i pasted the gdalinfo about where taken 1 minute appart... I hope you have everything you need . -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Some-queries-return-blank-Images-tp5219503p5219514.html Sent from the Mapserver - User mailing list archive at Nabble.com. From mapoubelle22 at gmail.com Wed Aug 12 06:08:10 2015 From: mapoubelle22 at gmail.com (fred p) Date: Wed, 12 Aug 2015 13:08:10 +0000 Subject: [mapserver-users] rendering a raster crossing the antimeridian through a WMS Message-ID: Hello, I do not manage do fully render in a Mapserver WMS a raster that crosses the antimeridian when I request a -180?/+180? longitude bbox. This is the request : mapserv -nh "QUERY_STRING=map=mapfile.map&layers=polar_orbiting_avhrr4&styles=&service=WMS&format=image%2Fpng&request=GetMap&height=400&width=800&version=1.1.1&bbox=-179.99%2C-89.99%2C179.99%2C89.99&exceptions=application%2Fvnd.ogc.se_inimage&srs=EPSG%3A4326&transparent=TRUE In the result image, I only get the western side of the raster, near the +180?. Nothing for the eastern part near the -180?. How to solve this problem ? This is a description of the raster : Driver: GTiff/GeoTIFF Files: /tmp/polar_orbiting_avhrr4.tiff Size is 7021, 4321 Coordinate System is: GEOGCS["unnamed ellipse", DATUM["unknown", SPHEROID["unnamed",6378160,298.2539162964669]], PRIMEM["Greenwich",0], UNIT["degree",0.0174532925199433]] Origin = (135.000000000000000,0.000000000000000) Pixel Size = (0.009257940464321,-0.009257116408239) Metadata: AREA_OR_POINT=Area Image Structure Metadata: INTERLEAVE=BAND Corner Coordinates: Upper Left ( 135.0000000, 0.0000000) (135d 0' 0.00"E, 0d 0' 0.01"N) Lower Left ( 135.0000000, -40.0000000) (135d 0' 0.00"E, 40d 0' 0.00"S) Upper Right ( 200.000, 0.000) (200d 0' 0.00"E, 0d 0' 0.01"N) Lower Right ( 200.000, -40.000) (200d 0' 0.00"E, 40d 0' 0.00"S) Center ( 167.5000000, -20.0000000) (167d30' 0.00"E, 20d 0' 0.00"S) Band 1 Block=7021x1 Type=Byte, ColorInterp=Gray This is the mapfile contents : MAP STATUS ON NAME "foo" CONFIG "MS_ERRORFILE" "stderr" IMAGETYPE "agg" MAXSIZE 8192 PROJECTION "init=epsg:4326" END OUTPUTFORMAT NAME "agg" DRIVER "AGG/PNG" MIMETYPE "image/png8" IMAGEMODE "PC256" EXTENSION "png" END WEB METADATA "ows_enable_request" "*" "ows_sld_enabled" "true" "wms_feature_info_mime_type" "text/html" "wms_srs" "epsg:4326" END END LAYER STATUS ON TYPE RASTER NAME "polar_orbiting_avhrr4" DATA "/tmp/polar_orbiting_avhrr4.tiff" OFFSITE 0 0 0 PROCESSING "RESAMPLE=NEAREST" END END -------------- next part -------------- An HTML attachment was scrubbed... URL: From jmckenna at gatewaygeomatics.com Wed Aug 12 06:37:04 2015 From: jmckenna at gatewaygeomatics.com (Jeff McKenna) Date: Wed, 12 Aug 2015 10:37:04 -0300 Subject: [mapserver-users] rendering a raster crossing the antimeridian through a WMS In-Reply-To: References: Message-ID: <55CB4C00.5040006@gatewaygeomatics.com> On 2015-08-12 10:08 AM, fred p wrote: > Hello, > > I do not manage do fully render in a Mapserver WMS a raster that crosses > the antimeridian when I request a -180?/+180? longitude bbox. > > This is the request : > mapserv -nh > "QUERY_STRING=map=mapfile.map&layers=polar_orbiting_avhrr4&styles=&service=WMS&format=image%2Fpng&request=GetMap&height=400&width=800&version=1.1.1&bbox=-179.99%2C-89.99%2C179.99%2C89.99&exceptions=application%2Fvnd.ogc.se_inimage&srs=EPSG%3A4326&transparent=TRUE > > In the result image, I only get the western side of the raster, near the > +180?. Nothing for the eastern part near the -180?. > > How to solve this problem ? > > This is a description of the raster : > Driver: GTiff/GeoTIFF > Files: /tmp/polar_orbiting_avhrr4.tiff > Size is 7021, 4321 > Coordinate System is: > GEOGCS["unnamed ellipse", > DATUM["unknown", > SPHEROID["unnamed",6378160,298.2539162964669]], > PRIMEM["Greenwich",0], > UNIT["degree",0.0174532925199433]] > Origin = (135.000000000000000,0.000000000000000) > Pixel Size = (0.009257940464321,-0.009257116408239) > Metadata: > AREA_OR_POINT=Area > Image Structure Metadata: > INTERLEAVE=BAND > Corner Coordinates: > Upper Left ( 135.0000000, 0.0000000) (135d 0' 0.00"E, 0d 0' 0.01"N) > Lower Left ( 135.0000000, -40.0000000) (135d 0' 0.00"E, 40d 0' 0.00"S) > Upper Right ( 200.000, 0.000) (200d 0' 0.00"E, 0d 0' 0.01"N) > Lower Right ( 200.000, -40.000) (200d 0' 0.00"E, 40d 0' 0.00"S) > Center ( 167.5000000, -20.0000000) (167d30' 0.00"E, 20d 0' 0.00"S) > Band 1 Block=7021x1 Type=Byte, ColorInterp=Gray > > > This is the mapfile contents : > MAP > STATUS ON > NAME "foo" > CONFIG "MS_ERRORFILE" "stderr" > IMAGETYPE "agg" > MAXSIZE 8192 > PROJECTION > "init=epsg:4326" > END > OUTPUTFORMAT > NAME "agg" > DRIVER "AGG/PNG" > MIMETYPE "image/png8" > IMAGEMODE "PC256" > EXTENSION "png" > END > WEB > METADATA > "ows_enable_request" "*" > "ows_sld_enabled" "true" > "wms_feature_info_mime_type" "text/html" > "wms_srs" "epsg:4326" > END > END > LAYER > STATUS ON > TYPE RASTER > NAME "polar_orbiting_avhrr4" > DATA "/tmp/polar_orbiting_avhrr4.tiff" > OFFSITE 0 0 0 > PROCESSING "RESAMPLE=NEAREST" > END > END > > > By the looks of your layer, before tackling any problems, be sure to execute a GetCapabilities request to your service, and be sure to remove any "WARNING" messages returned. For example, I bet that you have warnings for missing metadata of wms_title, wms_srs, as well as missing PROJECTION block for your layer. It's good practice to first remove the warnings on any WMS service (because those warnings will cause problems for downstream users of your service). -jeff -- Jeff McKenna MapServer Consulting and Training Services http://www.gatewaygeomatics.com/ From mapoubelle22 at gmail.com Wed Aug 12 07:43:31 2015 From: mapoubelle22 at gmail.com (fred p) Date: Wed, 12 Aug 2015 14:43:31 +0000 Subject: [mapserver-users] rendering a raster crossing the antimeridian through a WMS In-Reply-To: <55CB4C00.5040006@gatewaygeomatics.com> References: <55CB4C00.5040006@gatewaygeomatics.com> Message-ID: Thanks to Jeff for the answer. I simplified the mapfile to make it easier to read. Below I give the mapfile with these additional elements. I do not have warnings anymore with a GetCapabilities request but the image I get whith a GetMap request is still incomplete. Note that I get an error (*msProcessProjection(): Projection library error. proj error "projection not named" for ""*) with a projection block in the layer section if I declare the real projection definition (*"+proj=longlat +a=6378160 +b=6356775 +no_defs "*). No error with *"+init=epsg:4326"* which is closed to the real projection definition. As I have read somewhere that if not present the projection is read in the data file, I have removed it (the image I get is the same). MAP STATUS ON NAME "foo" CONFIG "MS_ERRORFILE" "stderr" IMAGETYPE "agg" MAXSIZE 8192 EXTENT -180 -90 180 90 PROJECTION "init=epsg:4326" END OUTPUTFORMAT NAME "agg" DRIVER "AGG/PNG" MIMETYPE "image/png8" IMAGEMODE "PC256" EXTENSION "png" END WEB METADATA "ows_enable_request" "*" "ows_sld_enabled" "true" "wms_feature_info_mime_type" "text/html" "ows_onlineresource" "http://127.0.0.1:8080/wms" "wms_title" "WMS" "wms_srs" "epsg:4326" END END LAYER STATUS ON TYPE RASTER NAME "polar_orbiting_avhrr4" DATA "/tmp/polar_orbiting_avhrr4.tiff" OFFSITE 0 0 0 PROCESSING "RESAMPLE=NEAREST" METADATA "wms_title" "foo" END #PROJECTION # "init=epsg:4326" #END #PROJECTION # "+proj=longlat +a=6378160 +b=6356775 +no_defs" #END END END 2015-08-12 13:37 GMT+00:00 Jeff McKenna : > On 2015-08-12 10:08 AM, fred p wrote: > >> Hello, >> >> I do not manage do fully render in a Mapserver WMS a raster that crosses >> the antimeridian when I request a -180?/+180? longitude bbox. >> >> This is the request : >> mapserv -nh >> >> "QUERY_STRING=map=mapfile.map&layers=polar_orbiting_avhrr4&styles=&service=WMS&format=image%2Fpng&request=GetMap&height=400&width=800&version=1.1.1&bbox=-179.99%2C-89.99%2C179.99%2C89.99&exceptions=application%2Fvnd.ogc.se_inimage&srs=EPSG%3A4326&transparent=TRUE >> >> In the result image, I only get the western side of the raster, near the >> +180?. Nothing for the eastern part near the -180?. >> >> How to solve this problem ? >> >> This is a description of the raster : >> Driver: GTiff/GeoTIFF >> Files: /tmp/polar_orbiting_avhrr4.tiff >> Size is 7021, 4321 >> Coordinate System is: >> GEOGCS["unnamed ellipse", >> DATUM["unknown", >> SPHEROID["unnamed",6378160,298.2539162964669]], >> PRIMEM["Greenwich",0], >> UNIT["degree",0.0174532925199433]] >> Origin = (135.000000000000000,0.000000000000000) >> Pixel Size = (0.009257940464321,-0.009257116408239) >> Metadata: >> AREA_OR_POINT=Area >> Image Structure Metadata: >> INTERLEAVE=BAND >> Corner Coordinates: >> Upper Left ( 135.0000000, 0.0000000) (135d 0' 0.00"E, 0d 0' 0.01"N) >> Lower Left ( 135.0000000, -40.0000000) (135d 0' 0.00"E, 40d 0' 0.00"S) >> Upper Right ( 200.000, 0.000) (200d 0' 0.00"E, 0d 0' 0.01"N) >> Lower Right ( 200.000, -40.000) (200d 0' 0.00"E, 40d 0' 0.00"S) >> Center ( 167.5000000, -20.0000000) (167d30' 0.00"E, 20d 0' 0.00"S) >> Band 1 Block=7021x1 Type=Byte, ColorInterp=Gray >> >> >> This is the mapfile contents : >> MAP >> STATUS ON >> NAME "foo" >> CONFIG "MS_ERRORFILE" "stderr" >> IMAGETYPE "agg" >> MAXSIZE 8192 >> PROJECTION >> "init=epsg:4326" >> END >> OUTPUTFORMAT >> NAME "agg" >> DRIVER "AGG/PNG" >> MIMETYPE "image/png8" >> IMAGEMODE "PC256" >> EXTENSION "png" >> END >> WEB >> METADATA >> "ows_enable_request" "*" >> "ows_sld_enabled" "true" >> "wms_feature_info_mime_type" "text/html" >> "wms_srs" "epsg:4326" >> END >> END >> LAYER >> STATUS ON >> TYPE RASTER >> NAME "polar_orbiting_avhrr4" >> DATA "/tmp/polar_orbiting_avhrr4.tiff" >> OFFSITE 0 0 0 >> PROCESSING "RESAMPLE=NEAREST" >> END >> END >> >> >> >> > By the looks of your layer, before tackling any problems, be sure to > execute a GetCapabilities request to your service, and be sure to remove > any "WARNING" messages returned. For example, I bet that you have warnings > for missing metadata of wms_title, wms_srs, as well as missing PROJECTION > block for your layer. > > It's good practice to first remove the warnings on any WMS service > (because those warnings will cause problems for downstream users of your > service). > > -jeff > > -- > Jeff McKenna > MapServer Consulting and Training Services > http://www.gatewaygeomatics.com/ > > > > > > > > > > > _______________________________________________ > mapserver-users mailing list > mapserver-users at lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/mapserver-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jmckenna at gatewaygeomatics.com Wed Aug 12 10:28:52 2015 From: jmckenna at gatewaygeomatics.com (Jeff McKenna) Date: Wed, 12 Aug 2015 14:28:52 -0300 Subject: [mapserver-users] rendering a raster crossing the antimeridian through a WMS In-Reply-To: References: <55CB4C00.5040006@gatewaygeomatics.com> Message-ID: <55CB8254.2060006@gatewaygeomatics.com> On 2015-08-12 11:43 AM, fred p wrote: > Thanks to Jeff for the answer. > > I simplified the mapfile to make it easier to read. > > Below I give the mapfile with these additional elements. I do not have > warnings anymore with a GetCapabilities request but the image I get > whith a GetMap request is still incomplete. > > Note that I get an error (/msProcessProjection(): Projection library > error. proj error "projection not named" for ""/) with a projection > block in the layer section if I declare the real projection definition > (/"+proj=longlat +a=6378160 +b=6356775 +no_defs "/). No error with > /"+init=epsg:4326"/ which is closed to the real projection definition. > As I have read somewhere that if not present the projection is read in > the data file, I have removed it (the image I get is the same). > > > > MAP > STATUS ON > NAME "foo" > CONFIG "MS_ERRORFILE" "stderr" > IMAGETYPE "agg" > MAXSIZE 8192 > EXTENT -180 -90 180 90 > PROJECTION > "init=epsg:4326" > END > OUTPUTFORMAT > NAME "agg" > DRIVER "AGG/PNG" > MIMETYPE "image/png8" > IMAGEMODE "PC256" > EXTENSION "png" > END > WEB > METADATA > "ows_enable_request" "*" > "ows_sld_enabled" "true" > "wms_feature_info_mime_type" "text/html" > "ows_onlineresource" "http://127.0.0.1:8080/wms" > "wms_title" "WMS" > "wms_srs" "epsg:4326" > END > END > LAYER > STATUS ON > TYPE RASTER > NAME "polar_orbiting_avhrr4" > DATA "/tmp/polar_orbiting_avhrr4.tiff" > OFFSITE 0 0 0 > PROCESSING "RESAMPLE=NEAREST" > METADATA > "wms_title" "foo" > END > #PROJECTION > # "init=epsg:4326" > #END > #PROJECTION > # "+proj=longlat +a=6378160 +b=6356775 +no_defs" > #END > END > END > > Give a good read to the projection page for MapServer (http://www.mapserver.org/mapfile/projection.html), take note of the Example#1, how to define the PROJ.4 parameters (I believe your error is because you've included the "+" by mistake), and then add in your projection block to your layer. And never assume that MapServer can magically read your projection and then announce that to all of your WMS users: always define each layer's actual projection. You can also experiment with the "PROJECTION AUTO" use, as described on that page, but I honestly avoid that and set all accurate projection definitions for each layer. If this was my situation, I'd test this first without WMS, just with the shp2img commandline tool, by modifying my output project (see the "Important Notes" at http://www.mapserver.org/mapfile/projection.html#important-notes) and making sure that this layer is reprojected correctly; once that works, and I'm satisfied with the map image, I'd start testing the WMS reprojection. -jeff -- Jeff McKenna MapServer Consulting and Training Services http://www.gatewaygeomatics.com/ From jmckenna at gatewaygeomatics.com Wed Aug 12 11:34:37 2015 From: jmckenna at gatewaygeomatics.com (Jeff McKenna) Date: Wed, 12 Aug 2015 15:34:37 -0300 Subject: [mapserver-users] Gallery: new version of City of Buenos Aires app Message-ID: <55CB91BD.1000802@gatewaygeomatics.com> Hi everyone, This isn't a question, but I saw on Twitter some news that the City of Buenos Aires has just released a new version of their mapping application, version 4.0 http://mapa.buenosaires.gob.ar I don't have any affiliation with them, but this uses MapServer with OpenStreetMap data, and pgRouting/Postgres/PostGIS. Very nice! -jeff -- Jeff McKenna MapServer Consulting and Training Services http://www.gatewaygeomatics.com/ From bob.basques at ci.stpaul.mn.us Wed Aug 12 11:44:33 2015 From: bob.basques at ci.stpaul.mn.us (Basques, Bob (CI-StPaul)) Date: Wed, 12 Aug 2015 18:44:33 +0000 Subject: [mapserver-users] Gallery: new version of City of Buenos Aires app In-Reply-To: <55CB91BD.1000802@gatewaygeomatics.com> References: <55CB91BD.1000802@gatewaygeomatics.com> Message-ID: <84CAB1EA-A8FB-4372-8108-0B221EAFE841@ci.stpaul.mn.us> All, Bootstrap and Leaflet are in there too. Very nice informational site. Easy to navigate, etc. bobb > On Aug 12, 2015, at 1:34 PM, Jeff McKenna wrote: > > Hi everyone, > > This isn't a question, but I saw on Twitter some news that the City of Buenos Aires has just released a new version of their mapping application, version 4.0 http://mapa.buenosaires.gob.ar > > I don't have any affiliation with them, but this uses MapServer with OpenStreetMap data, and pgRouting/Postgres/PostGIS. > > Very nice! > > -jeff > > > > -- > Jeff McKenna > MapServer Consulting and Training Services > http://www.gatewaygeomatics.com/ > > > > > > _______________________________________________ > mapserver-users mailing list > mapserver-users at lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/mapserver-users From mapoubelle22 at gmail.com Thu Aug 13 01:25:13 2015 From: mapoubelle22 at gmail.com (fred p) Date: Thu, 13 Aug 2015 08:25:13 +0000 Subject: [mapserver-users] rendering a raster crossing the antimeridian through a WMS In-Reply-To: <55CB8254.2060006@gatewaygeomatics.com> References: <55CB4C00.5040006@gatewaygeomatics.com> <55CB8254.2060006@gatewaygeomatics.com> Message-ID: Thanks again for your advices. Unfortunately, I get the same image with shp2img : shp2img -m mapfile.map -o /tmp/foo -e -179.99 -89.99 179.99 89.99 -s 800 400 -l polar_orbiting_avhrr4 -i image/png -all_debug Nothing special in the debug massages. No change about the projection error message with a corrected projection string or with projection auto. I activate the epsg:4326 (though this is not exactly the projection of my data) definition to actually have a projection defined into the layer without any error message. 2015-08-12 17:28 GMT+00:00 Jeff McKenna : > On 2015-08-12 11:43 AM, fred p wrote: > >> Thanks to Jeff for the answer. >> >> I simplified the mapfile to make it easier to read. >> >> Below I give the mapfile with these additional elements. I do not have >> warnings anymore with a GetCapabilities request but the image I get >> whith a GetMap request is still incomplete. >> >> Note that I get an error (/msProcessProjection(): Projection library >> error. proj error "projection not named" for ""/) with a projection >> block in the layer section if I declare the real projection definition >> (/"+proj=longlat +a=6378160 +b=6356775 +no_defs "/). No error with >> /"+init=epsg:4326"/ which is closed to the real projection definition. >> As I have read somewhere that if not present the projection is read in >> the data file, I have removed it (the image I get is the same). >> >> >> >> MAP >> STATUS ON >> NAME "foo" >> CONFIG "MS_ERRORFILE" "stderr" >> IMAGETYPE "agg" >> MAXSIZE 8192 >> EXTENT -180 -90 180 90 >> PROJECTION >> "init=epsg:4326" >> END >> OUTPUTFORMAT >> NAME "agg" >> DRIVER "AGG/PNG" >> MIMETYPE "image/png8" >> IMAGEMODE "PC256" >> EXTENSION "png" >> END >> WEB >> METADATA >> "ows_enable_request" "*" >> "ows_sld_enabled" "true" >> "wms_feature_info_mime_type" "text/html" >> "ows_onlineresource" "http://127.0.0.1:8080/wms" >> "wms_title" "WMS" >> "wms_srs" "epsg:4326" >> END >> END >> LAYER >> STATUS ON >> TYPE RASTER >> NAME "polar_orbiting_avhrr4" >> DATA "/tmp/polar_orbiting_avhrr4.tiff" >> OFFSITE 0 0 0 >> PROCESSING "RESAMPLE=NEAREST" >> METADATA >> "wms_title" "foo" >> END >> #PROJECTION >> # "init=epsg:4326" >> #END >> #PROJECTION >> # "+proj=longlat +a=6378160 +b=6356775 +no_defs" >> #END >> END >> END >> >> >> > Give a good read to the projection page for MapServer ( > http://www.mapserver.org/mapfile/projection.html), take note of the > Example#1, how to define the PROJ.4 parameters (I believe your error is > because you've included the "+" by mistake), and then add in your > projection block to your layer. And never assume that MapServer can > magically read your projection and then announce that to all of your WMS > users: always define each layer's actual projection. You can also > experiment with the "PROJECTION AUTO" use, as described on that page, but I > honestly avoid that and set all accurate projection definitions for each > layer. > > If this was my situation, I'd test this first without WMS, just with the > shp2img commandline tool, by modifying my output project (see the > "Important Notes" at > http://www.mapserver.org/mapfile/projection.html#important-notes) and > making sure that this layer is reprojected correctly; once that works, and > I'm satisfied with the map image, I'd start testing the WMS reprojection. > > -jeff > > > > > -- > Jeff McKenna > MapServer Consulting and Training Services > http://www.gatewaygeomatics.com/ > > > > > > > _______________________________________________ > mapserver-users mailing list > mapserver-users at lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/mapserver-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From charles.kaminski at lexisnexis.com Fri Aug 14 06:46:26 2015 From: charles.kaminski at lexisnexis.com (Kaminski Jr, Charles (RIS-ATL)) Date: Fri, 14 Aug 2015 13:46:26 +0000 Subject: [mapserver-users] Vector Data Formats Message-ID: <7E32F2324944864FB2EAB8AAAD39BFFF8EC2DD49@RISBCTMBXP003.risk.regn.net> Does anyone have any opinions on which vector data formats are preferred when serving up file-based data sources? ---------------------------------------- The information contained in this e-mail message is intended only for the personal and confidential use of the recipient(s) named above. This message may be an attorney-client communication and/or work product and as such is privileged and confidential. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this document in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jukka.rahkonen at maanmittauslaitos.fi Fri Aug 14 07:13:41 2015 From: jukka.rahkonen at maanmittauslaitos.fi (Rahkonen Jukka (MML)) Date: Fri, 14 Aug 2015 14:13:41 +0000 Subject: [mapserver-users] Vector Data Formats Message-ID: <064c555afa1b4142968165b3ba7f6d4e@C119S212VM022.msvyvi.vaha.local> Hi, My favourites are shapefiles and Spatialite. Shapefile format has filesize limits at 2/4 GB, but we have one very well working layer with +300 GB data in shapefiles which are used through ogrtileindex. Remember .qix indexing. With attribute filters shapefiles may get slow because attributes of shapefiles can?t be indexed otherwise than by sorting with sortshp utility. If advanced filters are needed then a properly indexed Spatialite DB is my favourite format. -Jukka Rahkonen- Kaminski Jr, Charles wrote: Does anyone have any opinions on which vector data formats are preferred when serving up file-based data sources? ________________________________ ---------------------------------------- The information contained in this e-mail message is intended only for the personal and confidential use of the recipient(s) named above. This message may be an attorney-client communication and/or work product and as such is privileged and confidential. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this document in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. -------------- next part -------------- An HTML attachment was scrubbed... URL: From aperi2007 at gmail.com Fri Aug 14 15:46:35 2015 From: aperi2007 at gmail.com (Andrea Peri) Date: Sat, 15 Aug 2015 00:46:35 +0200 Subject: [mapserver-users] How set tileindex in mapscript code Message-ID: Hi to all, and happy mid-august holiday. I'm try to understand and use python mapscript to create a mapfile. I'm have some trouble to understand how set the tileindex path for a raster layer. My mapfile setting shoud be something like this: LAYER NAME "layer_1" STATUS OFF TYPE raster TILEINDEX '/path-to-indextile/indextile' TILEITEM 'location' ..... But I dont find anything in the swig API to add the TILEINDEX setting. The only tileindex variable I found is an integer type. So I guess should be another solution to define the "tileindex", but I dont understand what is. Many thx for any help. -- ----------------- Andrea Peri . . . . . . . . . qwerty ????? ----------------- From aperi2007 at gmail.com Fri Aug 14 16:00:46 2015 From: aperi2007 at gmail.com (Andrea Peri) Date: Sat, 15 Aug 2015 01:00:46 +0200 Subject: [mapserver-users] How set tileindex in mapscript code In-Reply-To: References: Message-ID: Hi,I resolve the question: The code is: ..Getlayer(..).tileindex = "path to shapefile" Regards. 2015-08-15 0:46 GMT+02:00 Andrea Peri : > Hi to all, and happy mid-august holiday. > > I'm try to understand and use python mapscript to create a mapfile. > > I'm have some trouble to understand how set the tileindex path for a > raster layer. > > My mapfile setting shoud be something like this: > > LAYER > NAME "layer_1" > STATUS OFF > TYPE raster > TILEINDEX '/path-to-indextile/indextile' > TILEITEM 'location' > ..... > > But I dont find anything in the swig API to add the TILEINDEX setting. > > The only tileindex variable I found is an integer type. > So I guess should be another solution to define the "tileindex", > but I dont understand what is. > > Many thx for any help. > > -- > ----------------- > Andrea Peri > . . . . . . . . . > qwerty ????? > ----------------- -- ----------------- Andrea Peri . . . . . . . . . qwerty ????? ----------------- From Phil.Anzel at ftc.usda.gov Fri Aug 14 14:33:11 2015 From: Phil.Anzel at ftc.usda.gov (Anzel, Phil - NRCS, Fort Collins, CO) Date: Fri, 14 Aug 2015 21:33:11 +0000 Subject: [mapserver-users] Vector Data Formats Message-ID: Charles, A cautionary note on shapefiles: they use dBase III-format files for non-spatial data, this format does not officially support null data values (see for example the discussion at http://gis.stackexchange.com/questions/28411/how-to-have-a-nullable-field-included-in-a-shapefile-using-the-geotools-library). If your data schema allows for nulls you will either need to use some ad-hoc work-around or consider a different file format. - Phil Anzel USDA/NRCS contractor - Team Vistronix This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately. -----Original Message----- From: mapserver-users-bounces at lists.osgeo.org [mailto:mapserver-users-bounces at lists.osgeo.org] On Behalf Of mapserver-users-request at lists.osgeo.org Sent: Friday, August 14, 2015 1:00 PM To: mapserver-users at lists.osgeo.org Subject: mapserver-users Digest, Vol 91, Issue 13 Send mapserver-users mailing list submissions to mapserver-users at lists.osgeo.org To subscribe or unsubscribe via the World Wide Web, visit http://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. Vector Data Formats (Kaminski Jr, Charles (RIS-ATL)) 2. Re: Vector Data Formats (Rahkonen Jukka (MML)) ---------------------------------------------------------------------- Message: 1 Date: Fri, 14 Aug 2015 13:46:26 +0000 From: "Kaminski Jr, Charles (RIS-ATL)" To: "mapserver-users at lists.osgeo.org" Subject: [mapserver-users] Vector Data Formats Message-ID: <7E32F2324944864FB2EAB8AAAD39BFFF8EC2DD49 at RISBCTMBXP003.risk.regn.net> Content-Type: text/plain; charset="us-ascii" Does anyone have any opinions on which vector data formats are preferred when serving up file-based data sources? ---------------------------------------- The information contained in this e-mail message is intended only for the personal and confidential use of the recipient(s) named above. This message may be an attorney-client communication and/or work product and as such is privileged and confidential. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this document in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 2 Date: Fri, 14 Aug 2015 14:13:41 +0000 From: "Rahkonen Jukka (MML)" To: "Kaminski Jr, Charles (RIS-ATL)" , "mapserver-users at lists.osgeo.org" Subject: Re: [mapserver-users] Vector Data Formats Message-ID: <064c555afa1b4142968165b3ba7f6d4e at C119S212VM022.msvyvi.vaha.local> Content-Type: text/plain; charset="utf-8" Hi, My favourites are shapefiles and Spatialite. Shapefile format has filesize limits at 2/4 GB, but we have one very well working layer with +300 GB data in shapefiles which are used through ogrtileindex. Remember .qix indexing. With attribute filters shapefiles may get slow because attributes of shapefiles can?t be indexed otherwise than by sorting with sortshp utility. If advanced filters are needed then a properly indexed Spatialite DB is my favourite format. -Jukka Rahkonen- Kaminski Jr, Charles wrote: Does anyone have any opinions on which vector data formats are preferred when serving up file-based data sources? ________________________________ ---------------------------------------- The information contained in this e-mail message is intended only for the personal and confidential use of the recipient(s) named above. This message may be an attorney-client communication and/or work product and as such is privileged and confidential. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this document in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ _______________________________________________ mapserver-users mailing list mapserver-users at lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users End of mapserver-users Digest, Vol 91, Issue 13 *********************************************** From aperi2007 at gmail.com Fri Aug 14 23:36:31 2015 From: aperi2007 at gmail.com (Andrea Peri) Date: Sat, 15 Aug 2015 08:36:31 +0200 Subject: [mapserver-users] The new composite block in python swig api Message-ID: Hi, I dont find the new Composite block availability in the doc of python api swig. Is it instead available in python? Thx, -- ----------------- Andrea Peri . . . . . . . . . qwerty ????? ----------------- From ben at ausvet.com.au Sun Aug 16 05:36:06 2015 From: ben at ausvet.com.au (Ben Madin) Date: Sun, 16 Aug 2015 20:36:06 +0800 Subject: [mapserver-users] Vector Data Formats In-Reply-To: <7E32F2324944864FB2EAB8AAAD39BFFF8EC2DD49@RISBCTMBXP003.risk.regn.net> References: <7E32F2324944864FB2EAB8AAAD39BFFF8EC2DD49@RISBCTMBXP003.risk.regn.net> Message-ID: Charles, Very few people I work with feel any regrets for moving away from file based data sources and into spatial databases. Actually, I don?t think any of them have any regrets. cheers Ben > On 2015-08-14, at 21:46 , Kaminski Jr, Charles (RIS-ATL) wrote: > > Does anyone have any opinions on which vector data formats are preferred when serving up file-based data sources? > > ---------------------------------------- The information contained in this e-mail message is intended only for the personal and confidential use of the recipient(s) named above. This message may be an attorney-client communication and/or work product and as such is privileged and confidential. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this document in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. > > _______________________________________________ > mapserver-users mailing list > mapserver-users at lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/mapserver-users -- Ben Madin t : +61 8 6102 5535 m : +61 448 887 220 e : ben at ausvet.com.au AusVet Animal Health Services 18/27 Market Street, Fremantle Western Australia AusVet's website: http://www.ausvet.com.au Find our office: http://w3w.co/leader.code.frozen This transmission is for the intended addressee only and is confidential information. If you have received this transmission in error, please delete it and notify the sender. The contents of this email are the opinion of the writer only and are not endorsed by AusVet Animal Health Services unless expressly stated otherwise. Although AusVet uses virus scanning software we do not accept liability for viruses or similar in any attachments. Thanks for reading. -------------- next part -------------- An HTML attachment was scrubbed... URL: From aperi2007 at gmail.com Mon Aug 17 06:35:30 2015 From: aperi2007 at gmail.com (Andrea Peri) Date: Mon, 17 Aug 2015 15:35:30 +0200 Subject: [mapserver-users] Mapserver 7.0 and NODATA setting Message-ID: Hi, I have a raster (flot64) with NODATA = -9999. I set in LAYER section the value PROCESSING "NODATA=-9999" But the nodata portion are still visible (black) I guess it seem a bug in the NODATA code portion, but other thought are welcome. This is the section I have: LAYER EXTENT 142485 4505685 424815 4904415 MAXSCALEDENOM 5e+06 METADATA "wms_extent" "142485.0 4505685.0 424815.0 4904415.0" "wms_title" "Landsat - RGB - sensore LC8 strisciata 191 - Attuale" END # METADATA MINSCALEDENOM 1 NAME "rt_sat.LC8191.rt.attuale" PROCESSING "NODATA=-9999" PROCESSING "SCALE_3=0.106926710091,0.285584945751" PROCESSING "SCALE_2=0.072185581267,0.25725963371" PROCESSING "SCALE_1=0.0567421160237,0.258098917796" PROCESSING "BANDS=4,3,2" PROJECTION "init=epsg:32633" END # PROJECTION STATUS OFF TYPE RASTER UNITS PIXELS -- ----------------- Andrea Peri . . . . . . . . . qwerty ????? ----------------- From jukka.rahkonen at maanmittauslaitos.fi Mon Aug 17 06:44:13 2015 From: jukka.rahkonen at maanmittauslaitos.fi (Rahkonen Jukka (MML)) Date: Mon, 17 Aug 2015 13:44:13 +0000 Subject: [mapserver-users] Mapserver 7.0 and NODATA setting Message-ID: <8e4a6638d853404f9a3fab6083dd963d@C119S212VM022.msvyvi.vaha.local> Hi, I have never seen this processing directive PROCESSING "NODATA=9999" before. Where is it documented? -Jukka Rahkonen- Andrea Peri wrote: Hi, I have a raster (flot64) with NODATA = -9999. I set in LAYER section the value PROCESSING "NODATA=-9999" But the nodata portion are still visible (black) I guess it seem a bug in the NODATA code portion, but other thought are welcome. This is the section I have: LAYER EXTENT 142485 4505685 424815 4904415 MAXSCALEDENOM 5e+06 METADATA "wms_extent" "142485.0 4505685.0 424815.0 4904415.0" "wms_title" "Landsat - RGB - sensore LC8 strisciata 191 - Attuale" END # METADATA MINSCALEDENOM 1 NAME "rt_sat.LC8191.rt.attuale" PROCESSING "NODATA=-9999" PROCESSING "SCALE_3=0.106926710091,0.285584945751" PROCESSING "SCALE_2=0.072185581267,0.25725963371" PROCESSING "SCALE_1=0.0567421160237,0.258098917796" PROCESSING "BANDS=4,3,2" PROJECTION "init=epsg:32633" END # PROJECTION STATUS OFF TYPE RASTER UNITS PIXELS -- ----------------- Andrea Peri . . . . . . . . . qwerty ????? ----------------- _______________________________________________ mapserver-users mailing list mapserver-users at lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users From aperi2007 at gmail.com Mon Aug 17 07:11:28 2015 From: aperi2007 at gmail.com (Andrea Peri) Date: Mon, 17 Aug 2015 16:11:28 +0200 Subject: [mapserver-users] Mapserver 7.0 and NODATA setting In-Reply-To: <8e4a6638d853404f9a3fab6083dd963d@C119S212VM022.msvyvi.vaha.local> References: <8e4a6638d853404f9a3fab6083dd963d@C119S212VM022.msvyvi.vaha.local> Message-ID: Hi Jukka. Perhaps you have right ! The NODATA setting is an ancient setting that I reuse always in my mapfiles but only now I notice that the mapserver document don't report him. So more probably it is a false setting. But , if the nodata setting dont exist, how say to the mapserver to filter the nodata of a floating raster ? Thx. 2015-08-17 15:44 GMT+02:00 Rahkonen Jukka (MML) : > Hi, > > I have never seen this processing directive PROCESSING "NODATA=9999" before. Where is it documented? > > -Jukka Rahkonen- > > Andrea Peri wrote: > > Hi, > I have a raster (flot64) with NODATA = -9999. > I set in LAYER section the value > > PROCESSING "NODATA=-9999" > > But the nodata portion are still visible (black) I guess it seem a bug in the NODATA code portion, but other thought are welcome. > > This is the section I have: > > LAYER > EXTENT 142485 4505685 424815 4904415 > MAXSCALEDENOM 5e+06 > METADATA > "wms_extent" "142485.0 4505685.0 424815.0 4904415.0" > "wms_title" "Landsat - RGB - sensore LC8 strisciata 191 - Attuale" > END # METADATA > MINSCALEDENOM 1 > NAME "rt_sat.LC8191.rt.attuale" > PROCESSING "NODATA=-9999" > PROCESSING "SCALE_3=0.106926710091,0.285584945751" > PROCESSING "SCALE_2=0.072185581267,0.25725963371" > PROCESSING "SCALE_1=0.0567421160237,0.258098917796" > PROCESSING "BANDS=4,3,2" > PROJECTION > "init=epsg:32633" > END # PROJECTION > STATUS OFF > TYPE RASTER > UNITS PIXELS > > > > > -- > ----------------- > Andrea Peri > . . . . . . . . . > qwerty ????? > ----------------- > _______________________________________________ > mapserver-users mailing list > mapserver-users at lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/mapserver-users -- ----------------- Andrea Peri . . . . . . . . . qwerty ????? ----------------- From ian.walberg at airborne.aero Mon Aug 17 16:14:46 2015 From: ian.walberg at airborne.aero (Ian Walberg) Date: Mon, 17 Aug 2015 23:14:46 +0000 Subject: [mapserver-users] PHP Mapscript - setting PostLabelCache stops text displaying Message-ID: Folks, Using PHP Mapscript it appears that when PostLabelCache is set to '1' for a label layer this causes the label text not to display. With a map file this works as expected. Looking in the mapscript/php source directory there are mutiple '#ifdef disabled' around the labelcache functions. Is anyone aware of this? Should I raise an issue? Thanks, Ian From aperi2007 at gmail.com Tue Aug 18 00:08:08 2015 From: aperi2007 at gmail.com (Andrea Peri) Date: Tue, 18 Aug 2015 09:08:08 +0200 Subject: [mapserver-users] Mapserver 7.0 and NODATA setting In-Reply-To: References: <8e4a6638d853404f9a3fab6083dd963d@C119S212VM022.msvyvi.vaha.local> Message-ID: So my question is a little different. Seem that mapserver was not able to automatically understand the NODATA values of floating point rasters. In my usecase: the NODATA value is -9999.0 I produce the catalog using gdaltindex, and apply the result to mapserver 7. The result is this: http://tinyurl.com/ndsdyr8 The only partially solution I found was to set OFFSITE 0 0 0 but it is acceptable for my usecase because the black color is a color really available inside the rasters and it is not usable as a transparent color. Is this an issue for mapserver 7 ? Thx, A. 2015-08-17 16:11 GMT+02:00 Andrea Peri : > Hi Jukka. > > Perhaps you have right ! > > The NODATA setting is an ancient setting that I reuse always in my > mapfiles but only now I notice that the mapserver document don't > report him. > So more probably it is a false setting. > > But , if the nodata setting dont exist, how say to the mapserver to > filter the nodata of a floating raster ? > > Thx. > >> -- >> ----------------- >> Andrea Peri >> . . . . . . . . . >> qwerty ????? >> ----------------- >> _______________________________________________ >> mapserver-users mailing list >> mapserver-users at lists.osgeo.org >> http://lists.osgeo.org/mailman/listinfo/mapserver-users > > > > -- > ----------------- > Andrea Peri > . . . . . . . . . > qwerty ????? > ----------------- -- ----------------- Andrea Peri . . . . . . . . . qwerty ????? ----------------- From aperi2007 at gmail.com Tue Aug 18 00:28:53 2015 From: aperi2007 at gmail.com (Andrea Peri) Date: Tue, 18 Aug 2015 09:28:53 +0200 Subject: [mapserver-users] Mapserver 7.0 and NODATA setting In-Reply-To: References: <8e4a6638d853404f9a3fab6083dd963d@C119S212VM022.msvyvi.vaha.local> Message-ID: Hi, I have a clearly response from the log. The nodata is unsupported for this kind of rasters. > LoadGDALImage(rt_sat.LC8191.rt.attuale): NODATA value -9999 in GDAL >file or PROCESSING directive largely ignored. Not yet fully supported for >unclassified scaled data. The NODATA value is excluded from auto-scaling >min/max computation, but will not be transparent. So I must found another solution for my rasters. Regards. 2015-08-18 9:08 GMT+02:00 Andrea Peri : > So my question is a little different. > > Seem that mapserver was not able to automatically understand the > NODATA values of floating point rasters. > > In my usecase: the NODATA value is -9999.0 > I produce the catalog using gdaltindex, and apply the result to mapserver 7. > > The result is this: > > http://tinyurl.com/ndsdyr8 > > The only partially solution I found was to set > OFFSITE 0 0 0 > but it is acceptable for my usecase because the black color is a color > really available inside the rasters and it is not usable as a > transparent color. > > Is this an issue for mapserver 7 ? > > Thx, > > A. > > > > 2015-08-17 16:11 GMT+02:00 Andrea Peri : >> Hi Jukka. >> >> Perhaps you have right ! >> >> The NODATA setting is an ancient setting that I reuse always in my >> mapfiles but only now I notice that the mapserver document don't >> report him. >> So more probably it is a false setting. >> >> But , if the nodata setting dont exist, how say to the mapserver to >> filter the nodata of a floating raster ? >> >> Thx. >> > >>> -- >>> ----------------- >>> Andrea Peri >>> . . . . . . . . . >>> qwerty ????? >>> ----------------- >>> _______________________________________________ >>> mapserver-users mailing list >>> mapserver-users at lists.osgeo.org >>> http://lists.osgeo.org/mailman/listinfo/mapserver-users >> >> >> >> -- >> ----------------- >> Andrea Peri >> . . . . . . . . . >> qwerty ????? >> ----------------- > > > > -- > ----------------- > Andrea Peri > . . . . . . . . . > qwerty ????? > ----------------- -- ----------------- Andrea Peri . . . . . . . . . qwerty ????? ----------------- From aperi2007 at gmail.com Tue Aug 18 01:27:38 2015 From: aperi2007 at gmail.com (Andrea Peri) Date: Tue, 18 Aug 2015 10:27:38 +0200 Subject: [mapserver-users] Mapserver 7.0 and NODATA setting In-Reply-To: References: <8e4a6638d853404f9a3fab6083dd963d@C119S212VM022.msvyvi.vaha.local> Message-ID: HI, The question of NODATA processing command is not completelly clear afaik. Infact I found a patch from warmerdam: https://trac.osgeo.org/mapserver/ticket/2404 Where it speak explicitly of a PROCESSING "NODATA" setting. >I would note that OFFSITE is still supported, and the usual PROCESSING "NODATA=OFF" >mechanism can be used to disable using GDAL level nodata. A. 2015-08-18 9:28 GMT+02:00 Andrea Peri : > Hi, > > I have a clearly response from the log. > > The nodata is unsupported for this kind of rasters. > >> LoadGDALImage(rt_sat.LC8191.rt.attuale): NODATA value -9999 in GDAL >>file or PROCESSING directive largely ignored. Not yet fully supported for >>unclassified scaled data. The NODATA value is excluded from auto-scaling >>min/max computation, but will not be transparent. > > So I must found another solution for my rasters. > > Regards. > > > > 2015-08-18 9:08 GMT+02:00 Andrea Peri : >> So my question is a little different. >> >> Seem that mapserver was not able to automatically understand the >> NODATA values of floating point rasters. >> >> In my usecase: the NODATA value is -9999.0 >> I produce the catalog using gdaltindex, and apply the result to mapserver 7. >> >> The result is this: >> >> http://tinyurl.com/ndsdyr8 >> >> The only partially solution I found was to set >> OFFSITE 0 0 0 >> but it is acceptable for my usecase because the black color is a color >> really available inside the rasters and it is not usable as a >> transparent color. >> >> Is this an issue for mapserver 7 ? >> >> Thx, >> >> A. >> >> >> >> 2015-08-17 16:11 GMT+02:00 Andrea Peri : >>> Hi Jukka. >>> >>> Perhaps you have right ! >>> >>> The NODATA setting is an ancient setting that I reuse always in my >>> mapfiles but only now I notice that the mapserver document don't >>> report him. >>> So more probably it is a false setting. >>> >>> But , if the nodata setting dont exist, how say to the mapserver to >>> filter the nodata of a floating raster ? >>> >>> Thx. >>> >> >>>> -- >>>> ----------------- >>>> Andrea Peri >>>> . . . . . . . . . >>>> qwerty ????? >>>> ----------------- >>>> _______________________________________________ >>>> mapserver-users mailing list >>>> mapserver-users at lists.osgeo.org >>>> http://lists.osgeo.org/mailman/listinfo/mapserver-users >>> >>> >>> >>> -- >>> ----------------- >>> Andrea Peri >>> . . . . . . . . . >>> qwerty ????? >>> ----------------- >> >> >> >> -- >> ----------------- >> Andrea Peri >> . . . . . . . . . >> qwerty ????? >> ----------------- > > > > -- > ----------------- > Andrea Peri > . . . . . . . . . > qwerty ????? > ----------------- -- ----------------- Andrea Peri . . . . . . . . . qwerty ????? ----------------- From jukka.rahkonen at maanmittauslaitos.fi Tue Aug 18 07:16:11 2015 From: jukka.rahkonen at maanmittauslaitos.fi (Rahkonen Jukka (MML)) Date: Tue, 18 Aug 2015 14:16:11 +0000 Subject: [mapserver-users] How to install 64-bit Apache and Mapserver on Windows Message-ID: Hi, A friendly geologist told me to install 64-bit Apache and Mapserver by following this document http://www.onegeology.org/wmsCookbook/4_4_3.html Apache comes from Apache Lounge http://www.apachelounge.com/ and Mapserver from http://www.gisinternals.com/ and the recipe works. I think it would be worth adding a link to the cookbook into the Windows / Gisinternals section of document http://mapserver.org/download.html. FWTools can be wiped away from the document at the same. MS4W could be the next in a row unless it will get a new version sometimes. -Jukka Rahkonen- -------------- next part -------------- An HTML attachment was scrubbed... URL: From ian.walberg at airborne.aero Tue Aug 18 11:48:02 2015 From: ian.walberg at airborne.aero (Ian Walberg) Date: Tue, 18 Aug 2015 18:48:02 +0000 Subject: [mapserver-users] [mapserver-dev] PHP Mapscript - setting PostLabelCache stops text displaying In-Reply-To: References: Message-ID: <83f1bafaa515463aaa7c480aab386fe6@DAGN02C-S1E7.exg7.exghost.local> I have raised this as an issue https://github.com/mapserver/mapserver/issues/5142 -----Original Message----- From: mapserver-dev-bounces at lists.osgeo.org [mailto:mapserver-dev-bounces at lists.osgeo.org] On Behalf Of Ian Walberg Sent: Monday, August 17, 2015 4:15 PM To: mapserver-dev at lists.osgeo.org; mapserver-users at lists.osgeo.org Subject: [mapserver-dev] PHP Mapscript - setting PostLabelCache stops text displaying Folks, Using PHP Mapscript it appears that when PostLabelCache is set to '1' for a label layer this causes the label text not to display. With a map file this works as expected. Looking in the mapscript/php source directory there are mutiple '#ifdef disabled' around the labelcache functions. Is anyone aware of this? Should I raise an issue? Thanks, Ian _______________________________________________ mapserver-dev mailing list mapserver-dev at lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-dev From ian.walberg at airborne.aero Tue Aug 18 14:54:15 2015 From: ian.walberg at airborne.aero (Ian Walberg) Date: Tue, 18 Aug 2015 21:54:15 +0000 Subject: [mapserver-users] Cross compile - Mapserver 7 cmake Message-ID: Folks, We need to need to build for an arm processor and previously where able to ok with the configure script. However it is not immediately obvious how to do this now the build users cmake. Any pointers/advice would be most appreciated and save us some time. Thanks, Ian From Steve.Lime at state.mn.us Tue Aug 18 15:38:49 2015 From: Steve.Lime at state.mn.us (Lime, Steve D (MNIT)) Date: Tue, 18 Aug 2015 22:38:49 +0000 Subject: [mapserver-users] The new composite block in python swig api In-Reply-To: References: Message-ID: There doesn't look to be specific support for it in the SWIG configuration. The SWIG interface for layers does reference it in the getOpacity/setOpacity methods but for backwards compatibility reasons. The structure is exposed to SWIG however and should be accessible even without special methods. In perl, something like this should work: $layer->{compositor}->{opacity} = 50; $layer->{compositor}->{comp_op} = $mapscript::MS_COMPOP_SCREEN; Does that help? Steve -----Original Message----- From: mapserver-users-bounces at lists.osgeo.org [mailto:mapserver-users-bounces at lists.osgeo.org] On Behalf Of Andrea Peri Sent: Saturday, August 15, 2015 1:37 AM To: mapserver-users at lists.osgeo.org Subject: [mapserver-users] The new composite block in python swig api Hi, I dont find the new Composite block availability in the doc of python api swig. Is it instead available in python? Thx, -- ----------------- Andrea Peri . . . . . . . . . qwerty ????? ----------------- _______________________________________________ mapserver-users mailing list mapserver-users at lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users From richard.greenwood at gmail.com Tue Aug 18 19:15:35 2015 From: richard.greenwood at gmail.com (Richard Greenwood) Date: Tue, 18 Aug 2015 20:15:35 -0600 Subject: [mapserver-users] How to install 64-bit Apache and Mapserver on Windows In-Reply-To: References: Message-ID: On Tue, Aug 18, 2015 at 8:16 AM, Rahkonen Jukka (MML) < jukka.rahkonen at maanmittauslaitos.fi> wrote: > FWTools can be wiped away from the document at the same. MS4W could be the > next in a row unless it will get a new version sometimes. > I agree that http://www.gisinternals.com/ is a complete replacement for fwtools and almost a complete replacement for mw4w. But I think Windows users are stuck if they require php-mapscript. Rich -------------- next part -------------- An HTML attachment was scrubbed... URL: From emperor_stef at yahoo.gr Tue Aug 18 23:47:33 2015 From: emperor_stef at yahoo.gr (Stefanos Anastasiou) Date: Wed, 19 Aug 2015 06:47:33 +0000 (UTC) Subject: [mapserver-users] =?utf-8?b?zqPPh861z4Q6ICBIb3cgdG8gaW5zdGFsbCA2?= =?utf-8?q?4-bit_Apache_and_Mapserver_on=09Windows?= In-Reply-To: References: Message-ID: <1896803711.7245231.1439966853036.JavaMail.yahoo@mail.yahoo.com> Any other alternative for Linux users or cmake and FWTools can be used very good as well? -Stefanos ???? 5:15 ?.?. ???????, 19 ????????? 2015, ?/? Richard Greenwood ??????: On Tue, Aug 18, 2015 at 8:16 AM, Rahkonen Jukka (MML) wrote: FWTools can be wiped away from the document at the same. MS4W could be the next in a row unless it will get a new version sometimes. I agree that?http://www.gisinternals.com/?is a complete replacement for fwtools and almost a complete replacement for mw4w. But I think Windows users are stuck if they require php-mapscript.? Rich _______________________________________________ mapserver-users mailing list mapserver-users at lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From aperi2007 at gmail.com Tue Aug 18 23:56:09 2015 From: aperi2007 at gmail.com (Andrea Peri) Date: Wed, 19 Aug 2015 08:56:09 +0200 Subject: [mapserver-users] The new composite block in python swig api In-Reply-To: References: Message-ID: Hi Steve. Thx for hint. It dont seem work. I Querying the help from python I can see that the "compositer" object is defined inside the layerObj, but dont seem to have any opacity var inside it. I try this: The compositer object is defined, but seem don be any opacity variable inside it. I also check the code of swig inside the file "swiginc/layer.i" I can see that there is still the setOpacity under layer and the getOpacity instead has a 100 value hardcoded. :( ----- void setOpacity(int opacity) { msSetLayerOpacity(self, opacity); } int getOpacity() { if(self->compositer) return (self->compositer->opacity); return (100); } ----- Should I open an issue for this ? 2015-08-19 0:38 GMT+02:00 Lime, Steve D (MNIT) : > There doesn't look to be specific support for it in the SWIG configuration. The SWIG interface for layers does reference it in the getOpacity/setOpacity methods but for backwards compatibility reasons. The structure is exposed to SWIG however and should be accessible even without special methods. In perl, something like this should work: > > $layer->{compositor}->{opacity} = 50; > $layer->{compositor}->{comp_op} = $mapscript::MS_COMPOP_SCREEN; > > Does that help? > > Steve > > -----Original Message----- > From: mapserver-users-bounces at lists.osgeo.org [mailto:mapserver-users-bounces at lists.osgeo.org] On Behalf Of Andrea Peri > Sent: Saturday, August 15, 2015 1:37 AM > To: mapserver-users at lists.osgeo.org > Subject: [mapserver-users] The new composite block in python swig api > > Hi, > I dont find the new Composite block availability in the doc of python api swig. > Is it instead available in python? > > Thx, > > -- > ----------------- > Andrea Peri > . . . . . . . . . > qwerty ????? > ----------------- > _______________________________________________ > mapserver-users mailing list > mapserver-users at lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/mapserver-users -- ----------------- Andrea Peri . . . . . . . . . qwerty ????? ----------------- From aperi2007 at gmail.com Wed Aug 19 00:01:24 2015 From: aperi2007 at gmail.com (Andrea Peri) Date: Wed, 19 Aug 2015 09:01:24 +0200 Subject: [mapserver-users] The new composite block in python swig api In-Reply-To: References: Message-ID: No, I wrong to read the code. the getOpacity dont return a 100 hardcoded. There no issue. :) Sorry for noise. A. 2015-08-19 8:56 GMT+02:00 Andrea Peri : > Hi Steve. > > Thx for hint. > It dont seem work. > I > > Querying the help from python I can see that the "compositer" object > is defined inside the layerObj, but dont seem to have any opacity var > inside it. > > I try this: > > The compositer object is defined, but seem don be any opacity variable > inside it. > > I also check the code of swig inside the file "swiginc/layer.i" > I can see that there is still the setOpacity under layer and the > getOpacity instead > has a 100 value hardcoded. > :( > > ----- > void setOpacity(int opacity) > { > msSetLayerOpacity(self, opacity); > } > > int getOpacity() { > if(self->compositer) return (self->compositer->opacity); > return (100); > } > ----- > > Should I open an issue for this ? > > > 2015-08-19 0:38 GMT+02:00 Lime, Steve D (MNIT) : >> There doesn't look to be specific support for it in the SWIG configuration. The SWIG interface for layers does reference it in the getOpacity/setOpacity methods but for backwards compatibility reasons. The structure is exposed to SWIG however and should be accessible even without special methods. In perl, something like this should work: >> >> $layer->{compositor}->{opacity} = 50; >> $layer->{compositor}->{comp_op} = $mapscript::MS_COMPOP_SCREEN; >> >> Does that help? >> >> Steve >> >> -----Original Message----- >> From: mapserver-users-bounces at lists.osgeo.org [mailto:mapserver-users-bounces at lists.osgeo.org] On Behalf Of Andrea Peri >> Sent: Saturday, August 15, 2015 1:37 AM >> To: mapserver-users at lists.osgeo.org >> Subject: [mapserver-users] The new composite block in python swig api >> >> Hi, >> I dont find the new Composite block availability in the doc of python api swig. >> Is it instead available in python? >> >> Thx, >> >> -- >> ----------------- >> Andrea Peri >> . . . . . . . . . >> qwerty ????? >> ----------------- >> _______________________________________________ >> mapserver-users mailing list >> mapserver-users at lists.osgeo.org >> http://lists.osgeo.org/mailman/listinfo/mapserver-users > > > > -- > ----------------- > Andrea Peri > . . . . . . . . . > qwerty ????? > ----------------- -- ----------------- Andrea Peri . . . . . . . . . qwerty ????? ----------------- From zachc1980 at gmail.com Wed Aug 19 09:04:36 2015 From: zachc1980 at gmail.com (zach cruise) Date: Wed, 19 Aug 2015 12:04:36 -0400 Subject: [mapserver-users] split one geojson into tiles Message-ID: the subject says it all... but i need mapserver to slice one large geojson file into multiple static geojson files/tiles so i can upload them to the disk and serve from the webserver (without using mapserver) From Robert.Sanson at asurequality.com Wed Aug 19 13:27:12 2015 From: Robert.Sanson at asurequality.com (Robert Sanson) Date: Wed, 19 Aug 2015 20:27:12 +0000 Subject: [mapserver-users] split one geojson into tiles In-Reply-To: References: Message-ID: Maybe this is something you could do with Qgis? Sent from Samsung Mobile -------- Original message -------- From: zach cruise Date:20/08/2015 04:04 (GMT+12:00) To: mapserver-users Cc: mapserver-dev at lists.osgeo.org Subject: [mapserver-users] split one geojson into tiles the subject says it all... but i need mapserver to slice one large geojson file into multiple static geojson files/tiles so i can upload them to the disk and serve from the webserver (without using mapserver) _______________________________________________ mapserver-users mailing list mapserver-users at lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From zachc1980 at gmail.com Wed Aug 19 15:16:38 2015 From: zachc1980 at gmail.com (zach cruise) Date: Wed, 19 Aug 2015 18:16:38 -0400 Subject: [mapserver-users] split one geojson into tiles In-Reply-To: References: Message-ID: On 8/19/15, TC Haddad wrote: > Hi Zach > > If you set up Mapserver to serve the original geojson layer as WFS > service[1] with geojson output [2], you can then pass in the bounding boxes > (using the WFS URL parameter BBOX=) of the tiles that you want to create. > > You will get back the resulting geojson tiles as text in the browser and > can save them to wherever you want to serve them from. > > [1] http://mapserver.org/ogc/wfs_server.html > [2] > http://mapserver.org/output/template_output.html#outputformat-declarations i tried but you can't set zoom levels/precision with wfs [1] and geojson [2]. On 8/19/15, TC Haddad wrote: > OR, a much simpler process would be to use ogr2ogr and skip Mapserver > entirely. > > see the clipping options mentioned here: > > http://www.gdal.org/ogr2ogr.html interesting. i tried gdal2tiles but it creates raster not vector tiles. On 8/19/15, Robert Sanson wrote: > Maybe this is something you could do with Qgis? interesting. i found these- https://github.com/nextgis/QTiles (creates raster tiles) https://github.com/minorua/TileLayerPlugin (creates raster tiles) https://github.com/matakuka/gridsplitter (saves output in .shp that i can convert to geojson, but it doesn't follow the standard x/y/z) From tchaddad at gmail.com Wed Aug 19 15:31:47 2015 From: tchaddad at gmail.com (TC Haddad) Date: Wed, 19 Aug 2015 15:31:47 -0700 Subject: [mapserver-users] split one geojson into tiles In-Reply-To: References: Message-ID: On Wed, Aug 19, 2015 at 3:16 PM, zach cruise wrote: > On 8/19/15, TC Haddad wrote: > > > Hi Zach > > > > If you set up Mapserver to serve the original geojson layer as WFS > > service[1] with geojson output [2], you can then pass in the bounding > boxes > > (using the WFS URL parameter BBOX=) of the tiles that you want to create. > > > > You will get back the resulting geojson tiles as text in the browser and > > can save them to wherever you want to serve them from. > > > > [1] http://mapserver.org/ogc/wfs_server.html > > [2] > > > http://mapserver.org/output/template_output.html#outputformat-declarations > > i tried but you can't set zoom levels/precision with wfs [1] and geojson > [2]. > Yes - you must use BBOX= with WFS. You can get all the BBOX info you need by using globalmaptiles.py for your area of interest. You can get that script here: http://www.maptiler.org/google-maps-coordinates-tile-bounds-projection/ > > On 8/19/15, TC Haddad wrote: > > OR, a much simpler process would be to use ogr2ogr and skip Mapserver > > entirely. > > > > see the clipping options mentioned here: > > > > http://www.gdal.org/ogr2ogr.html > > interesting. i tried gdal2tiles but it creates raster not vector tiles. > Yes OGR2OGR is for vector to vector conversions. Spatial extent options can be passed in using the BBOXes obtained from the same script mentioned above. -------------- next part -------------- An HTML attachment was scrubbed... URL: From samuellapointe at gmail.com Thu Aug 20 10:35:59 2015 From: samuellapointe at gmail.com (Samuel Lapointe) Date: Thu, 20 Aug 2015 13:35:59 -0400 Subject: [mapserver-users] ScribeUI version 1.8 released for Google Summer of Code 2015 Message-ID: Hello everyone, You might already know about ScribeUI since I posted about it on this mailing list a few times this summer, but if you don?t, it is a web utility you can use to create and preview maps, using the regular Mapserver syntax or the Scribe syntax. I spend the summer working on new features to add to ScribeUI for the 2015 edition of Google Summer of Code. This update is the last large update I will make this summer, as the coding period of GSoC 2015 ends tomorrow. This update adds a new plugin called Classify, which automatically creates classes from a set of data. To see more information about this update, take a look at the release page or try it for yourself on the demo page . The demo is reset every day to keep it clean, which means the maps made there are temporary. Even though the summer is over, I will still release bugfixes if necessary. As always, if any issues arise, you can contact me by email or through the project?s issues page Have a nice day! ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmorissette at mapgears.com Thu Aug 20 11:00:10 2015 From: dmorissette at mapgears.com (Daniel Morissette) Date: Thu, 20 Aug 2015 14:00:10 -0400 Subject: [mapserver-users] ScribeUI version 1.8 released for Google Summer of Code 2015 In-Reply-To: References: Message-ID: <55D615AA.40806@mapgears.com> Thank you Samuel. And for those who would like a 5-minute-intro to Scribe features, have a look at the Getting Started page: https://github.com/mapgears/scribeui/wiki/Getting-started-with-ScribeUI Daniel On 2015-08-20 1:35 PM, Samuel Lapointe wrote: > Hello everyone, > > You might already know about ScribeUI since I posted about it on this > mailing list a few times this summer, but if you don?t, it is a web > utility you can use to create and preview maps, using the regular > Mapserver syntax or the Scribe syntax. > > I spend the summer working on new features to add to ScribeUI for the > 2015 edition of Google Summer of Code. This update is the last large > update I will make this summer, as the coding period of GSoC 2015 ends > tomorrow. > > This update adds a new plugin called Classify, which automatically > creates classes from a set of data. To see more information about this > update, take a look at the release page > or try it for > yourself on the demo page . The demo is reset > every day to keep it clean, which means the maps made there are temporary. > > Even though the summer is over, I will still release bugfixes if > necessary. As always, if any issues arise, you can contact me by email > or through the project?s issues page > > > Have a nice day! > > ? > > > _______________________________________________ > mapserver-users mailing list > mapserver-users at lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/mapserver-users > -- Daniel Morissette http://www.mapgears.com/ T: +1 418-696-5056 #201 http://evouala.com/ - Location Intelligence Made Easy From zachc1980 at gmail.com Fri Aug 21 12:48:56 2015 From: zachc1980 at gmail.com (zach cruise) Date: Fri, 21 Aug 2015 15:48:56 -0400 Subject: [mapserver-users] split one geojson into tiles In-Reply-To: References: Message-ID: i can use bbox with wfs in mapserver. or bbox in ogr2ogr. but it doesn't cluster for zoom levels. eg if i have 10 points at street level, i want it to cluster to show only 1 point at country level. however only bbox might work. but i don't understand how to get bbox info for z/x/y.json. could you explain in detail? http://wiki.openstreetmap.org/wiki/Slippy_map_tilenames also is there a seeding operation in mapserver like in geoserver? or should i just use gdal2tiles to create raster tiles? On 8/19/15, TC Haddad wrote: > On Wed, Aug 19, 2015 at 3:16 PM, zach cruise wrote: > >> On 8/19/15, TC Haddad wrote: >> > > >> > Hi Zach >> > >> > If you set up Mapserver to serve the original geojson layer as WFS >> > service[1] with geojson output [2], you can then pass in the bounding >> boxes >> > (using the WFS URL parameter BBOX=) of the tiles that you want to >> > create. >> > >> > You will get back the resulting geojson tiles as text in the browser >> > and >> > can save them to wherever you want to serve them from. >> > >> > [1] http://mapserver.org/ogc/wfs_server.html >> > [2] >> > >> http://mapserver.org/output/template_output.html#outputformat-declarations >> >> i tried but you can't set zoom levels/precision with wfs [1] and geojson >> [2]. >> > > > Yes - you must use BBOX= with WFS. You can get all the BBOX info you need > by using globalmaptiles.py for your area of interest. You can get that > script here: > http://www.maptiler.org/google-maps-coordinates-tile-bounds-projection/ > > >> >> On 8/19/15, TC Haddad wrote: >> > OR, a much simpler process would be to use ogr2ogr and skip Mapserver >> > entirely. >> > >> > see the clipping options mentioned here: >> > >> > http://www.gdal.org/ogr2ogr.html >> >> interesting. i tried gdal2tiles but it creates raster not vector tiles. >> > > > Yes OGR2OGR is for vector to vector conversions. Spatial extent options can > be passed in using the BBOXes obtained from the same script mentioned > above. > From geographika at gmail.com Mon Aug 24 05:51:00 2015 From: geographika at gmail.com (geographika) Date: Mon, 24 Aug 2015 14:51:00 +0200 Subject: [mapserver-users] Multiple MapCache configuration files Message-ID: <55DB1334.9000602@gmail.com> Hi, As per the configuration guide I have a single xml configuration file for all MapCache layers. This is set in httpd.conf (I'm using ms4w, and running on a Windows server): Order Allow,Deny Allow from all MapCacheAlias /mapcache "C:/ms4w/apps/mapcache/mapcache.xml" However I'm using MapCache on a development server and hosting several different applications. I create the xml file dynamically for each application, however with this approach I either have to change the above path and restart Apache, or merge all the xml files together to a single file. Is there anyway to change which xml file is used using a querystring, or is there any other suggested approach to handling multiple mapcache.xml files? Regards, Seth -- web:http://geographika.co.uk twitter: @geographika -------------- next part -------------- An HTML attachment was scrubbed... URL: From tkirstine at firstbasesolutions.com Mon Aug 24 06:10:24 2015 From: tkirstine at firstbasesolutions.com (Travis Kirstine) Date: Mon, 24 Aug 2015 09:10:24 -0400 Subject: [mapserver-users] Multiple MapCache configuration files In-Reply-To: <55DB1334.9000602@gmail.com> References: <55DB1334.9000602@gmail.com> Message-ID: You can create multiple aliases in apache Order Allow,Deny Allow from all MapCacheAlias /mapcache_1 "/path/to/mapcache_1.xml" MapCacheAlias /mapcache_2 "/path/to/mapcache_2.xml" MapCacheAlias /mapcache_3 "/path/to/mapcache_3.xml" On Mon, Aug 24, 2015 at 8:51 AM, geographika wrote: > Hi, > > As per the configuration guide I have a single xml configuration file for > all MapCache layers. This is set in httpd.conf (I'm using ms4w, and running > on a Windows server): > > > > Order Allow,Deny > Allow from all > > MapCacheAlias /mapcache "C:/ms4w/apps/mapcache/mapcache.xml" > > > However I'm using MapCache on a development server and hosting several > different applications. I create the xml file dynamically for each > application, however with this approach I either have to change the above > path and restart Apache, or merge all the xml files together to a single > file. > > Is there anyway to change which xml file is used using a querystring, or > is there any other suggested approach to handling multiple mapcache.xml > files? > > Regards, > > Seth > > -- > web: http://geographika.co.uk > twitter: @geographika > > > > _______________________________________________ > mapserver-users mailing list > mapserver-users at lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/mapserver-users > -- [image: FBS Logo] *Travis Kirstine*, Web Development Supervisor *t *905?477?3600* x *301 | *m *905?534?4798 | tkirstine at firstbasesolution.com *First Base Solutions Inc.* 140 Renfrew Drive, Suite 100 | Markham | Ontario | L3R 6B3 *t* 905?477?3600 | *f* 905?477?0892 | www.firstbasesolutions.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From geographika at gmail.com Mon Aug 24 07:19:01 2015 From: geographika at gmail.com (geographika) Date: Mon, 24 Aug 2015 16:19:01 +0200 Subject: [mapserver-users] Multiple MapCache configuration files In-Reply-To: References: <55DB1334.9000602@gmail.com> Message-ID: <55DB27D5.7040202@gmail.com> Hi, Many thanks for the quick reply! Order Allow,Deny Allow from all MapCacheAlias /mapcache "C:/ms4w/apps/mapcache/mapcache.xml" MapCacheAlias /mapcache2 "C:/ms4w/apps/mapcache/mapcache2.xml" I was getting the following errors in the log at first (even after a restart): [Mon Aug 24 14:59:34 2015] [error] [client 127.0.0.1] File does not exist: C:/ms4w/Apache/htdocs/mapcache2 However after a few restarts of Apache everything started working correctly. Regards, Seth On 24/08/2015 15:10, Travis Kirstine wrote: > You can create multiple aliases in apache > > > > Order Allow,Deny > Allow from all > > MapCacheAlias /mapcache_1 "/path/to/mapcache_1.xml" > MapCacheAlias /mapcache_2 "/path/to/mapcache_2.xml" > MapCacheAlias /mapcache_3 "/path/to/mapcache_3.xml" > > > > On Mon, Aug 24, 2015 at 8:51 AM, geographika > wrote: > > Hi, > > As per the configuration guide I have a single xml configuration > file for all MapCache layers. This is set in httpd.conf (I'm using > ms4w, and running on a Windows server): > > > > Order Allow,Deny > Allow from all > > MapCacheAlias /mapcache "C:/ms4w/apps/mapcache/mapcache.xml" > > > However I'm using MapCache on a development server and hosting > several different applications. I create the xml file dynamically > for each application, however with this approach I either have to > change the above path and restart Apache, or merge all the xml > files together to a single file. > > Is there anyway to change which xml file is used using a > querystring, or is there any other suggested approach to handling > multiple mapcache.xml files? > > Regards, > > Seth > > -- > web:http://geographika.co.uk > twitter: @geographika > > > > _______________________________________________ > mapserver-users mailing list > mapserver-users at lists.osgeo.org > > http://lists.osgeo.org/mailman/listinfo/mapserver-users > > > > > -- > FBS Logo > > *Travis Kirstine*, Web Development Supervisor > *t *905?477?3600/ x /301 | *m *905?534?4798 | > tkirstine at firstbasesolution.com > > *First Base Solutions Inc.* > 140 Renfrew Drive, Suite 100 | Markham | Ontario | L3R 6B3 > *t* 905?477?3600 | *f* 905?477?0892 | www.firstbasesolutions.com > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mapoubelle22 at gmail.com Thu Aug 27 07:21:33 2015 From: mapoubelle22 at gmail.com (fred p) Date: Thu, 27 Aug 2015 16:21:33 +0200 Subject: [mapserver-users] rendering a raster crossing the antimeridian through a WMS In-Reply-To: References: <55CB4C00.5040006@gatewaygeomatics.com> <55CB8254.2060006@gatewaygeomatics.com> Message-ID: Hello, I still cannot get the full image, using shp2img or mapserv commands. I have uploaded the mapfile, the original image, the result image and the expected image (got from gdalwarp) here : ftp://ftp.meteo.fr/pub/CMS/mapserver/ Does someone has got an idea on how to work around it ? Thanks ! 2015-08-13 10:25 GMT+02:00 fred p : > Thanks again for your advices. > > Unfortunately, I get the same image with shp2img : > shp2img -m mapfile.map -o /tmp/foo -e -179.99 -89.99 179.99 89.99 -s 800 > 400 -l polar_orbiting_avhrr4 -i image/png -all_debug > Nothing special in the debug massages. > > No change about the projection error message with a corrected projection > string or with projection auto. I activate the epsg:4326 (though this is > not exactly the projection of my data) definition to actually have a > projection defined into the layer without any error message. > > 2015-08-12 17:28 GMT+00:00 Jeff McKenna : > >> On 2015-08-12 11:43 AM, fred p wrote: >> >>> Thanks to Jeff for the answer. >>> >>> I simplified the mapfile to make it easier to read. >>> >>> Below I give the mapfile with these additional elements. I do not have >>> warnings anymore with a GetCapabilities request but the image I get >>> whith a GetMap request is still incomplete. >>> >>> Note that I get an error (/msProcessProjection(): Projection library >>> error. proj error "projection not named" for ""/) with a projection >>> block in the layer section if I declare the real projection definition >>> (/"+proj=longlat +a=6378160 +b=6356775 +no_defs "/). No error with >>> /"+init=epsg:4326"/ which is closed to the real projection definition. >>> As I have read somewhere that if not present the projection is read in >>> the data file, I have removed it (the image I get is the same). >>> >>> >>> >>> MAP >>> STATUS ON >>> NAME "foo" >>> CONFIG "MS_ERRORFILE" "stderr" >>> IMAGETYPE "agg" >>> MAXSIZE 8192 >>> EXTENT -180 -90 180 90 >>> PROJECTION >>> "init=epsg:4326" >>> END >>> OUTPUTFORMAT >>> NAME "agg" >>> DRIVER "AGG/PNG" >>> MIMETYPE "image/png8" >>> IMAGEMODE "PC256" >>> EXTENSION "png" >>> END >>> WEB >>> METADATA >>> "ows_enable_request" "*" >>> "ows_sld_enabled" "true" >>> "wms_feature_info_mime_type" "text/html" >>> "ows_onlineresource" "http://127.0.0.1:8080/wms" >>> "wms_title" "WMS" >>> "wms_srs" "epsg:4326" >>> END >>> END >>> LAYER >>> STATUS ON >>> TYPE RASTER >>> NAME "polar_orbiting_avhrr4" >>> DATA "/tmp/polar_orbiting_avhrr4.tiff" >>> OFFSITE 0 0 0 >>> PROCESSING "RESAMPLE=NEAREST" >>> METADATA >>> "wms_title" "foo" >>> END >>> #PROJECTION >>> # "init=epsg:4326" >>> #END >>> #PROJECTION >>> # "+proj=longlat +a=6378160 +b=6356775 +no_defs" >>> #END >>> END >>> END >>> >>> >>> >> Give a good read to the projection page for MapServer ( >> http://www.mapserver.org/mapfile/projection.html), take note of the >> Example#1, how to define the PROJ.4 parameters (I believe your error is >> because you've included the "+" by mistake), and then add in your >> projection block to your layer. And never assume that MapServer can >> magically read your projection and then announce that to all of your WMS >> users: always define each layer's actual projection. You can also >> experiment with the "PROJECTION AUTO" use, as described on that page, but I >> honestly avoid that and set all accurate projection definitions for each >> layer. >> >> If this was my situation, I'd test this first without WMS, just with the >> shp2img commandline tool, by modifying my output project (see the >> "Important Notes" at >> http://www.mapserver.org/mapfile/projection.html#important-notes) and >> making sure that this layer is reprojected correctly; once that works, and >> I'm satisfied with the map image, I'd start testing the WMS reprojection. >> >> -jeff >> >> >> >> >> -- >> Jeff McKenna >> MapServer Consulting and Training Services >> http://www.gatewaygeomatics.com/ >> >> >> >> >> >> >> _______________________________________________ >> mapserver-users mailing list >> mapserver-users at lists.osgeo.org >> http://lists.osgeo.org/mailman/listinfo/mapserver-users >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ian.walberg at airborne.aero Thu Aug 27 08:00:15 2015 From: ian.walberg at airborne.aero (Ian Walberg) Date: Thu, 27 Aug 2015 15:00:15 +0000 Subject: [mapserver-users] [mapserver-dev] PHP Mapscript - setting PostLabelCache stops text displaying In-Reply-To: <83f1bafaa515463aaa7c480aab386fe6@DAGN02C-S1E7.exg7.exghost.local> References: <83f1bafaa515463aaa7c480aab386fe6@DAGN02C-S1E7.exg7.exghost.local> Message-ID: Folks, Anyone have any ideas on this? Or is everyone still on their summer vacation :) Many thanks Ian -----Original Message----- From: Ian Walberg Sent: Tuesday, August 18, 2015 11:48 AM To: Ian Walberg ; mapserver-dev at lists.osgeo.org; mapserver-users at lists.osgeo.org Subject: RE: [mapserver-dev] PHP Mapscript - setting PostLabelCache stops text displaying I have raised this as an issue https://github.com/mapserver/mapserver/issues/5142 -----Original Message----- From: mapserver-dev-bounces at lists.osgeo.org [mailto:mapserver-dev-bounces at lists.osgeo.org] On Behalf Of Ian Walberg Sent: Monday, August 17, 2015 4:15 PM To: mapserver-dev at lists.osgeo.org; mapserver-users at lists.osgeo.org Subject: [mapserver-dev] PHP Mapscript - setting PostLabelCache stops text displaying Folks, Using PHP Mapscript it appears that when PostLabelCache is set to '1' for a label layer this causes the label text not to display. With a map file this works as expected. Looking in the mapscript/php source directory there are mutiple '#ifdef disabled' around the labelcache functions. Is anyone aware of this? Should I raise an issue? Thanks, Ian _______________________________________________ mapserver-dev mailing list mapserver-dev at lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-dev From ankuriimt at gmail.com Sun Aug 30 22:11:10 2015 From: ankuriimt at gmail.com (ankur chitranshi) Date: Mon, 31 Aug 2015 10:41:10 +0530 Subject: [mapserver-users] ms4w map file use with open layer UI Message-ID: Help me , how to use ms4w map file , with Open layer UI , to dispaly interactive interface with all features similar to google interface. -- thanks & regards Ankur Chitranshi -------------- next part -------------- An HTML attachment was scrubbed... URL: From Stefan.Ziegler at bd.so.ch Mon Aug 31 01:53:44 2015 From: Stefan.Ziegler at bd.so.ch (Ziegler Stefan) Date: Mon, 31 Aug 2015 08:53:44 +0000 Subject: [mapserver-users] MapCache: KVP vs Rest Message-ID: <96EAE7D042AAC14486D68EC70207B0C14AD797D5@srsofaioi16255.verw.rootso.org> Hi Perhaps rather a general question: is there any difference in the performance between requesting tiles with KVP an Rest? Or does one have some advantages? Best regards Stefan Freundliche Gr?sse Stefan Ziegler Kantonsgeometer Amt f?r Geoinformation Amtliche Vermessung R?tistrasse 4 4500 Solothurn Telefon +41 32 627 75 96 Telefax +41 32 627 75 98 stefan.ziegler at bd.so.ch http://www.so.ch