[Xastir] US Topo GeoPDF?

[Tom Russo]

On Sun, Mar 18, 2012 at 12:34:09PM -0600, we recorded a bogon-computron collision of the <esarfl at gmail.com> flavor, containing:
> On Sun, Mar 18, 2012 at 10:32, Lee Bengston <lee.bengston at gmail.com> wrote:
> > On Sun, Mar 18, 2012 at 12:16 PM, Tom Hayward <esarfl at gmail.com> wrote:
> >> I just discovered the USGS US Topo map download site
> >> (http://nationalmap.gov/ustopo/index.html). In the past I have used
> >> USGS Topo quads in geotiff format, but these downloads are "GeoPDF".
> >> It doesn't appear Xastir supports this format. Did I overlook
> >> something? How difficult would this be to add?
> >>
> >> Tom KD7LXL
> >
> > Fyi, Tom Russo added a script a while back that converts the geopdf's to tiff.
> 
> Thanks, I didn't realize this problem had been solved. Unfortunately I
> have not been successful in building gdal for OS X. I'll have to try
> with Ubuntu later; OSS tends to build more smoothly there.
> 
> In the meantime, I've found a source for the classic GeoTiff USGS quads:
> http://libremap.org/data/
> 
> I notice two things about the GeoTiff files: the borders aren't
> cropped, and the datum is translated from NAD27->WGS84.
> 
> Where does the crop data come from for the GeoTiffs? I see
> geopdf2gtiff creates crop data, but I would need to get this script
> working to utilize this.

GeoTiff files that have associated "fgd" files (metadata) will be collar-clipped
by Xastir.  If the file is named according to the original USGS naming 
convention, there is a script called "mapfgd.pl" in the Xastir scripts 
directory that will generate the subset of lines of the FGD file that 
Xastir looks for.

If your files have all been renamed from the original USGS file names, and
they don't have associated FGD files, then you have to generate them yourself.
There are four lines in the FGD file that tell what the north, south, east and
west neatlines lat/lons are, and Xastir uses those to clip off the collar.

> I understand Xastir is fixed to WGS84 (like all of APRS). My SAR team
> reads UTM coordinates from the map, which in this case is NAD27. Not
> everyone has APRS capability (actually, it's just me :). This leaves
> me with no good way to plot coordinates in Xastir without first doing
> a datum conversion with some 3rd party software. Is there a better
> solution?

We have a similar problem in NM, where most USGS topo quads are still printed
in NAD27.  This problem is gradually going away as USGS topo sheets go away
and are replaced by on-demand printed maps, but as yet there is no simple
solution.  Xastir doesn't have a datum conversion facility (and the 
NAD27->NAD83 conversion library it *does* have is not strictly correct, as 
it does not use NADCON datum shift grids, so even if one were to try to 
code it in one would need to require PROJ.4 and its datum shift grids).

I just use an external converter (proj.4's "cs2cs" program, for which I wrote
a few simple one-line scripts for NAD27/NAD83 UTM and NAD27/NAD83 Lat/Lon
conversion.  I also wrote a very simple Qt program that uses proj.4 to do
simple UTM/LL conversions, and compiled it for Android as well (using 
Necessitas), so most of my field conversions are pretty quick and easy.  But
mostly the NAD27 problem is going away, as fewer and fewer old USGS topo sheets
are being used in the field. 
-- 
Tom Russo    KM5VY   SAR502   DM64ux          http://www.swcp.com/~russo/
Tijeras, NM  QRPL#1592 K2#398  SOC#236        http://kevan.org/brain.cgi?DDTNM
"And, isn't sanity really just a one-trick pony anyway? I mean all you get is
 one trick, rational thinking, but when you're good and crazy, oooh, oooh,
 oooh, the sky is the limit!"  --- The Tick