<html style="direction: ltr;">
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
<style type="text/css">body p { margin-bottom: 0cm; margin-top: 0pt; } </style>
</head>
<body style="direction: ltr;"
bidimailui-detected-decoding-type="latin-charset" bgcolor="#FFFFFF"
text="#000000">
Hi Chris<br>
(now it's morning here :-)<br>
<br>
I never had occasion to use the -m option to r.out.ascii. I guess
that since MODFLOW is a fortran program, and fortran uses scientific
notation, that's why the -m flag produces that scientific notation.<br>
<br>
But I was curious, so I tired to recreate your steps. Here's what I
did:<br>
Downloaded the netcdf temp data from <br>
<address><a class="moz-txt-link-freetext"
href="https://www.esrl.noaa.gov/psd/data/gridded/data.UDel_AirT_Precip.html">https://www.esrl.noaa.gov/psd/data/gridded/data.UDel_AirT_Precip.html</a></address>
<br>
I got just the Apr 2014 slice with:<br>
<font size="+1"><tt>ncks -d time,1369,1369 air.mon.mean.v401.nc
air_april2014.nc</tt></font><br>
<br>
GRASS can read in netcdf, so in a Lon/Lat Location I ran:<br>
<font size="+1"><tt>r.in.gdal -l -o input=air_april2014.nc
output=air_apr14 </tt><tt><br>
</tt></font><br>
Next I set the computational region to 0.25 degrees:<br>
<tt><font size="+1">g.region -p rast=air_apr14 res=0:15<br>
</font></tt><br>
And I create a new raster at that resolution:<br>
<font size="+1"><tt>r.mapcalc "air_apr14_25 = air_apr14"</tt><tt><br>
</tt></font><br>
I can now export to an ascii file, as you did, which gives the rows
and cols as you showed. <br>
Although it's not clear yet what you need excel for? I want to
believe that whatever your needs are, it can be done right in GIS.<br>
<br>
Regards,<br>
Micha<br>
<br>
<div class="moz-cite-prefix">On 01/21/2017 02:15 AM,
Bartolomei.Chris wrote:<br>
</div>
<blockquote cite="mid:097f95ee6ee9416c8d73d7dcd72e1adc@ensco.com"
type="cite">
<pre wrap="">I think I found one of my problems working with the data and why it was lining up ... in Excel, if you use a space delimiter, the text-to-columns treats consecutive spaces as one ... you need to disable that (a checkbox). That still doesn't fix the scientific notation issue, but the process I'm using now seems to work.
:)
Chris
________________________________
From: Bartolomei.Chris
Sent: Friday, January 20, 2017 10:39 AM
To: Micha Silver; grass-user
Subject: Re: [GRASS-user] r.out.ascii not functioning for floating point values
Good (morning?) Micha :)
r.out.ascii dumps the values, not the x,y locations - that is r.out.xyz ... and r.out.ascii is indeed generating the scientific notation - I've pulled the output file up in Notepad++ to view the raw data and here's what I see for rows with data values (a snippet):
-4.9e+001-4.9e+001-5.0e+001-5.0e+001-4.9e+001-4.9e+001-5.0e+001-5.0e+001
and here's what I see for rows with no data (also a snippet):
0.0e+0000.0e+0000.0e+0000.0e+0000.0e+0000.0e+0000.0e+0000.0e+0000.0e+0000.0e+000
Note that 1) there is no way to turn scientific notation off (these are mean monthly temperatures so the values are <100 and 2 decimal places) and 2) there is nothing separating the values generated 3) This does not happen if the values are integers
Testing this morning:
If I do not use the MODFLOW checkbox, then this is what I get for no data rows:
* * * * * * * * * * * * * * * * * * * * * *
and this is what I get for rows with values:
-42.3 -42.3 -41.2 -41.2 -43.5 -43.5
but the number of values in each row vary from .... awww man .... wtf? I just reran this without the MODFLOW check box and now the data all lines up correctly ... that is weird (but good news!)
stay tuned - I'll repost more if this messes up again. My guess is that the module remembered a setting of something from the numerous times I tried different values. When in doubt, reboot, right?
Here's what I just ran in case anyone else needs the settings:
r.out.ascii -h --overwrite input=AirTemp_Test2@Zoonotic output=D:\air_temp_2014\Test3 precision=3 (note I did not set the width value here)
Wow - that was really really strange. Well - I'm not going to kick good news around - the issue with MODFLOW and floating point values should still be looked at though. I reran the MODFLOW option this morning as well and I get the same results as described above.
Chris
Chris Bartolomei P.E.
<a class="moz-txt-link-abbreviated" href="mailto:bartolomei.chris@ensco.com">bartolomei.chris@ensco.com</a>
________________________________
From: Micha Silver <a class="moz-txt-link-rfc2396E" href="mailto:tsvibar@gmail.com"><tsvibar@gmail.com></a>
Sent: Friday, January 20, 2017 9:52 AM
To: Bartolomei.Chris; grass-user
Subject: Re: [GRASS-user] r.out.ascii not functioning for floating point values
Hello Chris
What is it that you're trying to do in Excel?? Chances are that you can do any analysis you want right in the GIS.
The scientific notation is surely from Excel, r.out.ascii just dumps a list of three numbers: x,y, and raster values. All in straight ascii.
On 01/20/2017 01:24 PM, Bartolomei.Chris wrote:
I am using GRASS GIS 7.2 on a Windows 10 system with 32Gb ram. OSGEO4W distribution (with msys)
The region is lat/lon (-180 to 180, 90 to -90) and the resolution NS is 00:15 and EW is 00:15
I am trying to export a raster into a grid (array) that I can use in Excel but am getting unusable output ... Here's what I do:
I create a text file in Excel with the data (University of Delaware - Global Monthly Mean Temperatures, 2014, using April) and add the header rows:
ncols 720
nrows 360
xllcorner -180
yllcorner -90
cellsize .50
nodata_value -99999
each cell has some value in it, if it isn't "-99999" then it is a floating point number (signed, 2 decimal places)
I save it as a space-sparated text file with a .asc extension
I import the raster using r.in.arc (r.in.arc input=AirTemp_Test2.asc output=AirTemp_Test2 type=FCELL --overwrite) which imports fine.
My region is set as described above and now I want to resample on the fly and export an ASCII grid I can use in Excel so I want new each row of data to have 1440 columns (since the new resolution is 2x the original)
I have tried r.out.ascii (r.out.ascii -h -m input=AirTemp_Test2 output=D:\air_temp_2014\Test2.txt precision=2 width=1440 --overwrite) but the problem I have is that it is floating point values and for some reason all of the data exported into the ASCII grid is in scientific notation with no separation between the values. In order to get an even 1440 x 720 ASCII grid, I need to check the "Write MODFLOW (USGS) ASCII array" box in the GUI and set the number of significant digits to 2 (otherwise you just get integers) and the wrapping number to 1440 ... this works fine for integers but defaults to the scientific notation for floating point which since there are no value separators, can't be worked with (integers are separated by a space). Two things: can we turn off scientific notation?, and add a separator for floating point values ... (please)
If I do not check the MODFLOW box, the grid output has the appropriate number of rows (720) but many of them have their data truncated. Every row should have 1440 values.
I have tried r.out.arc (r.out.arc input=AirTemp_Test2 output=AirTest2 dp=2 --overwrite) as well and while it generates the grid with space-separated values, they also seem to be truncated ... the truncation is not consistent either...
Am I doing something really wrong here ???
Thanks :)
Chris Bartolomei P.E.
<a class="moz-txt-link-abbreviated" href="mailto:bartolomei.chris@ensco.com">bartolomei.chris@ensco.com</a><a class="moz-txt-link-rfc2396E" href="mailto:bartolomei.chris@ensco.com"><mailto:bartolomei.chris@ensco.com></a>
________________________________
The information contained in this email message is intended only for the use of the individual(s) to whom it is addressed and may contain information that is privileged and sensitive. If you are not the intended recipient, or otherwise have received this communication in error, please notify the sender immediately by email at the above referenced address and note that any further dissemination, distribution or copying of this communication is strictly prohibited.
The U.S. Export Control Laws regulate the export and re-export of technology originating in the United States. This includes the electronic transmission of information and software to foreign countries and to certain foreign nationals. Recipient agrees to abide by these laws and their regulations -- including the U.S. Department of Commerce Export Administration Regulations and the U.S. Department of State International Traffic in Arms Regulations -- and not to transfer, by electronic transmission or otherwise, any content derived from this email to either a foreign national or a foreign destination in violation of such laws.
_______________________________________________
grass-user mailing list
<a class="moz-txt-link-abbreviated" href="mailto:grass-user@lists.osgeo.org">grass-user@lists.osgeo.org</a><a class="moz-txt-link-rfc2396E" href="mailto:grass-user@lists.osgeo.org"><mailto:grass-user@lists.osgeo.org></a>
<a class="moz-txt-link-freetext" href="https://lists.osgeo.org/mailman/listinfo/grass-user">https://lists.osgeo.org/mailman/listinfo/grass-user</a><a class="moz-txt-link-rfc2396E" href="https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.osgeo.org_mailman_listinfo_grass-2Duser&d=CwMCaQ&c=DsZY2bea7iNIzyp-7sZ0t0F2UfNQZUfZhEPCv_2wBI0&r=O31ltou6ygJL2Y01kQyNJJD2kiILIsbyz2V0Hn4lFUY&m=k8AfdIjl1AEJxJiMQfhR2c6pruk63nVNG6kiAa5MB28&s=gF15Q9u5Hv0hknrFNrvk9l5kfXEuK9HXYuOyJ0nvvNs&e="><https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.osgeo.org_mailman_listinfo_grass-2Duser&d=CwMCaQ&c=DsZY2bea7iNIzyp-7sZ0t0F2UfNQZUfZhEPCv_2wBI0&r=O31ltou6ygJL2Y01kQyNJJD2kiILIsbyz2V0Hn4lFUY&m=k8AfdIjl1AEJxJiMQfhR2c6pruk63nVNG6kiAa5MB28&s=gF15Q9u5Hv0hknrFNrvk9l5kfXEuK9HXYuOyJ0nvvNs&e=></a>
</pre>
</blockquote>
<br>
</body>
</html>