I am developing a MapServer map file for a map created with Goode's Homolosine projection. The PROJ string is rather simple:

+proj=igh +lat_0=0 +lon_0=0 +datum=WGS84 +units=m +no_defs

The IOGP (former EPSG) never assigned a code to this CRS, meaning that it falls into the special case identified in the MapServer manual:

However, it is often impossible to find an EPSG code to match the projection of your data. In those cases, the “wms_srs” metadata is used to list one or more EPSG codes that the data can be served in, and the PROJECTION object contains the real PROJ4 definition of the data’s projection.

Therefore the map file contains the following segments:

    "ows_enable_request"    "*"
    "wms_srs"               "EPSG:4269 EPSG:4326"

# [...]

    NAME 'coutries'
    DATA Countries_Goode.tif
        "+proj=igh +lat_0=0 +lon_0=0 +datum=WGS84 +units=m +no_defs"

So far so good, however, the GetCapabilities request only lists the CRSs declared in the METADATA section:

    <LatLonBoundingBox minx="-1" miny="-1" maxx="-1" maxy="-1" />

And from this I am not able to issue a GetMap request with the original CRS. What is needed to make the original CRS available to the GetMap request (and listed in the GetCapabilities document)?

  • 1
    The list of available CRS, don't have to be epsg: codes, so just wondering what happens if you create a custom code in the mapserver bin/proj/share/... location, possibly other.extra, then reference it as other.extra:your_proj_code. – nmtoken Nov 7 '18 at 18:10
  • 1
    @nmtoken MapServer forces EPSG as the SRS namespace. Trying an alternative like OTHER.EXTRA results in an error saying only EPSG is supported and the map file becomes unusable. – Luís de Sousa Nov 8 '18 at 17:50
  • Other.extra was a stab in the dark, but certainly you don't have to have epsg: you can have or crs: esri: for example, that works for me. In fact I was able to create a new file gisse create a SRS <1> and have that appear as GISSE:1 in my GetCapabilities response. I deliberately didn't go for editing the epsg file because it isn't an epsg code – nmtoken Nov 8 '18 at 18:18
  • Apologies... when you said that the message only EPSG is supported, for MapServer, I thought you meant GetCapabilities, but now I see you mean GetMap. Just trying to get my custom CRS to work across QGIS and MapServer, I set up a custom CRS on QGIS, (it gives this a user: namespace) then set up a user CRS namespace on MapServer, and got QGIS to request the CRS in a valid GetMap request; then I got the error msWMSLoadGetMapParams(): WMS server error. Unsupported CRS namespace (only EPSG, AUTO2, CRS currently supported). So now we're stuck by the behaviour of both QGIS and MapServer – nmtoken Nov 9 '18 at 11:48

I would have a try by creating a fake EPSG code into the lookup table "epsg" that is located under the proj directory. On Linux it may be found as share/proj/epsg, in MS4W installation on Windows as ms4w\proj\nad\epsg.

The epsg file has records like

# WGS 84
<4326> +proj=longlat +datum=WGS84 +no_defs  <>

Add your own code as

 # Goode's homologine
 <200200> +proj=igh +lat_0=0 +lon_0=0 +datum=WGS84 +units=m +no_defs" <>

Now it may be possible to refer to this tailored CRS as EPSG:200200 both in your mapfile and by your WMS clients. However, too clever clients like QGIS may fail because they can't initialize their map into EPSG:200200 because they do not know what it is.

You can even create your own namespace by creating a file of that name (for example gisse) in the same location as the epsg file on your system, and reference that instead, so your map file can have:

 "OWS_SRS" "EPSG:4326 EPSG:21095 EPSG:21035 EPSG:21036 EPSG:32635 EPSG:32735 EPSG:32736 EPSG:3857 EPSG:4210 EPSG:4258 ESRI:102022 CRS:84 GISSE:1"

and the GetCapabilities response can be:

<BoundingBox CRS="EPSG:4326"
            minx="-2" miny="29" maxx="4.5" maxy="37" />
<BoundingBox CRS="EPSG:21095"
            minx="721844" miny="-224185" maxx="1.61841e+06" maxy="505393" />
<BoundingBox CRS="EPSG:21035"
            minx="721844" miny="9.77582e+06" maxx="1.61841e+06" maxy="1.05054e+07" />
<BoundingBox CRS="EPSG:21036"
            minx="54455.4" miny="9.7787e+06" maxx="945380" maxy="1.04989e+07" />
<BoundingBox CRS="EPSG:32635"
            minx="721913" miny="-224492" maxx="1.61848e+06" maxy="505089" />
<BoundingBox CRS="EPSG:32735"
            minx="721913" miny="9.77551e+06" maxx="1.61848e+06" maxy="1.05051e+07" />
<BoundingBox CRS="EPSG:32736"
            minx="54535.7" miny="9.7784e+06" maxx="945464" maxy="1.04986e+07" />
<BoundingBox CRS="EPSG:3857"
            minx="3.22827e+06" miny="-222684" maxx="4.11882e+06" maxy="501454" />
<BoundingBox CRS="EPSG:4210"
            minx="-1.99745" miny="28.9993" maxx="4.50312" maxy="36.9992" />
<BoundingBox CRS="EPSG:4258"
            minx="-2" miny="29" maxx="4.5" maxy="37" />
<BoundingBox CRS="ESRI:102022"
            minx="29" miny="-2" maxx="37" maxy="4.5" />
<BoundingBox CRS="CRS:84"
            minx="29" miny="-2" maxx="37" maxy="4.5" />
<BoundingBox CRS="GISSE:1"
            minx="29" miny="-2" maxx="37" maxy="4.5" />
  • This indeed includes the fake 200200 code in the list. However, QGis completely ignores it. Still trying to understand whether this is an issue with the map file or with QGis itself. – Luís de Sousa Nov 8 '18 at 7:28
  • 1
    QGIS is CRS aware. It needs to know what is the meaning of EPSG:200200 and how it relates to other coordinate systems of the world. Otherwise it can't take care of on-the-fly reprojection etc. That Mapserver announces that maps are available in something called EPSG:200200 does not help QGIS but it should know also the meaning of the synonym. Unfortunately QGIS does not use that same "epsg" file for the custom projections, and you can't create EPSG synonym for the custom projections docs.qgis.org/2.18/en/docs/user_manual/working_with_projections/… – user30184 Nov 8 '18 at 8:20
  • Do you need to use QGIS? If you could use OpenJUMP I believe it can show the EPSG:200200 maps for you. – user30184 Nov 8 '18 at 8:24
  • Definitely the issue is with QGis. I do not like using a fake EPSG code but it works; tested it by issuing WMS requests directly with wget. Check also my answer above to @nmtoken, MapServer actually forces the SRS namespace to be EPSG. Go figure. – Luís de Sousa Nov 8 '18 at 15:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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