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 [email protected]: > Send grass-user mailing list submissions to > [email protected] > > 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 > [email protected] > > You can reach the person managing the list at > [email protected] > > 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" <[email protected]> > To: Markus Neteler <[email protected]> > Cc: GRASS user list <[email protected]> > Subject: Re: [GRASS-user] installing add-ons for GRASS 6.4.2 on Ubuntu > fails > Message-ID: > <CAB4g1=y3qqpmakxcbvrekzzrjrzovbuc4tpgbyegukeshch...@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 <[email protected]> > >> 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 <[email protected]> >> >>> On Mon, Apr 15, 2013 at 12:32 PM, G. Allegri <[email protected]> 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 <[email protected]> > To: Pedro Ven=?iso-8859-1?B?4g==?=ncio <[email protected]> > Cc: GRASS users <[email protected]>, > [email protected] > Subject: Re: [GRASS-user] Using r.quantile result with r.recode > Message-ID: <[email protected]> > 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 <[email protected]> > > > ------------------------------ > > Message: 3 > Date: Tue, 16 Apr 2013 17:07:31 -0700 (PDT) > From: Hamish <[email protected]> > To: "G. Allegri" <[email protected]> > Cc: GRASS user list <[email protected]> > Subject: Re: [GRASS-user] installing add-ons for GRASS 6.4.2 on Ubuntu > fails > Message-ID: > <[email protected]> > 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" <[email protected]> > To: Hamish <[email protected]> > Cc: GRASS user list <[email protected]> > Subject: Re: [GRASS-user] installing add-ons for GRASS 6.4.2 on Ubuntu > fails > Message-ID: > <CAB4g1=xfgg8rw7d8odzop2e7v9pgtz-oafqx1_apy4d3ti7...@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 <[email protected]> > To: GRASS user list <[email protected]> > Subject: [GRASS-user] Problem with r.univar and very large values > Message-ID: > <CABsGe_wGMEeXa_=wcdlxx3u7e1u1qeq8rhsyubght_knjcg...@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 <[email protected]> > To: Glynn Clements <[email protected]> > Cc: GRASS users <[email protected]>, > "[email protected]" <[email protected]> > Subject: Re: [GRASS-user] Using r.quantile result with r.recode > Message-ID: > <[email protected]> > 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 <[email protected]> > > > ------------------------------ > > _______________________________________________ > grass-user mailing list > [email protected] > http://lists.osgeo.org/mailman/listinfo/grass-user > > > End of grass-user Digest, Vol 84, Issue 35 > ****************************************** _______________________________________________ grass-user mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-user
