[Mapserver-dev] Rotated Map Rendering

[Steve Lime]

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?

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.

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.

Steve

>>> Frank Warmerdam <warmerdam at pobox.com> 5/19/2004 2:26:59 PM >>>
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,
-- 
---------------------------------------+--------------------------------------
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