[Mapserver-dev] Rotated Map Rendering

[Sean Gillies]

On May 18, 2004, at 11:32 AM, Frank Warmerdam wrote:

> 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.
>

Frank, I was going to comment earlier but have been waiting till my 
ideas
were fully baked.  Not there yet, but I guess this is the time to chip 
in.

Instead of adding to the mapObj structure and increasing its complexity,
could we create a Frame or Window type of element allowing an
arbitrary view of the Map?  Rotation for now, but looking down the road,
someone will eventually ask for oblique views as well.

My $0.02.
Sean

--
Sean Gillies
sgillies at frii dot com
http://users.frii.com/sgillies