[GRASS-dev] Proj4 string not shown in loc wiz when creating new location from file

Hamish hamish_b at yahoo.com
Tue Jun 18 21:42:34 PDT 2013

MarkusN wrote:
> greetings from the amazing FOSS4G-CEE here in Bucharest
> http://2013.foss4g-cee.org/program/schedule

and greetings back to all you meet there, :)
will your history of geoFOSS slides go online?

> Preparing my slides I remembered an issue that the proj4 string is not
> shown in case of generating a new location from a GeoTIFF (attached)
> or SHP.

hmmm, I tested that a couple weeks ago and it was working, but now it doesn't
work for me using either your sample tiff or some I have locally. WKT & .prj
creation method similarly has no output in the summary page, same with .shp.
The locations are created ok though except I don't get prompted for datum
transform terms.

> When using EPSG code as base for the new location this works fine.
> I can of course open a ticket but perhaps it is just an "easy"
> omission in the code.

Some tests:

gdalinfo shows:
PROJCS["Lambert Azimuthal Equal Area",
    GEOGCS["GCS Name = grs80|Ellipsoid = Geodetic_Reference_System_1980|Primem = Greenwich|",
            SPHEROID["GRS 1980",6378137,298.2572221010002,

here is a little shell script to create a .prj file from that:
TOP=`gdalinfo "$GEOTIFF" | grep -n -m 1 '^Coordinate System is:$' | cut -f1 -d:`
BOT=`gdalinfo "$GEOTIFF" | grep -n -m 1 '^Origin = ' | cut -f1 -d:`
BOT=`expr "$BOT" - 1`
LINES=`expr "$BOT" - "$TOP"`

gdalinfo "$GEOTIFF" | head -n "$BOT" | tail -n "$LINES" > `basename "$GEOTIFF" .tif`.prj

Is the first term of the above GEOGCS string legit or is it a r.out.gdal string error?
(it doesn't seem to be the problem though, with  the other GeoTiff I had locally with
just "international" datum there, it still gave no +proj terms in the summary)

Using 'create new location from georef'd file' (latest 6.4.3svn) I end up with a
new location showing:

name       : Lambert Azimuthal Equal Area
proj       : laea
datum      : etrs89
ellps      : grs80
lat_0      : 52
lon_0      : 10
x_0        : 4321000
y_0        : 3210000
no_defs    : defined
unit       : metre
units      : metres
meters     : 1

which looks ok. I think the only data loss there is the Primem = Greenwich,
but that may just be left off as matching the default.

I'll have a look at the code... perhaps due to a glitch in the last commit there.


More information about the grass-dev mailing list