Longstanding Map Overlay Problem Solved! [message #59231] |
Fri, 14 March 2008 14:00  |
David Fanning
Messages: 11724 Registered: August 2001
|
Senior Member |
|
|
Folks,
For well over a year I have been pondering a map overlay problem.
The problem appears when trying to overlay continental outlines
on a GeoTIFF image. If you use the UV_BOX that is returned
in the map projection structure from MAP_PROJ_INIT to set up
a data coordinate space, then the outlines are just ever so
slightly wrong. However, it you use the UV_BOX that is
returned from MAP_PROJ_IMAGE, even if you don't warp the
image, the results are absolutely correct. The problem
(and solution) is described here.
http://www.dfanning.com/map_tips/tiffoverlay.html
With a great deal of help from Matt Savoie, I have now
identified the reason these two UV_BOXES are slightly
different. The answer comes down to a limitation in
MAP_PROJ_INIT.
Specifically, the limitation is that the LIMIT keyword
to MAP_PROJ_INIT can only accept a four-element vector
that describes two opposite corner points on the image.
The assumption is that the other two opposite corner
points can also be determined by this method. Unfortunately,
that is not a valid assumption for images that are in
some type of map projection already.
Rather, we need to use an 8-element LIMIT vector to
describe the location of a projected image in lat/lon
space. Something of this sort is available for MAP_SET,
although you must specify the left, top, right, and
bottom of the image, rather than its corners. But
if you try to use an 8-element LIMIT vector with
MAP_PROJ_INIT, it will accept it without argument, it
will just *completely* ignore its values.
Fortunately, MAP_PROJ_IMAGE *does* calculate the 8-element
limit correctly, and so does return the correct UV_BOX
to set up the data coordinate space. But, as Matt discovered,
it is also possible to set the data coordinate space directly
from values calculated from geotiff information in the file.
So, now we have two solutions, and it is only the most
commonly used method that is wrong. :-)
Anyway, I can't tell you how happy I am to know the reason
for this longstanding discrepancy and I look forward to
submitting a feature request to ITTVIS to get this cleared up.
Cheers,
David
--
David Fanning, Ph.D.
Fanning Software Consulting, Inc.
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Sepore ma de ni thui. ("Perhaps thou speakest truth.")
|
|
|