Opened 2 years ago

Closed 6 months ago

Last modified 5 months ago

#3059 closed defect (fixed)

r.external.out does not write CRS information

Reported by: sbl Owned by: grass-dev@…
Priority: major Milestone: 7.4.1
Component: Raster Version: 7.0.4
Keywords: r.external.out Cc:
CPU: Unspecified Platform: Unspecified

Description

At least for GeoTiffs?, which is the format I used, files created with r.external.out do not contain any CRS information.

The CRS is a central piece of information for a spatial data set and should not get lost during export.

In order to reproduce try:

g.proj -g
r.external.out directory=tmp extension=.tif format=GTiff options="COMPRESS=LZW,PREDICTOR=2"
r.mapcalc expression="test=1"
gdalinfo $GISDBASE/$LOCATION/$MAPSET/tmp/test.tif | grep -A 5 "Coordinate System"

Change History (10)

comment:1 Changed 2 years ago by sbl

Some additional observations: A colleague and me are facing significant "interoperability problems" with GeoTiffs? produced with r.external.out, which (after FTP transfer) could not be opened in ENVI.

ENVI complains about broken corner coordinates and a corrupted LZW-table.

The files are solar radiation grids (all integer) and are saved as Int32 by r.external.out. They were results from a tiled processing which was merged using r.patch. When I export via r.out.gdal I get a warning message that Metadata exceeds 32000 bytes and cannot be written to GeoTiff?, and therefore will be transferred to PAM. So this is possibly related to #3056

comment:2 Changed 2 years ago by neteler

Component: DefaultRaster
Priority: normalmajor

I can reproduce it with the NC location:

# NC Location
g.region raster=elevation -p

g.proj -w
PROJCS["Lambert Conformal Conic",
    GEOGCS["grs80",
        DATUM["North_American_Datum_1983",
            SPHEROID["Geodetic_Reference_System_1980",6378137,298.257222101]],
        PRIMEM["Greenwich",0],
        UNIT["degree",0.0174532925199433]],
    PROJECTION["Lambert_Conformal_Conic_2SP"],
    PARAMETER["standard_parallel_1",36.16666666666666],
    PARAMETER["standard_parallel_2",34.33333333333334],
    PARAMETER["latitude_of_origin",33.75],
    PARAMETER["central_meridian",-79],
    PARAMETER["false_easting",609601.22],
    PARAMETER["false_northing",0],
    UNIT["Meter",1]]

mkdir -p $HOME/tmp
r.external.out directory=$HOME/tmp extension=.tif format=GTiff options="COMPRESS=LZW,PREDICTOR=2"

r.mapcalc expression="test = 1"

gdalinfo $HOME/tmp/test.tif
Driver: GTiff/GeoTIFF
Files: test.tif
Size is 1500, 1350
Coordinate System is `'
Origin = (630000.000000000000000,228500.000000000000000)
Pixel Size = (10.000000000000000,-10.000000000000000)
Image Structure Metadata:
  COMPRESSION=LZW
  INTERLEAVE=BAND
Corner Coordinates:
...

Apparently some GDAL part is not initialized completely. I see in

https://trac.osgeo.org/grass/browser/grass/trunk/lib/raster/gdal.c#L431

that the use of GPJ_grass_to_wkt() is commented. Maybe that part needs to be updated/completed?

comment:3 in reply to:  2 ; Changed 2 years ago by glynn

Replying to neteler:

Apparently some GDAL part is not initialized completely. I see in

https://trac.osgeo.org/grass/browser/grass/trunk/lib/raster/gdal.c#L431

that the use of GPJ_grass_to_wkt() is commented. Maybe that part needs to be updated/completed?

The main problem is that gproj depends upon libgis, which means that libgis cannot depend upon gproj. However, it may be possible to load gproj dynamically, in the same manner as GDAL. The only other option is to merge gproj into libgis, making GDAL (along with its large and open-ended set of dependencies) a hard dependency of libgis.

comment:4 in reply to:  3 Changed 2 years ago by neteler

Replying to glynn:

Replying to neteler:

Apparently some GDAL part is not initialized completely. I see in

https://trac.osgeo.org/grass/browser/grass/trunk/lib/raster/gdal.c#L431

that the use of GPJ_grass_to_wkt() is commented. Maybe that part needs to be updated/completed?

The main problem is that gproj depends upon libgis, which means that libgis cannot depend upon gproj. However, it may be possible to load gproj dynamically, in the same manner as GDAL.

Rather than merging libproj into libgis, your suggestion of dynamical loading of libproj sounds more viable to avoid a dependency "hell".

comment:5 Changed 22 months ago by neteler

Milestone: 7.0.57.0.6

comment:6 Changed 21 months ago by sbl

See also: #3191 and #3193

comment:7 Changed 6 months ago by neteler

Since we run again into this problem, is there a way to "attach" the CRS?

comment:8 in reply to:  7 Changed 6 months ago by mmetz

Replying to neteler:

Since we run again into this problem, is there a way to "attach" the CRS?

Yes, there is no dependency hell any more because library raster fns are now (as of GRASS 7) in a separate library which can nowbe dependent on libproj.

Please try trunk r72098 and relbr74 r72099.

comment:9 Changed 6 months ago by sbl

Milestone: 7.0.67.4.0
Resolution: fixed
Status: newclosed

Thanks Markus! I can confirm that projection information now is written to GeoTiffs? produced with r.external.out in GRASS 7.4. However, like in r.out.gdal EPSG codes of the projections are not written here either (see #3048). Even for Locations purely created from EPSG code. Would be really helpful if EPSG codes somehow could be added where appropriate (and recorded in the projection information in GRASS).

comment:10 Changed 5 months ago by mmetz

Milestone: 7.4.07.4.1

adjust milestone

Note: See TracTickets for help on using tickets.