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:[EMAIL PROTECTED] Inviato: sab 10/05/2008 12.11 A: [EMAIL PROTECTED] Cc: [email protected] Oggetto: Re: R: [GRASS-dev] WinGRASS: r.in.gdal projection issue On Fri, 9 May 2008 [EMAIL PROTECTED] 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
_______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
