On Sun, Mar 18, 2012 at 12:34:09PM -0600, we recorded a bogon-computron collision of the <[email protected]> flavor, containing: > On Sun, Mar 18, 2012 at 10:32, Lee Bengston <[email protected]> wrote: > > On Sun, Mar 18, 2012 at 12:16 PM, Tom Hayward <[email protected]> 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 _______________________________________________ Xastir mailing list [email protected] http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir
