Re: [mapserver-users] DATA "table" does not find FID for WFS

[Rahkonen Jukka (MML)]

Hi,

I am testing with MS4W 3.1.0 and the GDAL that is included seems to be

C:\ms4w>gdalinfo --version
GDAL 2.0.0, released 2015/06/14

I believe that it should include #5781

-Jukka-

Even Rouault wrote:

Le mercredi 28 octobre 2015 08:10:44, Rahkonen Jukka (MML) a écrit :
> Hi,
> 
> I have noticed with Mapserver 7.0 that WFS server does not find the 
> "gml_featureid" column if I define DATA this way:
> 
> CONNECTIONTYPE OGR
> CONNECTION "\ms4w\apps\wms-wfs.sqlite"
> DATA "states"
> 
> This gives a warning into GML sent by GetFeature
> 
> and featureMembers are without fid
> 
> 
> 
> This leads to correct result:
> 
> CONNECTIONTYPE OGR
> CONNECTION "\ms4w\apps\wms-wfs.sqlite"
> DATA "select * from states"
> 
> 
> 
> 
> Documentation http://www.mapserver.org/input/vector/ogr.html does not 
> warn that defining data as "layer_name" vs. "select * from layer" 
> could make a difference. Ogrinfo finds the FID column and reports it 
> as: FID Column = PK_UID
> 
> PK_UID is defined in the table as
> CREATE TABLE states (
> PK_UID INTEGER PRIMARY KEY AUTOINCREMENT,
> 
> 
> This looks like a bug but I am not sure if it is a Mapserver bug of 
> GDAL bug and if it affects only Spatialite.

You didn't specify which GDAL version is used.

That could possibly be the following bug that was fixed in 1.11.2 and 2.0:
 * make GetFIDColumn() work when run as first method call (#5781)


> 
> -Jukka Rahkonen-

--
Spatialys - Geospatial professional services http://www.spatialys.com
___
mapserver-users mailing list
mapserver-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-users

Re: [mapserver-users] DATA "table" does not find FID for WFS

[Even Rouault]

Le mercredi 28 octobre 2015 13:24:28, Rahkonen Jukka (MML) a écrit :
> Hi,
> 
> > The GML output tries to find a item/field with the name of the
> > gml_featureid. But the FID column in OGR is treated specially and not
> > reported as a regular field.
> 
> I guess that it means that the issue does not affect only Spatialite, and
> the resolution would be to make GML output to try if it finds the
> "gml_featureid" field from the regular fields _OR_ from the field that is
> reported by OGR as "FID Column".

The GML output module cannot get this information back from the OGR provider. 
The OGR provider would rather have to expose the FID column as a regular item, 
when there's a named FID column. And when there's not, for example the OGR 
Shapefile has no FID column. possibly a generic name like 'FID' (which is the 
special name for the implicit FID column in OGR SQL) could be used to please 
MapServer.

> 
> The latter could be tried also if "gml_featureid" is missing from the
> mapfile or if it was set to " gml_featureid" "AUTO". I am not sure if this
> is a good idea or not because the native vector drivers should be adapted
> as well.

Looking at the postgis provider, it exposes all fields, excluding the geometry 
field, but including the primary key column as regular fields.

> 
> Should I file a Mapserver issue into Github about FID Columns getting
> hidden?

Possibly. There are also perhaps documentation advice with the workarounds I 
suggested.

> 
> -Jukka-
> 
> Even Rouault wrote:
> 
> Le mercredi 28 octobre 2015 12:12:55, Rahkonen Jukka (MML) a écrit :
> > Hi,
> > 
> > I am testing with MS4W 3.1.0 and the GDAL that is included seems to be
> > 
> > C:\ms4w>gdalinfo --version
> > GDAL 2.0.0, released 2015/06/14
> > 
> > I believe that it should include #5781
> 
> Yes, but that is irrelevant to your issue when looking closer.
> 
> The GML output tries to find a item/field with the name of the
> gml_featureid. But the FID column in OGR is treated specially and not
> reported as a regular field. Which explains the error. In the case of
> "select * from table_name" as pk_uid is different from ogc_fid then it is
> just recognized as a regular column, which makes things work. So even
> "select * from table_name" isn't a guarantee that things are going to
> work. If the primary key field was named ogc_fid, you'd have to do "select
> ogc_fid as pk_uid, * from table_name" so it appears as a regular OGR
> field.
> 
> > -Jukka-
> > 
> > Even Rouault wrote:
> > 
> > Le mercredi 28 octobre 2015 08:10:44, Rahkonen Jukka (MML) a écrit :
> > > Hi,
> > > 
> > > I have noticed with Mapserver 7.0 that WFS server does not find the
> > > "gml_featureid" column if I define DATA this way:
> > > 
> > > CONNECTIONTYPE OGR
> > > CONNECTION "\ms4w\apps\wms-wfs.sqlite"
> > > DATA "states"
> > > 
> > > This gives a warning into GML sent by GetFeature
> > >  and featureMembers are without fid
> > >  
> > > 
> > > This leads to correct result:
> > > 
> > > CONNECTIONTYPE OGR
> > > CONNECTION "\ms4w\apps\wms-wfs.sqlite"
> > > DATA "select * from states"
> > > 
> > > 
> > > 
> > > 
> > > Documentation http://www.mapserver.org/input/vector/ogr.html does
> > > not warn that defining data as "layer_name" vs. "select * from layer"
> > > could make a difference. Ogrinfo finds the FID column and reports it
> > > as: FID Column = PK_UID
> > > 
> > > PK_UID is defined in the table as
> > > CREATE TABLE states (
> > > PK_UID INTEGER PRIMARY KEY AUTOINCREMENT,
> > > 
> > > 
> > > This looks like a bug but I am not sure if it is a Mapserver bug of
> > > GDAL bug and if it affects only Spatialite.
> > 
> > You didn't specify which GDAL version is used.
> > 
> > That could possibly be the following bug that was fixed in 1.11.2 and 2.0:
> >  * make GetFIDColumn() work when run as first method call (#5781)
> >  
> > > -Jukka Rahkonen-
> > 
> > --
> > Spatialys - Geospatial professional services http://www.spatialys.com
> 
> --
> Spatialys - Geospatial professional services http://www.spatialys.com

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
___
mapserver-users mailing list
mapserver-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-users

Re: [mapserver-users] DATA "table" does not find FID for WFS

[Even Rouault]

Le mercredi 28 octobre 2015 12:12:55, Rahkonen Jukka (MML) a écrit :
> Hi,
> 
> I am testing with MS4W 3.1.0 and the GDAL that is included seems to be
> 
> C:\ms4w>gdalinfo --version
> GDAL 2.0.0, released 2015/06/14
> 
> I believe that it should include #5781

Yes, but that is irrelevant to your issue when looking closer.

The GML output tries to find a item/field with the name of the gml_featureid. 
But the FID column in OGR is treated specially and not reported as a regular 
field. Which explains the error. In the case of "select * from table_name" as 
pk_uid is different from ogc_fid then it is just recognized as a regular 
column, 
which makes things work. So even "select * from table_name" isn't a guarantee 
that things are going to work. If the primary key field was named ogc_fid, 
you'd 
have to do "select ogc_fid as pk_uid, * from table_name" so it appears as a 
regular OGR field.

> 
> -Jukka-
> 
> Even Rouault wrote:
> 
> Le mercredi 28 octobre 2015 08:10:44, Rahkonen Jukka (MML) a écrit :
> > Hi,
> > 
> > I have noticed with Mapserver 7.0 that WFS server does not find the
> > "gml_featureid" column if I define DATA this way:
> > 
> > CONNECTIONTYPE OGR
> > CONNECTION "\ms4w\apps\wms-wfs.sqlite"
> > DATA "states"
> > 
> > This gives a warning into GML sent by GetFeature
> > 
> > and featureMembers are without fid
> > 
> > 
> > 
> > This leads to correct result:
> > 
> > CONNECTIONTYPE OGR
> > CONNECTION "\ms4w\apps\wms-wfs.sqlite"
> > DATA "select * from states"
> > 
> > 
> > 
> > 
> > Documentation http://www.mapserver.org/input/vector/ogr.html does not
> > warn that defining data as "layer_name" vs. "select * from layer"
> > could make a difference. Ogrinfo finds the FID column and reports it
> > as: FID Column = PK_UID
> > 
> > PK_UID is defined in the table as
> > CREATE TABLE states (
> > PK_UID INTEGER PRIMARY KEY AUTOINCREMENT,
> > 
> > 
> > This looks like a bug but I am not sure if it is a Mapserver bug of
> > GDAL bug and if it affects only Spatialite.
> 
> You didn't specify which GDAL version is used.
> 
> That could possibly be the following bug that was fixed in 1.11.2 and 2.0:
>  * make GetFIDColumn() work when run as first method call (#5781)
> 
> > -Jukka Rahkonen-
> 
> --
> Spatialys - Geospatial professional services http://www.spatialys.com

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
___
mapserver-users mailing list
mapserver-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-users

Re: [mapserver-users] DATA "table" does not find FID for WFS

[Rahkonen Jukka (MML)]

Hi,

> The GML output tries to find a item/field with the name of the gml_featureid. 
> But the FID column in OGR is treated specially and not reported as a regular 
> field.

I guess that it means that the issue does not affect only Spatialite, and the 
resolution would be to make GML output to try if it finds the "gml_featureid" 
field from the regular fields _OR_ from the field that is reported by OGR as 
"FID Column".

The latter could be tried also if "gml_featureid" is missing from the mapfile 
or if it was set to " gml_featureid" "AUTO". I am not sure if this is a good 
idea or not because the native vector drivers should be adapted as well. 

Should I file a Mapserver issue into Github about FID Columns getting hidden?

-Jukka-

Even Rouault wrote:

Le mercredi 28 octobre 2015 12:12:55, Rahkonen Jukka (MML) a écrit :
> Hi,
> 
> I am testing with MS4W 3.1.0 and the GDAL that is included seems to be
> 
> C:\ms4w>gdalinfo --version
> GDAL 2.0.0, released 2015/06/14
> 
> I believe that it should include #5781

Yes, but that is irrelevant to your issue when looking closer.

The GML output tries to find a item/field with the name of the gml_featureid. 
But the FID column in OGR is treated specially and not reported as a regular 
field. Which explains the error. In the case of "select * from table_name" as 
pk_uid is different from ogc_fid then it is just recognized as a regular 
column, which makes things work. So even "select * from table_name" isn't a 
guarantee that things are going to work. If the primary key field was named 
ogc_fid, you'd have to do "select ogc_fid as pk_uid, * from table_name" so it 
appears as a regular OGR field.

> 
> -Jukka-
> 
> Even Rouault wrote:
> 
> Le mercredi 28 octobre 2015 08:10:44, Rahkonen Jukka (MML) a écrit :
> > Hi,
> > 
> > I have noticed with Mapserver 7.0 that WFS server does not find the 
> > "gml_featureid" column if I define DATA this way:
> > 
> > CONNECTIONTYPE OGR
> > CONNECTION "\ms4w\apps\wms-wfs.sqlite"
> > DATA "states"
> > 
> > This gives a warning into GML sent by GetFeature
> >  and featureMembers are without fid 
> >  
> > 
> > This leads to correct result:
> > 
> > CONNECTIONTYPE OGR
> > CONNECTION "\ms4w\apps\wms-wfs.sqlite"
> > DATA "select * from states"
> > 
> > 
> > 
> > 
> > Documentation http://www.mapserver.org/input/vector/ogr.html does 
> > not warn that defining data as "layer_name" vs. "select * from layer"
> > could make a difference. Ogrinfo finds the FID column and reports it
> > as: FID Column = PK_UID
> > 
> > PK_UID is defined in the table as
> > CREATE TABLE states (
> > PK_UID INTEGER PRIMARY KEY AUTOINCREMENT,
> > 
> > 
> > This looks like a bug but I am not sure if it is a Mapserver bug of 
> > GDAL bug and if it affects only Spatialite.
> 
> You didn't specify which GDAL version is used.
> 
> That could possibly be the following bug that was fixed in 1.11.2 and 2.0:
>  * make GetFIDColumn() work when run as first method call (#5781)
> 
> > -Jukka Rahkonen-
> 
> --
> Spatialys - Geospatial professional services http://www.spatialys.com

--
Spatialys - Geospatial professional services http://www.spatialys.com
___
mapserver-users mailing list
mapserver-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-users

Re: [mapserver-users] MapCache: cache some zoom levels, proxy others?

[thomas bonfort]

Paul,

Are you using metatiling? That would substantially reduce the number
of requests mapcache does to mapserver.

You also have the

...
   true

option, that lets mapcache launch mapserver requests in parallel
instead of sequentially (YMMV, this option isn't very tested)

--
thomas

On 28 October 2015 at 16:20, Paul Madden  wrote:
> I am working with a web application that makes WMS queries to MapCache. The 
> application supports zoom levels 0 through 13, and I have used mapcache_seed 
> to seed the cache through level 10. The deeper levels take so long to seed 
> that I am considering stopping at level 10 and letting MapCache / MapServer 
> produce deeper levels on demand, as users visit them. The problem I'm facing 
> is that, as far as I can tell, MapCache requests tiles from MapServer 
> serially, then stitches together the required image from these tiles, when it 
> receives a request for an uncached level. In one test, 34 separate tiles were 
> requested from MapServer, one at a time, and it took ~30 seconds to render 
> the final image.
>
> I'm wondering whether there is a way to configure MapCache to cache/provide a 
> defined set of zoom levels, and to proxy requests at other zoom levels 
> directly to MapServer. I tried setting minzoom and maxzoom on my  in 
> mapcache.xml to "0 10". I tried adding a proxy for my cached layer, hoping 
> that MapCache would redirect requests for unsupported zoom levels to 
> MapServer (I have proxies in place for other, completely uncached layers, and 
> those work fine). I tried copying/renaming the GoogleMapsCompatible grid 
> definition into my mapcache.xml and removing from  zoom levels I 
> don't want MapCache to cache. So far, these attempts apparently just prevent 
> MapCache from serving the deeper layers at all.
>
> Any thoughts on how I might address this issue? It might also help if 
> MapCache would make concurrent requests for tiles at uncached levels, but I 
> have no idea if this is feasible. And it would be nice to be able to let 
> MapServer handle some zoom levels directly in any case.
>
> Thanks in advance for any ideas.
>
> Paul Madden
> National Snow and Ice Data Center
> ___
> mapserver-users mailing list
> mapserver-users@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapserver-users
___
mapserver-users mailing list
mapserver-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-users

[mapserver-users] DATA "table" does not find FID for WFS

[Rahkonen Jukka (MML)]

Hi,

I have noticed with Mapserver 7.0 that WFS server does not find the 
"gml_featureid" column if I define DATA this way:

CONNECTIONTYPE OGR
CONNECTION "\ms4w\apps\wms-wfs.sqlite"
DATA "states"

This gives a warning into GML sent by GetFeature

and featureMembers are without fid



This leads to correct result:

CONNECTIONTYPE OGR
CONNECTION "\ms4w\apps\wms-wfs.sqlite"
DATA "select * from states"




Documentation http://www.mapserver.org/input/vector/ogr.html does not warn that 
defining data as "layer_name" vs. "select * from layer" could make a 
difference. Ogrinfo finds the FID column and reports it as:
FID Column = PK_UID

PK_UID is defined in the table as
CREATE TABLE states (
PK_UID INTEGER PRIMARY KEY AUTOINCREMENT,


This looks like a bug but I am not sure if it is a Mapserver bug of GDAL bug 
and if it affects only Spatialite.

-Jukka Rahkonen-
___
mapserver-users mailing list
mapserver-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-users

Re: [mapserver-users] DATA "table" does not find FID for WFS

[Even Rouault]

Le mercredi 28 octobre 2015 08:10:44, Rahkonen Jukka (MML) a écrit :
> Hi,
> 
> I have noticed with Mapserver 7.0 that WFS server does not find the
> "gml_featureid" column if I define DATA this way:
> 
> CONNECTIONTYPE OGR
> CONNECTION "\ms4w\apps\wms-wfs.sqlite"
> DATA "states"
> 
> This gives a warning into GML sent by GetFeature
> 
> and featureMembers are without fid
> 
> 
> 
> This leads to correct result:
> 
> CONNECTIONTYPE OGR
> CONNECTION "\ms4w\apps\wms-wfs.sqlite"
> DATA "select * from states"
> 
> 
> 
> 
> Documentation http://www.mapserver.org/input/vector/ogr.html does not warn
> that defining data as "layer_name" vs. "select * from layer" could make a
> difference. Ogrinfo finds the FID column and reports it as: FID Column =
> PK_UID
> 
> PK_UID is defined in the table as
> CREATE TABLE states (
> PK_UID INTEGER PRIMARY KEY AUTOINCREMENT,
> 
> 
> This looks like a bug but I am not sure if it is a Mapserver bug of GDAL
> bug and if it affects only Spatialite.

You didn't specify which GDAL version is used.

That could possibly be the following bug that was fixed in 1.11.2 and 2.0:
 * make GetFIDColumn() work when run as first method call (#5781)


> 
> -Jukka Rahkonen-

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
___
mapserver-users mailing list
mapserver-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-users

[mapserver-users] Question about gml_types - auto and WFS

[Rahkonen Jukka (MML)]

Hi,

I can read from http://mapserver.org/ogc/wfs_server.html:

gml_types (Optional)
If this field is "auto" then some input feature drivers (ie. OGR, POSTGIS, 
ORACLESPATIAL and native shapefiles) will automatically populate the type, 
width and precision metadata for the layer based on the source file. Currently 
this is only used for OGR based output formats, not the WFS GML2/GML3 output.

What does "Currently this is only used for OGR based output formats, not the 
WFS GML2/GML3 output" mean? I can see that the GML schema is changing when I 
add "gml_types" "auto" to the mapfile. So what does not work with GML2/GML3 
output?

-Jukka Rahkonen-
___
mapserver-users mailing list
mapserver-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-users

Re: [mapserver-users] MapCache: cache some zoom levels, proxy others?

[Paul Madden]

Hi Thomas,

Thank you for reminding me about metatiling. I was initially using the 
MapServer v6.4 / MapCache v1.2 available with the version of Ubuntu I 
need to use, and disabled metatiling because of a (maybe) bug whereby, 
at some shallow zoom levels, some parts of my layer would fail to appear 
or display. I found that, by varying the  values, I could push 
the problem to different zoom levels, but I could not seem to eliminate 
it. When I turned metatiling off, this problem disappeared but I then 
saw, probably unsurprisingly, issues with truncated and overlapping 
labels at deep zoom levels. I then built the v7.0 / v1.4 releases from 
source and the problem disappeared. However, Apache would segfault in 
the MapCache module when I tried to use the "sqlite3" cache type ("disk" 
worked fine, but I have more tiles than inodes, so I cannot use it). 
Finally, I built the head of your git master and then "sqlite3" worked 
fine, too. (I can get you a stacktrace of the v1.4 segfault if you're 
interested -- but you seem already to have fixed whatever the underlying 
issue was).


Sorry for the long backstory -- maybe some of it will be useful to someone.

I will try using metatiling again, and will test  as 
well. Thanks!


Out of curiosity, can I assume that my other idea, about proxying some 
zoom levels directly to WMS and caching others, is unrealistic?


paul

On 10/28/15 9:36 AM, thomas bonfort wrote:

Paul,

Are you using metatiling? That would substantially reduce the number
of requests mapcache does to mapserver.

You also have the

...
true

option, that lets mapcache launch mapserver requests in parallel
instead of sequentially (YMMV, this option isn't very tested)

--
thomas

On 28 October 2015 at 16:20, Paul Madden  wrote:

I am working with a web application that makes WMS queries to MapCache. The 
application supports zoom levels 0 through 13, and I have used mapcache_seed to 
seed the cache through level 10. The deeper levels take so long to seed that I 
am considering stopping at level 10 and letting MapCache / MapServer produce 
deeper levels on demand, as users visit them. The problem I'm facing is that, 
as far as I can tell, MapCache requests tiles from MapServer serially, then 
stitches together the required image from these tiles, when it receives a 
request for an uncached level. In one test, 34 separate tiles were requested 
from MapServer, one at a time, and it took ~30 seconds to render the final 
image.

I'm wondering whether there is a way to configure MapCache to cache/provide a defined set of zoom 
levels, and to proxy requests at other zoom levels directly to MapServer. I tried setting minzoom and 
maxzoom on my  in mapcache.xml to "0 10". I tried adding a proxy for my cached 
layer, hoping that MapCache would redirect requests for unsupported zoom levels to MapServer (I have 
proxies in place for other, completely uncached layers, and those work fine). I tried 
copying/renaming the GoogleMapsCompatible grid definition into my mapcache.xml and removing from 
 zoom levels I don't want MapCache to cache. So far, these attempts apparently 
just prevent MapCache from serving the deeper layers at all.

Any thoughts on how I might address this issue? It might also help if MapCache 
would make concurrent requests for tiles at uncached levels, but I have no idea 
if this is feasible. And it would be nice to be able to let MapServer handle 
some zoom levels directly in any case.

Thanks in advance for any ideas.

Paul Madden
National Snow and Ice Data Center
___
mapserver-users mailing list
mapserver-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-users


___
mapserver-users mailing list
mapserver-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-users

Re: [mapserver-users] MapCache: cache some zoom levels, proxy others?

[thomas bonfort]

> Out of curiosity, can I assume that my other idea, about proxying some zoom
> levels directly to WMS and caching others, is unrealistic?

not unrealistic, but not implemented

--
thomas

>
> paul
>
>
> On 10/28/15 9:36 AM, thomas bonfort wrote:
>>
>> Paul,
>>
>> Are you using metatiling? That would substantially reduce the number
>> of requests mapcache does to mapserver.
>>
>> You also have the
>> 
>> ...
>> true
>> 
>> option, that lets mapcache launch mapserver requests in parallel
>> instead of sequentially (YMMV, this option isn't very tested)
>>
>> --
>> thomas
>>
>> On 28 October 2015 at 16:20, Paul Madden  wrote:
>>>
>>> I am working with a web application that makes WMS queries to MapCache.
>>> The application supports zoom levels 0 through 13, and I have used
>>> mapcache_seed to seed the cache through level 10. The deeper levels take so
>>> long to seed that I am considering stopping at level 10 and letting MapCache
>>> / MapServer produce deeper levels on demand, as users visit them. The
>>> problem I'm facing is that, as far as I can tell, MapCache requests tiles
>>> from MapServer serially, then stitches together the required image from
>>> these tiles, when it receives a request for an uncached level. In one test,
>>> 34 separate tiles were requested from MapServer, one at a time, and it took
>>> ~30 seconds to render the final image.
>>>
>>> I'm wondering whether there is a way to configure MapCache to
>>> cache/provide a defined set of zoom levels, and to proxy requests at other
>>> zoom levels directly to MapServer. I tried setting minzoom and maxzoom on my
>>>  in mapcache.xml to "0 10". I tried adding a proxy for my cached
>>> layer, hoping that MapCache would redirect requests for unsupported zoom
>>> levels to MapServer (I have proxies in place for other, completely uncached
>>> layers, and those work fine). I tried copying/renaming the
>>> GoogleMapsCompatible grid definition into my mapcache.xml and removing from
>>>  zoom levels I don't want MapCache to cache. So far, these
>>> attempts apparently just prevent MapCache from serving the deeper layers at
>>> all.
>>>
>>> Any thoughts on how I might address this issue? It might also help if
>>> MapCache would make concurrent requests for tiles at uncached levels, but I
>>> have no idea if this is feasible. And it would be nice to be able to let
>>> MapServer handle some zoom levels directly in any case.
>>>
>>> Thanks in advance for any ideas.
>>>
>>> Paul Madden
>>> National Snow and Ice Data Center
>>> ___
>>> mapserver-users mailing list
>>> mapserver-users@lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/mapserver-users
>
>
> ___
> mapserver-users mailing list
> mapserver-users@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapserver-users
___
mapserver-users mailing list
mapserver-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-users

[mapserver-users] Two mapserver cgi opening the same mapfile file

[Andrea Peri]

Hi,
to try to have better usage resources I like to try a new
configuration using two distinct cgi mapservers each of them accessing
the same mapfile.
Both the cgi are in the same server with the mapfile.

The goal is to avoid to have two distinct but identical mapfiles to maintain.

I guess should be no problem to have two cgi opening the same mapfile,
but any thought on this kind of configuration is welcome.

Thx.

-- 
-
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-
___
mapserver-users mailing list
mapserver-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-users

Re: [mapserver-users] MapCache: cache some zoom levels, proxy others?

[Paul Madden]

Reading the docs more carefully, it sounds like SQLite databases may have 
concurrency problems even with only mapcache_seed accessing them, given a 
sufficiently high number of threads. I'm guessing that 8 is not "a high 
number", and that a few extra from MapCache itself isn't either. Does anybody 
know differently?

On 10/28/15 20:08, Paul Madden wrote:
> Travis,
> 
> Thank you -- I hadn't realized before what you could do with the various meta 
> caches. I'll definitely be experimenting with a front-end memcache at some 
> point.
> 
> But, I can't yet see how I can overcome the sqlite3 issue with these methods. 
> It seems like the following would *almost* work:
> 
> 
> db1
> db2
> 
> 
> where both db1 and db2 are sqlite3 caches, and db1 is being actively seeded 
> by mapcache_seed. At first I thought: MapCache will check db1 to see if the 
> requested tile has already been seeded and, if not, will move on to db2, 
> which will make the appropriate WMS requests to MapServer. Only mapcache_seed 
> will write to db1, and only MapCache will write to db2: No concurrency issue. 
> But I see this in the docs: "If a given tile isn’t found in the first child 
> cache, it will be read from the second child cache AND copied into the first 
> child cache for subsequent accesses." Given the "AND" part, it seems that 
> both mapcache_seed and MapCache will write concurrently to db1. If this is 
> right, does such a configuration actually avoid the sqlite3 concurrency 
> issue? Is there a better configuration that I've failed to imagine?
> 
> On a related note: If *only* mapcache_seed writes to a sqlite3, but runs in 
> multi-threaded mode, is it sqlite3-safe?
> 
> (The questions are for anyone kind enough to answer...)
> 
> paul
> 
> On 10/28/15 17:42, Travis Kirstine wrote:
>> Paul,
>>
>> I would have a look at some of the new tiered caching options available in 
>> 1.4.  SQLite can have issues locking under load
>>
>> On Wednesday, October 28, 2015, Paul Madden > > wrote:
>>
>>  Thomas,
>>
>>  Enabling metatiling indeed led to a significant speedup. I can also 
>> verify that  works for me (I can see the additional 
>> threads running), but it did not lead to a noticeable speedup, perhaps due 
>> to a bottleneck where my MapServer talks to a remote database. I also 
>> increased my tile size from 256x256 to 1024x1024, which seems fine for my 
>> application and which obviously reduces the number of tiles helpfully.
>>
>>  If I may ask one more question: Are you aware of any problems running 
>> mapcache_seed concurrently with users accessing MapCache via the web 
>> application, if one uses the sqlite3 cache? I saw a thread about potential 
>> conflicts, but I think that might have been specific to disk caches.
>>
>>  Thanks again,
>>  paul
>>
>>  On 10/28/15 9:59 AM, thomas bonfort wrote:
>>
>>  Out of curiosity, can I assume that my other idea, about 
>> proxying some zoom
>>  levels directly to WMS and caching others, is unrealistic?
>>
>>  not unrealistic, but not implemented
>>
>>  --
>>  thomas
>>
>>  paul
>>
>>
>>  On 10/28/15 9:36 AM, thomas bonfort wrote:
>>
>>  Paul,
>>
>>  Are you using metatiling? That would substantially reduce 
>> the number
>>  of requests mapcache does to mapserver.
>>
>>  You also have the
>>  
>>  ...
>>true
>>  
>>  option, that lets mapcache launch mapserver requests in 
>> parallel
>>  instead of sequentially (YMMV, this option isn't very 
>> tested)
>>
>>  --
>>  thomas
>>
>>  On 28 October 2015 at 16:20, Paul Madden 
>>  wrote:
>>
>>  I am working with a web application that makes WMS 
>> queries to MapCache.
>>  The application supports zoom levels 0 through 13, and 
>> I have used
>>  mapcache_seed to seed the cache through level 10. The 
>> deeper levels take so
>>  long to seed that I am considering stopping at level 10 
>> and letting MapCache
>>  / MapServer produce deeper levels on demand, as users 
>> visit them. The
>>  problem I'm facing is that, as far as I can tell, 
>> MapCache requests tiles
>>  from MapServer serially, then stitches together the 
>> required image from
>>  these tiles, when it receives a request for an uncached 
>> level. In one test,
>>  34 separate tiles were requested from MapServer, one at 
>> a time, and it took
>>  ~30 seconds to render the final image.
>>
>>  I'm wondering whether there is a way to configure 
>> MapCache to
>>  

Re: [mapserver-users] MapCache: cache some zoom levels, proxy others?

[Paul Madden]

Thomas,

Enabling metatiling indeed led to a significant speedup. I can also 
verify that  works for me (I can see the additional 
threads running), but it did not lead to a noticeable speedup, perhaps 
due to a bottleneck where my MapServer talks to a remote database. I 
also increased my tile size from 256x256 to 1024x1024, which seems fine 
for my application and which obviously reduces the number of tiles 
helpfully.


If I may ask one more question: Are you aware of any problems running 
mapcache_seed concurrently with users accessing MapCache via the web 
application, if one uses the sqlite3 cache? I saw a thread about 
potential conflicts, but I think that might have been specific to disk 
caches.


Thanks again,
paul

On 10/28/15 9:59 AM, thomas bonfort wrote:

Out of curiosity, can I assume that my other idea, about proxying some zoom
levels directly to WMS and caching others, is unrealistic?

not unrealistic, but not implemented

--
thomas


paul


On 10/28/15 9:36 AM, thomas bonfort wrote:

Paul,

Are you using metatiling? That would substantially reduce the number
of requests mapcache does to mapserver.

You also have the

...
 true

option, that lets mapcache launch mapserver requests in parallel
instead of sequentially (YMMV, this option isn't very tested)

--
thomas

On 28 October 2015 at 16:20, Paul Madden  wrote:

I am working with a web application that makes WMS queries to MapCache.
The application supports zoom levels 0 through 13, and I have used
mapcache_seed to seed the cache through level 10. The deeper levels take so
long to seed that I am considering stopping at level 10 and letting MapCache
/ MapServer produce deeper levels on demand, as users visit them. The
problem I'm facing is that, as far as I can tell, MapCache requests tiles
from MapServer serially, then stitches together the required image from
these tiles, when it receives a request for an uncached level. In one test,
34 separate tiles were requested from MapServer, one at a time, and it took
~30 seconds to render the final image.

I'm wondering whether there is a way to configure MapCache to
cache/provide a defined set of zoom levels, and to proxy requests at other
zoom levels directly to MapServer. I tried setting minzoom and maxzoom on my
 in mapcache.xml to "0 10". I tried adding a proxy for my cached
layer, hoping that MapCache would redirect requests for unsupported zoom
levels to MapServer (I have proxies in place for other, completely uncached
layers, and those work fine). I tried copying/renaming the
GoogleMapsCompatible grid definition into my mapcache.xml and removing from
 zoom levels I don't want MapCache to cache. So far, these
attempts apparently just prevent MapCache from serving the deeper layers at
all.

Any thoughts on how I might address this issue? It might also help if
MapCache would make concurrent requests for tiles at uncached levels, but I
have no idea if this is feasible. And it would be nice to be able to let
MapServer handle some zoom levels directly in any case.

Thanks in advance for any ideas.

Paul Madden
National Snow and Ice Data Center
___
mapserver-users mailing list
mapserver-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-users


___
mapserver-users mailing list
mapserver-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-users


___
mapserver-users mailing list
mapserver-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-users

[mapserver-users] RE Cascaded WMS GetFeatureInfo

[Steve . Toutant]

Cora have you read this?
http://mapserver.org/ogc/wms_server.html#cascading-wms-request
It might help to know why a layer is not cascaded

What happen if you don't modify the style?
steve
 





"Berger, Cora" @lists.osgeo.org 
Envoyé par : "mapserver-users" 
2015-10-27 04:01

A
"'mapserver-users@lists.osgeo.org'" 
cc

Objet
[mapserver-users] Cascaded WMS GetFeatureInfo








Hello everybody,
I am building a cascaded WMS. My layers all have connectiontype WMS and 
all of them use one layer of the same WMS as source. The only thing I 
change is the style of the original WMS. 
My problem is that the GetFeatureInfo does not cascade. I am using 
Mapserver 7.0. I read that the GetFeatureInfo request supports cascading. 
All requests are enabled in the metadata. Do I have to add a special tag 
in the metatada or layer section to "pass through" the GetFeatureInfo from 
the original WMS?

Thanks for your help.

Best regards

Cora Berger
   

___
mapserver-users mailing list
mapserver-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-users


___
mapserver-users mailing list
mapserver-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-users

[mapserver-users] Update Mapserver at demo.mapserver.org?

[Rahkonen Jukka (MML)]

Hi,

I wrote last year 
https://lists.osgeo.org/pipermail/mapserver-users/2014-May/076442.html and 
asked if it could be possible to update the Mapserver v. 5.6.5 that is running 
at http://demo.mapserver.org/cgi-bin/wms and I was told that not before general 
infrastructure transition is over, see 
http://wiki.osgeo.org/wiki/Infrastructure_Transition_Plan_2014

What it the situation now? It would be good to have some Mapserver 7.0 WMS, 
WFS, and WCS services online for testing the issues which are reported on the 
mailing list and in the Github issue tracker. Version 5.6.5 is rather useless 
for that.

-Jukka Rahkonen-
___
mapserver-users mailing list
mapserver-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-users

[mapserver-users] Mapserver and Complex Feature support

[Simon Templer]

Hi all,

I'm trying to find out if and how Mapserver can be used to serve Complex 
Features via WFS 2.0. It's great news that with Mapserver 7 WFS 2.0 is 
supported, but so far I didn't have any luck in finding any particular 
documentation for how to handle complex features or even an example.
Could be that I'm looking in the wrong places or use the wrong search 
terms (or it's just my general ignorance regarding Mapserver), so I 
would be very happy if someone could give a brief overview on the status 
in Mapserver regarding complex features or at least point me in the 
right direction.


For both GeoServer (with app-schema extension) and deegree I know that 
they each use a specific mapping configuration to describe the mapping 
between database (or other data source) to the GML Application Schema 
(for instance from INSPIRE). Is there something similar done in 
Mapserver, for instance as part of a Mapfile?


Thanks

Kind regards,
Simon
___
mapserver-users mailing list
mapserver-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-users

Re: [mapserver-users] Mapserver and Complex Feature support

[Even Rouault]

Le mercredi 28 octobre 2015 10:24:20, Simon Templer a écrit :
> Hi all,
> 
> I'm trying to find out if and how Mapserver can be used to serve Complex
> Features via WFS 2.0.

Complex Features are not really supported. You could perhaps have some success 
for GetFeature output by using template-driven output : 
http://mapserver.org/output/template_output.html . But I haven't tried myself 
and I guess that would only work for not too complex features. And 
DescribeFeatureType would produce only a schema for simple features.

> It's great news that with Mapserver 7 WFS 2.0 is
> supported, but so far I didn't have any luck in finding any particular
> documentation for how to handle complex features or even an example.
> Could be that I'm looking in the wrong places or use the wrong search
> terms (or it's just my general ignorance regarding Mapserver), so I
> would be very happy if someone could give a brief overview on the status
> in Mapserver regarding complex features or at least point me in the
> right direction.
> 
> For both GeoServer (with app-schema extension) and deegree I know that
> they each use a specific mapping configuration to describe the mapping
> between database (or other data source) to the GML Application Schema
> (for instance from INSPIRE). Is there something similar done in
> Mapserver, for instance as part of a Mapfile?
> 
> Thanks
> 
> Kind regards,
> Simon
> ___
> mapserver-users mailing list
> mapserver-users@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapserver-users

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
___
mapserver-users mailing list
mapserver-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-users

Re: [mapserver-users] Mapserver and Complex Feature support

[Simon Templer]

On 28.10.2015 10:46, Even Rouault wrote:

Le mercredi 28 octobre 2015 10:24:20, Simon Templer a écrit :

Hi all,

I'm trying to find out if and how Mapserver can be used to serve Complex
Features via WFS 2.0.

Complex Features are not really supported. You could perhaps have some success
for GetFeature output by using template-driven output :
http://mapserver.org/output/template_output.html . But I haven't tried myself
and I guess that would only work for not too complex features. And
DescribeFeatureType would produce only a schema for simple features.
Thanks for the information. Do you know if there is something like that 
worked on or planned for future versions of Mapserver?



Kind regards,
Simon
___
mapserver-users mailing list
mapserver-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-users

Re: [mapserver-users] Mapserver and Complex Feature support

[Even Rouault]

Le mercredi 28 octobre 2015 11:29:13, Simon Templer a écrit :
> On 28.10.2015 10:46, Even Rouault wrote:
> > Le mercredi 28 octobre 2015 10:24:20, Simon Templer a écrit :
> >> Hi all,
> >> 
> >> I'm trying to find out if and how Mapserver can be used to serve Complex
> >> Features via WFS 2.0.
> > 
> > Complex Features are not really supported. You could perhaps have some
> > success for GetFeature output by using template-driven output :
> > http://mapserver.org/output/template_output.html . But I haven't tried
> > myself and I guess that would only work for not too complex features.
> > And DescribeFeatureType would produce only a schema for simple features.
> 
> Thanks for the information. Do you know if there is something like that
> worked on or planned for future versions of Mapserver?

Not to my knowledge (which doesn't mean someone else isn't thinking to it), 
although you're not the only one that would be interested in that. That would 
require undoubtly a substantial amount of funding to be developed given that 
would probably have important impacts on the general Mapserver architecture.

> 
> 
> Kind regards,
> Simon

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
___
mapserver-users mailing list
mapserver-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-users