[Mapserver-dev] Rotated Map Rendering

[Stephen Woodbridge]

OK, I hate to jump into a thread late and into one that I have only half 
been following, but what the hey:

The view model that I have always worked with in the CAD/CAM and 
graphics world is the standard camera model i.e.: world space -> 
projected space -> to clipped 2d space -> viewport space or device 
coordinates. OK so I know we are not trying to redesign the mapserver 
viewing pipeline.

So I liked the idea that someone suggested about an output frame or view 
port definition that would describe a final transformation of the image. 
I was thinking that this could be defined to cause a simple image 
transform as the image is output. For now only allow ROTATION in 
increments of +-90 degrees. and this would be handled just before the 
OUTPUTFORMAT processor is invoked. May be like

OUTPUTFORMAT
   ROTATEOUTPUT 90
   ...
END

ALSO, If this is set then image.x and image.y are transformed on input 
so they align correctly with the internal image. If other parameters 
need to be adjusted to them at the same time. This keeps mapserver 
pretty much insulated from any of these changes.

By limiting the transforms to +-90 degrees increments the transform 
becomes one of just swapping x/y values and/or min/max values which 
should be fast and the same for pixel outputs.

So I probably have missed the whole point of this discussion and this is 
just extraneous noise so feel free to ignore it if it doesn't apply.

-Steve W.


Frank Warmerdam wrote:

> Steve Lime wrote:
> 
>> You're right, I was thinking EXTENT and ROTATEDEXTENT. With your
>> explanation its
>> clear that just ROTATION makes no sense.
>>
>> Clearer now. Why the switch from min/max to the alternative method? I
>> think that will only lead to confusion. You could just use the normal 
>> extent and throw
>> rotation in using
>> a single parameter, e.g.
>>
>> EXTENT ... as normal ...
>> ROTATION 45
>>
>> Or even use ANGLE, then we don't have to add any keywords. Even if we
>> go with
>> ROTATEDEXTENT I'd prefer expressing the extent portion as minx, miny,
>> maxx,
>> maxy for consistancy.
> 
> 
> Steve,
> 
> What would the meaning of the extent be in the rotated case? I can imagine
> a few alternatives:
> 
>  1) The map view would computed as if it was the provided extent, but then
>     rotated around the center point by the desired amount.  Thus the user
>     provided extent would no be completely contained within the view, 
> nor would
>     it it be completely containing the view but it would be the same ground
>     size as the final view.
> 
>  2) The map view would be computed to completely display the extent 
> provided
>     by the user plus as much additional data outside that extent as 
> necessary
>     given the rotation angle.  This is sort of similar to the current 
> approach
>     where the extent may be adjusted larger if needed to maintain a square
>     pixel size ... the extent is essentially request that the user 
> should see
>     *at least* the area requested.  The rotated view would be rotated 
> about the
>     center of the requested extent.
> 
>  3) The map view would be computed to fall completely within the requested
>     extent, so somewhat less than the requested extent would be actually 
> visible.
>     The extent is essentially treated as an MBR for what may be shown.
> 
> I was specifically trying to avoid a min/max style extent because it is so
> unclear what case is being used and because for many applications a 
> "preprocessing
> step" of faking up the extents is going to be required.   However, from my
> clients point of view any of these can be "worked around" so I am 
> willing to
> consider other view points.
> 
> Best regards,