[mapserver-dev] Implement msPostgisLayerGetExtent

[thomas bonfort]

I spoke too fast... before
https://github.com/mapserver/mapserver/issues/4039 was fixed, the
postgis driver returned bogus extents that caused qgis to disable some
WMS layers in a seemingly random behaviour. Since that one was fixed,
the postgis driver returns no extent, and the WMS spec says in that
case that the parent layer's extent should be used, which effectively
boils down to MAP extent. This clarification however does not change
the fact that capabilities requests will now cause a potentially
expensive st_extent() call.

--
thomas

On 31 December 2013 17:36, thomas bonfort <thomas.bonfort at gmail.com> wrote:
> Steve,
> This function is called to produce the capabilities document, in order
> to provide the client with information as to what the extent for each
> layer is. The provided patch is wanted/usefull, because some clients
> (namely qgis) are smart and will not request layers for extents that
> are outside the advertised extents; in the case where the advertized
> extents are incorrect then you can imagine that this leads to
> difficult to debug unexpected behavior. On the other hand, the
> provided patch is problematic because it may cause capabilities
> requests to take minutes or more to complete given that the st_extent
> call may take ages to complete. The simple workaround is to add an
> EXTENT to each layer, however this requires a manual intervention and
> was not needed beforehand.
>
> --
> thomas
>
> On 31 December 2013 17:20, Stephen Woodbridge <woodbri at swoodbridge.com> wrote:
>> Can someone provide a little background on why and where layer extents are
>> used?
>>
>> I have never used them and in fact never noticed that there was an extents
>> at the layer level. I have always set the extents at the map level, so I
>> guess by default the layers inherit that.
>>
>> I presume that the layer extents are checked to see if the whole layer can
>> be rejected if the image extents does not overlap with the layer extents. Is
>> this correct?
>>
>> Assuming that it is correct, are we changing this behavior?
>> ie: the layer inheriting from the map extents? (assuming that it did). I
>> would not want to take a performance penalty or not having this and would
>> not want to have to change all my mapfiles to add the extents to all the
>> layers.
>>
>> -0 based on not understanding why this is needed and where it gets used!
>>
>> -Steve W
>>
>>
>>
>>
>> On 12/31/2013 10:58 AM, Tamas Szekeres wrote:
>>>
>>> Hi Devs,
>>>
>>> I've recently added an implementation for msPostgisLayerGetExtent in the
>>> master branch based upon user request, but we entered into a debate with
>>> Thomas that this feature should never have been implemented at all.
>>>
>>> The key point against this feature is that it may cause performance
>>> issues for the existing configurations (as said 'denial of service')
>>> when the extent is not specified manually (in the mapfiles) and
>>> MapServer will now turn to the driver specific implementation instead of
>>> returning MS_FAILURE (in LayerDefaultGetExtent). Thomas also mentioned
>>> that this kind of addition should be disabled by default unless voted
>>> forward by the PSC.
>>>
>>> I did not think that we ever had an agreement not to implement
>>> msPostgisLayerGetExtent at all to address potential performance issues
>>> by the driver, as this has already been implemented for most of the
>>> drivers without such issues manifested. It is already documented that
>>> the extent should be configured manually  "to avoid the speed cost of
>>> having MapServer compute the extents of the data"
>>> (http://mapserver.org/mapfile/layer.html).
>>>
>>> Anyway, I would not be against a configuration option to specify that
>>> the extent is 'not set' for a layer, but it should be out of scope of a
>>> driver implementation. And I'm not really convinced about the usefulness
>>> of such setting.
>>>
>>> The complete discussion about this change can be found here:
>>> https://github.com/mapserver/mapserver/pull/4825
>>>
>>> Let me know if you prefer to keep this functionality or revert to the
>>> original (not implemented) behaviour.
>>>
>>> Best regards,
>>>
>>> Tamas
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> mapserver-dev mailing list
>>> mapserver-dev at lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/mapserver-dev
>>>
>>
>> _______________________________________________
>> mapserver-dev mailing list
>> mapserver-dev at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/mapserver-dev