[Mapserver-users] OGC compliance for WMS

Tue Jun 8 12:34:33 PDT 2004

Ed,

Thanks for the prompt response!

You wrote:

"A non-square pixel request should result when the BBOX extents are not
proportional to the WIDTH and HEIGHT request.  When acting as a WMS
*server*, MapServer adjusts the BBOX to the right ratio to match the
WIDTH and HEIGHT, instead of stretching the output image to fit.  Your
example involves MapServer acting as a *client* to ArcIMS, and this
incorrect behavior should not be involved.

I may be missing the boat here - am I?"

In the example I described, Mapserver is acting both as client and server.
It is a client to the USGS WMS and a server of that data along with several
local data layers.  The local layers are not reprojected because their
native projection is EPSG:2163.  The NED layer from the USGS WMS is indeed
reprojected from EPSG:4326 to EPSG:2163.  However, it appears that the
image generated by the USGS WMS was stretched, *prior* to reprojection by
Mapserver, as per the WMS specification because the BBOX aspect ratio and
the output width/height differ.  The reason they differ is because the BBOX
passed to Mapserver was based on EPSG:2163, while the BBOX that Mapserver
passes to the USGS WMS is based on EPSG:4326.  The issue is not that
Mapserver is "filling in" to preserve the correct aspect ratio, it is that
the USGS WMS doesn't and instead stretches, as per the spec.  Perhaps it's
simply a matter of having Mapserver, when cascading other WMSes, adjust the
BBOX that it passes to those servers to essentially force *them* to fill in
to maintain the correct aspect ratio so that no stretching takes place.

There is a message from Arnulf Christl dated April 6, 2004 that I believe
describes the same phenomenon.

He wrote:

"Anyway - UMN MapServer is still not implementing WMS correctly as it
always returns images with "square" pixels. If you use UMN MapServer as
the only service don't bother about it. If you have to combine it with
other WMS it might be problematic.
Its a little tricky to get the gist of this problem. Whenever you
request an image which has an inconsitent aspect ratio of pixels and
coordinates, UMN MapServer will cheat by adding as much map as is needed
to fill up the difference until it can return "square" pixels. The OGC
spec. specifies that instead the image should be stretched. If you
overlay the MS' result with another WMS which does return (WMS
compliant) warped images you will see the difference, whenever the
client works with warped start-up parameters. In the center of the map
the overlay looks good, the further you get to the border of the map the
larger will be the delta."

Does this help?  I could include some screenshots if that would help
illustrate this better.

Thanks again,

-Ty

                      "Ed McNierney"                                                                                                   
                      <ed at topozone.com         To:      "Barry Wilson" <barrywilson at fs.fed.us>, <mapserver-users at lists.gis.umn.edu>    
                      >                        cc:                                                                                     
                                               Subject: RE: [Mapserver-users] OGC compliance for WMS                                   
                      06/08/2004 12:24                                                                                                 
                      PM                                                                                                               

Barry -

I am a little puzzled at the description of your problem.  I was not
under the impression that the non-square output pixel support would be
related to the situation you describe.

The bounding box passed to the USGS server will indeed have a different
SIZE, but the EPSG:4326 image returned should be properly reprojected to
the EPSG:2163 projection and each pixel should end up in the right
place.  I haven't played with this extensively, but I don't think you
should be having a problem here - what am I missing?

The support for non-square pixels, as I understand, is intended to
support output devices with non-square pixels for display or print.  I
did not think it was related to image reprojection - after all, in the
example you give, it would seem like it's the USGS ArcIMS server that's
not returning the data properly.  There's no request for MapServer to
render non-square pixels.

A non-square pixel request should result when the BBOX extents are not
proportional to the WIDTH and HEIGHT request.  When acting as a WMS
*server*, MapServer adjusts the BBOX to the right ratio to match the
WIDTH and HEIGHT, instead of stretching the output image to fit.  Your
example involves MapServer acting as a *client* to ArcIMS, and this
incorrect behavior should not be involved.

I may be missing the boat here - am I?

             - Ed

Ed McNierney
President and Chief Mapmaker
TopoZone.com
-----Original Message-----
From: mapserver-users-admin at lists.gis.umn.edu
[mailto:mapserver-users-admin at lists.gis.umn.edu] On Behalf Of Barry
Wilson
Sent: Tuesday, June 08, 2004 11:11 AM
To: mapserver-users at lists.gis.umn.edu
Subject: [Mapserver-users] OGC compliance for WMS

I've been reading through the archives and saw a couple of threads
related to Mapserver OGC compliance for WMS dated from November 03 and
January 04.
Has the issue of "non-square" pixels been or is it being addressed?

This can be a fairly significant problem for folks who want to be able
to cascade from fully compliant WMSes.  A concrete example is the set of
services provided by USGS, say something like the NED.  These data are
served up by ArcIMS in EPSG:4326, a geographic SRS.  When they are
cascaded through my UMN Mapserver WMS, I reproject them to EPSG:2163, a
Lambert Azimuthal Equal Area projection.  This is where the "non-square"
pixels issue shows up.  When a client requests data from my WMS using a
bounding box in EPSG:2163, the bounding box that gets passed along to
the USGS WMS will have a different aspect ratio in EPSG:4326.  However,
the output image aspect ratio remains fixed.  Therefore, the image from
the USGS WMS gets stretched.  Any data that I serve up locally and
overlay on the USGS image will not get stretched.  The end result is
that the data from the two sources will line up only in the middle of
the image.  The conflation gets worse the further you get from the
center.

The simple solution, of course, is that I serve up my data in EPSG:4326
as well.  That will work in this instance, but I can see problems
arising if I also want to pull in data from other WMSes that serve up
data in some other SRS.

-Ty

~~~~~~~~~~~~~~~~~~~~~~~~
B. Tyler Wilson
USDA Forest Service
North Central Research Station
1992 Folwell Avenue
St. Paul, MN  55108
651-649-5189  barrywilson at fs.fed.us
~~~~~~~~~~~~~~~~~~~~~~~~

_______________________________________________
Mapserver-users mailing list
Mapserver-users at lists.gis.umn.edu
http://lists.gis.umn.edu/mailman/listinfo/mapserver-users