[Mapserver-users] OGC compliance for WMS

[Ed McNierney]

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