LocalCS not roundtrippable in GeoTIFF

Ray,

I have committed changes in gdal trunk to support roundtripping of LOCAL_CS via GeoTIFF.

Basically any file that is not projected, and not geographic but that does have some geokeys will be treated as LOCAL_CS when reading.

On write LOCAL_CS will be written with the name in the GTCitation and the linear units will be written. Something like:

Geotiff_Information:
   Version: 1
   Key_Revision: 1.0
   Tagged_Information:
      ModelTiepointTag (2,3):
         0                0                0                
         440720           3751320          0                
      ModelPixelScaleTag (1,3):
         60               60               0                
      End_Of_Tags.
   Keyed_Information:
      GTRasterTypeGeoKey (Short,1): RasterPixelIsArea
      GTCitationGeoKey (Ascii,10): "custom cs"
      GeogAngularUnitsGeoKey (Short,1): Angular_Degree
      ProjLinearUnitsGeoKey (Short,1): Linear_Meter
      End_Of_Keys.
   End_Of_Geotiff.

The changes seem a wee bit messy and seem like they could introduced new unexpected effects or bugs so I haven't applied this change in 1.4 branch.

I've confirmed success of that mod; thanks. It's especially nice in that it does not require any auxiliary world file.

Hmmm... yeah, if such geokey use leads to "impure" GeoTIFFs it could be a hazard... as much as I need the feature, I wouldn't want to cause bad files to start cropping up. Can the geotiff specs be updated to make this approach official, or should we try something else?

Just noticed that if the projectionref being written happens to be the default (origin 0,0 and pixelscale 1,1), reading the GeoTIFF back reports localcs, but GetProjectionRef? will issue CE_Failure.

Or are callers supposed to use the physical extents when a localcs is returned but not a projection ref?

Ray,

It would be desirable to make it clear in a future geotiff specification that a GTCitation and a linear units definitions is intended to be equivelent to the OGC/ISO LOCAL_CS concept. However, I don't think there is any harm in the meantime in using it that way.

Many parts of GDAL treat a geotransform of [0,1,0,0,0,1] as being invalid since it is the default returned when no geotransform is available. In north up datasets it should not happen since the y pixel size should be negative. But it is possible to have a south-up dataset with the origin at 0,0 in it's coordinate system and a pixel size of 1,1, and this will cause unfortunate effects in many places. At this time I'm not too inclined to pursue this issue.

Looking at GTiffDataset::GetProjectionRef?(), I don't see anything that will issue an error, and that method does not return a CPLErr value. Perhaps you mean that GetGeoTransform?() returns CE_Failure?

Sorry, yes, it was GetGeoTransform? returning the error.

I'm trying to support localcs w/o regard to what specific values people use for the origin and pixelsize... if there's a special case, my clients won't really understand what the problem is. In gaming, e.g., it's common to start off with a raster cs but then switch to localcs so you can treat pixels as meters/feet/whatever. But the origin and size will still be 0,0, 1,1. I can't tell these people that it's an error case. If I offer them the ability to have their own user-defined localcs, I can't say that some values are special; it defeats the purpose. They're not in geospace; they're in their own space which just happens to use realworld units of measure.

Since GetGeoTransform? can return an error, why not make it policy that the return code is the error flag and not the transform values? Failing this or another solution, I'll have to locally mod the gtiff driver to return CE_None for default geotransform if it actually read those values from the file.