[Xastir-Dev] problem with drg geotiff maps

[J. Lance Cotton]

No problem on the delay. For Curt and anyone else interested, I have 
posted a summary of my tests at:
http://www.lightningflash.net/~jlc7944/xastir-shots/

The upshot is :
* The DRG-E files will draw over the correct spots if you remove the 
.fgd file, but will overflow their boundaries and

* The DRG-E files will draw over the correct spots with decent boundary 
trimming (as far as I can tell, which isn't very far: correct me!) if 
you use a .fgd file taken from 'real' DRG files from USGS.

Basically: get rid of the .fgd file from the DRG-E!!

The reason I couldn't get the maps to display was that I wasn't deleting 
the map_index.sys file from my ~/.xastir/conf/ directory and so my 
changes to the .fgd weren't being taken into account. After I started 
removing the index file between restarts during the testing, it was 
working as Curt had described.

73 Lance KJ5O

Curt Mills wrote:

> Apologies.  Looks like I composed this several days ago and then got
> busy and didn't send it.
>
> On Fri, 1 Nov 2002, Curt Mills wrote:
>
>
> >Just tried it.  The stupid things tilt, but other than that they are
> >displayed roughly ok.  They don't quite fit within the borders of
> >the 24k overlay shapefile, which showed me the tilt quickly.
> >
> >So, it looks like FGD's are recommended for DRG-E's as well.  With
> >the FGD's I sent you, the map pixels overflow the 24k boundaries on
> >all sides by about equal amounts, which makes me think that either
> >the scaling is slightly off, or there are extra pixels attached to
> >all sides which aren't accounted for in the FGD or in the geoTIFF
> >tags.
>
>
> Are you seeing any DRG-E's at all on your screen yet?  It bothers me
> that you couldn't replicate what I'd done.
>
> Comparing the real DRG that you sent me to a DRG-E for the same
> area, the DRG-E is definitely getting scaled improperly.  That's why
> it's overflowing the 24kgrid.shp map overlay boundaries.
>
> DRG-E:  SW corner (representative) shows that the map corner is
> approx. 1180 ft too far west, 924 ft too far south.  NE corner shows
> the map corner 1053 ft too far north, 1086 ft too far east.  These
> errors are significant.  It appears to be a simple scaling problem,
> perhaps caused by incorrect numbers in the FGD file or by incorrect
> geoTIFF tags.
>
>
> DATUM TRANSLATION CHANGE:
> -------------------------
> To anyone who cares:  I changed Xastir's method of datum translation
> yesterday from using Proj.4 routines to using datum.h/datum.c
> routines, part of the Xastir sources.  The total difference at one
> point I checked was 1 meter in one direction, 2 meters in another,
> for a total 1.1414 meter shift in where your
> topo maps get displayed.  Since each pixel of a 24k topo map is
> about 2.4 meters, I didn't figure anyone would care.  Who knows, the
> new method may be more accurate than the old...
>
> This change reduces our dependency on Proj.4 (but doesn't remove it
> altogether), and gives us much more leeway to convert datums for
> maps from all over the world.  Proj.4 doesn't implement datum
> translation very completely, and wasn't intended to do so.
>

-- 
J. Lance Cotton, KJ5O
http://map.findu.com/kj5o-14
joe at lightningflash.net