From zach.chehayeb at airborne.aero Thu Oct 1 12:13:04 2015 From: zach.chehayeb at airborne.aero (Zach Chehayeb) Date: Thu, 1 Oct 2015 19:13:04 +0000 Subject: [mapserver-users] Understanding extents and resolutions Message-ID: <42693d31d0cf4b7d85f2c988e61cfd25@DAGN04A-S1E7.exg7.exghost.local> Hello All, Can anyone explain or point me in the right direction on how mapserver logic works when a requested map extent cannot be produced at the requested resolution with square pixels? I am using mapserver in an application that requests mapserver to produce various map extents at various resolutions. The map config is set to not allow non square pixel (so the MS_NONSQUARE setting is set to no). The application currently assumes that the extent height should always be half of the width. Of course, with MS_NONSQUARE set to no and producing resolutions where the height is not always exactly half of the width, mapserver is unable to produce the exact extents requested. As such, mapserver compensates by extending either the north and south or east and west bounds of the map. See images in link below for a detailed illustration (the red box indicates the requested extent). For all images below, the requested extent is x1=-58.615527, y1=50.434875, x2=-13.615527, y2=72.934875, but the actual extents differ. >From my observations, it seems that there are three cases. I have included a link below where a zip file that has examples of the cases can be downloaded. https://www.dropbox.com/s/dy1cgmt8lmbl3wf/Example%20Images.zip?dl=0 1. The requested resolution height is greater than half of the width (1280x720). a. Result: MapServer locks on the East and West bounds and extends the North and South bounds of the map. 2. The requested resolution height is less than half of the width (960x400). a. Result: MapServer locks on the North and South bounds and extends the East and West bounds. 3. The requested resolution height is half of the width (1000x500). a. Result: MapServer produces the image at the requested resolution. Is anyone able to confirm that these are the only three cases or correct my understanding (if there is more to it than I have described)? Some info about my installation: 1. MapServer version 6.0.3 OUTPUT=GIF OUTPUT=PNG OUTPUT=JPEG SUPPORTS=PROJ SUPPORTS=AGG SUPPORTS=FREETYPE SUPPORTS=ICONV SUPPORTS=FRIBIDI SUPPORTS=WMS_SERVER SUPPORTS=WMS_CLIENT SUPPORTS=WFS_SERVER SUPPORTS=WFS_CLIENT SUPPORTS=FASTCGI SUPPORTS=THREADS INPUT=OGR INPUT=GDAL INPUT=SHAPEFILE Please let me know if there is any other information needed. Thanks in advance, Zach Chehayeb Application Developer Email. zach.chehayeb at airborne.aero Tel No. +1 949 707 1800 www.airborne.aero [New Small2] -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 2577 bytes Desc: image001.jpg URL: From fl_v at inbox.ru Thu Oct 1 11:42:41 2015 From: fl_v at inbox.ru (=?UTF-8?B?VmxhZGltaXI=?=) Date: Thu, 01 Oct 2015 21:42:41 +0300 Subject: [mapserver-users] =?utf-8?q?PhpMapScript_7=2E0=3A_Property_=27typ?= =?utf-8?q?e=27_does_not_exist_in_this_object?= Message-ID: <1443724961.9753330@f419.i.mail.ru> I try to set a label font using: $label->set('type', MS_TRUETYPE); $label->set('font', 'arial'); but get MapScriptException: Property 'type' does not exist in this object using. Moreover, the labeling works well without these two strings.? The docs contain the reference to 'type' member of labelObj: http://mapserver.org/mapscript/php/phpmapscript.html#labelobj it seems the property should be legal. Could anybody clarify the situation? -------------- next part -------------- An HTML attachment was scrubbed... URL: From bob.basques at ci.stpaul.mn.us Thu Oct 1 12:28:58 2015 From: bob.basques at ci.stpaul.mn.us (Basques, Bob (CI-StPaul)) Date: Thu, 1 Oct 2015 19:28:58 +0000 Subject: [mapserver-users] Understanding extents and resolutions In-Reply-To: <42693d31d0cf4b7d85f2c988e61cfd25@DAGN04A-S1E7.exg7.exghost.local> References: <42693d31d0cf4b7d85f2c988e61cfd25@DAGN04A-S1E7.exg7.exghost.local> Message-ID: <79705E83-ABEF-4E8C-B7F3-5D822F79184C@ci.stpaul.mn.us> Zach, If I?m understanding your question correctly, MapServer will always give you your requested coordinate space inside of the requested image size, by buffering the image results along the axis that is larger than the coordinate window needs to draw completely. In other words, MapServer automatically pads the output image to fill in those areas, East/West and North/South edges based on the coordinate space requested. If you need them to match up exactly, then you need to do the computations in your application to make the correct requests and make the coordinate window ratio match the pixel window (image size) ratios. bobb On Oct 1, 2015, at 2:13 PM, Zach Chehayeb > wrote: Hello All, Can anyone explain or point me in the right direction on how mapserver logic works when a requested map extent cannot be produced at the requested resolution with square pixels? I am using mapserver in an application that requests mapserver to produce various map extents at various resolutions. The map config is set to not allow non square pixel (so the MS_NONSQUARE setting is set to no). The application currently assumes that the extent height should always be half of the width. Of course, with MS_NONSQUARE set to no and producing resolutions where the height is not always exactly half of the width, mapserver is unable to produce the exact extents requested. As such, mapserver compensates by extending either the north and south or east and west bounds of the map. See images in link below for a detailed illustration (the red box indicates the requested extent). For all images below, the requested extent is x1=-58.615527, y1=50.434875, x2=-13.615527, y2=72.934875, but the actual extents differ. From my observations, it seems that there are three cases. I have included a link below where a zip file that has examples of the cases can be downloaded. https://www.dropbox.com/s/dy1cgmt8lmbl3wf/Example%20Images.zip?dl=0 1. The requested resolution height is greater than half of the width (1280x720). a. Result: MapServer locks on the East and West bounds and extends the North and South bounds of the map. 2. The requested resolution height is less than half of the width (960x400). a. Result: MapServer locks on the North and South bounds and extends the East and West bounds. 3. The requested resolution height is half of the width (1000x500). a. Result: MapServer produces the image at the requested resolution. Is anyone able to confirm that these are the only three cases or correct my understanding (if there is more to it than I have described)? Some info about my installation: 1. MapServer version 6.0.3 OUTPUT=GIF OUTPUT=PNG OUTPUT=JPEG SUPPORTS=PROJ SUPPORTS=AGG SUPPORTS=FREETYPE SUPPORTS=ICONV SUPPORTS=FRIBIDI SUPPORTS=WMS_SERVER SUPPORTS=WMS_CLIENT SUPPORTS=WFS_SERVER SUPPORTS=WFS_CLIENT SUPPORTS=FASTCGI SUPPORTS=THREADS INPUT=OGR INPUT=GDAL INPUT=SHAPEFILE Please let me know if there is any other information needed. Thanks in advance, Zach Chehayeb Application Developer Email. zach.chehayeb at airborne.aero Tel No. +1 949 707 1800 www.airborne.aero _______________________________________________ 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 zach.chehayeb at airborne.aero Thu Oct 1 13:22:16 2015 From: zach.chehayeb at airborne.aero (Zach Chehayeb) Date: Thu, 1 Oct 2015 20:22:16 +0000 Subject: [mapserver-users] Understanding extents and resolutions In-Reply-To: <79705E83-ABEF-4E8C-B7F3-5D822F79184C@ci.stpaul.mn.us> References: <42693d31d0cf4b7d85f2c988e61cfd25@DAGN04A-S1E7.exg7.exghost.local> <79705E83-ABEF-4E8C-B7F3-5D822F79184C@ci.stpaul.mn.us> Message-ID: <0dbd96985f6a46568c5449cb6a9aec03@DAGN04A-S1E7.exg7.exghost.local> Bob, I am not sure I am understanding your response correctly. Are you suggesting that it is the coordinate window ratio that determines whether mapserver locks on the east/west or north/south bounds? If so, this doesn?t align with my observations below as all the images where sent the exact same coordinate window but pad on a different axis. I plan to do the computation to match up exactly as you have suggested but I want to be sure that I correctly understand the logic that mapserver uses to decide which axis to pad so I can apply the computations to the correct axis. I have to maintain backward compatibility in my application and need to accurately assess the actual extent drawn. Regards, Zach Chehayeb Application Developer Email. zach.chehayeb at airborne.aero Tel No. +1 949 707 1800 www.airborne.aero [New Small2] From: Basques, Bob (CI-StPaul) [mailto:bob.basques at ci.stpaul.mn.us] Sent: Thursday, October 01, 2015 12:29 PM To: Zach Chehayeb Cc: mapserver-users at lists.osgeo.org Subject: Re: [mapserver-users] Understanding extents and resolutions Zach, If I?m understanding your question correctly, MapServer will always give you your requested coordinate space inside of the requested image size, by buffering the image results along the axis that is larger than the coordinate window needs to draw completely. In other words, MapServer automatically pads the output image to fill in those areas, East/West and North/South edges based on the coordinate space requested. If you need them to match up exactly, then you need to do the computations in your application to make the correct requests and make the coordinate window ratio match the pixel window (image size) ratios. bobb On Oct 1, 2015, at 2:13 PM, Zach Chehayeb > wrote: Hello All, Can anyone explain or point me in the right direction on how mapserver logic works when a requested map extent cannot be produced at the requested resolution with square pixels? I am using mapserver in an application that requests mapserver to produce various map extents at various resolutions. The map config is set to not allow non square pixel (so the MS_NONSQUARE setting is set to no). The application currently assumes that the extent height should always be half of the width. Of course, with MS_NONSQUARE set to no and producing resolutions where the height is not always exactly half of the width, mapserver is unable to produce the exact extents requested. As such, mapserver compensates by extending either the north and south or east and west bounds of the map. See images in link below for a detailed illustration (the red box indicates the requested extent). For all images below, the requested extent is x1=-58.615527, y1=50.434875, x2=-13.615527, y2=72.934875, but the actual extents differ. From my observations, it seems that there are three cases. I have included a link below where a zip file that has examples of the cases can be downloaded. https://www.dropbox.com/s/dy1cgmt8lmbl3wf/Example%20Images.zip?dl=0 1. The requested resolution height is greater than half of the width (1280x720). a. Result: MapServer locks on the East and West bounds and extends the North and South bounds of the map. 2. The requested resolution height is less than half of the width (960x400). a. Result: MapServer locks on the North and South bounds and extends the East and West bounds. 3. The requested resolution height is half of the width (1000x500). a. Result: MapServer produces the image at the requested resolution. Is anyone able to confirm that these are the only three cases or correct my understanding (if there is more to it than I have described)? Some info about my installation: 1. MapServer version 6.0.3 OUTPUT=GIF OUTPUT=PNG OUTPUT=JPEG SUPPORTS=PROJ SUPPORTS=AGG SUPPORTS=FREETYPE SUPPORTS=ICONV SUPPORTS=FRIBIDI SUPPORTS=WMS_SERVER SUPPORTS=WMS_CLIENT SUPPORTS=WFS_SERVER SUPPORTS=WFS_CLIENT SUPPORTS=FASTCGI SUPPORTS=THREADS INPUT=OGR INPUT=GDAL INPUT=SHAPEFILE Please let me know if there is any other information needed. Thanks in advance, Zach Chehayeb Application Developer Email. zach.chehayeb at airborne.aero Tel No. +1 949 707 1800 www.airborne.aero _______________________________________________ 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 2443 bytes Desc: image001.gif URL: From Steve.Lime at state.mn.us Thu Oct 1 13:34:03 2015 From: Steve.Lime at state.mn.us (Lime, Steve D (MNIT)) Date: Thu, 1 Oct 2015 20:34:03 +0000 Subject: [mapserver-users] Understanding extents and resolutions In-Reply-To: <0dbd96985f6a46568c5449cb6a9aec03@DAGN04A-S1E7.exg7.exghost.local> References: <42693d31d0cf4b7d85f2c988e61cfd25@DAGN04A-S1E7.exg7.exghost.local> <79705E83-ABEF-4E8C-B7F3-5D822F79184C@ci.stpaul.mn.us> <0dbd96985f6a46568c5449cb6a9aec03@DAGN04A-S1E7.exg7.exghost.local> Message-ID: MapServer compares the requested extent to the aspect ratio of requested image. The code (msAdjustExtent in maputil.c) starts by computing a cellsize in each direction (x and y) and then uses the largest value to pad the other. You?re guaranteed to preserve the extent in one of the direction and maybe both. Steve From: mapserver-users-bounces at lists.osgeo.org [mailto:mapserver-users-bounces at lists.osgeo.org] On Behalf Of Zach Chehayeb Sent: Thursday, October 01, 2015 3:22 PM To: Basques, Bob (CI-StPaul) Cc: mapserver-users at lists.osgeo.org Subject: Re: [mapserver-users] Understanding extents and resolutions Bob, I am not sure I am understanding your response correctly. Are you suggesting that it is the coordinate window ratio that determines whether mapserver locks on the east/west or north/south bounds? If so, this doesn?t align with my observations below as all the images where sent the exact same coordinate window but pad on a different axis. I plan to do the computation to match up exactly as you have suggested but I want to be sure that I correctly understand the logic that mapserver uses to decide which axis to pad so I can apply the computations to the correct axis. I have to maintain backward compatibility in my application and need to accurately assess the actual extent drawn. Regards, Zach Chehayeb Application Developer Email. zach.chehayeb at airborne.aero Tel No. +1 949 707 1800 www.airborne.aero [New Small2] From: Basques, Bob (CI-StPaul) [mailto:bob.basques at ci.stpaul.mn.us] Sent: Thursday, October 01, 2015 12:29 PM To: Zach Chehayeb Cc: mapserver-users at lists.osgeo.org Subject: Re: [mapserver-users] Understanding extents and resolutions Zach, If I?m understanding your question correctly, MapServer will always give you your requested coordinate space inside of the requested image size, by buffering the image results along the axis that is larger than the coordinate window needs to draw completely. In other words, MapServer automatically pads the output image to fill in those areas, East/West and North/South edges based on the coordinate space requested. If you need them to match up exactly, then you need to do the computations in your application to make the correct requests and make the coordinate window ratio match the pixel window (image size) ratios. bobb On Oct 1, 2015, at 2:13 PM, Zach Chehayeb > wrote: Hello All, Can anyone explain or point me in the right direction on how mapserver logic works when a requested map extent cannot be produced at the requested resolution with square pixels? I am using mapserver in an application that requests mapserver to produce various map extents at various resolutions. The map config is set to not allow non square pixel (so the MS_NONSQUARE setting is set to no). The application currently assumes that the extent height should always be half of the width. Of course, with MS_NONSQUARE set to no and producing resolutions where the height is not always exactly half of the width, mapserver is unable to produce the exact extents requested. As such, mapserver compensates by extending either the north and south or east and west bounds of the map. See images in link below for a detailed illustration (the red box indicates the requested extent). For all images below, the requested extent is x1=-58.615527, y1=50.434875, x2=-13.615527, y2=72.934875, but the actual extents differ. From my observations, it seems that there are three cases. I have included a link below where a zip file that has examples of the cases can be downloaded. https://www.dropbox.com/s/dy1cgmt8lmbl3wf/Example%20Images.zip?dl=0 1. The requested resolution height is greater than half of the width (1280x720). a. Result: MapServer locks on the East and West bounds and extends the North and South bounds of the map. 2. The requested resolution height is less than half of the width (960x400). a. Result: MapServer locks on the North and South bounds and extends the East and West bounds. 3. The requested resolution height is half of the width (1000x500). a. Result: MapServer produces the image at the requested resolution. Is anyone able to confirm that these are the only three cases or correct my understanding (if there is more to it than I have described)? Some info about my installation: 1. MapServer version 6.0.3 OUTPUT=GIF OUTPUT=PNG OUTPUT=JPEG SUPPORTS=PROJ SUPPORTS=AGG SUPPORTS=FREETYPE SUPPORTS=ICONV SUPPORTS=FRIBIDI SUPPORTS=WMS_SERVER SUPPORTS=WMS_CLIENT SUPPORTS=WFS_SERVER SUPPORTS=WFS_CLIENT SUPPORTS=FASTCGI SUPPORTS=THREADS INPUT=OGR INPUT=GDAL INPUT=SHAPEFILE Please let me know if there is any other information needed. Thanks in advance, Zach Chehayeb Application Developer Email. zach.chehayeb at airborne.aero Tel No. +1 949 707 1800 www.airborne.aero _______________________________________________ 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 2443 bytes Desc: image001.gif URL: From klassen.js at gmail.com Thu Oct 1 13:58:33 2015 From: klassen.js at gmail.com (Jim Klassen) Date: Thu, 01 Oct 2015 15:58:33 -0500 Subject: [mapserver-users] Understanding extents and resolutions In-Reply-To: <0dbd96985f6a46568c5449cb6a9aec03@DAGN04A-S1E7.exg7.exghost.local> References: <42693d31d0cf4b7d85f2c988e61cfd25@DAGN04A-S1E7.exg7.exghost.local> <79705E83-ABEF-4E8C-B7F3-5D822F79184C@ci.stpaul.mn.us> <0dbd96985f6a46568c5449cb6a9aec03@DAGN04A-S1E7.exg7.exghost.local> Message-ID: <560D9E79.5040204@gmail.com> When MapServer forces square pixels, it does so with msAdjustExtent() in maputil.c:759 If MapServer tries to force square pixels depends on how it is called and how it is configured. For starters, see the MS_NONSQUARE configuration option. And if I remember correctly, MapServer doesn't force square pixels with WMS requests. On 10/01/2015 03:22 PM, Zach Chehayeb wrote: > Bob, > > I am not sure I am understanding your response correctly. Are you suggesting that it is the coordinate window ratio that determines whether mapserver locks on the east/west or north/south bounds? If so, this doesn?t align with my observations below as all the images where sent the exact same coordinate window but pad on a different axis. > > I plan to do the computation to match up exactly as you have suggested but I want to be sure that I correctly understand the logic that mapserver uses to decide which axis to pad so I can apply the computations to the correct axis. I have to maintain backward compatibility in my application and need to accurately assess the actual extent drawn. > > Regards, > > Zach Chehayeb > Application Developer > Email. zach.chehayeb at airborne.aero > Tel No. +1 949 707 1800 > www.airborne.aero > > [New Small2] > > > > From: Basques, Bob (CI-StPaul) [mailto:bob.basques at ci.stpaul.mn.us] > Sent: Thursday, October 01, 2015 12:29 PM > To: Zach Chehayeb > Cc: mapserver-users at lists.osgeo.org > Subject: Re: [mapserver-users] Understanding extents and resolutions > > Zach, > > If I?m understanding your question correctly, MapServer will always give you your requested coordinate space inside of the requested image size, by buffering the image results along the axis that is larger than the coordinate window needs to draw completely. In other words, MapServer automatically pads the output image to fill in those areas, East/West and North/South edges based on the coordinate space requested. > > If you need them to match up exactly, then you need to do the computations in your application to make the correct requests and make the coordinate window ratio match the pixel window (image size) ratios. > > bobb > > > > On Oct 1, 2015, at 2:13 PM, Zach Chehayeb > wrote: > > Hello All, > > Can anyone explain or point me in the right direction on how mapserver logic works when a requested map extent cannot be produced at the requested resolution with square pixels? > > I am using mapserver in an application that requests mapserver to produce various map extents at various resolutions. The map config is set to not allow non square pixel (so the MS_NONSQUARE setting is set to no). The application currently assumes that the extent height should always be half of the width. Of course, with MS_NONSQUARE set to no and producing resolutions where the height is not always exactly half of the width, mapserver is unable to produce the exact extents requested. As such, mapserver compensates by extending either the north and south or east and west bounds of the map. See images in link below for a detailed illustration (the red box indicates the requested extent). For all images below, the requested extent is x1=-58.615527, y1=50.434875, x2=-13.615527, y2=72.934875, but the actual extents differ. > > From my observations, it seems that there are three cases. I have included a link below where a zip file that has examples of the cases can be downloaded. > https://www.dropbox.com/s/dy1cgmt8lmbl3wf/Example%20Images.zip?dl=0 > 1. The requested resolution height is greater than half of the width (1280x720). > a. Result: MapServer locks on the East and West bounds and extends the North and South bounds of the map. > 2. The requested resolution height is less than half of the width (960x400). > a. Result: MapServer locks on the North and South bounds and extends the East and West bounds. > 3. The requested resolution height is half of the width (1000x500). > a. Result: MapServer produces the image at the requested resolution. > > Is anyone able to confirm that these are the only three cases or correct my understanding (if there is more to it than I have described)? > > Some info about my installation: > 1. MapServer version 6.0.3 OUTPUT=GIF OUTPUT=PNG OUTPUT=JPEG SUPPORTS=PROJ SUPPORTS=AGG SUPPORTS=FREETYPE SUPPORTS=ICONV SUPPORTS=FRIBIDI SUPPORTS=WMS_SERVER SUPPORTS=WMS_CLIENT SUPPORTS=WFS_SERVER SUPPORTS=WFS_CLIENT SUPPORTS=FASTCGI SUPPORTS=THREADS INPUT=OGR INPUT=GDAL INPUT=SHAPEFILE > > Please let me know if there is any other information needed. > > Thanks in advance, > > Zach Chehayeb > Application Developer > Email. zach.chehayeb at airborne.aero > Tel No. +1 949 707 1800 > www.airborne.aero > > > > > > > _______________________________________________ > 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 mwkorver at gmail.com Thu Oct 1 14:21:19 2015 From: mwkorver at gmail.com (Mark Korver) Date: Thu, 1 Oct 2015 14:21:19 -0700 Subject: [mapserver-users] Announcing the new MS4W In-Reply-To: References: Message-ID: First of all, very nice work on MS4W. Maybe the next time I give a demo for AWS, I will flip from my Ubuntu based instances running on EC2 to Windows. In the interest of getting more people access to all of this effort, especially new users, I am wondering how much interest there is out there in automated/scripted way to run Mapserver on AWS? Not just a Mapserver VM (AMI), but going further, trying to get to Jukka's point about getting it to 'just work'. Most of the work I am doing has to do with imagery or LiDAR, so I am thinking along the lines of once you get it up and running you can do something like load a new set of geotiffs in S3 and then underlying event driven process would add that to the vrt or shapefile index and it would just show up on the next WMS query. Something like WFS or WMS/WMTS request -- CloudFront (CDN) -- ELB (Load Balancer) - Autoscale Group of Mapservers -- pointed at PostGIS (running on our managed db service RDS) and S3 for geotiffs. The demo S3 bucket could hold any amount of open data shared across n # of demo deployments/accounts. The Postgres db could contain OSM, with some mechanism to keep it updated once a day. This would be the kind of data that would NOT fit on a USB stick. Nothing really new here in this idea. In fact here is deck Matt Walker put together back in 2012 that illustrates some of this. https://speakerdeck.com/walkermatt/building-a-national-tile-server If I were to add a point here, it would just be that we are now at a point where anybody should be able to deploy a national map server in minutes, mainly because you don't have the ETL bottleneck around data and you can use devops techniques to make standing up complex stuff a lot easier. However, all that is not so useful unless it is easy to get your own data working. -Mark On Sat, Sep 26, 2015 at 1:04 AM, Rahkonen Jukka (MML) < jukka.rahkonen at maanmittauslaitos.fi> wrote: > Hi, > > The add-ons are great work. However, my point is that without doing any > additional installations the best that a new Mapserver user can achieve is > "No query information to decode. QUERY_STRING is set, but empty." while > everybody who has installed Geoserver can read WMS GetCapabilities from > http://localhost :8080 and either add the service to any WMS or play with > the demo viewer: > > http://demo.opengeo.org/geoserver/topp/wms?service=WMS&version=1.1.0&request=GetMap&layers=topp:states&styles=&bbox=-124.73142200000001,24.955967,-66.969849,49.371735&width=780&height=330&srs=EPSG:4326&format=application/openlayers > > I still think that the best marketing we could do for Mapserver would be > to offer an immediate out-of-box experience for Mapserver users on any > platform "Hey, it makes maps! " > > > -Jukka Rahkonen- > > Jeff McKenna wrote: > > > Hi Jukka, > > > Speaking of that, I spent a considerable amount of time for this release > setting up the MS4W add-ons for this version (MapServer 7). Actually this > does handle the needs you mention. Such as OGC: well there is an MS4W > add-on named "MapServer OGC Workshop" that contains so many links to > services and working mapfiles (all working for MapServer 7). Need full > applications working with MapServer 7? : well there is GeoMOOSE (latest > release) or Mapbender (latest release), all ready for you to use with > MS4W. Looking for the original (as in Steve Lime's CGI demo), it works now > with MapServer 7 even, as an MS4W add-on, named "MapServer Itasca Demo > Application". :) > > In total there is over 500 MB of working mapfiles, data, applications > ready to get you going. > > Give them a try: http://www.ms4w.com/download.html > > See you on the new MS4W list. > > -jeff > > > > -- > Jeff McKenna > MapServer Consulting and Training Services > http://www.gatewaygeomatics.com/ > > On 2015-09-23 11:39 AM, Rahkonen Jukka (MML) wrote: > > Hi Jeff, > > > > That will be great. I am sure that Mapserver has frightened away > thousands of new users because it is so difficult to make the very first > map. Just compare it with Geoserver that comes with the data_dir and fine > collection of readymade demo services and layers. It is not so easy to make > Mapserver demos which would work out-of-the box on both Windows and Linux, > but making it to work in MS4W will be a good start. > > > > -Jukka- > > > > > > > > -----Alkuper?inen viesti----- > > L?hett?j?: Jeff McKenna [mailto:jmckenna at gatewaygeomatics.com] > > L?hetetty: 23. syyskuuta 2015 4:18 > > Vastaanottaja: Rahkonen Jukka (MML) > > Aihe: Re: [mapserver-users] Announcing the new MS4W > > > > Hi Jukka, > > > > Great idea, actually I have something ready from a workshop that can > > be used. Will add it with the upcoming GDAL 2.0.1 > > > > -jeff > > > > > > > > On 2015-09-22 10:40 AM, Rahkonen Jukka (MML) wrote: > >> Hi Jeff, > >> > >> I believe that MapServer should offer an immediate "It works" > experience for new users. Could you consider to include some demo data and > mapfiles into the standard delivery of MS4W? They could be placed for > example into \apps\demo. Once they are there we could have WMS GetMap > links with &FORMAT=image/png and &FORMAT=application/openlayers on a > visible place of the html page that opens from http://localhost. Or the > OpenLayers map could even be included on the start page by default. > >> > >> If you think it is a good idea I can make some first few mapfiles on > top of Natural Earth countries. It seems to mean about 5 MB extra as zipped > but I do believe that it would be worth it. I could start with these: > >> > >> - Hello world WMS - simple but still complete with enough WMS metadata, > and naturally debug and ms_errorfile. > >> - WMS with some styling > >> - WMS with labels > >> - WMS with GetFeatureInfo > >> - WFS > >> > >> I could also write a short document about how to get the first map with > shp2img, browser, and with a few GIS program. > >> > >> Regards, > >> > >> -Jukka Rahkonen- > >> > >> > >> Jeff McKenna wrote: Announcing the new MS4W > >> > >>> Hi everyone! > >> > >>> Just in time for FOSS4G-Seoul, I'm very proud to announce the new > MS4W[1] MS4W is thriving, as you can see by its long history[2] of > releases, and the last few months has seen a lot of development. Much > thanks goes to Tanya Haddad for her support for this release, it has been > quite an effort updating the full stack (the number of libraries updated > and added is large as you see in the recent history). > >> > >>> You'll also note that there has been releases happening, we just > needed a new home for people to find them. It's quite exciting to live at > ms4w.com now, and you'll also notice that we have been using a new > tracker[3] which has been working well (please feel free to use it). > >> > >> You may also notice that releases now have a Roadmap[4], every 3 months > with dated milestones, and you can follow along the exact changes coming > through the tracker link on that page. > >> > >> This 3.1.0 release has some tasty features, including optimized > >> Apache 2.4, MapServer 7.0, PHP 5.4.45, all mapscripts, Oracle > >> support, MapCache > >> 1.4.0 (with GDAL support), TinyOWS 1.1.1, spatialite/OSM utilities, and > many many more goodies. New users might like to start at the features[5] > page to review. > >> > >> Finally we have moved to a new mailing list (I haven't been able to > >> post to my own old MS4W mailing list for almost 2 years now): please > >> join, as all releases will be announced and support given through the > >> new MS4W list[6] So, I'll cya there! :) > >> > >> Thanks so much everyone, I am quite excited. > >> > >> [1] http://www.ms4w.com/ > >> [2] http://www.ms4w.com/HISTORY.html > >> [3] http://www.ms4w.com/trac/ > >> [4] http://www.ms4w.com/roadmap.html > >> [5] http://www.ms4w.com/features.html [6] > >> http://lists.ms4w.com/cgi-bin/mailman/listinfo/ms4w-users > >> > >> -jeff > >> > >> > > > > _______________________________________________ > 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 mafonso333 at gmail.com Thu Oct 1 14:54:12 2015 From: mafonso333 at gmail.com (Marco Afonso) Date: Thu, 1 Oct 2015 22:54:12 +0100 Subject: [mapserver-users] Announcing the new MS4W In-Reply-To: References: Message-ID: Congratulations to all the people that have been working hard for this MS4W release. We (local council) have been using MS4W since MS 5.6. We cant just thank enough. Keep up the terrific work. Cheers, Marco Em 01/10/2015 22:21, "Mark Korver" escreveu: > First of all, very nice work on MS4W. Maybe the next time I give a demo > for AWS, I will flip from my Ubuntu based instances running on EC2 to > Windows. > In the interest of getting more people access to all of this effort, > especially new users, I am wondering how much interest there is out there > in automated/scripted way to run Mapserver on AWS? Not just a Mapserver VM > (AMI), but going further, trying to get to Jukka's point about getting it > to 'just work'. Most of the work I am doing has to do with imagery or > LiDAR, so I am thinking along the lines of once you get it up and running > you can do something like load a new set of geotiffs in S3 and then > underlying event driven process would add that to the vrt or shapefile > index and it would just show up on the next WMS query. > Something like > > WFS or WMS/WMTS request -- CloudFront (CDN) -- ELB (Load Balancer) - > Autoscale Group of Mapservers -- > pointed at PostGIS (running on our managed db service RDS) and S3 for > geotiffs. > > The demo S3 bucket could hold any amount of open data shared across n # > of demo deployments/accounts. > The Postgres db could contain OSM, with some mechanism to keep it updated > once a day. > This would be the kind of data that would NOT fit on a USB stick. > > Nothing really new here in this idea. In fact here is deck Matt Walker put > together back in 2012 that illustrates some of this. > https://speakerdeck.com/walkermatt/building-a-national-tile-server > If I were to add a point here, it would just be that we are now at a point > where anybody should be able to deploy a national map server in minutes, > mainly because you don't have the ETL bottleneck around data and you can > use devops techniques to make standing up complex stuff a lot easier. > However, all that is not so useful unless it is easy to get your own data > working. > -Mark > > > On Sat, Sep 26, 2015 at 1:04 AM, Rahkonen Jukka (MML) < > jukka.rahkonen at maanmittauslaitos.fi> wrote: > >> Hi, >> >> The add-ons are great work. However, my point is that without doing any >> additional installations the best that a new Mapserver user can achieve is >> "No query information to decode. QUERY_STRING is set, but empty." while >> everybody who has installed Geoserver can read WMS GetCapabilities from >> http://localhost :8080 and either add the service to any WMS or play >> with the demo viewer: >> >> http://demo.opengeo.org/geoserver/topp/wms?service=WMS&version=1.1.0&request=GetMap&layers=topp:states&styles=&bbox=-124.73142200000001,24.955967,-66.969849,49.371735&width=780&height=330&srs=EPSG:4326&format=application/openlayers >> >> I still think that the best marketing we could do for Mapserver would be >> to offer an immediate out-of-box experience for Mapserver users on any >> platform "Hey, it makes maps! " >> >> >> -Jukka Rahkonen- >> >> Jeff McKenna wrote: >> >> > Hi Jukka, >> >> > Speaking of that, I spent a considerable amount of time for this >> release setting up the MS4W add-ons for this version (MapServer 7). >> Actually this does handle the needs you mention. Such as OGC: well there >> is an MS4W add-on named "MapServer OGC Workshop" that contains so many >> links to services and working mapfiles (all working for MapServer 7). Need >> full applications working with MapServer 7? : well there is GeoMOOSE >> (latest release) or Mapbender (latest release), all ready for you to use >> with MS4W. Looking for the original (as in Steve Lime's CGI demo), it >> works now with MapServer 7 even, as an MS4W add-on, named "MapServer Itasca >> Demo Application". :) >> >> In total there is over 500 MB of working mapfiles, data, applications >> ready to get you going. >> >> Give them a try: http://www.ms4w.com/download.html >> >> See you on the new MS4W list. >> >> -jeff >> >> >> >> -- >> Jeff McKenna >> MapServer Consulting and Training Services >> http://www.gatewaygeomatics.com/ >> >> On 2015-09-23 11:39 AM, Rahkonen Jukka (MML) wrote: >> > Hi Jeff, >> > >> > That will be great. I am sure that Mapserver has frightened away >> thousands of new users because it is so difficult to make the very first >> map. Just compare it with Geoserver that comes with the data_dir and fine >> collection of readymade demo services and layers. It is not so easy to make >> Mapserver demos which would work out-of-the box on both Windows and Linux, >> but making it to work in MS4W will be a good start. >> > >> > -Jukka- >> > >> > >> > >> > -----Alkuper?inen viesti----- >> > L?hett?j?: Jeff McKenna [mailto:jmckenna at gatewaygeomatics.com] >> > L?hetetty: 23. syyskuuta 2015 4:18 >> > Vastaanottaja: Rahkonen Jukka (MML) >> > Aihe: Re: [mapserver-users] Announcing the new MS4W >> > >> > Hi Jukka, >> > >> > Great idea, actually I have something ready from a workshop that can >> > be used. Will add it with the upcoming GDAL 2.0.1 >> > >> > -jeff >> > >> > >> > >> > On 2015-09-22 10:40 AM, Rahkonen Jukka (MML) wrote: >> >> Hi Jeff, >> >> >> >> I believe that MapServer should offer an immediate "It works" >> experience for new users. Could you consider to include some demo data and >> mapfiles into the standard delivery of MS4W? They could be placed for >> example into \apps\demo. Once they are there we could have WMS GetMap >> links with &FORMAT=image/png and &FORMAT=application/openlayers on a >> visible place of the html page that opens from http://localhost. Or the >> OpenLayers map could even be included on the start page by default. >> >> >> >> If you think it is a good idea I can make some first few mapfiles on >> top of Natural Earth countries. It seems to mean about 5 MB extra as zipped >> but I do believe that it would be worth it. I could start with these: >> >> >> >> - Hello world WMS - simple but still complete with enough WMS >> metadata, and naturally debug and ms_errorfile. >> >> - WMS with some styling >> >> - WMS with labels >> >> - WMS with GetFeatureInfo >> >> - WFS >> >> >> >> I could also write a short document about how to get the first map >> with shp2img, browser, and with a few GIS program. >> >> >> >> Regards, >> >> >> >> -Jukka Rahkonen- >> >> >> >> >> >> Jeff McKenna wrote: Announcing the new MS4W >> >> >> >>> Hi everyone! >> >> >> >>> Just in time for FOSS4G-Seoul, I'm very proud to announce the new >> MS4W[1] MS4W is thriving, as you can see by its long history[2] of >> releases, and the last few months has seen a lot of development. Much >> thanks goes to Tanya Haddad for her support for this release, it has been >> quite an effort updating the full stack (the number of libraries updated >> and added is large as you see in the recent history). >> >> >> >>> You'll also note that there has been releases happening, we just >> needed a new home for people to find them. It's quite exciting to live at >> ms4w.com now, and you'll also notice that we have been using a new >> tracker[3] which has been working well (please feel free to use it). >> >> >> >> You may also notice that releases now have a Roadmap[4], every 3 >> months with dated milestones, and you can follow along the exact changes >> coming through the tracker link on that page. >> >> >> >> This 3.1.0 release has some tasty features, including optimized >> >> Apache 2.4, MapServer 7.0, PHP 5.4.45, all mapscripts, Oracle >> >> support, MapCache >> >> 1.4.0 (with GDAL support), TinyOWS 1.1.1, spatialite/OSM utilities, >> and many many more goodies. New users might like to start at the >> features[5] page to review. >> >> >> >> Finally we have moved to a new mailing list (I haven't been able to >> >> post to my own old MS4W mailing list for almost 2 years now): please >> >> join, as all releases will be announced and support given through the >> >> new MS4W list[6] So, I'll cya there! :) >> >> >> >> Thanks so much everyone, I am quite excited. >> >> >> >> [1] http://www.ms4w.com/ >> >> [2] http://www.ms4w.com/HISTORY.html >> >> [3] http://www.ms4w.com/trac/ >> >> [4] http://www.ms4w.com/roadmap.html >> >> [5] http://www.ms4w.com/features.html [6] >> >> http://lists.ms4w.com/cgi-bin/mailman/listinfo/ms4w-users >> >> >> >> -jeff >> >> >> >> >> > >> >> _______________________________________________ >> 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 >> > > > _______________________________________________ > 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 bob.basques at ci.stpaul.mn.us Thu Oct 1 13:36:47 2015 From: bob.basques at ci.stpaul.mn.us (Basques, Bob (CI-StPaul)) Date: Thu, 1 Oct 2015 20:36:47 +0000 Subject: [mapserver-users] Understanding extents and resolutions In-Reply-To: References: <42693d31d0cf4b7d85f2c988e61cfd25@DAGN04A-S1E7.exg7.exghost.local> <79705E83-ABEF-4E8C-B7F3-5D822F79184C@ci.stpaul.mn.us> <0dbd96985f6a46568c5449cb6a9aec03@DAGN04A-S1E7.exg7.exghost.local> Message-ID: All, Yeah, I just figured it out for myself too. My tests were against a WMS call to MapServer vs a MapServer direct call. The MapServer call will do the padding, but a WMS will stretch ( as it?s supposed to) bobb On Oct 1, 2015, at 3:34 PM, Lime, Steve D (MNIT) > wrote: MapServer compares the requested extent to the aspect ratio of requested image. The code (msAdjustExtent in maputil.c) starts by computing a cellsize in each direction (x and y) and then uses the largest value to pad the other. You?re guaranteed to preserve the extent in one of the direction and maybe both. Steve From: mapserver-users-bounces at lists.osgeo.org [mailto:mapserver-users-bounces at lists.osgeo.org] On Behalf Of Zach Chehayeb Sent: Thursday, October 01, 2015 3:22 PM To: Basques, Bob (CI-StPaul) > Cc: mapserver-users at lists.osgeo.org Subject: Re: [mapserver-users] Understanding extents and resolutions Bob, I am not sure I am understanding your response correctly. Are you suggesting that it is the coordinate window ratio that determines whether mapserver locks on the east/west or north/south bounds? If so, this doesn?t align with my observations below as all the images where sent the exact same coordinate window but pad on a different axis. I plan to do the computation to match up exactly as you have suggested but I want to be sure that I correctly understand the logic that mapserver uses to decide which axis to pad so I can apply the computations to the correct axis. I have to maintain backward compatibility in my application and need to accurately assess the actual extent drawn. Regards, Zach Chehayeb Application Developer Email. zach.chehayeb at airborne.aero Tel No. +1 949 707 1800 www.airborne.aero From: Basques, Bob (CI-StPaul) [mailto:bob.basques at ci.stpaul.mn.us] Sent: Thursday, October 01, 2015 12:29 PM To: Zach Chehayeb Cc: mapserver-users at lists.osgeo.org Subject: Re: [mapserver-users] Understanding extents and resolutions Zach, If I?m understanding your question correctly, MapServer will always give you your requested coordinate space inside of the requested image size, by buffering the image results along the axis that is larger than the coordinate window needs to draw completely. In other words, MapServer automatically pads the output image to fill in those areas, East/West and North/South edges based on the coordinate space requested. If you need them to match up exactly, then you need to do the computations in your application to make the correct requests and make the coordinate window ratio match the pixel window (image size) ratios. bobb On Oct 1, 2015, at 2:13 PM, Zach Chehayeb > wrote: Hello All, Can anyone explain or point me in the right direction on how mapserver logic works when a requested map extent cannot be produced at the requested resolution with square pixels? I am using mapserver in an application that requests mapserver to produce various map extents at various resolutions. The map config is set to not allow non square pixel (so the MS_NONSQUARE setting is set to no). The application currently assumes that the extent height should always be half of the width. Of course, with MS_NONSQUARE set to no and producing resolutions where the height is not always exactly half of the width, mapserver is unable to produce the exact extents requested. As such, mapserver compensates by extending either the north and south or east and west bounds of the map. See images in link below for a detailed illustration (the red box indicates the requested extent). For all images below, the requested extent is x1=-58.615527, y1=50.434875, x2=-13.615527, y2=72.934875, but the actual extents differ. From my observations, it seems that there are three cases. I have included a link below where a zip file that has examples of the cases can be downloaded. https://www.dropbox.com/s/dy1cgmt8lmbl3wf/Example%20Images.zip?dl=0 1. The requested resolution height is greater than half of the width (1280x720). a. Result: MapServer locks on the East and West bounds and extends the North and South bounds of the map. 2. The requested resolution height is less than half of the width (960x400). a. Result: MapServer locks on the North and South bounds and extends the East and West bounds. 3. The requested resolution height is half of the width (1000x500). a. Result: MapServer produces the image at the requested resolution. Is anyone able to confirm that these are the only three cases or correct my understanding (if there is more to it than I have described)? Some info about my installation: 1. MapServer version 6.0.3 OUTPUT=GIF OUTPUT=PNG OUTPUT=JPEG SUPPORTS=PROJ SUPPORTS=AGG SUPPORTS=FREETYPE SUPPORTS=ICONV SUPPORTS=FRIBIDI SUPPORTS=WMS_SERVER SUPPORTS=WMS_CLIENT SUPPORTS=WFS_SERVER SUPPORTS=WFS_CLIENT SUPPORTS=FASTCGI SUPPORTS=THREADS INPUT=OGR INPUT=GDAL INPUT=SHAPEFILE Please let me know if there is any other information needed. Thanks in advance, Zach Chehayeb Application Developer Email. zach.chehayeb at airborne.aero Tel No. +1 949 707 1800 www.airborne.aero _______________________________________________ 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 zach.chehayeb at airborne.aero Thu Oct 1 15:01:09 2015 From: zach.chehayeb at airborne.aero (Zach Chehayeb) Date: Thu, 1 Oct 2015 22:01:09 +0000 Subject: [mapserver-users] Understanding extents and resolutions In-Reply-To: References: <42693d31d0cf4b7d85f2c988e61cfd25@DAGN04A-S1E7.exg7.exghost.local> <79705E83-ABEF-4E8C-B7F3-5D822F79184C@ci.stpaul.mn.us> <0dbd96985f6a46568c5449cb6a9aec03@DAGN04A-S1E7.exg7.exghost.local> Message-ID: <1b4c731f63a14194be1c1cd30a28c5d0@DAGN04A-S1E7.exg7.exghost.local> Thank you both for you responses! What you have described below does align with my observations. I will reply if I should notice any inconsistencies after examining the code you pointed out Steve. Thanks again, Zach From: Basques, Bob (CI-StPaul) [mailto:bob.basques at ci.stpaul.mn.us] Sent: Thursday, October 01, 2015 1:37 PM To: Lime, Steve D (MNIT) Cc: Zach Chehayeb; mapserver-users at lists.osgeo.org Subject: Re: [mapserver-users] Understanding extents and resolutions All, Yeah, I just figured it out for myself too. My tests were against a WMS call to MapServer vs a MapServer direct call. The MapServer call will do the padding, but a WMS will stretch ( as it?s supposed to) bobb On Oct 1, 2015, at 3:34 PM, Lime, Steve D (MNIT) > wrote: MapServer compares the requested extent to the aspect ratio of requested image. The code (msAdjustExtent in maputil.c) starts by computing a cellsize in each direction (x and y) and then uses the largest value to pad the other. You?re guaranteed to preserve the extent in one of the direction and maybe both. Steve From: mapserver-users-bounces at lists.osgeo.org [mailto:mapserver-users-bounces at lists.osgeo.org] On Behalf Of Zach Chehayeb Sent: Thursday, October 01, 2015 3:22 PM To: Basques, Bob (CI-StPaul) > Cc: mapserver-users at lists.osgeo.org Subject: Re: [mapserver-users] Understanding extents and resolutions Bob, I am not sure I am understanding your response correctly. Are you suggesting that it is the coordinate window ratio that determines whether mapserver locks on the east/west or north/south bounds? If so, this doesn?t align with my observations below as all the images where sent the exact same coordinate window but pad on a different axis. I plan to do the computation to match up exactly as you have suggested but I want to be sure that I correctly understand the logic that mapserver uses to decide which axis to pad so I can apply the computations to the correct axis. I have to maintain backward compatibility in my application and need to accurately assess the actual extent drawn. Regards, Zach Chehayeb Application Developer Email. zach.chehayeb at airborne.aero Tel No. +1 949 707 1800 www.airborne.aero From: Basques, Bob (CI-StPaul) [mailto:bob.basques at ci.stpaul.mn.us] Sent: Thursday, October 01, 2015 12:29 PM To: Zach Chehayeb Cc: mapserver-users at lists.osgeo.org Subject: Re: [mapserver-users] Understanding extents and resolutions Zach, If I?m understanding your question correctly, MapServer will always give you your requested coordinate space inside of the requested image size, by buffering the image results along the axis that is larger than the coordinate window needs to draw completely. In other words, MapServer automatically pads the output image to fill in those areas, East/West and North/South edges based on the coordinate space requested. If you need them to match up exactly, then you need to do the computations in your application to make the correct requests and make the coordinate window ratio match the pixel window (image size) ratios. bobb On Oct 1, 2015, at 2:13 PM, Zach Chehayeb > wrote: Hello All, Can anyone explain or point me in the right direction on how mapserver logic works when a requested map extent cannot be produced at the requested resolution with square pixels? I am using mapserver in an application that requests mapserver to produce various map extents at various resolutions. The map config is set to not allow non square pixel (so the MS_NONSQUARE setting is set to no). The application currently assumes that the extent height should always be half of the width. Of course, with MS_NONSQUARE set to no and producing resolutions where the height is not always exactly half of the width, mapserver is unable to produce the exact extents requested. As such, mapserver compensates by extending either the north and south or east and west bounds of the map. See images in link below for a detailed illustration (the red box indicates the requested extent). For all images below, the requested extent is x1=-58.615527, y1=50.434875, x2=-13.615527, y2=72.934875, but the actual extents differ. From my observations, it seems that there are three cases. I have included a link below where a zip file that has examples of the cases can be downloaded. https://www.dropbox.com/s/dy1cgmt8lmbl3wf/Example%20Images.zip?dl=0 1. The requested resolution height is greater than half of the width (1280x720). a. Result: MapServer locks on the East and West bounds and extends the North and South bounds of the map. 2. The requested resolution height is less than half of the width (960x400). a. Result: MapServer locks on the North and South bounds and extends the East and West bounds. 3. The requested resolution height is half of the width (1000x500). a. Result: MapServer produces the image at the requested resolution. Is anyone able to confirm that these are the only three cases or correct my understanding (if there is more to it than I have described)? Some info about my installation: 1. MapServer version 6.0.3 OUTPUT=GIF OUTPUT=PNG OUTPUT=JPEG SUPPORTS=PROJ SUPPORTS=AGG SUPPORTS=FREETYPE SUPPORTS=ICONV SUPPORTS=FRIBIDI SUPPORTS=WMS_SERVER SUPPORTS=WMS_CLIENT SUPPORTS=WFS_SERVER SUPPORTS=WFS_CLIENT SUPPORTS=FASTCGI SUPPORTS=THREADS INPUT=OGR INPUT=GDAL INPUT=SHAPEFILE Please let me know if there is any other information needed. Thanks in advance, Zach Chehayeb Application Developer Email. zach.chehayeb at airborne.aero Tel No. +1 949 707 1800 www.airborne.aero _______________________________________________ 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 thomas.bonfort at gmail.com Fri Oct 2 02:36:03 2015 From: thomas.bonfort at gmail.com (thomas bonfort) Date: Fri, 2 Oct 2015 11:36:03 +0200 Subject: [mapserver-users] RFC113 Chainable Compositing Filters Message-ID: Hi All, I have finished implementing the chainable compositing filters that were architectured along with RFC113, and the code has been committed to the master branch. The aim of the development is essentially to enable soft shadow and blurring effects, although other usages can exist or could be added in the future. To obtain a soft shadow effect that can be seen for example around the buildings on http://sitn.ne.ch/production/wsgi/mobile/?theme=mobile_default&baselayer_ref=plan_ville&map_x=554942.49763489&map_y=200242.9936142&map_zoom=6&tree_layers= you can use LAYER NAME "buildings" TYPE POLYGON COMPOSITE #create the shadow/blur effect by translating a blurred version of the layer COMPFILTER "grayscale()" COMPFILTER "translate(5,5)" COMPFILTER "blur(4)" OPACITY 50 END COMPOSITE #and render the buildings themselves OPACITY 100 END CLASS STYLE COLOR 128 128 128 OUTLINECOLOR 0 0 0 WIDTH 1 END END END The currently available filters are: - "blur(integer)" - "translate(integer,integer)" - "grayscale()" - "blacken()" - "whiten()" I'll add some documentation and autotests next week. best regards, Thomas From Steve.Lime at state.mn.us Fri Oct 2 09:18:01 2015 From: Steve.Lime at state.mn.us (Lime, Steve D (MNIT)) Date: Fri, 2 Oct 2015 16:18:01 +0000 Subject: [mapserver-users] [mapserver-dev] RFC113 Chainable Compositing Filters In-Reply-To: References: Message-ID: Beautiful maps... How'd you do the inside shading on the water bodies? Can these be applied to labels? --Steve -----Original Message----- From: mapserver-dev-bounces at lists.osgeo.org [mailto:mapserver-dev-bounces at lists.osgeo.org] On Behalf Of thomas bonfort Sent: Friday, October 02, 2015 4:36 AM To: MapServer Dev Mailing List ; MapserverList OSGEO Subject: [mapserver-dev] RFC113 Chainable Compositing Filters Hi All, I have finished implementing the chainable compositing filters that were architectured along with RFC113, and the code has been committed to the master branch. The aim of the development is essentially to enable soft shadow and blurring effects, although other usages can exist or could be added in the future. To obtain a soft shadow effect that can be seen for example around the buildings on http://sitn.ne.ch/production/wsgi/mobile/?theme=mobile_default&baselayer_ref=plan_ville&map_x=554942.49763489&map_y=200242.9936142&map_zoom=6&tree_layers= you can use LAYER NAME "buildings" TYPE POLYGON COMPOSITE #create the shadow/blur effect by translating a blurred version of the layer COMPFILTER "grayscale()" COMPFILTER "translate(5,5)" COMPFILTER "blur(4)" OPACITY 50 END COMPOSITE #and render the buildings themselves OPACITY 100 END CLASS STYLE COLOR 128 128 128 OUTLINECOLOR 0 0 0 WIDTH 1 END END END The currently available filters are: - "blur(integer)" - "translate(integer,integer)" - "grayscale()" - "blacken()" - "whiten()" I'll add some documentation and autotests next week. best regards, Thomas _______________________________________________ mapserver-dev mailing list mapserver-dev at lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-dev From David.Fawcett at state.mn.us Mon Oct 5 06:53:45 2015 From: David.Fawcett at state.mn.us (Fawcett, David (MNIT)) Date: Mon, 5 Oct 2015 13:53:45 +0000 Subject: [mapserver-users] [mapserver-dev] RFC113 Chainable Compositing Filters In-Reply-To: References: Message-ID: Like Steve said, beautiful maps. Awesome work Thomas! -----Original Message----- From: mapserver-users-bounces at lists.osgeo.org [mailto:mapserver-users-bounces at lists.osgeo.org] On Behalf Of Lime, Steve D (MNIT) Sent: Friday, October 02, 2015 11:18 AM To: thomas bonfort; MapServer Dev Mailing List; MapserverList OSGEO Subject: Re: [mapserver-users] [mapserver-dev] RFC113 Chainable Compositing Filters Beautiful maps... How'd you do the inside shading on the water bodies? Can these be applied to labels? --Steve -----Original Message----- From: mapserver-dev-bounces at lists.osgeo.org [mailto:mapserver-dev-bounces at lists.osgeo.org] On Behalf Of thomas bonfort Sent: Friday, October 02, 2015 4:36 AM To: MapServer Dev Mailing List ; MapserverList OSGEO Subject: [mapserver-dev] RFC113 Chainable Compositing Filters Hi All, I have finished implementing the chainable compositing filters that were architectured along with RFC113, and the code has been committed to the master branch. The aim of the development is essentially to enable soft shadow and blurring effects, although other usages can exist or could be added in the future. To obtain a soft shadow effect that can be seen for example around the buildings on http://sitn.ne.ch/production/wsgi/mobile/?theme=mobile_default&baselayer_ref=plan_ville&map_x=554942.49763489&map_y=200242.9936142&map_zoom=6&tree_layers= you can use LAYER NAME "buildings" TYPE POLYGON COMPOSITE #create the shadow/blur effect by translating a blurred version of the layer COMPFILTER "grayscale()" COMPFILTER "translate(5,5)" COMPFILTER "blur(4)" OPACITY 50 END COMPOSITE #and render the buildings themselves OPACITY 100 END CLASS STYLE COLOR 128 128 128 OUTLINECOLOR 0 0 0 WIDTH 1 END END END The currently available filters are: - "blur(integer)" - "translate(integer,integer)" - "grayscale()" - "blacken()" - "whiten()" I'll add some documentation and autotests next week. best regards, Thomas _______________________________________________ mapserver-dev mailing list mapserver-dev at lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-dev _______________________________________________ mapserver-users mailing list mapserver-users at lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users From thomas.bonfort at gmail.com Tue Oct 6 01:41:06 2015 From: thomas.bonfort at gmail.com (thomas bonfort) Date: Tue, 6 Oct 2015 10:41:06 +0200 Subject: [mapserver-users] [mapserver-dev] RFC113 Chainable Compositing Filters In-Reply-To: References: Message-ID: All credit for those beautiful maps go to the http://sitn.ne.ch/ team, I didn't have a play in them. I've cc'd Marc who might be able to share more details as to what he was using exactly (note that those maps predate the actual filter chaining implementation, and used a hack present in 7.0 along with drawing the shaded layers twice). For the water bodies, I suspect it can be done with: COMPOSITE #first we render normal water color END COMPOSITE COMPFILTER "whiten()" COMPFILTER "blur(5)" COMPOP "soft-light" OPACITY 50 END CLASS STYLE COLOR water-color END END At present filters are not supported on labels (unless they don't go through the labelcache). They could be supported in the longer run if we explicitely had a "labelcache" layer that we could draw into and that we could therefore plug into the compositing chain. regards, thomas On 2 October 2015 at 18:18, Lime, Steve D (MNIT) wrote: > Beautiful maps... How'd you do the inside shading on the water bodies? Can these be applied to labels? --Steve > > -----Original Message----- > From: mapserver-dev-bounces at lists.osgeo.org [mailto:mapserver-dev-bounces at lists.osgeo.org] On Behalf Of thomas bonfort > Sent: Friday, October 02, 2015 4:36 AM > To: MapServer Dev Mailing List ; MapserverList OSGEO > Subject: [mapserver-dev] RFC113 Chainable Compositing Filters > > Hi All, > > I have finished implementing the chainable compositing filters that > were architectured along with RFC113, and the code has been committed > to the master branch. The aim of the development is essentially to > enable soft shadow and blurring effects, although other usages can > exist or could be added in the future. > To obtain a soft shadow effect that can be seen for example around the > buildings on http://sitn.ne.ch/production/wsgi/mobile/?theme=mobile_default&baselayer_ref=plan_ville&map_x=554942.49763489&map_y=200242.9936142&map_zoom=6&tree_layers= > you can use > > LAYER > NAME "buildings" > TYPE POLYGON > COMPOSITE > #create the shadow/blur effect by translating a blurred version of the layer > COMPFILTER "grayscale()" > COMPFILTER "translate(5,5)" > COMPFILTER "blur(4)" > OPACITY 50 > END > COMPOSITE > #and render the buildings themselves > OPACITY 100 > END > CLASS > STYLE > COLOR 128 128 128 > OUTLINECOLOR 0 0 0 > WIDTH 1 > END > END > END > > The currently available filters are: > - "blur(integer)" > - "translate(integer,integer)" > - "grayscale()" > - "blacken()" > - "whiten()" > > I'll add some documentation and autotests next week. > > best regards, > Thomas > _______________________________________________ > mapserver-dev mailing list > mapserver-dev at lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/mapserver-dev From Steve.Lime at state.mn.us Tue Oct 6 08:26:51 2015 From: Steve.Lime at state.mn.us (Lime, Steve D (MNIT)) Date: Tue, 6 Oct 2015 15:26:51 +0000 Subject: [mapserver-users] [mapserver-dev] RFC113 Chainable Compositing Filters In-Reply-To: References: Message-ID: Hi Marc: Thanks for the snippet - always easier when you see practical examples. Again, your maps are great. The detail is insane - line-work in the sporting facilities, boats in the harbor and the trees... wow. No cars on the roads but I'm sure it's just a matter of time! Steve -----Original Message----- From: Riedo Marc [mailto:Marc.Riedo at ne.ch] Sent: Tuesday, October 06, 2015 3:57 AM To: thomas bonfort ; Lime, Steve D (MNIT) Cc: MapServer Dev Mailing List ; MapserverList OSGEO ; Kalbermatten Micha?l Subject: RE: [mapserver-dev] RFC113 Chainable Compositing Filters Hi Thomas, Hi Steeve, Thanks for your nice comments on our maps ... and thanks for the great implementation of the new filters that will help us to improve our cartography. We are great fans of mapserver here at SITN. In the current version http://sitn.ne.ch/production/wsgi/short/oyno9 we use the 7.0 hack. We will use the new possibilities developed by Thomas asap. Here is an example for the lakes LAYER NAME "lakes_situation" METADATA "wms_title" "Lacs suisse" "wms_srs" "EPSG:21781 EPSG:54004 EPSG:3785 EPSG:4326 EPSG:900913" END GROUP "Fonds_carto" TYPE POLYGON STATUS ON CONNECTIONTYPE POSTGIS CONNECTION ... PROCESSING "CLOSE_CONNECTION=DEFER" DATA "geom from mobilite2030.lacs_mobilite using unique idobj using srid=21781" CLASS STYLE COLOR 180 230 255 OUTLINECOLOR 107 185 235 WIDTH 0.5 END END END LAYER NAME "lakes_situation_shading" METADATA "wms_title" "lacs_situation ombrage" "wms_srs" "EPSG:21781 EPSG:54004 EPSG:3785 EPSG:4326 EPSG:900913" END GROUP "Fonds_carto" TYPE POLYGON CONNECTIONTYPE POSTGIS CONNECTION ... PROCESSING "CLOSE_CONNECTION=DEFER" DATA "geom from mobilite2030.lacs_mobilite using unique idobj using srid=21781" STATUS ON COMPOSITE OPACITY 50 COMPFILTER "10" END CLASS STYLE GEOMTRANSFORM (buffer([shape],-8)) COLOR 255 255 255 END END END Marc Riedo Responsable du SITN ____________________________________________________________ R?PUBLIQUE ET CANTON DE NEUCH?TEL D?partement du d?veloppement territorial et de l'environnement Service de la g?omatique et du registre foncier Direction Rue de Tivoli 22 2003 Neuch?tel T +41 32 889 47 83 G?oportail : http://sitn.ne.ch www.ne.ch/sitn -----Message d'origine----- De?: thomas bonfort [mailto:thomas.bonfort at gmail.com] Envoy??: mardi, 6 octobre 2015 10:41 ??: Lime, Steve D (MNIT); Riedo Marc Cc?: MapServer Dev Mailing List; MapserverList OSGEO Objet?: Re: [mapserver-dev] RFC113 Chainable Compositing Filters All credit for those beautiful maps go to the http://sitn.ne.ch/ team, I didn't have a play in them. I've cc'd Marc who might be able to share more details as to what he was using exactly (note that those maps predate the actual filter chaining implementation, and used a hack present in 7.0 along with drawing the shaded layers twice). For the water bodies, I suspect it can be done with: COMPOSITE #first we render normal water color END COMPOSITE COMPFILTER "whiten()" COMPFILTER "blur(5)" COMPOP "soft-light" OPACITY 50 END CLASS STYLE COLOR water-color END END At present filters are not supported on labels (unless they don't go through the labelcache). They could be supported in the longer run if we explicitely had a "labelcache" layer that we could draw into and that we could therefore plug into the compositing chain. regards, thomas On 2 October 2015 at 18:18, Lime, Steve D (MNIT) wrote: > Beautiful maps... How'd you do the inside shading on the water bodies? > Can these be applied to labels? --Steve > > -----Original Message----- > From: mapserver-dev-bounces at lists.osgeo.org > [mailto:mapserver-dev-bounces at lists.osgeo.org] On Behalf Of thomas > bonfort > Sent: Friday, October 02, 2015 4:36 AM > To: MapServer Dev Mailing List ; > MapserverList OSGEO > Subject: [mapserver-dev] RFC113 Chainable Compositing Filters > > Hi All, > > I have finished implementing the chainable compositing filters that > were architectured along with RFC113, and the code has been committed > to the master branch. The aim of the development is essentially to > enable soft shadow and blurring effects, although other usages can > exist or could be added in the future. > To obtain a soft shadow effect that can be seen for example around the > buildings on > http://sitn.ne.ch/production/wsgi/mobile/?theme=mobile_default&baselay > er_ref=plan_ville&map_x=554942.49763489&map_y=200242.9936142&map_zoom= > 6&tree_layers= > you can use > > LAYER > NAME "buildings" > TYPE POLYGON > COMPOSITE > #create the shadow/blur effect by translating a blurred version of the layer > COMPFILTER "grayscale()" > COMPFILTER "translate(5,5)" > COMPFILTER "blur(4)" > OPACITY 50 > END > COMPOSITE > #and render the buildings themselves > OPACITY 100 > END > CLASS > STYLE > COLOR 128 128 128 > OUTLINECOLOR 0 0 0 > WIDTH 1 > END > END > END > > The currently available filters are: > - "blur(integer)" > - "translate(integer,integer)" > - "grayscale()" > - "blacken()" > - "whiten()" > > I'll add some documentation and autotests next week. > > best regards, > Thomas > _______________________________________________ > mapserver-dev mailing list > mapserver-dev at lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/mapserver-dev From tkirstine at firstbasesolutions.com Tue Oct 6 12:22:08 2015 From: tkirstine at firstbasesolutions.com (Travis Kirstine) Date: Tue, 6 Oct 2015 15:22:08 -0400 Subject: [mapserver-users] riak make error Message-ID: Running into issues installing mapcache 1.4 with riak The cmake runs OK but I receive this error on the make In file included from /usr/local/include/riack.h:21, from /opt/mapcache/include/mapcache.h:75, from /opt/mapcache/lib/hmac-sha.c:34: /usr/local/include/riack_defines.h:20:18: error: ints.h: No such file or directory In file included from /opt/mapcache/lib/hmac-sha.c:34: /opt/mapcache/include/mapcache.h:706: error: expected specifier-qualifier-list before ?RIACK_STRING? make[2]: *** [CMakeFiles/mapcache.dir/lib/hmac-sha.c.o] Error 1 make[1]: *** [CMakeFiles/mapcache.dir/all] Error 2 Any Ideas? -- [image: FBS Logo] *Travis Kirstine*, Web Development Supervisor *t *905?477?3600* x *301 | *m *647?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 thomas.bonfort at gmail.com Tue Oct 6 12:38:34 2015 From: thomas.bonfort at gmail.com (thomas bonfort) Date: Tue, 6 Oct 2015 21:38:34 +0200 Subject: [mapserver-users] riak make error In-Reply-To: References: Message-ID: IIRC, you have to use the riak-1.4 branch, and there's some a minimal manual fix to apply to the riack headers for it to compile correctly, namely to include On 6 October 2015 at 21:22, Travis Kirstine < tkirstine at firstbasesolutions.com> wrote: > Running into issues installing mapcache 1.4 with riak > > The cmake runs OK but I receive this error on the make > > > In file included from /usr/local/include/riack.h:21, > from /opt/mapcache/include/mapcache.h:75, > from /opt/mapcache/lib/hmac-sha.c:34: > /usr/local/include/riack_defines.h:20:18: error: ints.h: No such file or > directory > In file included from /opt/mapcache/lib/hmac-sha.c:34: > /opt/mapcache/include/mapcache.h:706: error: expected > specifier-qualifier-list before ?RIACK_STRING? > make[2]: *** [CMakeFiles/mapcache.dir/lib/hmac-sha.c.o] Error 1 > make[1]: *** [CMakeFiles/mapcache.dir/all] Error 2 > > > Any Ideas? > > -- > [image: FBS Logo] > > *Travis Kirstine*, Web Development Supervisor > *t *905?477?3600* x *301 | *m *647?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 > > _______________________________________________ > 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 balajee at vizexperts.com Mon Oct 12 03:26:18 2015 From: balajee at vizexperts.com (Balajee R.C) Date: Mon, 12 Oct 2015 15:56:18 +0530 Subject: [mapserver-users] No Layers when configuring TinyOWS with a Mapserver (.map) File Message-ID: Am trying to expose a vector layer (loaded from shape file into PostGIS) as a WFS layer using tinyows. Following the instructions in the mapserver/tinyows documentation, here is the .map file I have come up with so far: MAP NAME "world" CONFIG "MS_ERRORFILE" "/home/balajeerc/Projects/Build_Dir/myproject/data/logs/mapservice_errors.log" EXTENT -180.000 -90.000 180.000 90.000 WEB METADATA "tinyows_schema_dir" "/home/balajeerc/Projects/Build_Dir/myproject/deps/mygis-services-0.1/data/schema" "tinyows_onlineresource" " http://192.168.43.164:19090/vectors/world/wfs?" "wfs_title" "MyGIS Feature Service: World" "wfs_contact" "support at giscompany.com" "wms_title" "MyGIS Feature Service: World" "wms_srs" "epsg:4326" "wms_enable_request" "*" "log_level" "15" "log" "/home/balajeerc/Projects/Build_Dir/myproject/deps/mygis-services-0.1/data/logs/wfs_world.log" "ows_contactorganization" "MyCompany" "ows_contactelectronicmailaddress" "contact at giscompany.com" "ows_contactperson" "Balajee.R.C" END END PROJECTION "init=epsg:4326" END LAYER NAME 'world_boundaries' CONNECTIONTYPE postgis CONNECTION "host=localhost user=mygis password=asdf123 dbname=mygis port=19095" DATA "geom from world_boundaries" TYPE POLYGON METADATA 'wfs_title' 'world_boundaries' 'wfs_namespace_prefix' 'tows' 'wfs_namespace_uri' 'http://www.giscompany.com/' 'wfs_srs' 'epsg:4326' 'wms_srs' 'epsg:4326' 'wms_title' 'world_boundaries' 'tinyows_table' 'world_boundaries' 'tinyows_writable' '1' 'tinyows_retrievable' '1' END CLASS STYLE COLOR 128 128 128 ANTIALIAS true END END PROJECTION "init=epsg:4326" END DUMP TRUE END END This .map file works fine with mapserver, i.e. I am able to render the feature layer as a WMS service using QGIS as a client. However, the WFS service (served by tinyows) using the same file (set using `TINYOWS_MAPFILE` environment variable seems to show no layers in GetCapabilities (and hence QGIS is not able to load any). The output from `tinyows --check` is as follows: balajeerc at Balajee:~/Projects/tinyows-1.1.1$ ./tinyows --check TinyOWS version: 1.1.0 FCGI support: Yes Config File Path: /home/balajeerc/Projects/Build_Dir/myproject/data/service_data/data/wfs/world.map (Mapfile) PostGIS Version: 2.1.8 PostGIS dsn: host=localhost user=mygis password=asdf123 dbname=mygis port=19095 Output Encoding: UTF-8 Database Encoding: UTF8 Schema dir: /home/balajeerc/Projects/Build_Dir/myproject/deps/mygis-services-0.1/data/schema Display bbox: Yes Estimated extent: No Check schema: Yes Check valid geoms: Yes Available layers: balajeerc at Balajee:~/Projects/tinyows-1.1.1$ Note that even though I am using a 1.1.1 version of tinyows, it prints tinyows version as 1.1.0. Also note that it prints no layers. Wondering what is going wrong, I decided to step into the code. I recompiled code after turning off (`-O2`) optimizations and with debugging (`-g`) enabled. I am only able to get so far as the `ows_parse_config` method in `src/ows/ows_config.c`. I am, for some reason not able to step into `ows_parse_config_map` in `src/mapfile/mapfile.c`. This probably has something to do with the fact that `mapfile.c` is generated by flex using `src/map/mapfile.l`. At this point I am completely stuck and at a brick wall as to what might be going wrong. Can someone here please help? TinyOWS version: 1.1.1 (Release ) Regards, Balajee.R.C -------------- next part -------------- An HTML attachment was scrubbed... URL: From Robert.Sanson at asurequality.com Mon Oct 12 13:13:48 2015 From: Robert.Sanson at asurequality.com (Robert Sanson) Date: Mon, 12 Oct 2015 20:13:48 +0000 Subject: [mapserver-users] Mapcache - optimum format for orthophotos? Message-ID: Hi What is the recommended format for serving and storing true colour orthophotos via Mapcache if we wish to preserve maximum detail? The source data are uncompressed GeoTiffs served as WMS by Mapserver. Many thanks, Robert Sanson From Robert.Sanson at asurequality.com Mon Oct 12 13:48:46 2015 From: Robert.Sanson at asurequality.com (Robert Sanson) Date: Mon, 12 Oct 2015 20:48:46 +0000 Subject: [mapserver-users] Mapcache - how to deal with changes to mapcache.xml? Message-ID: What is the recommended approach to dealing with stored tiles when changes to mapcache.xml are made, such as a change in the set of resolutions in a grid? Should we disable the Web server, delete all the existing tiles then restart the server? Many thanks, Robert Sanson From thomas.bonfort at gmail.com Tue Oct 13 00:06:53 2015 From: thomas.bonfort at gmail.com (thomas bonfort) Date: Tue, 13 Oct 2015 09:06:53 +0200 Subject: [mapserver-users] Mapcache - optimum format for orthophotos? In-Reply-To: References: Message-ID: in the vast majority of the cases, you'll want to have mapcache use metatiles, be serving PNGs from your WMS server (image/png in your mapcache ), and storing your tiles as JPG (JPG in your ). If you need to preserve transparency on your orthophoto edges, you can choose to store the tiles as a"mixed" format instead of pure JPG. -- thomas On 12 October 2015 at 22:13, Robert Sanson wrote: > Hi > > What is the recommended format for serving and storing true colour orthophotos via Mapcache if we wish to preserve maximum detail? The source data are uncompressed GeoTiffs served as WMS by Mapserver. > > Many thanks, > > Robert Sanson > _______________________________________________ > mapserver-users mailing list > mapserver-users at lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/mapserver-users From thomas.bonfort at gmail.com Tue Oct 13 00:10:59 2015 From: thomas.bonfort at gmail.com (thomas bonfort) Date: Tue, 13 Oct 2015 09:10:59 +0200 Subject: [mapserver-users] Mapcache - how to deal with changes to mapcache.xml? In-Reply-To: References: Message-ID: if it's a change that does not incur backwards compatibility (e.g. adding a tileset, changing the cache backend for a tileset, enabling/disabling a server, ...) you can just issue a graceful restart on the webserver. In your case (change of resolution), the path you suggested is the correct one. Note that if you just need to invalidate the cache because the stored tiles are outdated, you can do that while the server itself is running (rm -rf on dir, or delete from tiles in sqlite) -- thomas On 12 October 2015 at 22:48, Robert Sanson wrote: > What is the recommended approach to dealing with stored tiles when changes to mapcache.xml are made, such as a change in the set of resolutions in a grid? Should we disable the Web server, delete all the existing tiles then restart the server? > > Many thanks, > > Robert Sanson > _______________________________________________ > mapserver-users mailing list > mapserver-users at lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/mapserver-users From ahmettemiz88 at gmail.com Tue Oct 13 09:37:17 2015 From: ahmettemiz88 at gmail.com (Ahmet Temiz) Date: Tue, 13 Oct 2015 19:37:17 +0300 Subject: [mapserver-users] =?utf-8?q?=28no_subject=29?= Message-ID: Hello, I created tile/pyramid structure on my tif file using gdal_retile.py How can use it in my wcs-mapfile ? Regards Ahmet Temiz -- Ahmet Temiz Jeoloji M?h. Afet ve Acil Durum Y?netimi Ba?kanl??? Bilgi ??lem Dairesi Ba?kanl???-CBS Grubu ________________________ Ahmet Temiz Geological Eng. Information Systems - GIS Group Disaster and Emergency Management of Presidency -------------- next part -------------- An HTML attachment was scrubbed... URL: From ahmettemiz88 at gmail.com Tue Oct 13 09:38:34 2015 From: ahmettemiz88 at gmail.com (Ahmet Temiz) Date: Tue, 13 Oct 2015 19:38:34 +0300 Subject: [mapserver-users] Fwd: pyramid usage in wcs mapfile Message-ID: ---------- Forwarded message ---------- From: *Ahmet Temiz* Date: Tuesday, October 13, 2015 Subject: [mapserver-users] (no subject) To: mapserver-users Hello, I created tile/pyramid structure on my tif file using gdal_retile.py How can use it in my wcs-mapfile ? Regards Ahmet Temiz -- Ahmet Temiz Jeoloji M?h. Afet ve Acil Durum Y?netimi Ba?kanl??? Bilgi ??lem Dairesi Ba?kanl???-CBS Grubu ________________________ Ahmet Temiz Geological Eng. Information Systems - GIS Group Disaster and Emergency Management of Presidency -- Ahmet Temiz Jeoloji M?h. Afet ve Acil Durum Y?netimi Ba?kanl??? Bilgi ??lem Dairesi Ba?kanl???-CBS Grubu ________________________ Ahmet Temiz Geological Eng. Information Systems - GIS Group Disaster and Emergency Management of Presidency -------------- next part -------------- An HTML attachment was scrubbed... URL: From Robert.Sanson at asurequality.com Tue Oct 13 13:15:46 2015 From: Robert.Sanson at asurequality.com (Robert Sanson) Date: Tue, 13 Oct 2015 20:15:46 +0000 Subject: [mapserver-users] Mapcache - optimum format for orthophotos? In-Reply-To: References: Message-ID: Thanks Thomas. I do not have labels, so would you still recommend metatiles for performance reasons? Would you suggest 3 3 or 5 5 for a Mapserver WMS backend? 3 3 Robert -----Original Message----- From: thomas bonfort [mailto:thomas.bonfort at gmail.com] Sent: Tuesday, 13 October 2015 8:07 p.m. To: Robert Sanson Cc: mapserver-users at lists.osgeo.org Subject: Re: [mapserver-users] Mapcache - optimum format for orthophotos? in the vast majority of the cases, you'll want to have mapcache use metatiles, be serving PNGs from your WMS server (image/png in your mapcache ), and storing your tiles as JPG (JPG in your ). If you need to preserve transparency on your orthophoto edges, you can choose to store the tiles as a"mixed" format instead of pure JPG. -- thomas On 12 October 2015 at 22:13, Robert Sanson wrote: > Hi > > What is the recommended format for serving and storing true colour orthophotos via Mapcache if we wish to preserve maximum detail? The source data are uncompressed GeoTiffs served as WMS by Mapserver. > > Many thanks, > > Robert Sanson > _______________________________________________ > mapserver-users mailing list > mapserver-users at lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/mapserver-users From woodbri at swoodbridge.com Tue Oct 13 14:37:44 2015 From: woodbri at swoodbridge.com (Stephen Woodbridge) Date: Tue, 13 Oct 2015 17:37:44 -0400 Subject: [mapserver-users] Mapcache - optimum format for orthophotos? In-Reply-To: References: Message-ID: <561D79A8.3050705@swoodbridge.com> On 10/13/2015 4:15 PM, Robert Sanson wrote: > Thanks Thomas. I do not have labels, so would you still recommend > metatiles for performance reasons? Would you suggest 3 3 or 5 5 for a > Mapserver WMS backend? > > 3 3 Robert, Regarding labels you can set a metabuffer value in both the mapcache.xml and the mapfile. osm-curvature disk WGS84 g PNGQ_FAST 5 5 20 3600 and in the mapfile: WEB METADATA labelcache_map_edge_buffer "-20" ## "ows_title" "OSMCurvature" ... END END -Steve W > Robert > > -----Original Message----- From: thomas bonfort > [mailto:thomas.bonfort at gmail.com] Sent: Tuesday, 13 October 2015 8:07 > p.m. To: Robert Sanson Cc: > mapserver-users at lists.osgeo.org Subject: Re: [mapserver-users] > Mapcache - optimum format for orthophotos? > > in the vast majority of the cases, you'll want to have mapcache use > metatiles, be serving PNGs from your WMS server > (image/png in your mapcache ), and storing > your tiles as JPG (JPG in your ). If you > need to preserve transparency on your orthophoto edges, you can > choose to store the tiles as a"mixed" format instead of pure JPG. > > -- thomas > > On 12 October 2015 at 22:13, Robert Sanson > wrote: >> Hi >> >> What is the recommended format for serving and storing true colour >> orthophotos via Mapcache if we wish to preserve maximum detail? The >> source data are uncompressed GeoTiffs served as WMS by Mapserver. >> >> Many thanks, >> >> Robert Sanson _______________________________________________ >> 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 > From thomas.bonfort at gmail.com Wed Oct 14 03:56:36 2015 From: thomas.bonfort at gmail.com (thomas bonfort) Date: Wed, 14 Oct 2015 12:56:36 +0200 Subject: [mapserver-users] Mapcache - optimum format for orthophotos? In-Reply-To: References: Message-ID: it depends on many factors... large metatiles are more efficient as they usually impose less load on the WMS server, but can cause a significant delay for the end user if you are populating your cache on demand. If you're preseeding everything, use large power of 2 metatiles (4x4, 8x8,...). If you haven't pre-seeded, use smaller ones, how small depends on the experience you want to provide your user if the tile isn't already in the cache (2x2, 4x4). If you're rendering raster data only, you don't need a metabuffer. On 13 October 2015 at 22:15, Robert Sanson wrote: > Thanks Thomas. I do not have labels, so would you still recommend metatiles for performance reasons? Would you suggest 3 3 or 5 5 for a Mapserver WMS backend? > > 3 3 > > Robert > > -----Original Message----- > From: thomas bonfort [mailto:thomas.bonfort at gmail.com] > Sent: Tuesday, 13 October 2015 8:07 p.m. > To: Robert Sanson > Cc: mapserver-users at lists.osgeo.org > Subject: Re: [mapserver-users] Mapcache - optimum format for orthophotos? > > in the vast majority of the cases, you'll want to have mapcache use metatiles, be serving PNGs from your WMS server (image/png in your mapcache ), and storing your tiles as JPG (JPG in your ). If you need to preserve transparency on your orthophoto edges, you can choose to store the tiles as a"mixed" format instead of pure JPG. > > -- > thomas > > On 12 October 2015 at 22:13, Robert Sanson wrote: >> Hi >> >> What is the recommended format for serving and storing true colour orthophotos via Mapcache if we wish to preserve maximum detail? The source data are uncompressed GeoTiffs served as WMS by Mapserver. >> >> Many thanks, >> >> Robert Sanson >> _______________________________________________ >> mapserver-users mailing list >> mapserver-users at lists.osgeo.org >> http://lists.osgeo.org/mailman/listinfo/mapserver-users From tkirstine at firstbasesolutions.com Wed Oct 14 05:23:53 2015 From: tkirstine at firstbasesolutions.com (Travis Kirstine) Date: Wed, 14 Oct 2015 08:23:53 -0400 Subject: [mapserver-users] Mapcache - optimum format for orthophotos? In-Reply-To: References: Message-ID: This is worth a read as well for info on how to optimize your images for mapserver. http://mapserver.org/uk/optimization/raster.html On Wed, Oct 14, 2015 at 6:56 AM, thomas bonfort wrote: > it depends on many factors... large metatiles are more efficient as > they usually impose less load on the WMS server, but can cause a > significant delay for the end user if you are populating your cache on > demand. > If you're preseeding everything, use large power of 2 metatiles (4x4, > 8x8,...). If you haven't pre-seeded, use smaller ones, how small > depends on the experience you want to provide your user if the tile > isn't already in the cache (2x2, 4x4). > If you're rendering raster data only, you don't need a metabuffer. > > On 13 October 2015 at 22:15, Robert Sanson > wrote: > > Thanks Thomas. I do not have labels, so would you still recommend > metatiles for performance reasons? Would you suggest 3 3 or 5 5 for a > Mapserver WMS backend? > > > > 3 3 > > > > Robert > > > > -----Original Message----- > > From: thomas bonfort [mailto:thomas.bonfort at gmail.com] > > Sent: Tuesday, 13 October 2015 8:07 p.m. > > To: Robert Sanson > > Cc: mapserver-users at lists.osgeo.org > > Subject: Re: [mapserver-users] Mapcache - optimum format for orthophotos? > > > > in the vast majority of the cases, you'll want to have mapcache use > metatiles, be serving PNGs from your WMS server (image/png > in your mapcache ), and storing your tiles as JPG > (JPG in your ). If you need to preserve > transparency on your orthophoto edges, you can choose to store the tiles as > a"mixed" format instead of pure JPG. > > > > -- > > thomas > > > > On 12 October 2015 at 22:13, Robert Sanson < > Robert.Sanson at asurequality.com> wrote: > >> Hi > >> > >> What is the recommended format for serving and storing true colour > orthophotos via Mapcache if we wish to preserve maximum detail? The source > data are uncompressed GeoTiffs served as WMS by Mapserver. > >> > >> Many thanks, > >> > >> Robert Sanson > >> _______________________________________________ > >> 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 > -- [image: FBS Logo] *Travis Kirstine*, Web Development Supervisor *t *905?477?3600* x *301 | *m *647?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 lars.schylberg at saabgroup.com Wed Oct 14 06:24:42 2015 From: lars.schylberg at saabgroup.com (Schylberg Lars) Date: Wed, 14 Oct 2015 13:24:42 +0000 Subject: [mapserver-users] Mapcache - optimum format for orthophotos? In-Reply-To: References: Message-ID: <3c4f76fa47664e6dadd468fda8044c10@corpappl846.corp.saab.se> There is even more details how to optimize the data if You read the blog entry from Paul R. http://blog.cleverelephant.ca/2015/02/geotiff-compression-for-dummies.html /Lars S. From: mapserver-users [mailto:mapserver-users-bounces at lists.osgeo.org] On Behalf Of Travis Kirstine Sent: den 14 oktober 2015 14:24 Cc: mapserver-users at lists.osgeo.org Subject: Re: [mapserver-users] Mapcache - optimum format for orthophotos? This is worth a read as well for info on how to optimize your images for mapserver. http://mapserver.org/uk/optimization/raster.html On Wed, Oct 14, 2015 at 6:56 AM, thomas bonfort > wrote: it depends on many factors... large metatiles are more efficient as they usually impose less load on the WMS server, but can cause a significant delay for the end user if you are populating your cache on demand. If you're preseeding everything, use large power of 2 metatiles (4x4, 8x8,...). If you haven't pre-seeded, use smaller ones, how small depends on the experience you want to provide your user if the tile isn't already in the cache (2x2, 4x4). If you're rendering raster data only, you don't need a metabuffer. On 13 October 2015 at 22:15, Robert Sanson > wrote: > Thanks Thomas. I do not have labels, so would you still recommend metatiles for performance reasons? Would you suggest 3 3 or 5 5 for a Mapserver WMS backend? > > 3 3 > > Robert > > -----Original Message----- > From: thomas bonfort [mailto:thomas.bonfort at gmail.com] > Sent: Tuesday, 13 October 2015 8:07 p.m. > To: Robert Sanson > > Cc: mapserver-users at lists.osgeo.org > Subject: Re: [mapserver-users] Mapcache - optimum format for orthophotos? > > in the vast majority of the cases, you'll want to have mapcache use metatiles, be serving PNGs from your WMS server (image/png in your mapcache ), and storing your tiles as JPG (JPG in your ). If you need to preserve transparency on your orthophoto edges, you can choose to store the tiles as a"mixed" format instead of pure JPG. > > -- > thomas > > On 12 October 2015 at 22:13, Robert Sanson > wrote: >> Hi >> >> What is the recommended format for serving and storing true colour orthophotos via Mapcache if we wish to preserve maximum detail? The source data are uncompressed GeoTiffs served as WMS by Mapserver. >> >> Many thanks, >> >> Robert Sanson >> _______________________________________________ >> 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 -- [FBS Logo] Travis Kirstine, Web Development Supervisor t 905?477?3600 x 301 | m 647?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 karsten at terragis.net Wed Oct 14 14:39:23 2015 From: karsten at terragis.net (karsten) Date: Wed, 14 Oct 2015 14:39:23 -0700 Subject: [mapserver-users] UTF grid capabilities MapServer 7 ? Message-ID: <33F202129A6F420BA54E5183C860855A@terragis2> Hi all, I will be teaching a MapServer class the upcoming weekend and really wanted to add an example about the new UTF grid capabilities for MapServer 7 (seen this announced in the FOSS4G 2015 MapServer Status Report document I downloaded. Does anybody know if there is any working example our there I can look at , any documentation (could not even find a mention of UTF Grid in the new MapServer.pdf http://mapserver.org/MapServer.pdf for MS 7 nor could I find any example of the map file syntax to use. Each and every insight or help is greatly appreciated. Cheers Karsten Karsten Vennemann Principal Terra GIS LTD 2119 Boyer Ave E Seattle, WA 98112 USA www.terragis.net Phone ++1 206 905 1711 -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.bonfort at gmail.com Thu Oct 15 02:48:48 2015 From: thomas.bonfort at gmail.com (thomas bonfort) Date: Thu, 15 Oct 2015 11:48:48 +0200 Subject: [mapserver-users] UTF grid capabilities MapServer 7 ? In-Reply-To: <33F202129A6F420BA54E5183C860855A@terragis2> References: <33F202129A6F420BA54E5183C860855A@terragis2> Message-ID: there are a few examples in the autotests (*.json files in https://github.com/mapserver/msautotest/tree/master/renderers/expected) . Basically you just have to use the "json" outputformat that's enabled by default. You can also specify which fields to include with UTFDATA like in https://github.com/mapserver/msautotest/blob/master/renderers/utfgrid-escaping.map -- thomas On 14 October 2015 at 23:39, karsten wrote: > Hi all, > > I will be teaching a MapServer class the upcoming weekend and really wanted > to add an example about the new UTF grid capabilities for MapServer 7 (seen > this announced in the FOSS4G 2015 MapServer Status Report document I > downloaded. > Does anybody know if there is any working example our there I can look at , > any documentation (could not even find a mention of UTF Grid in the new > MapServer.pdf http://mapserver.org/MapServer.pdf for MS 7 nor could I find > any example of the map file syntax to use. > > Each and every insight or help is greatly appreciated. > > Cheers > Karsten > > Karsten Vennemann > Principal > > Terra GIS LTD > 2119 Boyer Ave E > Seattle, WA 98112 > USA > www.terragis.net > Phone ++1 206 905 1711 > > > > _______________________________________________ > mapserver-users mailing list > mapserver-users at lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/mapserver-users From jmckenna at gatewaygeomatics.com Thu Oct 15 05:23:16 2015 From: jmckenna at gatewaygeomatics.com (Jeff McKenna) Date: Thu, 15 Oct 2015 09:23:16 -0300 Subject: [mapserver-users] UTF grid capabilities MapServer 7 ? In-Reply-To: <33F202129A6F420BA54E5183C860855A@terragis2> References: <33F202129A6F420BA54E5183C860855A@terragis2> Message-ID: <561F9AB4.1060600@gatewaygeomatics.com> This is a good opportunity to remind the MapServer-dev team that when a funded enhancement comes your way, to please include effort/time/cost for the MapServer documentation team to test and document your enhancements (I've requested this years ago). Thanks! -jeff On 2015-10-14 6:39 PM, karsten wrote: > Hi all, > I will be teaching a MapServer class the upcoming weekend and really > wanted to add an example about the new UTF grid capabilities for > MapServer 7 (seen this announced in the FOSS4G 2015 MapServer Status > Report document I downloaded. > Does anybody know if there is any working example our there I can look > at , any documentation (could not even find a mention of UTF Grid in the > new MapServer.pdf http://mapserver.org/MapServer.pdf for MS 7 nor could > I find any example of the map file syntax to use. > Each and every insight or help is greatly appreciated. > Cheers > Karsten > > Karsten Vennemann > Principal > > Terra GIS LTD > 2119 Boyer Ave E > Seattle, WA 98112 > USA > www.terragis.net > Phone ++1 206 905 1711 > > -- Jeff McKenna MapServer Consulting and Training Services http://www.gatewaygeomatics.com/ From dmorissette at mapgears.com Thu Oct 15 05:46:42 2015 From: dmorissette at mapgears.com (Daniel Morissette) Date: Thu, 15 Oct 2015 08:46:42 -0400 Subject: [mapserver-users] UTF grid capabilities MapServer 7 ? In-Reply-To: <561F9AB4.1060600@gatewaygeomatics.com> References: <33F202129A6F420BA54E5183C860855A@terragis2> <561F9AB4.1060600@gatewaygeomatics.com> Message-ID: <561FA032.3060609@mapgears.com> For the record, this was the outcome of a Google Summer of Code project, and it was already hard enough to get the student to deliver working code, we could not expect good docs on top of that. Daniel On 2015-10-15 8:23 AM, Jeff McKenna wrote: > This is a good opportunity to remind the MapServer-dev team that when a > funded enhancement comes your way, to please include effort/time/cost > for the MapServer documentation team to test and document your > enhancements (I've requested this years ago). Thanks! > > -jeff > > > > > On 2015-10-14 6:39 PM, karsten wrote: >> Hi all, >> I will be teaching a MapServer class the upcoming weekend and really >> wanted to add an example about the new UTF grid capabilities for >> MapServer 7 (seen this announced in the FOSS4G 2015 MapServer Status >> Report document I downloaded. >> Does anybody know if there is any working example our there I can look >> at , any documentation (could not even find a mention of UTF Grid in the >> new MapServer.pdf http://mapserver.org/MapServer.pdf for MS 7 nor could >> I find any example of the map file syntax to use. >> Each and every insight or help is greatly appreciated. >> Cheers >> Karsten >> >> Karsten Vennemann >> Principal >> >> Terra GIS LTD >> 2119 Boyer Ave E >> Seattle, WA 98112 >> USA >> www.terragis.net >> Phone ++1 206 905 1711 >> >> -- Daniel Morissette http://www.mapgears.com/ T: +1 418-696-5056 #201 http://evouala.com/ - Location Intelligence Made Easy From dmorissette at mapgears.com Thu Oct 15 06:01:43 2015 From: dmorissette at mapgears.com (Daniel Morissette) Date: Thu, 15 Oct 2015 09:01:43 -0400 Subject: [mapserver-users] UTF grid capabilities MapServer 7 ? In-Reply-To: <561F9AB4.1060600@gatewaygeomatics.com> References: <33F202129A6F420BA54E5183C860855A@terragis2> <561F9AB4.1060600@gatewaygeomatics.com> Message-ID: <561FA3B7.50804@mapgears.com> Actually, I take that back. The student did produce docs, but we rejected the pull request because it needed cleanup and we never got back to it: https://github.com/mapserver/docs/pull/50 His docs are in his personal fork: https://github.com/fdesj/docs/commit/f2bcfcc7e42a8b9f1bd9d389bb7755f3400ee7a8 Finally, this is being handled in this new docs ticket: https://github.com/mapserver/docs/issues/131 And BTW, when docs are missing, keep in mind that the RFCs do contain enough info to use the feature and eventually write docs for them. Daniel On 2015-10-15 8:23 AM, Jeff McKenna wrote: > This is a good opportunity to remind the MapServer-dev team that when a > funded enhancement comes your way, to please include effort/time/cost > for the MapServer documentation team to test and document your > enhancements (I've requested this years ago). Thanks! > > -jeff > > > > > On 2015-10-14 6:39 PM, karsten wrote: >> Hi all, >> I will be teaching a MapServer class the upcoming weekend and really >> wanted to add an example about the new UTF grid capabilities for >> MapServer 7 (seen this announced in the FOSS4G 2015 MapServer Status >> Report document I downloaded. >> Does anybody know if there is any working example our there I can look >> at , any documentation (could not even find a mention of UTF Grid in the >> new MapServer.pdf http://mapserver.org/MapServer.pdf for MS 7 nor could >> I find any example of the map file syntax to use. >> Each and every insight or help is greatly appreciated. >> Cheers >> Karsten >> >> Karsten Vennemann >> Principal >> >> Terra GIS LTD >> 2119 Boyer Ave E >> Seattle, WA 98112 >> USA >> www.terragis.net >> Phone ++1 206 905 1711 >> >> -- Daniel Morissette http://www.mapgears.com/ T: +1 418-696-5056 #201 http://evouala.com/ - Location Intelligence Made Easy From ahmettemiz88 at gmail.com Fri Oct 16 00:23:09 2015 From: ahmettemiz88 at gmail.com (Ahmet Temiz) Date: Fri, 16 Oct 2015 10:23:09 +0300 Subject: [mapserver-users] confused about wcs Message-ID: ?Hello I am very confused about? wcs-request. My work doesn't deliver any map image. Where am I doing wrong ? http://localhost:8080/cgi-bin/mapserv?map=/usr/local/mapserver_work/wcs1.map&SERVICE=wcs&VERSION=1.0.0&REQUEST=GetCoverage&coverage=jeo&CRS=EPSG:4326&BBOX=25.670,35.813,44.824,42.106&WIDTH=1600&HEIGHT=1066&FORMAT=GTiff --------------- MAP NAME WCS_server STATUS ON DEBUG ON SIZE 2707 3360 PROJECTION "init=epsg:4326" END EXTENT 25.354 33.670 45.442 44.708 UNITS DD SHAPEPATH "/usr/local/webData/pyramids_jeo4326/0" CONFIG "MS_ERRORFILE" "/usr/local/webData/ms_error.txt" MAXSIZE 3361 OUTPUTFORMAT NAME GEOTIFF_16 DRIVER "GDAL/GTiff" MIMETYPE "image/tiff" IMAGEMODE INT16 EXTENSION "tif" END WEB IMAGEPATH "/usr/local/webData/pyramids_jeo4326/0" IMAGEURL "/ms_tmp/" TEMPLATE "template1.html" METADATA "wcs_label" "JeoMap WCS Demo Server" #"wcs_onlineresource" "http://localhost:8080/cgi-bin/mapserv?" "wcs_onlineresource" " http://localhost:8080/cgi-bin/mapserv?map=/usr/local/mapserver_work/wcs1.map " "wcs_enable_request" "*" END END LAYER NAME jeo METADATA "wcs_label" "GMap WCS Demo Server" ### required "wcs_description" "Some text description of the service" "wcs_onlineresource" "http://127.0.0.1/cgi-bin/mapserv.exe?" ### recommended "wcs_fees" "none" "wcs_accessconstraints" "none" "wcs_keywordlist" "wcs,test" "wcs_metadatalink_type" "TC211" "wcs_metadatalink_format" "text/plain" "wcs_metadatalink_href" "http://someurl.com" "wcs_address" "124 Gilmour Street" "wcs_city" "Ottawa" "wcs_stateorprovince" "ON" "wcs_postcode" "90210" "wcs_country" "Canada" "wcs_contactelectronicmailaddress" "blah at blah" "wcs_contactperson" "me" "wcs_contactorganization" "unemployed" "wcs_contactposition" "manager" "wcs_contactvoicetelephone" "613-555-1234" "wcs_contactfacimiletelephone" "613-555-1235" "wcs_service_onlineresource" "http://127.0.0.1/cgi-bin/mapserv.exe?" "wcs_enable_request" "*" END TYPE RASTER STATUS ON DATA jeo88_1_1.tif PROJECTION "init=epsg:4326" END DUMP TRUE ## Required END END I will appreciate if you supply hints ?regards? -- Ahmet Temiz Jeoloji M?h. Afet ve Acil Durum Y?netimi Ba?kanl??? Bilgi ??lem Dairesi Ba?kanl???-CBS Grubu ________________________ Ahmet Temiz Geological Eng. Information Systems - GIS Group Disaster and Emergency Management of Presidency -------------- next part -------------- An HTML attachment was scrubbed... URL: From ahmettemiz88 at gmail.com Fri Oct 16 06:45:33 2015 From: ahmettemiz88 at gmail.com (Ahmet Temiz) Date: Fri, 16 Oct 2015 16:45:33 +0300 Subject: [mapserver-users] my cgi app. doesn't work Message-ID: hello, I put mapserv in "apache-tomcat-7.0.34/webapps/cgi-bin". Is it wrong ? my wcs newer worked. ( http://localhost:8080/cgi-bin/mapserv?map=/usr/local/mapserver_work/wcs1.map&SERVICE=wcs&VERSION=1.0.0&REQUEST=GetCoverage&coverage=jeo&CRS=EPSG:4326&BBOX=25.670,35.813,44.824,42.106&WIDTH=1600&HEIGHT=1066&FORMAT=GTiff ) Where is the proper place in which we have to put the "mapserv" for cgi app in Tomcat ? Are there any further configurations I have to do ? I will appreciate if you provide any idea. regards -- Ahmet Temiz Jeoloji M?h. Afet ve Acil Durum Y?netimi Ba?kanl??? Bilgi ??lem Dairesi Ba?kanl???-CBS Grubu ________________________ Ahmet Temiz Geological Eng. Information Systems - GIS Group Disaster and Emergency Management of Presidency -------------- next part -------------- An HTML attachment was scrubbed... URL: From ahmettemiz88 at gmail.com Mon Oct 19 01:08:49 2015 From: ahmettemiz88 at gmail.com (Ahmet Temiz) Date: Mon, 19 Oct 2015 11:08:49 +0300 Subject: [mapserver-users] getting true wcs-dem value Message-ID: hello I retrieve wcs-dem . curl --trace -i -H "Content-Type: application/image" -XGET " http://127.0.1.1/cgi-bin/mapserv?map=wcs1.map&SERVICE=wcs&VERSION=1.0.0&REQUEST=GetCoverage&coverage=dem&CRS=EPSG:4326&BBOX=35.670381,35.813051,44.81901235734796,42.106463&WIDTH=1600&HEIGHT=1066&FORMAT=GTiff" > dem.tif But, it generates 3 bands without having any dem value as : (gdalinfo dem.tif) Band 1 Block=1600x1 Type=Byte, ColorInterp=Red Band 2 Block=1600x1 Type=Byte, ColorInterp=Green Band 3 Block=1600x1 Type=Byte, ColorInterp=Blue ---- shp2img produce proper results : Band 1 Block=2707x3 Type=Byte, ColorInterp=Gray What am I doing possibly wrong ? What do I have to do to get raw wcs-dem value? regards -- Ahmet Temiz Jeoloji M?h. Afet ve Acil Durum Y?netimi Ba?kanl??? Bilgi ??lem Dairesi Ba?kanl???-CBS Grubu ________________________ Ahmet Temiz Geological Eng. Information Systems - GIS Group Disaster and Emergency Management of Presidency -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin.icking at bentley.com Mon Oct 19 07:00:19 2015 From: martin.icking at bentley.com (Martin Icking) Date: Mon, 19 Oct 2015 07:00:19 -0700 (PDT) Subject: [mapserver-users] Search in MapServer.org does not work Message-ID: <1445263219496-5231150.post@n6.nabble.com> The search window opens, but no search result is shown. In the debug console I get: GET http://mapserver.org/_sources/MIGRATION_GUIDE.txt 404 (Not Found) Tx Martin -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Search-in-MapServer-org-does-not-work-tp5231150.html Sent from the Mapserver - User mailing list archive at Nabble.com. From jmckenna at gatewaygeomatics.com Mon Oct 19 09:26:53 2015 From: jmckenna at gatewaygeomatics.com (Jeff McKenna) Date: Mon, 19 Oct 2015 13:26:53 -0300 Subject: [mapserver-users] Search in MapServer.org does not work In-Reply-To: <1445263219496-5231150.post@n6.nabble.com> References: <1445263219496-5231150.post@n6.nabble.com> Message-ID: <562519CD.6080004@gatewaygeomatics.com> Thanks for reporting Martin. This was a tough one. I've noticed that since we made the move to build our docs on travis-ci.org the search stopped working, I think this problem has existed for a long time. Today finally I discovered some travis-ci.org build scripts for MapServer that "rm" some directories after copying to mapserver.org including "_sources/". I've changed those scripts and the search seems to be working again: http://www.mapserver.org/search.html?q=class -jeff -- Jeff McKenna MapServer Consulting and Training Services http://www.gatewaygeomatics.com/ On 2015-10-19 11:00 AM, Martin Icking wrote: > The search window opens, but no search result is shown. > In the debug console I get: > > GET http://mapserver.org/_sources/MIGRATION_GUIDE.txt 404 (Not Found) > > Tx > Martin > > From havard.tveite at nmbu.no Tue Oct 20 05:57:37 2015 From: havard.tveite at nmbu.no (Havard Tveite) Date: Tue, 20 Oct 2015 14:57:37 +0200 Subject: [mapserver-users] Documentation index missing on mapserver.org (Was: Re: Search in MapServer.org does not work) Message-ID: <56263A41.7000204@nmbu.no> Another similar(?) issue with mapserver.org: Some time ago, the documentation index disappeared from mapserver.org together with the blue navigation line near the top of the page. Could that be a similar issue, Jeff? When compiling the docs locally the blue navigation line below the translation flags shows up, but on mapserver.org it is gone. See https://github.com/mapserver/docs/issues/125 for details. In my opinion, the documentation index is essential when using the Mapserver documentation, so this is a critical issue. The link to the documentation index: http://www.mapserver.org/genindex.html H?vard On Mon Oct 19 09:26:53 PDT 2015, Jeff McKenna wrote: > Thanks for reporting Martin. > > This was a tough one. I've noticed that since we made the move to build > our docs on travis-ci.org the search stopped working, I think this > problem has existed for a long time. > > Today finally I discovered some travis-ci.org build scripts for > MapServer that "rm" some directories after copying to mapserver.org > including "_sources/". I've changed those scripts and the search seems > to be working again: http://www.mapserver.org/search.html?q=class > > -jeff > > > -- > Jeff McKenna > MapServer Consulting and Training Services > http://www.gatewaygeomatics.com/ > > > > On 2015-10-19 11:00 AM, Martin Icking wrote: >> The search window opens, but no search result is shown. >> In the debug console I get: >> >> GET http://mapserver.org/_sources/MIGRATION_GUIDE.txt 404 (Not Found) >> >> Tx >> Martin From jmckenna at gatewaygeomatics.com Tue Oct 20 06:05:30 2015 From: jmckenna at gatewaygeomatics.com (Jeff McKenna) Date: Tue, 20 Oct 2015 10:05:30 -0300 Subject: [mapserver-users] Documentation index missing on mapserver.org (Was: Re: Search in MapServer.org does not work) In-Reply-To: <56263A41.7000204@nmbu.no> References: <56263A41.7000204@nmbu.no> Message-ID: <56263C1A.4030708@gatewaygeomatics.com> Thanks for pushing this H?vard, I'll dive in... -jeff On 2015-10-20 9:57 AM, Havard Tveite wrote: > Another similar(?) issue with mapserver.org: > > Some time ago, the documentation index disappeared from > mapserver.org together with the blue navigation line near > the top of the page. > > Could that be a similar issue, Jeff? > > When compiling the docs locally the blue navigation line > below the translation flags shows up, but on mapserver.org it > is gone. > > See https://github.com/mapserver/docs/issues/125 for details. > > In my opinion, the documentation index is essential when > using the Mapserver documentation, so this is a critical > issue. > > The link to the documentation index: > http://www.mapserver.org/genindex.html > > H?vard > > On Mon Oct 19 09:26:53 PDT 2015, Jeff McKenna > wrote: > > Thanks for reporting Martin. > > > > This was a tough one. I've noticed that since we made the move to build > > our docs on travis-ci.org the search stopped working, I think this > > problem has existed for a long time. > > > > Today finally I discovered some travis-ci.org build scripts for > > MapServer that "rm" some directories after copying to mapserver.org > > including "_sources/". I've changed those scripts and the search seems > > to be working again: http://www.mapserver.org/search.html?q=class > > > > -jeff > > > > > > -- > > Jeff McKenna > > MapServer Consulting and Training Services > > http://www.gatewaygeomatics.com/ > > > > > > > > On 2015-10-19 11:00 AM, Martin Icking wrote: > >> The search window opens, but no search result is shown. > >> In the debug console I get: > >> > >> GET http://mapserver.org/_sources/MIGRATION_GUIDE.txt 404 (Not Found) > >> > >> Tx > >> Martin > From martin.icking at bentley.com Tue Oct 20 06:07:49 2015 From: martin.icking at bentley.com (Martin Icking) Date: Tue, 20 Oct 2015 06:07:49 -0700 (PDT) Subject: [mapserver-users] Documentation index missing on mapserver.org (Was: Re: Search in MapServer.org does not work) In-Reply-To: <56263C1A.4030708@gatewaygeomatics.com> References: <56263A41.7000204@nmbu.no> <56263C1A.4030708@gatewaygeomatics.com> Message-ID: <1445346469501-5231410.post@n6.nabble.com> Hi Jeff, while looking into this pls check on how the search is working. e.g. seaching for "Layer" you get to a lot of stuff but NOT the "Layer" chapter. Some results are about "OpenLayers" ("layer" being part of the word...) but if you search for "Openlayers" you don't even get the main "OpenLayers" section... Best regards Martin -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Documentation-index-missing-on-mapserver-org-Was-Re-Search-in-MapServer-org-does-not-work-tp5231405p5231410.html Sent from the Mapserver - User mailing list archive at Nabble.com. From yves.jacolin at camptocamp.com Tue Oct 20 06:24:38 2015 From: yves.jacolin at camptocamp.com (Yves Jacolin) Date: Tue, 20 Oct 2015 15:24:38 +0200 Subject: [mapserver-users] Documentation index missing on mapserver.org (Was: Re: Search in MapServer.org does not work) In-Reply-To: <56263C1A.4030708@gatewaygeomatics.com> References: <56263A41.7000204@nmbu.no> <56263C1A.4030708@gatewaygeomatics.com> Message-ID: <2244951.TKYgQShAZt@tatras> H?vard, By index file you mean glossary I guess? FYI, when pushing update for the translation last week, I get one error on this file. Y. On Tuesday, October 20, 2015 10:05:30 Jeff McKenna wrote: > Thanks for pushing this H?vard, I'll dive in... > > -jeff > > On 2015-10-20 9:57 AM, Havard Tveite wrote: > > Another similar(?) issue with mapserver.org: > > > > Some time ago, the documentation index disappeared from > > mapserver.org together with the blue navigation line near > > the top of the page. > > > > Could that be a similar issue, Jeff? > > > > When compiling the docs locally the blue navigation line > > below the translation flags shows up, but on mapserver.org it > > is gone. > > > > See https://github.com/mapserver/docs/issues/125 for details. > > > > In my opinion, the documentation index is essential when > > using the Mapserver documentation, so this is a critical > > issue. > > > > The link to the documentation index: > > http://www.mapserver.org/genindex.html > > > > H?vard > > > > On Mon Oct 19 09:26:53 PDT 2015, Jeff McKenna > > > > wrote: > > > Thanks for reporting Martin. > > > > > > This was a tough one. I've noticed that since we made the move to build > > > our docs on travis-ci.org the search stopped working, I think this > > > problem has existed for a long time. > > > > > > Today finally I discovered some travis-ci.org build scripts for > > > MapServer that "rm" some directories after copying to mapserver.org > > > including "_sources/". I've changed those scripts and the search seems > > > to be working again: http://www.mapserver.org/search.html?q=class > > > > > > -jeff > > > > > > > > > -- > > > Jeff McKenna > > > MapServer Consulting and Training Services > > > http://www.gatewaygeomatics.com/ > > > > > > On 2015-10-19 11:00 AM, Martin Icking wrote: > > >> The search window opens, but no search result is shown. > > >> In the debug console I get: > > >> > > >> GET http://mapserver.org/_sources/MIGRATION_GUIDE.txt 404 (Not Found) > > >> > > >> Tx > > >> Martin > > _______________________________________________ > 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 jmckenna at gatewaygeomatics.com Tue Oct 20 06:48:08 2015 From: jmckenna at gatewaygeomatics.com (Jeff McKenna) Date: Tue, 20 Oct 2015 10:48:08 -0300 Subject: [mapserver-users] Documentation index missing on mapserver.org (Was: Re: Search in MapServer.org does not work) In-Reply-To: <2244951.TKYgQShAZt@tatras> References: <56263A41.7000204@nmbu.no> <56263C1A.4030708@gatewaygeomatics.com> <2244951.TKYgQShAZt@tatras> Message-ID: <56264618.4050509@gatewaygeomatics.com> Hi Yves, What was your error exactly? -jeff On 2015-10-20 10:24 AM, Yves Jacolin wrote: > H?vard, > > By index file you mean glossary I guess? > > FYI, when pushing update for the translation last week, I get one error on > this file. > > Y. > > On Tuesday, October 20, 2015 10:05:30 Jeff McKenna wrote: >> Thanks for pushing this H?vard, I'll dive in... >> >> -jeff >> >> On 2015-10-20 9:57 AM, Havard Tveite wrote: >>> Another similar(?) issue with mapserver.org: >>> >>> Some time ago, the documentation index disappeared from >>> mapserver.org together with the blue navigation line near >>> the top of the page. >>> >>> Could that be a similar issue, Jeff? >>> >>> When compiling the docs locally the blue navigation line >>> below the translation flags shows up, but on mapserver.org it >>> is gone. >>> >>> See https://github.com/mapserver/docs/issues/125 for details. >>> >>> In my opinion, the documentation index is essential when >>> using the Mapserver documentation, so this is a critical >>> issue. >>> >>> The link to the documentation index: >>> http://www.mapserver.org/genindex.html >>> >>> H?vard >>> >>> On Mon Oct 19 09:26:53 PDT 2015, Jeff McKenna >>> >>> wrote: >>> > Thanks for reporting Martin. >>> > >>> > This was a tough one. I've noticed that since we made the move to build >>> > our docs on travis-ci.org the search stopped working, I think this >>> > problem has existed for a long time. >>> > >>> > Today finally I discovered some travis-ci.org build scripts for >>> > MapServer that "rm" some directories after copying to mapserver.org >>> > including "_sources/". I've changed those scripts and the search seems >>> > to be working again: http://www.mapserver.org/search.html?q=class >>> > >>> > -jeff >>> > >>> > >>> > -- >>> > Jeff McKenna >>> > MapServer Consulting and Training Services >>> > http://www.gatewaygeomatics.com/ >>> > >>> > On 2015-10-19 11:00 AM, Martin Icking wrote: >>> >> The search window opens, but no search result is shown. >>> >> In the debug console I get: >>> >> >>> >> GET http://mapserver.org/_sources/MIGRATION_GUIDE.txt 404 (Not Found) >>> >> >>> >> Tx >>> >> Martin >> From havard.tveite at nmbu.no Tue Oct 20 07:24:13 2015 From: havard.tveite at nmbu.no (Havard Tveite) Date: Tue, 20 Oct 2015 16:24:13 +0200 Subject: [mapserver-users] Documentation index missing on mapserver.org (Was: Re: Search in MapServer.org does not work) In-Reply-To: <2244951.TKYgQShAZt@tatras> References: <56263A41.7000204@nmbu.no> <56263C1A.4030708@gatewaygeomatics.com> <2244951.TKYgQShAZt@tatras> Message-ID: <56264E8D.2010005@nmbu.no> Yves, The index file I am talking about is the one that is generated by Sphinx based on the ".. index::" entries in the documentation files. This one: http://www.mapserver.org/genindex.html There does not seem to be a problem with the generation of the index file. The one at mapserver.org is up to date with the latest commits. The problem is that it is not any more available as a link on the mapserver.org web pages. H?vard On 20/10/2015 15:24:PM, Yves Jacolin wrote: > H?vard, > > By index file you mean glossary I guess? > > FYI, when pushing update for the translation last week, I get one error on > this file. > > Y. > > On Tuesday, October 20, 2015 10:05:30 Jeff McKenna wrote: >> Thanks for pushing this H?vard, I'll dive in... >> >> -jeff >> >> On 2015-10-20 9:57 AM, Havard Tveite wrote: >>> Another similar(?) issue with mapserver.org: >>> >>> Some time ago, the documentation index disappeared from >>> mapserver.org together with the blue navigation line near >>> the top of the page. >>> >>> Could that be a similar issue, Jeff? >>> >>> When compiling the docs locally the blue navigation line >>> below the translation flags shows up, but on mapserver.org it >>> is gone. >>> >>> See https://github.com/mapserver/docs/issues/125 for details. >>> >>> In my opinion, the documentation index is essential when >>> using the Mapserver documentation, so this is a critical >>> issue. >>> >>> The link to the documentation index: >>> http://www.mapserver.org/genindex.html >>> >>> H?vard >>> >>> On Mon Oct 19 09:26:53 PDT 2015, Jeff McKenna >>> >>> wrote: >>> > Thanks for reporting Martin. >>> > >>> > This was a tough one. I've noticed that since we made the move to build >>> > our docs on travis-ci.org the search stopped working, I think this >>> > problem has existed for a long time. >>> > >>> > Today finally I discovered some travis-ci.org build scripts for >>> > MapServer that "rm" some directories after copying to mapserver.org >>> > including "_sources/". I've changed those scripts and the search seems >>> > to be working again: http://www.mapserver.org/search.html?q=class >>> > >>> > -jeff >>> > >>> > >>> > -- >>> > Jeff McKenna >>> > MapServer Consulting and Training Services >>> > http://www.gatewaygeomatics.com/ >>> > >>> > On 2015-10-19 11:00 AM, Martin Icking wrote: >>> >> The search window opens, but no search result is shown. >>> >> In the debug console I get: >>> >> >>> >> GET http://mapserver.org/_sources/MIGRATION_GUIDE.txt 404 (Not Found) >>> >> >>> >> Tx >>> >> Martin >> >> _______________________________________________ >> 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 Oct 20 07:29:16 2015 From: yves.jacolin at camptocamp.com (Yves Jacolin) Date: Tue, 20 Oct 2015 16:29:16 +0200 Subject: [mapserver-users] Documentation index missing on mapserver.org (Was: Re: Search in MapServer.org does not work) In-Reply-To: <56264618.4050509@gatewaygeomatics.com> References: <56263A41.7000204@nmbu.no> <56263C1A.4030708@gatewaygeomatics.com> <2244951.TKYgQShAZt@tatras> <56264618.4050509@gatewaygeomatics.com> Message-ID: I don't remember exactly the error message, but to be clear, the error was on genindex po/mo file(s) when using tx client. Y. 2015-10-20 15:48 GMT+02:00 Jeff McKenna : > Hi Yves, > > What was your error exactly? > > -jeff > > > > > On 2015-10-20 10:24 AM, Yves Jacolin wrote: > >> H?vard, >> >> By index file you mean glossary I guess? >> >> FYI, when pushing update for the translation last week, I get one error on >> this file. >> >> Y. >> >> On Tuesday, October 20, 2015 10:05:30 Jeff McKenna wrote: >> >>> Thanks for pushing this H?vard, I'll dive in... >>> >>> -jeff >>> >>> On 2015-10-20 9:57 AM, Havard Tveite wrote: >>> >>>> Another similar(?) issue with mapserver.org: >>>> >>>> Some time ago, the documentation index disappeared from >>>> mapserver.org together with the blue navigation line near >>>> the top of the page. >>>> >>>> Could that be a similar issue, Jeff? >>>> >>>> When compiling the docs locally the blue navigation line >>>> below the translation flags shows up, but on mapserver.org it >>>> is gone. >>>> >>>> See https://github.com/mapserver/docs/issues/125 for details. >>>> >>>> In my opinion, the documentation index is essential when >>>> using the Mapserver documentation, so this is a critical >>>> issue. >>>> >>>> The link to the documentation index: >>>> http://www.mapserver.org/genindex.html >>>> >>>> H?vard >>>> >>>> On Mon Oct 19 09:26:53 PDT 2015, Jeff McKenna >>>> >>>> wrote: >>>> > Thanks for reporting Martin. >>>> > >>>> > This was a tough one. I've noticed that since we made the move to >>>> build >>>> > our docs on travis-ci.org the search stopped working, I think this >>>> > problem has existed for a long time. >>>> > >>>> > Today finally I discovered some travis-ci.org build scripts for >>>> > MapServer that "rm" some directories after copying to mapserver.org >>>> > including "_sources/". I've changed those scripts and the search >>>> seems >>>> > to be working again: http://www.mapserver.org/search.html?q=class >>>> > >>>> > -jeff >>>> > >>>> > >>>> > -- >>>> > Jeff McKenna >>>> > MapServer Consulting and Training Services >>>> > http://www.gatewaygeomatics.com/ >>>> > >>>> > On 2015-10-19 11:00 AM, Martin Icking wrote: >>>> >> The search window opens, but no search result is shown. >>>> >> In the debug console I get: >>>> >> >>>> >> GET http://mapserver.org/_sources/MIGRATION_GUIDE.txt 404 (Not >>>> Found) >>>> >> >>>> >> Tx >>>> >> Martin >>>> >>> >>> _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jmckenna at gatewaygeomatics.com Tue Oct 20 10:31:36 2015 From: jmckenna at gatewaygeomatics.com (Jeff McKenna) Date: Tue, 20 Oct 2015 14:31:36 -0300 Subject: [mapserver-users] Documentation index missing on mapserver.org (Was: Re: Search in MapServer.org does not work) In-Reply-To: References: <56263A41.7000204@nmbu.no> <56263C1A.4030708@gatewaygeomatics.com> <2244951.TKYgQShAZt@tatras> <56264618.4050509@gatewaygeomatics.com> Message-ID: <56267A78.9060302@gatewaygeomatics.com> I'm not sure what is going on yet, with the navigation bar (called "relbar" in sphinx terminology). I've at least found one other sphinx user in the same boat as us for their website, and I'm talking to him. For now, I discovered that if I manually force a draw of that navigation bar, in layout.html with relbar() it causes a duplicate bar locally, but now on mapserver.org the navigation bar is back, for English. I don't know how to get it back to other langs yet. Confusing, to say the least. -jeff -- Jeff McKenna MapServer Consulting and Training Services http://www.gatewaygeomatics.com/ On 2015-10-20 11:29 AM, Yves Jacolin wrote: > I don't remember exactly the error message, but to be clear, the error > was on genindex po/mo file(s) when using tx client. > > Y. > > 2015-10-20 15:48 GMT+02:00 Jeff McKenna >: > > Hi Yves, > > What was your error exactly? > > -jeff > > > > > On 2015-10-20 10:24 AM, Yves Jacolin wrote: > > H?vard, > > By index file you mean glossary I guess? > > FYI, when pushing update for the translation last week, I get > one error on > this file. > > Y. > > On Tuesday, October 20, 2015 10:05:30 Jeff McKenna wrote: > > Thanks for pushing this H?vard, I'll dive in... > > -jeff > > On 2015-10-20 9:57 AM, Havard Tveite wrote: > > Another similar(?) issue with mapserver.org > : > > Some time ago, the documentation index disappeared from > mapserver.org together with the > blue navigation line near > the top of the page. > > Could that be a similar issue, Jeff? > > When compiling the docs locally the blue navigation line > below the translation flags shows up, but on > mapserver.org it > is gone. > > See https://github.com/mapserver/docs/issues/125 for > details. > > In my opinion, the documentation index is essential when > using the Mapserver documentation, so this is a critical > issue. > > The link to the documentation index: > http://www.mapserver.org/genindex.html > > H?vard > > On Mon Oct 19 09:26:53 PDT 2015, Jeff McKenna > > > wrote: > > Thanks for reporting Martin. > > > > This was a tough one. I've noticed that since we > made the move to build > > our docs on travis-ci.org > the search stopped working, I think this > > problem has existed for a long time. > > > > Today finally I discovered some travis-ci.org > build scripts for > > MapServer that "rm" some directories after copying > to mapserver.org > > including "_sources/". I've changed those scripts > and the search seems > > to be working again: > http://www.mapserver.org/search.html?q=class > > > > -jeff > > > > > > -- > > Jeff McKenna > > MapServer Consulting and Training Services > > http://www.gatewaygeomatics.com/ > > > > On 2015-10-19 11:00 AM, Martin Icking wrote: > >> The search window opens, but no search result is > shown. > >> In the debug console I get: > >> > >> GET > http://mapserver.org/_sources/MIGRATION_GUIDE.txt 404 > (Not Found) > >> > >> Tx > >> Martin > > > _______________________________________________ > 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 pschweitzer at usgs.gov Tue Oct 20 15:11:24 2015 From: pschweitzer at usgs.gov (Schweitzer, Peter) Date: Tue, 20 Oct 2015 18:11:24 -0400 Subject: [mapserver-users] QGIS cannot use some of my mapcache WMTS services Message-ID: Help! I tried to use QGIS (2.10.1-Pisa, on Linux) to read WMTS services that I make available at http://mrdata.usgs.gov/mapcache/wmts? QGIS is able to read some of them, and not others, says type of image is "image/unknown" In my mapcache.xml, I have image formats specified as fast 256 75 RGB jpeg PNGQ_FAST and I notice that QGIS can use the tilesets where I have written PNGQ_FAST but QGIS cannot use the tilesets where I have written mixed Other software doesn't have this difficulty (for example, OpenLayers and Leaflet). Should I change my mixed to PNGQ_FAST ? What harm will this do? Will I need to erase and re-create the affected tilesets? Thanks for any advice you can provide! Peter -- Peter N. Schweitzer (U.S. Geological Survey, Reston, VA 20192) (703) 648-6533 email: pschweitzer at usgs.gov http://geology.usgs.gov/peter/ From semska at gmail.com Wed Oct 21 00:32:15 2015 From: semska at gmail.com (Richard Hanssen) Date: Wed, 21 Oct 2015 09:32:15 +0200 Subject: [mapserver-users] MapCache performance tips Message-ID: Hi We have a MapCache service running on top of a WMS service that holds a few layers with several dimensions(runtime substitution). The MapCache is also set up with dimensions that corresponds with the WMS service. We have a client that uses OpenLayers with tiled wms layers that is read from MapCache(or underlying WMS if the tiles are not preseeded) We have a simple IIS proxy in front of MapCache that forwards the tile requests to MapCache. The problem is that the speed does not seem to be very good when there are several users requesting tiles even if they are preseeded. The layers contain lines from shiptracks, and these are separated on 13 shiptypes, 8 size categories and periods of months. This leads to a considerable amount of cache structures. We also host the cache in 2 different projections. In total we have around 10 000 cache structures with all combinations of dimensions. And this is growing with 225 new structures each month. We preseed 5-7 levels for each of these structures. We use disk cache and have today approximately: - 25 000 000 tiles - 3 500 000 folders - 300 GB size on disk Database that holds the shiptails is PostgreSQL 9.3.4(64-bit) with PostGIS 2.1 on a Windows 2008 server. WMS service and MapCache is hosted on another Windows 2008 server. Any tips on where the most likely bottlenecks might be? Most interested in how to speed up preseeded tiles. Windows VS Linux, Hardware, config etc. Many thanks, Richard Hanssen -------------- next part -------------- An HTML attachment was scrubbed... URL: From jukka.rahkonen at maanmittauslaitos.fi Wed Oct 21 01:30:53 2015 From: jukka.rahkonen at maanmittauslaitos.fi (Rahkonen Jukka (MML)) Date: Wed, 21 Oct 2015 08:30:53 +0000 Subject: [mapserver-users] Ogrtileindex bug in Mapserver 7.0 Message-ID: <21c8bdb08aa144cdb18c4f4caf75c16c@C119S212VM022.msvyvi.vaha.local> Hi, I was wondering why my ogrtileindex layer sometimes works but sometimes not. It appears that Mapserver is reading data from the shapefiles which are behind the ogrtileindex file only if the BBOX of the WMS GetMap request intersects the boundary of the vector tile. Mapserver version is 7.0.0 on Linux and GDAL version is 2.0.1, released 2015/09/15. The ogrtindex file is shapefile and it is defined in the mapfile as CONNECTIONTYPE OGR TILEINDEX "/tindex/heigthidx.shp,0" Can anybody suggest a quick workaround? -Jukka Rahkonen- -------------- next part -------------- An HTML attachment was scrubbed... URL: From jukka.rahkonen at maanmittauslaitos.fi Wed Oct 21 01:52:46 2015 From: jukka.rahkonen at maanmittauslaitos.fi (Rahkonen Jukka (MML)) Date: Wed, 21 Oct 2015 08:52:46 +0000 Subject: [mapserver-users] Ogrtileindex bug in Mapserver 7.0 Message-ID: <11d85020c2a941a6a6be27e6dc500890@C119S212VM022.msvyvi.vaha.local> Hi, The workaround is to use the native tileindex instead of using CONNECTIONTYPE OGR # CONNECTIONTYPE OGR TILEINDEX "/tindex/heigthidx.shp,0" I do not remember right now why I have preferred to read tileindex through OGR. -Jukka Rahkonen- L?hett?j?: Rahkonen Jukka (MML) L?hetetty: 21. lokakuuta 2015 11:31 Vastaanottaja: Mapserver-Users (mapserver-users at lists.osgeo.org) Aihe: Ogrtileindex bug in Mapserver 7.0 Hi, I was wondering why my ogrtileindex layer sometimes works but sometimes not. It appears that Mapserver is reading data from the shapefiles which are behind the ogrtileindex file only if the BBOX of the WMS GetMap request intersects the boundary of the vector tile. Mapserver version is 7.0.0 on Linux and GDAL version is 2.0.1, released 2015/09/15. The ogrtindex file is shapefile and it is defined in the mapfile as CONNECTIONTYPE OGR TILEINDEX "/tindex/heigthidx.shp,0" Can anybody suggest a quick workaround? -Jukka Rahkonen- -------------- next part -------------- An HTML attachment was scrubbed... URL: From lydon_chandra at technologyonecorp.com Thu Oct 8 06:31:45 2015 From: lydon_chandra at technologyonecorp.com (Lydon Chandra) Date: Thu, 8 Oct 2015 21:31:45 +0800 Subject: [mapserver-users] Shapefile spatial index challenge Message-ID: Hi List, How can we generate more quadrants for the spatial index for the Australia polygon below ? Using MapServer shptree, even forcing it to go to 50 level deep, the spatial index does not have more quadrants. More data and details at: http://www.evernote.com/l/AhrYASBGtqVOkJn0BLqZkceADvOsA_UBfvY/ [image: Inline image 1] Kind Regards, Don -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 45227 bytes Desc: not available URL: From matt at wildwalks.com Mon Oct 12 20:59:59 2015 From: matt at wildwalks.com (Matt McClelland) Date: Tue, 13 Oct 2015 14:59:59 +1100 Subject: [mapserver-users] Label formatting on GRID In-Reply-To: References: Message-ID: Hi All I am wanting to truncate (simplify) the grid numbering to match the grid reference users would use in the field. Looking at the top right (of the attached example) I would like 236000 to just display as 36 and 6263000 to just display as 63 In a perfect world I would love it to display like this a subscript (little) 2 followed by standard 36 = 236 and a subscript (little) 62 followed by standard 63 = 6263 Any suggestions ?? Thanks :) The attache map I generated using mapserver 7.0 The Grid map file is LAYER GROUP "default" NAME "grid" METADATA "DESCRIPTION" "Grid" END TYPE LINE STATUS ON CLASS NAME "Graticule" COLOR 100 100 100 LABEL COLOR 255 0 0 FONT sc TYPE truetype SIZE 8 POSITION AUTO PARTIALS FALSE FORCE TRUE BUFFER -10 OUTLINECOLOR 255 255 255 END END PROJECTION "init=epsg:28356" END GRID LABELFORMAT '%.0f' MININTERVAL 1000 END END # Layer Matt :)[image: Inline image 1] -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: mapserv (1).jpg Type: image/jpeg Size: 79286 bytes Desc: not available URL: From jukka.rahkonen at maanmittauslaitos.fi Wed Oct 21 01:16:41 2015 From: jukka.rahkonen at maanmittauslaitos.fi (Rahkonen Jukka (MML)) Date: Wed, 21 Oct 2015 08:16:41 +0000 Subject: [mapserver-users] Ogrtileindex bug in Mapserver 7.0 Message-ID: <37fe62101a75428ba7f5356269151c20@C119S212VM022.msvyvi.vaha.local> Hi, I was wondering why my ogrtileindex layer sometimes works but sometimes not. It appears that Mapserver is reading data from the shapefiles which are behind the ogrtileindex file only if the BBOX of the WMS GetMap request intersects the boundary of the vector tile. Mapserver version is 7.0.0 on Linux and GDAL version is 2.0.1, released 2015/09/15. The ogrtindex file is shapefile and it is defined in the mapfile as CONNECTIONTYPE OGR TILEINDEX "/tindex/heigthidx.shp,0" Can anybody suggest a quick workaround? -Jukka Rahkonen- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Ogrtileindex_bug_1.png Type: image/png Size: 45766 bytes Desc: Ogrtileindex_bug_1.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Ogrtileindex_bug_2.png Type: image/png Size: 25864 bytes Desc: Ogrtileindex_bug_2.png URL: From jukka.rahkonen at maanmittauslaitos.fi Thu Oct 22 01:07:36 2015 From: jukka.rahkonen at maanmittauslaitos.fi (Rahkonen Jukka (MML)) Date: Thu, 22 Oct 2015 08:07:36 +0000 Subject: [mapserver-users] Shapefile spatial index challenge Message-ID: <3170f84ee8054e93afbea7dfe39ef03f@C119S212VM022.msvyvi.vaha.local> Hi, I am not sure what you are aiming at. Your shapefile has 9 features. Shptree documentarion says ?The quadtree method breaks the file into 4 quadrants, recursively until only a few shapes are contained in each quadrant?. I guess that with the current shptree code it is impossible to build quadrants so that they would contain less than one feature. What actually is your issue? Perhaps there is something else to improve than fiddling with the indexing of partial features. -Jukka Rahkonen- Lydon Chandra wrote: Hi List, How can we generate more quadrants for the spatial index for the Australia polygon below ? Using MapServer shptree, even forcing it to go to 50 level deep, the spatial index does not have more quadrants. More data and details at: http://www.evernote.com/l/AhrYASBGtqVOkJn0BLqZkceADvOsA_UBfvY/ Kind Regards, Don -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.bonfort at gmail.com Thu Oct 22 01:10:18 2015 From: thomas.bonfort at gmail.com (thomas bonfort) Date: Thu, 22 Oct 2015 10:10:18 +0200 Subject: [mapserver-users] Ogrtileindex bug in Mapserver 7.0 In-Reply-To: <21c8bdb08aa144cdb18c4f4caf75c16c@C119S212VM022.msvyvi.vaha.local> References: <21c8bdb08aa144cdb18c4f4caf75c16c@C119S212VM022.msvyvi.vaha.local> Message-ID: It's not clear to me what your issue actually is.... > reading data from the shapefiles which are behind the ogrtileindex file only if the BBOX of the WMS GetMap request intersects the boundary of the vector tile ->why is that not the expected behavior? -> what do you mean by "vector tile" ? On 21 October 2015 at 10:30, Rahkonen Jukka (MML) wrote: > Hi, > > > > I was wondering why my ogrtileindex layer sometimes works but sometimes not. > It appears that Mapserver is reading data from the shapefiles which are > behind the ogrtileindex file only if the BBOX of the WMS GetMap request > intersects the boundary of the vector tile. Mapserver version is 7.0.0 on > Linux and GDAL version is 2.0.1, released 2015/09/15. The ogrtindex file is > shapefile and it is defined in the mapfile as > > > > CONNECTIONTYPE OGR > > TILEINDEX "/tindex/heigthidx.shp,0" > > > > Can anybody suggest a quick workaround? > > > > > > -Jukka Rahkonen- > > > _______________________________________________ > mapserver-users mailing list > mapserver-users at lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/mapserver-users From jukka.rahkonen at maanmittauslaitos.fi Thu Oct 22 01:39:48 2015 From: jukka.rahkonen at maanmittauslaitos.fi (Rahkonen Jukka (MML)) Date: Thu, 22 Oct 2015 08:39:48 +0000 Subject: [mapserver-users] Ogrtileindex bug in Mapserver 7.0 Message-ID: <3bd8611ab7aa43a0b673c2ad8a3a0427@C119S212VM022.msvyvi.vaha.local> Hi, I have loads of shapefiles on a disk and I have combined them into a single layer by creating an index shapefile with ogrtindex http://www.gdal.org/ogrtindex.html which is doing the same for the original vector datasets than gdaltindex for images by storing an envelope of each source dataset into the index file. "Vector tile" in my question means the envelope in the ogrtindex shapefile. The issue is that when I use CONNECTIONTYPE OGR and the BBOX of the GetMap request is totally inside of some envelope in the ogrtindex shapefile then Mapserver believes that BBOX contains no data. It only finds the envelopes (and finally the original vector data by following the file path that is stored into the LOCATION field) if BBOX is intersecting the boundary of an envelope. See my trial with ASCII graphics below, when BBOX is totally inside the envelope then no data are found. The key is that data are not found when BBOX intersects with the envelope (the interior of the polygon) but not with the boundary of the polygon. With native TILEINDEX access to vector data this issue does not happen. ------------------- | ----- ---- | | | BBOX | | reading data from the shapefiles which are behind the ogrtileindex > file only if the BBOX of the WMS GetMap request intersects the > boundary of the vector tile ->why is that not the expected behavior? -> what do you mean by "vector tile" ? On 21 October 2015 at 10:30, Rahkonen Jukka (MML) wrote: > Hi, > > > > I was wondering why my ogrtileindex layer sometimes works but sometimes not. > It appears that Mapserver is reading data from the shapefiles which > are behind the ogrtileindex file only if the BBOX of the WMS GetMap > request intersects the boundary of the vector tile. Mapserver version > is 7.0.0 on Linux and GDAL version is 2.0.1, released 2015/09/15. The > ogrtindex file is shapefile and it is defined in the mapfile as > > > > CONNECTIONTYPE OGR > > TILEINDEX "/tindex/heigthidx.shp,0" > > > > Can anybody suggest a quick workaround? > > > > > > -Jukka Rahkonen- > > > _______________________________________________ > mapserver-users mailing list > mapserver-users at lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/mapserver-users From thomas.bonfort at gmail.com Thu Oct 22 01:42:24 2015 From: thomas.bonfort at gmail.com (thomas bonfort) Date: Thu, 22 Oct 2015 10:42:24 +0200 Subject: [mapserver-users] Ogrtileindex bug in Mapserver 7.0 In-Reply-To: <3bd8611ab7aa43a0b673c2ad8a3a0427@C119S212VM022.msvyvi.vaha.local> References: <3bd8611ab7aa43a0b673c2ad8a3a0427@C119S212VM022.msvyvi.vaha.local> Message-ID: did this work OK with previous mapserver versions ? On 22 October 2015 at 10:39, Rahkonen Jukka (MML) wrote: > Hi, > > I have loads of shapefiles on a disk and I have combined them into a single layer by creating an index shapefile with ogrtindex http://www.gdal.org/ogrtindex.html which is doing the same for the original vector datasets than gdaltindex for images by storing an envelope of each source dataset into the index file. "Vector tile" in my question means the envelope in the ogrtindex shapefile. > > The issue is that when I use CONNECTIONTYPE OGR and the BBOX of the GetMap request is totally inside of some envelope in the ogrtindex shapefile then Mapserver believes that BBOX contains no data. It only finds the envelopes (and finally the original vector data by following the file path that is stored into the LOCATION field) if BBOX is intersecting the boundary of an envelope. See my trial with ASCII graphics below, when BBOX is totally inside the envelope then no data are found. The key is that data are not found when BBOX intersects with the envelope (the interior of the polygon) but not with the boundary of the polygon. With native TILEINDEX access to vector data this issue does not happen. > > > ------------------- > | ----- ---- | > | | BBOX | | | ---------- | > ------------------ > > -Jukka Rahkonen > > thomas Bonfort wrote: > > It's not clear to me what your issue actually is.... > >> reading data from the shapefiles which are behind the ogrtileindex >> file only if the BBOX of the WMS GetMap request intersects the >> boundary of the vector tile > > ->why is that not the expected behavior? > -> what do you mean by "vector tile" ? > > On 21 October 2015 at 10:30, Rahkonen Jukka (MML) wrote: >> Hi, >> >> >> >> I was wondering why my ogrtileindex layer sometimes works but sometimes not. >> It appears that Mapserver is reading data from the shapefiles which >> are behind the ogrtileindex file only if the BBOX of the WMS GetMap >> request intersects the boundary of the vector tile. Mapserver version >> is 7.0.0 on Linux and GDAL version is 2.0.1, released 2015/09/15. The >> ogrtindex file is shapefile and it is defined in the mapfile as >> >> >> >> CONNECTIONTYPE OGR >> >> TILEINDEX "/tindex/heigthidx.shp,0" >> >> >> >> Can anybody suggest a quick workaround? >> >> >> >> >> >> -Jukka Rahkonen- >> >> >> _______________________________________________ >> mapserver-users mailing list >> mapserver-users at lists.osgeo.org >> http://lists.osgeo.org/mailman/listinfo/mapserver-users From jukka.rahkonen at maanmittauslaitos.fi Thu Oct 22 02:06:37 2015 From: jukka.rahkonen at maanmittauslaitos.fi (Rahkonen Jukka (MML)) Date: Thu, 22 Oct 2015 09:06:37 +0000 Subject: [mapserver-users] Ogrtileindex bug in Mapserver 7.0 Message-ID: <41be00b744b4452c90101623a6e257d9@C119S212VM022.msvyvi.vaha.local> Hi, I believe it did work with v. 6.4 but I noticed the issue now when I was building a new dataset which has bigger envelopes which makes it more common that BBOX fits totally inside an envelope. We do not have any MS 6.x running any more so testing would mean some extra work. Last time vector tileindex system is probably touched because of this discussion: http://osgeo-org.1560.x6.nabble.com/GetFeatureInfo-error-with-native-vector-tileindex-td5155807.html -Jukka Rahkonen- thomas bonfort wrote: did this work OK with previous mapserver versions ? On 22 October 2015 at 10:39, Rahkonen Jukka (MML) wrote: > Hi, > > I have loads of shapefiles on a disk and I have combined them into a single layer by creating an index shapefile with ogrtindex http://www.gdal.org/ogrtindex.html which is doing the same for the original vector datasets than gdaltindex for images by storing an envelope of each source dataset into the index file. "Vector tile" in my question means the envelope in the ogrtindex shapefile. > > The issue is that when I use CONNECTIONTYPE OGR and the BBOX of the GetMap request is totally inside of some envelope in the ogrtindex shapefile then Mapserver believes that BBOX contains no data. It only finds the envelopes (and finally the original vector data by following the file path that is stored into the LOCATION field) if BBOX is intersecting the boundary of an envelope. See my trial with ASCII graphics below, when BBOX is totally inside the envelope then no data are found. The key is that data are not found when BBOX intersects with the envelope (the interior of the polygon) but not with the boundary of the polygon. With native TILEINDEX access to vector data this issue does not happen. > > > ------------------- > | ----- ---- | > | | BBOX | | | ---------- | > ------------------ > > -Jukka Rahkonen > > thomas Bonfort wrote: > > It's not clear to me what your issue actually is.... > >> reading data from the shapefiles which are behind the ogrtileindex >> file only if the BBOX of the WMS GetMap request intersects the >> boundary of the vector tile > > ->why is that not the expected behavior? > -> what do you mean by "vector tile" ? > > On 21 October 2015 at 10:30, Rahkonen Jukka (MML) wrote: >> Hi, >> >> >> >> I was wondering why my ogrtileindex layer sometimes works but sometimes not. >> It appears that Mapserver is reading data from the shapefiles which >> are behind the ogrtileindex file only if the BBOX of the WMS GetMap >> request intersects the boundary of the vector tile. Mapserver >> version is 7.0.0 on Linux and GDAL version is 2.0.1, released >> 2015/09/15. The ogrtindex file is shapefile and it is defined in the >> mapfile as >> >> >> >> CONNECTIONTYPE OGR >> >> TILEINDEX "/tindex/heigthidx.shp,0" >> >> >> >> Can anybody suggest a quick workaround? >> >> >> >> >> >> -Jukka Rahkonen- >> >> >> _______________________________________________ >> mapserver-users mailing list >> mapserver-users at lists.osgeo.org >> http://lists.osgeo.org/mailman/listinfo/mapserver-users From aperi2007 at gmail.com Thu Oct 22 13:13:58 2015 From: aperi2007 at gmail.com (Andrea Peri) Date: Thu, 22 Oct 2015 22:13:58 +0200 Subject: [mapserver-users] Using different datasets at different scales in the same layer Message-ID: Hi, Often we serve huge datasets in our wms services. To have a faster response, we usually done a secondary hidden layer with a simplified dataset and serve both using a group of two layers with complementary scales. This allow the serve to use the simplified dataset for lower scale and detailed dataset for higher scales. But this structure is boring and error prone to configure. I guess more better should be if possible have one only layer and declare in it two distinct datasets. One for lower scale and the other for higher scale. Is possible to do something like this in mapserver ? Thx. -- ----------------- Andrea Peri . . . . . . . . . qwerty ????? ----------------- From ready945 at gmail.com Thu Oct 22 13:20:03 2015 From: ready945 at gmail.com (ready945 at gmail.com) Date: Thu, 22 Oct 2015 22:20:03 +0200 Subject: [mapserver-users] Using different datasets at different scales in the same layer In-Reply-To: References: Message-ID: <562944F3.9040701@gmail.com> Hi, Maybe scale token can help you : http://mapserver.org/development/rfc/ms-rfc-86.html On 22/10/2015 22:13, Andrea Peri wrote: > Hi, > > Often we serve huge datasets in our wms services. > To have a faster response, we usually done a secondary hidden layer > with a simplified dataset and > serve both using a group of two layers with complementary scales. > > This allow the serve to use the simplified dataset for lower scale and > detailed dataset for higher scales. > > But this structure is boring and error prone to configure. > > I guess more better should be if possible > have one only layer and declare in it two distinct datasets. > One for lower scale and the other for higher scale. > > Is possible to do something like this in mapserver ? > > Thx. > From aperi2007 at gmail.com Thu Oct 22 13:57:46 2015 From: aperi2007 at gmail.com (Andrea Peri) Date: Thu, 22 Oct 2015 22:57:46 +0200 Subject: [mapserver-users] Using different datasets at different scales in the same layer In-Reply-To: <562944F3.9040701@gmail.com> References: <562944F3.9040701@gmail.com> Message-ID: Its seem really interesting . Thx. Il 22 ott 2015 22:20, "ready945 at gmail.com" ha scritto: > Hi, > > Maybe scale token can help you : > http://mapserver.org/development/rfc/ms-rfc-86.html > > On 22/10/2015 22:13, Andrea Peri wrote: > >> Hi, >> >> Often we serve huge datasets in our wms services. >> To have a faster response, we usually done a secondary hidden layer >> with a simplified dataset and >> serve both using a group of two layers with complementary scales. >> >> This allow the serve to use the simplified dataset for lower scale and >> detailed dataset for higher scales. >> >> But this structure is boring and error prone to configure. >> >> I guess more better should be if possible >> have one only layer and declare in it two distinct datasets. >> One for lower scale and the other for higher scale. >> >> Is possible to do something like this in mapserver ? >> >> Thx. >> >> > _______________________________________________ > 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 ben at ausvet.com.au Thu Oct 22 23:22:59 2015 From: ben at ausvet.com.au (Ben Madin) Date: Fri, 23 Oct 2015 14:22:59 +0800 Subject: [mapserver-users] Shapefile spatial index challenge In-Reply-To: References: Message-ID: <161C4075-CC21-4261-A635-F075B8AECD99@ausvet.com.au> G?day Lydon, I feel your pain, but there is little benefit to creating more quadrants. The idea (as I understand it - could be wrong) is to be able to use a (fast) bounding box to find the polygons to test, rather than having to test against every polygon using more complex algorithms. I suppose you could consider that if you want to find out if a point is in one or more of your polygons, the benefit of having more index squares. You only have 8 polygons (I presume) so this should limit you in most cases to only having to compare your ?point? with only a couple of polygons using the more complex algorithms. hth cheers Ben > On 2015-10-08, at 21:31 , Lydon Chandra wrote: > > Hi List, > > How can we generate more quadrants for the spatial index for the Australia polygon below ? > > Using MapServer shptree, even forcing it to go to 50 level deep, the spatial index does not have more quadrants. > > More data and details at: > http://www.evernote.com/l/AhrYASBGtqVOkJn0BLqZkceADvOsA_UBfvY/ > > > > > > Kind Regards, > Don > > > > > _______________________________________________ > 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. The average disclaimer at the bottom of an email is probably never read but contributes substantially to increasing the size of packet being sent through the internet and ultimately congestion. -------------- next part -------------- An HTML attachment was scrubbed... URL: From David.Fawcett at state.mn.us Fri Oct 23 09:20:14 2015 From: David.Fawcett at state.mn.us (Fawcett, David (MNIT)) Date: Fri, 23 Oct 2015 16:20:14 +0000 Subject: [mapserver-users] Shapefile spatial index challenge In-Reply-To: <161C4075-CC21-4261-A635-F075B8AECD99@ausvet.com.au> References: <161C4075-CC21-4261-A635-F075B8AECD99@ausvet.com.au> Message-ID: I have seen examples where for the purpose of overlay operations, someone chops up their large polys into smaller ones, each with an attribute that contains the id for the large poly. I don?t know if that would fit your use case. David. From: mapserver-users [mailto:mapserver-users-bounces at lists.osgeo.org] On Behalf Of Ben Madin Sent: Friday, October 23, 2015 1:23 AM To: Lydon Chandra Cc: mapserver-users at lists.osgeo.org Subject: Re: [mapserver-users] Shapefile spatial index challenge G?day Lydon, I feel your pain, but there is little benefit to creating more quadrants. The idea (as I understand it - could be wrong) is to be able to use a (fast) bounding box to find the polygons to test, rather than having to test against every polygon using more complex algorithms. I suppose you could consider that if you want to find out if a point is in one or more of your polygons, the benefit of having more index squares. You only have 8 polygons (I presume) so this should limit you in most cases to only having to compare your ?point? with only a couple of polygons using the more complex algorithms. hth cheers Ben On 2015-10-08, at 21:31 , Lydon Chandra > wrote: Hi List, How can we generate more quadrants for the spatial index for the Australia polygon below ? Using MapServer shptree, even forcing it to go to 50 level deep, the spatial index does not have more quadrants. More data and details at: http://www.evernote.com/l/AhrYASBGtqVOkJn0BLqZkceADvOsA_UBfvY/ Kind Regards, Don _______________________________________________ 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. The average disclaimer at the bottom of an email is probably never read but contributes substantially to increasing the size of packet being sent through the internet and ultimately congestion. -------------- next part -------------- An HTML attachment was scrubbed... URL: From emperor_stef at yahoo.gr Mon Oct 26 11:16:20 2015 From: emperor_stef at yahoo.gr (Stefanos Anastasiou) Date: Mon, 26 Oct 2015 18:16:20 +0000 (UTC) Subject: [mapserver-users] Encoding problem References: <635533167.4909945.1445883380388.JavaMail.yahoo@mail.yahoo.com> Message-ID: <635533167.4909945.1445883380388.JavaMail.yahoo@mail.yahoo.com> Hello everybody. I'm having a small issue with truetype and encoding in greek. Instead of normal letters I'm getting weird symbols or even shapes.? iconv -l | grep {GREEK | ?ISO-8859-7 | WINDOWS-1253} ? ? ? ? ?are all present in the system.? My Mapserver version:? MapServer version 7.0.0 OUTPUT=PNG OUTPUT=JPEG OUTPUT=KML SUPPORTS=PROJ SUPPORTS=AGG SUPPORTS=FREETYPE SUPPORTS=CAIRO SUPPORTS=ICONV SUPPORTS=XMP SUPPORTS=FRIBIDI SUPPORTS=WMS_SERVER SUPPORTS=WMS_CLIENT SUPPORTS=WFS_SERVER SUPPORTS=WFS_CLIENT SUPPORTS=WCS_SERVER SUPPORTS=SOS_SERVER SUPPORTS=FASTCGI SUPPORTS=GEOS INPUT=JPEG INPUT=POSTGIS INPUT=OGR INPUT=GDAL INPUT=SHAPEFILE My LABEL object in my code is the following: ? ? ? ? ? ?LABEL? ? ? ? ? ? ? ?TYPE truetype? ? ? ? ? ? ? ?FONT arial? ? ? ? ? ? ? ?SIZE 6? ? ? ? ? ? ? ?PARTIALS TRUE? ? ? ? ? ? ? ?ENCODING GREEK? ? ? ? ? ?END I also tried ENCODING ISO-8859-7 and WINDOWS-1253. But getting symbols instead of letters. The closest to human readable is with encoding UTF-8... but still.? I'm probably missing something here.What is the problem ?? -------------- next part -------------- An HTML attachment was scrubbed... URL: From woodbri at swoodbridge.com Mon Oct 26 11:24:54 2015 From: woodbri at swoodbridge.com (Stephen Woodbridge) Date: Mon, 26 Oct 2015 14:24:54 -0400 Subject: [mapserver-users] Encoding problem In-Reply-To: <635533167.4909945.1445883380388.JavaMail.yahoo@mail.yahoo.com> References: <635533167.4909945.1445883380388.JavaMail.yahoo@mail.yahoo.com> <635533167.4909945.1445883380388.JavaMail.yahoo@mail.yahoo.com> Message-ID: <562E6FF6.9010308@swoodbridge.com> Try dumping the shapefile like: dbfdump file.dbf > out.txt file out.txt The file command might give you some indication of the encoding. Also note that the ttf file that you are using must have glyphs for the characters you are trying to display otherwise you will get a black box or something eles strange. -Steve W On 10/26/2015 2:16 PM, Stefanos Anastasiou wrote: > Hello everybody. > > I'm having a small issue with truetype and encoding in greek. Instead of > normal letters I'm getting weird symbols or even shapes. > > iconv -l | grep {GREEK | ISO-8859-7 | WINDOWS-1253} are all > present in the system. > > > My Mapserver version: > > MapServer version 7.0.0 OUTPUT=PNG OUTPUT=JPEG OUTPUT=KML SUPPORTS=PROJ > SUPPORTS=AGG SUPPORTS=FREETYPE SUPPORTS=CAIRO SUPPORTS=ICONV > SUPPORTS=XMP SUPPORTS=FRIBIDI SUPPORTS=WMS_SERVER SUPPORTS=WMS_CLIENT > SUPPORTS=WFS_SERVER SUPPORTS=WFS_CLIENT SUPPORTS=WCS_SERVER > SUPPORTS=SOS_SERVER SUPPORTS=FASTCGI SUPPORTS=GEOS INPUT=JPEG > INPUT=POSTGIS INPUT=OGR INPUT=GDAL INPUT=SHAPEFILE > > > My LABEL object in my code is the following: > > LABEL > TYPE truetype > FONT arial > SIZE 6 > PARTIALS TRUE > ENCODING GREEK > END > > I also tried ENCODING ISO-8859-7 and WINDOWS-1253. But getting symbols > instead of letters. The closest to human readable is with encoding > UTF-8... but still. > > I'm probably missing something here.What is the problem ? > > > > > > > > _______________________________________________ > mapserver-users mailing list > mapserver-users at lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/mapserver-users > From thomas.bonfort at gmail.com Mon Oct 26 11:25:42 2015 From: thomas.bonfort at gmail.com (thomas bonfort) Date: Mon, 26 Oct 2015 19:25:42 +0100 Subject: [mapserver-users] Encoding problem In-Reply-To: <635533167.4909945.1445883380388.JavaMail.yahoo@mail.yahoo.com> References: <635533167.4909945.1445883380388.JavaMail.yahoo@mail.yahoo.com> <635533167.4909945.1445883380388.JavaMail.yahoo@mail.yahoo.com> Message-ID: Stefanos, First off, you *need* to know the encoding that's actually used by each datasource, there's no way of guessing that reliably programmatically. And since MapServer 7, the ENCODING keyword has been moved to the LAYER level: http://mapserver.org/development/rfc/ms-rfc-103.html If you have the possibility, and/or in the future, always use UTF8 inside your datasources. regards, thomas On 26 October 2015 at 19:16, Stefanos Anastasiou wrote: > Hello everybody. > > I'm having a small issue with truetype and encoding in greek. Instead of > normal letters I'm getting weird symbols or even shapes. > > iconv -l | grep {GREEK | ISO-8859-7 | WINDOWS-1253} are all > present in the system. > > > My Mapserver version: > > MapServer version 7.0.0 OUTPUT=PNG OUTPUT=JPEG OUTPUT=KML SUPPORTS=PROJ > SUPPORTS=AGG SUPPORTS=FREETYPE SUPPORTS=CAIRO SUPPORTS=ICONV SUPPORTS=XMP > SUPPORTS=FRIBIDI SUPPORTS=WMS_SERVER SUPPORTS=WMS_CLIENT SUPPORTS=WFS_SERVER > SUPPORTS=WFS_CLIENT SUPPORTS=WCS_SERVER SUPPORTS=SOS_SERVER SUPPORTS=FASTCGI > SUPPORTS=GEOS INPUT=JPEG INPUT=POSTGIS INPUT=OGR INPUT=GDAL INPUT=SHAPEFILE > > > My LABEL object in my code is the following: > > LABEL > TYPE truetype > FONT arial > SIZE 6 > PARTIALS TRUE > ENCODING GREEK > END > > I also tried ENCODING ISO-8859-7 and WINDOWS-1253. But getting symbols > instead of letters. The closest to human readable is with encoding UTF-8... > but still. > > I'm probably missing something here.What is the problem ? > > > > > > > _______________________________________________ > mapserver-users mailing list > mapserver-users at lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/mapserver-users From emperor_stef at yahoo.gr Mon Oct 26 11:56:57 2015 From: emperor_stef at yahoo.gr (Stefanos Anastasiou) Date: Mon, 26 Oct 2015 18:56:57 +0000 (UTC) Subject: [mapserver-users] =?utf-8?b?zqPPh861z4Q6ICBFbmNvZGluZyBwcm9ibGVt?= In-Reply-To: References: Message-ID: <247194146.4949970.1445885817109.JavaMail.yahoo@mail.yahoo.com> Thanks for the reply. Stephen: (it turned out I didn't have the shapelib installed. Do I have to recompile MapServer from scratch now?) dbfdump ?gives me this: ??out.txt: ISO-8859 text ? ? ? The glyph indeed exists. It's there Thomas: Thanks for the clarification. I wasn't aware of that. This encoding that dbfdump says I'm having is ISO-8859.. just that and of course iconv complains it's not supported. RFC suggests all characters should iconv'd to UTF-8. Am I right?? -Stefanos ???? 8:25 ?.?. ???????, 26 ????????? 2015, ?/? thomas bonfort ??????: Stefanos, First off, you *need* to know the encoding that's actually used by each datasource, there's no way of guessing that reliably programmatically. And since MapServer 7, the ENCODING keyword has been moved to the LAYER level: http://mapserver.org/development/rfc/ms-rfc-103.html If you have the possibility, and/or in the future, always use UTF8 inside your datasources. regards, thomas On 26 October 2015 at 19:16, Stefanos Anastasiou wrote: > Hello everybody. > > I'm having a small issue with truetype and encoding in greek. Instead of > normal letters I'm getting weird symbols or even shapes. > > iconv -l | grep {GREEK |? ISO-8859-7 | WINDOWS-1253}? ? ? ? ? are all > present in the system. > > > My Mapserver version: > > MapServer version 7.0.0 OUTPUT=PNG OUTPUT=JPEG OUTPUT=KML SUPPORTS=PROJ > SUPPORTS=AGG SUPPORTS=FREETYPE SUPPORTS=CAIRO SUPPORTS=ICONV SUPPORTS=XMP > SUPPORTS=FRIBIDI SUPPORTS=WMS_SERVER SUPPORTS=WMS_CLIENT SUPPORTS=WFS_SERVER > SUPPORTS=WFS_CLIENT SUPPORTS=WCS_SERVER SUPPORTS=SOS_SERVER SUPPORTS=FASTCGI > SUPPORTS=GEOS INPUT=JPEG INPUT=POSTGIS INPUT=OGR INPUT=GDAL INPUT=SHAPEFILE > > > My LABEL object in my code is the following: > >? ? ? ? ? ? LABEL >? ? ? ? ? ? ? ? TYPE truetype >? ? ? ? ? ? ? ? FONT arial >? ? ? ? ? ? ? ? SIZE 6 >? ? ? ? ? ? ? ? PARTIALS TRUE >? ? ? ? ? ? ? ? ENCODING GREEK >? ? ? ? ? ? END > > I also tried ENCODING ISO-8859-7 and WINDOWS-1253. But getting symbols > instead of letters. The closest to human readable is with encoding UTF-8... > but still. > > I'm probably missing something here.What is the problem ? > > > > > > > _______________________________________________ > 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 thomas.bonfort at gmail.com Mon Oct 26 12:11:02 2015 From: thomas.bonfort at gmail.com (thomas bonfort) Date: Mon, 26 Oct 2015 20:11:02 +0100 Subject: [mapserver-users] Encoding problem In-Reply-To: <247194146.4949970.1445885817109.JavaMail.yahoo@mail.yahoo.com> References: <247194146.4949970.1445885817109.JavaMail.yahoo@mail.yahoo.com> Message-ID: > RFC suggests all characters should iconv'd to > UTF-8. Am I right? If you're creating the datasource from scratch and have the choice, then yes, use UTF8. If you have an exisiting datasource you cannot modify, just set the LAYER->ENCODING to ISO-8859 (well, the one that is is supported by iconv) and the transormation to utf8 will be done automatically and internally by mapserver. -- thomas > > > -Stefanos > > > > > ???? 8:25 ?.?. ???????, 26 ????????? 2015, ?/? thomas bonfort > ??????: > > > Stefanos, > First off, you *need* to know the encoding that's actually used by > each datasource, there's no way of guessing that reliably > programmatically. And since MapServer 7, the ENCODING keyword has been > moved to the LAYER level: > http://mapserver.org/development/rfc/ms-rfc-103.html > If you have the possibility, and/or in the future, always use UTF8 > inside your datasources. > > regards, > thomas > > On 26 October 2015 at 19:16, Stefanos Anastasiou > wrote: >> Hello everybody. >> >> I'm having a small issue with truetype and encoding in greek. Instead of >> normal letters I'm getting weird symbols or even shapes. >> >> iconv -l | grep {GREEK | ISO-8859-7 | WINDOWS-1253} are all >> present in the system. >> >> >> My Mapserver version: >> >> MapServer version 7.0.0 OUTPUT=PNG OUTPUT=JPEG OUTPUT=KML SUPPORTS=PROJ >> SUPPORTS=AGG SUPPORTS=FREETYPE SUPPORTS=CAIRO SUPPORTS=ICONV SUPPORTS=XMP >> SUPPORTS=FRIBIDI SUPPORTS=WMS_SERVER SUPPORTS=WMS_CLIENT >> SUPPORTS=WFS_SERVER >> SUPPORTS=WFS_CLIENT SUPPORTS=WCS_SERVER SUPPORTS=SOS_SERVER >> SUPPORTS=FASTCGI >> SUPPORTS=GEOS INPUT=JPEG INPUT=POSTGIS INPUT=OGR INPUT=GDAL >> INPUT=SHAPEFILE >> >> >> My LABEL object in my code is the following: >> >> LABEL >> TYPE truetype >> FONT arial >> SIZE 6 >> PARTIALS TRUE >> ENCODING GREEK >> END >> >> I also tried ENCODING ISO-8859-7 and WINDOWS-1253. But getting symbols >> instead of letters. The closest to human readable is with encoding >> UTF-8... >> but still. >> >> I'm probably missing something here.What is the problem ? > >> >> >> >> >> >> >> _______________________________________________ >> mapserver-users mailing list >> mapserver-users at lists.osgeo.org >> http://lists.osgeo.org/mailman/listinfo/mapserver-users > > > From emperor_stef at yahoo.gr Mon Oct 26 12:37:48 2015 From: emperor_stef at yahoo.gr (Stefanos Anastasiou) Date: Mon, 26 Oct 2015 19:37:48 +0000 (UTC) Subject: [mapserver-users] =?utf-8?b?zqPPh861z4Q6ICBFbmNvZGluZyBwcm9ibGVt?= In-Reply-To: References: Message-ID: <304635979.4932141.1445888268536.JavaMail.yahoo@mail.yahoo.com> Well, apparently there's a problem with greek letters. ?I created a shapefile from scratch and saved it with UTF-8 encoding. A ".cpg" file is created along the shapefile as well that has only the "UTF-8" statement. I entered greek letters in the shapefile's field and used ? ?ENCODING UTF-8? in the layer level. ?Also dbfdump ?gives me UTF-8 Unicode text. Still getting weird symbols. The only readable letter is "?"? Thank you. -Stefanos ???? 9:11 ?.?. ???????, 26 ????????? 2015, ?/? thomas bonfort ??????: > RFC suggests all characters should iconv'd to > UTF-8. Am I right? If you're creating the datasource from scratch and have the choice, then yes, use UTF8. If you have an exisiting datasource you cannot modify, just set the LAYER->ENCODING to ISO-8859 (well, the one that is is supported by iconv) and the transormation to utf8 will be done automatically and internally by mapserver. -- thomas > > > -Stefanos > > > > > ???? 8:25 ?.?. ???????, 26 ????????? 2015, ?/? thomas bonfort > ??????: > > > Stefanos, > First off, you *need* to know the encoding that's actually used by > each datasource, there's no way of guessing that reliably > programmatically. And since MapServer 7, the ENCODING keyword has been > moved to the LAYER level: > http://mapserver.org/development/rfc/ms-rfc-103.html > If you have the possibility, and/or in the future, always use UTF8 > inside your datasources. > > regards, > thomas > > On 26 October 2015 at 19:16, Stefanos Anastasiou > wrote: >> Hello everybody. >> >> I'm having a small issue with truetype and encoding in greek. Instead of >> normal letters I'm getting weird symbols or even shapes. >> >> iconv -l | grep {GREEK |? ISO-8859-7 | WINDOWS-1253}? ? ? ? ? are all >> present in the system. >> >> >> My Mapserver version: >> >> MapServer version 7.0.0 OUTPUT=PNG OUTPUT=JPEG OUTPUT=KML SUPPORTS=PROJ >> SUPPORTS=AGG SUPPORTS=FREETYPE SUPPORTS=CAIRO SUPPORTS=ICONV SUPPORTS=XMP >> SUPPORTS=FRIBIDI SUPPORTS=WMS_SERVER SUPPORTS=WMS_CLIENT >> SUPPORTS=WFS_SERVER >> SUPPORTS=WFS_CLIENT SUPPORTS=WCS_SERVER SUPPORTS=SOS_SERVER >> SUPPORTS=FASTCGI >> SUPPORTS=GEOS INPUT=JPEG INPUT=POSTGIS INPUT=OGR INPUT=GDAL >> INPUT=SHAPEFILE >> >> >> My LABEL object in my code is the following: >> >>? ? ? ? ? ? LABEL >>? ? ? ? ? ? ? ? TYPE truetype >>? ? ? ? ? ? ? ? FONT arial >>? ? ? ? ? ? ? ? SIZE 6 >>? ? ? ? ? ? ? ? PARTIALS TRUE >>? ? ? ? ? ? ? ? ENCODING GREEK >>? ? ? ? ? ? END >> >> I also tried ENCODING ISO-8859-7 and WINDOWS-1253. But getting symbols >> instead of letters. The closest to human readable is with encoding >> UTF-8... >> but still. >> >> I'm probably missing something here.What is the problem ? > >> >> >> >> >> >> >> _______________________________________________ >> 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 thomas.bonfort at gmail.com Mon Oct 26 13:10:11 2015 From: thomas.bonfort at gmail.com (thomas bonfort) Date: Mon, 26 Oct 2015 21:10:11 +0100 Subject: [mapserver-users] Encoding problem In-Reply-To: <304635979.4932141.1445888268536.JavaMail.yahoo@mail.yahoo.com> References: <304635979.4932141.1445888268536.JavaMail.yahoo@mail.yahoo.com> Message-ID: The cpg file is not read/used by mapserver. In your case, and as Stephen pointed out, you should make sure that the font you are using with mapserver contains the glyphs for your greek glyphs. -- thomas On 26 October 2015 at 20:37, Stefanos Anastasiou wrote: > Well, apparently there's a problem with greek letters. I created a > shapefile from scratch and saved it with UTF-8 encoding. A ".cpg" file is > created along the shapefile as well that has only the "UTF-8" statement. I > entered greek letters in the shapefile's field and used > > ENCODING UTF-8 > > in the layer level. Also dbfdump gives me UTF-8 Unicode text. > > Still getting weird symbols. The only readable letter is "?" > > Thank you. > > -Stefanos > > > > > > > > ???? 9:11 ?.?. ???????, 26 ????????? 2015, ?/? thomas bonfort > ??????: > > >> RFC suggests all characters should iconv'd to >> UTF-8. Am I right? > If you're creating the datasource from scratch and have the choice, > then yes, use UTF8. If you have an exisiting datasource you cannot > modify, just set the LAYER->ENCODING to ISO-8859 (well, the one that > is is supported by iconv) and the transormation to utf8 will be done > automatically and internally by mapserver. > > -- > thomas > > >> >> >> -Stefanos >> >> >> >> >> ???? 8:25 ?.?. ???????, 26 ????????? 2015, ?/? thomas bonfort >> ??????: >> >> >> Stefanos, >> First off, you *need* to know the encoding that's actually used by >> each datasource, there's no way of guessing that reliably >> programmatically. And since MapServer 7, the ENCODING keyword has been >> moved to the LAYER level: >> http://mapserver.org/development/rfc/ms-rfc-103.html >> If you have the possibility, and/or in the future, always use UTF8 >> inside your datasources. >> >> regards, >> thomas >> >> On 26 October 2015 at 19:16, Stefanos Anastasiou >> wrote: >>> Hello everybody. >>> >>> I'm having a small issue with truetype and encoding in greek. Instead of >>> normal letters I'm getting weird symbols or even shapes. >>> >>> iconv -l | grep {GREEK | ISO-8859-7 | WINDOWS-1253} are all >>> present in the system. >>> >>> >>> My Mapserver version: >>> >>> MapServer version 7.0.0 OUTPUT=PNG OUTPUT=JPEG OUTPUT=KML SUPPORTS=PROJ >>> SUPPORTS=AGG SUPPORTS=FREETYPE SUPPORTS=CAIRO SUPPORTS=ICONV SUPPORTS=XMP >>> SUPPORTS=FRIBIDI SUPPORTS=WMS_SERVER SUPPORTS=WMS_CLIENT >>> SUPPORTS=WFS_SERVER >>> SUPPORTS=WFS_CLIENT SUPPORTS=WCS_SERVER SUPPORTS=SOS_SERVER >>> SUPPORTS=FASTCGI >>> SUPPORTS=GEOS INPUT=JPEG INPUT=POSTGIS INPUT=OGR INPUT=GDAL >>> INPUT=SHAPEFILE >>> >>> >>> My LABEL object in my code is the following: >>> >>> LABEL >>> TYPE truetype >>> FONT arial >>> SIZE 6 >>> PARTIALS TRUE >>> ENCODING GREEK >>> END >>> >>> I also tried ENCODING ISO-8859-7 and WINDOWS-1253. But getting symbols >>> instead of letters. The closest to human readable is with encoding >>> UTF-8... >>> but still. >>> >>> I'm probably missing something here.What is the problem ? >> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> mapserver-users mailing list >>> mapserver-users at lists.osgeo.org >>> http://lists.osgeo.org/mailman/listinfo/mapserver-users >> >> >> > > From edmar.moretti at gmail.com Mon Oct 26 13:36:29 2015 From: edmar.moretti at gmail.com (Moretti Edmar) Date: Mon, 26 Oct 2015 18:36:29 -0200 Subject: [mapserver-users] COMPOSITE opacity Message-ID: Hi. I'm using version 7 of MapServer but I can not set the opacity of a layer. I've tried several ways: $layer->set ("opacity", 40); $layer->compositer->set ("opacity", 40); $layer->compositer->opacity = 40; $layer->updateFromString('LAYER COMPOSITE OPACITY 40 END END'); I still fail. Any idea? There is documentation on how to use COMPOSITE with MapScript? -- Edmar Moretti http://www.edmarmoretti.com.br Skype: edmar.moretti gTalk: edmar.moretti -------------- next part -------------- An HTML attachment was scrubbed... URL: From lars.schylberg at blixtmail.se Mon Oct 26 14:39:18 2015 From: lars.schylberg at blixtmail.se (lars.schylberg at blixtmail.se) Date: Mon, 26 Oct 2015 22:39:18 +0100 Subject: [mapserver-users] Using different datasets at different scales in the same layer In-Reply-To: References: Message-ID: Hi Andrea, There are several ways to think about this. I had about the same issue two years ago. One way to get organized is to use ScribeUI (http://mapgears.github.io/scribeui/) or only the scribe preprocessor. Julien-Samuel Lacroixgave a good? talk about this at FOSS4G in Portland and I talked about this in my presentation at FOSS4G in Portland. The videos is available online. That gives You the possibility to define different cartography in different zoom levels and even use different data sets in different zoom level. ?It is like SCALETOKENs but even more sophisticated. Another way is to use separate WMS layers for different zoom levels and assemble everything with cascading WMS calls. There is good description in the German Mapserver Pro TIPPS ?from this year and last year (German FOSS4G) how this is done. ?There are performance penalties for using this method. A third option is to use brute force and draw small scale cartographic layers first then just continue to draw larger scale layers on top based on MAXSCALEDENOM. ?This requires that You have areas that are covering. ?This is a good approach if You have a national data set and then larger scale regional data set that is just patches, i.e. covering parts of the small scale national data set. ?Using this method, you could still show the national large scale data where no regional data is available. This is the method I prefer right now. ?There WAS a problem with this approach before that labels in the label cache could get mixed up. ?That was that labels from the national data set could show up in the larger scale presentation since the label cache is drawn last. ?But with Mapserver 7.0 there is a new processing command called ?PROCESSING FORCE_DRAW_LABEL_CACHE=FLUSH?. The usage is that I draw all layers in the national data set, then I include a dummy layer that flushes the label cache and then I continue to draw the more detailed data on top. This is in my mind the biggest improvement in Mapserver 7.0 !!!!! Thanks to Daniel and all the other developers. In my current use case I have 6 different sets of cartography (more and more detailed) with about 20 ? 50 layers in each set. ?I am doing label cache flush in between each set of layers. ?I get excellent performance with this method. A fourth option would be to use the the brute force method but to preprocess all your labeling layers and mask out the labels with holes in the large scale data set where the more detailed data comes on top. ?This is quite complicated to do,. so I prefer the third method with flushing the cache. A fifth option to organize things is to use an approach like the ?basemap example? (https://github.com/mapserver/basemaps)? to combine a lot of layers. Have fun Lars Schylberg -----Originalmeddelande----- > Fr?n: "Andrea Peri" > Till: mapserver-users at lists.osgeo.org > Datum: 2015-10-22 22:14 > ?mne: [mapserver-users] Using different datasets at different scales in the same layer > > Hi, > > Often we serve huge datasets in our wms services. > To have a faster response, we usually done a secondary hidden layer > with a simplified dataset and > serve both using a group of two layers with complementary scales. > > This allow the serve to use the simplified dataset for lower scale and > detailed dataset for higher scales. > > But this structure is boring and error prone to configure. > > I guess more better should be if possible > have one only layer and declare in it two distinct datasets. > One for lower scale and the other for higher scale. > > Is possible to do something like this in mapserver ? > > Thx. > > -- > ----------------- > Andrea Peri > . . . . . . . . . > qwerty ????? > ----------------- > _______________________________________________ > 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 lars.schylberg at blixtmail.se Mon Oct 26 14:54:52 2015 From: lars.schylberg at blixtmail.se (lars.schylberg at blixtmail.se) Date: Mon, 26 Oct 2015 22:54:52 +0100 Subject: [mapserver-users] Usage: PROCESSING FORCE_DRAW_LABEL_CACHE=FLUSH Message-ID: Since I mentioned the command ?PROCESSING FORCE_DRAW_LABEL_CACHE=FLUSH? in a previous entry I thought it could be good to describe how it is used. Maybe this could be the basis for some description in the manual. In my mind this is best improvement in Mapserver 7.0 The use case: To produce a WMS service where You could zoom in from a very small scale like Europe down to a very detailed city map. You only have detailed data in certain parts. One data set larger area like the Nordic countries 1:1M, one data set a nation like Sweden 250K and one detailed data set over one town 50K. I don't have detailed data in the other countries and I only have town data covering one town. The usage is like this: Draw all layers in the small scale data set without any MAXSCALEDENOM. Do a FORCE DRAW LABEL CACHE Draw all layer in the 250k data set on top with a MAXSCALEDENOM=500000, or whatever is good for each layer when You would like to turn on your data. Do another FORCE DRAW LABEL CACHE Draw all the layers in the 50k town data set on top of that with a MAXSCALEDENOM=70000 The following mapfile shows the principle for using the command. The example shows the effect of using and not using the FORCE DRAW LABEL CACHE command. Just run the example with shp2img. ---------------------------------------------------------------------------------------------------------------------------------------- MAP ?NAME FDLC # Author: Lars Schylberg,? 2015-09-26 # # Requires Mapserver 7-0 # # shp2img -m force_draw_label_cache.map -o without_force_label_cache.png -s 500 300 -e -80 42 -74 46 -l "towns big_city" # # Result is that the unwanted red Big City label is showing up on top of the Big city polygon. # # shp2img -m force_draw_label_cache.map -o with_force_label_cache.png -s 500 300? -e -80 42 -74 46 -l "towns force_cache big_city" # # Result is the wanted, label cache is drawn after the towns layer and the big_city polygon can draw its new label. # ?PROJECTION ? "init=epsg:4326" ?END ?SYMBOL ? NAME "circle" ? TYPE ellipse ? FILLED true ? POINTS ??? 1 1 ? END ?END ?WEB ? METADATA ?? "ows_enable_request" "*" ?? "ows_title" "foo server" ? END ?END ?LAYER ? NAME "towns" ? STATUS ON ? TYPE POINT ? FEATURE ??? POINTS -75 45 END ??? TEXT "Village" ? END ? FEATURE ??? POINTS -79 43 END ??? TEXT "Town" ? END ? FEATURE ??? POINTS -77 44 END ??? TEXT "Big City" ? END ? FEATURE ??? POINTS -75 43 END ??? TEXT "Village2" ? END? ? FEATURE ??? POINTS -79 45 END ??? TEXT "Town2" ? END ? CLASS ?? NAME "PopulatedPlaces" ?? STYLE ??? SYMBOL "circle" ??? SIZE 10 ??? COLOR 10 10 0 ?? END ?? LABEL ???? SIZE large ???? COLOR 255 0 0 ???? POSITION AUTO ???? FORCE TRUE ?? END ? END ?END # Layer ? ?LAYER ??? NAME "force_cache" ??? TYPE POINT ??? PROCESSING "FORCE_DRAW_LABEL_CACHE=FLUSH" ??? TRANSFORM FALSE ??? STATUS ON ??? FEATURE ????? POINTS 1 1 END ??? END ?END? # Layer ? ?LAYER ??? NAME "big_city" ??? TYPE POLYGON ??? FEATURE ??? ?? POINTS ??? ??? -78 44.5? ??? ??? -76 44.5? ??? ??? -76 43.5? ??? ??? -78 43.5?? ??? ??? -78 44.5 ?????? END ?????? TEXT 'Big City' ??? END ??? CLASS ?????? STYLE ????????? COLOR 255 250 0 ?????? END ?????? LABEL ??? ??? SIZE giant ??????? COLOR 0 0 0 ??????? POSITION AUTO ??????? FORCE TRUE ????? END? ??? END ? END # Layer END # Map -------------- next part -------------- An HTML attachment was scrubbed... URL: From lars.schylberg at blixtmail.se Mon Oct 26 15:25:00 2015 From: lars.schylberg at blixtmail.se (lars.schylberg at blixtmail.se) Date: Mon, 26 Oct 2015 23:25:00 +0100 Subject: [mapserver-users] Usage: PROCESSING FORCE_DRAW_LABEL_CACHE=FLUSH In-Reply-To: References: Message-ID: <6a1b0fcb98aa6da234640475eee79e37@blixtmail.se> Some more things that I just remembered:? Certain rules that You should have think about when You are flushing the label cache. The automatic label placement will be final for the underlying layers when the label cache is flushed. You have to be sure that new labels in the following layers have polygon features underneath. If You are using GROUP for the WMS layers, be sure to have the command PROCESSING "FORCE_DRAW_LABEL_CACHE=FLUSH"? in a GROUP that is always drawn. / Lars Schylberg -----Originalmeddelande----- Fr?n: lars.schylberg at blixtmail.se Till: mapserver-users at lists.osgeo.org Datum: 2015-10-26 22:54 ?mne: [mapserver-users] Usage: PROCESSING FORCE_DRAW_LABEL_CACHE=FLUSH Since I mentioned the command "PROCESSING FORCE_DRAW_LABEL_CACHE=FLUSH" in a previous entry I thought it could be good to describe how it is used. Maybe this could be the basis for some description in the manual. In my mind this is best improvement in Mapserver 7.0 The use case: To produce a WMS service where You could zoom in from a very small scale like Europe down to a very detailed city map. You only have detailed data in certain parts. One data set larger area like the Nordic countries 1:1M, one data set a nation like Sweden 250K and one detailed data set over one town 50K. I don't have detailed data in the other countries and I only have town data covering one town. The usage is like this: Draw all layers in the small scale data set without any MAXSCALEDENOM. Do a FORCE DRAW LABEL CACHE Draw all layer in the 250k data set on top with a MAXSCALEDENOM=500000, or whatever is good for each layer when You would like to turn on your data. Do another FORCE DRAW LABEL CACHE Draw all the layers in the 50k town data set on top of that with a MAXSCALEDENOM=70000 The following mapfile shows the principle for using the command. The example shows the effect of using and not using the FORCE DRAW LABEL CACHE command. Just run the example with shp2img. ---------------------------------------------------------------------------------------------------------------------------------------- MAP ?NAME FDLC # Author: Lars Schylberg,? 2015-09-26 # # Requires Mapserver 7-0 # # shp2img -m force_draw_label_cache.map -o without_force_label_cache.png -s 500 300 -e -80 42 -74 46 -l "towns big_city" # # Result is that the unwanted red Big City label is showing up on top of the Big city polygon. # # shp2img -m force_draw_label_cache.map -o with_force_label_cache.png -s 500 300? -e -80 42 -74 46 -l "towns force_cache big_city" # # Result is the wanted, label cache is drawn after the towns layer and the big_city polygon can draw its new label. # ?PROJECTION ? "init=epsg:4326" ?END ?SYMBOL ? NAME "circle" ? TYPE ellipse ? FILLED true ? POINTS ??? 1 1 ? END ?END ?WEB ? METADATA ?? "ows_enable_request" "*" ?? "ows_title" "foo server" ? END ?END ?LAYER ? NAME "towns" ? STATUS ON ? TYPE POINT ? FEATURE ??? POINTS -75 45 END ??? TEXT "Village" ? END ? FEATURE ??? POINTS -79 43 END ??? TEXT "Town" ? END ? FEATURE ??? POINTS -77 44 END ??? TEXT "Big City" ? END ? FEATURE ??? POINTS -75 43 END ??? TEXT "Village2" ? END? ? FEATURE ??? POINTS -79 45 END ??? TEXT "Town2" ? END ? CLASS ?? NAME "PopulatedPlaces" ?? STYLE ??? SYMBOL "circle" ??? SIZE 10 ??? COLOR 10 10 0 ?? END ?? LABEL ???? SIZE large ???? COLOR 255 0 0 ???? POSITION AUTO ???? FORCE TRUE ?? END ? END ?END # Layer ? ?LAYER ??? NAME "force_cache" ??? TYPE POINT ??? PROCESSING "FORCE_DRAW_LABEL_CACHE=FLUSH" ??? TRANSFORM FALSE ??? STATUS ON ??? FEATURE ????? POINTS 1 1 END ??? END ?END? # Layer ? ?LAYER ??? NAME "big_city" ??? TYPE POLYGON ??? FEATURE ??? ?? POINTS ??? ??? -78 44.5? ??? ??? -76 44.5? ??? ??? -76 43.5? ??? ??? -78 43.5?? ??? ??? -78 44.5 ?????? END ?????? TEXT 'Big City' ??? END ??? CLASS ?????? STYLE ????????? COLOR 255 250 0 ?????? END ?????? LABEL ??? ??? SIZE giant ??????? COLOR 0 0 0 ??????? POSITION AUTO ??????? FORCE TRUE ????? END? ??? END ? END # Layer END # Map _______________________________________________ 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 cora.berger at bezreg-koeln.nrw.de Tue Oct 27 01:01:37 2015 From: cora.berger at bezreg-koeln.nrw.de (Berger, Cora) Date: Tue, 27 Oct 2015 08:01:37 +0000 Subject: [mapserver-users] Cascaded WMS GetFeatureInfo Message-ID: <5D5AE574FB890744BCB91DE22F3A53C183193E43@vbrk21mx02.bezreg-koeln.nrw.de> Hello everybody, I am building a cascaded WMS. My layers all have connectiontype WMS and all of them use one layer of the same WMS as source. The only thing I change is the style of the original WMS. My problem is that the GetFeatureInfo does not cascade. I am using Mapserver 7.0. I read that the GetFeatureInfo request supports cascading. All requests are enabled in the metadata. Do I have to add a special tag in the metatada or layer section to "pass through" the GetFeatureInfo from the original WMS? Thanks for your help. Best regards ???????????????? Cora Berger ??????????????????????????? From thomas.bonfort at gmail.com Tue Oct 27 01:28:20 2015 From: thomas.bonfort at gmail.com (thomas bonfort) Date: Tue, 27 Oct 2015 09:28:20 +0100 Subject: [mapserver-users] COMPOSITE opacity In-Reply-To: References: Message-ID: Can you try with the tbonfort/compfilters branch and report back? On 26 October 2015 at 21:36, Moretti Edmar wrote: > Hi. > > I'm using version 7 of MapServer but I can not set the opacity of a layer. > I've tried several ways: > > $layer->set ("opacity", 40); > $layer->compositer->set ("opacity", 40); > $layer->compositer->opacity = 40; > $layer->updateFromString('LAYER COMPOSITE OPACITY 40 END END'); > > I still fail. > > Any idea? > There is documentation on how to use COMPOSITE with MapScript? > > -- > Edmar Moretti > http://www.edmarmoretti.com.br > Skype: edmar.moretti > gTalk: edmar.moretti > > _______________________________________________ > mapserver-users mailing list > mapserver-users at lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/mapserver-users From havard.tveite at nmbu.no Tue Oct 27 05:02:35 2015 From: havard.tveite at nmbu.no (Havard Tveite) Date: Tue, 27 Oct 2015 13:02:35 +0100 Subject: [mapserver-users] Usage: PROCESSING FORCE_DRAW_LABEL_CACHE=FLUSH In-Reply-To: References: Message-ID: <562F67DB.9030601@nmbu.no> It would be useful if someone (preferably a developer ...) could file a documentation issue for this (and issues for other enhancements that have not yet been documented). http://github.org/mapserver/docs H?vard On 26/10/2015 22:54:PM, lars.schylberg at blixtmail.se wrote: > Since I mentioned the command "PROCESSING FORCE_DRAW_LABEL_CACHE=FLUSH" in a previous entry I thought it could be good to describe how it is used. Maybe this could be the basis for some description in the manual. > > In my mind this is best improvement in Mapserver 7.0 > > The use case: > > To produce a WMS service where You could zoom in from a very small scale like Europe down to a very detailed city map. You only have detailed data in certain parts. > > One data set larger area like the Nordic countries 1:1M, one data set a nation like Sweden 250K and one detailed data set over one town 50K. I don't have detailed data in the other countries and I only have town data covering one town. > > The usage is like this: > > Draw all layers in the small scale data set without any MAXSCALEDENOM. > > Do a FORCE DRAW LABEL CACHE > > Draw all layer in the 250k data set on top with a MAXSCALEDENOM=500000, or whatever is good for each layer when You would like to turn on your data. > > Do another FORCE DRAW LABEL CACHE > > Draw all the layers in the 50k town data set on top of that with a MAXSCALEDENOM=70000 > > The following mapfile shows the principle for using the command. The example shows the effect of using and not using the FORCE DRAW LABEL CACHE command. Just run the example with shp2img. > > ---------------------------------------------------------------------------------------------------------------------------------------- > > MAP > NAME FDLC > > # Author: Lars Schylberg, 2015-09-26 > # > # Requires Mapserver 7-0 > # > # shp2img -m force_draw_label_cache.map -o without_force_label_cache.png -s 500 300 -e -80 42 -74 46 -l "towns big_city" > # > # Result is that the unwanted red Big City label is showing up on top of the Big city polygon. > # > # shp2img -m force_draw_label_cache.map -o with_force_label_cache.png -s 500 300 -e -80 42 -74 46 -l "towns force_cache big_city" > # > # Result is the wanted, label cache is drawn after the towns layer and the big_city polygon can draw its new label. > # > PROJECTION > "init=epsg:4326" > END > > SYMBOL > NAME "circle" > TYPE ellipse > FILLED true > POINTS > 1 1 > END > END > > WEB > METADATA > "ows_enable_request" "*" > "ows_title" "foo server" > END > END > > LAYER > NAME "towns" > STATUS ON > TYPE POINT > FEATURE > POINTS -75 45 END > TEXT "Village" > END > FEATURE > POINTS -79 43 END > TEXT "Town" > END > FEATURE > POINTS -77 44 END > TEXT "Big City" > END > FEATURE > POINTS -75 43 END > TEXT "Village2" > END > FEATURE > POINTS -79 45 END > TEXT "Town2" > END > CLASS > NAME "PopulatedPlaces" > STYLE > SYMBOL "circle" > SIZE 10 > COLOR 10 10 0 > END > LABEL > SIZE large > COLOR 255 0 0 > POSITION AUTO > FORCE TRUE > END > END > END # Layer > > LAYER > NAME "force_cache" > TYPE POINT > PROCESSING "FORCE_DRAW_LABEL_CACHE=FLUSH" > TRANSFORM FALSE > STATUS ON > FEATURE > POINTS 1 1 END > END > END # Layer > > LAYER > NAME "big_city" > TYPE POLYGON > FEATURE > POINTS > -78 44.5 > -76 44.5 > -76 43.5 > -78 43.5 > -78 44.5 > END > TEXT 'Big City' > END > CLASS > STYLE > COLOR 255 250 0 > END > LABEL > SIZE giant > COLOR 0 0 0 > POSITION AUTO > FORCE TRUE > END > END > END # Layer > END # Map > > > > > > _______________________________________________ > 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 Oct 27 06:09:46 2015 From: richard.greenwood at gmail.com (Richard Greenwood) Date: Tue, 27 Oct 2015 07:09:46 -0600 Subject: [mapserver-users] No Layers when configuring TinyOWS with a Mapserver (.map) File In-Reply-To: References: Message-ID: I am also unable to get tinyows to work using a map file, even with the example map file from the documentation. I have both the example and my own layer working with an XML file, so I believe there is either a bug with map file support or something missing from the documentation. Regardless of whether I have a valid or invalid map file tinyows always returns: Unknown layer name I've tested with both an OpenLayers web interface and with QGIS. I built 1.1.1 from source on Ubuntu 14.04. Can anyone suggests steps that I should take to narrow down the problem more? Thanks, Rich On Mon, Oct 12, 2015 at 4:26 AM, Balajee R.C wrote: > Am trying to expose a vector layer (loaded from shape file into PostGIS) > as a WFS layer using tinyows. > > Following the instructions in the mapserver/tinyows documentation, here is > the .map file I have come up with so far: > > MAP > NAME "world" > CONFIG "MS_ERRORFILE" > "/home/balajeerc/Projects/Build_Dir/myproject/data/logs/mapservice_errors.log" > EXTENT -180.000 -90.000 180.000 90.000 > > WEB > METADATA > "tinyows_schema_dir" > "/home/balajeerc/Projects/Build_Dir/myproject/deps/mygis-services-0.1/data/schema" > "tinyows_onlineresource" " > http://192.168.43.164:19090/vectors/world/wfs?" > "wfs_title" "MyGIS Feature Service: World" > "wfs_contact" "support at giscompany.com" > "wms_title" "MyGIS Feature Service: World" > "wms_srs" "epsg:4326" > "wms_enable_request" "*" > "log_level" "15" > "log" > "/home/balajeerc/Projects/Build_Dir/myproject/deps/mygis-services-0.1/data/logs/wfs_world.log" > "ows_contactorganization" "MyCompany" > "ows_contactelectronicmailaddress" "contact at giscompany.com > " > "ows_contactperson" "Balajee.R.C" > END > END > > PROJECTION > "init=epsg:4326" > END > > LAYER > NAME 'world_boundaries' > CONNECTIONTYPE postgis > CONNECTION "host=localhost user=mygis password=asdf123 > dbname=mygis port=19095" > DATA "geom from world_boundaries" > TYPE POLYGON > METADATA > 'wfs_title' 'world_boundaries' > 'wfs_namespace_prefix' 'tows' > 'wfs_namespace_uri' 'http://www.giscompany.com/' > 'wfs_srs' 'epsg:4326' > 'wms_srs' 'epsg:4326' > 'wms_title' 'world_boundaries' > 'tinyows_table' 'world_boundaries' > 'tinyows_writable' '1' > 'tinyows_retrievable' '1' > END > CLASS > STYLE > COLOR 128 128 128 > ANTIALIAS true > END > END > PROJECTION > "init=epsg:4326" > END > DUMP TRUE > END > END > > This .map file works fine with mapserver, i.e. I am able to render the > feature layer as a WMS service using QGIS as a client. > > However, the WFS service (served by tinyows) using the same file (set > using `TINYOWS_MAPFILE` environment variable seems to show no layers in > GetCapabilities (and hence QGIS is not able to load any). > > The output from `tinyows --check` is as follows: > > balajeerc at Balajee:~/Projects/tinyows-1.1.1$ ./tinyows --check > TinyOWS version: 1.1.0 > FCGI support: Yes > Config File Path: > /home/balajeerc/Projects/Build_Dir/myproject/data/service_data/data/wfs/world.map > (Mapfile) > PostGIS Version: 2.1.8 > PostGIS dsn: host=localhost user=mygis password=asdf123 > dbname=mygis port=19095 > Output Encoding: UTF-8 > Database Encoding: UTF8 > Schema dir: > /home/balajeerc/Projects/Build_Dir/myproject/deps/mygis-services-0.1/data/schema > Display bbox: Yes > Estimated extent: No > Check schema: Yes > Check valid geoms: Yes > Available layers: > balajeerc at Balajee:~/Projects/tinyows-1.1.1$ > > Note that even though I am using a 1.1.1 version of tinyows, it prints > tinyows version as 1.1.0. Also note that it prints no layers. > > Wondering what is going wrong, I decided to step into the code. I > recompiled code after turning off (`-O2`) optimizations and with debugging > (`-g`) enabled. > > I am only able to get so far as the `ows_parse_config` method in > `src/ows/ows_config.c`. I am, for some reason not able to step into > `ows_parse_config_map` in `src/mapfile/mapfile.c`. This probably has > something to do with the fact that `mapfile.c` is generated by flex using > `src/map/mapfile.l`. > > At this point I am completely stuck and at a brick wall as to what might > be going wrong. Can someone here please help? > > TinyOWS version: 1.1.1 (Release > ) > > Regards, > Balajee.R.C > > > _______________________________________________ > mapserver-users mailing list > mapserver-users at lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/mapserver-users > -- Richard W. Greenwood, PLS www.greenwoodmap.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From emperor_stef at yahoo.gr Tue Oct 27 14:32:33 2015 From: emperor_stef at yahoo.gr (Stefanos Anastasiou) Date: Tue, 27 Oct 2015 21:32:33 +0000 (UTC) Subject: [mapserver-users] =?utf-8?b?zqPPh861z4Q6ICBFbmNvZGluZyBwcm9ibGVt?= In-Reply-To: References: Message-ID: <1343704471.5970876.1445981553652.JavaMail.yahoo@mail.yahoo.com> Yes, glyphs are there. I also tried two different glyphs in .ttf but still not working.I can't imagine what else could be wrong Thank you..!! ???? 10:10 ?.?. ???????, 26 ????????? 2015, ?/? thomas bonfort ??????: The cpg file is not read/used by mapserver. In your case, and as Stephen pointed out, you should make sure that the font you are using with mapserver contains the glyphs for your greek glyphs. -- thomas On 26 October 2015 at 20:37, Stefanos Anastasiou wrote: > Well, apparently there's a problem with greek letters.? I created a > shapefile from scratch and saved it with UTF-8 encoding. A ".cpg" file is > created along the shapefile as well that has only the "UTF-8" statement. I > entered greek letters in the shapefile's field and used > >? ? ENCODING UTF-8 > > in the layer level.? Also dbfdump? gives me UTF-8 Unicode text. > > Still getting weird symbols. The only readable letter is "?" > > Thank you. > > -Stefanos > > > > > > > > ???? 9:11 ?.?. ???????, 26 ????????? 2015, ?/? thomas bonfort > ??????: > > >> RFC suggests all characters should iconv'd to >> UTF-8. Am I right? > If you're creating the datasource from scratch and have the choice, > then yes, use UTF8. If you have an exisiting datasource you cannot > modify, just set the LAYER->ENCODING to ISO-8859 (well, the one that > is is supported by iconv) and the transormation to utf8 will be done > automatically and internally by mapserver. > > -- > thomas > > >> >> >> -Stefanos >> >> >> >> >> ???? 8:25 ?.?. ???????, 26 ????????? 2015, ?/? thomas bonfort >> ??????: >> >> >> Stefanos, >> First off, you *need* to know the encoding that's actually used by >> each datasource, there's no way of guessing that reliably >> programmatically. And since MapServer 7, the ENCODING keyword has been >> moved to the LAYER level: >> http://mapserver.org/development/rfc/ms-rfc-103.html >> If you have the possibility, and/or in the future, always use UTF8 >> inside your datasources. >> >> regards, >> thomas >> >> On 26 October 2015 at 19:16, Stefanos Anastasiou >> wrote: >>> Hello everybody. >>> >>> I'm having a small issue with truetype and encoding in greek. Instead of >>> normal letters I'm getting weird symbols or even shapes. >>> >>> iconv -l | grep {GREEK |? ISO-8859-7 | WINDOWS-1253}? ? ? ? ? are all >>> present in the system. >>> >>> >>> My Mapserver version: >>> >>> MapServer version 7.0.0 OUTPUT=PNG OUTPUT=JPEG OUTPUT=KML SUPPORTS=PROJ >>> SUPPORTS=AGG SUPPORTS=FREETYPE SUPPORTS=CAIRO SUPPORTS=ICONV SUPPORTS=XMP >>> SUPPORTS=FRIBIDI SUPPORTS=WMS_SERVER SUPPORTS=WMS_CLIENT >>> SUPPORTS=WFS_SERVER >>> SUPPORTS=WFS_CLIENT SUPPORTS=WCS_SERVER SUPPORTS=SOS_SERVER >>> SUPPORTS=FASTCGI >>> SUPPORTS=GEOS INPUT=JPEG INPUT=POSTGIS INPUT=OGR INPUT=GDAL >>> INPUT=SHAPEFILE >>> >>> >>> My LABEL object in my code is the following: >>> >>>? ? ? ? ? ? LABEL >>>? ? ? ? ? ? ? ? TYPE truetype >>>? ? ? ? ? ? ? ? FONT arial >>>? ? ? ? ? ? ? ? SIZE 6 >>>? ? ? ? ? ? ? ? PARTIALS TRUE >>>? ? ? ? ? ? ? ? ENCODING GREEK >>>? ? ? ? ? ? END >>> >>> I also tried ENCODING ISO-8859-7 and WINDOWS-1253. But getting symbols >>> instead of letters. The closest to human readable is with encoding >>> UTF-8... >>> but still. >>> >>> I'm probably missing something here.What is the problem ? >> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> 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 edmar.moretti at gmail.com Tue Oct 27 18:17:35 2015 From: edmar.moretti at gmail.com (Moretti Edmar) Date: Tue, 27 Oct 2015 23:17:35 -0200 Subject: [mapserver-users] COMPOSITE opacity In-Reply-To: References: Message-ID: Hi Thomas. Unfortunately I can not compile MapServer. I use versions available for Ubuntu 15-10. I develop software called i3Geo, which is based on MapServer and PHP-MapScript and many people use the available versions with "apt-get install ..." to prepare the web server. The solution I found was to use OPACITY for classes instead of layers, but it is not a good solution. Another problem: when I use cgi-bin/mapserv and COMPOSITE OPACITY everything works, but only for OPACITY, other filters do not work. I tested with this mapfile (cgi-bin/mapserv?map=...&mode=map ): MAP FONTSET "/var/www/i3geo/symbols/fontes.txt" SYMBOLSET "/var/www/i3geo/symbols/simbolosv7.sym" SHAPEPATH "/var/www/geodados" IMAGECOLOR 104 171 195 MAXSIZE 4096 IMAGETYPE AGG_Q #Brasil EXTENT -76.5125927 -39.3925675209 -29.5851853 9.49014852081 SIZE 480 500 STATUS ON UNITS DD NAME "GERAL" DEBUG OFF OUTPUTFORMAT NAME 'AGG_Q' DRIVER AGG/PNG IMAGEMODE RGB FORMATOPTION "QUANTIZE_FORCE=ON" FORMATOPTION "QUANTIZE_DITHER=OFF" FORMATOPTION "QUANTIZE_COLORS=256" FORMATOPTION "INTERLACE=OFF" END PROJECTION "+proj=longlat +ellps=GRS67 +no_defs" END WEB #edite o caminho se a aplicacao for movida de lugar IMAGEPATH "/tmp/ms_tmp/" IMAGEURL "/ms_tmp/" TEMPLATE "" END LAYER DATA "/var/www/i3geo/aplicmap/dados/mundo" NAME "mundo" STATUS DEFAULT TYPE POLYGON CLASS NAME "" STYLE COLOR 230 230 230 OUTLINECOLOR 255 255 255 END END END LAYER DATA "/var/www/i3geo/aplicmap/dados/estados" NAME "estados" STATUS DEFAULT TRANSPARENCY 100 TYPE POLYGON COMPOSITE OPACITY 50 END CLASS NAME " " STYLE COLOR 232 220 201 MAXSIZE 100 MINSIZE 1 SIZE 1 SYMBOL 0 END END END END My configuration of MapServer is: MapServer version 7.0.0 OUTPUT=PNG OUTPUT=JPEG OUTPUT=KML SUPPORTS=PROJ SUPPORTS=AGG SUPPORTS=FREETYPE SUPPORTS=CAIRO SUPPORTS=SVG_SYMBOLS SUPPORTS=RSVG SUPPORTS=ICONV SUPPORTS=FRIBIDI SUPPORTS=WMS_SERVER SUPPORTS=WMS_CLIENT SUPPORTS=WFS_SERVER SUPPORTS=WFS_CLIENT SUPPORTS=WCS_SERVER SUPPORTS=SOS_SERVER SUPPORTS=FASTCGI SUPPORTS=THREADS SUPPORTS=GEOS INPUT=JPEG INPUT=POSTGIS INPUT=OGR INPUT=GDAL INPUT=SHAPEFILE 2015-10-27 6:28 GMT-02:00 thomas bonfort : > Can you try with the tbonfort/compfilters branch and report back? > > On 26 October 2015 at 21:36, Moretti Edmar > wrote: > > Hi. > > > > I'm using version 7 of MapServer but I can not set the opacity of a > layer. > > I've tried several ways: > > > > $layer->set ("opacity", 40); > > $layer->compositer->set ("opacity", 40); > > $layer->compositer->opacity = 40; > > $layer->updateFromString('LAYER COMPOSITE OPACITY 40 END END'); > > > > I still fail. > > > > Any idea? > > There is documentation on how to use COMPOSITE with MapScript? > > > > -- > > Edmar Moretti > > http://www.edmarmoretti.com.br > > Skype: edmar.moretti > > gTalk: edmar.moretti > > > > _______________________________________________ > > mapserver-users mailing list > > mapserver-users at lists.osgeo.org > > http://lists.osgeo.org/mailman/listinfo/mapserver-users > -- Edmar Moretti http://www.edmarmoretti.com.br Skype: edmar.moretti gTalk: edmar.moretti -------------- next part -------------- An HTML attachment was scrubbed... URL: From jukka.rahkonen at maanmittauslaitos.fi Wed Oct 28 00:10:44 2015 From: jukka.rahkonen at maanmittauslaitos.fi (Rahkonen Jukka (MML)) Date: Wed, 28 Oct 2015 07:10:44 +0000 Subject: [mapserver-users] DATA "table" does not find FID for WFS Message-ID: Hi, I have noticed with Mapserver 7.0 that WFS server does not find the "gml_featureid" column if I define DATA this way: CONNECTIONTYPE OGR CONNECTION "\ms4w\apps\wms-wfs.sqlite" DATA "states" This gives a warning into GML sent by GetFeature and featureMembers are without fid This leads to correct result: CONNECTIONTYPE OGR CONNECTION "\ms4w\apps\wms-wfs.sqlite" DATA "select * from states" Documentation http://www.mapserver.org/input/vector/ogr.html does not warn that defining data as "layer_name" vs. "select * from layer" could make a difference. Ogrinfo finds the FID column and reports it as: FID Column = PK_UID PK_UID is defined in the table as CREATE TABLE states ( PK_UID INTEGER PRIMARY KEY AUTOINCREMENT, This looks like a bug but I am not sure if it is a Mapserver bug of GDAL bug and if it affects only Spatialite. -Jukka Rahkonen- -------------- next part -------------- An HTML attachment was scrubbed... URL: From jukka.rahkonen at maanmittauslaitos.fi Wed Oct 28 02:31:16 2015 From: jukka.rahkonen at maanmittauslaitos.fi (Rahkonen Jukka (MML)) Date: Wed, 28 Oct 2015 09:31:16 +0000 Subject: [mapserver-users] Update Mapserver at demo.mapserver.org? Message-ID: <77589662baf8422c91ba593383e68f63@C119S212VM022.msvyvi.vaha.local> Hi, I wrote last year https://lists.osgeo.org/pipermail/mapserver-users/2014-May/076442.html and asked if it could be possible to update the Mapserver v. 5.6.5 that is running at http://demo.mapserver.org/cgi-bin/wms and I was told that not before general infrastructure transition is over, see http://wiki.osgeo.org/wiki/Infrastructure_Transition_Plan_2014 What it the situation now? It would be good to have some Mapserver 7.0 WMS, WFS, and WCS services online for testing the issues which are reported on the mailing list and in the Github issue tracker. Version 5.6.5 is rather useless for that. -Jukka Rahkonen- -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon at templer.cc Wed Oct 28 02:24:20 2015 From: simon at templer.cc (Simon Templer) Date: Wed, 28 Oct 2015 10:24:20 +0100 Subject: [mapserver-users] Mapserver and Complex Feature support Message-ID: <56309444.9060601@templer.cc> Hi all, I'm trying to find out if and how Mapserver can be used to serve Complex Features via WFS 2.0. It's great news that with Mapserver 7 WFS 2.0 is supported, but so far I didn't have any luck in finding any particular documentation for how to handle complex features or even an example. Could be that I'm looking in the wrong places or use the wrong search terms (or it's just my general ignorance regarding Mapserver), so I would be very happy if someone could give a brief overview on the status in Mapserver regarding complex features or at least point me in the right direction. For both GeoServer (with app-schema extension) and deegree I know that they each use a specific mapping configuration to describe the mapping between database (or other data source) to the GML Application Schema (for instance from INSPIRE). Is there something similar done in Mapserver, for instance as part of a Mapfile? Thanks Kind regards, Simon From even.rouault at spatialys.com Wed Oct 28 02:46:56 2015 From: even.rouault at spatialys.com (Even Rouault) Date: Wed, 28 Oct 2015 10:46:56 +0100 Subject: [mapserver-users] Mapserver and Complex Feature support In-Reply-To: <56309444.9060601@templer.cc> References: <56309444.9060601@templer.cc> Message-ID: <201510281046.56520.even.rouault@spatialys.com> Le mercredi 28 octobre 2015 10:24:20, Simon Templer a ?crit : > Hi all, > > I'm trying to find out if and how Mapserver can be used to serve Complex > Features via WFS 2.0. Complex Features are not really supported. You could perhaps have some success for GetFeature output by using template-driven output : http://mapserver.org/output/template_output.html . But I haven't tried myself and I guess that would only work for not too complex features. And DescribeFeatureType would produce only a schema for simple features. > It's great news that with Mapserver 7 WFS 2.0 is > supported, but so far I didn't have any luck in finding any particular > documentation for how to handle complex features or even an example. > Could be that I'm looking in the wrong places or use the wrong search > terms (or it's just my general ignorance regarding Mapserver), so I > would be very happy if someone could give a brief overview on the status > in Mapserver regarding complex features or at least point me in the > right direction. > > For both GeoServer (with app-schema extension) and deegree I know that > they each use a specific mapping configuration to describe the mapping > between database (or other data source) to the GML Application Schema > (for instance from INSPIRE). Is there something similar done in > Mapserver, for instance as part of a Mapfile? > > Thanks > > Kind regards, > Simon > _______________________________________________ > 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 Oct 28 02:49:49 2015 From: even.rouault at spatialys.com (Even Rouault) Date: Wed, 28 Oct 2015 10:49:49 +0100 Subject: [mapserver-users] DATA "table" does not find FID for WFS In-Reply-To: References: Message-ID: <201510281049.49751.even.rouault@spatialys.com> Le mercredi 28 octobre 2015 08:10:44, Rahkonen Jukka (MML) a ?crit : > Hi, > > I have noticed with Mapserver 7.0 that WFS server does not find the > "gml_featureid" column if I define DATA this way: > > CONNECTIONTYPE OGR > CONNECTION "\ms4w\apps\wms-wfs.sqlite" > DATA "states" > > This gives a warning into GML sent by GetFeature > > and featureMembers are without fid > > > > This leads to correct result: > > CONNECTIONTYPE OGR > CONNECTION "\ms4w\apps\wms-wfs.sqlite" > DATA "select * from states" > > > > > Documentation http://www.mapserver.org/input/vector/ogr.html does not warn > that defining data as "layer_name" vs. "select * from layer" could make a > difference. Ogrinfo finds the FID column and reports it as: FID Column = > PK_UID > > PK_UID is defined in the table as > CREATE TABLE states ( > PK_UID INTEGER PRIMARY KEY AUTOINCREMENT, > > > This looks like a bug but I am not sure if it is a Mapserver bug of GDAL > bug and if it affects only Spatialite. You didn't specify which GDAL version is used. That could possibly be the following bug that was fixed in 1.11.2 and 2.0: * make GetFIDColumn() work when run as first method call (#5781) > > -Jukka Rahkonen- -- Spatialys - Geospatial professional services http://www.spatialys.com From simon at templer.cc Wed Oct 28 03:29:13 2015 From: simon at templer.cc (Simon Templer) Date: Wed, 28 Oct 2015 11:29:13 +0100 Subject: [mapserver-users] Mapserver and Complex Feature support In-Reply-To: <201510281046.56520.even.rouault@spatialys.com> References: <56309444.9060601@templer.cc> <201510281046.56520.even.rouault@spatialys.com> Message-ID: <5630A379.2030702@templer.cc> On 28.10.2015 10:46, Even Rouault wrote: > Le mercredi 28 octobre 2015 10:24:20, Simon Templer a ?crit : >> Hi all, >> >> I'm trying to find out if and how Mapserver can be used to serve Complex >> Features via WFS 2.0. > Complex Features are not really supported. You could perhaps have some success > for GetFeature output by using template-driven output : > http://mapserver.org/output/template_output.html . But I haven't tried myself > and I guess that would only work for not too complex features. And > DescribeFeatureType would produce only a schema for simple features. Thanks for the information. Do you know if there is something like that worked on or planned for future versions of Mapserver? Kind regards, Simon From even.rouault at spatialys.com Wed Oct 28 03:40:02 2015 From: even.rouault at spatialys.com (Even Rouault) Date: Wed, 28 Oct 2015 11:40:02 +0100 Subject: [mapserver-users] Mapserver and Complex Feature support In-Reply-To: <5630A379.2030702@templer.cc> References: <56309444.9060601@templer.cc> <201510281046.56520.even.rouault@spatialys.com> <5630A379.2030702@templer.cc> Message-ID: <201510281140.02855.even.rouault@spatialys.com> Le mercredi 28 octobre 2015 11:29:13, Simon Templer a ?crit : > On 28.10.2015 10:46, Even Rouault wrote: > > Le mercredi 28 octobre 2015 10:24:20, Simon Templer a ?crit : > >> Hi all, > >> > >> I'm trying to find out if and how Mapserver can be used to serve Complex > >> Features via WFS 2.0. > > > > Complex Features are not really supported. You could perhaps have some > > success for GetFeature output by using template-driven output : > > http://mapserver.org/output/template_output.html . But I haven't tried > > myself and I guess that would only work for not too complex features. > > And DescribeFeatureType would produce only a schema for simple features. > > Thanks for the information. Do you know if there is something like that > worked on or planned for future versions of Mapserver? Not to my knowledge (which doesn't mean someone else isn't thinking to it), although you're not the only one that would be interested in that. That would require undoubtly a substantial amount of funding to be developed given that would probably have important impacts on the general Mapserver architecture. > > > Kind regards, > Simon -- Spatialys - Geospatial professional services http://www.spatialys.com From jukka.rahkonen at maanmittauslaitos.fi Wed Oct 28 04:12:55 2015 From: jukka.rahkonen at maanmittauslaitos.fi (Rahkonen Jukka (MML)) Date: Wed, 28 Oct 2015 11:12:55 +0000 Subject: [mapserver-users] DATA "table" does not find FID for WFS Message-ID: Hi, I am testing with MS4W 3.1.0 and the GDAL that is included seems to be C:\ms4w>gdalinfo --version GDAL 2.0.0, released 2015/06/14 I believe that it should include #5781 -Jukka- Even Rouault wrote: Le mercredi 28 octobre 2015 08:10:44, Rahkonen Jukka (MML) a ?crit : > Hi, > > I have noticed with Mapserver 7.0 that WFS server does not find the > "gml_featureid" column if I define DATA this way: > > CONNECTIONTYPE OGR > CONNECTION "\ms4w\apps\wms-wfs.sqlite" > DATA "states" > > This gives a warning into GML sent by GetFeature > > and featureMembers are without fid > > > > This leads to correct result: > > CONNECTIONTYPE OGR > CONNECTION "\ms4w\apps\wms-wfs.sqlite" > DATA "select * from states" > > > > > Documentation http://www.mapserver.org/input/vector/ogr.html does not > warn that defining data as "layer_name" vs. "select * from layer" > could make a difference. Ogrinfo finds the FID column and reports it > as: FID Column = PK_UID > > PK_UID is defined in the table as > CREATE TABLE states ( > PK_UID INTEGER PRIMARY KEY AUTOINCREMENT, > > > This looks like a bug but I am not sure if it is a Mapserver bug of > GDAL bug and if it affects only Spatialite. You didn't specify which GDAL version is used. That could possibly be the following bug that was fixed in 1.11.2 and 2.0: * make GetFIDColumn() work when run as first method call (#5781) > > -Jukka Rahkonen- -- Spatialys - Geospatial professional services http://www.spatialys.com From even.rouault at spatialys.com Wed Oct 28 04:31:26 2015 From: even.rouault at spatialys.com (Even Rouault) Date: Wed, 28 Oct 2015 12:31:26 +0100 Subject: [mapserver-users] DATA "table" does not find FID for WFS In-Reply-To: References: Message-ID: <201510281231.27074.even.rouault@spatialys.com> Le mercredi 28 octobre 2015 12:12:55, Rahkonen Jukka (MML) a ?crit : > Hi, > > I am testing with MS4W 3.1.0 and the GDAL that is included seems to be > > C:\ms4w>gdalinfo --version > GDAL 2.0.0, released 2015/06/14 > > I believe that it should include #5781 Yes, but that is irrelevant to your issue when looking closer. The GML output tries to find a item/field with the name of the gml_featureid. But the FID column in OGR is treated specially and not reported as a regular field. Which explains the error. In the case of "select * from table_name" as pk_uid is different from ogc_fid then it is just recognized as a regular column, which makes things work. So even "select * from table_name" isn't a guarantee that things are going to work. If the primary key field was named ogc_fid, you'd have to do "select ogc_fid as pk_uid, * from table_name" so it appears as a regular OGR field. > > -Jukka- > > Even Rouault wrote: > > Le mercredi 28 octobre 2015 08:10:44, Rahkonen Jukka (MML) a ?crit : > > Hi, > > > > I have noticed with Mapserver 7.0 that WFS server does not find the > > "gml_featureid" column if I define DATA this way: > > > > CONNECTIONTYPE OGR > > CONNECTION "\ms4w\apps\wms-wfs.sqlite" > > DATA "states" > > > > This gives a warning into GML sent by GetFeature > > > > and featureMembers are without fid > > > > > > > > This leads to correct result: > > > > CONNECTIONTYPE OGR > > CONNECTION "\ms4w\apps\wms-wfs.sqlite" > > DATA "select * from states" > > > > > > > > > > Documentation http://www.mapserver.org/input/vector/ogr.html does not > > warn that defining data as "layer_name" vs. "select * from layer" > > could make a difference. Ogrinfo finds the FID column and reports it > > as: FID Column = PK_UID > > > > PK_UID is defined in the table as > > CREATE TABLE states ( > > PK_UID INTEGER PRIMARY KEY AUTOINCREMENT, > > > > > > This looks like a bug but I am not sure if it is a Mapserver bug of > > GDAL bug and if it affects only Spatialite. > > You didn't specify which GDAL version is used. > > That could possibly be the following bug that was fixed in 1.11.2 and 2.0: > * make GetFIDColumn() work when run as first method call (#5781) > > > -Jukka Rahkonen- > > -- > Spatialys - Geospatial professional services http://www.spatialys.com -- Spatialys - Geospatial professional services http://www.spatialys.com From jukka.rahkonen at maanmittauslaitos.fi Wed Oct 28 05:24:28 2015 From: jukka.rahkonen at maanmittauslaitos.fi (Rahkonen Jukka (MML)) Date: Wed, 28 Oct 2015 12:24:28 +0000 Subject: [mapserver-users] DATA "table" does not find FID for WFS Message-ID: <8974d856d811448d8e64cde469e295e8@C119S212VM022.msvyvi.vaha.local> Hi, > The GML output tries to find a item/field with the name of the gml_featureid. > But the FID column in OGR is treated specially and not reported as a regular field. I guess that it means that the issue does not affect only Spatialite, and the resolution would be to make GML output to try if it finds the "gml_featureid" field from the regular fields _OR_ from the field that is reported by OGR as "FID Column". The latter could be tried also if "gml_featureid" is missing from the mapfile or if it was set to " gml_featureid" "AUTO". I am not sure if this is a good idea or not because the native vector drivers should be adapted as well. Should I file a Mapserver issue into Github about FID Columns getting hidden? -Jukka- Even Rouault wrote: Le mercredi 28 octobre 2015 12:12:55, Rahkonen Jukka (MML) a ?crit : > Hi, > > I am testing with MS4W 3.1.0 and the GDAL that is included seems to be > > C:\ms4w>gdalinfo --version > GDAL 2.0.0, released 2015/06/14 > > I believe that it should include #5781 Yes, but that is irrelevant to your issue when looking closer. The GML output tries to find a item/field with the name of the gml_featureid. But the FID column in OGR is treated specially and not reported as a regular field. Which explains the error. In the case of "select * from table_name" as pk_uid is different from ogc_fid then it is just recognized as a regular column, which makes things work. So even "select * from table_name" isn't a guarantee that things are going to work. If the primary key field was named ogc_fid, you'd have to do "select ogc_fid as pk_uid, * from table_name" so it appears as a regular OGR field. > > -Jukka- > > Even Rouault wrote: > > Le mercredi 28 octobre 2015 08:10:44, Rahkonen Jukka (MML) a ?crit : > > Hi, > > > > I have noticed with Mapserver 7.0 that WFS server does not find the > > "gml_featureid" column if I define DATA this way: > > > > CONNECTIONTYPE OGR > > CONNECTION "\ms4w\apps\wms-wfs.sqlite" > > DATA "states" > > > > This gives a warning into GML sent by GetFeature > > and featureMembers are without fid > > > > > > This leads to correct result: > > > > CONNECTIONTYPE OGR > > CONNECTION "\ms4w\apps\wms-wfs.sqlite" > > DATA "select * from states" > > > > > > > > > > Documentation http://www.mapserver.org/input/vector/ogr.html does > > not warn that defining data as "layer_name" vs. "select * from layer" > > could make a difference. Ogrinfo finds the FID column and reports it > > as: FID Column = PK_UID > > > > PK_UID is defined in the table as > > CREATE TABLE states ( > > PK_UID INTEGER PRIMARY KEY AUTOINCREMENT, > > > > > > This looks like a bug but I am not sure if it is a Mapserver bug of > > GDAL bug and if it affects only Spatialite. > > You didn't specify which GDAL version is used. > > That could possibly be the following bug that was fixed in 1.11.2 and 2.0: > * make GetFIDColumn() work when run as first method call (#5781) > > > -Jukka Rahkonen- > > -- > Spatialys - Geospatial professional services http://www.spatialys.com -- Spatialys - Geospatial professional services http://www.spatialys.com From even.rouault at spatialys.com Wed Oct 28 05:42:38 2015 From: even.rouault at spatialys.com (Even Rouault) Date: Wed, 28 Oct 2015 13:42:38 +0100 Subject: [mapserver-users] DATA "table" does not find FID for WFS In-Reply-To: <8974d856d811448d8e64cde469e295e8@C119S212VM022.msvyvi.vaha.local> References: <8974d856d811448d8e64cde469e295e8@C119S212VM022.msvyvi.vaha.local> Message-ID: <201510281342.38451.even.rouault@spatialys.com> Le mercredi 28 octobre 2015 13:24:28, Rahkonen Jukka (MML) a ?crit : > Hi, > > > The GML output tries to find a item/field with the name of the > > gml_featureid. But the FID column in OGR is treated specially and not > > reported as a regular field. > > I guess that it means that the issue does not affect only Spatialite, and > the resolution would be to make GML output to try if it finds the > "gml_featureid" field from the regular fields _OR_ from the field that is > reported by OGR as "FID Column". The GML output module cannot get this information back from the OGR provider. The OGR provider would rather have to expose the FID column as a regular item, when there's a named FID column. And when there's not, for example the OGR Shapefile has no FID column. possibly a generic name like 'FID' (which is the special name for the implicit FID column in OGR SQL) could be used to please MapServer. > > The latter could be tried also if "gml_featureid" is missing from the > mapfile or if it was set to " gml_featureid" "AUTO". I am not sure if this > is a good idea or not because the native vector drivers should be adapted > as well. Looking at the postgis provider, it exposes all fields, excluding the geometry field, but including the primary key column as regular fields. > > Should I file a Mapserver issue into Github about FID Columns getting > hidden? Possibly. There are also perhaps documentation advice with the workarounds I suggested. > > -Jukka- > > Even Rouault wrote: > > Le mercredi 28 octobre 2015 12:12:55, Rahkonen Jukka (MML) a ?crit : > > Hi, > > > > I am testing with MS4W 3.1.0 and the GDAL that is included seems to be > > > > C:\ms4w>gdalinfo --version > > GDAL 2.0.0, released 2015/06/14 > > > > I believe that it should include #5781 > > Yes, but that is irrelevant to your issue when looking closer. > > The GML output tries to find a item/field with the name of the > gml_featureid. But the FID column in OGR is treated specially and not > reported as a regular field. Which explains the error. In the case of > "select * from table_name" as pk_uid is different from ogc_fid then it is > just recognized as a regular column, which makes things work. So even > "select * from table_name" isn't a guarantee that things are going to > work. If the primary key field was named ogc_fid, you'd have to do "select > ogc_fid as pk_uid, * from table_name" so it appears as a regular OGR > field. > > > -Jukka- > > > > Even Rouault wrote: > > > > Le mercredi 28 octobre 2015 08:10:44, Rahkonen Jukka (MML) a ?crit : > > > Hi, > > > > > > I have noticed with Mapserver 7.0 that WFS server does not find the > > > "gml_featureid" column if I define DATA this way: > > > > > > CONNECTIONTYPE OGR > > > CONNECTION "\ms4w\apps\wms-wfs.sqlite" > > > DATA "states" > > > > > > This gives a warning into GML sent by GetFeature > > > and featureMembers are without fid > > > > > > > > > This leads to correct result: > > > > > > CONNECTIONTYPE OGR > > > CONNECTION "\ms4w\apps\wms-wfs.sqlite" > > > DATA "select * from states" > > > > > > > > > > > > > > > Documentation http://www.mapserver.org/input/vector/ogr.html does > > > not warn that defining data as "layer_name" vs. "select * from layer" > > > could make a difference. Ogrinfo finds the FID column and reports it > > > as: FID Column = PK_UID > > > > > > PK_UID is defined in the table as > > > CREATE TABLE states ( > > > PK_UID INTEGER PRIMARY KEY AUTOINCREMENT, > > > > > > > > > This looks like a bug but I am not sure if it is a Mapserver bug of > > > GDAL bug and if it affects only Spatialite. > > > > You didn't specify which GDAL version is used. > > > > That could possibly be the following bug that was fixed in 1.11.2 and 2.0: > > * make GetFIDColumn() work when run as first method call (#5781) > > > > > -Jukka Rahkonen- > > > > -- > > Spatialys - Geospatial professional services http://www.spatialys.com > > -- > Spatialys - Geospatial professional services http://www.spatialys.com -- Spatialys - Geospatial professional services http://www.spatialys.com From pmadden at nsidc.org Wed Oct 28 08:20:11 2015 From: pmadden at nsidc.org (Paul Madden) Date: Wed, 28 Oct 2015 09:20:11 -0600 Subject: [mapserver-users] MapCache: cache some zoom levels, proxy others? Message-ID: <5630E7AB.8050509@nsidc.org> I am working with a web application that makes WMS queries to MapCache. The application supports zoom levels 0 through 13, and I have used mapcache_seed to seed the cache through level 10. The deeper levels take so long to seed that I am considering stopping at level 10 and letting MapCache / MapServer produce deeper levels on demand, as users visit them. The problem I'm facing is that, as far as I can tell, MapCache requests tiles from MapServer serially, then stitches together the required image from these tiles, when it receives a request for an uncached level. In one test, 34 separate tiles were requested from MapServer, one at a time, and it took ~30 seconds to render the final image. I'm wondering whether there is a way to configure MapCache to cache/provide a defined set of zoom levels, and to proxy requests at other zoom levels directly to MapServer. I tried setting minzoom and maxzoom on my in mapcache.xml to "0 10". I tried adding a proxy for my cached layer, hoping that MapCache would redirect requests for unsupported zoom levels to MapServer (I have proxies in place for other, completely uncached layers, and those work fine). I tried copying/renaming the GoogleMapsCompatible grid definition into my mapcache.xml and removing from zoom levels I don't want MapCache to cache. So far, these attempts apparently just prevent MapCache from serving the deeper layers at all. Any thoughts on how I might address this issue? It might also help if MapCache would make concurrent requests for tiles at uncached levels, but I have no idea if this is feasible. And it would be nice to be able to let MapServer handle some zoom levels directly in any case. Thanks in advance for any ideas. Paul Madden National Snow and Ice Data Center From thomas.bonfort at gmail.com Wed Oct 28 08:36:04 2015 From: thomas.bonfort at gmail.com (thomas bonfort) Date: Wed, 28 Oct 2015 16:36:04 +0100 Subject: [mapserver-users] MapCache: cache some zoom levels, proxy others? In-Reply-To: <5630E7AB.8050509@nsidc.org> References: <5630E7AB.8050509@nsidc.org> Message-ID: Paul, Are you using metatiling? That would substantially reduce the number of requests mapcache does to mapserver. You also have the ... true option, that lets mapcache launch mapserver requests in parallel instead of sequentially (YMMV, this option isn't very tested) -- thomas On 28 October 2015 at 16:20, Paul Madden wrote: > I am working with a web application that makes WMS queries to MapCache. The application supports zoom levels 0 through 13, and I have used mapcache_seed to seed the cache through level 10. The deeper levels take so long to seed that I am considering stopping at level 10 and letting MapCache / MapServer produce deeper levels on demand, as users visit them. The problem I'm facing is that, as far as I can tell, MapCache requests tiles from MapServer serially, then stitches together the required image from these tiles, when it receives a request for an uncached level. In one test, 34 separate tiles were requested from MapServer, one at a time, and it took ~30 seconds to render the final image. > > I'm wondering whether there is a way to configure MapCache to cache/provide a defined set of zoom levels, and to proxy requests at other zoom levels directly to MapServer. I tried setting minzoom and maxzoom on my in mapcache.xml to "0 10". I tried adding a proxy for my cached layer, hoping that MapCache would redirect requests for unsupported zoom levels to MapServer (I have proxies in place for other, completely uncached layers, and those work fine). I tried copying/renaming the GoogleMapsCompatible grid definition into my mapcache.xml and removing from zoom levels I don't want MapCache to cache. So far, these attempts apparently just prevent MapCache from serving the deeper layers at all. > > Any thoughts on how I might address this issue? It might also help if MapCache would make concurrent requests for tiles at uncached levels, but I have no idea if this is feasible. And it would be nice to be able to let MapServer handle some zoom levels directly in any case. > > Thanks in advance for any ideas. > > Paul Madden > National Snow and Ice Data Center > _______________________________________________ > mapserver-users mailing list > mapserver-users at lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/mapserver-users From jukka.rahkonen at maanmittauslaitos.fi Wed Oct 28 08:40:34 2015 From: jukka.rahkonen at maanmittauslaitos.fi (Rahkonen Jukka (MML)) Date: Wed, 28 Oct 2015 15:40:34 +0000 Subject: [mapserver-users] Question about gml_types - auto and WFS Message-ID: Hi, I can read from http://mapserver.org/ogc/wfs_server.html: gml_types (Optional) If this field is "auto" then some input feature drivers (ie. OGR, POSTGIS, ORACLESPATIAL and native shapefiles) will automatically populate the type, width and precision metadata for the layer based on the source file. Currently this is only used for OGR based output formats, not the WFS GML2/GML3 output. What does "Currently this is only used for OGR based output formats, not the WFS GML2/GML3 output" mean? I can see that the GML schema is changing when I add "gml_types" "auto" to the mapfile. So what does not work with GML2/GML3 output? -Jukka Rahkonen- -------------- next part -------------- An HTML attachment was scrubbed... URL: From even.rouault at spatialys.com Wed Oct 28 08:52:36 2015 From: even.rouault at spatialys.com (Even Rouault) Date: Wed, 28 Oct 2015 16:52:36 +0100 Subject: [mapserver-users] Question about gml_types - auto and WFS In-Reply-To: References: Message-ID: <201510281652.36925.even.rouault@spatialys.com> Le mercredi 28 octobre 2015 16:40:34, Rahkonen Jukka (MML) a ?crit : > Hi, > > I can read from http://mapserver.org/ogc/wfs_server.html: > > gml_types (Optional) > If this field is "auto" then some input feature drivers (ie. OGR, POSTGIS, > ORACLESPATIAL and native shapefiles) will automatically populate the type, > width and precision metadata for the layer based on the source file. > Currently this is only used for OGR based output formats, not the WFS > GML2/GML3 output. > > What does "Currently this is only used for OGR based output formats, not > the WFS GML2/GML3 output" mean? I can see that the GML schema is changing > when I add "gml_types" "auto" to the mapfile. So what does not work with > GML2/GML3 output? I think the comment can be removed, as it doesn't bring a lot of value and adds some potential confusion. The type isn't really used by the GML2/GML3 *feature* output as MapServer representation is strings and GML2/GML3 is also. I think the comment meant that in the case of OGR output, the type is used to properly instanciate OGR field definitions with the appropriate OGR type. > > -Jukka Rahkonen- -- Spatialys - Geospatial professional services http://www.spatialys.com From pmadden at nsidc.org Wed Oct 28 08:55:18 2015 From: pmadden at nsidc.org (Paul Madden) Date: Wed, 28 Oct 2015 09:55:18 -0600 Subject: [mapserver-users] MapCache: cache some zoom levels, proxy others? In-Reply-To: References: <5630E7AB.8050509@nsidc.org> Message-ID: <5630EFE6.1030808@nsidc.org> Hi Thomas, Thank you for reminding me about metatiling. I was initially using the MapServer v6.4 / MapCache v1.2 available with the version of Ubuntu I need to use, and disabled metatiling because of a (maybe) bug whereby, at some shallow zoom levels, some parts of my layer would fail to appear or display. I found that, by varying the values, I could push the problem to different zoom levels, but I could not seem to eliminate it. When I turned metatiling off, this problem disappeared but I then saw, probably unsurprisingly, issues with truncated and overlapping labels at deep zoom levels. I then built the v7.0 / v1.4 releases from source and the problem disappeared. However, Apache would segfault in the MapCache module when I tried to use the "sqlite3" cache type ("disk" worked fine, but I have more tiles than inodes, so I cannot use it). Finally, I built the head of your git master and then "sqlite3" worked fine, too. (I can get you a stacktrace of the v1.4 segfault if you're interested -- but you seem already to have fixed whatever the underlying issue was). Sorry for the long backstory -- maybe some of it will be useful to someone. I will try using metatiling again, and will test as well. Thanks! Out of curiosity, can I assume that my other idea, about proxying some zoom levels directly to WMS and caching others, is unrealistic? paul On 10/28/15 9:36 AM, thomas bonfort wrote: > Paul, > > Are you using metatiling? That would substantially reduce the number > of requests mapcache does to mapserver. > > You also have the > > ... > true > > option, that lets mapcache launch mapserver requests in parallel > instead of sequentially (YMMV, this option isn't very tested) > > -- > thomas > > On 28 October 2015 at 16:20, Paul Madden wrote: >> I am working with a web application that makes WMS queries to MapCache. The application supports zoom levels 0 through 13, and I have used mapcache_seed to seed the cache through level 10. The deeper levels take so long to seed that I am considering stopping at level 10 and letting MapCache / MapServer produce deeper levels on demand, as users visit them. The problem I'm facing is that, as far as I can tell, MapCache requests tiles from MapServer serially, then stitches together the required image from these tiles, when it receives a request for an uncached level. In one test, 34 separate tiles were requested from MapServer, one at a time, and it took ~30 seconds to render the final image. >> >> I'm wondering whether there is a way to configure MapCache to cache/provide a defined set of zoom levels, and to proxy requests at other zoom levels directly to MapServer. I tried setting minzoom and maxzoom on my in mapcache.xml to "0 10". I tried adding a proxy for my cached layer, hoping that MapCache would redirect requests for unsupported zoom levels to MapServer (I have proxies in place for other, completely uncached layers, and those work fine). I tried copying/renaming the GoogleMapsCompatible grid definition into my mapcache.xml and removing from zoom levels I don't want MapCache to cache. So far, these attempts apparently just prevent MapCache from serving the deeper layers at all. >> >> Any thoughts on how I might address this issue? It might also help if MapCache would make concurrent requests for tiles at uncached levels, but I have no idea if this is feasible. And it would be nice to be able to let MapServer handle some zoom levels directly in any case. >> >> Thanks in advance for any ideas. >> >> Paul Madden >> National Snow and Ice Data Center >> _______________________________________________ >> mapserver-users mailing list >> mapserver-users at lists.osgeo.org >> http://lists.osgeo.org/mailman/listinfo/mapserver-users From thomas.bonfort at gmail.com Wed Oct 28 08:59:01 2015 From: thomas.bonfort at gmail.com (thomas bonfort) Date: Wed, 28 Oct 2015 16:59:01 +0100 Subject: [mapserver-users] MapCache: cache some zoom levels, proxy others? In-Reply-To: <5630EFE6.1030808@nsidc.org> References: <5630E7AB.8050509@nsidc.org> <5630EFE6.1030808@nsidc.org> Message-ID: > Out of curiosity, can I assume that my other idea, about proxying some zoom > levels directly to WMS and caching others, is unrealistic? not unrealistic, but not implemented -- thomas > > paul > > > On 10/28/15 9:36 AM, thomas bonfort wrote: >> >> Paul, >> >> Are you using metatiling? That would substantially reduce the number >> of requests mapcache does to mapserver. >> >> You also have the >> >> ... >> true >> >> option, that lets mapcache launch mapserver requests in parallel >> instead of sequentially (YMMV, this option isn't very tested) >> >> -- >> thomas >> >> On 28 October 2015 at 16:20, Paul Madden wrote: >>> >>> I am working with a web application that makes WMS queries to MapCache. >>> The application supports zoom levels 0 through 13, and I have used >>> mapcache_seed to seed the cache through level 10. The deeper levels take so >>> long to seed that I am considering stopping at level 10 and letting MapCache >>> / MapServer produce deeper levels on demand, as users visit them. The >>> problem I'm facing is that, as far as I can tell, MapCache requests tiles >>> from MapServer serially, then stitches together the required image from >>> these tiles, when it receives a request for an uncached level. In one test, >>> 34 separate tiles were requested from MapServer, one at a time, and it took >>> ~30 seconds to render the final image. >>> >>> I'm wondering whether there is a way to configure MapCache to >>> cache/provide a defined set of zoom levels, and to proxy requests at other >>> zoom levels directly to MapServer. I tried setting minzoom and maxzoom on my >>> in mapcache.xml to "0 10". I tried adding a proxy for my cached >>> layer, hoping that MapCache would redirect requests for unsupported zoom >>> levels to MapServer (I have proxies in place for other, completely uncached >>> layers, and those work fine). I tried copying/renaming the >>> GoogleMapsCompatible grid definition into my mapcache.xml and removing from >>> zoom levels I don't want MapCache to cache. So far, these >>> attempts apparently just prevent MapCache from serving the deeper layers at >>> all. >>> >>> Any thoughts on how I might address this issue? It might also help if >>> MapCache would make concurrent requests for tiles at uncached levels, but I >>> have no idea if this is feasible. And it would be nice to be able to let >>> MapServer handle some zoom levels directly in any case. >>> >>> Thanks in advance for any ideas. >>> >>> Paul Madden >>> National Snow and Ice Data Center >>> _______________________________________________ >>> 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 From aperi2007 at gmail.com Wed Oct 28 12:48:22 2015 From: aperi2007 at gmail.com (Andrea Peri) Date: Wed, 28 Oct 2015 20:48:22 +0100 Subject: [mapserver-users] Two mapserver cgi opening the same mapfile file Message-ID: Hi, to try to have better usage resources I like to try a new configuration using two distinct cgi mapservers each of them accessing the same mapfile. Both the cgi are in the same server with the mapfile. The goal is to avoid to have two distinct but identical mapfiles to maintain. I guess should be no problem to have two cgi opening the same mapfile, but any thought on this kind of configuration is welcome. Thx. -- ----------------- Andrea Peri . . . . . . . . . qwerty ????? ----------------- From pmadden at nsidc.org Wed Oct 28 14:10:01 2015 From: pmadden at nsidc.org (Paul Madden) Date: Wed, 28 Oct 2015 15:10:01 -0600 Subject: [mapserver-users] MapCache: cache some zoom levels, proxy others? In-Reply-To: References: <5630E7AB.8050509@nsidc.org> <5630EFE6.1030808@nsidc.org> Message-ID: <563139A9.3010807@nsidc.org> Thomas, Enabling metatiling indeed led to a significant speedup. I can also verify that works for me (I can see the additional threads running), but it did not lead to a noticeable speedup, perhaps due to a bottleneck where my MapServer talks to a remote database. I also increased my tile size from 256x256 to 1024x1024, which seems fine for my application and which obviously reduces the number of tiles helpfully. If I may ask one more question: Are you aware of any problems running mapcache_seed concurrently with users accessing MapCache via the web application, if one uses the sqlite3 cache? I saw a thread about potential conflicts, but I think that might have been specific to disk caches. Thanks again, paul On 10/28/15 9:59 AM, thomas bonfort wrote: >> Out of curiosity, can I assume that my other idea, about proxying some zoom >> levels directly to WMS and caching others, is unrealistic? > not unrealistic, but not implemented > > -- > thomas > >> paul >> >> >> On 10/28/15 9:36 AM, thomas bonfort wrote: >>> Paul, >>> >>> Are you using metatiling? That would substantially reduce the number >>> of requests mapcache does to mapserver. >>> >>> You also have the >>> >>> ... >>> true >>> >>> option, that lets mapcache launch mapserver requests in parallel >>> instead of sequentially (YMMV, this option isn't very tested) >>> >>> -- >>> thomas >>> >>> On 28 October 2015 at 16:20, Paul Madden wrote: >>>> I am working with a web application that makes WMS queries to MapCache. >>>> The application supports zoom levels 0 through 13, and I have used >>>> mapcache_seed to seed the cache through level 10. The deeper levels take so >>>> long to seed that I am considering stopping at level 10 and letting MapCache >>>> / MapServer produce deeper levels on demand, as users visit them. The >>>> problem I'm facing is that, as far as I can tell, MapCache requests tiles >>>> from MapServer serially, then stitches together the required image from >>>> these tiles, when it receives a request for an uncached level. In one test, >>>> 34 separate tiles were requested from MapServer, one at a time, and it took >>>> ~30 seconds to render the final image. >>>> >>>> I'm wondering whether there is a way to configure MapCache to >>>> cache/provide a defined set of zoom levels, and to proxy requests at other >>>> zoom levels directly to MapServer. I tried setting minzoom and maxzoom on my >>>> in mapcache.xml to "0 10". I tried adding a proxy for my cached >>>> layer, hoping that MapCache would redirect requests for unsupported zoom >>>> levels to MapServer (I have proxies in place for other, completely uncached >>>> layers, and those work fine). I tried copying/renaming the >>>> GoogleMapsCompatible grid definition into my mapcache.xml and removing from >>>> zoom levels I don't want MapCache to cache. So far, these >>>> attempts apparently just prevent MapCache from serving the deeper layers at >>>> all. >>>> >>>> Any thoughts on how I might address this issue? It might also help if >>>> MapCache would make concurrent requests for tiles at uncached levels, but I >>>> have no idea if this is feasible. And it would be nice to be able to let >>>> MapServer handle some zoom levels directly in any case. >>>> >>>> Thanks in advance for any ideas. >>>> >>>> Paul Madden >>>> National Snow and Ice Data Center >>>> _______________________________________________ >>>> 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 From Steve.Toutant at inspq.qc.ca Wed Oct 28 05:25:24 2015 From: Steve.Toutant at inspq.qc.ca (Steve.Toutant at inspq.qc.ca) Date: Wed, 28 Oct 2015 08:25:24 -0400 Subject: [mapserver-users] RE Cascaded WMS GetFeatureInfo In-Reply-To: <5D5AE574FB890744BCB91DE22F3A53C183193E43@vbrk21mx02.bezreg-koeln.nrw.de> References: <5D5AE574FB890744BCB91DE22F3A53C183193E43@vbrk21mx02.bezreg-koeln.nrw.de> Message-ID: Cora have you read this? http://mapserver.org/ogc/wms_server.html#cascading-wms-request It might help to know why a layer is not cascaded What happen if you don't modify the style? steve "Berger, Cora" @lists.osgeo.org Envoy? par : "mapserver-users" 2015-10-27 04:01 A "'mapserver-users at lists.osgeo.org'" cc Objet [mapserver-users] Cascaded WMS GetFeatureInfo Hello everybody, I am building a cascaded WMS. My layers all have connectiontype WMS and all of them use one layer of the same WMS as source. The only thing I change is the style of the original WMS. My problem is that the GetFeatureInfo does not cascade. I am using Mapserver 7.0. I read that the GetFeatureInfo request supports cascading. All requests are enabled in the metadata. Do I have to add a special tag in the metatada or layer section to "pass through" the GetFeatureInfo from the original WMS? Thanks for your help. Best regards Cora Berger _______________________________________________ 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 pmadden at nsidc.org Wed Oct 28 19:08:29 2015 From: pmadden at nsidc.org (Paul Madden) Date: Wed, 28 Oct 2015 20:08:29 -0600 Subject: [mapserver-users] MapCache: cache some zoom levels, proxy others? In-Reply-To: References: <5630E7AB.8050509@nsidc.org> <5630EFE6.1030808@nsidc.org> <563139A9.3010807@nsidc.org> Message-ID: <56317F9D.2060301@nsidc.org> Travis, Thank you -- I hadn't realized before what you could do with the various meta caches. I'll definitely be experimenting with a front-end memcache at some point. But, I can't yet see how I can overcome the sqlite3 issue with these methods. It seems like the following would *almost* work: db1 db2 where both db1 and db2 are sqlite3 caches, and db1 is being actively seeded by mapcache_seed. At first I thought: MapCache will check db1 to see if the requested tile has already been seeded and, if not, will move on to db2, which will make the appropriate WMS requests to MapServer. Only mapcache_seed will write to db1, and only MapCache will write to db2: No concurrency issue. But I see this in the docs: "If a given tile isn?t found in the first child cache, it will be read from the second child cache AND copied into the first child cache for subsequent accesses." Given the "AND" part, it seems that both mapcache_seed and MapCache will write concurrently to db1. If this is right, does such a configuration actually avoid the sqlite3 concurrency issue? Is there a better configuration that I've failed to imagine? On a related note: If *only* mapcache_seed writes to a sqlite3, but runs in multi-threaded mode, is it sqlite3-safe? (The questions are for anyone kind enough to answer...) paul On 10/28/15 17:42, Travis Kirstine wrote: > Paul, > > I would have a look at some of the new tiered caching options available in 1.4. SQLite can have issues locking under load > > On Wednesday, October 28, 2015, Paul Madden > wrote: > > Thomas, > > Enabling metatiling indeed led to a significant speedup. I can also verify that works for me (I can see the additional threads running), but it did not lead to a noticeable speedup, perhaps due to a bottleneck where my MapServer talks to a remote database. I also increased my tile size from 256x256 to 1024x1024, which seems fine for my application and which obviously reduces the number of tiles helpfully. > > If I may ask one more question: Are you aware of any problems running mapcache_seed concurrently with users accessing MapCache via the web application, if one uses the sqlite3 cache? I saw a thread about potential conflicts, but I think that might have been specific to disk caches. > > Thanks again, > paul > > On 10/28/15 9:59 AM, thomas bonfort wrote: > > Out of curiosity, can I assume that my other idea, about proxying some zoom > levels directly to WMS and caching others, is unrealistic? > > not unrealistic, but not implemented > > -- > thomas > > paul > > > On 10/28/15 9:36 AM, thomas bonfort wrote: > > Paul, > > Are you using metatiling? That would substantially reduce the number > of requests mapcache does to mapserver. > > You also have the > > ... > true > > option, that lets mapcache launch mapserver requests in parallel > instead of sequentially (YMMV, this option isn't very tested) > > -- > thomas > > On 28 October 2015 at 16:20, Paul Madden wrote: > > I am working with a web application that makes WMS queries to MapCache. > The application supports zoom levels 0 through 13, and I have used > mapcache_seed to seed the cache through level 10. The deeper levels take so > long to seed that I am considering stopping at level 10 and letting MapCache > / MapServer produce deeper levels on demand, as users visit them. The > problem I'm facing is that, as far as I can tell, MapCache requests tiles > from MapServer serially, then stitches together the required image from > these tiles, when it receives a request for an uncached level. In one test, > 34 separate tiles were requested from MapServer, one at a time, and it took > ~30 seconds to render the final image. > > I'm wondering whether there is a way to configure MapCache to > cache/provide a defined set of zoom levels, and to proxy requests at other > zoom levels directly to MapServer. I tried setting minzoom and maxzoom on my > in mapcache.xml to "0 10". I tried adding a proxy for my cached > layer, hoping that MapCache would redirect requests for unsupported zoom > levels to MapServer (I have proxies in place for other, completely uncached > layers, and those work fine). I tried copying/renaming the > GoogleMapsCompatible grid definition into my mapcache.xml and removing from > zoom levels I don't want MapCache to cache. So far, these > attempts apparently just prevent MapCache from serving the deeper layers at > all. > > Any thoughts on how I might address this issue? It might also help if > MapCache would make concurrent requests for tiles at uncached levels, but I > have no idea if this is feasible. And it would be nice to be able to let > MapServer handle some zoom levels directly in any case. > > Thanks in advance for any ideas. > > Paul Madden > National Snow and Ice Data Center > _______________________________________________ > 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 > > > _______________________________________________ > mapserver-users mailing list > mapserver-users at lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/mapserver-users > From richard.greenwood at gmail.com Wed Oct 28 19:18:03 2015 From: richard.greenwood at gmail.com (Richard Greenwood) Date: Wed, 28 Oct 2015 20:18:03 -0600 Subject: [mapserver-users] Two mapserver cgi opening the same mapfile file In-Reply-To: References: Message-ID: I don't see why there would be problem, but are you using standard cgi or fastcgi? It seems like fastcgi would do that for you without having to run and maintain two cgi instances, but I probably don't understand your whole goal. rich On Wed, Oct 28, 2015 at 1:48 PM, Andrea Peri wrote: > Hi, > to try to have better usage resources I like to try a new > configuration using two distinct cgi mapservers each of them accessing > the same mapfile. > Both the cgi are in the same server with the mapfile. > > The goal is to avoid to have two distinct but identical mapfiles to > maintain. > > I guess should be no problem to have two cgi opening the same mapfile, > but any thought on this kind of configuration is welcome. > > Thx. > > -- > ----------------- > Andrea Peri > . . . . . . . . . > qwerty ????? > ----------------- > _______________________________________________ > mapserver-users mailing list > mapserver-users at lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/mapserver-users -- Richard W. Greenwood, PLS www.greenwoodmap.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From pmadden at nsidc.org Wed Oct 28 19:44:41 2015 From: pmadden at nsidc.org (Paul Madden) Date: Wed, 28 Oct 2015 20:44:41 -0600 Subject: [mapserver-users] MapCache: cache some zoom levels, proxy others? In-Reply-To: <56317F9D.2060301@nsidc.org> References: <5630E7AB.8050509@nsidc.org> <5630EFE6.1030808@nsidc.org> <563139A9.3010807@nsidc.org> <56317F9D.2060301@nsidc.org> Message-ID: <56318819.8000407@nsidc.org> Reading the docs more carefully, it sounds like SQLite databases may have concurrency problems even with only mapcache_seed accessing them, given a sufficiently high number of threads. I'm guessing that 8 is not "a high number", and that a few extra from MapCache itself isn't either. Does anybody know differently? On 10/28/15 20:08, Paul Madden wrote: > Travis, > > Thank you -- I hadn't realized before what you could do with the various meta caches. I'll definitely be experimenting with a front-end memcache at some point. > > But, I can't yet see how I can overcome the sqlite3 issue with these methods. It seems like the following would *almost* work: > > > db1 > db2 > > > where both db1 and db2 are sqlite3 caches, and db1 is being actively seeded by mapcache_seed. At first I thought: MapCache will check db1 to see if the requested tile has already been seeded and, if not, will move on to db2, which will make the appropriate WMS requests to MapServer. Only mapcache_seed will write to db1, and only MapCache will write to db2: No concurrency issue. But I see this in the docs: "If a given tile isn?t found in the first child cache, it will be read from the second child cache AND copied into the first child cache for subsequent accesses." Given the "AND" part, it seems that both mapcache_seed and MapCache will write concurrently to db1. If this is right, does such a configuration actually avoid the sqlite3 concurrency issue? Is there a better configuration that I've failed to imagine? > > On a related note: If *only* mapcache_seed writes to a sqlite3, but runs in multi-threaded mode, is it sqlite3-safe? > > (The questions are for anyone kind enough to answer...) > > paul > > On 10/28/15 17:42, Travis Kirstine wrote: >> Paul, >> >> I would have a look at some of the new tiered caching options available in 1.4. SQLite can have issues locking under load >> >> On Wednesday, October 28, 2015, Paul Madden > wrote: >> >> Thomas, >> >> Enabling metatiling indeed led to a significant speedup. I can also verify that works for me (I can see the additional threads running), but it did not lead to a noticeable speedup, perhaps due to a bottleneck where my MapServer talks to a remote database. I also increased my tile size from 256x256 to 1024x1024, which seems fine for my application and which obviously reduces the number of tiles helpfully. >> >> If I may ask one more question: Are you aware of any problems running mapcache_seed concurrently with users accessing MapCache via the web application, if one uses the sqlite3 cache? I saw a thread about potential conflicts, but I think that might have been specific to disk caches. >> >> Thanks again, >> paul >> >> On 10/28/15 9:59 AM, thomas bonfort wrote: >> >> Out of curiosity, can I assume that my other idea, about proxying some zoom >> levels directly to WMS and caching others, is unrealistic? >> >> not unrealistic, but not implemented >> >> -- >> thomas >> >> paul >> >> >> On 10/28/15 9:36 AM, thomas bonfort wrote: >> >> Paul, >> >> Are you using metatiling? That would substantially reduce the number >> of requests mapcache does to mapserver. >> >> You also have the >> >> ... >> true >> >> option, that lets mapcache launch mapserver requests in parallel >> instead of sequentially (YMMV, this option isn't very tested) >> >> -- >> thomas >> >> On 28 October 2015 at 16:20, Paul Madden wrote: >> >> I am working with a web application that makes WMS queries to MapCache. >> The application supports zoom levels 0 through 13, and I have used >> mapcache_seed to seed the cache through level 10. The deeper levels take so >> long to seed that I am considering stopping at level 10 and letting MapCache >> / MapServer produce deeper levels on demand, as users visit them. The >> problem I'm facing is that, as far as I can tell, MapCache requests tiles >> from MapServer serially, then stitches together the required image from >> these tiles, when it receives a request for an uncached level. In one test, >> 34 separate tiles were requested from MapServer, one at a time, and it took >> ~30 seconds to render the final image. >> >> I'm wondering whether there is a way to configure MapCache to >> cache/provide a defined set of zoom levels, and to proxy requests at other >> zoom levels directly to MapServer. I tried setting minzoom and maxzoom on my >> in mapcache.xml to "0 10". I tried adding a proxy for my cached >> layer, hoping that MapCache would redirect requests for unsupported zoom >> levels to MapServer (I have proxies in place for other, completely uncached >> layers, and those work fine). I tried copying/renaming the >> GoogleMapsCompatible grid definition into my mapcache.xml and removing from >> zoom levels I don't want MapCache to cache. So far, these >> attempts apparently just prevent MapCache from serving the deeper layers at >> all. >> >> Any thoughts on how I might address this issue? It might also help if >> MapCache would make concurrent requests for tiles at uncached levels, but I >> have no idea if this is feasible. And it would be nice to be able to let >> MapServer handle some zoom levels directly in any case. >> >> Thanks in advance for any ideas. >> >> Paul Madden >> National Snow and Ice Data Center >> _______________________________________________ >> 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 >> >> >> _______________________________________________ >> mapserver-users mailing list >> mapserver-users at lists.osgeo.org >> http://lists.osgeo.org/mailman/listinfo/mapserver-users >> From cora.berger at bezreg-koeln.nrw.de Thu Oct 29 00:34:37 2015 From: cora.berger at bezreg-koeln.nrw.de (Berger, Cora) Date: Thu, 29 Oct 2015 07:34:37 +0000 Subject: [mapserver-users] RE Cascaded WMS GetFeatureInfo In-Reply-To: References: <5D5AE574FB890744BCB91DE22F3A53C183193E43@vbrk21mx02.bezreg-koeln.nrw.de> Message-ID: <5D5AE574FB890744BCB91DE22F3A53C183193FFF@vbrk21mx02.bezreg-koeln.nrw.de> Dear Steve, yes, I have read this. My layers do cascade. The only thing that doesn't work is the GetFeatureInfo Request. The original WMS supports GetFeatureInfo. But if I connect to this WMS and use it as a layer for my new WMS GetFeatureInfo stops working. Cora Von: Steve.Toutant at inspq.qc.ca [mailto:Steve.Toutant at inspq.qc.ca] Gesendet: Mittwoch, 28. Oktober 2015 13:25 An: Berger, Cora Cc: 'mapserver-users at lists.osgeo.org'; mapserver-users Betreff: RE [mapserver-users] Cascaded WMS GetFeatureInfo Cora have you read this? http://mapserver.org/ogc/wms_server.html#cascading-wms-request It might help to know why a layer is not cascaded What happen if you don't modify the style? steve "Berger, Cora" >@lists.osgeo.org Envoy? par : "mapserver-users" > 2015-10-27 04:01 A "'mapserver-users at lists.osgeo.org'" > cc Objet [mapserver-users] Cascaded WMS GetFeatureInfo Hello everybody, I am building a cascaded WMS. My layers all have connectiontype WMS and all of them use one layer of the same WMS as source. The only thing I change is the style of the original WMS. My problem is that the GetFeatureInfo does not cascade. I am using Mapserver 7.0. I read that the GetFeatureInfo request supports cascading. All requests are enabled in the metadata. Do I have to add a special tag in the metatada or layer section to "pass through" the GetFeatureInfo from the original WMS? Thanks for your help. Best regards Cora Berger _______________________________________________ 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 hschiebold at codematix.de Thu Oct 29 01:05:05 2015 From: hschiebold at codematix.de (hschiebold at codematix.de) Date: Thu, 29 Oct 2015 04:05:05 -0400 Subject: [mapserver-users] RE Cascaded WMS GetFeatureInfo In-Reply-To: References: <5D5AE574FB890744BCB91DE22F3A53C183193E43@vbrk21mx02.bezreg-koeln.nrw.de> Message-ID: <20151029040505.scjq2pbrr4wws88w@webmail.codematix.de> i was able to cascade the featureinfo with a dummy template in the layer section of the mapfile - without dummy template there was no cascading featureinfo in my service regards Holger Zitat von Steve.Toutant at inspq.qc.ca: > Cora have you read this? > http://mapserver.org/ogc/wms_server.html#cascading-wms-request > It might help to know why a layer is not cascaded > > What happen if you don't modify the style? > steve > > > > > > > "Berger, Cora" @lists.osgeo.org > Envoy? par : "mapserver-users" > 2015-10-27 04:01 > > A > "'mapserver-users at lists.osgeo.org'" > cc > > Objet > [mapserver-users] Cascaded WMS GetFeatureInfo > > > > > > > > > Hello everybody, > I am building a cascaded WMS. My layers all have connectiontype WMS and > all of them use one layer of the same WMS as source. The only thing I > change is the style of the original WMS. > My problem is that the GetFeatureInfo does not cascade. I am using > Mapserver 7.0. I read that the GetFeatureInfo request supports cascading. > All requests are enabled in the metadata. Do I have to add a special tag > in the metatada or layer section to "pass through" the GetFeatureInfo from > the original WMS? > > Thanks for your help. > > Best regards > > Cora Berger > > > _______________________________________________ > mapserver-users mailing list > mapserver-users at lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/mapserver-users > > > From jukka.rahkonen at maanmittauslaitos.fi Thu Oct 29 01:51:19 2015 From: jukka.rahkonen at maanmittauslaitos.fi (Rahkonen Jukka (MML)) Date: Thu, 29 Oct 2015 08:51:19 +0000 Subject: [mapserver-users] RE Cascaded WMS GetFeatureInfo Message-ID: Hi, I have never tried to cascade GetFeatureInfo from Mapserver to other WMS servers but I have tried to do that when Geoserver is used for cascading our Mapserver. I would say that it is complicated. First issue is that the list of supported info_formats is a per service feature, not per layer. For example Geoserver by default supports these formats: text/plain application/vnd.ogc.gml application/vnd.ogc.gml/3.1.1 text/html text/javascript application/json If I try to cascade Mapserver WMS that is configured to support only info_format=text/html with Geoserver, then users can't know that info_format=text/plain can't work with the cascaded layer. Actually no info_format will work in this theoretical case because Geoserve is always using "application/vnd.ogc.gml" when it cascades GetFeatureInfo but our Mapserver was not configured to support that. I have no idea about how Mapserver should be configured to support GetFeatureInfo for cascaded WMS layers. I do not believe that it is even possible to do it generally in a reliable way so that any WMS could do it successfully with any other WMS. Probably Mapserver can do is in some cases because http://mapserver.org/ogc/wms_client.html documents * GetFeatureInfo is not fully supported since the output of getFeatureInfo is left to the discretion of the remote server. A method layer.getWMSFeatureInfoURL() has been added to MapScript for applications that want to access featureInfo results and handle them directly -Jukka Rahkonen- Berger, Cora wrote: Dear Steve, yes, I have read this. My layers do cascade. The only thing that doesn't work is the GetFeatureInfo Request. The original WMS supports GetFeatureInfo. But if I connect to this WMS and use it as a layer for my new WMS GetFeatureInfo stops working. Cora Von: Steve.Toutant at inspq.qc.ca [mailto:Steve.Toutant at inspq.qc.ca] Gesendet: Mittwoch, 28. Oktober 2015 13:25 An: Berger, Cora Cc: 'mapserver-users at lists.osgeo.org'; mapserver-users Betreff: RE [mapserver-users] Cascaded WMS GetFeatureInfo Cora have you read this? http://mapserver.org/ogc/wms_server.html#cascading-wms-request It might help to know why a layer is not cascaded What happen if you don't modify the style? steve "Berger, Cora" >@lists.osgeo.org Envoy? par : "mapserver-users" > 2015-10-27 04:01 A "'mapserver-users at lists.osgeo.org'" > cc Objet [mapserver-users] Cascaded WMS GetFeatureInfo Hello everybody, I am building a cascaded WMS. My layers all have connectiontype WMS and all of them use one layer of the same WMS as source. The only thing I change is the style of the original WMS. My problem is that the GetFeatureInfo does not cascade. I am using Mapserver 7.0. I read that the GetFeatureInfo request supports cascading. All requests are enabled in the metadata. Do I have to add a special tag in the metatada or layer section to "pass through" the GetFeatureInfo from the original WMS? Thanks for your help. Best regards Cora Berger _______________________________________________ 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 hschiebold at codematix.de Thu Oct 29 08:41:51 2015 From: hschiebold at codematix.de (Holger Schiebold) Date: Thu, 29 Oct 2015 16:41:51 +0100 Subject: [mapserver-users] RE Cascaded WMS GetFeatureInfo In-Reply-To: <20151029040505.scjq2pbrr4wws88w@webmail.codematix.de> References: <5D5AE574FB890744BCB91DE22F3A53C183193E43@vbrk21mx02.bezreg-koeln.nrw.de> <20151029040505.scjq2pbrr4wws88w@webmail.codematix.de> Message-ID: <56323E3F.3070909@codematix.de> Hmm, but it was only working with one layer in my 6.4.2 mapserver here. If i was requesting more than one layer, mapserver crashed. I had to made a patch for the mapwmslayer.c, so now it's working for all layers in my cascading service. If it's not fixed in mapserver 7 (i can not test at the moment) i can provide a patch based on the 6.4.2 Version. regards Holger Am 29.10.2015 um 09:05 schrieb hschiebold at codematix.de: > i was able to cascade the featureinfo with a dummy template in the > layer section of the mapfile - without dummy template there was no > cascading featureinfo in my service > > regards Holger > > Zitat von Steve.Toutant at inspq.qc.ca: > >> Cora have you read this? >> http://mapserver.org/ogc/wms_server.html#cascading-wms-request >> It might help to know why a layer is not cascaded >> >> What happen if you don't modify the style? >> steve >> >> >> >> >> >> >> "Berger, Cora" @lists.osgeo.org >> Envoy? par : "mapserver-users" >> 2015-10-27 04:01 >> >> A >> "'mapserver-users at lists.osgeo.org'" >> cc >> >> Objet >> [mapserver-users] Cascaded WMS GetFeatureInfo >> >> >> >> >> >> >> >> >> Hello everybody, >> I am building a cascaded WMS. My layers all have connectiontype WMS and >> all of them use one layer of the same WMS as source. The only thing I >> change is the style of the original WMS. >> My problem is that the GetFeatureInfo does not cascade. I am using >> Mapserver 7.0. I read that the GetFeatureInfo request supports >> cascading. >> All requests are enabled in the metadata. Do I have to add a special tag >> in the metatada or layer section to "pass through" the GetFeatureInfo >> from >> the original WMS? >> >> Thanks for your help. >> >> Best regards >> >> Cora Berger >> >> >> _______________________________________________ >> 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 mit freundlichen Gr??en -- Holger Schiebold ____________________ codematix GmbH Felsbachstrasse 5/7 D-07745 Jena Tel. +49 (3641) 3038-34 www.codematix.de From mwkorver at gmail.com Thu Oct 29 10:28:17 2015 From: mwkorver at gmail.com (Mark Korver) Date: Thu, 29 Oct 2015 10:28:17 -0700 Subject: [mapserver-users] Update Mapserver at demo.mapserver.org? In-Reply-To: <77589662baf8422c91ba593383e68f63@C119S212VM022.msvyvi.vaha.local> References: <77589662baf8422c91ba593383e68f63@C119S212VM022.msvyvi.vaha.local> Message-ID: Would it help to have Mapserver 7 built as a public AMI (Amazon Machine Image)? I could help with that, but I would think that there are probably a number of preferences in how Mapserver gets built. For example I would typically build on Ubuntu and use NGINX, just because that is more familiar to me. -Mark Korver On Wed, Oct 28, 2015 at 2:31 AM, Rahkonen Jukka (MML) < jukka.rahkonen at maanmittauslaitos.fi> wrote: > Hi, > > > > I wrote last year > https://lists.osgeo.org/pipermail/mapserver-users/2014-May/076442.html > and asked if it could be possible to update the Mapserver v. 5.6.5 that is > running at http://demo.mapserver.org/cgi-bin/wms and I was told that not > before general infrastructure transition is over, see > http://wiki.osgeo.org/wiki/Infrastructure_Transition_Plan_2014 > > > > What it the situation now? It would be good to have some Mapserver 7.0 > WMS, WFS, and WCS services online for testing the issues which are reported > on the mailing list and in the Github issue tracker. Version 5.6.5 is > rather useless for that. > > > > -Jukka Rahkonen- > > _______________________________________________ > 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 Thu Oct 29 13:25:07 2015 From: aperi2007 at gmail.com (Andrea Peri) Date: Thu, 29 Oct 2015 21:25:07 +0100 Subject: [mapserver-users] Two mapserver cgi opening the same mapfile file In-Reply-To: References: Message-ID: Hi thx for responses. I dont use the fastcgi My mapserver run on a tomcat environment. My first goal is to be able to have two distinct cgi istance using the same dataset resources (we work with tiffs and spatialites) and the same mapfiles. his to reduce al minimum the manage overhead. My need for two distinct cgi instance if to test some strategies to have a balance of resources when the istances are on the same server machine. 2015-10-29 3:18 GMT+01:00 Richard Greenwood : > I don't see why there would be problem, but are you using standard cgi or > fastcgi? It seems like fastcgi would do that for you without having to run > and maintain two cgi instances, but I probably don't understand your whole > goal. > > rich > > On Wed, Oct 28, 2015 at 1:48 PM, Andrea Peri wrote: >> >> Hi, >> to try to have better usage resources I like to try a new >> configuration using two distinct cgi mapservers each of them accessing >> the same mapfile. >> Both the cgi are in the same server with the mapfile. >> >> The goal is to avoid to have two distinct but identical mapfiles to >> maintain. >> >> I guess should be no problem to have two cgi opening the same mapfile, >> but any thought on this kind of configuration is welcome. >> >> Thx. >> >> -- >> ----------------- >> Andrea Peri >> . . . . . . . . . >> qwerty ????? >> ----------------- >> _______________________________________________ >> mapserver-users mailing list >> mapserver-users at lists.osgeo.org >> http://lists.osgeo.org/mailman/listinfo/mapserver-users > > > > > -- > Richard W. Greenwood, PLS > www.greenwoodmap.com -- ----------------- Andrea Peri . . . . . . . . . qwerty ????? ----------------- From cora.berger at bezreg-koeln.nrw.de Thu Oct 29 23:41:22 2015 From: cora.berger at bezreg-koeln.nrw.de (Berger, Cora) Date: Fri, 30 Oct 2015 06:41:22 +0000 Subject: [mapserver-users] RE Cascaded WMS GetFeatureInfo Message-ID: <5D5AE574FB890744BCB91DE22F3A53C183194133@vbrk21mx02.bezreg-koeln.nrw.de> Hello Holger, It would be very nice if you provide your patch. I can work with different mapserver versions. Thanks a lot >-----Urspr?ngliche Nachricht----- >Von: mapserver-users [mailto:mapserver-users-bounces at lists.osgeo.org] Im >Auftrag von mapserver-users-request at lists.osgeo.org >Gesendet: Donnerstag, 29. Oktober 2015 20:00 >An: mapserver-users at lists.osgeo.org >Betreff: mapserver-users Digest, Vol 93, Issue 35 > >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. Re: RE Cascaded WMS GetFeatureInfo (Holger Schiebold) > 2. Re: Update Mapserver at demo.mapserver.org? (Mark Korver) > > >---------------------------------------------------------------------- > >Message: 1 >Date: Thu, 29 Oct 2015 16:41:51 +0100 >From: Holger Schiebold >To: mapserver-users at lists.osgeo.org >Subject: Re: [mapserver-users] RE Cascaded WMS GetFeatureInfo >Message-ID: <56323E3F.3070909 at codematix.de> >Content-Type: text/plain; charset=utf-8; format=flowed > >Hmm, but it was only working with one layer in my 6.4.2 mapserver here. >If i was requesting more than one layer, mapserver crashed. I had to >made a patch for the mapwmslayer.c, so now it's working for all layers >in my cascading service. If it's not fixed in mapserver 7 (i can not >test at the moment) i can provide a patch based on the 6.4.2 Version. > >regards Holger > >Am 29.10.2015 um 09:05 schrieb hschiebold at codematix.de: >> i was able to cascade the featureinfo with a dummy template in the >> layer section of the mapfile - without dummy template there was no >> cascading featureinfo in my service >> >> regards Holger >> >> Zitat von Steve.Toutant at inspq.qc.ca: >> >>> Cora have you read this? >>> http://mapserver.org/ogc/wms_server.html#cascading-wms-request >>> It might help to know why a layer is not cascaded >>> >>> What happen if you don't modify the style? >>> steve >>> >>> >>> >>> >>> >>> >>> "Berger, Cora" @lists.osgeo.org >>> Envoy? par : "mapserver-users" >>> 2015-10-27 04:01 >>> >>> A >>> "'mapserver-users at lists.osgeo.org'" >>> cc >>> >>> Objet >>> [mapserver-users] Cascaded WMS GetFeatureInfo >>> >>> >>> >>> >>> >>> >>> >>> >>> Hello everybody, >>> I am building a cascaded WMS. My layers all have connectiontype WMS and >>> all of them use one layer of the same WMS as source. The only thing I >>> change is the style of the original WMS. >>> My problem is that the GetFeatureInfo does not cascade. I am using >>> Mapserver 7.0. I read that the GetFeatureInfo request supports >>> cascading. >>> All requests are enabled in the metadata. Do I have to add a special tag >>> in the metatada or layer section to "pass through" the GetFeatureInfo >>> from >>> the original WMS? >>> >>> Thanks for your help. >>> >>> Best regards >>> >>> Cora Berger >>> >>> >>> _______________________________________________ >>> 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 > > >mit freundlichen Gr??en > >-- >Holger Schiebold > > >____________________ >codematix GmbH >Felsbachstrasse 5/7 >D-07745 Jena >Tel. +49 (3641) 3038-34 >www.codematix.de > > > >------------------------------ > >Message: 2 >Date: Thu, 29 Oct 2015 10:28:17 -0700 >From: Mark Korver >To: "Rahkonen Jukka (MML)" , > Jeff McKenna >Cc: "Mapserver-Users \(mapserver-users at lists.osgeo.org\)" > >Subject: Re: [mapserver-users] Update Mapserver at demo.mapserver.org? >Message-ID: > XXOzQMp+aLL1jWi3hZOQ at mail.gmail.com> >Content-Type: text/plain; charset="utf-8" > >Would it help to have Mapserver 7 built as a public AMI (Amazon Machine >Image)? >I could help with that, but I would think that there are probably a number >of preferences in how Mapserver gets built. >For example I would typically build on Ubuntu and use NGINX, just because >that is more familiar to me. >-Mark Korver > >On Wed, Oct 28, 2015 at 2:31 AM, Rahkonen Jukka (MML) < >jukka.rahkonen at maanmittauslaitos.fi> wrote: > >> Hi, >> >> >> >> I wrote last year >> https://lists.osgeo.org/pipermail/mapserver-users/2014-May/076442.html >> and asked if it could be possible to update the Mapserver v. 5.6.5 that is >> running at http://demo.mapserver.org/cgi-bin/wms and I was told that not >> before general infrastructure transition is over, see >> http://wiki.osgeo.org/wiki/Infrastructure_Transition_Plan_2014 >> >> >> >> What it the situation now? It would be good to have some Mapserver 7.0 >> WMS, WFS, and WCS services online for testing the issues which are reported >> on the mailing list and in the Github issue tracker. Version 5.6.5 is >> rather useless for that. >> >> >> >> -Jukka Rahkonen- >> >> _______________________________________________ >> 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: users/attachments/20151029/2370d60e/attachment-0001.html> > >------------------------------ > >Subject: Digest Footer > >_______________________________________________ >mapserver-users mailing list >mapserver-users at lists.osgeo.org >http://lists.osgeo.org/mailman/listinfo/mapserver-users > >------------------------------ > >End of mapserver-users Digest, Vol 93, Issue 35 >*********************************************** From jukka.rahkonen at maanmittauslaitos.fi Fri Oct 30 08:15:29 2015 From: jukka.rahkonen at maanmittauslaitos.fi (Rahkonen Jukka (MML)) Date: Fri, 30 Oct 2015 15:15:29 +0000 Subject: [mapserver-users] WFS axis order in Mapserver 7.0 Message-ID: <9db420b76ee94c41b8514cbb926cb71c@C119S212VM022.msvyvi.vaha.local> Hi, I am getting EPSG:4326 data with wrong axis order from Mapserver 7.0 and WFS 1.1.0 and 2.0.0 with my demo data. However, I believe that there are automatic tests which must be passed before new Mapserver releases are published. Where could I find data, mapfiles, and tests so I could compare them with my own tests? -Jukka Rahkonen- -------------- next part -------------- An HTML attachment was scrubbed... URL: From jukka.rahkonen at maanmittauslaitos.fi Fri Oct 30 08:30:27 2015 From: jukka.rahkonen at maanmittauslaitos.fi (Rahkonen Jukka (MML)) Date: Fri, 30 Oct 2015 15:30:27 +0000 Subject: [mapserver-users] Don't Mapserver support srsName as OGC HTTP URI? Message-ID: Hi, >From WFS 1.1.0 standard: Any valid URI value can be assigned to the srsName attribute. However, in order to enhance interoperability, a web feature service must be able to process srsName attribute values with the following format models: * EPSG: * http://www.opengis.net/gml/srs/epsg.xml# * urn:EPSG:geographicCRC: Mapserver 7.0 WFS 1.1.0 does accept EPSG:4326 and it accepts also urn:ogc:def:crs:EPSG::4326. However, it does not accept srsName= http://www.opengis.net/def/crs/EPSG/0/4326 I have tested this both with GET and POST requests and I am almost sure that this is a bug but can somebody verify if my query is correct: Similar query does work with Geoserver. -Jukka Rahkonen- -------------- next part -------------- An HTML attachment was scrubbed... URL: From even.rouault at spatialys.com Fri Oct 30 08:41:34 2015 From: even.rouault at spatialys.com (Even Rouault) Date: Fri, 30 Oct 2015 16:41:34 +0100 Subject: [mapserver-users] WFS axis order in Mapserver 7.0 In-Reply-To: <9db420b76ee94c41b8514cbb926cb71c@C119S212VM022.msvyvi.vaha.local> References: <9db420b76ee94c41b8514cbb926cb71c@C119S212VM022.msvyvi.vaha.local> Message-ID: <201510301641.35153.even.rouault@spatialys.com> Le vendredi 30 octobre 2015 16:15:29, Rahkonen Jukka (MML) a ?crit : > Hi, > > I am getting EPSG:4326 data with wrong axis order from Mapserver 7.0 and > WFS 1.1.0 and 2.0.0 with my demo data. However, I believe that there are > automatic tests which must be passed before new Mapserver releases are > published. Where could I find data, mapfiles, and tests so I could compare > them with my own tests? https://github.com/mapserver/msautotest/tree/master/wxs For example https://github.com/mapserver/msautotest/blob/master/wxs/wfs_200.map has # srsName # Next 3 requests should be equivalent in result # RUN_PARMS: wfs_200_getfeature_srsname.xml [MAPSERV] QUERY_STRING="map=[MAPFILE]&SERVICE=WFS&VERSION=2.0.0&REQUEST=GetFeature&TYPENAMES=province&SRSNAME=EPSG:4269" > [RESULT_DEVERSION] # RUN_PARMS: wfs_200_getfeature_urn_srsname.xml [MAPSERV] QUERY_STRING="map=[MAPFILE]&SERVICE=WFS&VERSION=2.0.0&REQUEST=GetFeature&TYPENAMES=province&SRSNAME=urn:ogc:def:crs:EPSG::4269" > [RESULT_DEVERSION] # RUN_PARMS: wfs_200_post_getfeature_srsname.xml [MAPSERV] [POST][/POST] > [RESULT_DEVERSION] # And if you look at : https://github.com/mapserver/msautotest/blob/master/wxs/expected/wfs_200_getfeature_srsname.xml the axis order seems ok (somewhere in Canada I believe) This is with EPSG:4269 but should work similarly for EPSG:4326 > > -Jukka Rahkonen- -- Spatialys - Geospatial professional services http://www.spatialys.com From even.rouault at spatialys.com Fri Oct 30 09:03:26 2015 From: even.rouault at spatialys.com (Even Rouault) Date: Fri, 30 Oct 2015 17:03:26 +0100 Subject: [mapserver-users] Don't Mapserver support srsName as OGC HTTP URI? In-Reply-To: References: Message-ID: <201510301703.26394.even.rouault@spatialys.com> Le vendredi 30 octobre 2015 16:30:27, Rahkonen Jukka (MML) a ?crit : > Hi, > > From WFS 1.1.0 standard: > > Any valid URI value can be assigned to the srsName attribute. However, in > order to enhance interoperability, a web feature service must be able to > process srsName attribute values with the following format models: * > EPSG: > * http://www.opengis.net/gml/srs/epsg.xml# > * urn:EPSG:geographicCRC: > > Mapserver 7.0 WFS 1.1.0 does accept EPSG:4326 and it accepts also > urn:ogc:def:crs:EPSG::4326. However, it does not accept srsName= > http://www.opengis.net/def/crs/EPSG/0/4326 Yep, confirmed. The relevant code is at https://github.com/mapserver/mapserver/blob/branch-7-0/mapwfs.c#L310 That could probably be routed to https://github.com/mapserver/mapserver/blob/branch-7-0/mapfile.c#L1527 which supports more syntaxes, but it might not be obvious to get back the EPSG code from the projectionObj* object. Hence probably this custom method in the WFS code to get the EPSG code and compare it to the list of authorized ones. > > I have tested this both with GET and POST requests and I am almost sure > that this is a bug but can somebody verify if my query is correct: > > > xmlns:gml="http://www.opengis.net/gml" > xmlns:wfs="http://www.opengis.net/wfs" service="WFS" version="1.1.0" > maxFeatures="1000" outputFormat="text/xml; subtype=gml/3.1.1"> srsName="http://www.opengis.net/def/crs/EPSG/0/4326" > typeName="states_table"> > > > Similar query does work with Geoserver. Yes, it would probably be good to support the http://www.opengis.net/def/crs/EPSG/0/ syntax which is the latest one promoted by OGC I think ? Until they change again their minds. > > -Jukka Rahkonen- -- Spatialys - Geospatial professional services http://www.spatialys.com From jukka.rahkonen at maanmittauslaitos.fi Fri Oct 30 09:10:41 2015 From: jukka.rahkonen at maanmittauslaitos.fi (Rahkonen Jukka (MML)) Date: Fri, 30 Oct 2015 16:10:41 +0000 Subject: [mapserver-users] WFS axis order in Mapserver 7.0 Message-ID: <65e7b75defe14c079882016f6d193a49@C119S212VM022.msvyvi.vaha.local> Hi, I am testing with the latest MS4W: MapServer version 7.0.0 (MS4W 3.1.0) I put test data and mapfile to http://latuviitta.org/downloads/MS_axis_test.zip Map file may have some dirt from the original one that I simplified but I did test that it shows the issue for me with request: http://localhost:8060/cgi-bin/mapserv.exe?map=c:/ms4w/apps/axis_test.map&service=WFS&version=2.0.0&request=getfeature&typename=states_shp Part of the response: -88.071564 37.510990 -88.087883 37.476273 -88.311707 37.442852 Same lon-lat order comes with WFS 1.1.0 and of course with WFS 1.0.0. If it works for you then perhaps the issue is in MS4W. -Jukka Rahkonen- Even Rouault wrote: Le vendredi 30 octobre 2015 16:15:29, Rahkonen Jukka (MML) a ?crit : > Hi, > > I am getting EPSG:4326 data with wrong axis order from Mapserver 7.0 > and WFS 1.1.0 and 2.0.0 with my demo data. However, I believe that > there are automatic tests which must be passed before new Mapserver > releases are published. Where could I find data, mapfiles, and tests > so I could compare them with my own tests? https://github.com/mapserver/msautotest/tree/master/wxs For example https://github.com/mapserver/msautotest/blob/master/wxs/wfs_200.map has # srsName # Next 3 requests should be equivalent in result # RUN_PARMS: wfs_200_getfeature_srsname.xml [MAPSERV] QUERY_STRING="map=[MAPFILE]&SERVICE=WFS&VERSION=2.0.0&REQUEST=GetFeature&TYPENAMES=province&SRSNAME=EPSG:4269" > [RESULT_DEVERSION] # RUN_PARMS: wfs_200_getfeature_urn_srsname.xml [MAPSERV] QUERY_STRING="map=[MAPFILE]&SERVICE=WFS&VERSION=2.0.0&REQUEST=GetFeature&TYPENAMES=province&SRSNAME=urn:ogc:def:crs:EPSG::4269" > [RESULT_DEVERSION] # RUN_PARMS: wfs_200_post_getfeature_srsname.xml [MAPSERV] [POST][/POST] > [RESULT_DEVERSION] # And if you look at : https://github.com/mapserver/msautotest/blob/master/wxs/expected/wfs_200_getfeature_srsname.xml the axis order seems ok (somewhere in Canada I believe) This is with EPSG:4269 but should work similarly for EPSG:4326 > > -Jukka Rahkonen- -- Spatialys - Geospatial professional services http://www.spatialys.com From even.rouault at spatialys.com Fri Oct 30 09:28:28 2015 From: even.rouault at spatialys.com (Even Rouault) Date: Fri, 30 Oct 2015 17:28:28 +0100 Subject: [mapserver-users] WFS axis order in Mapserver 7.0 In-Reply-To: <65e7b75defe14c079882016f6d193a49@C119S212VM022.msvyvi.vaha.local> References: <65e7b75defe14c079882016f6d193a49@C119S212VM022.msvyvi.vaha.local> Message-ID: <201510301728.28752.even.rouault@spatialys.com> Le vendredi 30 octobre 2015 17:10:41, Rahkonen Jukka (MML) a ?crit : > Hi, > > I am testing with the latest MS4W: > MapServer version 7.0.0 (MS4W 3.1.0) > > I put test data and mapfile to > http://latuviitta.org/downloads/MS_axis_test.zip Map file may have some > dirt from the original one that I simplified but I did test that it shows > the issue for me with request: > http://localhost:8060/cgi-bin/mapserv.exe?map=c:/ms4w/apps/axis_test.map&s > ervice=WFS&version=2.0.0&request=getfeature&typename=states_shp > > Part of the response: > -88.071564 37.510990 -88.087883 37.476273 > -88.311707 37.442852 > > Same lon-lat order comes with WFS 1.1.0 and of course with WFS 1.0.0. > > If it works for you then perhaps the issue is in MS4W. It didn't work for me either. I had a hard time figuring out what's wrong and what's wrong is the following line: "ows_srs" "CRS:84 EPSG:4326 EPSG:32634 EPSG:3857 EPSG:2923" and more particularly the CRS:84 at the beginning. It confuses mapserver to think the order is lon/lat. If you remove it, everything's fine again. This might be a bug, or nut, as I recall there's a quite complex explanation somewhere in the doc describing the precedence between MAP projection, LAYER projection, ows_srs at MAP level, wfs_srs at LAYER level... (I finally found https://github.com/mapserver/msautotest/blob/master/wxs/wfs_200_allgeoms.map which is a test with EPSG:4326 data and requests without explicit srsName and the results are correct : https://github.com/mapserver/msautotest/blob/master/wxs/expected/wfs_200_allgeoms_getfeature.xml ) > > -Jukka Rahkonen- > > Even Rouault wrote: > > Le vendredi 30 octobre 2015 16:15:29, Rahkonen Jukka (MML) a ?crit : > > Hi, > > > > I am getting EPSG:4326 data with wrong axis order from Mapserver 7.0 > > and WFS 1.1.0 and 2.0.0 with my demo data. However, I believe that > > there are automatic tests which must be passed before new Mapserver > > releases are published. Where could I find data, mapfiles, and tests > > so I could compare them with my own tests? > > https://github.com/mapserver/msautotest/tree/master/wxs > > For example > https://github.com/mapserver/msautotest/blob/master/wxs/wfs_200.map > has > > # srsName > # Next 3 requests should be equivalent in result # RUN_PARMS: > wfs_200_getfeature_srsname.xml [MAPSERV] > QUERY_STRING="map=[MAPFILE]&SERVICE=WFS&VERSION=2.0.0&REQUEST=GetFeature&T > YPENAMES=province&SRSNAME=EPSG:4269" > [RESULT_DEVERSION] # RUN_PARMS: > wfs_200_getfeature_urn_srsname.xml [MAPSERV] > QUERY_STRING="map=[MAPFILE]&SERVICE=WFS&VERSION=2.0.0&REQUEST=GetFeature&T > YPENAMES=province&SRSNAME=urn:ogc:def:crs:EPSG::4269" > [RESULT_DEVERSION] > # RUN_PARMS: wfs_200_post_getfeature_srsname.xml [MAPSERV] [POST] version="1.0" ?> xmlns="http://www.opengis.net/wfs/2.0" > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xsi:schemaLocation="http://www.opengis.net/wfs/2.0 > http://schemas.opengis.net/wfs/2.0/wfs.xsd"> typeNames="province">[/POST] > [RESULT_DEVERSION] # > > And if you look at : > > https://github.com/mapserver/msautotest/blob/master/wxs/expected/wfs_200_ge > tfeature_srsname.xml > > the axis order seems ok (somewhere in Canada I believe) > > This is with EPSG:4269 but should work similarly for EPSG:4326 > > > -Jukka Rahkonen- > > -- > 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 -- Spatialys - Geospatial professional services http://www.spatialys.com From jukka.rahkonen at maanmittauslaitos.fi Fri Oct 30 14:28:58 2015 From: jukka.rahkonen at maanmittauslaitos.fi (Rahkonen Jukka (MML)) Date: Fri, 30 Oct 2015 21:28:58 +0000 Subject: [mapserver-users] WFS axis order in Mapserver 7.0 In-Reply-To: <201510301728.28752.even.rouault@spatialys.com> References: <65e7b75defe14c079882016f6d193a49@C119S212VM022.msvyvi.vaha.local>, <201510301728.28752.even.rouault@spatialys.com> Message-ID: <1446240539344.7467@maanmittauslaitos.fi> Hi Even, OK, now I undestand that this issue is a side effect of my attempt to study the Github issue https://github.com/mapserver/mapserver/issues/3126 when I added CRS:84 into my mapfile. CRS:84 is OK to be used in mapfile because it belongs to WMS 1.3.0 and no ordinary user can guess that it might have bad effects to WFS. >From our documentation http://mapserver.org/ogc/wfs_server.html: "The OGC WFS 1.1 and 2.0 specifications allow more than one SRS to be advertised, and one of the SRSs will be advertised as the default SRS (the default SRS will be the first in the list specified in the METADATA wfs_srs / ows_srs)." I would say that if I put CRS:84 into firs SRS on the ows_srs list then it should be advertised as the defaultSRS in WFS 1.1.0 and 2.0.0 GetCapabilities (perhaps in suitable WVS versions as well), and all requests without srsName should then send data in CRS:84 and use longitude-latitude axis order in output geometries and when evaluating filters which are used in requests. The CRS:84 example of http://geonames.nga.mil/nameswfs/default.htm looks good to me "MBR within Filter - request EPSG:4326 response CRS:84 " Alternatively CRS:84 should just be skipped totally in all places where it does not work correctly. Can Proj4 seems to recognize CRS:84 so it might be possible to handle it correctly. gdalsrsinfo crs:84 PROJ.4 : '+proj=longlat +datum=WGS84 +no_defs ' OGC WKT : GEOGCS["WGS 84", DATUM["WGS_1984", SPHEROID["WGS 84",6378137,298.257223563, AUTHORITY["EPSG","7030"]], AUTHORITY["EPSG","6326"]], PRIMEM["Greenwich",0, AUTHORITY["EPSG","8901"]], UNIT["degree",0.0174532925199433, AUTHORITY["EPSG","9122"]], AUTHORITY["EPSG","4326"]] -Jukka Rahkonen- ________________________________________ Even Rouault wrote: Le vendredi 30 octobre 2015 17:10:41, Rahkonen Jukka (MML) a ?crit : > Hi, > > I am testing with the latest MS4W: > MapServer version 7.0.0 (MS4W 3.1.0) > > I put test data and mapfile to > http://latuviitta.org/downloads/MS_axis_test.zip Map file may have some > dirt from the original one that I simplified but I did test that it shows > the issue for me with request: > http://localhost:8060/cgi-bin/mapserv.exe?map=c:/ms4w/apps/axis_test.map&s > ervice=WFS&version=2.0.0&request=getfeature&typename=states_shp > > Part of the response: > -88.071564 37.510990 -88.087883 37.476273 > -88.311707 37.442852 > > Same lon-lat order comes with WFS 1.1.0 and of course with WFS 1.0.0. > > If it works for you then perhaps the issue is in MS4W. It didn't work for me either. I had a hard time figuring out what's wrong and what's wrong is the following line: "ows_srs" "CRS:84 EPSG:4326 EPSG:32634 EPSG:3857 EPSG:2923" and more particularly the CRS:84 at the beginning. It confuses mapserver to think the order is lon/lat. If you remove it, everything's fine again. This might be a bug, or nut, as I recall there's a quite complex explanation somewhere in the doc describing the precedence between MAP projection, LAYER projection, ows_srs at MAP level, wfs_srs at LAYER level... (I finally found https://github.com/mapserver/msautotest/blob/master/wxs/wfs_200_allgeoms.map which is a test with EPSG:4326 data and requests without explicit srsName and the results are correct : https://github.com/mapserver/msautotest/blob/master/wxs/expected/wfs_200_allgeoms_getfeature.xml ) > > -Jukka Rahkonen- > > Even Rouault wrote: > > Le vendredi 30 octobre 2015 16:15:29, Rahkonen Jukka (MML) a ?crit : > > Hi, > > > > I am getting EPSG:4326 data with wrong axis order from Mapserver 7.0 > > and WFS 1.1.0 and 2.0.0 with my demo data. However, I believe that > > there are automatic tests which must be passed before new Mapserver > > releases are published. Where could I find data, mapfiles, and tests > > so I could compare them with my own tests? > > https://github.com/mapserver/msautotest/tree/master/wxs > > For example > https://github.com/mapserver/msautotest/blob/master/wxs/wfs_200.map > has > > # srsName > # Next 3 requests should be equivalent in result # RUN_PARMS: > wfs_200_getfeature_srsname.xml [MAPSERV] > QUERY_STRING="map=[MAPFILE]&SERVICE=WFS&VERSION=2.0.0&REQUEST=GetFeature&T > YPENAMES=province&SRSNAME=EPSG:4269" > [RESULT_DEVERSION] # RUN_PARMS: > wfs_200_getfeature_urn_srsname.xml [MAPSERV] > QUERY_STRING="map=[MAPFILE]&SERVICE=WFS&VERSION=2.0.0&REQUEST=GetFeature&T > YPENAMES=province&SRSNAME=urn:ogc:def:crs:EPSG::4269" > [RESULT_DEVERSION] > # RUN_PARMS: wfs_200_post_getfeature_srsname.xml [MAPSERV] [POST] version="1.0" ?> xmlns="http://www.opengis.net/wfs/2.0" > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xsi:schemaLocation="http://www.opengis.net/wfs/2.0 > http://schemas.opengis.net/wfs/2.0/wfs.xsd"> typeNames="province">[/POST] > [RESULT_DEVERSION] # > > And if you look at : > > https://github.com/mapserver/msautotest/blob/master/wxs/expected/wfs_200_ge > tfeature_srsname.xml > > the axis order seems ok (somewhere in Canada I believe) > > This is with EPSG:4269 but should work similarly for EPSG:4326 > > > -Jukka Rahkonen- > > -- > 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 -- Spatialys - Geospatial professional services http://www.spatialys.com From miladnidal2604 at gmail.com Fri Oct 30 17:52:57 2015 From: miladnidal2604 at gmail.com (milad nidal) Date: Fri, 30 Oct 2015 20:52:57 -0400 Subject: [mapserver-users] WMS Cascading Message-ID: Hi, I have 100 layer for a large area.. I was creating cache (Mapcache linux) and Mapserver 6.4 (Windows). I?m creating some WMS from layer in Postgis and some from other WMS (cascading from another Mapserver Linux) and everything was correct. Later we started using Mapserver 7 (Linux) and Mapcache Linux. The result is not nice.. We get something like an outline of cascading WMS and this happened only when we do a cache (it is correct when we visualize the cascading WMS for one layer in the browser). I?m using the style "" and "wms_transparent" "true" and "wms_format" "image/png". Thanks for any help -------------- next part -------------- An HTML attachment was scrubbed... URL: From even.rouault at spatialys.com Sat Oct 31 08:00:14 2015 From: even.rouault at spatialys.com (Even Rouault) Date: Sat, 31 Oct 2015 16:00:14 +0100 Subject: [mapserver-users] WFS axis order in Mapserver 7.0 In-Reply-To: <1446240539344.7467@maanmittauslaitos.fi> References: <65e7b75defe14c079882016f6d193a49@C119S212VM022.msvyvi.vaha.local> <201510301728.28752.even.rouault@spatialys.com> <1446240539344.7467@maanmittauslaitos.fi> Message-ID: <201510311600.14880.even.rouault@spatialys.com> Le vendredi 30 octobre 2015 22:28:58, Rahkonen Jukka (MML) a ?crit : > Hi Even, > > OK, now I undestand that this issue is a side effect of my attempt to study > the Github issue https://github.com/mapserver/mapserver/issues/3126 when I > added CRS:84 into my mapfile. > > CRS:84 is OK to be used in mapfile because it belongs to WMS 1.3.0 and no > ordinary user can guess that it might have bad effects to WFS. > > From our documentation http://mapserver.org/ogc/wfs_server.html: > > "The OGC WFS 1.1 and 2.0 specifications allow more than one SRS to be > advertised, and one of the SRSs will be advertised as the default SRS (the > default SRS will be the first in the list specified in the METADATA > wfs_srs / ows_srs)." > > I would say that if I put CRS:84 into firs SRS on the ows_srs list then it > should be advertised as the defaultSRS in WFS 1.1.0 and 2.0.0 > GetCapabilities (perhaps in suitable WVS versions as well), and all > requests without srsName should then send data in CRS:84 and use > longitude-latitude axis order in output geometries and when evaluating > filters which are used in requests. The CRS:84 example of > http://geonames.nga.mil/nameswfs/default.htm looks good to me "MBR within > Filter - request EPSG:4326 response CRS:84 " You can probably create an issue to track this. The skipping solution would probably be the easiest one. I'm not sure to remember what would be involved to properly support CRS:84. Probably would require gulping several aspirin pills as with all axis ordering issues. As a workaround, you could have distinct wfs_srs and wms_srs lists. > > Alternatively CRS:84 should just be skipped totally in all places where it > does not work correctly. Can Proj4 seems to recognize CRS:84 so it might > be possible to handle it correctly. > > gdalsrsinfo crs:84 > > PROJ.4 : '+proj=longlat +datum=WGS84 +no_defs ' > > OGC WKT : > GEOGCS["WGS 84", > DATUM["WGS_1984", > SPHEROID["WGS 84",6378137,298.257223563, > AUTHORITY["EPSG","7030"]], > AUTHORITY["EPSG","6326"]], > PRIMEM["Greenwich",0, > AUTHORITY["EPSG","8901"]], > UNIT["degree",0.0174532925199433, > AUTHORITY["EPSG","9122"]], > AUTHORITY["EPSG","4326"]] > > -Jukka Rahkonen- > > ________________________________________ > Even Rouault wrote: > > Le vendredi 30 octobre 2015 17:10:41, Rahkonen Jukka (MML) a ?crit : > > Hi, > > > > I am testing with the latest MS4W: > > MapServer version 7.0.0 (MS4W 3.1.0) > > > > I put test data and mapfile to > > http://latuviitta.org/downloads/MS_axis_test.zip Map file may have some > > dirt from the original one that I simplified but I did test that it shows > > the issue for me with request: > > http://localhost:8060/cgi-bin/mapserv.exe?map=c:/ms4w/apps/axis_test.map& > > s ervice=WFS&version=2.0.0&request=getfeature&typename=states_shp > > > > Part of the response: > > -88.071564 37.510990 -88.087883 37.476273 > > -88.311707 37.442852 > > > > Same lon-lat order comes with WFS 1.1.0 and of course with WFS 1.0.0. > > > > If it works for you then perhaps the issue is in MS4W. > > It didn't work for me either. I had a hard time figuring out what's wrong > and what's wrong is the following line: > > "ows_srs" "CRS:84 EPSG:4326 EPSG:32634 EPSG:3857 EPSG:2923" > > and more particularly the CRS:84 at the beginning. It confuses mapserver to > think the order is lon/lat. If you remove it, everything's fine again. This > might be a bug, or nut, as I recall there's a quite complex explanation > somewhere in the doc describing the precedence between MAP projection, > LAYER projection, ows_srs at MAP level, wfs_srs at LAYER level... > > (I finally found > https://github.com/mapserver/msautotest/blob/master/wxs/wfs_200_allgeoms.ma > p which is a test with EPSG:4326 data and requests without explicit srsName > and the results are correct : > https://github.com/mapserver/msautotest/blob/master/wxs/expected/wfs_200_al > lgeoms_getfeature.xml ) > > > -Jukka Rahkonen- > > > > Even Rouault wrote: > > > > Le vendredi 30 octobre 2015 16:15:29, Rahkonen Jukka (MML) a ?crit : > > > Hi, > > > > > > I am getting EPSG:4326 data with wrong axis order from Mapserver 7.0 > > > and WFS 1.1.0 and 2.0.0 with my demo data. However, I believe that > > > there are automatic tests which must be passed before new Mapserver > > > releases are published. Where could I find data, mapfiles, and tests > > > so I could compare them with my own tests? > > > > https://github.com/mapserver/msautotest/tree/master/wxs > > > > For example > > https://github.com/mapserver/msautotest/blob/master/wxs/wfs_200.map > > has > > > > # srsName > > # Next 3 requests should be equivalent in result # RUN_PARMS: > > wfs_200_getfeature_srsname.xml [MAPSERV] > > QUERY_STRING="map=[MAPFILE]&SERVICE=WFS&VERSION=2.0.0&REQUEST=GetFeature& > > T YPENAMES=province&SRSNAME=EPSG:4269" > [RESULT_DEVERSION] # RUN_PARMS: > > wfs_200_getfeature_urn_srsname.xml [MAPSERV] > > QUERY_STRING="map=[MAPFILE]&SERVICE=WFS&VERSION=2.0.0&REQUEST=GetFeature& > > T YPENAMES=province&SRSNAME=urn:ogc:def:crs:EPSG::4269" > > > [RESULT_DEVERSION] # RUN_PARMS: wfs_200_post_getfeature_srsname.xml > > [MAPSERV] [POST] > version="2.0.0" > > xmlns="http://www.opengis.net/wfs/2.0" > > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > > xsi:schemaLocation="http://www.opengis.net/wfs/2.0 > > http://schemas.opengis.net/wfs/2.0/wfs.xsd"> > typeNames="province">[/POST] > [RESULT_DEVERSION] # > > > > And if you look at : > > > > https://github.com/mapserver/msautotest/blob/master/wxs/expected/wfs_200_ > > ge tfeature_srsname.xml > > > > the axis order seems ok (somewhere in Canada I believe) > > > > This is with EPSG:4269 but should work similarly for EPSG:4326 > > > > > -Jukka Rahkonen- > > > > -- > > 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 > > -- > Spatialys - Geospatial professional services > http://www.spatialys.com -- Spatialys - Geospatial professional services http://www.spatialys.com From aperi2007 at gmail.com Sat Oct 31 14:50:21 2015 From: aperi2007 at gmail.com (Andrea Peri) Date: Sat, 31 Oct 2015 22:50:21 +0100 Subject: [mapserver-users] How setting the legend color from mapscript Message-ID: Hi, I try to have a set like this: LEGEND IMAGECOLOR 255 255 255 using a python mapscript code. My code is this: msMap = mapscript.mapObj() .... legendColor = mapscript.colorObj(255,255,255,0) msMap.legend.imagecolor=legendColor But the mapfile dont have the IMAGECOLOR 255 255 255 Is imagecolor supported in the python mapscript ? Thx, -- ----------------- Andrea Peri . . . . . . . . . qwerty ????? ----------------- From thomas.bonfort at gmail.com Thu Oct 22 02:32:05 2015 From: thomas.bonfort at gmail.com (thomas bonfort) Date: Thu, 22 Oct 2015 09:32:05 -0000 Subject: [mapserver-users] Label formatting on GRID In-Reply-To: References: Message-ID: There is no such support that I know of in mapserver. Your first use-case could be implemented by extending the grid labelling function to get it's text from a mapserver expression, and extending the expression syntax to include integer division and modulo operators. Your second use-case is more involved and would require multiple label blocks along with the aforementioned enhancements. Both cases are not trivial and would require funding. regards, thomas On 13 October 2015 at 05:59, Matt McClelland wrote: > Hi All > > I am wanting to truncate (simplify) the grid numbering to match the grid > reference users would use in the field. > > Looking at the top right (of the attached example) I would like > 236000 to just display as 36 and > 6263000 to just display as 63 > > In a perfect world I would love it to display like this > a subscript (little) 2 followed by standard 36 = 236 and > a subscript (little) 62 followed by standard 63 = 6263 > > Any suggestions ?? > > Thanks :) > > The attache map I generated using mapserver 7.0 > The Grid map file is > LAYER > GROUP "default" > NAME "grid" > METADATA > "DESCRIPTION" "Grid" > END > TYPE LINE > STATUS ON > CLASS > NAME "Graticule" > COLOR 100 100 100 > LABEL > COLOR 255 0 0 > FONT sc > TYPE truetype > SIZE 8 > POSITION AUTO > PARTIALS FALSE > FORCE TRUE > BUFFER -10 > OUTLINECOLOR 255 255 255 > END > END > PROJECTION > "init=epsg:28356" > END > GRID > LABELFORMAT '%.0f' > MININTERVAL 1000 > END > END # Layer > > Matt :)[image: Inline image 1] > > > _______________________________________________ > 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: mapserv (1).jpg Type: image/jpeg Size: 79286 bytes Desc: not available URL: