[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