[Mapserver-users] Globe View with Orthographic Projection

[Frank Warmerdam]

Harald Wehr wrote:
> Many thanks for the changes you have made! Things become better and 
> better but I have discovered other things that seem to be strange too.
> 
> As in my first mail, I put the example under this url:
> 
> http://www2.hs-harz.de/~hwehr/mapserver/
> 
> Picture 4 is well, with the extent of test4.mapfile:
> EXTENT  -6300000 -6300000 6300000 6300000
> 
> When I change the extent to something near the radius of the earth the 
> output is really strange (picture 5).
> 
> Same happens when I try to display the polar region. Picture 6 is well 
> for the extent of: EXTENT  -6500000 -6500000 6500000 6500000
> 
> Changing this to EXTENT  -6300000 -6300000 6300000 6300000 results in 
> picture 7 which is almost all blank.
> 
> So what do you think happens here? As my programming skills in C are 
> really bad I cant support you with some code. But of course I will be 
> able to do further tests if you wish.
> 
> Thanks in advance!

Harold,

Ugg ... very difficult issues.   OK, I have dug into these and made a
number of changes in mapresample.c.  They all relate to the code that
decides what portion of the source image should be loaded into and used
fed into the output image resampling operation.

One category of problems is the code that computes the bounds of what is
needed from the input raster.  That code was transforming points all all
around the edge (11 points along each edge) from destination to source
coordinates.  In many of your cases all of these fail to transform because
they are beyond the horizon.  When this occurs the code fallsback to loading
the whole source image (though possibly at a reduced resolution).  However,
if any of the points do transform it can happen that they are not a
very good representation of the total area of the source image that
should be loaded.  That's what happened with your cases 5 and 7.

To correct this I added logic such that if *any* of the edge points fail
to transform, the code will rerun the operation but with a grid of points
(121) over the output image.  This "internal sampling" is intended to
discover the areas of the output image that can be transformed back to the
source, and roughly what the edges would be in the source image.

However, because the grid is very coarse (11x11) the code may do a poor
job of discovering the real edges.  I could add a whole much of logic to
try and trace along the edge but this would be code and processor intensive.
So, instead I just grow the discovered region by 10% in each direction.
This would usually catch everything.  However, in your case it does not
always get all the appropriate parts of the source image since (due to
horizon effects) small areas on the horizon can reflect large areas on
the source image.  The net result is that all this "grid" logic still
doesn't work properly, though it works much better than what you were
getting.

To work around this edge estimation problem in pathalogical
"world mapping" situations such as you are doing I added a new
mapfile directive as a way to say that the whole source image
should be loaded.  This will short circuit all the computations
of the source window and just assume the whole thing should be used.

eg.
PROCESSING "LOAD_WHOLE_IMAGE=YES"

Well, this was a substantial improvement, but I would still see
"cracks" on the date line.  I looked into this, and didn't exactly
figure out what was going wrong.  However, I did determine it
related to the fact that the source image was being decimated
during loading.  My source file was 2048x1024, but the map was
only 400x400 so the loading code assumes that loading at 800x800
(or perhaps 800x400 in this case) would be sufficient to get
the data needed for the resampling.  That is, we try to load the
source image data at twice the resolution of the output image.

But for reasons that escape me, this means that output pixels at
the very edge of the input image (at the dateline) may be considered
"not loaded" resulting in the crack.  Failing to understand the
problem properly, I have just added a hack to allow the user
to request the source image be loaded at full resolution.

eg.
PROCESSING "LOAD_FULL_RES_IMAGE=YES"

I have committed the changes to mapresample.c and you should be able to
see the improved results.  Then if you add the above processing directives
you should get fully correct results. I hate the fact that the above
directives are necessary in some situations ... it puts an extra onus on
the mapserver application building to understand internal issues.  But I
can't seem to *practically* work around it.  Nevertheless, the grid and other
improvements should help quite alot in bad cases and be sufficient in not quite
so bad cases as yours.

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