[mapserver-dev] Overwrite Extent for WMS

[Fabian Schindler]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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 _______________________________________________ 
>>> 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
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRSEvaAAoJEJoaok7HgajK3hQH/3jtQNmjHmaKiOw8PF2MqbeU
iFs5xlFIWlXRXpf+E2mgh2pBkmHjdU/z1B4nuBTED5VoMWMg5MVIyzkO1IY1bk87
xPxrlJP3mWUVIzqU3nGaXq8vSY32Wy/Xh18+XVVihbV0I1uBXIfqyHyRFUT47Hfz
FQ61XY8VcB1Ko9KSx1e/2uYK22+d9bR+mYmEz3s2t9L2N0V0gZtgEBIr72u/zXRZ
GWe5ekvZTcLvMJDu3uukFEfwafksRCV2whBe9p26T2hozsSOANlekC3+pbyQW6jz
fB1MoiXh3TtW5ZvztVCBeKPfmVgnbfdKIxDYPGm3YTETbs0FuyU3Xo6mHpFXONk=
=qqpg
-----END PGP SIGNATURE-----