[WMS Server] Enable non-square pixel support by default in WMS interface

[dmorissette]

In bug 728, Frank added the ability to return images with non-square pixels in
WMS requests. This feature is not enabled by default, it requires the following
line in the mapfile to be enabled:

    CONFIG MS_NONSQUARE YES

I would like to enable this option by default in the WMS server case (probably
at the beginning of msWMSDispatch()).  Does anyone see a problem with that?

[sgillies@…]

What would you think about making non-square the default for mapscript as
well?

I think it's awkward to need to use setExtent to set a map's bounding box
instead of going through the map.extent attribute, and then have to check
the values of map.extent afterwards to see what they are after they have
been adjusted.

[sdlime]

I think non-square pixels, unless you're working with non-square pixeled data 
are a bad idea in general. Any changes to the basic workings of extents is not 
going to go well...

Steve

[fwarmerdam]

I would like to point out that things completely do *not* work with 
nonsquare pixel mode if you don't have valid projections set on everything.
I don't see how we can make it be on by default.

We might be able to make it the default for WMS if it is safe to assume
that there always valid projections in the WMS situation. 

"CONFIG MS_NONSQUARE YES" is dangerous!

Fear it!

I fear it. 

Additional work could be done to remove the projection requirement, but 
that will be pretty hard and I'm not funded to work on that (nor do I
have the time just now).  Furthermore, non-square mode really perverts 
all sorts of logic and is likely to force up all sorts of additional issues.

The setExtent() / map.extent query steps are really quite minor in comparison.

[sgillies@…]

Understood.  fear++;

[fwarmerdam]

Where do we want to go with this? 

I think it is risky to turn it on by default for WMS but the risk might be
acceptable.  Another possibibility would be to only turn it on if we recieve
a non-square request.  It might fail in some cases (such as a dataset without
really valid projection information) but at least we would only risk failure
when a request was made that would have been answered wrong anyways.

The other alternative is for us to remove the requirement for real projection
objects for nonsquare (or any sort of rotation) support.  That would be more
work but potentially the best approach overall.  However, doing that is hard
enough (and non-fun enough) that I would appreciate having a DMSolutions 
project to bill the work against. :-)

[dmorissette]

I think I could address this at the same time as bug 947 in the following way:

IF (a WMS request includes a SRS different from the default map projection) 
   OR (includes a request for non-square pixels)
THEN
{
  - Copy the default map projection to all layers with TRANSFORM TRUE that don't
    already have a PROJECTION set
  - Set the top-level map projection to the requested SRS (if applicable) 
  - Set MS_NONSQUARE (if applicable)
}
ELSE
{
  - Just handle the request as usual
}

This would be limited to the WMS interface only, should address any potential
problem with the current non-square implementation, and would address the RTFM
errors from bug 947.

Any objections?

[dmorissette]

Actually I shouldn't ask "any objections?" but more "does anyone see any problem
with this?"

[dmorissette]

No comments received, so I'll implement the solution described in comment #6 now
this will also fix bug 947.

[dmorissette]

Fixed as described in comment #6 (will be in 4.4.0-beta2). No docs updates
required for this bug since this fix actually brings us in line with the spec,
so I think there is no need to state that we do the right thing in the HOWTO.