[GRASS-dev] WinGRASS: r.in.gdal projection issue

GRASS GRASS developer
,
1

Hi all,

During WinGRASS 6.3.0 testings I encontered a problem with the r.in.gdal module: it reports no errors, and correctly import rasters, but fails creating the projection for the new location created during raster import.
I explain better with an example: I imported an SRTM tile, to be imported in a new location named “test”, with the following command line:

r.in.gdal {input=C:/Documents and Settings/Marco/Documenti/GIS Data Repository/SRTM v3.0 DEM 90m/Z_39_3.ASC} output=Z_39_3.dem location=test

At the end of the Run it reports as follows in the output window:

Location created

r.in.gdal complete.

After that I exit GRASS and I restart it accessing the location test: the raster have been correctly imported, the region set to the raster boundaries, but if type:

g.proj -j

it reports

XY (unprojected)

talking in IRC with a linux huy, I asked him to do the same command using the same raster with GRASS-6.3.0SVN: the location test, for him, has a correct projection (that is latlong wgs84 and so on…). So I guess that is a windows problem, but I don’t really know why since the command doesn’t report errors!

any suggestions?

This said I have another question for you: I have linux (ubuntu) installed on my system with xual boot along with xp pro sp2, but it’s really impossible to me to always reboot within the two systems to make tests, so today I decided to install VMware with an ubuntu (8.04) virtual machine. I would use this VM to make tests on GRASS and directly check if WinGRASS problems are strictly referred to windows platform or to other problems. Now I have a doubt:

  1. Install GRASS from a destributed package or

  2. Manually compile and install all the needed dependencies (if not already intalled, obviously) with the same support configuration as I did for the current WinGRASS release, in order to check if WinGRASS errors are generated by dependency issues and not by platform problems?

Thanks for your help,

Regards

Marco

2

Hi all,

I also tried to launch GRASS with GISBase without spaces (such as C:\GISBASE), with the demolocation, and placing the input file (Z_39_3.ASC) in a path without spaces too (C:), but I got the same result.

Marco

PS: VMware seems to not be a good solution, it requires a too performant hardware; I’ll go back with the linux dual boot solution.

Da: grass-dev-bounces@lists.osgeo.org per conto di marco.pasetti@alice.it
Inviato: ven 09/05/2008 16.51
A: grass-dev@lists.osgeo.org
Oggetto: [GRASS-dev] WinGRASS: r.in.gdal projection issue

Hi all,

During WinGRASS 6.3.0 testings I encontered a problem with the r.in.gdal module: it reports no errors, and correctly import rasters, but fails creating the projection for the new location created during raster import.
I explain better with an example: I imported an SRTM tile, to be imported in a new location named “test”, with the following command line:

r.in.gdal {input=C:/Documents and Settings/Marco/Documenti/GIS Data Repository/SRTM v3.0 DEM 90m/Z_39_3.ASC} output=Z_39_3.dem location=test

At the end of the Run it reports as follows in the output window:

Location created

r.in.gdal complete.

After that I exit GRASS and I restart it accessing the location test: the raster have been correctly imported, the region set to the raster boundaries, but if type:

g.proj -j

it reports

XY (unprojected)

talking in IRC with a linux huy, I asked him to do the same command using the same raster with GRASS-6.3.0SVN: the location test, for him, has a correct projection (that is latlong wgs84 and so on…). So I guess that is a windows problem, but I don’t really know why since the command doesn’t report errors!

any suggestions?

This said I have another question for you: I have linux (ubuntu) installed on my system with xual boot along with xp pro sp2, but it’s really impossible to me to always reboot within the two systems to make tests, so today I decided to install VMware with an ubuntu (8.04) virtual machine. I would use this VM to make tests on GRASS and directly check if WinGRASS problems are strictly referred to windows platform or to other problems. Now I have a doubt:

  1. Install GRASS from a destributed package or

  2. Manually compile and install all the needed dependencies (if not already intalled, obviously) with the same support configuration as I did for the current WinGRASS release, in order to check if WinGRASS errors are generated by dependency issues and not by platform problems?

Thanks for your help,

Regards

Marco

3

Hi all,

I also tried to launch GRASS with GISBase without spaces (such as C:\GISBASE), with the demolocation, and placing the input file (Z_39_3.ASC) in a path without spaces too (C:), but I got the same result.

Marco

PS: VMware seems to not be a good solution, it requires a too performant hardware; I’ll go back with the linux dual boot solution.

Da: grass-dev-bounces@lists.osgeo.org per conto di marco.pasetti@alice.it
Inviato: ven 09/05/2008 16.51
A: grass-dev@lists.osgeo.org
Oggetto: [GRASS-dev] WinGRASS: r.in.gdal projection issue

Hi all,

During WinGRASS 6.3.0 testings I encontered a problem with the r.in.gdal module: it reports no errors, and correctly import rasters, but fails creating the projection for the new location created during raster import.
I explain better with an example: I imported an SRTM tile, to be imported in a new location named “test”, with the following command line:

r.in.gdal {input=C:/Documents and Settings/Marco/Documenti/GIS Data Repository/SRTM v3.0 DEM 90m/Z_39_3.ASC} output=Z_39_3.dem location=test

At the end of the Run it reports as follows in the output window:

Location created

r.in.gdal complete.

After that I exit GRASS and I restart it accessing the location test: the raster have been correctly imported, the region set to the raster boundaries, but if type:

g.proj -j

it reports

XY (unprojected)

talking in IRC with a linux huy, I asked him to do the same command using the same raster with GRASS-6.3.0SVN: the location test, for him, has a correct projection (that is latlong wgs84 and so on…). So I guess that is a windows problem, but I don’t really know why since the command doesn’t report errors!

any suggestions?

This said I have another question for you: I have linux (ubuntu) installed on my system with xual boot along with xp pro sp2, but it’s really impossible to me to always reboot within the two systems to make tests, so today I decided to install VMware with an ubuntu (8.04) virtual machine. I would use this VM to make tests on GRASS and directly check if WinGRASS problems are strictly referred to windows platform or to other problems. Now I have a doubt:

  1. Install GRASS from a destributed package or

  2. Manually compile and install all the needed dependencies (if not already intalled, obviously) with the same support configuration as I did for the current WinGRASS release, in order to check if WinGRASS errors are generated by dependency issues and not by platform problems?

Thanks for your help,

Regards

Marco

4

On Fri, 9 May 2008 marco.pasetti@alice.it wrote:

Hi all,

I also tried to launch GRASS with GISBase without spaces (such as C:\GISBASE), with the demolocation, and placing the input file (Z_39_3.ASC) in a path without spaces too (C:\), but I got the same result.

Hello Marco,
How big is the file? Would it be possible to put it somewhere for me to have a look at and try and reproduce the behaviour?

FWIW, other things to try would be to see if other commands can read the projection info from the file. E.g.
gdalinfo filename
g.proj -p georef=filename

Paul

5

marco.pasetti@alice.it wrote:

During WinGRASS 6.3.0 testings I encontered a problem with the r.in.gdal
module: it reports no errors, and correctly import rasters, but fails
creating the projection for the new location created during raster
import.
I explain better with an example: I imported an SRTM tile, to be
imported in a new location named "test", with the following command
line:

r.in.gdal {input=C:/Documents and Settings/Marco/Documenti/GIS Data
Repository/SRTM v3.0 DEM 90m/Z_39_3.ASC} output=Z_39_3.dem
location=test

At the end of the Run it reports as follows in the output window:

Location <test> created

r.in.gdal complete.

After that I exit GRASS and I restart it accessing the location test:
the raster have been correctly imported, the region set to the raster
boundaries, but if type:

g.proj -j

it reports

XY (unprojected)

talking in IRC with a linux huy, I asked him to do the same command
using the same raster with GRASS-6.3.0SVN: the location test, for him,
has a correct projection (that is latlong wgs84 and so on...). So I
guess that is a windows problem, but I don't really know why since the
command doesn't report errors!

any suggestions?

Check the existence and contents of the following:

  <database>/test/
  <database>/test/PERMANENT/
  <database>/test/PERMANENT/DEFAULT_WIND
  <database>/test/PERMANENT/PROJ_INFO
  <database>/test/PERMANENT/PROJ_UNITS

where <database> is the GRASS database directory.

In particular, check whether the files have Unix (LF) or DOS (CR+LF)
line endings (if the files look correct in Notepad, they have DOS line
endings; with Unix line endings, you get one long line with little
black blocks).

--
Glynn Clements <glynn@gclements.plus.com>

6

Hi Glynn,

In PERMANENT I have WIND and DEFAULT_WIND; they have Unix line endings.
PROJ_* files are missing!

Many thanks

Marco

Da: Glynn Clements [mailto:glynn@gclements.plus.com]
Inviato: dom 11/05/2008 7.12
A: marco.pasetti@alice.it
Cc: grass-dev@lists.osgeo.org
Oggetto: Re: [GRASS-dev] WinGRASS: r.in.gdal projection issue

marco.pasetti@alice.it wrote:

During WinGRASS 6.3.0 testings I encontered a problem with the r.in.gdal
module: it reports no errors, and correctly import rasters, but fails
creating the projection for the new location created during raster
import.
I explain better with an example: I imported an SRTM tile, to be
imported in a new location named “test”, with the following command
line:

r.in.gdal {input=C:/Documents and Settings/Marco/Documenti/GIS Data
Repository/SRTM v3.0 DEM 90m/Z_39_3.ASC} output=Z_39_3.dem
location=test

At the end of the Run it reports as follows in the output window:

Location created

r.in.gdal complete.

After that I exit GRASS and I restart it accessing the location test:
the raster have been correctly imported, the region set to the raster
boundaries, but if type:

g.proj -j

it reports

XY (unprojected)

talking in IRC with a linux huy, I asked him to do the same command
using the same raster with GRASS-6.3.0SVN: the location test, for him,
has a correct projection (that is latlong wgs84 and so on…). So I
guess that is a windows problem, but I don’t really know why since the
command doesn’t report errors!

any suggestions?

Check the existence and contents of the following:

/test/
/test/PERMANENT/
/test/PERMANENT/DEFAULT_WIND
/test/PERMANENT/PROJ_INFO
/test/PERMANENT/PROJ_UNITS

where is the GRASS database directory.

In particular, check whether the files have Unix (LF) or DOS (CR+LF)
line endings (if the files look correct in Notepad, they have DOS line
endings; with Unix line endings, you get one long line with little
black blocks).

–
Glynn Clements glynn@gclements.plus.com

7

Marco:

> r.in.gdal {input=C:/Documents and Settings/Marco/Documenti/GIS Data
> Repository/SRTM v3.0 DEM 90m/Z_39_3.ASC} output=Z_39_3.dem
> location=test

...

In PERMANENT I have WIND and DEFAULT_WIND; they have Unix
line endings. PROJ_* files are missing!

The PROJ_* files are missing because it is a XY location, ie without projection. Nothing unusual there.

** what does gdalinfo say about the original file?

I would guess that the *.ASC file does not contain projection info, and therefore it gets imported as XY.

what do the top few lines of the ASC file look like? any .prj or .tfw ... files kicking about with the same basename?

Hamish

      ____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

8

Hi Paul,

How big is the file? Would it be possible to put it somewhere for me to
have a look at and try and reproduce the behaviour?

the file is available here:

http://armadillo.geog.kcl.ac.uk/portal/srtm3/srtm_data_arcascii/srtm_39_03.zip

(I selected the server nearest to you)

gdalinfo filename

gdalinfo {C:/Documents and Settings/Marco/Documenti/GIS Data Repository/SRTM v3.0 DEM 90m/Z_39_3.ASC}

output:

Driver: AAIGrid/Arc/Info ASCII Grid
Files: C:/Documents and Settings/Marco/Documenti/GIS Data Repository/SRTM v3.0 DEM 90m/Z_39_3.ASC
Size is 6000, 6000
Coordinate System is `’
Origin = (10.000000000000000,49.999999999999979)
Pixel Size = (0.000833333333333,-0.000833333333333)
Corner Coordinates:
Upper Left ( 10.0000000, 50.0000000)
Lower Left ( 10.0000000, 45.0000000)
Upper Right ( 15.0000000, 50.0000000)
Lower Right ( 15.0000000, 45.0000000)
Center ( 12.5000000, 47.5000000)
Band 1 Block=6000x1 Type=Int16, ColorInterp=Undefined
NoData Value=-9999

g.proj -p georef=filename

g.proj -p {georef=C:/Documents and Settings/Marco/Documenti/GIS Data Repository/SRTM v3.0 DEM 90m/Z_39_3.ASC}

output:

XY location (unprojected)
Trying to open with OGR…
Trying to open with GDAL…
…succeeded.
Read of file C:/Documents and Settings/Marco/Documenti/GIS Data Repository/SRTM v3.0 DEM 90m/Z_39_3.ASC was successful, but it did not contain projection information. ‘XY (unprojected)’ will be used

It seems that it cannot read the coordinate system (or that it is not present… but I beleive in the first option).
Probably we should need to search the problem in the GDAL build?
Here the current GDAL (1.5.1) configuration:

GDAL is now configured for i686-pc-mingw32

  Installation directory:    	/usr/local
  C compiler:                	gcc -g -O2
  C++ compiler:              	g++ -g -O2

  LIBTOOL support:           	yes

  LIBZ support:              	internal
  GRASS support:             	no
  CFITSIO support:           	no
  PCRaster support:          	internal
  NetCDF support:            	no
  LIBPNG support:            	internal
  LIBTIFF support:           	internal (BigTIFF=yes)
  LIBGEOTIFF support:        	internal
  LIBJPEG support:           	internal
  LIBGIF support:            	internal
  OGDI support:              	no
  HDF4 support:              	no
  HDF5 support:              	no
  Kakadu support:            	no
  JasPer support:            	no
  ECW support:               	no
  MrSID support:             	no
  GRIB support:              	no
  cURL support (wms/wcs/...):	no
  PostgreSQL support:        	yes
  MySQL support:             	no
  Xerces-C support:            	no
  Expat support:             	yes
  ODBC support:              	no
  PGeo support:              	no
  OCI support:               	no
  SDE support:               	no
  DODS support:              	no
  SQLite support:            	yes
  DWGdirect support          	no
  PANORAMA GIS support:      	no
  INFORMIX DataBlade support:	no
  GEOS support:              	yes

  Old-gen python          	no
  SWIG Bindings:          	no

  Statically link PROJ.4:    	no
  enable OGR building:       	yes
  enable pthread support:    	no
  hide internal symbols:     	no

Regards,

Marco

Da: Paul Kelly [mailto:paul-grass@stjohnspoint.co.uk]
Inviato: sab 10/05/2008 12.11
A: marco.pasetti@alice.it
Cc: grass-dev@lists.osgeo.org
Oggetto: Re: R: [GRASS-dev] WinGRASS: r.in.gdal projection issue

On Fri, 9 May 2008 marco.pasetti@alice.it wrote:

Hi all,

I also tried to launch GRASS with GISBase without spaces (such as C:\GISBASE), with the demolocation, and placing the input file (Z_39_3.ASC) in a path without spaces too (C:), but I got the same result.

Hello Marco,
How big is the file? Would it be possible to put it somewhere for me to
have a look at and try and reproduce the behaviour?

FWIW, other things to try would be to see if other commands can read the
projection info from the file. E.g.
gdalinfo filename
g.proj -p georef=filename

Paul

9

Marco:

>gdalinfo filename

gdalinfo {C:/Documents and Settings/Marco/Documenti/GIS
Data Repository/SRTM v3.0 DEM 90m/Z_39_3.ASC}

output:

Driver: AAIGrid/Arc/Info ASCII Grid
Files: C:/Documents and Settings/Marco/Documenti/GIS Data
Repository/SRTM v3.0 DEM 90m/Z_39_3.ASC
Size is 6000, 6000
Coordinate System is `'

                    ^^^^^^^^
no coordinate system is defined == XY.

any support files come with it that supply that information?

Hamish

      ____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

10

Hi Hamish,

no coordinate system is defined == XY

yes, it seemed the same to me (I also opened the ASC file and I didn’t find any information about the projection), but a linux user on IRC did the same command (on my request) and told me that on linux it created the location ‘test’ with proj defined.

any support files come with it that supply that information?

no. There’s only the MASK file, but I haven’t it because the file is not available on the server.

The best thing is that someone else could try to import the same file [1] with the same command.

[1] http://srtm.jrc.it/SRTM_Data_ArcAscii/srtm_39_03.zip

Regards,

Marco

Da: Hamish [mailto:hamish_b@yahoo.com]
Inviato: lun 12/05/2008 10.42
A: marco.pasetti@alice.it
Cc: grass-dev@lists.osgeo.org
Oggetto: Re: R: R: [GRASS-dev] WinGRASS: r.in.gdal projection issue

Marco:

gdalinfo filename

gdalinfo {C:/Documents and Settings/Marco/Documenti/GIS
Data Repository/SRTM v3.0 DEM 90m/Z_39_3.ASC}

output:

Driver: AAIGrid/Arc/Info ASCII Grid
Files: C:/Documents and Settings/Marco/Documenti/GIS Data
Repository/SRTM v3.0 DEM 90m/Z_39_3.ASC
Size is 6000, 6000
Coordinate System is `’

^^^^^^^^
no coordinate system is defined == XY.

any support files come with it that supply that information?

Hamish

Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

11

On Mon, 12 May 2008 marco.pasetti@alice.it wrote:

Hi Paul,

How big is the file? Would it be possible to put it somewhere for me to
have a look at and try and reproduce the behaviour?

the file is available here:

http://armadillo.geog.kcl.ac.uk/portal/srtm3/srtm_data_arcascii/srtm_39_03.zip

I get a 404 not found error on that file.

(I selected the server nearest to you)

gdalinfo filename

gdalinfo {C:/Documents and Settings/Marco/Documenti/GIS Data Repository/SRTM v3.0 DEM 90m/Z_39_3.ASC}

output:

Driver: AAIGrid/Arc/Info ASCII Grid
Files: C:/Documents and Settings/Marco/Documenti/GIS Data Repository/SRTM v3.0 DEM 90m/Z_39_3.ASC
Size is 6000, 6000
Coordinate System is `'

As Hamish said, this means the file doesn't contain projection information. Or if it does, GDAL can't read it, thus not a GRASS problem. Probably though there is simply no projection information present?

Paul

12

Hi Paul,

I get a 404 not found error on that file.

sorry, I supposed that is was working. The following works, I checked it out:

http://srtm.jrc.it/SRTM_Data_ArcAscii/srtm_39_03.zip

Probably though there is simply no projection information present?

Yes, I suppose. But why the guy on IRC told me that it worked for him? Did he lie?

Marco

Da: Paul Kelly [mailto:paul-grass@stjohnspoint.co.uk]
Inviato: lun 12/05/2008 11.28
A: marco.pasetti@alice.it
Cc: grass-dev@lists.osgeo.org
Oggetto: Re: R: R: [GRASS-dev] WinGRASS: r.in.gdal projection issue

On Mon, 12 May 2008 marco.pasetti@alice.it wrote:

Hi Paul,

How big is the file? Would it be possible to put it somewhere for me to
have a look at and try and reproduce the behaviour?

the file is available here:

http://armadillo.geog.kcl.ac.uk/portal/srtm3/srtm_data_arcascii/srtm_39_03.zip <http://armadillo.geog.kcl.ac.uk/portal/srtm3/srtm_data_arcascii/srtm_39_03.zip>

I get a 404 not found error on that file.

(I selected the server nearest to you)

gdalinfo filename

gdalinfo {C:/Documents and Settings/Marco/Documenti/GIS Data Repository/SRTM v3.0 DEM 90m/Z_39_3.ASC}

output:

Driver: AAIGrid/Arc/Info ASCII Grid
Files: C:/Documents and Settings/Marco/Documenti/GIS Data Repository/SRTM v3.0 DEM 90m/Z_39_3.ASC
Size is 6000, 6000
Coordinate System is `’

As Hamish said, this means the file doesn’t contain projection
information. Or if it does, GDAL can’t read it, thus not a GRASS problem.
Probably though there is simply no projection information present?

Paul