<HTML dir=ltr><HEAD>
<META http-equiv=Content-Type content="text/html; charset=unicode">
<META content="MSHTML 6.00.6000.16640" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT face=Arial color=#000000 size=2>Hi all,</FONT></DIV>
<DIV><FONT size=2></FONT> </DIV>
<DIV><FONT size=2>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.</FONT></DIV>
<DIV><FONT size=2>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:</FONT></DIV>
<DIV><FONT size=2></FONT> </DIV>
<DIV><FONT size=2><FONT face="Courier New">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</FONT></DIV>
<DIV>
<P>At the end of the Run it reports as follows in the output window:</P>
<P><FONT face="Courier New">Location <test> created</FONT></P>
<P><FONT face="Courier New">r.in.gdal complete.</FONT></P>
<P>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:</P>
<P><FONT face="Courier New">g.proj -j</FONT></P>
<P>it reports</P>
<P><FONT face="Courier New">XY (unprojected)</FONT></P>
<P>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!</P>
<P>any suggestions?</P>
<P>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:</P>
<P>1. Install GRASS from a destributed package or</P>
<P>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?</P>
<P>Thanks for your help,</P>
<P>Regards</P>
<P>Marco</P></FONT></DIV></BODY></HTML>