From jmckenna at gatewaygeomatics.com  Sun Sep  1 04:05:25 2019
From: jmckenna at gatewaygeomatics.com (Jeff McKenna)
Date: Sun, 1 Sep 2019 08:05:25 -0300
Subject: [mapserver-users] Updated MS4W ZOO-Project package (1.8dev) for
	Windows users
In-Reply-To: <299122de-909f-59df-f6ac-6a5054d939e2@gatewaygeomatics.com>
References: <299122de-909f-59df-f6ac-6a5054d939e2@gatewaygeomatics.com>
Message-ID: <8f6b2408-2b6b-6ef0-8708-67a82d6c0ab7@gatewaygeomatics.com>

The MS4W 4.0.1 installer now will download ZOO-Project 1.8dev (compiled
  today from today's SVN/head).   Here is the manual link to the new ZOO 
package, if you already have MS4W 4.0.1 : 
https://ms4w.com/release/apps/zoo-project-1.8dev-ms4w.zip

  Compiled WPS services include:
   - MapServer support (automatically generate mapfile+OGC services)
   - Python3 support
   - PHP7 support
   - mono support
   - java support
   - OGR services:
     - base-vector-ops (all)
     - ogr2ogr
     - base-vector-ops-py
       - see discussion in ticket #230
   - GDAL services:
     - contour, dem, grid, profile, translate, warp
   - utils/status

  Also configured main.cfg to point to local MS4W's curl certificate 
bundle (for HTTPS connections)

MS4W is a proud longtime member of the ZOO tribe.  Thanks and have a 
nice weekend!

"MS4W: open doors as well as windows"
https://ms4w.com

-jeff






From lars.schylberg at blixtmail.se  Tue Sep  3 12:15:31 2019
From: lars.schylberg at blixtmail.se (Lars Schylberg)
Date: Tue, 3 Sep 2019 21:15:31 +0200
Subject: [mapserver-users] Mapserver optimize talk - from Foss4G in Bucharest
Message-ID: <033685c1-4ae4-d48d-e393-07ac6a01e70f@blixtmail.se>

Hi,

The recording of my talk "Mapserver - optimize for performance" from 
last week is available here:

https://media.ccc.de/v/bucharest-271-mapserver-optimize-for-performance

The full code examples that I mention, can be found here:

*road_shields_13_long_version_MS_Syntax.map* 
<https://gist.github.com/LarsSchy/092c2688a36337683db914cb72599969#file-road_shields_13_long_version_ms_syntax-map>

https://gist.github.com/LarsSchy/092c2688a36337683db914cb72599969

*roadsigns_proc_fk.sh * 
<https://gist.github.com/LarsSchy/090dd391a4e4107452978a8f8b179ba7#file-roadsigns_proc_fk-sh>

https://gist.github.com/LarsSchy/090dd391a4e4107452978a8f8b179ba7

*road_shields_13_fast_MS_syntax.map * 
<https://gist.github.com/LarsSchy/6d60610e0790db7caba122d7c2ce0a79#file-road_shields_13_fast_ms_syntex-map>

https://gist.github.com/LarsSchy/6d60610e0790db7caba122d7c2ce0a79

*import_raster_retile_v3.sh* 
<https://gist.github.com/LarsSchy/9ecb31eb964dd83820c139b2f2769a7c#file-import_raster_retile_v3-sh>

https://gist.github.com/LarsSchy/9ecb31eb964dd83820c139b2f2769a7c

Have fun

/Lars Schylberg


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mapserver-users/attachments/20190903/9abb2bca/attachment.htm>

From MarkVolz at co.lyon.mn.us  Fri Sep  6 11:35:53 2019
From: MarkVolz at co.lyon.mn.us (Mark Volz)
Date: Fri, 6 Sep 2019 18:35:53 +0000
Subject: [mapserver-users] mapcache: restricted extent and ruleset to
 limit cache area seems ineffective
In-Reply-To: <CALtm4h33-9UDUHOjGKdBzezRFLzdjOokfFo-wrFCHbWqv2pMpg@mail.gmail.com>
References: <dee5c7b27a0748fe8e841f28e5230fa7@co.lyon.mn.us>
 <CALtm4h33-9UDUHOjGKdBzezRFLzdjOokfFo-wrFCHbWqv2pMpg@mail.gmail.com>
Message-ID: <37555663bba146b68238c16b15fc44ff@co.lyon.mn.us>

Hello,

I am still having issues restricting the extent in my mapcache area using rulesets.  I created a rule for all of my zoom levels that has a limited visibility extent.  However, Mapcache is still returning imagery for the entire grid area even though I created a rule that should only display a limited extent.  I am still not sure why the visibility extent rule seems ineffective.

Thanks!

________________________________
You can set the

<errors>empty_img</errors>

To return a blank tile.  I believe the status is still 404 - I don't think you can control this

On Fri, 30 Aug 2019 at 15:44, Mark Volz <MarkVolz at co.lyon.mn.us<mailto:MarkVolz at co.lyon.mn.us>> wrote:
Hello,
 I am in the process of limiting the cached area in mapcache.  I am having trouble with both the restricted_extent and ruleset parameters.  I first started by using restricted_extent such as ?<grid restricted_extent="435567 98889 568247 259687">LyonCC</grid>?.  That parameter seemed to work.  However mapcache returned 404 errors for any tiles outside of the restricted extent.  Next I tried to use rulesets instead.  The rulesets seem to have no effect, and new tiles were getting generated outside of the visibility extent.
 Question 1:  When we use restricted extents on a grid should MapCache return a transparent tile, white tile, or a 404 error?  Can we control what it returns?
 Question 2:  Do I have my ruleset configured appropriately?
 <tileset name="LyonBaseMap">
<grid ruleset="CountyBuffer">LyonCC</grid>
</tileset>
 <ruleset name="CountyBuffer">
<rule zoom_level="1 2 3 4 5 6 7 8 9 10 11"><!?Do I need to include zoom levels?-->
<visibility>
<extent>435567 98889 568247 259687</extent>
</visibility>
</rule>
</ruleset>
 Thank You!

Sincerely,
Mark Volz, GISP
_______________________________________________
mapserver-users mailing list
mapserver-users at lists.osgeo.org<mailto:mapserver-users at lists.osgeo.org>
https://lists.osgeo.org/mailman/listinfo/mapserver-users<https://linkprotect.cudasvc.com/url?a=https%3a%2f%2flists.osgeo.org%2fmailman%2flistinfo%2fmapserver-users&c=E,1,6lLLKxr4YQ4gS0gO-fBg_QGwrJ8NxU_Qs7RwHq0qR8cvYcIZcYFAPHM9maX52KR__kCixDuKb7sTCiozp0p31et-WqjfL0pBYi_rbBr-m7rA1J_hoO7IhowR&typo=1>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mapserver-users/attachments/20190906/a09fa76d/attachment.htm>

From steve.lime at state.mn.us  Fri Sep  6 14:34:04 2019
From: steve.lime at state.mn.us (Lime, Steve D (MNIT))
Date: Fri, 6 Sep 2019 21:34:04 +0000
Subject: [mapserver-users] mapcache: restricted extent and ruleset to
 limit cache area seems ineffective
In-Reply-To: <37555663bba146b68238c16b15fc44ff@co.lyon.mn.us>
References: <dee5c7b27a0748fe8e841f28e5230fa7@co.lyon.mn.us>
 <CALtm4h33-9UDUHOjGKdBzezRFLzdjOokfFo-wrFCHbWqv2pMpg@mail.gmail.com>
 <37555663bba146b68238c16b15fc44ff@co.lyon.mn.us>
Message-ID: <BN6PR09MB139593C8A8CD43DF4D771D1EDABA0@BN6PR09MB1395.namprd09.prod.outlook.com>

Is it returning a blank tile? If so that might be expected. I thought mapcache would return a blank tile for requests outside the grid extent.

From: mapserver-users [mailto:mapserver-users-bounces at lists.osgeo.org] On Behalf Of Mark Volz
Sent: Friday, September 06, 2019 1:36 PM
To: Travis Kirstine <traviskirstine at gmail.com>
Cc: mapserver-users at lists.osgeo.org
Subject: Re: [mapserver-users] mapcache: restricted extent and ruleset to limit cache area seems ineffective

This message may be from an external email source.
Do not select links or open attachments unless verified. Report all suspicious emails to Minnesota IT Services Security Operations Center.

Hello,

I am still having issues restricting the extent in my mapcache area using rulesets.  I created a rule for all of my zoom levels that has a limited visibility extent.  However, Mapcache is still returning imagery for the entire grid area even though I created a rule that should only display a limited extent.  I am still not sure why the visibility extent rule seems ineffective.

Thanks!

________________________________
You can set the

<errors>empty_img</errors>

To return a blank tile.  I believe the status is still 404 - I don't think you can control this

On Fri, 30 Aug 2019 at 15:44, Mark Volz <MarkVolz at co.lyon.mn.us<mailto:MarkVolz at co.lyon.mn.us>> wrote:
Hello,
 I am in the process of limiting the cached area in mapcache.  I am having trouble with both the restricted_extent and ruleset parameters.  I first started by using restricted_extent such as ?<grid restricted_extent="435567 98889 568247 259687">LyonCC</grid>?.  That parameter seemed to work.  However mapcache returned 404 errors for any tiles outside of the restricted extent.  Next I tried to use rulesets instead.  The rulesets seem to have no effect, and new tiles were getting generated outside of the visibility extent.
 Question 1:  When we use restricted extents on a grid should MapCache return a transparent tile, white tile, or a 404 error?  Can we control what it returns?
 Question 2:  Do I have my ruleset configured appropriately?
 <tileset name="LyonBaseMap">
<grid ruleset="CountyBuffer">LyonCC</grid>
</tileset>
 <ruleset name="CountyBuffer">
<rule zoom_level="1 2 3 4 5 6 7 8 9 10 11"><!?Do I need to include zoom levels?-->
<visibility>
<extent>435567 98889 568247 259687</extent>
</visibility>
</rule>
</ruleset>
 Thank You!

Sincerely,
Mark Volz, GISP
_______________________________________________
mapserver-users mailing list
mapserver-users at lists.osgeo.org<mailto:mapserver-users at lists.osgeo.org>
https://lists.osgeo.org/mailman/listinfo/mapserver-users<https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.osgeo.org%2Fmailman%2Flistinfo%2Fmapserver-users&data=02%7C01%7Csteve.lime%40state.mn.us%7Cd77753cd04294d16be5708d732f91114%7Ceb14b04624c445198f26b89c2159828c%7C0%7C1%7C637033917625038578&sdata=%2FdtbdLEeeiE8S4PsFkY84yNJRe2TeJyQVA%2BdJGflxsg%3D&reserved=0>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mapserver-users/attachments/20190906/9aeb5609/attachment.htm>

From tchaddad at gmail.com  Fri Sep  6 14:45:13 2019
From: tchaddad at gmail.com (TC Haddad)
Date: Fri, 6 Sep 2019 16:45:13 -0500
Subject: [mapserver-users] mapcache: restricted extent and ruleset to
 limit cache area seems ineffective
In-Reply-To: <37555663bba146b68238c16b15fc44ff@co.lyon.mn.us>
References: <dee5c7b27a0748fe8e841f28e5230fa7@co.lyon.mn.us>
 <CALtm4h33-9UDUHOjGKdBzezRFLzdjOokfFo-wrFCHbWqv2pMpg@mail.gmail.com>
 <37555663bba146b68238c16b15fc44ff@co.lyon.mn.us>
Message-ID: <CAFVrPygfYkGYn1hY+ERwH2R7iZJR96T1_zNM+8k0pFksiXWVPg@mail.gmail.com>

I?ve had success setting a mask at the Mapserver level, and MapCache has
not problem only rendering imagery to the edge of whatever irregular shape
you need to use (e.g. watershed or county boundary). So maybe try that?

However It?s true, MapCache will still return blank tiles outside the mask
area.

Tanya

On Fri, Sep 6, 2019 at 1:36 PM Mark Volz <MarkVolz at co.lyon.mn.us> wrote:

> Hello,
>
>
>
> I am still having issues restricting the extent in my mapcache area using
> rulesets.  I created a rule for all of my zoom levels that has a limited
> visibility extent.  However, Mapcache is still returning imagery for the
> entire grid area even though I created a rule that should only display a
> limited extent.  I am still not sure why the visibility extent rule seems
> ineffective.
>
>
>
> Thanks!
>
>
> ------------------------------
>
> You can set the
>
> <errors>empty_img</errors>
>
> To return a blank tile.  I believe the status is still 404 - I don't think you can control this
>
>
>
> On Fri, 30 Aug 2019 at 15:44, Mark Volz <MarkVolz at co.lyon.mn.us> wrote:
>
> Hello,
>
>  I am in the process of limiting the cached area in mapcache.  I am having
> trouble with both the restricted_extent and ruleset parameters.  I first
> started by using restricted_extent such as ?<grid restricted_extent="435567
> 98889 568247 259687">LyonCC</grid>?.  That parameter seemed to work.
> However mapcache returned 404 errors for any tiles outside of the
> restricted extent.  Next I tried to use rulesets instead.  The rulesets
> seem to have no effect, and new tiles were getting generated outside of the
> visibility extent.
>
>  Question 1:  When we use restricted extents on a grid should MapCache
> return a transparent tile, white tile, or a 404 error?  Can we control what
> it returns?
>
>  Question 2:  Do I have my ruleset configured appropriately?
>
>  <tileset name="LyonBaseMap">
>
> <grid ruleset="CountyBuffer">LyonCC</grid>
>
> </tileset>
>
>  <ruleset name="CountyBuffer">
>
> <rule zoom_level="1 2 3 4 5 6 7 8 9 10 11"><!?Do I need to include zoom
> levels?-->
>
> <visibility>
>
> <extent>435567 98889 568247 259687</extent>
>
> </visibility>
>
> </rule>
>
> </ruleset>
>
>  Thank You!
>
>
>
> Sincerely,
>
> *Mark Volz, GISP*
>
> _______________________________________________
> mapserver-users mailing list
> mapserver-users at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/mapserver-users
> <https://linkprotect.cudasvc.com/url?a=https%3a%2f%2flists.osgeo.org%2fmailman%2flistinfo%2fmapserver-users&c=E,1,6lLLKxr4YQ4gS0gO-fBg_QGwrJ8NxU_Qs7RwHq0qR8cvYcIZcYFAPHM9maX52KR__kCixDuKb7sTCiozp0p31et-WqjfL0pBYi_rbBr-m7rA1J_hoO7IhowR&typo=1>
>
> _______________________________________________
> mapserver-users mailing list
> mapserver-users at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/mapserver-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mapserver-users/attachments/20190906/56beb9e5/attachment.htm>

From ikeszei at yahoo.com  Sat Sep  7 03:02:12 2019
From: ikeszei at yahoo.com (ikeszei at yahoo.com)
Date: Sat, 7 Sep 2019 12:02:12 +0200
Subject: [mapserver-users] Highly inefficient MakeValid statement in
	Mapserver-generated spatial queries
Message-ID: <000601d56563$530fa6c0$f92ef440$@yahoo.com>

Hello, 

 

I noticed that when MapServer issues the query to MS SQL Server, it appends
a .MakeValid() tag to the geometry field, which makes data access highly
inefficient as no spatial indexes can be used when the MakeValid() is used.
Here is the query that is being produced:

 

SELECT 

convert(nvarchar(max), [label]),

[ogr_geometry],

convert(varchar(36), [ogr_fid]) 

FROM 

section 

WHERE 

ogr_geometry.MakeValid().STIntersects(geometry::STGeomFromText('POLYGON((-10
973271.1167343 5605636.0681215,-10963019.0003155
5605636.0681215,-10963019.0003155 5614459.76757417,-10973271.1167343
5614459.76757417,-10973271.1167343 5605636.0681215))',3857)) = 1

 

Here is the data access string from the map file:

 

DATA "ogr_geometry from section USING UNIQUE ogr_fid USING SRID=3857"

 

Earlier I was using a specific HINT for index usage:

 

DATA "ogr_geometry from section WITH (INDEX(section_ogr_geometry_idx)) USING
UNIQUE ogr_fid USING SRID=3857"

 

But since MapServer adds the MakeValid automatically, I am getting the
following error:

 

Msg 8635, Level 16, State 9, Line 1

The query processor could not produce a query plan for a query with a
spatial index hint.  Reason: Could not find required binary spatial method
in a condition.  Try removing the index hints or removing SET FORCEPLAN.

 

How do I configure mapserver to NOT ADD the MakeValid to every single one of
its queries ?

 

Any response is much appreciated !

 

Thanks,

Istvan

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mapserver-users/attachments/20190907/c1a4cd0f/attachment.htm>

From sethg at geographika.co.uk  Sat Sep  7 12:35:11 2019
From: sethg at geographika.co.uk (Seth G)
Date: Sat, 07 Sep 2019 21:35:11 +0200
Subject: [mapserver-users]
 =?utf-8?q?Highly_inefficient_MakeValid_statemen?=
 =?utf-8?q?t_in=09Mapserver-generated_spatial_queries?=
In-Reply-To: <000601d56563$530fa6c0$f92ef440$@yahoo.com>
References: <000601d56563$530fa6c0$f92ef440$@yahoo.com>
Message-ID: <7d9d6e05-21f7-4441-8549-55cd545702b9@www.fastmail.com>

Hi,

Good question. This is a fairly new change as part of https://github.com/mapserver/mapserver/issues/5781 from April this year. 
In SQL Profiler I seem to get GEOM.STIntersects for WFS requests and GEOM.MakeVaid().STIntersects for WMS. 
MakeValid does appear to stop the index being used. Do you have a link which says this definitively?

Seth

--
web:http://geographika.co.uk
twitter: @geographika


On Sat, Sep 7, 2019, at 12:02 PM, ikeszei at yahoo.com wrote:
> Hello,

> 

> I noticed that when MapServer issues the query to MS SQL Server, it appends a .MakeValid() tag to the geometry field, which makes data access highly inefficient as no spatial indexes can be used when the MakeValid() is used. Here is the query that is being produced:

> 

> SELECT

> convert(nvarchar(max), [label]),

> [ogr_geometry],

> convert(varchar(36), [ogr_fid])

> FROM

> section

> WHERE

> ogr_geometry.*MakeValid()*.STIntersects(geometry::STGeomFromText('POLYGON((-10973271.1167343 5605636.0681215,-10963019.0003155 5605636.0681215,-10963019.0003155 5614459.76757417,-10973271.1167343 5614459.76757417,-10973271.1167343 5605636.0681215))',3857)) = 1

> 

> Here is the data access string from the map file:

> 

> *DATA "ogr_geometry from section USING UNIQUE ogr_fid USING SRID=3857"*

> 

> Earlier I was using a specific HINT for index usage:

> 

> *DATA "ogr_geometry from section WITH (INDEX(section_ogr_geometry_idx)) USING UNIQUE ogr_fid USING SRID=3857"*

> 

> But since MapServer adds the MakeValid automatically, I am getting the following error:

> 

> Msg 8635, Level 16, State 9, Line 1

> The query processor could not produce a query plan for a query with a spatial index hint. Reason: Could not find required binary spatial method in a condition. Try removing the index hints or removing SET FORCEPLAN.

> 

> How do I configure mapserver to NOT ADD the MakeValid to every single one of its queries ?

> 

> Any response is much appreciated !

> 

> Thanks,

> Istvan

> 

> 

> _______________________________________________
> mapserver-users mailing list
> mapserver-users at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/mapserver-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mapserver-users/attachments/20190907/8a4f40e0/attachment.htm>

From szekerest at gmail.com  Sat Sep  7 14:55:43 2019
From: szekerest at gmail.com (Tamas Szekeres)
Date: Sat, 7 Sep 2019 23:55:43 +0200
Subject: [mapserver-users] Highly inefficient MakeValid statement in
 Mapserver-generated spatial queries
In-Reply-To: <7d9d6e05-21f7-4441-8549-55cd545702b9@www.fastmail.com>
References: <000601d56563$530fa6c0$f92ef440$@yahoo.com>
 <7d9d6e05-21f7-4441-8549-55cd545702b9@www.fastmail.com>
Message-ID: <CACALY+Trmg_hLeVo+apGmE1LhkVysGO_WeiazCRk9H+1Bv512w@mail.gmail.com>

I think we can remove MakeValid from the queries entirely.
The problem is that if the table contains invalid geometries, the entire
query will fail.

Best regards,

Tamas


Seth G <sethg at geographika.co.uk> ezt ?rta (id?pont: 2019. szept. 7., Szo,
21:35):

> Hi,
>
> Good question. This is a fairly new change as part of
> https://github.com/mapserver/mapserver/issues/5781 from April this year.
> In SQL Profiler I seem to get GEOM.STIntersects for WFS requests and
> GEOM.MakeVaid().STIntersects for WMS.
> MakeValid does appear to stop the index being used. Do you have a link
> which says this definitively?
>
> Seth
>
> --
> web:http://geographika.co.uk
> twitter: @geographika
>
>
> On Sat, Sep 7, 2019, at 12:02 PM, ikeszei at yahoo.com wrote:
>
> Hello,
>
>
>
> I noticed that when MapServer issues the query to MS SQL Server, it
> appends a .MakeValid() tag to the geometry field, which makes data access
> highly inefficient as no spatial indexes can be used when the MakeValid()
> is used. Here is the query that is being produced:
>
>
>
> SELECT
>
> convert(nvarchar(max), [label]),
>
> [ogr_geometry],
>
> convert(varchar(36), [ogr_fid])
>
> FROM
>
> section
>
> WHERE
>
> ogr_geometry.*MakeValid()*.STIntersects(geometry::STGeomFromText('POLYGON((-10973271.1167343
> 5605636.0681215,-10963019.0003155 5605636.0681215,-10963019.0003155
> 5614459.76757417,-10973271.1167343 5614459.76757417,-10973271.1167343
> 5605636.0681215))',3857)) = 1
>
>
>
> Here is the data access string from the map file:
>
>
>
> *DATA "ogr_geometry from section USING UNIQUE ogr_fid USING SRID=3857"*
>
>
>
> Earlier I was using a specific HINT for index usage:
>
>
>
> *DATA "ogr_geometry from section WITH (INDEX(section_ogr_geometry_idx))
> USING UNIQUE ogr_fid USING SRID=3857"*
>
>
>
> But since MapServer adds the MakeValid automatically, I am getting the
> following error:
>
>
>
> Msg 8635, Level 16, State 9, Line 1
>
> The query processor could not produce a query plan for a query with a
> spatial index hint.  Reason: Could not find required binary spatial method
> in a condition.  Try removing the index hints or removing SET FORCEPLAN.
>
>
>
> How do I configure mapserver to NOT ADD the MakeValid to every single one
> of its queries ?
>
>
>
> Any response is much appreciated !
>
>
>
> Thanks,
>
> Istvan
>
>
>
>
> _______________________________________________
> mapserver-users mailing list
> mapserver-users at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/mapserver-users
>
>
> _______________________________________________
> mapserver-users mailing list
> mapserver-users at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/mapserver-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mapserver-users/attachments/20190907/b4a862ce/attachment.htm>

From ikeszei at yahoo.com  Sat Sep  7 15:30:47 2019
From: ikeszei at yahoo.com (Istvan Keszei)
Date: Sun, 8 Sep 2019 00:30:47 +0200
Subject: [mapserver-users] Highly inefficient MakeValid statement in
	Mapserver-generated spatial queries
In-Reply-To: <CACALY+Trmg_hLeVo+apGmE1LhkVysGO_WeiazCRk9H+1Bv512w@mail.gmail.com>
References: <000601d56563$530fa6c0$f92ef440$@yahoo.com>
 <7d9d6e05-21f7-4441-8549-55cd545702b9@www.fastmail.com>
 <CACALY+Trmg_hLeVo+apGmE1LhkVysGO_WeiazCRk9H+1Bv512w@mail.gmail.com>
Message-ID: <84E9191F-27C2-4A86-8381-70BF54BA59EC@yahoo.com>

We have real large geospatial tables.  Not having an option to turn MakeValid off will kill our applications? performance as indexes are essential. 

For a simple query, the disk reads are 100x more for a query including the MakeValid. Hence, the cpu resources required are multifold too.

Yes, please turn it off or make it optional. Can this be done manually somehow? We have waited long months for 4.0.1 to come out (with the opacity fix) and now this issue prevents the upgrade. 

I see the invalid geometries more of a data maintenance responsibility rather than a query-side-responsibility. I understand for some people this is convenient, so that is why I suggest to make this optional. 

Any help is appreciated!

Thank you,
Istvan


> On 2019. Sep 7., at 23:55, Tamas Szekeres <szekerest at gmail.com> wrote:
> 
> I think we can remove MakeValid from the queries entirely. 
> The problem is that if the table contains invalid geometries, the entire query will fail.
> 
> Best regards,
> 
> Tamas
> 
> 
> Seth G <sethg at geographika.co.uk> ezt ?rta (id?pont: 2019. szept. 7., Szo, 21:35):
>> Hi,
>> 
>> Good question. This is a fairly new change as part of https://github.com/mapserver/mapserver/issues/5781 from April this year. 
>> In SQL Profiler I seem to get GEOM.STIntersects for WFS requests and GEOM.MakeVaid().STIntersects for WMS. 
>> MakeValid does appear to stop the index being used. Do you have a link which says this definitively?
>> 
>> Seth
>> 
>> --
>> web:http://geographika.co.uk
>> twitter: @geographika
>> 
>> 
>>> On Sat, Sep 7, 2019, at 12:02 PM, ikeszei at yahoo.com wrote:
>>> Hello,
>>> 
>>>  
>>> 
>>> I noticed that when MapServer issues the query to MS SQL Server, it appends a .MakeValid() tag to the geometry field, which makes data access highly inefficient as no spatial indexes can be used when the MakeValid() is used. Here is the query that is being produced:
>>> 
>>>  
>>> 
>>> SELECT
>>> 
>>> convert(nvarchar(max), [label]),
>>> 
>>> [ogr_geometry],
>>> 
>>> convert(varchar(36), [ogr_fid])
>>> 
>>> FROM
>>> 
>>> section
>>> 
>>> WHERE
>>> 
>>> ogr_geometry.MakeValid().STIntersects(geometry::STGeomFromText('POLYGON((-10973271.1167343 5605636.0681215,-10963019.0003155 5605636.0681215,-10963019.0003155 5614459.76757417,-10973271.1167343 5614459.76757417,-10973271.1167343 5605636.0681215))',3857)) = 1
>>> 
>>>  
>>> 
>>> Here is the data access string from the map file:
>>> 
>>>  
>>> 
>>> DATA "ogr_geometry from section USING UNIQUE ogr_fid USING SRID=3857"
>>> 
>>>  
>>> 
>>> Earlier I was using a specific HINT for index usage:
>>> 
>>>  
>>> 
>>> DATA "ogr_geometry from section WITH (INDEX(section_ogr_geometry_idx)) USING UNIQUE ogr_fid USING SRID=3857"
>>> 
>>>  
>>> 
>>> But since MapServer adds the MakeValid automatically, I am getting the following error:
>>> 
>>>  
>>> 
>>> Msg 8635, Level 16, State 9, Line 1
>>> 
>>> The query processor could not produce a query plan for a query with a spatial index hint.  Reason: Could not find required binary spatial method in a condition.  Try removing the index hints or removing SET FORCEPLAN.
>>> 
>>>  
>>> 
>>> How do I configure mapserver to NOT ADD the MakeValid to every single one of its queries ?
>>> 
>>>  
>>> 
>>> Any response is much appreciated !
>>> 
>>>  
>>> 
>>> Thanks,
>>> 
>>> Istvan
>>> 
>>>  
>>> 
>>>  
>>> 
>>> _______________________________________________
>>> mapserver-users mailing list
>>> mapserver-users at lists.osgeo.org
>>> https://lists.osgeo.org/mailman/listinfo/mapserver-users
>> 
>> _______________________________________________
>> mapserver-users mailing list
>> mapserver-users at lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/mapserver-users
> _______________________________________________
> mapserver-users mailing list
> mapserver-users at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/mapserver-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mapserver-users/attachments/20190908/b47ac6f6/attachment.htm>

From sethg at geographika.co.uk  Sun Sep  8 14:05:33 2019
From: sethg at geographika.co.uk (Seth G)
Date: Sun, 08 Sep 2019 23:05:33 +0200
Subject: [mapserver-users]
 =?utf-8?q?Highly_inefficient_MakeValid_statemen?=
 =?utf-8?q?t_in_Mapserver-generated_spatial_queries?=
In-Reply-To: <84E9191F-27C2-4A86-8381-70BF54BA59EC@yahoo.com>
References: <000601d56563$530fa6c0$f92ef440$@yahoo.com>
 <7d9d6e05-21f7-4441-8549-55cd545702b9@www.fastmail.com>
 <CACALY+Trmg_hLeVo+apGmE1LhkVysGO_WeiazCRk9H+1Bv512w@mail.gmail.com>
 <84E9191F-27C2-4A86-8381-70BF54BA59EC@yahoo.com>
Message-ID: <4f72234f-81c2-4b25-84db-a8034a742e2f@www.fastmail.com>

Hi Istvan,

Unfortunately you won't be able to turn it off without recompiling the MSSQL driver. 
I've added a pull request removing these at https://github.com/mapserver/mapserver/pull/5856
This will be merged into master assuming there are no objections. 
I assume you are using ms4w as you mention a 4.0.1 release? You'll need to see when a new release of that may be available with the update. 
Thanks for reporting this issue,

Seth

--
web:http://geographika.co.uk
twitter: @geographika


On Sun, Sep 8, 2019, at 12:30 AM, Istvan Keszei wrote:
> 
> We have real large geospatial tables. Not having an option to turn MakeValid off will kill our applications? performance as indexes are essential. 
> 
> For a simple query, the disk reads are 100x more for a query including the MakeValid. Hence, the cpu resources required are multifold too.
> 
> Yes, please turn it off or make it optional. Can this be done manually somehow? We have waited long months for 4.0.1 to come out (with the opacity fix) and now this issue prevents the upgrade. 
> 
> I see the invalid geometries more of a data maintenance responsibility rather than a query-side-responsibility. I understand for some people this is convenient, so that is why I suggest to make this optional. 
> 
> Any help is appreciated!
> 
> Thank you,
> Istvan
> 
> 
> On 2019. Sep 7., at 23:55, Tamas Szekeres <szekerest at gmail.com> wrote:
>> I think we can remove MakeValid from the queries entirely. 
>> The problem is that if the table contains invalid geometries, the entire query will fail.
>> 
>> Best regards,
>> 
>> Tamas
>> 
>> 
>> Seth G <sethg at geographika.co.uk> ezt ?rta (id?pont: 2019. szept. 7., Szo, 21:35):
>>> __
>>> Hi,
>>> 
>>> Good question. This is a fairly new change as part of https://github.com/mapserver/mapserver/issues/5781 from April this year. 
>>> In SQL Profiler I seem to get GEOM.STIntersects for WFS requests and GEOM.MakeVaid().STIntersects for WMS. 
>>> MakeValid does appear to stop the index being used. Do you have a link which says this definitively?
>>> 
>>> Seth
>>> 
>>> --
>>> web:http://geographika.co.uk
>>> twitter: @geographika
>>> 
>>> 
>>> On Sat, Sep 7, 2019, at 12:02 PM, ikeszei at yahoo.com wrote:
>>>> Hello,

>>>> 

>>>> I noticed that when MapServer issues the query to MS SQL Server, it appends a .MakeValid() tag to the geometry field, which makes data access highly inefficient as no spatial indexes can be used when the MakeValid() is used. Here is the query that is being produced:

>>>> 

>>>> SELECT

>>>> convert(nvarchar(max), [label]),

>>>> [ogr_geometry],

>>>> convert(varchar(36), [ogr_fid])

>>>> FROM

>>>> section

>>>> WHERE

>>>> ogr_geometry.*MakeValid()*.STIntersects(geometry::STGeomFromText('POLYGON((-10973271.1167343 5605636.0681215,-10963019.0003155 5605636.0681215,-10963019.0003155 5614459.76757417,-10973271.1167343 5614459.76757417,-10973271.1167343 5605636.0681215))',3857)) = 1

>>>> 

>>>> Here is the data access string from the map file:

>>>> 

>>>> *DATA "ogr_geometry from section USING UNIQUE ogr_fid USING SRID=3857"*

>>>> 

>>>> Earlier I was using a specific HINT for index usage:

>>>> 

>>>> *DATA "ogr_geometry from section WITH (INDEX(section_ogr_geometry_idx)) USING UNIQUE ogr_fid USING SRID=3857"*

>>>> 

>>>> But since MapServer adds the MakeValid automatically, I am getting the following error:

>>>> 

>>>> Msg 8635, Level 16, State 9, Line 1

>>>> The query processor could not produce a query plan for a query with a spatial index hint. Reason: Could not find required binary spatial method in a condition. Try removing the index hints or removing SET FORCEPLAN.

>>>> 

>>>> How do I configure mapserver to NOT ADD the MakeValid to every single one of its queries ?

>>>> 

>>>> Any response is much appreciated !

>>>> 

>>>> Thanks,

>>>> Istvan

>>>> 

>>>> 

>>>> _______________________________________________
>>>> mapserver-users mailing list
>>>> mapserver-users at lists.osgeo.org
>>>> https://lists.osgeo.org/mailman/listinfo/mapserver-users
>>> 
>>> _______________________________________________
>>>  mapserver-users mailing list
>>> mapserver-users at lists.osgeo.org
>>> https://lists.osgeo.org/mailman/listinfo/mapserver-users
>> _______________________________________________
>> mapserver-users mailing list
>> mapserver-users at lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/mapserver-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mapserver-users/attachments/20190908/65387f25/attachment.htm>

From ikeszei at yahoo.com  Mon Sep  9 05:19:37 2019
From: ikeszei at yahoo.com (ikeszei at yahoo.com)
Date: Mon, 9 Sep 2019 14:19:37 +0200
Subject: [mapserver-users] Highly inefficient MakeValid statement in
	Mapserver-generated spatial queries
In-Reply-To: <4f72234f-81c2-4b25-84db-a8034a742e2f@www.fastmail.com>
References: <000601d56563$530fa6c0$f92ef440$@yahoo.com>
 <7d9d6e05-21f7-4441-8549-55cd545702b9@www.fastmail.com>
 <CACALY+Trmg_hLeVo+apGmE1LhkVysGO_WeiazCRk9H+1Bv512w@mail.gmail.com>
 <84E9191F-27C2-4A86-8381-70BF54BA59EC@yahoo.com>
 <4f72234f-81c2-4b25-84db-a8034a742e2f@www.fastmail.com>
Message-ID: <00c201d56708$da175860$8e460920$@yahoo.com>

Is there any chance that an ?unstable? version could be released sooner so that we don?t have to wait another 3-6 months for the next release?

This performance issue affects the entire MS4W user community for all WMS requests. It would be great if an interim version could be released sooner.

Much appreciated,

Istvan

 

From: Seth G <sethg at geographika.co.uk> 
Sent: Sunday, September 8, 2019 11:06 PM
To: Istvan Keszei <ikeszei at yahoo.com>; Tamas Szekeres <szekerest at gmail.com>
Cc: MapserverList OSGEO <mapserver-users at lists.osgeo.org>
Subject: Re: [mapserver-users] Highly inefficient MakeValid statement in Mapserver-generated spatial queries

 

Hi Istvan,

 

Unfortunately you won't be able to turn it off without recompiling the MSSQL driver. 

I've added a pull request removing these at https://github.com/mapserver/mapserver/pull/5856

This will be merged into master assuming there are no objections. 

I assume you are using ms4w as you mention a 4.0.1 release? You'll need to see when a new release of that may be available with the update.  

Thanks for reporting this issue,

 

Seth

 

--

web:http://geographika.co.uk

twitter: @geographika

 

 

On Sun, Sep 8, 2019, at 12:30 AM, Istvan Keszei wrote:

 

We have real large geospatial tables.  Not having an option to turn MakeValid off will kill our applications? performance as indexes are essential. 

 

For a simple query, the disk reads are 100x more for a query including the MakeValid. Hence, the cpu resources required are multifold too.

 

Yes, please turn it off or make it optional. Can this be done manually somehow? We have waited long months for 4.0.1 to come out (with the opacity fix) and now this issue prevents the upgrade. 

 

I see the invalid geometries more of a data maintenance responsibility rather than a query-side-responsibility. I understand for some people this is convenient, so that is why I suggest to make this optional. 

 

Any help is appreciated!

 

Thank you,

Istvan

 

 

On 2019. Sep 7., at 23:55, Tamas Szekeres <szekerest at gmail.com <mailto:szekerest at gmail.com> > wrote:

I think we can remove MakeValid from the queries entirely. 

The problem is that if the table contains invalid geometries, the entire query will fail.

 

Best regards,

 

Tamas

 

 

Seth G <sethg at geographika.co.uk <mailto:sethg at geographika.co.uk> > ezt ?rta (id?pont: 2019. szept. 7., Szo, 21:35):

 

Hi,

 

Good question. This is a fairly new change as part of https://github.com/mapserver/mapserver/issues/5781 from April this year. 

In SQL Profiler I seem to get GEOM.STIntersects for WFS requests and GEOM.MakeVaid().STIntersects for WMS. 

MakeValid does appear to stop the index being used. Do you have a link which says this definitively?

 

Seth

 

--

web:http://geographika.co.uk

twitter: @geographika

 

 

On Sat, Sep 7, 2019, at 12:02 PM, ikeszei at yahoo.com <mailto:ikeszei at yahoo.com>  wrote:

Hello,

 

I noticed that when MapServer issues the query to MS SQL Server, it appends a .MakeValid() tag to the geometry field, which makes data access highly inefficient as no spatial indexes can be used when the MakeValid() is used. Here is the query that is being produced:

 

SELECT

convert(nvarchar(max), [label]),

[ogr_geometry],

convert(varchar(36), [ogr_fid])

FROM

section

WHERE

ogr_geometry.MakeValid().STIntersects(geometry::STGeomFromText('POLYGON((-10973271.1167343 5605636.0681215,-10963019.0003155 5605636.0681215,-10963019.0003155 5614459.76757417,-10973271.1167343 5614459.76757417,-10973271.1167343 5605636.0681215))',3857)) = 1

 

Here is the data access string from the map file:

 

DATA "ogr_geometry from section USING UNIQUE ogr_fid USING SRID=3857"

 

Earlier I was using a specific HINT for index usage:

 

DATA "ogr_geometry from section WITH (INDEX(section_ogr_geometry_idx)) USING UNIQUE ogr_fid USING SRID=3857"

 

But since MapServer adds the MakeValid automatically, I am getting the following error:

 

Msg 8635, Level 16, State 9, Line 1

The query processor could not produce a query plan for a query with a spatial index hint.  Reason: Could not find required binary spatial method in a condition.  Try removing the index hints or removing SET FORCEPLAN.

 

How do I configure mapserver to NOT ADD the MakeValid to every single one of its queries ?

 

Any response is much appreciated !

 

Thanks,

Istvan

 

 

_______________________________________________

mapserver-users mailing list

mapserver-users at lists.osgeo.org <mailto:mapserver-users at lists.osgeo.org> 

https://lists.osgeo.org/mailman/listinfo/mapserver-users

 

_______________________________________________

mapserver-users mailing list

mapserver-users at lists.osgeo.org <mailto:mapserver-users at lists.osgeo.org> 

https://lists.osgeo.org/mailman/listinfo/mapserver-users

_______________________________________________

mapserver-users mailing list

mapserver-users at lists.osgeo.org <mailto:mapserver-users at lists.osgeo.org> 

https://lists.osgeo.org/mailman/listinfo/mapserver-users

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mapserver-users/attachments/20190909/ca228dc3/attachment.htm>

From jukka.rahkonen at maanmittauslaitos.fi  Mon Sep  9 06:05:13 2019
From: jukka.rahkonen at maanmittauslaitos.fi (Rahkonen Jukka (MML))
Date: Mon, 9 Sep 2019 13:05:13 +0000
Subject: [mapserver-users] Highly inefficient MakeValid statement
	in	Mapserver-generated spatial queries
Message-ID: <168607035e1e41e28e84272eaed30866@C119S212VM042.msvyvi.vaha.local>

Hi,

Fortunately not the entire MS4W community is affected, just those who work with MS SQL server.

When makevalid will be turned off MapServer admin will have another option to deal with invalid geometries: select data in  mapfile with IsValid=true. Then the faulty geometries will not show on the map but the whole layer will not fail.

-Jukka Rahkonen-

L?hett?j?: mapserver-users <mapserver-users-bounces at lists.osgeo.org> Puolesta ikeszei at yahoo.com
L?hetetty: maanantai 9. syyskuuta 2019 15.20
Vastaanottaja: 'Seth G' <sethg at geographika.co.uk>; 'Tamas Szekeres' <szekerest at gmail.com>
Kopio: 'MapserverList OSGEO' <mapserver-users at lists.osgeo.org>
Aihe: Re: [mapserver-users] Highly inefficient MakeValid statement in Mapserver-generated spatial queries

Is there any chance that an ?unstable? version could be released sooner so that we don?t have to wait another 3-6 months for the next release?
This performance issue affects the entire MS4W user community for all WMS requests. It would be great if an interim version could be released sooner.
Much appreciated,
Istvan

From: Seth G <sethg at geographika.co.uk<mailto:sethg at geographika.co.uk>>
Sent: Sunday, September 8, 2019 11:06 PM
To: Istvan Keszei <ikeszei at yahoo.com<mailto:ikeszei at yahoo.com>>; Tamas Szekeres <szekerest at gmail.com<mailto:szekerest at gmail.com>>
Cc: MapserverList OSGEO <mapserver-users at lists.osgeo.org<mailto:mapserver-users at lists.osgeo.org>>
Subject: Re: [mapserver-users] Highly inefficient MakeValid statement in Mapserver-generated spatial queries

Hi Istvan,

Unfortunately you won't be able to turn it off without recompiling the MSSQL driver.
I've added a pull request removing these at https://github.com/mapserver/mapserver/pull/5856
This will be merged into master assuming there are no objections.
I assume you are using ms4w as you mention a 4.0.1 release? You'll need to see when a new release of that may be available with the update.
Thanks for reporting this issue,

Seth

--
web:http://geographika.co.uk
twitter: @geographika


On Sun, Sep 8, 2019, at 12:30 AM, Istvan Keszei wrote:

We have real large geospatial tables.  Not having an option to turn MakeValid off will kill our applications? performance as indexes are essential.

For a simple query, the disk reads are 100x more for a query including the MakeValid. Hence, the cpu resources required are multifold too.

Yes, please turn it off or make it optional. Can this be done manually somehow? We have waited long months for 4.0.1 to come out (with the opacity fix) and now this issue prevents the upgrade.

I see the invalid geometries more of a data maintenance responsibility rather than a query-side-responsibility. I understand for some people this is convenient, so that is why I suggest to make this optional.

Any help is appreciated!

Thank you,
Istvan


On 2019. Sep 7., at 23:55, Tamas Szekeres <szekerest at gmail.com<mailto:szekerest at gmail.com>> wrote:
I think we can remove MakeValid from the queries entirely.
The problem is that if the table contains invalid geometries, the entire query will fail.

Best regards,

Tamas


Seth G <sethg at geographika.co.uk<mailto:sethg at geographika.co.uk>> ezt ?rta (id?pont: 2019. szept. 7., Szo, 21:35):

Hi,

Good question. This is a fairly new change as part of https://github.com/mapserver/mapserver/issues/5781 from April this year.
In SQL Profiler I seem to get GEOM.STIntersects for WFS requests and GEOM.MakeVaid().STIntersects for WMS.
MakeValid does appear to stop the index being used. Do you have a link which says this definitively?

Seth

--
web:http://geographika.co.uk
twitter: @geographika


On Sat, Sep 7, 2019, at 12:02 PM, ikeszei at yahoo.com<mailto:ikeszei at yahoo.com> wrote:

Hello,



I noticed that when MapServer issues the query to MS SQL Server, it appends a .MakeValid() tag to the geometry field, which makes data access highly inefficient as no spatial indexes can be used when the MakeValid() is used. Here is the query that is being produced:



SELECT

convert(nvarchar(max), [label]),

[ogr_geometry],

convert(varchar(36), [ogr_fid])

FROM

section

WHERE

ogr_geometry.MakeValid().STIntersects(geometry::STGeomFromText('POLYGON((-10973271.1167343 5605636.0681215,-10963019.0003155 5605636.0681215,-10963019.0003155 5614459.76757417,-10973271.1167343 5614459.76757417,-10973271.1167343 5605636.0681215))',3857)) = 1



Here is the data access string from the map file:



DATA "ogr_geometry from section USING UNIQUE ogr_fid USING SRID=3857"



Earlier I was using a specific HINT for index usage:



DATA "ogr_geometry from section WITH (INDEX(section_ogr_geometry_idx)) USING UNIQUE ogr_fid USING SRID=3857"



But since MapServer adds the MakeValid automatically, I am getting the following error:



Msg 8635, Level 16, State 9, Line 1

The query processor could not produce a query plan for a query with a spatial index hint.  Reason: Could not find required binary spatial method in a condition.  Try removing the index hints or removing SET FORCEPLAN.



How do I configure mapserver to NOT ADD the MakeValid to every single one of its queries ?



Any response is much appreciated !



Thanks,

Istvan




_______________________________________________
mapserver-users mailing list
mapserver-users at lists.osgeo.org<mailto:mapserver-users at lists.osgeo.org>
https://lists.osgeo.org/mailman/listinfo/mapserver-users

_______________________________________________
mapserver-users mailing list
mapserver-users at lists.osgeo.org<mailto:mapserver-users at lists.osgeo.org>
https://lists.osgeo.org/mailman/listinfo/mapserver-users
_______________________________________________
mapserver-users mailing list
mapserver-users at lists.osgeo.org<mailto:mapserver-users at lists.osgeo.org>
https://lists.osgeo.org/mailman/listinfo/mapserver-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mapserver-users/attachments/20190909/0956ac19/attachment.htm>

From traviskirstine at gmail.com  Mon Sep  9 06:25:05 2019
From: traviskirstine at gmail.com (Travis Kirstine)
Date: Mon, 9 Sep 2019 09:25:05 -0400
Subject: [mapserver-users] mapserver / gdal / proj5 docker image
Message-ID: <CALtm4h0FHRokWZiM0wYHyPy+XL_3H9xHCmoHGQrsicLfVH5WWg@mail.gmail.com>

I'm wondering if anyone knows of a docker image with mapserver using gdal
compiled with proj5?

Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mapserver-users/attachments/20190909/daf58f5c/attachment.htm>

From MarkVolz at co.lyon.mn.us  Mon Sep  9 06:30:29 2019
From: MarkVolz at co.lyon.mn.us (Mark Volz)
Date: Mon, 9 Sep 2019 13:30:29 +0000
Subject: [mapserver-users] mapcache: restricted extent and ruleset to
 limit cache area seems ineffective
Message-ID: <e271fc39f4c844ea834277a9344cc5ad@co.lyon.mn.us>

Steve,
Mapcache is unexpectedly generating and returning a new air photo image outside of the visibility extent.  

Thank You!
Sincerely,
Mark Volz

----------------------------------------------------------------------

Message: 1
Date: Fri, 6 Sep 2019 21:34:04 +0000
From: "Lime, Steve D (MNIT)" <steve.lime at state.mn.us>
To: Mark Volz <MarkVolz at co.lyon.mn.us>, Travis Kirstine
        <traviskirstine at gmail.com>
Cc: "mapserver-users at lists.osgeo.org"
        <mapserver-users at lists.osgeo.org>
Subject: Re: [mapserver-users] mapcache: restricted extent and ruleset
        to limit cache area seems ineffective
Message-ID:
        <BN6PR09MB139593C8A8CD43DF4D771D1EDABA0 at BN6PR09MB1395.namprd09.prod.outlook.com>

Content-Type: text/plain; charset="utf-8"

Is it returning a blank tile? If so that might be expected. I thought mapcache would return a blank tile for requests outside the grid extent.

From: mapserver-users [mailto:mapserver-users-bounces at lists.osgeo.org] On Behalf Of Mark Volz
Sent: Friday, September 06, 2019 1:36 PM
To: Travis Kirstine <traviskirstine at gmail.com>
Cc: mapserver-users at lists.osgeo.org
Subject: Re: [mapserver-users] mapcache: restricted extent and ruleset to limit cache area seems ineffective

This message may be from an external email source.
Do not select links or open attachments unless verified. Report all suspicious emails to Minnesota IT Services Security Operations Center.

Hello,

I am still having issues restricting the extent in my mapcache area using rulesets.  I created a rule for all of my zoom levels that has a limited visibility extent.  However, Mapcache is still returning imagery for the entire grid area even though I created a rule that should only display a limited extent.  I am still not sure why the visibility extent rule seems ineffective.

Thanks!

From bob.basques at ci.stpaul.mn.us  Wed Sep 11 08:38:45 2019
From: bob.basques at ci.stpaul.mn.us (Basques, Bob (CI-StPaul))
Date: Wed, 11 Sep 2019 15:38:45 +0000
Subject: [mapserver-users] REMINDER: OSGeo Local Chapter (aka TCMUG) Meeting
Message-ID: <56BFE7B1-4A09-4E97-BC60-84B9BBB99E82@ci.stpaul.mn.us>

Sorry everyone, I usually send these out the day before, but got real busy end of the day yesterday.

Anyway, we had a really good turnout last meeting, with a lot of new faces.  Let?s keep that momentum going.

The next meeting (tonight) will be at:

Brunson's Pub
956 Payne Ave, Saint Paul, MN  55130

Time:  4:30 - 6:00

See you there!

bobb




-------------- next part --------------
A non-text attachment was scrubbed...
Name: OSGeo Local Chapter (aka TCMUG) Meeting.ics
Type: text/calendar
Size: 1476 bytes
Desc: OSGeo Local Chapter (aka TCMUG) Meeting.ics
URL: <http://lists.osgeo.org/pipermail/mapserver-users/attachments/20190911/55082a5b/attachment.ics>

From bob.basques at ci.stpaul.mn.us  Fri Sep 13 06:56:08 2019
From: bob.basques at ci.stpaul.mn.us (Basques, Bob (CI-StPaul))
Date: Fri, 13 Sep 2019 13:56:08 +0000
Subject: [mapserver-users] OSGeo Local Chapter (aka TCMUG) Meeting
Message-ID: <6D0C5CC0-0346-4E1C-904D-248F98A582CB@ci.stpaul.mn.us>

Hello all,

Good turnout<https://www.dropbox.com/s/sena18k01nzwwmi/20190911_181849_brunsons_pub.jpg?dl=0> this past Wed. at Brunson Pub, especially with the rainy weather.  Some nice discussion about what folks have been working on.

The next Meeting will be on Oct 9th, the week after the GIS/LIS.


Place:  Holmans Table
Time:  4:30 PM

See you there.

bobb






OSGeo Local Chapter (aka TCMUG) Meeting

Scheduled: Oct 9, 2019 at 4:30 PM to 6:00 PM

Location: Holman's Table

644 Bayfield St, Saint Paul, MN  55107, United States

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mapserver-users/attachments/20190913/9c1ca0c2/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: iCal-20190913-085207.ics
Type: text/calendar
Size: 1541 bytes
Desc: iCal-20190913-085207.ics
URL: <http://lists.osgeo.org/pipermail/mapserver-users/attachments/20190913/9c1ca0c2/attachment.ics>

From jmckenna at gatewaygeomatics.com  Sat Sep 14 08:33:42 2019
From: jmckenna at gatewaygeomatics.com (Jeff McKenna)
Date: Sat, 14 Sep 2019 12:33:42 -0300
Subject: [mapserver-users] maintenance version 7.4.2 released
Message-ID: <49c52e8f-9b8a-b8d8-d0bd-e11ace9464b5@gatewaygeomatics.com>

The maintenance release of MapServer 7.4.2 is now available for 
download: http://mapserver.org/download.html

For a list of the many changes please see the changelog: 
https://mapserver.org/development/changelog/changelog-7-4.html

Thank you to all of the users, developers, documenters, and packagers 
for sharing the passion for such a great project.

-- 
The MapServer Team








From sconstatinescu at gmail.com  Wed Sep 18 19:36:30 2019
From: sconstatinescu at gmail.com (Serban Constantinescu)
Date: Thu, 19 Sep 2019 05:36:30 +0300
Subject: [mapserver-users] Attribute Query/ItemQuery Mapserver 7.4.2,
	OS X failure
Message-ID: <CAMGokZh_oYe5RbTqaTLwuPy2OJq=qVJ2g8pUTTHueX053oDzNA@mail.gmail.com>

Hello everybody,

BACKGROUND INFO
------------------------------
I compiled and installed Mapserver 7.4.2 on OS X 10.13.6 as a framework,
64-bit, using CMAKE. It works.
The dependencies I am using are the frameworks from KyngChaos (
http://www.kyngchaos.com/):
GDAL 2.4, PROJ 5.0, GEOS 3.7.x, Postgres 9.6, PostGIS 2.5, etc.

I used on and off Mapserver since version 5.x so, I know how it's supposed
to work. After installation, when I run in terminal
"$ /Library/WebServer/CGI-Executables/mapserv -v"

I get:
MapServer version 7.4.2 OUTPUT=PNG OUTPUT=JPEG OUTPUT=KML SUPPORTS=PROJ
SUPPORTS=AGG SUPPORTS=FREETYPE SUPPORTS=CAIRO SUPPORTS=ICONV
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

ISSUE:
----------
I am trying to create simple files (*.map and *.html) in a directory named
"msquery" where I can successfully implement the Search by Attribute,
basically a prototype. For this, I created a shapefile, in EPSG:3857 (web
mercator), with 3 shapes: a rectangle, a circle, and a triangle. The DBF
file shows (wkt_geom is not in the DBF file):

OID (Integer),STYPE(string) -- WKT geometry in Shapefile
1,rectangle, -- wkt_geom: LineString (3194696 5605893, 3196116 5605893,
3196116 5604938, 3194696 5604938, 3194696 5605893)
2,circle, -- ...too many vertices to list here...
3,triangle -- wkt_geom: LineString (3197117 5604282, 3196225 5602525,
3198201 5602525, 3197117 5604282)

What I want is a very simple thing. In an html file displaying the map,
have a form with a text input, where if I enter STYPE="rectangle" or
STYPE="triangle" (qitem=STYPE&qstring=triangle), to take me to the same
html page or another one, that would display a map image, displaying either
the rectangle or the triangle (the queried item), zoomed at the shape's
extent +5% buffer (whatever Mapserver's default is), with a highlighted
color.

Here's my files:

1) index.html -- simple file initializing the map via a form:
<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="utf-8" />
    <title>Index File - Initialize Mapserver App</title>
</head>
<body>
<p>Set default variables and initialze the Mapserver app and map.</p>
<hr>
<form method="get" name="initialize" action="/cgi-bin/mapserv">
<input type="radio" name="map"
value="/Library/Webserver/Documents/msquery/qry.map" checked> MAP =
qry.map<br>
<input type="radio" name="layer" value="testdata" checked> LAYER =
testdata<br>
<!-- apparently mode=BROWSE is set by default, so it's not needed here-->
<input type="submit" value="display map">
</form>
</body>
</html>

2) qry_browse.html
<!-- Mapserver Template -->
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8" />
<title>Index File Attribute Query Demo</title>
</head>
<body>
<center>

<form method="GET" action="/cgi-bin/mapserv" name="mapserv">
<table>
<tr>
<td>
<!-- map image -->
<input type="image" name="img" src="[img]" width="[mapwidth]"
height="[mapheight]" border="1" alt="this is the map">
<!-- // map image -->
</td>
<td valign="top">
<font size="-1">
<input type="radio" name="map" value="[map]" checked> MAP:
&quot;[map]&quot; <br>
<input type="radio" name="layer" value="[layer]" checked> LAYER:
&quot;[layer]&quot; <br>
&nbsp; IMGXY = [center] <br>
&nbsp; IMGEXT = [mapext] <br>
<hr>
Map Mode:<br>
<input type="radio" name="mode" value="browse" selected> browse<br>
------------------------ <br>
<input type="radio" name="mode" value="itemquery"> itemquery<br>
QLAYER: "testdata"<br>
<input type="hidden" name="qlayer" value="testdata">
QITEM: "STYPE"<br>
<input type="hidden" name="qitem" value="STYPE">
QSTRING: <input type="text" name="qstring" value=""><br>
</font>
</td>
</tr>
</table>
<hr>
<!-- these 2 are required for centering the map where clicked, while
panning the image in BROWSE mode -->
<input type="hidden" name="imgxy" value="[center]">
<input type="hidden" name="imgext" value="[mapext]">

<input type="submit" value="refresh">
</form>

</center>
</body>
</html>

3) qry.map

MAP

IMAGETYPE PNG24
NAME QUERYDEMO
SIZE 1000 800
EXTENT 3192000 5601300 3202000 5608000 # in epsg:3857
PROJECTION
"init=epsg:3857"
END
UNITS METERS
SHAPEPATH "data"
IMAGECOLOR 255 255 255
# TEMPLATEPATTERN may not be needed
TRANSPARENT ON

CONFIG "MS_ERRORFILE"
"/Library/WebServer/Documents/msquery/ms_error_log.txt"
DEBUG 5

WEB
MINSCALEDENOM 106
MAXSCALEDENOM 54167.9728005186
IMAGEPATH "/Library/WebServer/Documents/msquery/tmp/"
IMAGEURL "/msquery/tmp/"
LOG "/Library/WebServer/Documents/msquery/ms_error_log.txt"
METADATA
# no need for WMS/WFS for this demo
END
TEMPLATE qry_browse.html
VALIDATION
'qstring'  '.'
'STYPE' '.'
'OID' '.'
END
END # WEB

# SYMBOL DEFINITIONS
SYMBOL
NAME 'circle'
TYPE ELLIPSE
POINTS 1 1 END
FILLED TRUE
END


QUERYMAP
COLOR 0 0 255
STATUS ON
STYLE HILITE
END

LAYER # line layer begins here
NAME         testdata
DATA         "testdata.shp"
STATUS       ON
TYPE         LINE
PROJECTION
"init=epsg:3857"
END
CLASS
TEMPLATE "qry_browse.html" # this seems to be ncecessary to make the
layer/class queriable
NAME 'default'# Name to use in legends for this class. If not set class
won?t show up in legend.
STYLE
SYMBOL     0
COLOR      255 0 0
SIZE       1
END
STATUS on
# TEMPLATE # Template file or URL to use in presenting query results to the
user. See Templating for more info.
END # end of CLASS
#VALIDATION # As of MapServer 5.4.0, VALIDATION blocks are the preferred
mechanism for specifying validation patterns for CGI param runtime
substitutions. See Run-time Substitution.
#END # end of VALIDATION
END # end of LAYER

END # end of mapfile

At this point the error I'm getting is:
msQueryByFilter(): Search returned no results. No matching record(s) found.

I don't know of the VALIDATION block is correct (syntax) and/or if it's
placed where it should be.
I also don't know if the "qry_browse.html" html is is supposed to display
the query results, or the query form should redirect the display to a
different html template.
I also don't know if the search map file should be different than qry.map.

I've been banging my head against the walls for the past 2.5 days and it
seems to go nowhere, for such a simple feature. The documentation did not
help me very much, nor did the Mapserver demo files, as the examples are
old, they do not contain text/attribute based queries, plus the query
validation has changed several times across version since the demo was
built.

I am attaching a zipped copy of my prototype folder for ease of evaluation.

Thanks in advance for your help.

PS: this should eventually make it in the demo, as it is probably one of
the most necessary features users look for.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mapserver-users/attachments/20190919/564b1bc9/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: msquery.zip
Type: application/zip
Size: 11920 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/mapserver-users/attachments/20190919/564b1bc9/attachment.zip>

From jpass at bgs.ac.uk  Thu Sep 19 03:24:25 2019
From: jpass at bgs.ac.uk (Passmore, James H.)
Date: Thu, 19 Sep 2019 10:24:25 +0000
Subject: [mapserver-users] msWFSGetStoredQuery(): WFS server error.
	Cannot open file
Message-ID: <CWXP123MB256523E102774B9B0FF64FDCEB890@CWXP123MB2565.GBRP123.PROD.OUTLOOK.COM>

Answering my own question,

on Windows the filedef path must be absolute.

so "wfs_CommodityByYearStoredQuery_filedef" "storedQry/comm-by-year.map" doesn't work but

"wfs_CommodityByYearStoredQuery_filedef" " C:/some/path/to/test/my/storedQry/comm-by-year.map" works


James Passmore
-------------------------------
British Geological Survey,
Environmental Science Centre,
KEYWORTH,
United Kingdom,
NG12 5GG

orcid: https://orcid.org/0000-0002-9891-6265
-------------------------------
Phone: +44 (0)115 936 3125
-------------------------------
Skype: BGSjames



This email and any attachments are intended solely for the use of the named recipients. If you are not the intended recipient you must not use, disclose, copy or distribute this email or any of its attachments and should notify the sender immediately and delete this email from your system.
UK Research and Innovation has taken every reasonable precaution to minimise risk of this email or any attachments containing viruses or malware but the recipient should carry out its own virus and malware checks before opening the attachments. UK Research and Innovation does not accept any liability for any losses or damages which the recipient may sustain due to presence of any viruses.
Opinions, conclusions or other information in this message and attachments that are not related directly to UK Research and Innovation business are solely those of the author and do not represent the views of UK Research and Innovation.



From louis-philippe.rousseaulambert2 at canada.ca  Thu Sep 19 11:13:00 2019
From: louis-philippe.rousseaulambert2 at canada.ca (Rousseau Lambert2, Louis-Philippe (EC))
Date: Thu, 19 Sep 2019 18:13:00 +0000
Subject: [mapserver-users] "ows_http_max_age" have no effect...
Message-ID: <1568916739298.60764@canada.ca>

Hi everyone!


I'm trying to set a cache-control maximum age for my web services and am having some difficulties making it work.


I have added the line `"ows_http_max_age" "10800"` in my mapfile (MAP.WEB.METADATA) but the response headers I get does not have any cache-control value:


```
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mapserver-users/attachments/20190919/e94d325c/attachment.htm>

From louis-philippe.rousseaulambert2 at canada.ca  Thu Sep 19 11:25:01 2019
From: louis-philippe.rousseaulambert2 at canada.ca (Rousseau Lambert2, Louis-Philippe (EC))
Date: Thu, 19 Sep 2019 18:25:01 +0000
Subject: [mapserver-users] TR: "ows_http_max_age" have no effect...
In-Reply-To: <1568916739298.60764@canada.ca>
References: <1568916739298.60764@canada.ca>
Message-ID: <1568917459908.77552@canada.ca>

Oups sorry, pressed the shift key too soon... Here is the complete message/question:


Hi everyone!


I'm trying to set a cache-control maximum age for my web services and am having some difficulties making it work.


I have added the line `"ows_http_max_age" "10800"` in my mapfile (MAP.WEB.METADATA) but the response headers I get (from curl) does not have any cache-control value:


```

HTTP/1.0 200 OK
Date: Thu, 19 Sep 2019 18:08:46 GMT
Server: WSGIServer/0.1 Python/2.7.6
Content-type: image/png
Content-Length: 653383
```

I am using:

MapServer version 7.0.7 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 SUPPORTS=POINT_Z_M INPUT=JPEG INPUT=POSTGIS INPUT=OGR INPUT=GDAL INPUT=SHAPEFILE


and here is a minimal working mapfile example, you can use any *TMP_TGL_2* data from

http://dd.weather.gc.ca/model_gem_global/25km/grib2/lat_lon/00/000/


```

    MAP
 NAME ""
 IMAGETYPE PNG
 EXTENT -180 -90 180 90
 MAXSIZE 4096
 SIZE 500 300
 IMAGECOLOR 255 255 255
 PROJECTION
  "init=epsg:4326"
 END
 TRANSPARENT ON
 DEBUG 5
     WEB
      METADATA
    "ows_http_max_age" "10800"
    "ows_extent" "-180 -90 180 90"
    "wms_getmap_formatlist" "image/png,image/jpeg"
    "ows_enable_request" "*"
    "ows_srs" "EPSG:4326"
    "ows_title" "example"
      END
     END
    LAYER
     NAME "GDPS"
     DEBUG 5
     TYPE RASTER
     TOLERANCE 15
     TEMPLATE "ttt.html"
PROJECTION
 "proj=longlat"
 "a=6371229"
 "b=6371229"
 "no_defs"
 "pm=-359.88"
END
     DATA '/path/to/model_gem_global/25km/grib2/lat_lon/00/015/CMC_glb_TMP_TGL_2_latlon.24x.24_2019091900_P015.grib2'
     METADATA
      "ows_title" "GDPS"
      "ows_include_items" "all"
      "ows_abstract" "stuf"
      "ows_extent" "-180 -90.24 180 90"
      "ows_geomtype" "Geometry"
      "ows_size" "1500 751"
      "gml_include_items" "all"
     END
CLASSGROUP "TEMPERATURE-LINEAR"
CLASS
 NAME "1"
 GROUP "TEMPERATURE-LINEAR"
 EXPRESSION ([pixel] < 0)
 STYLE
  COLORRANGE 0 0 255 0 255 0
  DATARANGE -100.0 0
 END
END
CLASS
 NAME "2"
 GROUP "TEMPERATURE-LINEAR"
 EXPRESSION ([pixel] >= 0)
 STYLE
  COLORRANGE 0 255 0 255 0 0
  DATARANGE 0 50
 END
END
   END
END


Thanks


LP

________________________________
De : Rousseau Lambert2, Louis-Philippe (EC)
Envoy? : 19 septembre 2019 14:13
? : mapserver-users at lists.osgeo.org
Objet : "ows_http_max_age" have no effect...


Hi everyone!


I'm trying to set a cache-control maximum age for my web services and am having some difficulties making it work.


I have added the line `"ows_http_max_age" "10800"` in my mapfile (MAP.WEB.METADATA) but the response headers I get does not have any cache-control value:


```
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mapserver-users/attachments/20190919/dfa1e859/attachment.htm>

From jukka.rahkonen at maanmittauslaitos.fi  Thu Sep 19 16:43:20 2019
From: jukka.rahkonen at maanmittauslaitos.fi (Rahkonen Jukka (MML))
Date: Thu, 19 Sep 2019 23:43:20 +0000
Subject: [mapserver-users] How does colorrange actually work with vector
	layers?
Message-ID: <f628b8ab7a0e44fc88024f5b50d32286@C119S212VM042.msvyvi.vaha.local>

Hi,

Documentation of colorrange in https://www.mapserver.org/mapfile/style.html suggests to find details from https://www.mapserver.org/development/rfc/ms-rfc-6.html#rfc6 but the RFC does not really tell what was finally implemented. Is this what is documented for styles what we have now?

STYLE
    RANGEITEM "myAttr"
    COLORRANGE 255 0 0  0 255 0
    DATARANGE 0.0 1.0
END

I suppose it is not possible to give a third, interim value for COLORRANGE, nor to use Z (or M) coordinate value as RANGEITEM. Especially I have in my mind usecases for Z to visualize heights and depths, and M for speed or other measures.

-Jukka Rahkonen-
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mapserver-users/attachments/20190919/043defbc/attachment.htm>

From Panagiotis.KAVALAGIOS at ext.eeas.europa.eu  Fri Sep 27 02:41:37 2019
From: Panagiotis.KAVALAGIOS at ext.eeas.europa.eu (KAVALAGIOS Panagiotis (EEAS-EXT))
Date: Fri, 27 Sep 2019 09:41:37 +0000
Subject: [mapserver-users] Download Windows binaries of MapServer
Message-ID: <a4333b3667b747fc95ef80c8361ad9da@BELBRU-EXMP101.eeas.europa.eu>

Dear all,

We would like to investigate the usage of MapServer in a Proof of Concept. Where can I find the binaries? The download link to ms4w.com causes:

--------------
Network Error (tcp_error)

A communication error occurred: "Operation timed out"

The Web Server may be down, too busy, or experiencing other problems preventing it from responding to requests. You may wish to try again at a later time.


For assistance, contact your network support team

--------------

Is there any other mirror I could try?

Kind regards,

Panos Kavalagios

Application Architect
MTS4EEAS (under contract with the EEAS)
BA.BS.3.IS
_____________________________________
Office: EEAS B100 Floor 5 Area F5/048
Rue Belliard 100, 1000 Brussels
Phone: +32 2 584 6017
Panagiotis.KAVALAGIOS at ext.eeas.europa.eu<mailto:Panagiotis.KAVALAGIOS at ext.eeas.europa.eu>
[cid:image002.jpg at 01D4EAFA.CCC51A60]

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mapserver-users/attachments/20190927/2e1190c6/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 11303 bytes
Desc: image001.jpg
URL: <http://lists.osgeo.org/pipermail/mapserver-users/attachments/20190927/2e1190c6/attachment.jpg>

From schroeter at netgis.de  Fri Sep 27 03:27:57 2019
From: schroeter at netgis.de (Sven Schroeter)
Date: Fri, 27 Sep 2019 12:27:57 +0200
Subject: [mapserver-users] Download Windows binaries of MapServer
In-Reply-To: <a4333b3667b747fc95ef80c8361ad9da@BELBRU-EXMP101.eeas.europa.eu>
References: <a4333b3667b747fc95ef80c8361ad9da@BELBRU-EXMP101.eeas.europa.eu>
Message-ID: <93cfc554-6622-3736-27d4-2387a7722143@netgis.de>

Hello,
I don't think the ms4w page is available right now. If you need Windows 
binaries, you can also download the version of gisinternals:
https://www.gisinternals.com/release.php
You can quickly download the latest version of ms4w 4.01 here, I just 
put it on our server: https://netgis.de/download/ms4w_4.0.1.zip

Greetings
Sven



Mit freundlichen Gr??en

Sven Schr?ter

**************************************
NETGIS GbR
Benediktinerstr. 32a
54292 Trier
Tel.: 0651-1704731
Fax: 0651-1704733
schroeter at netgis.de
www.netgis.de


Am 27.09.2019 um 11:41 schrieb KAVALAGIOS Panagiotis (EEAS-EXT):
>
> Dear all,
>
> We would like to investigate the usage of MapServer in a Proof of 
> Concept. Where can I find the binaries? The download link to ms4w.com 
> causes:
>
> --------------
>
> Network Error (tcp_error)
>
> A communication error occurred: "Operation timed out"
>
> The Web Server may be down, too busy, or experiencing other problems 
> preventing it from responding to requests. You may wish to try again 
> at a later time.
>
>
> For assistance, contact your network support team
>
> --------------
>
> Is there any other mirror I could try?
>
> Kind regards,
>
> *Panos Kavalagios*
>
> *
> *Application Architect
>
> MTS4EEAS (under contract with the EEAS)
>
> *BA.BS.3.IS*
>
> _____________________________________
>
> Office: EEAS B100 Floor 5 Area F5/048
>
> Rue Belliard 100, 1000 Brussels**
>
> Phone: +32 2 584 6017
>
> Panagiotis.KAVALAGIOS at ext.eeas.europa.eu 
> <mailto:Panagiotis.KAVALAGIOS at ext.eeas.europa.eu>
>
> *cid:image002.jpg at 01D4EAFA.CCC51A60***
>
>
> _______________________________________________
> mapserver-users mailing list
> mapserver-users at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/mapserver-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mapserver-users/attachments/20190927/56b8ade7/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 11303 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/mapserver-users/attachments/20190927/56b8ade7/attachment.jpg>

From jmckenna at gatewaygeomatics.com  Fri Sep 27 07:33:08 2019
From: jmckenna at gatewaygeomatics.com (Jeff McKenna)
Date: Fri, 27 Sep 2019 11:33:08 -0300
Subject: [mapserver-users] Download Windows binaries of MapServer
In-Reply-To: <a4333b3667b747fc95ef80c8361ad9da@BELBRU-EXMP101.eeas.europa.eu>
References: <a4333b3667b747fc95ef80c8361ad9da@BELBRU-EXMP101.eeas.europa.eu>
Message-ID: <ae680c0f-9e1a-5e4c-395a-3203c2d2e294@gatewaygeomatics.com>

Thanks for reporting this, the ms4w.com server has been fixed :)

You can also report this directly through the MS4W forum (which is not 
on that same server): subscribe at 
https://lists.ms4w.com/mailman/listinfo/ms4w-users

-jeff



On 2019-09-27 6:41 AM, KAVALAGIOS Panagiotis (EEAS-EXT) wrote:
> Dear all,
> 
> We would like to investigate the usage of MapServer in a Proof of 
> Concept. Where can I find the binaries? The download link to ms4w.com 
> causes:
> 
> --------------
> 
> Network Error (tcp_error)
> 
> A communication error occurred: "Operation timed out"
> 
> The Web Server may be down, too busy, or experiencing other problems 
> preventing it from responding to requests. You may wish to try again at 
> a later time.
> 
> 
> For assistance, contact your network support team
> 
> --------------
> 
> Is there any other mirror I could try?
> 
> Kind regards,
> 
> *Panos Kavalagios*
> 
> *
> *Application Architect
> 
> MTS4EEAS (under contract with the EEAS)
> 
> *BA.BS.3.IS*
> 
> _____________________________________
> 
> Office: EEAS B100 Floor 5 Area F5/048
> 
> Rue Belliard 100, 1000 Brussels**
> 
> Phone: +32 2 584 6017
> 
> Panagiotis.KAVALAGIOS at ext.eeas.europa.eu 
> <mailto:Panagiotis.KAVALAGIOS at ext.eeas.europa.eu>
> 
> *cid:image002.jpg at 01D4EAFA.CCC51A60***
> 
> 
> _______________________________________________
> mapserver-users mailing list
> mapserver-users at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/mapserver-users
> 


-- 
Jeff McKenna
MapServer Consulting and Training Services
https://gatewaygeomatics.com/


From jmckenna at gatewaygeomatics.com  Fri Sep 27 07:36:14 2019
From: jmckenna at gatewaygeomatics.com (Jeff McKenna)
Date: Fri, 27 Sep 2019 11:36:14 -0300
Subject: [mapserver-users] Download Windows binaries of MapServer
In-Reply-To: <ae680c0f-9e1a-5e4c-395a-3203c2d2e294@gatewaygeomatics.com>
References: <a4333b3667b747fc95ef80c8361ad9da@BELBRU-EXMP101.eeas.europa.eu>
 <ae680c0f-9e1a-5e4c-395a-3203c2d2e294@gatewaygeomatics.com>
Message-ID: <e35c68fb-d2ee-c396-597b-269f4520a217@gatewaygeomatics.com>

PS. the ms4w.com server now gets ~6000 downloads per month, and now 
almost 2TB in data (mapfiles, data, applications) are downloaded per 
month.....so it is heavily used by the Windows community.  -jeff

--

Thank you for using MS4W.
"MS4W: open doors as well as windows"




On 2019-09-27 11:33 AM, Jeff McKenna wrote:
> Thanks for reporting this, the ms4w.com server has been fixed :)
> 
> You can also report this directly through the MS4W forum (which is not 
> on that same server): subscribe at 
> https://lists.ms4w.com/mailman/listinfo/ms4w-users
> 
> -jeff
> 
> 
> 
> On 2019-09-27 6:41 AM, KAVALAGIOS Panagiotis (EEAS-EXT) wrote:
>> Dear all,
>>
>> We would like to investigate the usage of MapServer in a Proof of 
>> Concept. Where can I find the binaries? The download link to ms4w.com 
>> causes:
>>
>> --------------
>>
>> Network Error (tcp_error)
>>
>> A communication error occurred: "Operation timed out"
>>
>> The Web Server may be down, too busy, or experiencing other problems 
>> preventing it from responding to requests. You may wish to try again 
>> at a later time.
>>
>>
>> For assistance, contact your network support team
>>
>> --------------
>>
>> Is there any other mirror I could try?
>>
>> Kind regards,
>>
>> *Panos Kavalagios*
>>
>> *
>> *Application Architect
>>
>> MTS4EEAS (under contract with the EEAS)
>>
>> *BA.BS.3.IS*
>>
>> _____________________________________
>>
>> Office: EEAS B100 Floor 5 Area F5/048
>>
>> Rue Belliard 100, 1000 Brussels**
>>
>> Phone: +32 2 584 6017
>>
>> Panagiotis.KAVALAGIOS at ext.eeas.europa.eu 
>> <mailto:Panagiotis.KAVALAGIOS at ext.eeas.europa.eu>
>>
>> *cid:image002.jpg at 01D4EAFA.CCC51A60***
>>
>>
>> _______________________________________________
>> mapserver-users mailing list
>> mapserver-users at lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/mapserver-users
>>
> 
> 


-- 
Jeff McKenna
MapServer Consulting and Training Services
https://gatewaygeomatics.com/


From acowie at gmail.com  Sun Sep 29 23:35:14 2019
From: acowie at gmail.com (AndyC79)
Date: Sun, 29 Sep 2019 23:35:14 -0700 (MST)
Subject: [mapserver-users] mapcache_seed - bdb cache failure
Message-ID: <1569825314581-0.post@n6.nabble.com>

Hello all,

Hope someone can help.

We're hitting a problem using mapcache 1.8.0 (issue has existed before that
version however).

When using Berkley DB backend, errors are appearing when trying to use
multiple threads. Errors are not consistent when running exact same seed
process across different hardware.

For example, using -n 4 with mapcache_seed

Brings errors such as the below:

BDB0126 mmap: Invalid argument
failed to seed tile z3,x8,y8:
bdb cache failure for env->open: Invalid argument
aborting seed as 20.0% of the last 1000 requests failed

Same seed process was run across different hardware, all OS: Ubuntu Server
16.04.6

** A virtual box VM on a Macbook pro - doesn't run in to these errors.

** A well resourced AWS EC2 instance - occasionally hits these errors.

** A Cray CS400 cluster, Intel Xeon Broadwell nodes seems to hit these
errors every time.

The tile it fails on is not consistent, when run seed process is run again.

If anyone has any bright ideas as to where to look next or how to fix that'd
be great.

Cheers



--
Sent from: http://osgeo-org.1560.x6.nabble.com/Mapserver-User-f4226646.html


From aperi2007 at gmail.com  Mon Sep 30 05:14:57 2019
From: aperi2007 at gmail.com (Andrea Peri)
Date: Mon, 30 Sep 2019 14:14:57 +0200
Subject: [mapserver-users] Lost the transparency after a SO Update
Message-ID: <CABqTJk_AmoRcDLg7moJ_4fPicytvRntFe3WhC1N8gk+K3EpowA@mail.gmail.com>

Hi,

After update the Linux Debian to last Burst version , and recompile gdal
and mapserver, I see the mapserver was no more capable to produce png
images with transparency.

I guess there is some library wrong.
I try also to set gdal to recmpile using the internal version of png but
don't seem to have any result.

Any help is welcome.

Thx,

-
-----------------
Andrea Peri
. . . . . . . . .
qwerty ?????
-----------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mapserver-users/attachments/20190930/b9d4eae7/attachment.htm>

From aperi2007 at gmail.com  Mon Sep 30 05:49:37 2019
From: aperi2007 at gmail.com (Andrea Peri)
Date: Mon, 30 Sep 2019 14:49:37 +0200
Subject: [mapserver-users] Lost the transparency after a SO Update
In-Reply-To: <CABqTJk_AmoRcDLg7moJ_4fPicytvRntFe3WhC1N8gk+K3EpowA@mail.gmail.com>
References: <CABqTJk_AmoRcDLg7moJ_4fPicytvRntFe3WhC1N8gk+K3EpowA@mail.gmail.com>
Message-ID: <CABqTJk-zkpwuu7nrj_2mqYH4uPYXn8+wVCzWE1oJEiianLM6AA@mail.gmail.com>

Hi,

seem the issue is due to a more recent trunk of mapserver.
I try with an older trunk version and it work . The transparency is ok.

So the issue is in the last trunk.

A.


Il giorno lun 30 set 2019 alle ore 14:14 Andrea Peri <aperi2007 at gmail.com>
ha scritto:

> Hi,
>
> After update the Linux Debian to last Burst version , and recompile gdal
> and mapserver, I see the mapserver was no more capable to produce png
> images with transparency.
>
> I guess there is some library wrong.
> I try also to set gdal to recmpile using the internal version of png but
> don't seem to have any result.
>
> Any help is welcome.
>
> Thx,
>
> -
> -----------------
> Andrea Peri
> . . . . . . . . .
> qwerty ?????
> -----------------
>


-- 
-----------------
Andrea Peri
. . . . . . . . .
qwerty ?????
-----------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mapserver-users/attachments/20190930/de642d7f/attachment.htm>

From sethg at geographika.co.uk  Mon Sep 30 06:30:38 2019
From: sethg at geographika.co.uk (Seth G)
Date: Mon, 30 Sep 2019 15:30:38 +0200
Subject: [mapserver-users] Lost the transparency after a SO Update
In-Reply-To: <CABqTJk-zkpwuu7nrj_2mqYH4uPYXn8+wVCzWE1oJEiianLM6AA@mail.gmail.com>
References: <CABqTJk_AmoRcDLg7moJ_4fPicytvRntFe3WhC1N8gk+K3EpowA@mail.gmail.com>
 <CABqTJk-zkpwuu7nrj_2mqYH4uPYXn8+wVCzWE1oJEiianLM6AA@mail.gmail.com>
Message-ID: <bbbfa749-4b7d-4ea0-9355-7e8e22abc8ff@www.fastmail.com>

Hi Andrea,

Do you have a cut-down Mapfile to reproduce this?
Are you using the COMPOSITE block to set OPACITY?
https://mapserver.org/mapfile/composite.html#parameters
Setting OPACITY on the layer directly is deprecated since 7.0

Seth

--
web:http://geographika.co.uk
twitter: @geographika


On Mon, Sep 30, 2019, at 2:49 PM, Andrea Peri wrote:
> Hi,
> 
> seem the issue is due to a more recent trunk of mapserver.
> I try with an older trunk version and it work . The transparency is ok.
> 
> So the issue is in the last trunk.
> 
> A.
> 
> 
> Il giorno lun 30 set 2019 alle ore 14:14 Andrea Peri <aperi2007 at gmail.com> ha scritto:
>> Hi,
>> 
>> After update the Linux Debian to last Burst version , and recompile gdal and mapserver, I see the mapserver was no more capable to produce png images with transparency.
>> 
>> I guess there is some library wrong. 
>> I try also to set gdal to recmpile using the internal version of png but don't seem to have any result.
>> 
>> Any help is welcome.
>> 
>> Thx,
>> 
>> -
>> -----------------
>> Andrea Peri
>> . . . . . . . . . 
>> qwerty ?????
>> -----------------
> 
> 
> -- 
> -----------------
> Andrea Peri
> . . . . . . . . . 
> qwerty ?????
> -----------------
> _______________________________________________
> mapserver-users mailing list
> mapserver-users at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/mapserver-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mapserver-users/attachments/20190930/45d18dee/attachment.htm>

From aperi2007 at gmail.com  Mon Sep 30 07:56:01 2019
From: aperi2007 at gmail.com (Andrea Peri)
Date: Mon, 30 Sep 2019 16:56:01 +0200
Subject: [mapserver-users] Lost the transparency after a SO Update
In-Reply-To: <bbbfa749-4b7d-4ea0-9355-7e8e22abc8ff@www.fastmail.com>
References: <CABqTJk_AmoRcDLg7moJ_4fPicytvRntFe3WhC1N8gk+K3EpowA@mail.gmail.com>
 <CABqTJk-zkpwuu7nrj_2mqYH4uPYXn8+wVCzWE1oJEiianLM6AA@mail.gmail.com>
 <bbbfa749-4b7d-4ea0-9355-7e8e22abc8ff@www.fastmail.com>
Message-ID: <CABqTJk9R5SkixUnq-OHGWF8CEQpUhE4edsu-PLjtC6_pZVfG_g@mail.gmail.com>

Hi,

this is the class I use

The transparenc is used if RGBA hex.
        COLOR "#e1cc4f7f"

    CLASS
      NAME ' '
      GROUP 'avorio'
      MAXSCALEDENOM 5000000
      MINSCALEDENOM 1
      STYLE
        COLOR "#e1cc4f7f"
        ANTIALIAS false
        MAXSCALEDENOM 5000000
        MINSCALEDENOM 1
      END
      STYLE
        WIDTH 2.0
        OUTLINECOLOR "#e1cc4f"
        ANTIALIAS false
        MAXSCALEDENOM 5000000
        MINSCALEDENOM 1
      END
    END


Il giorno lun 30 set 2019 alle ore 15:31 Seth G <sethg at geographika.co.uk>
ha scritto:

> Hi Andrea,
>
> Do you have a cut-down Mapfile to reproduce this?
> Are you using the COMPOSITE block to set OPACITY?
> https://mapserver.org/mapfile/composite.html#parameters
> Setting OPACITY on the layer directly is deprecated since 7.0
>
> Seth
>
> --
> web:http://geographika.co.uk
> twitter: @geographika
>
>
> On Mon, Sep 30, 2019, at 2:49 PM, Andrea Peri wrote:
>
> Hi,
>
> seem the issue is due to a more recent trunk of mapserver.
> I try with an older trunk version and it work . The transparency is ok.
>
> So the issue is in the last trunk.
>
> A.
>
>
> Il giorno lun 30 set 2019 alle ore 14:14 Andrea Peri <aperi2007 at gmail.com>
> ha scritto:
>
> Hi,
>
> After update the Linux Debian to last Burst version , and recompile gdal
> and mapserver, I see the mapserver was no more capable to produce png
> images with transparency.
>
> I guess there is some library wrong.
> I try also to set gdal to recmpile using the internal version of png but
> don't seem to have any result.
>
> Any help is welcome.
>
> Thx,
>
> -
> -----------------
> Andrea Peri
> . . . . . . . . .
> qwerty ?????
> -----------------
>
>
>
> --
> -----------------
> Andrea Peri
> . . . . . . . . .
> qwerty ?????
> -----------------
> _______________________________________________
> mapserver-users mailing list
> mapserver-users at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/mapserver-users
>
>
>

-- 
-----------------
Andrea Peri
. . . . . . . . .
qwerty ?????
-----------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mapserver-users/attachments/20190930/66b4abfc/attachment.htm>

From sethg at geographika.co.uk  Mon Sep 30 08:26:08 2019
From: sethg at geographika.co.uk (Seth G)
Date: Mon, 30 Sep 2019 17:26:08 +0200
Subject: [mapserver-users] Lost the transparency after a SO Update
In-Reply-To: <CABqTJk9R5SkixUnq-OHGWF8CEQpUhE4edsu-PLjtC6_pZVfG_g@mail.gmail.com>
References: <CABqTJk_AmoRcDLg7moJ_4fPicytvRntFe3WhC1N8gk+K3EpowA@mail.gmail.com>
 <CABqTJk-zkpwuu7nrj_2mqYH4uPYXn8+wVCzWE1oJEiianLM6AA@mail.gmail.com>
 <bbbfa749-4b7d-4ea0-9355-7e8e22abc8ff@www.fastmail.com>
 <CABqTJk9R5SkixUnq-OHGWF8CEQpUhE4edsu-PLjtC6_pZVfG_g@mail.gmail.com>
Message-ID: <71b5f12f-9fb0-42b0-9fec-5423906bcbc8@www.fastmail.com>

Actually that does remind me of a recent issue I had when updating from 7.2 to 7.4. I have the following diff:

 STYLE
 # add an almost fully translucent colour
 # setting the aa value to 00 in the rrggbbaa setting causes any masked layers to no
 # longer display
 COLOR "#FFFFFF01"
 END

The above no longer worked and I updated to:

 STYLE
 # add an almost fully translucent colour - if no colour then no MASK
 COLOR "#ffffff"
 OPACITY 1
 END


--
web:http://geographika.co.uk
twitter: @geographika


On Mon, Sep 30, 2019, at 4:56 PM, Andrea Peri wrote:
> Hi,
> 
> this is the class I use
> 
> The transparenc is used if RGBA hex.
>  COLOR "#e1cc4f7f"
> 
>  CLASS
>  NAME ' '
>  GROUP 'avorio'
>  MAXSCALEDENOM 5000000
>  MINSCALEDENOM 1
>  STYLE
>  COLOR "#e1cc4f7f"
>  ANTIALIAS false
>  MAXSCALEDENOM 5000000
>  MINSCALEDENOM 1
>  END
>  STYLE
>  WIDTH 2.0
>  OUTLINECOLOR "#e1cc4f"
>  ANTIALIAS false
>  MAXSCALEDENOM 5000000
>  MINSCALEDENOM 1
>  END
>  END
> 
> 
> Il giorno lun 30 set 2019 alle ore 15:31 Seth G <sethg at geographika.co.uk> ha scritto:
>> __
>> Hi Andrea,
>> 
>> Do you have a cut-down Mapfile to reproduce this?
>> Are you using the COMPOSITE block to set OPACITY?
>> https://mapserver.org/mapfile/composite.html#parameters
>> Setting OPACITY on the layer directly is deprecated since 7.0
>> 
>> Seth
>> 
>> --
>> web:http://geographika.co.uk
>> twitter: @geographika
>> 
>> 
>> On Mon, Sep 30, 2019, at 2:49 PM, Andrea Peri wrote:
>>> Hi,
>>> 
>>> seem the issue is due to a more recent trunk of mapserver.
>>> I try with an older trunk version and it work . The transparency is ok.
>>> 
>>> So the issue is in the last trunk.
>>> 
>>> A.
>>> 
>>> 
>>> Il giorno lun 30 set 2019 alle ore 14:14 Andrea Peri <aperi2007 at gmail.com> ha scritto:
>>>> Hi,
>>>> 
>>>> After update the Linux Debian to last Burst version , and recompile gdal and mapserver, I see the mapserver was no more capable to produce png images with transparency.
>>>> 
>>>> I guess there is some library wrong. 
>>>> I try also to set gdal to recmpile using the internal version of png but don't seem to have any result.
>>>> 
>>>> Any help is welcome.
>>>> 
>>>> Thx,
>>>> 
>>>> -
>>>> -----------------
>>>> Andrea Peri
>>>> . . . . . . . . . 
>>>> qwerty ?????
>>>> -----------------
>>> 
>>> 
>>> -- 
>>> -----------------
>>> Andrea Peri
>>> . . . . . . . . . 
>>> qwerty ?????
>>> -----------------
>>> _______________________________________________
>>> mapserver-users mailing list
>>> mapserver-users at lists.osgeo.org
>>> https://lists.osgeo.org/mailman/listinfo/mapserver-users
>> 
> 
> 
> -- 
> -----------------
> Andrea Peri
> . . . . . . . . . 
> qwerty ?????
> -----------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mapserver-users/attachments/20190930/9fb0a06e/attachment.htm>

From aperi2007 at gmail.com  Mon Sep 30 08:36:30 2019
From: aperi2007 at gmail.com (Andrea Peri)
Date: Mon, 30 Sep 2019 17:36:30 +0200
Subject: [mapserver-users] Lost the transparency after a SO Update
In-Reply-To: <71b5f12f-9fb0-42b0-9fec-5423906bcbc8@www.fastmail.com>
References: <CABqTJk_AmoRcDLg7moJ_4fPicytvRntFe3WhC1N8gk+K3EpowA@mail.gmail.com>
 <CABqTJk-zkpwuu7nrj_2mqYH4uPYXn8+wVCzWE1oJEiianLM6AA@mail.gmail.com>
 <bbbfa749-4b7d-4ea0-9355-7e8e22abc8ff@www.fastmail.com>
 <CABqTJk9R5SkixUnq-OHGWF8CEQpUhE4edsu-PLjtC6_pZVfG_g@mail.gmail.com>
 <71b5f12f-9fb0-42b0-9fec-5423906bcbc8@www.fastmail.com>
Message-ID: <CABqTJk8iMvGpYgRmcMtcsU9EeXVD5GqMEnMp_5DtZ5q0Jshocw@mail.gmail.com>

The "#ffffff01" sintax was dismissed ?

The 7.4.2 docs don't report this.


------ from https://www.mapserver.org/mapfile/style.html
-

RGBA value (adding translucence): ?#rrggbbaa?. To specify a
semi-translucent magenta, the following is used:

COLOR "#FF00FFCC"

-------

I try this sintax with OPACITY.

Thx,
A.


Il giorno lun 30 set 2019 alle ore 17:26 Seth G <sethg at geographika.co.uk>
ha scritto:

> Actually that does remind me of a recent issue I had when updating from
> 7.2 to 7.4. I have the following diff:
>
>         STYLE
>             # add an almost fully translucent colour
>             # setting the aa value to 00 in the rrggbbaa setting causes
> any masked layers to no
>             # longer display
>             COLOR "#FFFFFF01"
>         END
>
> The above no longer worked and I updated to:
>
>         STYLE
>             # add an almost fully translucent colour - if no colour then
> no MASK
>             COLOR "#ffffff"
>             OPACITY 1
>         END
>
>
> --
> web:http://geographika.co.uk
> twitter: @geographika
>
>
> On Mon, Sep 30, 2019, at 4:56 PM, Andrea Peri wrote:
>
> Hi,
>
> this is the class I use
>
> The transparenc is used if RGBA hex.
>         COLOR "#e1cc4f7f"
>
>     CLASS
>       NAME ' '
>       GROUP 'avorio'
>       MAXSCALEDENOM 5000000
>       MINSCALEDENOM 1
>       STYLE
>         COLOR "#e1cc4f7f"
>         ANTIALIAS false
>         MAXSCALEDENOM 5000000
>         MINSCALEDENOM 1
>       END
>       STYLE
>         WIDTH 2.0
>         OUTLINECOLOR "#e1cc4f"
>         ANTIALIAS false
>         MAXSCALEDENOM 5000000
>         MINSCALEDENOM 1
>       END
>     END
>
>
> Il giorno lun 30 set 2019 alle ore 15:31 Seth G <sethg at geographika.co.uk>
> ha scritto:
>
>
> Hi Andrea,
>
> Do you have a cut-down Mapfile to reproduce this?
> Are you using the COMPOSITE block to set OPACITY?
> https://mapserver.org/mapfile/composite.html#parameters
> Setting OPACITY on the layer directly is deprecated since 7.0
>
> Seth
>
> --
> web:http://geographika.co.uk
> twitter: @geographika
>
>
> On Mon, Sep 30, 2019, at 2:49 PM, Andrea Peri wrote:
>
> Hi,
>
> seem the issue is due to a more recent trunk of mapserver.
> I try with an older trunk version and it work . The transparency is ok.
>
> So the issue is in the last trunk.
>
> A.
>
>
> Il giorno lun 30 set 2019 alle ore 14:14 Andrea Peri <aperi2007 at gmail.com>
> ha scritto:
>
> Hi,
>
> After update the Linux Debian to last Burst version , and recompile gdal
> and mapserver, I see the mapserver was no more capable to produce png
> images with transparency.
>
> I guess there is some library wrong.
> I try also to set gdal to recmpile using the internal version of png but
> don't seem to have any result.
>
> Any help is welcome.
>
> Thx,
>
> -
> -----------------
> Andrea Peri
> . . . . . . . . .
> qwerty ?????
> -----------------
>
>
>
> --
> -----------------
> Andrea Peri
> . . . . . . . . .
> qwerty ?????
> -----------------
> _______________________________________________
> mapserver-users mailing list
> mapserver-users at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/mapserver-users
>
>
>
>
> --
> -----------------
> Andrea Peri
> . . . . . . . . .
> qwerty ?????
> -----------------
>
>
>

-- 
-----------------
Andrea Peri
. . . . . . . . .
qwerty ?????
-----------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mapserver-users/attachments/20190930/4d2b4a54/attachment.htm>

From aperi2007 at gmail.com  Mon Sep 30 08:48:36 2019
From: aperi2007 at gmail.com (Andrea Peri)
Date: Mon, 30 Sep 2019 17:48:36 +0200
Subject: [mapserver-users] Lost the transparency after a SO Update
In-Reply-To: <CABqTJk8iMvGpYgRmcMtcsU9EeXVD5GqMEnMp_5DtZ5q0Jshocw@mail.gmail.com>
References: <CABqTJk_AmoRcDLg7moJ_4fPicytvRntFe3WhC1N8gk+K3EpowA@mail.gmail.com>
 <CABqTJk-zkpwuu7nrj_2mqYH4uPYXn8+wVCzWE1oJEiianLM6AA@mail.gmail.com>
 <bbbfa749-4b7d-4ea0-9355-7e8e22abc8ff@www.fastmail.com>
 <CABqTJk9R5SkixUnq-OHGWF8CEQpUhE4edsu-PLjtC6_pZVfG_g@mail.gmail.com>
 <71b5f12f-9fb0-42b0-9fec-5423906bcbc8@www.fastmail.com>
 <CABqTJk8iMvGpYgRmcMtcsU9EeXVD5GqMEnMp_5DtZ5q0Jshocw@mail.gmail.com>
Message-ID: <CABqTJk85G045bTg=Fvr09M4Tias-YEwjNWMNK5h=pypKcjZhVw@mail.gmail.com>

Hi Seth.
I confirm the sintax

      STYLE
        COLOR "#e1cc4f"
        OPACITY 50
        ANTIALIAS false
        MAXSCALEDENOM 5000000
        MINSCALEDENOM 1
      END


Is working.

The opacity is in percent (50 => 50%)


Il giorno lun 30 set 2019 alle ore 17:36 Andrea Peri <aperi2007 at gmail.com>
ha scritto:

> The "#ffffff01" sintax was dismissed ?
>
> The 7.4.2 docs don't report this.
>
>
> ------ from https://www.mapserver.org/mapfile/style.html
>
>    -
>
>    RGBA value (adding translucence): ?#rrggbbaa?. To specify a
>    semi-translucent magenta, the following is used:
>
>    COLOR "#FF00FFCC"
>
>
> -------
>
> I try this sintax with OPACITY.
>
> Thx,
> A.
>
>
> Il giorno lun 30 set 2019 alle ore 17:26 Seth G <sethg at geographika.co.uk>
> ha scritto:
>
>> Actually that does remind me of a recent issue I had when updating from
>> 7.2 to 7.4. I have the following diff:
>>
>>         STYLE
>>             # add an almost fully translucent colour
>>             # setting the aa value to 00 in the rrggbbaa setting causes
>> any masked layers to no
>>             # longer display
>>             COLOR "#FFFFFF01"
>>         END
>>
>> The above no longer worked and I updated to:
>>
>>         STYLE
>>             # add an almost fully translucent colour - if no colour then
>> no MASK
>>             COLOR "#ffffff"
>>             OPACITY 1
>>         END
>>
>>
>> --
>> web:http://geographika.co.uk
>> twitter: @geographika
>>
>>
>> On Mon, Sep 30, 2019, at 4:56 PM, Andrea Peri wrote:
>>
>> Hi,
>>
>> this is the class I use
>>
>> The transparenc is used if RGBA hex.
>>         COLOR "#e1cc4f7f"
>>
>>     CLASS
>>       NAME ' '
>>       GROUP 'avorio'
>>       MAXSCALEDENOM 5000000
>>       MINSCALEDENOM 1
>>       STYLE
>>         COLOR "#e1cc4f7f"
>>         ANTIALIAS false
>>         MAXSCALEDENOM 5000000
>>         MINSCALEDENOM 1
>>       END
>>       STYLE
>>         WIDTH 2.0
>>         OUTLINECOLOR "#e1cc4f"
>>         ANTIALIAS false
>>         MAXSCALEDENOM 5000000
>>         MINSCALEDENOM 1
>>       END
>>     END
>>
>>
>> Il giorno lun 30 set 2019 alle ore 15:31 Seth G <sethg at geographika.co.uk>
>> ha scritto:
>>
>>
>> Hi Andrea,
>>
>> Do you have a cut-down Mapfile to reproduce this?
>> Are you using the COMPOSITE block to set OPACITY?
>> https://mapserver.org/mapfile/composite.html#parameters
>> Setting OPACITY on the layer directly is deprecated since 7.0
>>
>> Seth
>>
>> --
>> web:http://geographika.co.uk
>> twitter: @geographika
>>
>>
>> On Mon, Sep 30, 2019, at 2:49 PM, Andrea Peri wrote:
>>
>> Hi,
>>
>> seem the issue is due to a more recent trunk of mapserver.
>> I try with an older trunk version and it work . The transparency is ok.
>>
>> So the issue is in the last trunk.
>>
>> A.
>>
>>
>> Il giorno lun 30 set 2019 alle ore 14:14 Andrea Peri <aperi2007 at gmail.com>
>> ha scritto:
>>
>> Hi,
>>
>> After update the Linux Debian to last Burst version , and recompile gdal
>> and mapserver, I see the mapserver was no more capable to produce png
>> images with transparency.
>>
>> I guess there is some library wrong.
>> I try also to set gdal to recmpile using the internal version of png but
>> don't seem to have any result.
>>
>> Any help is welcome.
>>
>> Thx,
>>
>> -
>> -----------------
>> Andrea Peri
>> . . . . . . . . .
>> qwerty ?????
>> -----------------
>>
>>
>>
>> --
>> -----------------
>> Andrea Peri
>> . . . . . . . . .
>> qwerty ?????
>> -----------------
>> _______________________________________________
>> mapserver-users mailing list
>> mapserver-users at lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/mapserver-users
>>
>>
>>
>>
>> --
>> -----------------
>> Andrea Peri
>> . . . . . . . . .
>> qwerty ?????
>> -----------------
>>
>>
>>
>
> --
> -----------------
> Andrea Peri
> . . . . . . . . .
> qwerty ?????
> -----------------
>


-- 
-----------------
Andrea Peri
. . . . . . . . .
qwerty ?????
-----------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mapserver-users/attachments/20190930/fda20b23/attachment.htm>