Determining Natural Origin for a GeoTIFF file (Lambert Conic)

Question

I am trying to display an existing GeoTIFF file (from the FAA WAC set) in an application that requires the GeoTIFF NaturalOriginLongitude tag (FalconView 5.1.1). There are some older files in that set that display OK, and newer files that don't appear.

I'm confident that it is that tag (from running the code in a debugger, and from trying "fake" longitude values in files). That is, I know how to add the tag (using listgeo and geotifcp) as described in an earlier question, and adding the tag makes the file appear.

However the values that I'm putting in aren't providing an appropriately georeferenced display. I've tried zero (because that seemed like something easy) and I've tried using the same value as is in FalseOriginLongitude (which is what the older files seemed to contain). Setting NaturalOriginalLongitude to be the same as the FalseOriginLongitude value is definitely better than setting it to zero, but its a little off in Longitude (a few minutes) and a lot off in Latitude (a few degrees).

I tried some likely-looking google hits (especially an EPSG Guidance Note 7 Part2), but I didn't find anything that gives me the natural origin longitude (lambda0) value that I need.

Here is the output of listgeo for a specific file that does not display.

$ listgeo CG-18\ WAC\ 42\ North.tif 
TIFFReadDirectory: Warning, CG-18 WAC 42 North.tif: unknown field with tag 42112 (0xa480) encountered.
TIFFReadDirectory: Warning, CG-18 WAC 42 North.tif: unknown field with tag 42113 (0xa481) encountered.
Geotiff_Information:
   Version: 1
   Key_Revision: 1.0
   Tagged_Information:
       ModelTiepointTag (2,3):
         0                0                0                
         -833364.681326397491974.541710076 0                
       ModelPixelScaleTag (1,3):
          126.87142        126.87142        0                
       End_Of_Tags.
   Keyed_Information:
      GTModelTypeGeoKey (Short,1): ModelTypeProjected
      GTRasterTypeGeoKey (Short,1): RasterPixelIsArea
      GTCitationGeoKey (Ascii,21): "PCS Name = CG-18 WAC"
      GeographicTypeGeoKey (Short,1): GCS_NAD83
      GeogCitationGeoKey (Ascii,24): "GCS_North_American_1983"
      GeogAngularUnitsGeoKey (Short,1): Angular_Degree
      GeogSemiMajorAxisGeoKey (Double,1): 6378137          
      GeogInvFlatteningGeoKey (Double,1): 298.257222101    
      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.66667         
      ProjStdParallel2GeoKey (Double,1): 33.33333         
      ProjFalseOriginLongGeoKey (Double,1): -118.085         
      ProjFalseOriginLatGeoKey (Double,1): 36               
      ProjFalseOriginEastingGeoKey (Double,1): 0                
      ProjFalseOriginNorthingGeoKey (Double,1): 0                
      End_Of_Keys.
   End_Of_Geotiff.

Projection Method: CT_LambertConfConic_2SP
   ProjFalseOriginLatGeoKey: 36.000000 ( 36d 0' 0.00"N)
   ProjFalseOriginLongGeoKey: -118.085000 (118d 5' 6.00"W)
   ProjStdParallel1GeoKey: 38.666670 ( 38d40' 0.01"N)
   ProjStdParallel2GeoKey: 33.333330 ( 33d19'59.99"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    ( -833364.681,  491974.542)  (127d51'15.84"W, 40d 3'23.84"N)
Lower Left    ( -833364.681,  -31877.551)  (127d16'36.93"W, 35d21'26.95"N)
Upper Right   (  685286.216,  491974.542)  (110d 2'34.02"W, 40d10'41.37"N)
Lower Right   (  685286.216,  -31877.551)  (110d31' 8.78"W, 35d28'20.04"N)
Center        (  -74039.233,  230048.495)  (118d55'44.97"W, 38d 4'18.53"N)

There are also world files for each TIFF. Here is an example:

$ cat CG-18\ WAC\ 42\ North.tfw
126.8714200000
0.0000000000
0.0000000000
-126.8714200000
-833301.2456163971
491911.1060000764

There are also HTML files providing metadata, but it seems (to me) to be a subset of the GeoTIFF tags.

Any suggestions for how to get a reasonable value for NaturalOriginLongitude from the information I have available?

I did some reading about this. The FalseOriginLong is just the x=0 line for the projection. While the NaturalOriginLong is the longitude of the center of a cylindrical or azimuthal projection (where distortion is zero). From what I understand, the NaturalOriginLong is undefined for a LCC projection. Guess this isn't helpful to you, but maybe it explains why there hasn't been an answer yet. — L_Holcombe, Dec 02 '12 at 07:02
The 5th line of your world file is the x-coord for the upper left pixel. What longitude is 833301.25 meters east of there? Is it -118.085? If not, then that's the value you want. — L_Holcombe, Dec 02 '12 at 07:06

score 1 · Answer 1 · answered Dec 04 '12 at 23:34

1

If FalconView requires NaturalOriginLongitude, it uses a different projection method: Lambert Canonical Standard Parallel 2 uses false origin*; it is SP1 that uses natural origin long/lat, scale, and false easting/northing. The first change in your headers needs to be all-around SP1.

Since these are all relative coordinates using the same math (just an older standard for the inputs), I would take @L_Holcombe's advice. I would first try just negating/inverting the values because it would be quick. To make sure you do it right, you would need to back-calc the false origins from SP2 and then recalculate using the SP1 method. This document from OGP might be useful for the calculations.

answered Dec 04 '12 at 23:34

egbutter

187
3

I'm not sure what you are intending with the reference from EPSG Guidance Note 7 Part 2, since I already know about that (see question). FalconView uses SP2 (I've looked at the code), but it isn't doing the same calculations as are refered to in the EPSG Guidance Note 7 Part 2. So I'm not sure how this answer is supposed to help me at all. – BradHards Dec 05 '12 at 03:06
1

@BradHards Frustrated or not, please be a little bit more respectful of my attempt to help. If the answer is wrong, don't accept it. I did not realize my link was also EPSG Guidance Note 7 Part 2 -- but that document does show calculations with Natural Origin and False Origin -- why does it matter that they are not called lambda0? If doing the back-calculation gets you the wrong coordinates, either your math is wrong or the header is confusing this FalconView (I just threw out a suggestion that it could be an SP2 vs. SP1 issue -- I do not have a user guide myself!) Cheers, – egbutter Dec 06 '12 at 14:50
Sorry if you are offended by my response. It looks like you've just done a google search and found the same links I found. If that isn't the case, can you explain exactly which parts of the referenced document show how to get from the information I have (which I've put into the question), to get to something that will work in FalconView? Or actually write out the equation? – BradHards Dec 06 '12 at 20:03
Well, it came off that way to me, at least. My response also comes from my experience having only used False Origin in SP2. That was confirmed by the ESPG Guidance doc in Table 2 on p 15: it suggests only SP1 uses Natural Origin. Check p. 18 -- visually compares false and natural origin calculations. Search for False Origin and Natural Origin -- there are a couple good examples I read there. – egbutter Dec 08 '12 at 16:45
If I needed False Origin, my problems would be solved, since I already have that. I need Natural Origin, and I don't know how to calculate it. – BradHards Dec 08 '12 at 21:28

Determining Natural Origin for a GeoTIFF file (Lambert Conic)

1 Answers1