From warmerdam at pobox.com Tue May 8 20:46:21 2012 From: warmerdam at pobox.com (Frank Warmerdam) Date: Tue, 8 May 2012 18:46:21 -0700 Subject: [Geotiff] CT_HotineObliqueMercatorAzimuthCenter added .. new CT_ policy Message-ID: Folks, At the point when GeoTIFF was created EPSG (apparently) did not have an enumeration for coordinate transformation methods (like Transverse Mercator). So the GeoTIFF spec embedded it's own - the CT_* constants in geo_ctrans.inc. Shortly after that EPSG added the coordinate_operation_method table but the split had already occured. Since EPSG has added many projection methods not included in GeoTIFF. It looks like I, by fiat, added CT_CylindricalEqualArea and perhaps CT_TransvMercator_SouthOrientated with consecutive codes. However, this did not do much to catch things up with EPSG. I have recently done a bunch of work in GDAL to differentiate EPSG's hotine oblique mercator methods, marking 9815 as distinct with a name of Hotine_Oblique_Mercator_Azimuth_Center. I was going to add it to GeoTIFF too but I really don't want to have distinct codes between EPSG and GeoTIFF. So I am suggesting (and implementing) a move to using the EPSG transform codes for new projection methods. Are there there any questions or concerns about this? eg. in geo_ctrans.inc: /* Added May 2012 - from now on we use the EPSG */ ValuePair(CT_HotineObliqueMercatorAzimuthCenter, 9815) Best regards, -- ---------------------------------------+-------------------------------------- I set the clouds in motion - turn up?? | Frank Warmerdam, warmerdam at pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush? ? | Geospatial Software Developer