Opened 17 years ago
Closed 5 years ago
#1511 closed enhancement (wontfix)
GDAL doesn't write out PROJ metadata for Krovak to GeoTIFF
Reported by: | Markus Neteler | Owned by: | warmerdam |
---|---|---|---|
Priority: | normal | Milestone: | closed_because_of_github_migration |
Component: | GDAL_Raster | Version: | 1.4.0 |
Severity: | normal | Keywords: | gtiff |
Cc: | martinl |
Description (last modified by )
Frank, when exporting a raster map from GRASS to GeoTIFF, the PROJ metadata get lost: # via plugin: GRASS 6.3.cvs (krovak): > gdalinfo ~/grassdata/krovak2/PERMANENT/cellhd/random Driver: GRASS/GRASS Database Rasters (5.7+) Size is 2340, 1454 Coordinate System is: PROJCS["Krovak", GEOGCS["bessel", DATUM["Militar_Geographische_Institut", SPHEROID["Bessel_1841",6377397.155,299.1528128], TOWGS84[570.8,85.7,462.8,4.998,1.587,5.261,3.56]], PRIMEM["ferro",-17.666666666668], UNIT["degree",0.0174532925199433]], PROJECTION["Krovak"], PARAMETER["latitude_of_center",49.5], PARAMETER["longitude_of_center",24.833333333332], PARAMETER["azimuth",0], PARAMETER["pseudo_standard_parallel_1",0], PARAMETER["scale_factor",0.9999], PARAMETER["false_easting",0], PARAMETER["false_northing",0], UNIT["metre",1]] Origin = (-901759.455629699979909,-934983.943862739950418) Pixel Size = (200.005911179846152,-200.042690930873476) Corner Coordinates: Upper Left ( -901759.456, -934983.944) ( 11d58'38.87"E, 50d49'49.42"N) Lower Left ( -901759.456,-1225846.016) ( 12d38'15.27"E, 48d15'2.29"N) Upper Right ( -433745.623, -934983.944) ( 18d36'25.77"E, 51d21'20.24"N) Lower Right ( -433745.623,-1225846.016) ( 18d55'41.19"E, 48d44'56.71"N) Center ( -667752.540,-1080414.980) ( 15d31'37.98"E, 49d50'30.36"N) Band 1 Block=2340x1 Type=Byte, ColorInterp=Palette Min=1.000 Max=1.000 NoData Value=0 Metadata: COLOR_TABLE_RULES_COUNT=1 COLOR_TABLE_RULE_RGB_0=1.000000e+00 1.000000e+00 255 0 127 255 0 127 Color Table (RGB with 2 entries) 0: 0,0,0,0 1: 255,0,127,255 # exporting via plugin (but also r.out.gdal in C fails): GRASS 6.3.cvs (krovak): > gdal_translate ~/grassdata/krovak/PERMANENT/cellhd/random random.tif Input file size is 2340, 1454 0...10...20...30...40...50...60...70...80...90...100 - done. GRASS 6.3.cvs (krovak): > gdalinfo random.tif Driver: GTiff/GeoTIFF Size is 2340, 1454 Coordinate System is `' Origin = (-901759.455629699979909,-934983.943862739950418) Pixel Size = (200.005911179846152,-200.042690930873476) Metadata: AREA_OR_POINT=Area Corner Coordinates: Upper Left ( -901759.456, -934983.944) Lower Left ( -901759.456,-1225846.016) Upper Right ( -433745.623, -934983.944) Lower Right ( -433745.623,-1225846.016) Center ( -667752.540,-1080414.980) Band 1 Block=2340x3 Type=Byte, ColorInterp=Palette NoData Value=0 [...] I suspect a simple lookup problem for "Militar_Geographische_Institut" or such. Version: GDAL SVN HEAD from 7 March 2007 (today) Best, Markus
Change History (8)
comment:4 by , 17 years ago
Description: | modified (diff) |
---|---|
Milestone: | → 1.5.0 |
Priority: | highest → normal |
Severity: | blocker → normal |
Version: | unspecified → 1.4.0 |
comment:5 by , 16 years ago
Keywords: | gtiff added |
---|---|
Milestone: | 1.5.0 |
deferred from 1.5 since it is primarily a geotiff/libgeotiff issue.
comment:6 by , 9 years ago
I do not know what would be the correct behaviour but I report what happens 7 years later with 2.0-dev:
This is what GDAL knows about EPSG:2065
gdalsrsinfo epsg:2065 PROJ.4 : '+proj=krovak +lat_0=49.5 +lon_0=42.5 +alpha=30.28813972222222 +k=0.999 9 +x_0=0 +y_0=0 +ellps=bessel +towgs84=589,76,480,0,0,0,0 +pm=ferro +units=m +no _defs ' OGC WKT : PROJCS["S-JTSK (Ferro) / Krovak", GEOGCS["S-JTSK (Ferro)", DATUM["System_Jednotne_Trigonometricke_Site_Katastralni_Ferro", SPHEROID["Bessel 1841",6377397.155,299.1528128, AUTHORITY["EPSG","7004"]], TOWGS84[589,76,480,0,0,0,0], AUTHORITY["EPSG","6818"]], PRIMEM["Ferro",-17.66666666666667, AUTHORITY["EPSG","8909"]], UNIT["degree",0.0174532925199433, AUTHORITY["EPSG","9122"]], AUTHORITY["EPSG","4818"]], PROJECTION["Krovak"], PARAMETER["latitude_of_center",49.5], PARAMETER["longitude_of_center",42.5], PARAMETER["azimuth",30.28813972222222], PARAMETER["pseudo_standard_parallel_1",78.5], PARAMETER["scale_factor",0.9999], PARAMETER["false_easting",0], PARAMETER["false_northing",0], UNIT["metre",1, AUTHORITY["EPSG","9001"]], AXIS["X",SOUTH], AXIS["Y",WEST], AUTHORITY["EPSG","2065"]]
This is what gdalinfo reports as a coordinate system of an image that I created with gdalwarp by using -t_srs epsg:2065
Coordinate System is: LOCAL_CS["S-JTSK (Ferro) / Krovak", GEOGCS["S-JTSK (Ferro)", DATUM["System_Jednotne_Trigonometricke_Site_Katastralni_Ferro", SPHEROID["Bessel 1841",6377397.155,299.1528128000009, AUTHORITY["EPSG","7004"]], TOWGS84[589,76,480,0,0,0,0], AUTHORITY["EPSG","6818"]], PRIMEM["Ferro",-17.66666666666667], UNIT["degree",0.0174532925199433], AUTHORITY["EPSG","4818"]], AUTHORITY["EPSG","2065"], UNIT["metre",1]]
comment:7 by , 9 years ago
Cc: | added |
---|
Hi Martin, Based on your changeset r28305 a few minutes ago you know the Krovak system. Could you perhaps say something about this ticket?
comment:8 by , 9 years ago
Jukka, Frank's initial statement is valid. There's no normalized way of representing the Krovak projection in GeoTIFF, with arbitrary values for the projection parameters. Currently the GeoTIFF writer will just manage to write Krovak projection as an EPSG code if there's an EPSG code associated with the SRS. The GeoTIFF reader however doesn't manage to make sense of it (although that could be easily workaround on GDAL side)
comment:9 by , 6 years ago
Type: | defect → enhancement |
---|
Reclassifying as an enhancement. The GeoTIFF spec needs to be updated first
comment:10 by , 5 years ago
Milestone: | → closed_because_of_github_migration |
---|---|
Resolution: | → wontfix |
Status: | assigned → closed |
This ticket has been automatically closed because Trac is no longer used for GDAL bug tracking, since the project has migrated to GitHub. If you believe this ticket is still valid, you may file it to https://github.com/OSGeo/gdal/issues if it is not already reported there.