WMS BBOX issues

[relliott]

When used as a WMS server mapserver will re-create the WMS BBOX by adding a -0.5pixel buffer to it (in fact its not a 0.5 pixel but a 0.5 unit so could be quite a distance). From the code I can see that it was done because mapserver uses the centre of the four corner pixels as its BBOX and not the outside of the pixels like WMS. This causes several problems:

1/ if you ask for a geoTiff the header will also be buffered by -0.5 and will not represent the original BBOX from the WMS request;

2/ if you have cascaded WMS layers in the map file the request they get uses the new buffered BBOX and not the original WMS one, this in itself can cause the returned image to be offset by half a unit.

[dmorissette]

Which version of MapServer are you using? 4.10?

Can you please try again with 5.0-beta1? Steve did some work to address this issue in 5.0. See ticket #2015 for more details.

[sdlime]

Any more on this one? Would like confirmation that the changes are ok.

Steve

[relliott]

Replying to sdlime:

Any more on this one? Would like confirmation that the changes are ok.

Steve

I'll get on to it today, shouldn't take me long.

Ross

[relliott]

Ok, finally got it all installed (I have to work over a VPN with X and several servers as I'm at home today) and tested. It still doesn't do what I'd expect it to do, I used 5.0.0-beta1 and the following two lines from my apache log file show the two requests, one to mapserver and the other from mapserver to my own WMS.

/cgi-bin/mapserver?VERSION=1.1.1&SERVICE=WMS&REQUEST=GetMap&STYLES=&FORMAT=image%2fjpeg&SRS=EPSG:27700&LAYERS=UKP25&BBOX=436728.861927986,107477.939128876,549586.230516434,170344.841480255&WIDTH=1043&HEIGHT=581&BGCOLOR=0xFFFFFF&EXCEPTIONS=application/vnd.ogc.se_xml

/cgi-bin/GIcgiApp?SERVICE=WMS&BGCOLOR=0&VERSION=1.0.8&REQUEST=GetMap&LAYERS=UKP25&FORMAT=jpg&REQUEST=GetMap&HEIGHT=581&SRS=EPSG:27700&WIDTH=1043&BBOX=436782%2E922943262%2C107532%2E04145448%2C549532%2E169501157%2C170290%2E739154651&EXCEPTIONS=application/vnd.ogc.se_inimage

As you can see it is out by quite a bit now whereas before it was only 0.5 of a metre for my mapfiles.

Ross

[sdlime]

So this test shows the original call to mapserver and then the cascaded call for a WMS layer, correct?

Steve

[relliott]

Replying to sdlime:

So this test shows the original call to mapserver and then the cascaded call for a WMS layer, correct?

Steve

Yes, sorry, I should have said that before.

Ross

[sdlime]

Will address before beta 3 then...

Steve

[sdlime]

I think I know what the error is. I think the MS_CELLSIZE macro should remain as it was in 4.10 but the calls should change. That way it can be used with OWS extents as well. That's likely the cause here. targeting 5.0-beta3. (Dan, this is probably the cause of the difference you reported in bug 2015.)

Steve

[sdlime]

I'm not seeing the problem. I *think* I have the correct test case set up here. Two mapfiles, both for WMS (one server and one client). I call the cascaded WMS service like so:

~/dev/mapserver/mapserv "QUERY_STRING=map=test2.map&service=wms&version=1.1.1&request=GetMap&layers=ctybdpy2_wms&bbox=493000,4978000,494000,4979000&width=250&height=350&srs=EPSG:26915&format=gif&styles=" 

I tossed a couple of debug lines in to make sure the converstion from WMS extents to MapServer extents were happening. The output confirms the conversion and that the cellsize computations are consistent between each model:

OWS extent: 493000.000000,4978000.000000,494000.000000,4979000.000000 OWS cellsize: 4.000000, 2.857143 MS extent: 493002.000000,4978001.428571,493998.000000,4978998.571429 MS cellsize: 4.000000, 2.857143

These are just a couple of printf's on either side of the computations in the if-then block starting on line 842 in mapwms.c.

Then in the web logs we see the call to the WMS server via MapServer WMS client support:

127.0.0.1 - - [03/Sep/2007:19:47:31 -0500] "GET /cgi-bin/mapserv?map=/Users/sdli me/dev/tmp/2175/test.map&LAYERS=ctybdpy2&REQUEST=GetMap&SERVICE=WMS&FORMAT=image %2Fgif&STYLES=&HEIGHT=350&VERSION=1.1.1&SRS=EPSG:26915&WIDTH=250&BBOX=493000%2C4 978000%2C494000%2C4979000&TRANSPARENT=TRUE&EXCEPTIONS=application/vnd.ogc.se_ini mage HTTP/1.1" 200 473

Notice that the requested bbox in this cascaded request is exactly the same as the original. The error log also contains debug lines like above. As expected they are identical.

So, near as I can tell the WMS server and WMS client are handing this just fine.

I also tried generating a GeoTIFF with the above method. I checked the TIFF using gdalinfo and it also matches the original request. Here's the output.

Stephen-Limes-Computer:~/dev/tmp/2175 sdlime$ /usr/local/bin/gdalinfo mapserv.tiff
Driver: GTiff/GeoTIFF
Size is 250, 350
Coordinate System is:
PROJCS["NAD83 / UTM zone 15N",
    GEOGCS["NAD83",
        DATUM["North_American_Datum_1983",
            SPHEROID["GRS 1980",6378137,298.2572221010002,
                AUTHORITY["EPSG","7019"]],
            AUTHORITY["EPSG","6269"]],
        PRIMEM["Greenwich",0],
        UNIT["degree",0.0174532925199433],
        AUTHORITY["EPSG","4269"]],
    PROJECTION["Transverse_Mercator"],
    PARAMETER["latitude_of_origin",0],
    PARAMETER["central_meridian",-93],
    PARAMETER["scale_factor",0.9996],
    PARAMETER["false_easting",500000],
    PARAMETER["false_northing",0],
    UNIT["metre",1,
        AUTHORITY["EPSG","9001"]],
    AUTHORITY["EPSG","26915"]]
Origin = (493000.000000,4979000.000000)
Pixel Size = (4.00000000,-2.85714286)
Metadata:
  AREA_OR_POINT=Area
Corner Coordinates:
Upper Left  (  493000.000, 4979000.000) ( 93d 5'19.54"W, 44d57'51.86"N)
Lower Left  (  493000.000, 4978000.000) ( 93d 5'19.49"W, 44d57'19.45"N)
Upper Right (  494000.000, 4979000.000) ( 93d 4'33.89"W, 44d57'51.89"N)
Lower Right (  494000.000, 4978000.000) ( 93d 4'33.85"W, 44d57'19.48"N)
Center      (  493500.000, 4978500.000) ( 93d 4'56.69"W, 44d57'35.67"N)
Band 1 Block=250x32 Type=Byte, ColorInterp=Red
Band 2 Block=250x32 Type=Byte, ColorInterp=Green
Band 3 Block=250x32 Type=Byte, ColorInterp=Blue

Steve

[sdlime]

Marking as "worksforme" for the time being. Can always re-open if necessary.

Steve

[tbonfort]

Steve,

the bbox issue doesn't seem fixed on our side for wmsclient layers (the code in mapwmslayer.c). at lines 661 and 704 of that file, the generated bbox is

snprintf(szBuf, 100, "%.15g,%.15g,%.15g,%.15g", 
                 bbox.minx, bbox.miny, bbox.maxx, bbox.maxy);

with bbox = map->extent. ie it's the mapserver extent that's being used.

our logs show the pb:

tilecache.py?(....)BBOX=-179.296875,-89.296875,179.296875,269.296875
/cgi-bin/mapserv?mapfile=mapfile.map&(...)&BBOX=-180,-90,180,270

the second url is the original request

the first url is the one generated by the mapserver wms client code

[dmorissette]

Closing. I believe the mapwmslayer.c issue was fixed in ticket #2843 in MS 5.4 dev (r8392) and 5.2 branch (r8393).