[Mapserver-users] OGC compliance for WMS
Barry Wilson
barrywilson at fs.fed.us
Tue Jun 8 14:22:13 PDT 2004
Ed,
Yes, you've understood perfectly the issue I was trying to describe.
First, I agree with you that this particular problem could be solved
without addressing the "non-square" pixel issue. Also, cartographically
speaking, I prefer the way Mapserver handles aspect ratio mismatches to the
stretching approach adopted in the specification. However, because of
Mapserver's support of reprojection-on-the-fly I viewed these as being
related and somewhat troubling issues.
The real problem is when other WMSes, that support "non-square" pixels, try
to cascade Mapserver and pass through a "non-square" request. In this case
the bug (assuming it really is a bug and not just operator error on my
part) fix we're talking about will not help. The bug fix ensures that
other WMSes will conform to Mapserver, not vice versa.
IMHO, Mapserver is far more appealing when it behaves exactly like every
other OGC-compliant WMS, especially when you factor in price and
performance. It is an easier sell to an organization when you can say it
is truly interoperable and "plays nicely with others" ... and it won't cost
you anything! Just my $.02 anyway.
Not complaining, just encouraging :-)
Thanks for your help,
-Ty
"Ed McNierney"
<ed at topozone.com To: "Barry Wilson" <barrywilson at fs.fed.us>
> cc: <mapserver-users at lists.gis.umn.edu>
Subject: RE: [Mapserver-users] OGC compliance for WMS
06/08/2004 02:49
PM
Barry -
I *think* Arnulf is talking about something else - but I still could be
confused.
MapServer wants EPSG:2163 but the USGS only serves EPSG:4326. So
MapServer reprojects the BBOX it wants from EPSG:2163 to EPSG:4326 - and
it SHOULD ALSO ADJUST THE REQUESTED WIDTH AND HEIGHT to reflect the
reprojected BBOX. If I'm looking for a 100x100 pixel image in
EPSG:2163, I may need to request a 110x106 pixel (or whatever) image
from an EPSG:4326 server. If MapServer is deciding to generate the
appropriate BBOX request from another server, it should be generating an
appropriate WIDTH and HEIGHT to go with it.
This can be a bit tricky to do (I worked with software from Blue Marble
several years ago that never got it right) but it should be done. If
MapServer is not doing it, then (I think) it is indeed a bug, but one
that is unrelated to whether MapServer generates non-square pixels in
response to a WMS request.
- Ed
Ed McNierney
President and Chief Mapmaker
TopoZone.com
-----Original Message-----
From: Barry Wilson [mailto:barrywilson at fs.fed.us]
Sent: Tuesday, June 08, 2004 3:35 PM
To: Ed McNierney
Cc: mapserver-users at lists.gis.umn.edu
Subject: RE: [Mapserver-users] OGC compliance for WMS
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
More information about the MapServer-users
mailing list