[mapserver-dev] Overwrite Extent for WMS
Fabian Schindler
fabian.schindler at eox.at
Mon Mar 18 02:23:47 PDT 2013
(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
>>
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: demime.py
Type: text/x-python
Size: 199 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/mapserver-dev/attachments/20130318/cca74852/attachment.py>
-------------- next part --------------
MAP
STATUS ON
EXTENT -180 -90 180 90
SIZE 400 300
IMAGETYPE png24
DEBUG 5
CONFIG MS_ERRORFILE "stderr"
WEB
METADATA
"ows_onlineresource" ""
"ows_enable_request" "*"
END
END
PROJECTION
"init=epsg:4326"
END
LAYER
NAME "red"
DATA "red2.tif"
#DATA "red.png"
PROJECTION
"init=epsg:4326"
END
METADATA
"ows_extent" "-10 -10 0 0"
"wms_srs" "EPSG:4326"
END
TYPE RASTER
STATUS on
END
END
-------------- next part --------------
A non-text attachment was scrubbed...
Name: red.png
Type: image/png
Size: 757 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/mapserver-dev/attachments/20130318/cca74852/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: red.tif
Type: image/tiff
Size: 5474 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/mapserver-dev/attachments/20130318/cca74852/attachment.tif>
More information about the mapserver-dev
mailing list