Opened 12 years ago

Closed 4 weeks 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 warmerdam)

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:1 Changed 12 years ago by warmerdam

Markus,

I believe the geotiff specification has no mention of the krovak projection
method, the the specification would have to be implicitly or explicitly 
extended for this to be possible. 

I doubt I'll be acting on this immediately, but I'll keep the bug open.

comment:4 Changed 12 years ago by warmerdam

Description: modified (diff)
Milestone: 1.5.0
Priority: highestnormal
Severity: blockernormal
Version: unspecified1.4.0

comment:5 Changed 11 years ago by warmerdam

Keywords: gtiff added
Milestone: 1.5.0

deferred from 1.5 since it is primarily a geotiff/libgeotiff issue.

comment:6 Changed 4 years ago by Jukka Rahkonen

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 Changed 4 years ago by Jukka Rahkonen

Cc: martinl 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 Changed 4 years ago by Even Rouault

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 Changed 14 months ago by Even Rouault

Type: defectenhancement

Reclassifying as an enhancement. The GeoTIFF spec needs to be updated first

comment:10 Changed 4 weeks ago by Even Rouault

Milestone: closed_because_of_github_migration
Resolution: wontfix
Status: assignedclosed

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.

Note: See TracTickets for help on using tickets.