heyyy / espa

Automatically exported from code.google.com/p/espa
0 stars 0 forks source link

Modify keys in tiff tags #64

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
Community accepted conversion tools like HEG and MRT write Geographic 
projection tags like this:

   Keyed_Information:
      GTModelTypeGeoKey (Short,1): ModelTypeGeographic
      GTRasterTypeGeoKey (Short,1): RasterPixelIsPoint
      GTCitationGeoKey (Ascii,34): "Geographic (Longitude, Latitude) "
      GeographicTypeGeoKey (Short,1): GCS_WGS_84
      GeogGeodeticDatumGeoKey (Short,1): DatumE_WGS84
      GeogAngularUnitsGeoKey (Short,1): Angular_Degree
      ProjectedCSTypeGeoKey (Short,1): User-Defined
      End_Of_Keys.

ESPA2.2.0 write them out like this:

      GTModelTypeGeoKey (Short,1): ModelTypeGeographic
      GTRasterTypeGeoKey (Short,1): RasterPixelIsArea
      GeographicTypeGeoKey (Short,1): GCS_WGS_84
      GeogCitationGeoKey (Ascii,7): "WGS 84"
      GeogAngularUnitsGeoKey (Short,1): Angular_Degree
      GeogSemiMajorAxisGeoKey (Double,1): 6378137          
      GeogInvFlatteningGeoKey (Double,1): 298.257224  

I was wondering if we should use the 'standard' keys and values to describe 
ESPA products, specifically for the GTCitationGeoKey, GeographicTypeGeoKey, and 
the GeogGeodeticDatumGeoKey.

Original issue reported on code.google.com by kallie...@gmail.com on 21 Oct 2013 at 4:46

GoogleCodeExporter commented 9 years ago
The following looks half-baked to me. It's in the keyed tags in sinusoidal 
output.  It's not affecting projection recognition in image processing 
software, but I'd like it cleaned up when we get to addressing the other geotag 
work.

GeogCitationGeoKey (Ascii,83): "GCS Name = unnamed ellipse|Datum = 
unknown|Ellipsoid = unnamed|Primem = Greenwich|"

Original comment by kallie...@gmail.com on 22 Oct 2013 at 5:05

GoogleCodeExporter commented 9 years ago
Team discussion resulted in saving these tiff things up and dealing with them 
in conjunction/at completion of the binary transition.  Specifically, here's 
the plan:

1. we will write all products (internally) to raw binary with the XML metadata 
file.
2. create raw binary to {insert file format here} converters to convert our 
format to GeoTIFF, HDF, etc.

The converters would be C tools that we create using the actual libraries 
(GeoTIFF, HDF, etc.)  That gives us the best control over the tags that we want 
to write.  GDAL doesn't allow for a lot of customization ....

This issue should be attached with Issue 66 Create output format translator.

Original comment by kallie...@gmail.com on 22 Oct 2013 at 5:08

GoogleCodeExporter commented 9 years ago

Original comment by davehil...@gmail.com on 27 Jan 2014 at 9:54