[SOLVED] Posting my last comment as the answer because it really did solve the problem. Found out the MapServer User forum that a proper WMS call does not use the "MODE=map" option. When one does that, it's not a WMS call but a MapServer call. Therefore, MapServer specific values are required (e.g. imgext, mapext). Taking out the "MODE=map" and then using a point layer vs the raster I started to work with did indeed use the BBOX, HEIGHT, and WIDTH values in the WMS options to properly display the layer over the map area. The reason I had thought "MODE=map" was needed was that I would get an error with the raster layer I started to work with and it would go away if I put it back in. But, I then tried with a points layer with the same EPSG as the map (raster was different and real cause of that error) and that worked when I didn't use the "MODE=map" in the options. unicoletti was essentially correct that the mapserver link provided the answer. But, I couldn't see this detail in the doc due to the other error I was getting with the raster layer. A person on the MapServer User forum I asked the question to told me outright that including "MODE=map" makes the call a MapServer call and that expects different parameters (i.e. imgext, mapext), whereas taking MODE=map out and using the WMS options for GetMap makes it a WMS call. BTW, I also solved the problem with the raster layer. I was getting an error indicating the SRS had to be the same for the layers which didn't initially make sense according to the MapServer docs and how I had structured the mapfile. But, searched for the error, reread the MapServer docs, saw other possible answers on the user forums, changed around the mapfile, and finally got it to work. Thanks for the comments and to all for considering this problem!
The difference between WMS 1.1.1 and 1.3.0 is two fold.
CHANGE NO 1 - CRS/SRS Usage
Use SRS for 1.1.1
Use CRS for 1.3.0
CHANGE No 2 - WMS 1.3.0 ONLY
The order of parameters for BBOX depends on whether the CRS definition has flipped axes. You will see this in the GetCapabilities request at 1.3.0 - the response should show the flipped axes.
BBOX=xmin,ymin,xmax,ymax NON-FLIPPED
BBOX=ymin,xmin,ymax,xmax FLIPPED
I have made a list of EPSG codes that need to be flipped by creating a SpatiaLite 4.3.0 database and then saving this SQL request to file:
SELECT auth_srid, has_flipped_axes, ref_sys_name, axis_1_name, axis_1_orientation, axis_2_name, axis_2_orientation FROM "spatial_ref_sys_all" WHERE auth_name = "epsg";
You will then see that EPSG:4326 needs to have flipped axes.
4326 1 WGS 84 Latitude North Longitude East
THIS IS THE CORRECTED 1.3.0 REQUEST
Change is BBOX=24,-126,50,-66
http://mesonet.agron.iastate.edu/cgi-bin/mapserv/mapserv?map=/mesonet/www/apps/iemwebsite/data/wms/goes/conus_ir.map&SERVICE=WMS&REQUEST=GetMap&VERSION=1.3.0&WIDTH=256&HEIGHT=256&FORMAT=image/png&TRANSPARENT=TRUE&BBOX=24,-126,50,-66&LAYERS=conus_ir_4km_900913,conus_ir_4km&CRS=EPSG:4326&STYLES&
Best Answer
The cause of the problem is that the service is expecting a SRS parameter and you have not supplied one.
If you are making a GetMap (and GetFeatureInfo) request with WMS versions 1.1.1 or below, you must pass the coordinate reference system to the WMS Server (in this case MapServer, but the same is true for all WMS servers) using the
SRS
parameter.Like SRS=epsg:27700& in the below GetMap request:
For WMS version 1.3.0 the parameter name changes to
CRS
(spelling of parameter names is not case sensitive, just using capitals for emphasis here).Like CRS=EPSG:4326& in the below GetMap request: