[mapserver-users] mapserver-users Digest, Vol 153, Issue 13

Zmitser Kozhukh zmitserk at mail.ru
Wed Oct 21 23:28:39 PDT 2020


Thank you, Jeff. Specifying wms_extent in metadata has helped. I didn’t think that all these efforts (reading tens of thousands child tables) was just to figure out layer extent. Somehow was thinking that it is taken automatically from mapfile header.
I need to check just for an interest to read such layer through OGR library and see how much it will take to complete layer.GetExtent() :D 
Regarding close_connection=defer directive. Does it mean  that if I use it the connection will be opened for the whole time wms is being viewed by user and all the select queries will use this exact connection. While if I wouldn’t use this directive:  different select queries would have different connections opened? Or do I misunderstand something?
Sincerely, Dimitri
 
  
>Среда, 21 октября 2020, 22:01 +03:00 от mapserver-users-request at lists.osgeo.org:
> 
>Send mapserver-users mailing list submissions to
>mapserver-users at lists.osgeo.org
>
>To subscribe or unsubscribe via the World Wide Web, visit
>https://lists.osgeo.org/mailman/listinfo/mapserver-users
>or, via email, send a message with subject or body 'help' to
>mapserver-users-request at lists.osgeo.org
>
>You can reach the person managing the list at
>mapserver-users-owner at lists.osgeo.org
>
>When replying, please edit your Subject line so it is more specific
>than "Re: Contents of mapserver-users digest..."
>
>
>Today's Topics:
>
>   1. problem with getcapabilities xml generation when layer is
>      using data from postgresql inherited table (Zmitser Kozhukh)
>   2. Re: problem with getcapabilities xml generation when layer is
>      using data from postgresql inherited table (Jeff McKenna)
>   3. Re: problem with getcapabilities xml generation when layer is
>      using data from postgresql inherited table (Jeff McKenna)
>
>
>----------------------------------------------------------------------
>
>Message: 1
>Date: Wed, 21 Oct 2020 13:14:58 +0300
>From: Zmitser Kozhukh < zmitserk at mail.ru >
>To: mapserver-users < mapserver-users at lists.osgeo.org >
>Subject: [mapserver-users] problem with getcapabilities xml generation
>when layer is using data from postgresql inherited table
>Message-ID: < 1603275298.195396547 at f418.i.mail.ru >
>Content-Type: text/plain; charset="utf-8"
>
>
>Good time of the day, may be it is my misconception, but I used to think that generation of GetCapabilities xml doesn’t require checking that the data source of the layer is valid and it really has data etc. I was thinking that this is just a matter of converting metadata from mapfile to xml format by certain rules.
>But it appears, that it is different from what I have been thinking. I am having a wms service that reads data from inherited postgresql table (table inherits data from many thousands of childs table) and it takes infinity to generate getcapabilities xml document:
>https://gis.lesprojekt.cz/cgi-bin/mapserv?map=/home/dima/maps/olu/european_openlandusemap.map&service=WMS&request=GetCapabilities
>With other wms services that use just ordinary tables as data source it (this instance of mapserver) works just fine.
>So my questions is : is it possible to change the code of mapserver not to check all child tables and instead just generate getcapabilities xml from the metadata in mapfile?
>Or may be someone had this issue and found other solution?
>I think in older versions of mapserver (this concrete instance is version 7.2.0 ) inherited tables didn’t cause any troubles.
>Sincerely, Dimitri
> 
>-------------- next part --------------
>An HTML attachment was scrubbed...
>URL: < http://lists.osgeo.org/pipermail/mapserver-users/attachments/20201021/397456cd/attachment-0001.html >
>
>------------------------------
>
>Message: 2
>Date: Wed, 21 Oct 2020 08:31:39 -0300
>From: Jeff McKenna < jmckenna at gatewaygeomatics.com >
>To:  mapserver-users at lists.osgeo.org
>Subject: Re: [mapserver-users] problem with getcapabilities xml
>generation when layer is using data from postgresql inherited table
>Message-ID:
>< aec3cd68-66bb-237e-5028-cad64d11e575 at gatewaygeomatics.com >
>Content-Type: text/plain; charset=utf-8; format=flowed
>
>Hi Dimitri,
>
>For database connections such as PostgreSQL I always manually set the
>LAYER metadata "wms_extent" for each layer (the actual bounding box of
>that specific table in PostGIS), so that MapServer does not have to
>calculate the extents for the GetCapabilities for each layer. (I
>believe this is also mentioned as a "WARNING" in the GetCapabilities
>response).
>
>-jeff
>
>
>
>--
>Jeff McKenna
>MapServer Consulting and Training Services
>co-founder of FOSS4G
>http://gatewaygeo.com/
>
>
>
>On 2020-10-21 7:14 a.m., Zmitser Kozhukh wrote:
>> Good time of the day, may be it is my misconception, but I used to think
>> that generation of GetCapabilities xml doesn’t require checking that the
>> data source of the layer is valid and it really has data etc. I was
>> thinking that this is just a matter of converting metadata from mapfile
>> to xml format by certain rules.
>> But it appears, that it is different from what I have been thinking. I
>> am having a wms service that reads data from inherited postgresql table
>> (table inherits data from many thousands of childs table) and it takes
>> infinity to generate getcapabilities xml document:
>>  https://gis.lesprojekt.cz/cgi-bin/mapserv?map=/home/dima/maps/olu/european_openlandusemap.map&service=WMS&request=GetCapabilities
>> With other wms services that use just ordinary tables as data source it
>> (this instance of mapserver) works just fine.
>> So my questions is : is it possible to change the code of mapserver not
>> to check all child tables and instead just generate getcapabilities xml
>> from the metadata in mapfile?
>> Or may be someone had this issue and found other solution?
>> I think in older versions of mapserver (this concrete instance
>> is version 7.2.0 ) inherited tables didn’t cause any troubles.
>> Sincerely, Dimitri
>>
>
>
>
>
>
>------------------------------
>
>Message: 3
>Date: Wed, 21 Oct 2020 08:35:56 -0300
>From: Jeff McKenna < jmckenna at gatewaygeomatics.com >
>To:  mapserver-users at lists.osgeo.org
>Subject: Re: [mapserver-users] problem with getcapabilities xml
>generation when layer is using data from postgresql inherited table
>Message-ID:
>< add5b6e5-479e-4f4e-61ef-5570c1e94ab1 at gatewaygeomatics.com >
>Content-Type: text/plain; charset=utf-8; format=flowed
>
>I should also mention that for each of my PostgreSQL layers I always
>enable connection pooling for each LAYER:
>
>   PROCESSING "CLOSE_CONNECTION=DEFER"
>
>Although my notes don't answer your specific question, these are the
>steps that I always follow.
>
>-jeff
>
>
>
>--
>Jeff McKenna
>MapServer Consulting and Training Services
>co-founder of FOSS4G
>http://gatewaygeo.com/
>
>
>On 2020-10-21 7:14 a.m., Zmitser Kozhukh wrote:
>> Good time of the day, may be it is my misconception, but I used to think
>> that generation of GetCapabilities xml doesn’t require checking that the
>> data source of the layer is valid and it really has data etc. I was
>> thinking that this is just a matter of converting metadata from mapfile
>> to xml format by certain rules.
>> But it appears, that it is different from what I have been thinking. I
>> am having a wms service that reads data from inherited postgresql table
>> (table inherits data from many thousands of childs table) and it takes
>> infinity to generate getcapabilities xml document:
>>  https://gis.lesprojekt.cz/cgi-bin/mapserv?map=/home/dima/maps/olu/european_openlandusemap.map&service=WMS&request=GetCapabilities
>> With other wms services that use just ordinary tables as data source it
>> (this instance of mapserver) works just fine.
>> So my questions is : is it possible to change the code of mapserver not
>> to check all child tables and instead just generate getcapabilities xml
>> from the metadata in mapfile?
>> Or may be someone had this issue and found other solution?
>> I think in older versions of mapserver (this concrete instance
>> is version 7.2.0 ) inherited tables didn’t cause any troubles.
>> Sincerely, Dimitri
>>
>
>
>------------------------------
>
>Subject: Digest Footer
>
>_______________________________________________
>mapserver-users mailing list
>mapserver-users at lists.osgeo.org
>https://lists.osgeo.org/mailman/listinfo/mapserver-users
>
>------------------------------
>
>End of mapserver-users Digest, Vol 153, Issue 13
>************************************************
--
Zmitser Kozhukh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mapserver-users/attachments/20201022/02c443a6/attachment-0001.html>


More information about the mapserver-users mailing list