[Xastir] Re: Bounding boxes

[Tom Russo]

On Tue, Oct 14, 2003 at 07:59:40AM -0500, a Mr. Richard Feyler of Fort Lee, New Jersey <gerry.creager at tamu.edu> writes 'Dear Rosanne Rosannadanna':
> Tom Russo wrote:
> >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:
> >>
> >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.
> 
> Pedantically, any time a scan is done on a paper map, there is a problem 
> associated with stretching, as well as with rotation.  Further, the 
> quarter quads serving as the origins of the DRG are *not* simple Lon/Lat 
> rectangles, although they're close.  I don't hhave any paper maps here 
> (I'll check at work) but memory tells me they're in a mercator 
> projection.  The distortion associated with a mercator projection in a 
> quarter quadrangle is so small as to appear rectilinear.  But it's not. 
>  Registration and rectification remain mandatory.

Of course, you're right.  The USGS maps represent a 7.5' chunk in each 
direction, but they are indeed projected using the UTM and naturally will
have the distortion you both have mentioned.  I used the weasel-words "usually
mostly a rotation" and "not much of a stretching" coz down here where I live
the maps are nearly rectangular even after the lat-lon wedge is projected, but
of course it's not correct of me to say that they're rectangles.  

I was misreading how the code works, and Curt's cleared some of that up in his 
followups.  I dug around again last night and see what he means about the 
clipping and stretching being done in the same block of code.  But I still 
think that the way it's being done, combined with small-area maps that only 
need a little transforming to stretch them into Lat/Lon would probably work 
OK, if not entirely correctly.

As I read the comments in the code, the way the individual pixels of the 
geotiff file are plotted is not *pedantically* correct, but practically it's
fine --- for speed, each scan line of the geotiff image is mapped onto a 
corresponding rotated/stretched line in the lat/lon system used for plotting 
in the xastir window.  That's not strictly correct, but on these scales I 
can't imagine the precision lost would make it worthwhile to do all the extra 
calculations to get it strictly correct (it already takes an age or more to 
load all the topos I need to cover my local area at high zoom levels, I 
wouldn't want it any slower!).  I suspect that if the same technique were 
applied to the state plane system maps Tyler started this discussion with, if 
the corner points were converted correctly (including unit conversion, datum 
conversion  (in Tyler's case there was no datum conversion needed), and the
conversion from LCC-2SP to Lat/Lon), that the stretching and rotation 
operations would produce no worse an imprecision than is already there for the 
UTM - Lat/Lon conversion.  In fact, while I'd have to go back and read more
about the Lambert projection, I think the nature of the projection might make
it *less* imprecise to map lines in projected image onto lines in the lat/long
system than it is for UTM-Lat/Lon.

[gdal] 
> >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!
> 
> OH NO! NOT ANOTHER SOAPBOX OPPORTUNITY!
> 
> If it doesn't have metadata, even if you can find what might pass as 
> sufficient information, it remains nothing more than an otherwise 
> undocumented picture.

I agree.  The web site that distributed those geotiff files did have a 
complete exposition of the metadata, but as a separate human-readable PDF,
not in the geotiff metadata keys, even while saying they were georeferenced
images.  That's a  pretty big goof IMNSHO, but could be corrected with a 
little work.  Just have to know the arcana of geotiff keys and geotifcp's 
metadata file format well enough to encode the projection parameters in the 
PDF back into the geotiff files.  There weren't that many to deal with (IIRC, 
the units (us-survey feet), the projection (2-standard parallel version of 
lambert conformal conic), the relevent parallels and meridian, and the false 
easting and northing, plus the relevant codes to specify that it was a 
user-defined projection rather than one of the standard numbered PCS's).

-- 
Tom Russo   KM5VY    QRPL #1592   K2#398    http://www.swcp.com/~russo/
Tijeras, NM DM64ux   SOC #236     AHTB#1    http://www.qsl.net/~km5vy/
 "The older I grow the more I distrust the familiar doctrine that age
  brings wisdom." -- H.L. Mencken