MS RFC 5: MapServer Horizon Reprojection Improvements

[Daniel Morissette]

Frank Warmerdam wrote:
> Folks, 
> 
> Yet another promised RFC.  Really just a bug fix, but substantial 
> enough that I thought an RFC discussion might be appropriate. 
> 

That's a tough one, good luck! See a few comments/questions below...


> 
> Area Features
> -------------
> 
>  o Each ring will be treated distinctly, without regard to the other rings. 
>    This means no there is no assurance that an inner ring will remain 
>    completely within the outer ring after clipping.  In particular, where
>    the horizon passes through an area and a hole in the area, it is likely 
>    that the hole edge will touch over even overlap the outer area edge a bit.
>    Genreally this should not matter much in the MapServer context since a
>    simple scanline rasterization (winding number based) technique is used. 
>    So polygon "correctness" is not paramount.  
> 
>  o A similar technique to that for lines is used to interpolate the edge
>    vertices when clipping is to be applied. 
> 
>  o For polygons there will be two (or possibly 4, 6, 8...) interpolated
>    horizon points.  These will be connected with a straight line segment. 
>    For very large polygons spanning a significant portion of the horizon
>    (ie. dozens of degrees of arc of the horizon) this will result in part of
>    the circle of the horizon getting clipped off.  Optionally an iterative 
>    method could be applied to address this curvature issue (not priced into
>    this proposal). 
> 

My experience trying to clip polygons has been that with odd shaped 
polygons it's hard to maintain the polygon's integrity. I assume you're 
aware that it may not be as simple as it seems to do the clipping in 
some cases. (Well, it was several years ago that I did that, maybe it's 
not that hard and I had just done something wrong too.)

> 
> Tolerances
> ----------
> 
> MapServer will need make a decision on how detailed to get when doing the
> iterative horizon determination.   The tolerance will be fixed as half the
> size of a pixel in the current map rendering.   In normal map drawing this
> should mean that the final rendering is effectively exact. 
> 
> However, communicating the tolerance into msProjectShape() will require
> substantial work as the msProjectShape() function does not normally know
> anything about the map or current rendering information.  To communicate 
> this information to msProjectShape(), I will add a transformation options
> structure with this information (and possibly other flags controlling 
> transformation) which will be passed into msProjectShape().  If NULL 
> particular defaults will be used.  
> 
> All appropriate uses of msProjectShape() will need to be updated to reflect
> this change, and to setup the transformation options information ahead of
> time.  layerObj level PROCESSING options will also be provided to control
> (override) the default transformation options. 
> 

Will the setup of the transformation structure result in overhead for 
code that calls msProjectShape() multiple times? Hopefully the structure 
can be cached.

How will this transformation struct relate to the map rotation 
parameters? Should an attempt be made to merge this tolerance and the 
rotation parameters in the same structure? I don't know that code too 
well, so I'm not sure if it is possible or makes sense at all to merge 
both, but I thought I would ask anyway.

Daniel
-- 
------------------------------------------------------------
  Daniel Morissette               dmorissette at dmsolutions.ca
  DM Solutions Group              http://www.dmsolutions.ca/
------------------------------------------------------------