[Mapserver-dev] Rotated Map Rendering

[Julien-Samuel Lacroix]

Hi,

Sorry if you got this message twice, my first attempt was blocked by the 
  spam filter (changed address).

Frank, a question or two about this. I know I'm late, but I'll trow my 
idea in anyway, feel free to ignore them. Is there any advantage of 
using the x/y min/max + rotation datastructure? What was the main reason 
of going this way?

Because my thought was since an extent defined this way with angle 0 
will be the same thing as a regular extent, we could maybe support both 
extent definition and put, like it have been suggested many time, the 
rotation angle in a separate keyword. I don't know how much effort it 
will be hard integrate, but this could keep your original plan on the 
track and lead to future enhancement that will take advantage of this 
definition (like camera model features).

But since internally (for now) there will probably no difference between 
the two method (correct me if him wrong), this will be just a new 
feature in mapserver. A feature that can maybe help users to use 
mapserver in the case they have less difficulty to figure how to define 
extent with this method. Or maybe this could just lead to confusion or 
maybe this could lead to some cool/crazy idea for futur enhacement.

Ishh! Round map!
Just kidding!

My 0,02$
Julien

Frank Warmerdam wrote:
> Steve Lime wrote:
> 
>> Gee, didn't mean to make this difficult. Guess I should've gone with the
>> camera view model when I started. But then we'd have to change things to
>> support the OGC specs. You can't win I guess. However, things being as
>> they are:
>>
>> Based on your alternatives it seems like 2 mirrors the current meaning
>> of an extent. You get that area plus a bit more. This was going to be an
>> issue regardless of how you define your AOI. What was your original
>> plan?
> 
> 
> Steve,
> 
> The issue is how we describe the portion of the earth that the map render
> will show.  Traditionally we did this with the EXTENT keyword with the
> implicit assumption that our mapview would be north up and unrotated (with
> respect to the coordinate system in play anyways).
> 
> My change was not to alter the concept of a rectangle to allow the view
> rectangle to be rotated.  My way of specifying the rectangle (center,
> size and rotaton) exactly and unambiguously defined the view rectangle.
> 
> We are only running into problems now (in my not-very-humble-opinion) 
> because
> we are trying to use an x/y min/max + rotation datastructure to define
> something it is illsuited to.
> 
>> I thought that to deal with the non-square pixel issue in the future
>> we'd probably have to set a flag that would alter the meaning of extent,
>> that is, you'd get extactly that extent albeit stretched a bit if
>> necessary. I'm not sure how that would play out with rotation. Probably
>> not that big of an issue since only the OGC WMS/WCS specs would leverage
>> that capability very often.
> 
> 
> My intention was that non-square aspect ratio pixels would be fine
> when going through the rotated view stuff since it will just remap stuff
> to a 1x1 fake pixel size anyways.
> 
>> As for placement of this new parameter. I guess the main MAP object is
>> fine. The WEB object is really overhead and could be removed. It's an
>> artifact of very early versions of MapServer that stored web
>> configuration as part of the HTML template files.
> 
> 
> The rotation is very closely related to the extent.  Together they
> define the view rectangle.  I strongly believe the rotation belongs where
> ever the extent is.  That would presumably mean in the mapObj, and in
> the .map file it would be in the general MAP block as well.
> 
> Daniel Morissette wrote:
>  > Actually, my understanding was that only #1 would maintain scale (and
>  > cellsize) from map to map.  With #2 or #3, the scale would vary for a
>  > given extent depending on the rotation angle, and predicting the
>  > resulting scale would be a complex calculation. However with #2 and #3 I
>  > believe the scale/cellsize would be constant from map to map as long as
>  > the rotation angle doesn't change, but would still be hard to calculate
> 
> I believe your assumptions here are correct Daniel.  I gather from the
> various discussions that we are essentially settling on option 1.  That is
> the view will be computed by essentially rotating the EXTENT box around
> the center of the extent box by the rotation amount.  This is an easy 
> enough
> form for me to handle, and I will do so now before I commit.  Likewise, I
> will change the keyword to ANGLE as suggested by Steve.
> 
> I have also looked a bit more at how the cgi mode mapserver works.  I would
> like to add some sort of rotation control here as well.  I don't quite 
> follow
> how all this stuff works now, but I was thinking something along the 
> line of
> an "maprot" keyword that could provide a rotation.  I also think it 
> would be
> nice in browse mode we could have rotation options much like we have 
> zoom in
> and zoom out options.  I don't think I am ready to address all that just
> now, unless it would be easy.  But I would at least like to be able to
> drive rotation from the URL.
> 
> Any objections to "maprot"?
> 
> Finally, I would like to thank everyone for the feedback.
> 
> Best regards,

-- 
------------------------------------------------------------
Julien-Samuel Lacroix            jlacroix at dmsolutions.ca
DM Solutions Group               http://www.dmsolutions.ca/
------------------------------------------------------------