[mapserver-dev] Overwrite Extent for WMS

[Stephan Meißl]

Fabian,

we discussed this here at the code sprint and the conclusion was to not
override the georefernce with information from layer->extent (note that
layer->metadata->extent has been removed in favor of layer->extent).

You could use a VRT or world file to overwrite the georeference though.

cu
Stephan


On 03/19/2013 07:28 AM, Fabian Schindler wrote:
> Folks,
> 
> I opened an issue for this apparent bug [1]. It would be nice if
> anyone could confirm the problem.
> 
> I detected a typo in my earlier test mapfile. It should be "DATA
> red.tif" instead of "DATA red2.tif" in the only layer.
> 
> Thanks,
> Fabian
> 
> [1] https://github.com/mapserver/mapserver/issues/4611
> 
> On 03/18/2013 10:23 AM, Fabian Schindler wrote:
> 
>> (new try with smaller images)
> 
>> Daniel,
> 
>> Sorry I did not provide a test case myself, you'll find one in the 
>> attachment.
> 
>> I tested it with the following requests:
> 
>> This yields a red image (where it should not be as "ows_extent" is
>> set to a different extent): mapserv -nh 
>> QUERY_STRING="map=red.map&service=wms&version=1.1.0&request=getmap&bbox=10,10,20,20&srs=EPSG:4326&format=image/png&styles=&layers=red&width=256&height=256&bgcolor=0,0,0"
>>>
> 
> x.png && python demime.py x.png
> 
>> This yields a black image (where it should be red): mapserv -nh 
>> QUERY_STRING="map=red.map&service=wms&version=1.1.0&request=getmap&bbox=-10,-10,0,0&srs=EPSG:4326&format=image/png&styles=&layers=red&width=256&height=256&bgcolor=0,0,0"
>>>
> 
> x.png && python demime.py x.png
> 
> 
>> If you replace the DATA of the layer with "red.png" the results are
>> the exact opposite. It makes *no* difference what version of WMS I
>> use.
> 
>> My Version:
> 
>> $ shp2img -v MapServer version 6.3dev OUTPUT=...
> 
> 
>> Unfortunately I'm lost in the WMS sources. Could you give me some 
>> pointers to find that bug?
> 
>> Cheers, Fabian
> 
> 
>> On 03/15/2013 08:53 PM, Daniel Morissette wrote:
>>> Hi Fabian,
>>>
>>> I didn't setup a testcase to try to reproduce this, but the code
>>> should take the layer "wms|ows_extent" metadata in priority even
>>> for rasters, so I do not understand what is happening. (i.e.
>>> mapwms.c will call msOWSGetLayerExtent() for any layer type,
>>> which looks up the metadata first and should fall back on calling
>>> msLayerGetExtent() -> msRASTERLayerGetExtent() only if metadata
>>> is not set.)
>>>
>>> You didn't specify which version of MapServer you are using.
>>> Hopefully it's 6.2 or a more recent dev snapshot.
>>>
>>> All this to say that you may have hit a bug that should be
>>> investigated.
>>>
>>> Daniel
>>>
>>>
>>> On 13-03-15 10:06 AM, Fabian Schindler wrote:
>>>> Dear Devs,
>>>>
>>>> I want to configure a layer for WMS where I set the extent of
>>>> the image with a dateline wrapped extent (for raster files that
>>>> cross the dateline).
>>>>
>>>> Now I expected I could do this with "wms|ows_extent" metadata
>>>> entries, but it only works for "plain" raster files with no
>>>> geospatial metadata attached.
>>>>
>>>> It does not work, however, with GeoTIFFs with projection and 
>>>> geotransform set. The images are always at the extent that is
>>>> given in the raster file itself.
>>>>
>>>> For comparison: in WCS when "ows|wcs_extent" and any of
>>>> "ows|wcs_size" or "ows|wcs_resolution" is set, the extent is
>>>> always overruled by the mapfile.
>>>>
>>>> Is this behavior intended? Or did I stumble over a bug? Is
>>>> there any other way to overrule the input data extent without
>>>> touching the file itself?
>>>>
>>>> Regads, Fabian