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

marco.pasetti at alice.it marco.pasetti at alice.it
Mon May 12 04:30:06 EDT 2008


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 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 at stjohnspoint.co.uk]
Inviato: sab 10/05/2008 12.11
A: marco.pasetti at alice.it
Cc: grass-dev at lists.osgeo.org
Oggetto: Re: R: [GRASS-dev] WinGRASS: r.in.gdal projection issue



On Fri, 9 May 2008 marco.pasetti at 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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/grass-dev/attachments/20080512/63d15586/attachment.html


More information about the grass-dev mailing list