Opened 15 years ago

Closed 12 years ago

Last modified 12 years ago

#2028 closed defect (fixed)

[WMS Server] Using non-EPSG-format projections

Reported by: jmckenna@… Owned by: dmorissette
Priority: high Milestone: 6.0 release
Component: WMS Server Version: 5.0
Severity: normal Keywords:
Cc: jmckenna

Description (last modified by dmorissette)

Best explained with an example:

- wms data to be served is in a projection that is not part of the standard EPSG
lookup file
- wms-server mapfile sets the MAP.PROJECTION, and LAYER.PROJECTION to the following:

   # Map projection

- however a GetCapabilities request response gives these errors for the layers:

<!-- WARNING: Mandatory mapfile parameter '(at least one of) MAP.PROJECTION,
LAYER.PROJECTION or wms_srs metadata' was missing in this context. -->


Assefa and I looked into the code and MapServer is looking for an actual EPSG
code here, so this appears to be a "limitation" of MapServer.

Attachments (1) (1.6 KB ) - added by nsavard 13 years ago.
zip of mapfile and shapefile

Download all attachments as: .zip

Change History (22)

comment:1 by dmorissette, 15 years ago

Resolution: invalid
Status: newclosed
Dunno if I'd call that a limitation of MapServer... it takes its roots in the
WMS spec.

The WMS spec mandates that a server advertizes its supported SRS using EPSG
codes. MapServer is simply asking you to specify at least one EPSG code to
advertize in its capabilities otherwise you cannot have a valid WMS server.

Note that in your example if no ESPG code exists, you could keep your map and
layer projection definitions as they are now (PROJ4 definitions) and simply add
a "wms_srs" "EPSG:4326" (for instance) in the map-level METADATA. Then the WMS
would advertize EPSG:4326 as its one and only supported SRS and would be fully

I'll close as invalid since I don't think there is much we can do about this...
you need to provide a EPSG code, that's it. (Or did I misunderstand the issue?)

comment:2 by dmorissette, 15 years ago

Oh, I forgot to mention that if you set "wms_srs" "EPSG:4326" as suggested above
then the WMS will be fully functional, but you'll have to pay the price of
on-the-fly reprojection for every request.

comment:3 by jmckenna@…, 15 years ago

Maybe i left out one thing:

- map-level metadata is set to advertize the following epsg codes:

    "ows_srs"   "EPSG:42304 EPSG:42101 EPSG:4269 EPSG:4326"

So that is why I was confused to see that warning message from getcapabilities.  

So it would seem that MapServer requires that advertising to occur at the layer
level as well (I need to add in "ows_srs" layer metadata as well).

Anyway thanks for your response.

comment:4 by jmckenna@…, 15 years ago

for the record, I still believe that there is a bug because in my example I had
map.projection, layer.projection, and map srs metadata set and I still got an
error stating that I must set one of those.  To me that is a bug.  Maybe the
warning should state:

<!-- WARNING: Mandatory mapfile parameter '(at least one of) MAP.PROJECTION in
EPSG format,
LAYER.PROJECTION in EPSG format, or LAYER.METADATA "wms_srs"' was missing in
this context. -->

comment:5 by dmorissette, 15 years ago

Milestone: 5.0 release
Resolution: invalid
Status: closedreopened
Reopening. You had left out an important detail, i.e. that you had specified
ows_srs at the map-level. This should have been enough to make MapServer happy,
so yes there is a bug and the layer-level metadata should not be required in
this case.

comment:6 by dmorissette, 15 years ago

Description: modified (diff)
Owner: changed from mapserverbugs to dmorissette
Status: reopenednew

I'll take this one.

comment:7 by dmorissette, 15 years ago

Ticket #2254 seems to be about the same issue but adds an interesting piece of info: it happens only with WMS 1.1.1 and not with 1.1.0

comment:8 by dmorissette, 15 years ago

Milestone: 5.0 release5.0.1 release

comment:9 by dmorissette, 14 years ago

Milestone: 5.0.1 release5.2 release

comment:10 by dmorissette, 14 years ago

Milestone: 5.2 release5.4 release

comment:11 by jmckenna, 13 years ago

Cc: jmckenna added

comment:12 by dmorissette, 13 years ago

Milestone: 5.4 release6.0 release

comment:13 by nsavard, 13 years ago

Daniel, do you have any new development on this one? If no could I reassign this ticket to someone else or do you prefer to fix it?

comment:14 by dmorissette, 13 years ago

Do we have a simple testcase to reproduce this?

comment:15 by sdlime, 13 years ago

Milestone: 6.0 release5.6.0 release

comment:16 by nsavard, 13 years ago

Re comment:14

I try to put in place a simple test case.

by nsavard, 13 years ago

Attachment: added

zip of mapfile and shapefile

comment:17 by nsavard, 13 years ago


I attached a test case and was not able to reproduce. Notice that I commented out the EPSG:4326 in the epsg file. I tested with MapServer trunk. Could you verify if I forgot something in the test case?


comment:18 by dmorissette, 12 years ago

Milestone: 5.6 release6.0 release

comment:19 by dmorissette, 12 years ago

Resolution: fixed
Status: newclosed

I finally came across a way to reproduce this issue... and fixed it in SVN trunk r9858 (future 6.0)

It turns out that when you had a valid ows_srs metadata or projection at the map level, but none at the layer level, you would get this warning when you shouldn't. Great to see that this one is finally behind us.

comment:20 by dmorissette, 12 years ago

OOpps... the changeset was r9854

comment:21 by dmorissette, 12 years ago

Also backported to branch-5-6 r9855

Note: See TracTickets for help on using tickets.