[Xastir] Re: Bounding boxes

[Curt Mills, WE7U]

On Mon, 13 Oct 2003, Tom Russo wrote:

> Um... since the geotiff files are originally scanned from paper maps
> that are lat/lon rectangles, and small ones at that, isn't it usually
> the case that the transformation is mostly a rotation, and not much of
> a stretching operation?

No.  You're thinking of the paper USGS maps that you buy.  Take a
look at one of the DRG files in a normal TIFF viewer.  They have been
distorted into a UTM projection.  I don't think the paper maps were.
I have a few USGS quads in my SAR pack.  I should get that out and
look at them again, but I seem to remember the edge was small and
even around (except the bottom margin was bigger).

These DRG files are narrow at the top, wide at the bottom, and have a
rotation to them as well.  The top and bottom edge of them are also
curved.


> For example, a UTM grid plotted over a topo
> map is pretty much rectilinear, but at a slight angle to the N/S/E/W
> lines.  It's only when you get pretty far (i.e. more than a zone
> width!) from the central meridian and on pretty long scales that the
> deformation from rotated rectangular becomes apparent.

And the only places that gets to be a problem are probably in the 12
degree-wide UTM zones north of Norway.  Perhaps the 9 degree zones
have a lot of trouble as well, but the regular 6 degree zones should
be fine (most of the world).


> As I read the code, all that I could tell it was doing was converting the
> corner coordinates of the clipped region to lat/lon and make sure it
> didn't plot pixels that were outside the clipping area.  

I wrote the code, so I remember the major points about what it did.
It does rotation and stretching of pixels as it is drawing each pixel
to the screen.  It definitely has to stretch the image in varying
amounts as it goes from top to bottom on the image as it is quite
noticeable if you don't.  Nothing lines up.


> > We should be able to handle state-plane coordinate systems and
> > cropped geotiff's.  It might be good to separate out the cropping
> > and the stretching code into separate functions, as well as the
> > datum translation code.  It might then be easier to extend the code
> > to other types of files.
> 
> I'm going to need to dig some more, then, because from what I read of
> the code it looked like the transformation from image coordinates to
> lat/lon was all handled through libgeotiff, and it was pretty general.
> If Tyler's map source had put the proper projection metadata into the
> tiff files to begin with, I have a feeling he wouldn't have had any
> trouble.

We only check for two or three possibilities for datum in order to
do a datum translation for the corner points (cropping points).
Basically we're looking for WGS84/NAD83.  If we find NAD27, we do
a translation to WGS84.  It shouldn't be hard to make that code
more general there, to handle more datums, but we'd need to be able
to handle other types of units as well throughout the code, like
state-plane (feet) and perhaps UTM coordinates (meters)?


> The cropping of the geotiff file *seems* to already be handled
> separately, and is only done if there's an fgd file.  The
> transformation done through libgeotiff is based entirely on the
> metadata encoded within the geotiff file --- of which the state-plane
> maps that started the whole thing have none.  I haven't read the code
> that carefully, but honestly it looked like the cropping *was* already
> sorta separate.

It might have gotten separated at some point.  Can't recall now.
Initially it was all in the one (big) routine.  That code might not
be pretty, but it was my first big input to the Xastir project, and I
was pretty proud of it at the time.  I got better with more C-coding
experience later in the project.


> It'll be pretty cool if that can happen.  I've used GDAL to import files
> of all make and model into GRASS once upon a time, and it was pretty slick.
> But it sure as heck won't fix broken geotiff files with no metadata in them!

;-)

It _will_ give us more options for maps.  117 isn't enough...

Curt, WE7U.				archer at eskimo.com
http://www.eskimo.com/~archer
  Lotto:  A tax on people who are bad at math. - unknown
Windows:  Microsoft's tax on computer illiterates. - WE7U.
The world DOES revolve around me:  I picked the coordinate system!"