id,summary,reporter,owner,description,type,status,priority,milestone,component,version,severity,resolution,keywords,cc 1884,Format - SRTM HGT,Metatron,Even Rouault,"According to the NASA documentation: 3.0 Data Formats The names of individual data tiles refer to the longitude and latitude of the lower-left (southwest) corner of the tile (this follows the DTED convention as opposed to the GTOPO30 standard). For example, the coordinates of the lower-left corner of tile N40W118 are 40 degrees north latitude and 118 degrees west longitude. To be more exact, these coordinates refer to the geometric center of the lower left sample, which in the case of SRTM3 data will be about 90 meters in extent. Though in the loader it is expected that the coordinate definition lies on the corner of the sample, not on it's center and tries to fix it accordingly. That is wrong - the following would comply with the NASA definition: GDALDataset* SRTMHGTDataset::Open(GDALOpenInfo* poOpenInfo) poDS->adfGeoTransform[0] = southWestLon; poDS->adfGeoTransform[1] = 1.0 / (numPixels-1); poDS->adfGeoTransform[2] = 0.0000000000; poDS->adfGeoTransform[3] = southWestLat + 1; poDS->adfGeoTransform[4] = 0.0000000000; poDS->adfGeoTransform[5] = -1.0 / (numPixels-1); Furthermore: SRTM1 data are sampled at one arc-second of latitude and longitude and each file contains 3601 lines and 3601 samples. The rows at the north and south edges as well as the columns at he east and west edges of each cell overlap and are identical to the edge rows and columns in the adjacent cell. Though in the loader is is expected to cover 1.0 degree on the [0,1200]/[0,3600] or [0,1201)/[0,3601) interval. That is wrong, it is slightly more (the overlap). 1.0 degree is then on the [0,1199]/[0,3599] or [0,1200)/[0,3600) interval - the following would correct that also: poDS->adfGeoTransform[0] = southWestLon; poDS->adfGeoTransform[1] = 1.0 / (numPixels-2); poDS->adfGeoTransform[2] = 0.0000000000; poDS->adfGeoTransform[3] = southWestLat + 1; poDS->adfGeoTransform[4] = 0.0000000000; poDS->adfGeoTransform[5] = -1.0 / (numPixels-2); I detected the error by trying to connect independent SRTM-tiles in a 3D-software, they weren't adjacent. I implemented the fix, and now the data fits absolutely correct. Ciao Niels ",defect,closed,normal,1.7.0,GDAL_Raster,svn-trunk,minor,fixed,"SRTM, GeoCoordinates",Even Rouault warmerdam Kyle Shannon