MS RFC 5: MapServer Horizon Reprojection Improvements

[Steve Lime]

Fine with me. +1...

>>> Frank Warmerdam <warmerdam at POBOX.COM> 10/04/05 11:50 AM >>>
On 9/19/05, Daniel Morissette <dmorissette at dmsolutions.ca> wrote:
> 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.)

Daniel,

I can see a couple of difficult issues maintaining the polygon integrity.
One is that fact that I am planning (in this simplified approach) to just
attach one line segment from the point where we go over the horizon
to the point where we come back over the horizon.  They they are a long
distance apart it will become evident that the horizon arc is not being
tracked.

The second is that failure to track the horizon could result in self
intersection.  This problem I don't consider too serious because it is very
rare, and because self intersecting polygons are not particularly bad for
mapserver since it uses a scanline rasterizer.

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

I don't forsee too much overhead since I would expect that
msDrawShape() will compute the tolerance once per layer, not
once per shape.  And the computation is quite simple as long as the
mapObj is available.

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

The map rotation information is stored within the projectionObj that
is already passed into msProjectShape().  On reflection, it might make
sense to add the map tolerance into the projectionObj as well.  The
major benfit of this is that no changes to the API would be required.

Consider the proposal ammended to this approach.

Given this ammendment, are there any other concerns about the
proposal?  Anyone care to vote?

I will now vote +1 to get things rolling. :-)

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