[Xastir-Dev] problem with drg geotiff maps

Curt Mills hacker at tc.fluke.com
Thu Nov 7 13:11:19 EST 2002


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.

-- 
Curt Mills, WE7U                    hacker_NO_SPAM_ at tc.fluke.com
Senior Methods Engineer/SysAdmin
"Lotto:    A tax on people who are bad at math!"
"Windows:  Microsoft's tax on computer illiterates!" -- WE7U
"The world DOES revolve around me:  I picked the coordinate system!"




More information about the Xastir-dev mailing list