[Mapserver-dev] Rotated Map Rendering

[Frank Warmerdam]

Steve Lime wrote:
> What sort of feedback did you get? I appologize for not responding in a
> timely fashion...

Steve,

None .... which I take as implicit consent. :-)

> Will normal projections still function?

Yes.

>>It is hoped that support for non-square pixels will also fall out of this
> 
>>work, allowing us to complete WMS conformance testing.
> 
> 
> We'll need to chat on this. Things are setup for non-square pixels at
> low levels
> but the ramifications of such a change will be wide-spread.

Right but my theory is that we would continue to "fake" the coordinate
system so that the pixel seem square in the pseudo-coordinate system.

>> o The rotation effect will only cause an alteration in function in
>>   msDrawMap().  It should have no effect on query mode or other
> 
> operations.
> 
> How do people interact with the "rotated" images to perform queries,
> pans and 
> zooms? Those work off a bounding box to turn a mouse click into
> something 
> useful.

Hmm, this may be problematic.  To make this work the parts of the
code that use the extents to map a pixel/line location back to
a geographic location would likely need to be aware of the changes.
Alternatively, we could look at always having the fake extent information
"in action" not just during a msDrawMap() call but that might well have
other impacts I haven't considered.


>>EXTENT_ROT <center_x> <center_y> <width> <height> <rotation_angle>
> 
> 
> In keeping with the rest of the syntax I would prefer a less cryptic
> name, with no
> underscore. ROTATION might be as good as anything.

Well, I don't think ROTATION implies it is a full view region.
Would ROTATEDEXTENT work for you?


> Change to whatever the keyword becomes (map->setRotation rolls off the
> tongue)...

Well, yes, but it is misleading.

>>The mapObj will include following extra parameters:
> 
> 
> Could/should these be buried in a new object (rotationObj)? Makes
> exclusion from
> SWIG a tad easier. When adding this much it seems like it warrants a
> new structure.

OK, seems fair.

> My main worry I guess is interaction with rotated maps. Too bad this
> couldn't
> be dealt with entirely within the existing projectionObj setup.

Well, it could be - in theory - but only if the user was able to mentally
work in the rotated coordinate system.  There is lots of code that needs
to know about pixel/line coordinates and georeferenced coordinates.  That
transformation currently has nothing to do with the projectionObj.

I am essentially introducing a "fake" set of georeferenced coordinates so
that the existing code doing transformations between pixel/line and georeferenced
can continue to operate based on their assumption of square pixels and
northup rectangular extents.  The alternative is to visit every location
where transformations are made between pixel/line and georeferenced coordinates
(or vice versa) and update them to use the geotransform[].  I am concerned this
may go beyond the available funding and introduce untold numbers of possible
bugs.

I am cc:ing the -dev list again in case others want to chip in now.

Best regards,

-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent