5

I'm using mapserver to serve an overlay of weather data onto a google map (V2) and the weather data is not displaying where it should.

The image below shows the problem i am having. The black lines are the land border of Alaska, as you can see, they do not line up. The brown lines represent lat long lines.

As you can see the relationship between the lat lon lines and the borders of Alaska align correctly, however they don't match up with google.

enter image description here

The WMS request i am using looks like the following:

http://mysite.com/cgi-bin/mapserv?map=/opt/fgs/www/htdocs/mymap.map&REQUEST=GetMap&SERVICE=WMS&VERSION=1.1.1&LAYERS=radarALASKA_TEST,Graticule&STYLES=&FORMAT=image/png&BGCOLOR=0xFFFFFF&TRANSPARENT=TRUE&SRS=EPSG:4326&BBOX=0,66.51326044311185,45,79.17133464081945&WIDTH=256&HEIGHT=256&reaspect=true

The bounding box is built using the following javascript:

var lULP = new GPoint(a.x * 256, (a.y + 1) * 256);
var lLRP = new GPoint((a.x + 1) * 256, a.y * 256);

var lUL = G_NORMAL_MAP.getProjection().fromPixelToLatLng(lULP, b, false);
var lLR = G_NORMAL_MAP.getProjection().fromPixelToLatLng(lLRP, b, false);

var lBbox = lUL.x + "," + lUL.y + "," + lLR.x + "," + lLR.y;

and this is my mapfile

MAP
#CONFIG "PROJ_DEBUG" "ON"
#CONFIG "CPL_DEBUG" "ON"
#CONFIG "MS_ERRORFILE" "/opt/fgs/www/htdocs/airlog/logs/ms_error.txt"
#DEBUG 5
IMAGETYPE PNG

SIZE 400 300
SHAPEPATH "/opt/fgs/www/htdocs/data"
#FONTSET   "/opt/fgs/www/htdocs//data/fonts.txt"
IMAGECOLOR 255 255 255 
TRANSPARENT OFF

WEB
METADATA
"wms_title"           "WMS Demo Server"
"wms_onlineresource"  "http://10.142.62.153/cgi-bin/mapserv?map=/opt/fgs/www/htdocs/mymap.map&"
"wms_srs"             "epsg:4326 epsg:900913"
END
END

PROJECTION
"proj=merc"
"a=6378137"
"b=6378137"
"lat_ts=0.0"
"lon_0=0.0"
"x_0=0.0"
"y_0=0"
"k=1.0"
"units=m"
"nadgrids=@null"
"wktext"
"no_defs"
END

EXTENT -20037508.34 -20037508.34 20037508.34 20037508.34
UNITS meters

LAYER
TYPE RASTER
STATUS ON
#NAME GISIMAGE_RADAR_CUR_ALASKA_TEST
GROUP radarALASKA_TEST
DATA "/opt/fgs/www/htdocs/Bristow/GISIMAGE_RADAR_CUR_ALASK.png"

PROJECTION
"proj=latlong"
"a=6367451.5"
"b=6367451.5"
END 
UNITS DD
PROCESSING "DITHER=YES"

# For Mapserver 3.x, we would use
# OFFSITE 0
OFFSITE 0 0 0
END

SYMBOL
NAME "circle"
TYPE ellipse
FILLED true
POINTS
1 1
END
END

#  Graticule (lines of constant lat-lon)
LAYER
NAME "Graticule"

PROJECTION
"proj=latlong"
"a=6378137"
"b=6378137"
#"ellps=WGS84"
#"datum=WGS84"
END

TYPE LINE
STATUS ON
CLASS
COLOR 180 180 180

LABEL
TYPE BITMAP
SIZE SMALL
COLOR 90 90 90
POSITION AUTO
OUTLINECOLOR 255 255 255
END
END

GRID
#  In lat-lon coordinate system, lines will always be straight (need 2 pts)
MINSUBDIVIDE 2
MAXSUBDIVIDE 180 
# MAXINTERVAL must be < MININTERVAL or mapserver will hang.
# MININTERVAL 15
# MAXINTERVAL 10
# MINARCS 18
# MAXARCS 10
LABELFORMAT '%.f'
END
END
END

I think the issue is related to the output WKT in the map file but i'm not really sure and i would certainly appreciate help from those far more experienced than me at this stuff!

Thanks everyone in advance, and if i have neglected to include some critical information, please let me know :)

4
  • 4
    It seems as if the WMS request uses EPSG:4326 while it should be EPSG:900913.
    – unicoletti
    Jan 16, 2012 at 10:50
  • Hi, i tried this, but when i set the EPSG to 900913 in the WMS request using the same bounding box i get no overlay and all lat and lon labels return as 0's. When i change the bounding box in the request to -20037508.34, -20037508.34, 20037508.34, 20037508.34, i get the following image: link. My understanding of the request is that the EPSG defines the structure of the bounding box provided so the map server can render correctly, perhaps i have an incorrect bounding box when using 900913? Thanks for your help.
    – user5491
    Jan 16, 2012 at 23:16
  • I think unicoletti is mostly correct here. The request should use the SRS of the basemap, which is 900913. But if you're using MapServer, you want to use 3857. So that I can include more info, I'm posting a bit more in an answer below. Feb 17, 2012 at 16:09
  • Do you have the definition for 900913 in your EPSG file? It should be the same as the EPSG 3857 definition # WGS 84 / Pseudo-Mercator <3857> +proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgrids=@null +wktext +no_defs <> except it should start with<900913> ...
    – nmtoken
    Feb 11, 2016 at 19:25

4 Answers 4

2

The problem turned out to be the definition of the bounding box in the request. I needed to use the proj4.js libraries to properly define the bounding box in 3857 to get this working. Once i did this it worked perfectly, so there was nothing wrong with my mapfile after all :)

1

I have noticed that in the definition of EPSG:900913 (= EPSG:3857) on spatialreference.org differs from other definitions: The parameter "nadgrids=@null" is replaced through "towgs84=0,0,0,0,0,0,0".

I don't know the exact meaning of those parameters, so I can tell which definition in right but it might worth a try to adapt the projection in your mapfile.

(I would be interested if someone can explain the difference...)

2
  • Info on the towgs84 parameters is here: trac.osgeo.org/proj/wiki/… Hopefully you will understand it more than I! "The seven parameter case uses delta_x, delta_y, delta_z, Rx - rotation X, Ry - rotation Y, Rz - rotation Z, M_BF - Scaling. The three translation parameters are in meters as in the three parameter case. The rotational parameters are in seconds of arc. The scaling is apparently the scale change in parts per million."
    – neuhausr
    Jan 17, 2012 at 14:14
  • Hi, I tried substituting the nadgrids line with the towgs84 line above, however this also makes no difference. I don't know if i am missing something fundamental here, but I have to think that the output format is incorrect for both of these layers to project incorrectly, yet i am using the "official" 900913 WKT for the output projection in my map file. If the problem was just the raster layer then i would suspect the WKT for that layer, but since the graticule layer has the same problem, it appears the issue must be the output WKT. Am I right or am i completely off target?
    – user5491
    Jan 18, 2012 at 0:38
1

You're right, projection must be transformed:

    function get_wms_url(bounds) {
         // recalculate bounds from Google to WGS
        var proj = new OpenLayers.Projection("EPSG:4326");
        bounds = bounds.transform(map.baseLayer.projection, proj);

        //construct WMS request

      var url = this.url;
        url += "&REQUEST=GetMap";
        url += "&SERVICE=WMS";
        url += "&VERSION=1.1.1";
        url += "&LAYERS=" + this.layers;
        url += "&FORMAT=" + this.format;
        url += "&TRANSPARENT=TRUE";
        url += "&SRS=" + "EPSG:4326";
        url += "&BBOX=" + bounds.toBBOX();
        url += "&WIDTH=" + this.tileSize.w;
        url += "&HEIGHT=" + this.tileSize.h;
        return url;
     }
    var layerWMS = new OpenLayers.Layer.WMS( "Roads",
        "http://"+location.host+"/cgi-bin/mapserv?map="+basePath+"&", {
            layers: 'roads,buildings,buildingssm,creek,fences,waterbodies',
            format: "image/png",
            getURL: get_wms_url,
            isBaseLayer: false
            }, {gutter: 15, isBaseLayer: false, singleTile: true} );
0

We recently installed MapServer and I also tried to use 900913. That failed. But using 3857 (the modern version of 900913) worked. So, it looks like when MapServer is installed, it may already have the 3857 definition. And you should include that in the wms_srs line of your mapfile. BTW, you might get more debug/error info if you paste the entire get map request to MapServer in a browser window and hit return. If it works with 3857, you get the png overlay. If not, hoperfully MapServer will return a line with error information to help you troubleshoot. If you still get errors, there's a projection definition area that MapServer refers to (MapServer docs says /usr/local/share/proj/epsg) that you may have to modify accordingly.

2
  • Thought I'd add that in our MapServer (6.0), 3857 is indeed defined in the directory I indicated but not 900913. Feb 17, 2012 at 17:30
  • Note that 900913 is not an official EPSG code.
    – markusN
    Apr 7, 2012 at 9:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.