[GRASS-user] Reading file with with space separators

Wed Apr 17 01:53:03 PDT 2013

Dear all

presumably a trivial question - but what is the argument for space when importing data?
I have xyz files with the format
..x..y...value 
where <.> stands for white space. The spacing is two spaces between x and y and three spaces to data column.

I used
r.in.xyz fs='space', in=dgm10_32292_5548_2_rp.xyz out=test
and obtain:
ERROR: Bad y-coordinate line 1 column 2. <>

I also tried different options for fs: fs=' ', fs = space, fs = \s (whitespace regular expression) - without success

In R it is no problem - the simple read.table with sep="" for any whitespace works. And with rasterFromXYZ (raster package) I can create a raster without problems.

I guess it is also easy in GRASS but I am just too ignorant :-)

Cheers
Ralf

Am 17.04.2013 um 10:33 schrieb grass-user-request at lists.osgeo.org:

> Send grass-user mailing list submissions to
> 	grass-user at lists.osgeo.org
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> 	http://lists.osgeo.org/mailman/listinfo/grass-user
> or, via email, send a message with subject or body 'help' to
> 	grass-user-request at lists.osgeo.org
> 
> You can reach the person managing the list at
> 	grass-user-owner at lists.osgeo.org
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of grass-user digest..."
> 
> 
> Today's Topics:
> 
>   1. Re: installing add-ons for GRASS 6.4.2 on Ubuntu fails
>      (G. Allegri)
>   2. Re: Using r.quantile result with r.recode (Glynn Clements)
>   3. Re: installing add-ons for GRASS 6.4.2 on Ubuntu fails (Hamish)
>   4. Re: installing add-ons for GRASS 6.4.2 on Ubuntu fails
>      (G. Allegri)
>   5. Problem with r.univar and very large values (Johannes Radinger)
>   6. Re: Using r.quantile result with r.recode (Pedro Ven?ncio)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Tue, 16 Apr 2013 21:44:02 +0200
> From: "G. Allegri" <giohappy at gmail.com>
> To: Markus Neteler <neteler at osgeo.org>
> Cc: GRASS user list <grass-user at lists.osgeo.org>
> Subject: Re: [GRASS-user] installing add-ons for GRASS 6.4.2 on Ubuntu
> 	fails
> Message-ID:
> 	<CAB4g1=y3QQpMakxcbVrekZZRJRzoVbuC4tPgbYeGuKeShchrsg at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
> 
> I've compiled GRASS 6.4.3RC2.
> The add-on installation exits with the following error:
> 
> /usr/bin/install: impossibile eseguire stat di "/home/giova/
> Data/GRASSDB/3003/PERMANENT/.tmp/xubuntu/16152.0/v.mkhexgrid
> /man/man1/v.mkhexgrid.1": File o directory non esistente
> make: *** [install] Errore 1
> WARNING: Installation failed, sorry. Please check above error messages.
> 
> In english it's something like
> 
> /usr/bin/install: cannot execute stat "/home/giova/
> Data/GRASSDB/3003/PERMANENT/.tmp/xubuntu/16152.0/v.mkhexgrid
> /man/man1/v.mkhexgrid.1": File or folder not existing
> make: *** [install] Error 1
> WARNING: Installation failed, sorry. Please check above error messages.
> 
> I've installed system wide with sudo, but I launch GRASS without sudoing.
> Could the problem be related to this?
> 
> giovanni
> 
> 
> 2013/4/16 G. Allegri <giohappy at gmail.com>
> 
>> I will go on compiling.
>> I'm not so expert in sw management on Linux, will it be problematic to
>> have both a 6.4 and 7 GRASS on the same machine? I would like to test GRASS
>> 7 too...
>> 
>> giovanni
>> 
>> 2013/4/16 Markus Neteler <neteler at osgeo.org>
>> 
>>> On Mon, Apr 15, 2013 at 12:32 PM, G. Allegri <giohappy at gmail.com> wrote:
>>>> Hi,
>>>> I've never installed add-ons throught the WxPython GUI.
>>>> I need to use the v.mkhexgrid [1], but the process fails because at some
>>>> stage (Rules.make) it tries to create/write into /usr/lib/bin folder
>>> (very
>>>> strange).
>>> 
>>> You need (to wait for) current GRASS 6.4.svn or 6.4.3 which hopefully
>>> addresses this problem.
>>> 
>>> The best would be that you compile 6.4.svn yourself on Ubuntu and
>>> make a test before we release 6.4.3:
>>> 
>>> http://grasswiki.osgeo.org/wiki/Compile_and_Install_Ubuntu
>>> 
>>> thanks
>>> Markus
>>> 
>> 
>> 
>> 
>> --
>> Giovanni Allegri
>> http://about.me/giovanniallegri
>> blog: http://blog.spaziogis.it
>> GEO+ geomatica in Italia http://bit.ly/GEOplus
>> 
> 
> 
> 
> -- 
> Giovanni Allegri
> http://about.me/giovanniallegri
> blog: http://blog.spaziogis.it
> GEO+ geomatica in Italia http://bit.ly/GEOplus
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.osgeo.org/pipermail/grass-user/attachments/20130416/6a1ad95a/attachment-0001.html>
> 
> ------------------------------
> 
> Message: 2
> Date: Tue, 16 Apr 2013 20:50:41 +0100
> From: Glynn Clements <glynn at gclements.plus.com>
> To: Pedro Ven=?iso-8859-1?B?4g==?=ncio <pedrongvenancio at yahoo.com>
> Cc: GRASS users <grass-user at lists.osgeo.org>,
> 	grass-dev at lists.osgeo.org
> Subject: Re: [GRASS-user] Using r.quantile result with r.recode
> Message-ID: <20845.43921.602188.954714 at cerise.gclements.plus.com>
> Content-Type: text/plain; charset=iso-8859-1
> 
> 
> [CC to grass-dev for discussion]
> 
> Pedro Ven?ncio wrote:
> 
>> Thank you very much for your answer!
>> 
>> My question lies precisely in the need to know if a quantile value
>> which falls as the upper limit for one range and the lower limit of
>> the next, should belong to the class anterior or posterior.
>> 
>> 
>> For example, assuming that r.quantile (with -r flag) gives this result:
>> 
>> 2:6:1 
>> 6:8:2 
>> 8:12:3 
>> 12:20:4 
>> 20:873:5
>> 
>> the value 6 should belong to the first class or second?
> 
> r.recode will treat boundary values as belonging to the upper range,
> e.g. in the above example, 6.0 will get recoded to 2.
> 
> This behaviour stems from Rast_fpreclass_get_cell_value() in
> lib/raster/fpreclass.c, and isn't configurable (i.e. there's no way
> that r.recode's behaviour could be modified without modifying the
> fpreclass functions).
> 
> -- 
> Glynn Clements <glynn at gclements.plus.com>
> 
> 
> ------------------------------
> 
> Message: 3
> Date: Tue, 16 Apr 2013 17:07:31 -0700 (PDT)
> From: Hamish <hamish_b at yahoo.com>
> To: "G. Allegri" <giohappy at gmail.com>
> Cc: GRASS user list <grass-user at lists.osgeo.org>
> Subject: Re: [GRASS-user] installing add-ons for GRASS 6.4.2 on Ubuntu
> 	fails
> Message-ID:
> 	<1366157251.11397.YahooMailClassic at web140003.mail.bf1.yahoo.com>
> Content-Type: text/plain; charset=us-ascii
> 
> G. Allegri wrote:
>> I've compiled GRASS 6.4.3RC2.The add-on installation
>> exits with the following error:
> ...
>> /usr/bin/install: cannot execute stat "/home/giova/Data/GRASSDB
>> /3003/PERMANENT/.tmp/xubuntu/16152.0/v.mkhexgrid/man/man1
>> /v.mkhexgrid.1": File or folder not existing
>> make: *** [install] Error 1WARNING: Installation failed, sorry.
>> Please check above error messages.
> 
> Hi,
> 
> since v.mkhexgrid is just a python script, you can just download
> it by hand and put it somewhere in your path.
> 
> http://svn.osgeo.org/grass/grass-addons/grass6/vector/v.mkhexgrid/v.mkhexgrid
> 
> (~/.grass6/addons/ is a nice place, but ~/bin/ will work too
> if you don't have GRASS_ADDON_PATH set up yet)
> 
> make sure to run 'chmod +x v.mkhexgrid' on it to make it executable.
> 
> 
>> I've installed system wide with sudo, but I launch GRASS
>> without sudoing. Could the problem be related to this?
> 
> Probably it is related to packaging work-in-progress issues with
> the last version of GRASS on Ubuntu & Debian. Hopefully fixed
> with the upcoming release of RC3 and the lastest DebianGIS
> packaging rules.
> 
>> I'm not so expert in sw management on Linux, will it be
>> problematic to have both a 6.4 and 7 GRASS on the same
>> machine? I would like to test GRASS 7 too...
> 
> In general no problem, as 'make install' will create independent
> grass64/ and grass70/ directories for each. From a pre-built
> packaging perspective the grass64 deb package contains a symlink
> called "grass" for startup which the grass7 package can not
> collide with. (only one package can provide a file by the same
> name) AFAIR the other common system files like the desktop icons
> are all named with the major version in the filename so no
> conflict there.
> 
> note if you want the v.mkhexgrid script to run in g7 you should
> check for a grass7 addons version of it. (or minor changes may
> be required to adjust for any changed options)
> 
> 
> Hamish
> 
> 
> ------------------------------
> 
> Message: 4
> Date: Wed, 17 Apr 2013 08:48:58 +0200
> From: "G. Allegri" <giohappy at gmail.com>
> To: Hamish <hamish_b at yahoo.com>
> Cc: GRASS user list <grass-user at lists.osgeo.org>
> Subject: Re: [GRASS-user] installing add-ons for GRASS 6.4.2 on Ubuntu
> 	fails
> Message-ID:
> 	<CAB4g1=xFgG8RW7d8odZop2e7V9PGtz-oafQx1_aPY4d3Ti7zPw at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
> 
> Hi
> 
>> since v.mkhexgrid is just a python script, you can just download
>> it by hand and put it somewhere in your path.
> 
> that's what I did, even before trying with a self-compiled 6.4.3RC2, but I
> cannot find the extension under the GUI menus (I know, I can run it via
> CLI).
> 
>> make sure to run 'chmod +x v.mkhexgrid' on it to make it executable.
> 
> Maybe this is thw reason it doesn't load? I will try ASAP
> 
>> Probably it is related to packaging work-in-progress issues with
>> the last version of GRASS on Ubuntu & Debian. Hopefully fixed
>> with the upcoming release of RC3 and the lastest DebianGIS
>> packaging rules.
> 
> This happens with 6.4.3RC2. I've compiled it using the sources from the svn
> tags repository. Is trunk the latest 6.4.3? I thought it wad GRASS 7.
> 
>> In general no problem, as 'make install' will create independent
>> grass64/ and grass70/ directories for each. From a pre-built
>> packaging perspective the grass64 deb package contains a symlink
>> called "grass" for startup which the grass7 package can not
>> collide with. (only one package can provide a file by the same
>> name) AFAIR the other common system files like the desktop icons
>> are all named with the major version in the filename so no
>> conflict there.
> 
> Ok, thx
> 
>> 
>> note if you want the v.mkhexgrid script to run in g7 you should
>> check for a grass7 addons version of it. (or minor changes may
>> be required to adjust for any changed options)
> 
> I verified that it doesn't exist for g7, but it should be easy to update
> it.
> 
> giovanni
> 
>> 
>> 
>> Hamish
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.osgeo.org/pipermail/grass-user/attachments/20130417/9a629e01/attachment-0001.html>
> 
> ------------------------------
> 
> Message: 5
> Date: Wed, 17 Apr 2013 10:04:09 +0200
> From: Johannes Radinger <johannesradinger at gmail.com>
> To: GRASS user list <grass-user at lists.osgeo.org>
> Subject: [GRASS-user] Problem with r.univar and very large values
> Message-ID:
> 	<CABsGe_wGMEeXa_=WcDLxx3U7E1U1QeQ8RHsyUBGHt_knJcG51g at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
> 
> Hi,
> 
> I just faced a problem when trying to run r.univar (both GRASS6.5 and
> GRASS7) on a raster which was multiplied by a very large value (1e+200) in
> a python script.
> The raster is displayed correctly and the cells can be querried and give
> the correct large value but r.univar gives: *** stack smashing detected
> ***: r.univar terminated
> 
> As the map is not mutliplied using r.mapcalc but here I used the interface
> to numpy arrays. Here a short working example (with the fields raster map
> of the small spearfish example dataset). Probably this might work with
> other raster input as well.
> 
> # With small spearfish dataset
> import grass.script.array as garray
> 
> large_value = float(1e+200)
> 
> x1 = garray.array()
> x1.read("lower_distance_tmp_29117")
> result = garray.array()
> result[...] = x1 * large_value
> result.write("result_test")
> 
> And then running r.univar on result_test produces this error on my machine.
> Can anyone reproduce that?
> 
> What might cause that problem? Does anyone have an idea? E.g. do some
> summary value get to large (E.g. sum) to be processed? #
> 
> /Johannes
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.osgeo.org/pipermail/grass-user/attachments/20130417/bf7ee688/attachment-0001.html>
> 
> ------------------------------
> 
> Message: 6
> Date: Wed, 17 Apr 2013 01:33:28 -0700 (PDT)
> From: Pedro Ven?ncio <pedrongvenancio at yahoo.com>
> To: Glynn Clements <glynn at gclements.plus.com>
> Cc: GRASS users <grass-user at lists.osgeo.org>,
> 	"grass-dev at lists.osgeo.org" <grass-dev at lists.osgeo.org>
> Subject: Re: [GRASS-user] Using r.quantile result with r.recode
> Message-ID:
> 	<1366187608.86300.YahooMailNeo at web122301.mail.ne1.yahoo.com>
> Content-Type: text/plain; charset=iso-8859-1
> 
> Hi Glynn,
> 
>> ----- Original Message -----
>> From: Glynn Clements
> 
>> r.recode will treat boundary values as belonging to the upper range,
>> e.g. in the above example, 6.0 will get recoded to 2.
> 
> 
> So we can not use directly the result of r.quantile with -r flag in r.recode, right?
> 
> In the example, 6 should be recoded to 1, right?
> 
> Thank you very much!
> 
> Best regards,
> Pedro
> 
> 
> 
> 
> 
> 
> 
> Pedro Ven?ncio wrote:
> 
>> Thank you very much for your answer!
>> 
>> My question lies precisely in the need to know if a quantile value
>> which falls as the upper limit for one range and the lower limit of
>> the next, should belong to the class anterior or posterior.
>> 
>> 
>> For example, assuming that r.quantile (with -r flag) gives this result:
>> 
>> 2:6:1 
>> 6:8:2 
>> 8:12:3 
>> 12:20:4 
>> 20:873:5
>> 
>> the value 6 should belong to the first class or second?
> 
> r.recode will treat boundary values as belonging to the upper range,
> e.g. in the above example, 6.0 will get recoded to 2.
> 
> This behaviour stems from Rast_fpreclass_get_cell_value() in
> lib/raster/fpreclass.c, and isn't configurable (i.e. there's no way
> that r.recode's behaviour could be modified without modifying the
> fpreclass functions).
> 
> -- 
> Glynn Clements <glynn at gclements.plus.com> 
> 
> 
> ------------------------------
> 
> _______________________________________________
> grass-user mailing list
> grass-user at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-user
> 
> 
> End of grass-user Digest, Vol 84, Issue 35
> ******************************************