[Xastir] Re: Bounding boxes

[Gerry Creager N5JXS]

A couple of caveats about State Plane coordinates, and a little history.

The National Geodetic Survey created the State Plane Coordinate System 
to assist surveyors in performing local surveys on a plane.  Each 
coordinate plane was established for a given state.  Or, in the case of 
Texas, 5 separate SPC zones.  The idea is simple.  Planar geometry is 
easier than spherical geometry to understand and perform, and a lot of 
the surveyors out there were not well versed in spherical mathematical 
concepts.

Now, taking Texas as an example, we have 5 zones, and 3 referent 
measurements: US Foot Surveyor Foot, and meter; as well, we have 2 
horizontal datums:  NAD-27 and NAD-83.

Adding to the interesting aspects of this, our Texas Geographic 
Information Council has approved another mapping system that has minimum 
distortion across the bounds of the entire State.  Created by a 
Department of Transportation cartographer and GIS specialist named Steve 
Shackleford, this isn't his first foray into creating a Statewide 
projection for Texas, but, in my opinion, it was a better result than 
his first attempt... which was STILL superior to SPC for Texas.

Typically, SPCs use a Lambert Conformal projection for their projection 
system.  This tends to offer the least distortion, although generally, 
the zones are selected to help in minimizing the distortion.  Some SPCs 
use an Albers Equal Area projection and there are other outliers as well.

SPCs tend to be linear offset systems represented as a "Northing" and an 
"Easting" value.  Hence, it's an ordered pair of numbers, beginning at 
some arbitrary origin and proceeding from there.  GOTCHA!  the ordered 
pair may well have positive and NEGATIVE components.  All depends on the 
Origin and where it starts in relation to the State's borders.

All this to explain: The metadata must be complete, or any efforts to 
reproject the image will be problemmatic.

You need the following metadata as a minimum:
Measurement unit (US Foot, Survey Foot, Meter)
Projection (Lambert/Albers)
Central Meridian (or occasionally, Latitude)
Bounding Latitudes (or occasionally, Longitudes)
Point of Origin
*OFFSET* (another GOTCHA!: Some SPCs have a point of origin that appears 
reasonable, but then have an offset starting point for all their 
coordinates.  This allows the numbers to be more reasonable to work with 
for manual calculations)
Datum (NAD83/NAD27)

Note: There's no vertical datum associated with SPCs in general: They're 
a planar coordinate system and not well suited for inclusion of vertical 
information, although a lot of surveyors try.

Pedantically yours,
Gerry

Curt Mills, WE7U wrote:
> On Tue, 7 Oct 2003, Tom Russo wrote:
> 
> 
>>Hate to drag this thread on too long, but you've tickled my interest
>>with your problem, and inspired me to dig for more information than
>>I'd normally bother digging for.
> 
> 
> Good thing you dug too!  It's been too long since I've been into
> that code, and you had some good info about it.
> 
> 
> 
>>>Doable, but not a
>>>matter of just setting up an FGD file or tweaking the geotiff metadata.
>>
>>Turns out it was probably incorrect of me to say that Xastir wasn't
>>set up to use anything but UTM projected tiff files, and while I still
>>claim that "tweaking" the geotiff metadata isn't enough, "twiddling"
>>the data *might* be enough. (see
>><http://catb.org/esr/jargon/html/F/frobnicate.html> for the distinction)
>>
>>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.
> 
> The code should be able to be extended to handle other types of
> geoTIFF files, but that just wasn't the original goal.
> 
> 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 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.
> 
> 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.
>