Marco,
I reported something similar a month or so back. Some of my students using
WinGRASS would import an SRTM or other file--or they would make a location
from an EPSG code. Then when they tried to reproject into another location,
they'd get an error that there is no projection file.
It seems most common (only?) with some latlon locations. UTM's seem OK. It
is also somewhat erratic. I assume that it is either a g.proj error or a bad
EPSG entry.
Michael
On 5/9/08 8:35 PM, "grass-dev-request@lists.osgeo.org"
<grass-dev-request@lists.osgeo.org> wrote:
Message: 1
Date: Fri, 9 May 2008 18:38:01 +0200
From: <marco.pasetti@alice.it>
Subject: R: [GRASS-dev] WinGRASS: r.in.gdal projection issue
To: <marco.pasetti@alice.it>, <grass-dev@lists.osgeo.org>
Message-ID:
<FA8A693893F4CE4283B4473C79FA47D505BB41CF@FBCMST06V02.fbc.local>
Content-Type: text/plain; charset="iso-8859-1"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 issueHi 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=testAt 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?
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.osgeo.org/pipermail/grass-dev/attachments/20080509/1255b67d/attac
hment-0001.html------------------------------
__________________________________________
Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University
phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton
