[Xastir] Re: Bounding boxes

[Gerry Creager N5JXS]

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

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.

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

Registration and rectification based on 4 corners is usually adequate, 
especially if working on images as small as a quad (or quarter-quad) on 
a much larger map as a base.

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

Unit transformation, amongst other things must be observed.

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

If the metadata are there and in a consistent form it's pretty trivial.

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

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.

Period.

73, gerry