Re: [GRASS-user] r.out.ascii not functioning for floating point values

2017-01-20 Thread Bartolomei.Chris 
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+.0e+.0e+.0e+.0e+.0e+.0e+.0e+.0e+.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.
bartolomei.ch...@ensco.com



From: Micha Silver 
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 -9
each cell has some value in it, if it isn't "-9" 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

Re: [GRASS-user] Archiving GPM 3hr rainrate in GRASS

2017-01-20 Thread Laurent C. 
Hello all,

I wrote a module that automatically download, import and register GPM
IMERG maps in GRASS.
You will need a NASA Earthdata Login to download the data. The code
can be found here:
https://bitbucket.org/lrntct/t.rast.in.gpm

For now, it is limited to IMERGHH data.
Hope it could help people working with those data.

Regards,
Laurent


2015-03-19 10:50 GMT-06:00 Laurent C. :
> Hi all,
>
> I'm coming back to that subject because the GPM datas are finally available
> since December 2014. The original data are stored in HDF5, which is
> supported by GDAL.
> However, I had a problem with the geo-referencing of the data. It seems that
> the lat/long coordinates are flipped.
> The problem seems to come from GDAL, as the HDF5 driver still don't support
> GPM data:
> http://www.gdal.org/frmt_hdf5.html
>
> I've actually downloaded a regional extracts the data in NetCDF from a NASA
> website, although I can't remember where exactly, as there are several
> services. Those data suffer from the same problem of inverted coordinates.
>
> So I used the ncpdq from NCO package to fix the NetCDF directly, and a tiny
> Python script to batch process the files :
>
> ###
> #!/usr/bin/env python
> from os import listdir
> import subprocess
> for input_file in listdir(main_path):
> output_file = input_file + '_fixed'
> subprocess.call(['ncpdq','-a', 'lat,lon', input_file, output_file])
> ###
>
> After batch import the data in GRASS, maintaining the original name
> including timestep, which looks like this:
> 3B-HHR.MS.MRG.3IMERG.20140619-S00-E002959..V03D
>
> A Python script to register the maps in temporal framework:
>
> #
> #!/usr/bin/env python
> import grass.script as grass
>
> # retrieve the list of maps
> maplist = grass.read_command('g.list', type = 'raster',
> pattern = '*IMERG*')
>
> # turn result in a list
> maplist = maplist.split()
>
> file_name = 'gpm_timestamp.txt'
>
> # creating the file containing the timepstamp
> list_file = open(file_name,'w')
>
> # iterate through the maps
> for input_map in maplist:
> # split line to keep only the timestamp
> raw_ts = input_map.split('.')[4]
> # isolate the date
> raw_mapdate = raw_ts.split('-')[0]
> # put the date in form
> mapdate = raw_mapdate[:4] + '-' + raw_mapdate[4:6] + \
> '-' + raw_mapdate[6:]
> # isolate the start time
> raw_start_time = raw_ts.split('-')[1]
> # put the date in form
> start_time = raw_start_time[1:3] + ':' + \
> raw_start_time[3:5] + ':' + raw_start_time[5:]
> # isolate the end time
> raw_end_time = raw_ts.split('-')[2]
> # put the end time in form
> end_time = raw_end_time[1:3] + ':' + \
> raw_end_time[3:5] + ':' + raw_end_time[5:]
> # put timestamp in form
> timestamp = mapdate + ' ' + start_time + '|' + mapdate + \
> ' ' + end_time
>
> # format the whole line
> line = input_map + '|' + timestamp + '\n'
>
> # write line to the file
> list_file.write(line)
>
> # close the file
> list_file.close()
>
> # register the maps in grass space_time dataset
> grass.run_command('t.register', input = 'GPM_ZMCM', file = file_name)
>
> #
>
>
> Hope it will help other peoples having trouble using those data.
>
> Regards,
> Laurent
>
>
> 2014-11-06 5:15 GMT-06:00 maning sambale :
>>
>> Thanks Markus.  Already registered and can access ftp.  Unfortunately,
>> processed (L3) rainfall data will be released by Dec 2014.
>> Will just wait then. :)
>>
>> On Thu, Nov 6, 2014 at 4:27 PM, Markus Neteler  wrote:
>> > On Mon, Nov 3, 2014 at 10:18 AM, maning sambale
>> >  wrote:
>> >> Has anyone here able to archive and load GPM dataset into GRASS?  I
>> >> was able to get TRMM netcdf in my area of interest before, but I can't
>> >> find the tools to automate GPM downloads.
>> >>
>> >> Thanks!
>> >>
>> >> [0] http://www.nasa.gov/mission_pages/GPM/main/
>> >
>> > They state
>> >
>> > "All data are freely available through the NASA's Precipitation
>> > Processing System at http://pps.gsfc.nasa.gov;
>> >
>> > --> "Register and search for GPM and TRMM data, order custom subsets
>> > and set up subscriptions using PPS Data Products Ordering Interface
>> > (STORM)."
>> >
>> > At time the server seems to be down?
>> >
>> > Markus
>>
>>
>>
>> --
>> cheers,
>> maning
>> --
>> "Freedom is still the most radical idea of all" -N.Branden
>> wiki: http://esambale.wikispaces.com/
>> blog: http://epsg4253.wordpress.com/
>> --
>> ___
>> grass-user mailing list
>> grass-user@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/grass-user
>
>
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] r.out.ascii not functioning for floating point values

2017-01-20 Thread Bartolomei.Chris 
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+.0e+.0e+.0e+.0e+.0e+.0e+.0e+.0e+.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.
bartolomei.ch...@ensco.com



From: Micha Silver 
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 -9
each cell has some value in it, if it isn't "-9" 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.
bartolomei.ch...@ensco.com

[GRASS-user] Are Grass-7.2.0 and Qgis-2.18.3 working together on Fedora 25?

2017-01-20 Thread dulcamara 




--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/Are-Grass-7-2-0-and-Qgis-2-18-3-working-together-on-Fedora-25-tp5304215.html
Sent from the Grass - Users mailing list archive at Nabble.com.
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] r.out.ascii not functioning for floating point values

2017-01-20 Thread Micha Silver 

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 -9
each cell has some value in it, if it isn't "-9" 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.
bartolomei.ch...@ensco.com



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
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user


___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] GRASS 7.2 v.in.ascii error

2017-01-20 Thread Thomas Adams 
Martin,

Yes; I pretty much figured that out -- 'datetime' worked. I'm slowly
catching on...

Tom

On Fri, Jan 20, 2017 at 7:18 AM, Martin Landa 
wrote:

> Hi,
>
> 2017-01-20 13:15 GMT+01:00 Thomas Adams :
> > Thank you; I did try 'date' and got the same result using the exact
> dataset.
>
> well, 'date' is also SQL reserved word :-) [1] Ma
>
> [1] http://developer.mimer.se/validator/sql-reserved-words.tml
>
> --
> Martin Landa
> http://geo.fsv.cvut.cz/gwiki/Landa
> http://gismentors.cz/mentors/landa
>



-- 
Thomas E Adams, III
1724 Sage Lane
Blacksburg, VA 24060
tea...@gmail.com (personal)
t...@terrapredictions.org (work)

1 (513) 739-9512 (cell)
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] GRASS 7.2 v.in.ascii error

2017-01-20 Thread Martin Landa 
Hi,

2017-01-20 13:15 GMT+01:00 Thomas Adams :
> Thank you; I did try 'date' and got the same result using the exact dataset.

well, 'date' is also SQL reserved word :-) [1] Ma

[1] http://developer.mimer.se/validator/sql-reserved-words.tml

-- 
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] GRASS 7.2 v.in.ascii error

2017-01-20 Thread Thomas Adams 
Helmut,

Thank you; I did try 'date' and got the same result using the exact
dataset. After sending out the email (thinking GRASS *might* be choking on
the number of columns), I reduced the number of columns and re-ordered them
(thinking that maybe the ID ought to come first -- also recognizing that
this should NOT be the case). I got the same error -- then, I did as you
have suggested, using 'datetime' instead of 'time' -- this worked. So, it
almost certainly was the use of 'time' or 'date' as a column name...

At some point I'll go back to the original dataset to verify this.

Thank you...

Best,
Tom

On Thu, Jan 19, 2017 at 3:27 PM, Helmut Kudrnovsky  wrote:

> >SQL parser error (syntax error, unexpected TIME, expecting
> >NAME processing 'time') in statement:
>
> Could it be that time is a SQL reserved word/key? Try another word instead
> of 'time'.
>
> HTH
> Helmut
>
>
>
> -
> best regards
> Helmut
> --
> View this message in context: http://osgeo-org.1560.x6.
> nabble.com/GRASS-7-2-v-in-ascii-error-tp5304079p5304089.html
> Sent from the Grass - Users mailing list archive at Nabble.com.
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user




--
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] r.out.ascii not functioning for floating point values

2017-01-20 Thread Bartolomei.Chris 
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 -9
each cell has some value in it, if it isn't "-9" 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.
bartolomei.ch...@ensco.com



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
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user