[Xastir] Re: Bounding boxes

[Tom Russo]

On Mon, Oct 13, 2003 at 03:16:23PM -0700, a Mr. Richard Feyler of Fort Lee, New Jersey <hacker at tc.fluke.com> writes 'Dear Rosanne Rosannadanna':
> On Tue, 7 Oct 2003, Tom Russo wrote:
> > Tom Russo wrote:
> > > Doable, but not a
> > > matter of just setting up an FGD file or tweaking the geotiff metadata.
> > [...]
> > Xastir uses the libgeotiff functions GTIFImageToPCS and
> > GTIFProj4ToLatLong functions to map tiff file contents to the screen,
> > and prior to that uses the GTIFGetDefn function to extract projection
> > data from the geotiff metadata.  If (that's a big if) the geotiff file
> > contains the correct metadata to define the projection then it could
> > conceivably be the case that Xastir would read any old geotiff,
> > regardless of the projection.
> 
> Be aware that the code was written exclusively to handle the case of
> USGS geoTIFF DRG topo files, which have the white map collar which
> needs cropping, and are in UTM projection, so they need to be
> stretched a bit to make them into rectangles for our lat/long
> projection.

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

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.  

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

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.

> I'm off doing other things in the code now, but I'd be an available
> resource should someone else want to tackle this any time soon.

And it looks like it'll be a few more weeks till any of those changes
show up in anon CVS anyway :-(

> Another thing to keep in mind is that a couple of the developers are
> working on integrating the GDAL library with Xastir.  If that
> library provides all we need for other sorts of geoTIFF files, it
> might be better to wait for that to get done rather than hacking on
> the old code.

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!

-- 
Tom Russo   KM5VY    QRPL #1592   K2#398    http://www.swcp.com/~russo/
Tijeras, NM DM64ux   SOC #236     AHTB#1    http://www.qsl.net/~km5vy/
 "Evil.  Good.  These are moral absolutes that predate the fermentation of
  malt and fine hops.  If beer had been invented first, there'd be only
  'Kinda nice' and 'Pretty cool'."  
       -- Season 4, Buffy the Vampire Slayer, "Beer Bad"