Georeferencing Maps [was Re: GPS and airspace]

[John Clonts]

Hello Tom,

Thanks for the tips. I found that when I use the "raw data" it does work as
you say (http://aviationtoolbox.org/raw_data/FAA/sectionals/current/). Is
this what you are using?

But I have trouble when I try to use one of Kyler's "processed images" from
https://aviationtoolbox.org/Members/kyler/tools/map_explorer
I have the problems that J.G. diagnoses below.

Kyler, are you out there? does any of that make sense to you?

(The example that I was using was
<https://aviationtoolbox.org/Members/kyler/tools/map_image?
scale=50&image_format=GeoTIFF&lr_Y=-
792315.0&lr_X=352633.0&ul_X=250233.0&ul_Y=-715515.0>)

Cheers,
John Clonts
Temple, Texas
N7NZ




"Tom Jackson" > wrote in message
news:KnHDc.190504$Ly.84959@attbi_s01...
> I'm using version 3.95.3e of Oziexlplorer (commercial version, not demo.)
>
> I download the TIF file from Kyler's website into a folder.
>
> In Ozi, I choose file|Import Map|Single DRG (Or, all DRG . . .) It asks a
> few questions, such as file location, etc. and automatically imports and
> calibrates the image.
>
> When I first got Ozi, it didn't work so I e-mailed them. Des, the
creator,
> e-mailed me back that he had updated the program to handle these types of
> files, and that I should download the most current version. I did, and it
> worked great. When I download waypoints (i.e., airports, using
> http://navaid.com/GPX/) it shows them almost exactly on top of the ones
> depicted on the map. Some are off slightly, but I don't use it for any
real
> navigation - just for fun.
>
> I have actually used it a few times in the plane, works well as a moving
> map. Will automatically pan from one sectional to the other, as I cross
> boundries. The Terminal charts are also geo-referenced, and Ozi can
import
> them as well. Can draw routes, etc. or download them from the GPS. I use
a
> simple Garmin GPS III (not the Pilot version.)
>
> "John Clonts" > wrote in message
> ...
> >
> > "Tom Jackson" > wrote in message
> > news:pw6Dc.95742$2i5.90727@attbi_s52...
> > > Try Oziexplorer (www.oziexporer.com,) and scanned FAA sectionals
> provided
> > by
> > > Kyler Laird at aviationtoolbox.org.
> > >
> > > The sectionals are "geo-tiffs" and Oziexplorer can import them and
> > > automatically scale them to the proper lat/lon.
> > >
> >
> > Have you actually done this? It didn't work for me-- the georeferencing
> nor
> > the image display. I posted to the Ozi-Users email list and got the
> > response below.
> >
> > I would sure like to get it to work, so if you have some tips please let
> me
> > know at jclonts AT hot DOT rr DOT com.
> >
> > Cheers,
> > John Clonts
> > Temple, Texas
> >
> >
> > Date: Sun, 20 Jun 2004 19:05:18 -0000
> > From: "rwcx183" <xyzzy>
> > Subject: Re: GeoTiff support?
> >
> > John,
> >
> > There's more than 1 problem with what you're trying to do. Firstly,
> > the Geotiff tags for this image specify that the image is in Lambert
> > Conformal Conic projection and Ozi cannot (to my knowledge) handle
> > that projection on import. You can try to use Albers (equal area) as
> > an alternative, since it has the same set of required parameters.
> > That sometimes results in acceptable accuracy, but sometimes not
> > (this case). You can also manually calibrate the map image using the
> > just the upper left and lower right corners as cal points. You will
> > have to convert the lambert grid coordinates for the corners to
> > lat/lon or UTM first though, since Ozi doesn't allow specifying
> > coordinates in Lambert grid. That Ozi does not support Lambert
> > Conformal Conic projection on import, is the most glaring omission,
> > in an otherwise very capable program. That and the non-support of
> > any linear unit besides meters, for georef coordinates. Here's the
> > Geotiff dump of the georeferencing info for your image:
> >
> > Geotiff_Information:
> > Version: 1
> > Key_Revision: 1.0
> > Tagged_Information:
> > ModelTiepointTag (2,3):
> > 0 0 0
> > 250233 -715515 0
> > ModelPixelScaleTag (1,3):
> > 128 128 0
> > End_Of_Tags.
> > Keyed_Information:
> > GTModelTypeGeoKey (Short,1): ModelTypeProjected
> > GTRasterTypeGeoKey (Short,1): RasterPixelIsArea
> > GTCitationGeoKey (Ascii,8): "unnamed"
> > GeographicTypeGeoKey (Short,1): GCS_NAD83
> > ProjectedCSTypeGeoKey (Short,1): User-Defined
> > ProjectionGeoKey (Short,1): User-Defined
> > ProjCoordTransGeoKey (Short,1): CT_LambertConfConic_2SP
> > ProjLinearUnitsGeoKey (Short,1): Linear_Meter
> > ProjStdParallel1GeoKey (Double,1): 38.6666667
> > ProjStdParallel2GeoKey (Double,1): 33.3333333
> > ProjFalseEastingGeoKey (Double,1): 0
> > ProjFalseNorthingGeoKey (Double,1): 0
> > ProjFalseOriginLongGeoKey (Double,1): -100.583333
> > ProjFalseOriginLatGeoKey (Double,1): 38
> > End_Of_Keys.
> > End_Of_Geotiff.
> >
> > Projection Method: CT_LambertConfConic_2SP
> > ProjFalseOriginLatGeoKey: 38.000000 ( 38d 0' 0.00"N)
> > ProjFalseOriginLongGeoKey: -100.583333 (100d35' 0.00"W)
> > ProjStdParallel1GeoKey: 38.666667 ( 38d40' 0.00"N)
> > ProjStdParallel2GeoKey: 33.333333 ( 33d20' 0.00"N)
> > ProjFalseEastingGeoKey: 0.000000 m
> > ProjFalseNorthingGeoKey: 0.000000 m
> > GCS: 4269/NAD83
> > Datum: 6269/North American Datum 1983
> > Ellipsoid: 7019/GRS 1980 (6378137.00,6356752.31)
> > Prime Meridian: 8901/Greenwich (0.000000/ 0d 0' 0.00"E)
> > Projection Linear Units: 9001/metre (1.000000m)
> >
> > Corner Coordinates:
> > Upper Left ( 250233.000,-715515.000)
> > Lower Left ( 250233.000,-792315.000)
> > Upper Right ( 352633.000,-715515.000)
> > Lower Right ( 352633.000,-792315.000)
> > Center ( 301433.000,-753915.000)
> >
> > Now, to the obvious problem that you're seeing. I ran the image
> > through a tiffinfo utility and discovered the problem. Here's what
> > tiffinfo shows:
> >
> > TIFF Directory at offset 0x15ff3e
> > Image Width: 800 Image Length: 600
> > Bits/Sample: 8
> > Sample Format: unsigned integer
> > Compression Scheme: None
> > Photometric Interpretation: RGB color
> > Samples/Pixel: 3
> > Rows/Strip: 10
> > Planar Configuration: separate image planes
> > Tag 33550: 128.000000,128.000000,0.000000
> > .
> > .
> >
> > It's that Planar Configuration setting of "separate image planes"
> > that is confusing Ozi. Ozi wants to see "single image plane". As
> > Dave already pointed out, you can load and save the image using a
> > general purpose graphics editing program and that will correct that
> > situation. You will still need to take care of the projection
> > problem, one way or another, though.
> >
> > J.G.
> >
> > P.S. Here's the upper left coordinate in lat/lon:
> >
> > N 31Deg 31Min 3.9Sec latitude
> > W 97Deg 57Min 13.1sec longitude
> >
> > For the lower lower right, it's:
> >
> > N 30Deg 47Min 50.2Sec latitude
> > W 96Deg 54Min 31.8Sec longitude
> >
> >
> >
> >
> >
>
>

[Kyler Laird]

"John Clonts" > writes:

>Thanks for the tips. I found that when I use the "raw data" it does work as
>you say (http://aviationtoolbox.org/raw_data/FAA/sectionals/current/). Is
>this what you are using?

>But I have trouble when I try to use one of Kyler's "processed images" from
>https://aviationtoolbox.org/Members/kyler/tools/map_explorer
>I have the problems that J.G. diagnoses below.

>> > TIFF Directory at offset 0x15ff3e
>> > Image Width: 800 Image Length: 600
>> > Bits/Sample: 8
>> > Sample Format: unsigned integer
>> > Compression Scheme: None
>> > Photometric Interpretation: RGB color
>> > Samples/Pixel: 3
>> > Rows/Strip: 10
>> > Planar Configuration: separate image planes
>> > Tag 33550: 128.000000,128.000000,0.000000
>> > .
>> > .
>> >
>> > It's that Planar Configuration setting of "separate image planes"
>> > that is confusing Ozi. Ozi wants to see "single image plane".

Ah ha! That was causing problems for ImageMagick too. I just didn't
realize that's what was doing it.

http://www.remotesensing.org/gdal/frmt_gtiff.html

INTERLEAVE=[BAND,PIXEL]: By default TIFF files with band
interleaving (PLANARCONFIG_SEPARATE in TIFF terminology) are
created. These are slightly more efficient for some purposes,
but some applications only support pixel interleaved TIFF
files. In these cases pass INTERLEAVE=PIXEL to produce pixel
interleaved TIFF files (PLANARCONFIG_CONTIG in TIFF
terminology).

So...I added "INTERLEAVE=PIXEL" and now tiffinfo reports this.
TIFF Directory at offset 0x580a1e
Image Width: 1600 Image Length: 1200
Bits/Sample: 8
Sample Format: unsigned integer
Compression Scheme: None
Photometric Interpretation: RGB color
Samples/Pixel: 3
Rows/Strip: 1
Planar Configuration: single image plane
ImageMagick displays a beautiful image now too.

Does that solve the problem you had?

Thank you for the report.

--kyler

[John Clonts]

"Kyler Laird" > wrote in message
...
> "John Clonts" > writes:
>
> >Thanks for the tips. I found that when I use the "raw data" it does work
as
> >you say (http://aviationtoolbox.org/raw_data/FAA/sectionals/current/).
Is
> >this what you are using?
>
> >But I have trouble when I try to use one of Kyler's "processed images"
from
> >https://aviationtoolbox.org/Members/kyler/tools/map_explorer
> >I have the problems that J.G. diagnoses below.
>
> >> > TIFF Directory at offset 0x15ff3e
> >> > Image Width: 800 Image Length: 600
> >> > Bits/Sample: 8
> >> > Sample Format: unsigned integer
> >> > Compression Scheme: None
> >> > Photometric Interpretation: RGB color
> >> > Samples/Pixel: 3
> >> > Rows/Strip: 10
> >> > Planar Configuration: separate image planes
> >> > Tag 33550: 128.000000,128.000000,0.000000
> >> > .
> >> > .
> >> >
> >> > It's that Planar Configuration setting of "separate image planes"
> >> > that is confusing Ozi. Ozi wants to see "single image plane".
>
> Ah ha! That was causing problems for ImageMagick too. I just didn't
> realize that's what was doing it.
>
> http://www.remotesensing.org/gdal/frmt_gtiff.html
>
> INTERLEAVE=[BAND,PIXEL]: By default TIFF files with band
> interleaving (PLANARCONFIG_SEPARATE in TIFF terminology) are
> created. These are slightly more efficient for some purposes,
> but some applications only support pixel interleaved TIFF
> files. In these cases pass INTERLEAVE=PIXEL to produce pixel
> interleaved TIFF files (PLANARCONFIG_CONTIG in TIFF
> terminology).
>
> So...I added "INTERLEAVE=PIXEL" and now tiffinfo reports this.
> TIFF Directory at offset 0x580a1e
> Image Width: 1600 Image Length: 1200
> Bits/Sample: 8
> Sample Format: unsigned integer
> Compression Scheme: None
> Photometric Interpretation: RGB color
> Samples/Pixel: 3
> Rows/Strip: 1
> Planar Configuration: single image plane
> ImageMagick displays a beautiful image now too.
>
> Does that solve the problem you had?
>
> Thank you for the report.
>

Kyler,

Thanks that does solve the image display problem!

The other problem remains however: the georeference information is not read
in successfully by Oziexplorer:

The example which works is e.g. the San Antonio Sectional at
http://aviationtoolbox.org/raw_data/FAA/sectionals/current/San%20Antonio%2073%20North.tif
:
Its listgeo info is:
Geotiff_Information:
Version: 1
Key_Revision: 1.0
Tagged_Information:
ModelTiepointTag (2,3):
0 0 0
-364619.149 238513.594 0
ModelPixelScaleTag (1,3):
63.781518 63.781518 0
End_Of_Tags.
Keyed_Information:
GTModelTypeGeoKey (Short,1): ModelTypeProjected
GTRasterTypeGeoKey (Short,1): RasterPixelIsArea
GTCitationGeoKey (Ascii,235): "IMAGINE GeoTIFF Support
Copyright 1991 - 2001 by ERDAS, Inc. All Rights Reserved
@(#)$RCSfile: egtf.c $ $Revision: 1.9.2.4 $ $Date: 2002/01/24 16:43:13Z $
Projection Name = Lambert Conformal Conic
Units = meters
GeoTIFF Units = meters"
GeographicTypeGeoKey (Short,1): GCS_NAD83
ProjectedCSTypeGeoKey (Short,1): User-Defined
PCSCitationGeoKey (Ascii,192): "IMAGINE GeoTIFF Support
Copyright 1991 - 2001 by ERDAS, Inc. All Rights Reserved
@(#)$RCSfile: egtf.c $ $Revision: 1.9.2.4 $ $Date: 2002/01/24 16:43:13Z $
Projection = Lambert Conformal Conic"
ProjectionGeoKey (Short,1): User-Defined
ProjCoordTransGeoKey (Short,1): CT_LambertConfConic_2SP
ProjLinearUnitsGeoKey (Short,1): Linear_Meter
ProjStdParallel1GeoKey (Double,1): 30.6666667
ProjStdParallel2GeoKey (Double,1): 25.3333333
ProjNatOriginLongGeoKey (Double,1): -100
ProjFalseOriginLongGeoKey (Double,1): 0
ProjFalseOriginLatGeoKey (Double,1): 30.125
ProjFalseOriginEastingGeoKey (Double,1): 0
ProjFalseOriginNorthingGeoKey (Double,1): 0
End_Of_Keys.
End_Of_Geotiff.

Projection Method: CT_LambertConfConic_2SP
ProjStdParallel1GeoKey: 30.666667 ( 30d40' 0.00"N)
ProjStdParallel2GeoKey: 25.333333 ( 25d20' 0.00"N)
ProjFalseOriginLatGeoKey: 30.125000 ( 30d 7'30.00"N)
ProjFalseOriginLongGeoKey: -100.000000 (100d 0' 0.00"W)
ProjFalseEastingGeoKey: 0.000000
ProjFalseNorthingGeoKey: 0.000000
GCS: 4269/NAD83
Datum: 6269/North American Datum 1983
Ellipsoid: 7019/GRS 1980 (6378137.00,6356752.31)
Prime Meridian: 8901/Greenwich (0.000000/ 0d 0' 0.00"E)
Projection Linear Units: 9001/metre (1.000000m)

Corner Coordinates:
Upper Left (-364619.149, 238513.594) (103d51'44.46"W, 32d13'23.18"N)
Lower Left (-364619.149, -26434.831) (103d46'31.88"W, 29d50' 7.76"N)
Upper Right ( 343419.482, 238513.594) ( 96d21'43.48"W, 32d13'44.30"N)
Lower Right ( 343419.482, -26434.831) ( 96d26'37.91"W, 29d50'28.46"N)
Center ( -10599.834, 106039.382) (100d 6'39.75"W, 31d 4'53.35"N)


The example that does not work is:
https://aviationtoolbox.org/Members/kyler/tools/map_image?scale=50&image_format=GeoTIFF&lr_Y=-753147.0&lr_X=318457.0&ul_X=216057.0&ul_Y=-676347.0

And its listgeo info is:
Geotiff_Information:
Version: 1
Key_Revision: 1.0
Tagged_Information:
ModelTiepointTag (2,3):
0 0 0
216057 -676347 0
ModelPixelScaleTag (1,3):
128 128 0
End_Of_Tags.
Keyed_Information:
GTModelTypeGeoKey (Short,1): ModelTypeProjected
GTRasterTypeGeoKey (Short,1): RasterPixelIsArea
GTCitationGeoKey (Ascii,8): "unnamed"
GeographicTypeGeoKey (Short,1): GCS_NAD83
ProjectedCSTypeGeoKey (Short,1): User-Defined
ProjectionGeoKey (Short,1): User-Defined
ProjCoordTransGeoKey (Short,1): CT_LambertConfConic_2SP
ProjLinearUnitsGeoKey (Short,1): Linear_Meter
ProjStdParallel1GeoKey (Double,1): 38.6666667
ProjStdParallel2GeoKey (Double,1): 33.3333333
ProjFalseEastingGeoKey (Double,1): 0
ProjFalseNorthingGeoKey (Double,1): 0
ProjFalseOriginLongGeoKey (Double,1): -100.583333
ProjFalseOriginLatGeoKey (Double,1): 38
End_Of_Keys.
End_Of_Geotiff.

Projection Method: CT_LambertConfConic_2SP
ProjStdParallel1GeoKey: 38.666667 ( 38d40' 0.00"N)
ProjStdParallel2GeoKey: 33.333333 ( 33d20' 0.00"N)
ProjFalseOriginLatGeoKey: 38.000000 ( 38d 0' 0.00"N)
ProjFalseOriginLongGeoKey: -100.583333 (100d35' 0.00"W)
ProjFalseEastingGeoKey: 0.000000
ProjFalseNorthingGeoKey: 0.000000
GCS: 4269/NAD83
Datum: 6269/North American Datum 1983
Ellipsoid: 7019/GRS 1980 (6378137.00,6356752.31)
Prime Meridian: 8901/Greenwich (0.000000/ 0d 0' 0.00"E)
Projection Linear Units: 9001/metre (1.000000m)

Corner Coordinates:
Upper Left ( 216057.000,-676347.000) ( 98d18'10.89"W, 31d52'40.87"N)
Lower Left ( 216057.000,-753147.000) ( 98d19'18.60"W, 31d11'12.79"N)
Upper Right ( 318457.000,-676347.000) ( 97d13'22.77"W, 31d51' 4.80"N)
Lower Right ( 318457.000,-753147.000) ( 97d15' 2.51"W, 31d 9'37.59"N)
Center ( 267257.000,-714747.000) ( 97d46'28.56"W, 31d31'13.34"N)


They both look pretty good to me-- the corner coordinates seem to be there,
etc-- but I don't know anything about all the "false origin" stuff.
Oziexplorer doesn't seem to have trouble with the Lambert projection in the
first example though.

I am copying this to the OziUsers List, maybe J.G. can give some more
assistance?

Thanks!
John Clonts
Temple, Texas
N7NZ

[John Clonts]

"John Clonts" > wrote in message >...
> "Kyler Laird" > wrote in message
> ...
> > "John Clonts" > writes:
> >
> > >Thanks for the tips. I found that when I use the "raw data" it does work
> as
> > >you say (http://aviationtoolbox.org/raw_data/FAA/sectionals/current/).
> Is
> > >this what you are using?
>
> > >But I have trouble when I try to use one of Kyler's "processed images"
> from
> > >https://aviationtoolbox.org/Members/kyler/tools/map_explorer
> > >I have the problems that J.G. diagnoses below.
>
> > >> > TIFF Directory at offset 0x15ff3e
> > >> > Image Width: 800 Image Length: 600
> > >> > Bits/Sample: 8
> > >> > Sample Format: unsigned integer
> > >> > Compression Scheme: None
> > >> > Photometric Interpretation: RGB color
> > >> > Samples/Pixel: 3
> > >> > Rows/Strip: 10
> > >> > Planar Configuration: separate image planes
> > >> > Tag 33550: 128.000000,128.000000,0.000000
> > >> > .
> > >> > .
> > >> >
> > >> > It's that Planar Configuration setting of "separate image planes"
> > >> > that is confusing Ozi. Ozi wants to see "single image plane".
> >
> > Ah ha! That was causing problems for ImageMagick too. I just didn't
> > realize that's what was doing it.
> >
> > http://www.remotesensing.org/gdal/frmt_gtiff.html
> >
> > INTERLEAVE=[BAND,PIXEL]: By default TIFF files with band
> > interleaving (PLANARCONFIG_SEPARATE in TIFF terminology) are
> > created. These are slightly more efficient for some purposes,
> > but some applications only support pixel interleaved TIFF
> > files. In these cases pass INTERLEAVE=PIXEL to produce pixel
> > interleaved TIFF files (PLANARCONFIG_CONTIG in TIFF
> > terminology).
> >
> > So...I added "INTERLEAVE=PIXEL" and now tiffinfo reports this.
> > TIFF Directory at offset 0x580a1e
> > Image Width: 1600 Image Length: 1200
> > Bits/Sample: 8
> > Sample Format: unsigned integer
> > Compression Scheme: None
> > Photometric Interpretation: RGB color
> > Samples/Pixel: 3
> > Rows/Strip: 1
> > Planar Configuration: single image plane
> > ImageMagick displays a beautiful image now too.
> >
> > Does that solve the problem you had?
> >
> > Thank you for the report.
> >
>
> Kyler,
>
> Thanks that does solve the image display problem!
>
> The other problem remains however: the georeference information is not read
> in successfully by Oziexplorer:
>
> The example which works is e.g. the San Antonio Sectional at
> http://aviationtoolbox.org/raw_data/FAA/sectionals/current/San%20Antonio%2073%20North.tif
> :
> Its listgeo info is:
> Geotiff_Information:
> Version: 1
> Key_Revision: 1.0
> Tagged_Information:
> ModelTiepointTag (2,3):
> 0 0 0
> -364619.149 238513.594 0
> ModelPixelScaleTag (1,3):
> 63.781518 63.781518 0
> End_Of_Tags.
> Keyed_Information:
> GTModelTypeGeoKey (Short,1): ModelTypeProjected
> GTRasterTypeGeoKey (Short,1): RasterPixelIsArea
> GTCitationGeoKey (Ascii,235): "IMAGINE GeoTIFF Support
> Copyright 1991 - 2001 by ERDAS, Inc. All Rights Reserved
> @(#)$RCSfile: egtf.c $ $Revision: 1.9.2.4 $ $Date: 2002/01/24 16:43:13Z $
> Projection Name = Lambert Conformal Conic
> Units = meters
> GeoTIFF Units = meters"
> GeographicTypeGeoKey (Short,1): GCS_NAD83
> ProjectedCSTypeGeoKey (Short,1): User-Defined
> PCSCitationGeoKey (Ascii,192): "IMAGINE GeoTIFF Support
> Copyright 1991 - 2001 by ERDAS, Inc. All Rights Reserved
> @(#)$RCSfile: egtf.c $ $Revision: 1.9.2.4 $ $Date: 2002/01/24 16:43:13Z $
> Projection = Lambert Conformal Conic"
> ProjectionGeoKey (Short,1): User-Defined
> ProjCoordTransGeoKey (Short,1): CT_LambertConfConic_2SP
> ProjLinearUnitsGeoKey (Short,1): Linear_Meter
> ProjStdParallel1GeoKey (Double,1): 30.6666667
> ProjStdParallel2GeoKey (Double,1): 25.3333333
> ProjNatOriginLongGeoKey (Double,1): -100
> ProjFalseOriginLongGeoKey (Double,1): 0
> ProjFalseOriginLatGeoKey (Double,1): 30.125
> ProjFalseOriginEastingGeoKey (Double,1): 0
> ProjFalseOriginNorthingGeoKey (Double,1): 0
> End_Of_Keys.
> End_Of_Geotiff.
>
> Projection Method: CT_LambertConfConic_2SP
> ProjStdParallel1GeoKey: 30.666667 ( 30d40' 0.00"N)
> ProjStdParallel2GeoKey: 25.333333 ( 25d20' 0.00"N)
> ProjFalseOriginLatGeoKey: 30.125000 ( 30d 7'30.00"N)
> ProjFalseOriginLongGeoKey: -100.000000 (100d 0' 0.00"W)
> ProjFalseEastingGeoKey: 0.000000
> ProjFalseNorthingGeoKey: 0.000000
> GCS: 4269/NAD83
> Datum: 6269/North American Datum 1983
> Ellipsoid: 7019/GRS 1980 (6378137.00,6356752.31)
> Prime Meridian: 8901/Greenwich (0.000000/ 0d 0' 0.00"E)
> Projection Linear Units: 9001/metre (1.000000m)
>
> Corner Coordinates:
> Upper Left (-364619.149, 238513.594) (103d51'44.46"W, 32d13'23.18"N)
> Lower Left (-364619.149, -26434.831) (103d46'31.88"W, 29d50' 7.76"N)
> Upper Right ( 343419.482, 238513.594) ( 96d21'43.48"W, 32d13'44.30"N)
> Lower Right ( 343419.482, -26434.831) ( 96d26'37.91"W, 29d50'28.46"N)
> Center ( -10599.834, 106039.382) (100d 6'39.75"W, 31d 4'53.35"N)
>
>
> The example that does not work is:
> https://aviationtoolbox.org/Members/kyler/tools/map_image?scale=50&image_format=GeoTIFF&lr_Y=-753147.0&lr_X=318457.0&ul_X=216057.0&ul_Y=-676347.0
>
> And its listgeo info is:
> Geotiff_Information:
> Version: 1
> Key_Revision: 1.0
> Tagged_Information:
> ModelTiepointTag (2,3):
> 0 0 0
> 216057 -676347 0
> ModelPixelScaleTag (1,3):
> 128 128 0
> End_Of_Tags.
> Keyed_Information:
> GTModelTypeGeoKey (Short,1): ModelTypeProjected
> GTRasterTypeGeoKey (Short,1): RasterPixelIsArea
> GTCitationGeoKey (Ascii,8): "unnamed"
> GeographicTypeGeoKey (Short,1): GCS_NAD83
> ProjectedCSTypeGeoKey (Short,1): User-Defined
> ProjectionGeoKey (Short,1): User-Defined
> ProjCoordTransGeoKey (Short,1): CT_LambertConfConic_2SP
> ProjLinearUnitsGeoKey (Short,1): Linear_Meter
> ProjStdParallel1GeoKey (Double,1): 38.6666667
> ProjStdParallel2GeoKey (Double,1): 33.3333333
> ProjFalseEastingGeoKey (Double,1): 0
> ProjFalseNorthingGeoKey (Double,1): 0
> ProjFalseOriginLongGeoKey (Double,1): -100.583333
> ProjFalseOriginLatGeoKey (Double,1): 38
> End_Of_Keys.
> End_Of_Geotiff.
>
> Projection Method: CT_LambertConfConic_2SP
> ProjStdParallel1GeoKey: 38.666667 ( 38d40' 0.00"N)
> ProjStdParallel2GeoKey: 33.333333 ( 33d20' 0.00"N)
> ProjFalseOriginLatGeoKey: 38.000000 ( 38d 0' 0.00"N)
> ProjFalseOriginLongGeoKey: -100.583333 (100d35' 0.00"W)
> ProjFalseEastingGeoKey: 0.000000
> ProjFalseNorthingGeoKey: 0.000000
> GCS: 4269/NAD83
> Datum: 6269/North American Datum 1983
> Ellipsoid: 7019/GRS 1980 (6378137.00,6356752.31)
> Prime Meridian: 8901/Greenwich (0.000000/ 0d 0' 0.00"E)
> Projection Linear Units: 9001/metre (1.000000m)
>
> Corner Coordinates:
> Upper Left ( 216057.000,-676347.000) ( 98d18'10.89"W, 31d52'40.87"N)
> Lower Left ( 216057.000,-753147.000) ( 98d19'18.60"W, 31d11'12.79"N)
> Upper Right ( 318457.000,-676347.000) ( 97d13'22.77"W, 31d51' 4.80"N)
> Lower Right ( 318457.000,-753147.000) ( 97d15' 2.51"W, 31d 9'37.59"N)
> Center ( 267257.000,-714747.000) ( 97d46'28.56"W, 31d31'13.34"N)
>
>
> They both look pretty good to me-- the corner coordinates seem to be there,
> etc-- but I don't know anything about all the "false origin" stuff.
> Oziexplorer doesn't seem to have trouble with the Lambert projection in the
> first example though.
>
> I am copying this to the OziUsers List, maybe J.G. can give some more
> assistance?
>

Kyler,

This is the input I got from J.G. on the OziUsers list, regarding the
above:

<begin quote>
I took a look at the goetiff tags for the two images and I think I
see the problem. The full image is specifying a key:

ProjNatOriginLongGeoKey (Double,1): -100

While the smaller image does not even have that key. Somehow, the
smaller image is using the tag:

ProjFalseOriginLongGeoKey (Double,1): -100.583333

These can't both be right. I'd say the full image is the right one,
since it loads fine in not just Ozi, but other programs too, while
the smaller image does not work in other programs. I'm pretty
certain that the ProjNatOriginLongGeoKey is only supposed to be used
in cases where the prime meridian is not the familiar 0 degrees
longitude value. Technically, the math may work, to subvert the
function of that tag and then specify the ProjFalseOriginLongGeoKey
as 0.0, but it's highly irregular. Listgeo is able to deal with it,
by translating the natorigin key to it's equivalent falseorigin key,
but programs generating geotiff files should not rely on geotiff
readers to do this.

All that said, you can fix these keys. If you redirect the output of
the listgeo program to a file, you can edit that file with any
ordinary text editor and reinstall it into the geotiff file, using
the geotifcp program, which is part of the zip file I referred to
previously.

J.G.
<end quote>

By full image he means the San Antonio sectional ("raw"), and by
"smaller image" he means the one provided by your map_explorer link...

Hope that helps,
John

[John Clonts]

"John Clonts" > wrote in message
om...

> Kyler,
>
> This is the input I got from J.G. on the OziUsers list, regarding the
> above:
>
> <begin quote>
> I took a look at the goetiff tags for the two images and I think I
> see the problem. The full image is specifying a key:
>
> ProjNatOriginLongGeoKey (Double,1): -100
>
> While the smaller image does not even have that key. Somehow, the
> smaller image is using the tag:
>
> ProjFalseOriginLongGeoKey (Double,1): -100.583333
>
> These can't both be right. I'd say the full image is the right one,
> since it loads fine in not just Ozi, but other programs too, while
> the smaller image does not work in other programs. I'm pretty
> certain that the ProjNatOriginLongGeoKey is only supposed to be used
> in cases where the prime meridian is not the familiar 0 degrees
> longitude value. Technically, the math may work, to subvert the
> function of that tag and then specify the ProjFalseOriginLongGeoKey
> as 0.0, but it's highly irregular. Listgeo is able to deal with it,
> by translating the natorigin key to it's equivalent falseorigin key,
> but programs generating geotiff files should not rely on geotiff
> readers to do this.
>
> All that said, you can fix these keys. If you redirect the output of
> the listgeo program to a file, you can edit that file with any
> ordinary text editor and reinstall it into the geotiff file, using
> the geotifcp program, which is part of the zip file I referred to
> previously.
>
> J.G.
> <end quote>

Hello Kyler,

FYI, I patched the tags in my test file (from
https://aviationtoolbox.org/Members/kyler/tools/map_image?scale=50&image_format=GeoTIFF&lr_Y=-753147.0&lr_X=318457.0&ul_X=216057.0&ul_Y=-676347.0)
with geotifcp per J.G.'s instructions, and Oziexplorer is happy with that
image now. Do you know if changing your generation code would be
appropriate, and/or cause other problems with other software?

Cheers,
John

[Kyler Laird]

"John Clonts" > writes:

>FYI, I patched the tags in my test file (from
>https://aviationtoolbox.org/Members/kyler/tools/map_image?scale=50&image_format=GeoTIFF&lr_Y=-753147.0&lr_X=318457.0&ul_X=216057.0&ul_Y=-676347.0)
>with geotifcp per J.G.'s instructions, and Oziexplorer is happy with that
>image now. Do you know if changing your generation code would be
>appropriate, and/or cause other problems with other software?

It's appropriate and I want to do it. If it causes any problems, I'll
work through them. I want these things to be correct.

Yesterday I distilled the code to a few lines that demonstrate the
problem and sent a report to the GDAL developer mailing list.
http://remotesensing.org/mailman/listinfo/gdal-dev/
It hasn't appeared in the archives yet.

I welcome more reports to the list. My trivial example is below.

Thank you.

--kyler

================================================== ========================
#!/usr/bin/env python

import gdal

a = gdal.Open('a.tif')

b = gdal.GetDriverByName('GTiff').Create(
'b.tif',
a.RasterXSize, a.RasterYSize,
3, gdal.GDT_Byte,
[ 'TILED=YES' ]
)

b.SetProjection(a.GetProjection())
b.SetGeoTransform(a.GetGeoTransform())

[John Clonts]

"Kyler Laird" > wrote in message
...
> "John Clonts" > writes:
>
> >FYI, I patched the tags in my test file (from
>
>https://aviationtoolbox.org/Members/kyler/tools/map_image?scale=50&image_fo
rmat=GeoTIFF&lr_Y=-753147.0&lr_X=318457.0&ul_X=216057.0&ul_Y=-676347.0)
> >with geotifcp per J.G.'s instructions, and Oziexplorer is happy with that
> >image now. Do you know if changing your generation code would be
> >appropriate, and/or cause other problems with other software?
>
> It's appropriate and I want to do it. If it causes any problems, I'll
> work through them. I want these things to be correct.
>
> Yesterday I distilled the code to a few lines that demonstrate the
> problem and sent a report to the GDAL developer mailing list.
> http://remotesensing.org/mailman/listinfo/gdal-dev/
> It hasn't appeared in the archives yet.
>

Hello Kyler,

Well, I haven't seen your inquiry show up there yet-- nor at the nntp site
news.gmane.org/gmane.comp.gis.gdal.devel.

But in the mean time I did some digging, and determined a fix that seems to
work for it, in gdal-1.2.1\frmts\gtiff\gt_wkt_srs.cpp, line 1419:

else if( EQUAL(pszProjection,SRS_PT_LAMBERT_CONFORMAL_CONIC _2SP) )
{
GTIFKeySet(psGTIF, GTModelTypeGeoKey, TYPE_SHORT, 1,
ModelTypeProjected);
GTIFKeySet(psGTIF, ProjectedCSTypeGeoKey, TYPE_SHORT, 1,
KvUserDefined );
GTIFKeySet(psGTIF, ProjectionGeoKey, TYPE_SHORT, 1,
KvUserDefined );

GTIFKeySet(psGTIF, ProjCoordTransGeoKey, TYPE_SHORT, 1,
CT_LambertConfConic_2SP );

GTIFKeySet(psGTIF, ProjFalseOriginLatGeoKey, TYPE_DOUBLE, 1,
poSRS->GetProjParm( SRS_PP_LATITUDE_OF_ORIGIN, 0.0 ) );

/* jcc 7/2/04 changed from ProjFalseOriginLongGeoKey */
GTIFKeySet(psGTIF, ProjNatOriginLongGeoKey, TYPE_DOUBLE, 1, //
line 1419
poSRS->GetProjParm( SRS_PP_CENTRAL_MERIDIAN, 0.0 ) );

GTIFKeySet(psGTIF, ProjStdParallel1GeoKey, TYPE_DOUBLE, 1,
poSRS->GetProjParm( SRS_PP_STANDARD_PARALLEL_1, 0.0 ) );

I tried to post to the nntp server on the devel list but it did not accept
my posting... perhaps you have better connections into that group.

I will post my new pymod\_gdal.dll and bin\gdal12.dll on
alt.binaries.pictures.aviation if you would like to test them...

Cheers,
John

[Kyler Laird]

"John Clonts" > writes:

> /* jcc 7/2/04 changed from ProjFalseOriginLongGeoKey */
> GTIFKeySet(psGTIF, ProjNatOriginLongGeoKey, TYPE_DOUBLE, 1, //

I had considered doing that too. I hesitated because I just don't know
enough about it. If it works for you, however, I'm happy to do it.

Please try the GeoTIFFs now. Do they work the way you expect?

If not, please take a look at the TIFFs in these directories.
http://aviationtoolbox.org/munge/data/masked/
http://aviationtoolbox.org/munge/data/warped/
I'm regenerating the whole set with the modified GDAL.

Thank you!

--kyler

[John Clonts]

"Kyler Laird" > wrote in message
...
> "John Clonts" > writes:
>
> > /* jcc 7/2/04 changed from ProjFalseOriginLongGeoKey */
> > GTIFKeySet(psGTIF, ProjNatOriginLongGeoKey, TYPE_DOUBLE, 1, //
>
> I had considered doing that too. I hesitated because I just don't know
> enough about it. If it works for you, however, I'm happy to do it.

Well, you probably know more about it than I do-- I hope it doesn't screw
somebody else up :) I notice that Frank W the main GDAL guy is on vacation
until next week

>
> Please try the GeoTIFFs now. Do they work the way you expect?
>
It works the same as before, and I see that it still has the "FalseOrigin"
instead of the "NatOrigin" key. (I.e. from
https://aviationtoolbox.org/Members/kyler/tools/map_explorer).


> If not, please take a look at the TIFFs in these directories.
> http://aviationtoolbox.org/munge/data/masked/
> http://aviationtoolbox.org/munge/data/warped/

Ok, but these are 200Mb files?

> I'm regenerating the whole set with the modified GDAL.
>
> Thank you!
>


Thank you!

John

[Kyler Laird]

I've completely regenerated all of the images from the base (FAA) set
using the modifified GDAL. Please verify that the GeoTIFFs are now as
they need to be.
https://aviationtoolbox.org/Members/kyler/tools/map_explorer

I now see tags such as this.
ProjNatOriginLongGeoKey (Double,1): -100.583333

Thank you.

--kyler

[John Clonts]

"Kyler Laird" > wrote in message
...
> I've completely regenerated all of the images from the base (FAA) set
> using the modifified GDAL. Please verify that the GeoTIFFs are now as
> they need to be.
> https://aviationtoolbox.org/Members/kyler/tools/map_explorer
>
> I now see tags such as this.
> ProjNatOriginLongGeoKey (Double,1): -100.583333
>
> Thank you.
>
> --kyler\

Seems to work perfectly for me now...

Thank you!!

John