Re: [GRASS-stats] spgrass6 archived on CRAN

[Markus Neteler]

Dear Roger,

On Mon, May 2, 2022 at 10:46 AM Roger Bivand  wrote:
>
> The old spgrass6 CRAN package has been archived, as GRASS 6 was last
> updated many years ago.
>
> rgrass7 will be archived when the rgdal package is retired at the latest
> in 18 months. It will be complemented before summer 2022 by a new rgrass
> package using terra (and oprionally sf) for file transfer.

A big THANK YOU to you for maintaining spgrass6 for so many years!
And certainly also for rgrass7 and the new upcoming rgrass package.

Best regards,
Markus

> Roger
>
> --
> Roger Bivand
> Emeritus Professor
> Department of Economics, Norwegian School of Economics,
> Postboks 3490 Ytre Sandviken, 5045 Bergen, Norway.
> e-mail: roger.biv...@nhh.no
> https://orcid.org/-0003-2392-6140
> https://scholar.google.no/citations?user=AWeghB0J=en
> ___
> grass-stats mailing list
> grass-stats@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-stats

-- 
Markus Neteler, PhD
https://www.mundialis.de - free data with free software
https://grass.osgeo.org
https://courses.neteler.org/blog
___
grass-stats mailing list
grass-stats@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-stats

Re: [GRASS-stats] error when trying to start GRASS from Rstudio in Windows

[Markus Neteler]

On Thu, Nov 1, 2018 at 1:20 PM Veronica Andreo  wrote:
> In the body of the ticket I mentioned that the "pop-up error is a missing 
> iconv.dll" and

Yes - but the real error message might help.

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

Re: [GRASS-stats] error when trying to start GRASS from Rstudio in Windows

[Markus Neteler]

On Thu, Nov 1, 2018 at 12:56 PM Veronica Andreo  wrote:
>
> Done in
> https://trac.osgeo.org/grass/ticket/3688
> but, no news so far...

As far as I seee the a iconv.dll-issue (missing iconv.dll) is not yet
mentioned in the ticket.
More details on that might be useful.

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

Re: [GRASS-stats] rgrass7 - SQLite and GML drivers not working for readVECT

[Markus Neteler]

Dear Roger,

On Oct 11, 2017 1:41 PM, "Roger Bivand"  wrote:
>
> New version submitted to CRAN; until then:
>
> install.packages("rgrass7", repos="http://R-Forge.R-project.org;)
>
> should pick up the latest version; #3425 closed. Please report back
whether this works ... (conditioning on GRASS version to create comparable
driver name strings).

I hope we find a long term solution.
In any case:
Thanks for your efforts!

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

Re: [GRASS-stats] Parameter error in when using r.horizons

[Markus Neteler]

On Fri, Jan 6, 2017 at 10:22 PM, helekua  wrote:
> Thanks Roger, this solution worked perfect.  I'm no longer receiving the
> error.

Please consider to add a note or example here:

https://grasswiki.osgeo.org/wiki/R_statistics/rgrass7

thanks
Markus
___
grass-stats mailing list
grass-stats@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-stats

Re: [GRASS-stats] GRASS can't find R packages from personal library on Windows

[Markus Neteler]

On Wed, Nov 23, 2016 at 10:56 PM, Helmut Kudrnovsky  wrote:
...
> New Revision: 69883
>
> Modified:
>grass/trunk/mswindows/env.bat
> Log:
> set R_USER if %USERPROFILE%\Documents\R\ exists to catch most common cases
> of private R libraries in windows
>
> it should catch at least the common cases where personal libraries are
> located in %USERPROFILE%\Documents\R\
>
> please test the next standalone winGRASS7.3.svn daily builds
> (https://wingrass.fsv.cvut.cz/grass73/x86_64/ or
> https://wingrass.fsv.cvut.cz/grass73/x86/).

The new installer is available now:

https://wingrass.fsv.cvut.cz/grass73/x86_64/WinGRASS-7.3.svn-r69883-73-Setup-x86_64.exe
(or later)

> if it works, it should be backported to the standalone winGRASS7.0.x and the
> upcoming winGRASS7.2.

If possible, please timely test. I am holding RC2 for this at time.

thanks
Markus
___
grass-stats mailing list
grass-stats@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-stats

Re: [GRASS-stats] Using GRASS addons in R on Windows

[Markus Neteler]

On Tue, Jan 12, 2016 at 8:24 PM, Roger Bivand  wrote:
> On Tue, 12 Jan 2016, Helmut Kudrnovsky wrote:
>> confirmed, it works now.
>> great, thanks!
>>
> OK, thanks, as I've also made progress on the other problem (using temporary
> SQLite files for vector transfer under Windows), I've submitted to CRAN.
> Anyone who installed the 0.1-4 versions for testing will need to install the
> CRAN version when/if it appears.

That's great, thanks for discovering and solving!

Markus
___
grass-stats mailing list
grass-stats@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-stats

Re: [GRASS-stats] rgrass7 read/write SpatialPolygonsDataFrames errors

[Markus Neteler]

On Sat, Oct 10, 2015 at 5:45 PM, Eduardo Diez  wrote:
>
> Apparently "v.info" through execGRASS is expecting the "layer" argument to be 
> a string rather than an integer.


Yes, layer is a string:

v.info --interface-description




Outputs basic information about a vector map.

...


Layer number or name



Best
Markus
___
grass-stats mailing list
grass-stats@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-stats

[GRASS-stats] How to use r.what in rgrass7?

[Markus Neteler]

Dear list,

I try to query from R a raster map at given vector point positions
(both maps are in GRASS but it could well be that the points are in R
and the (huge) raster map in GRASS).

So, simple North Carolina data set example:

goutput <- execGRASS("r.what", map="elev_state_500m",
points="geodetic_pts", separator=",")

I would expect that the result is stored in "goutput" (seems it is)
but it also dumps it into the terminal which I would like to avoid. I
don't manage to switch that off.

Then, following this blog
https://pvanb.wordpress.com/2013/01/23/import-grass-function-console-output-as-data-frame-in-r/

I tried to parse the output:
con <- textConnection(goutput)

which fails with
Error in textConnection(goutput) : invalid 'text' argument

Does anyone have a suggestion how to turn the output of r.what into an R object?

Likewise suggestions are welcome how to feed R point positions into
r.what from R.

Hope I am not asking too much :-)

thanks,
Markus
___
grass-stats mailing list
grass-stats@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-stats

Re: [GRASS-stats] raster data in R

[Markus Neteler]

Hi Rainer,

On Thu, Sep 10, 2015 at 4:36 PM, Rainer M Krug  wrote:
...
> Just check out the rgrass7 package - readRAST() allows you to read your
> raster, then you do your calculations with the data,

... this calculation part is the question of Marisa... any recommended
tutorials on how to loop over pixels in R after having used
readRAST()?

> then you add them
> to the map object in R and finally you can safe them by using
> writeRAST() back to GRASS.

Yes, that part is clear. Just the "loop" best practice not so much.

thanks
Markus
___
grass-stats mailing list
grass-stats@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-stats

[GRASS-stats] wish: less verbose messages in rgrass7

[Markus Neteler]

Hi,

today we used "rgrass7" on Windows (and I made some tests on Linux, too).

I was wondering about a few warnings which might be suppressed to avoid
user confusion:


 Windows: calling GRASS 7.1 from R session

> library(rgrass7)
Loading required package: sp
Loading required package: XML
GRASS GIS interface loaded with GRASS version: (GRASS not running)
Warning messages:
1: package ‘rgrass7’ was built under R version 3.2.2
2: package ‘sp’ was built under R version 3.2.2
3: package ‘XML’ was built under R version 3.2.2

> initGRASS(gisBase = "C:/OSGeo4W/apps/grass/grass-7.1.svn",
+ gisDbase = "C:/Users/marissa/GRASSdata/",
+ location = "CA", mapset = "Aegypti")
Error in initGRASS(gisBase = "C:/OSGeo4W/apps/grass/grass-7.1.svn",
gisDbase = "C:/Users/marissa/GRASSdata/",  :
  A GISRC file already exists; to override, set override=TRUE


==> the last sentence is not quite clear. Perhaps change to

"A GISRC file already exists (the GRASS GIS mapset is already in use); to
override, set override=TRUE"


> initGRASS(gisBase = "C:/OSGeo4W/apps/grass/grass-7.1.svn",
+ gisDbase = "C:/Users/marissa/GRASSdata/",
+ location = "CA", mapset = "Aegypti",
+ override=TRUE)
gisdbaseC:/Users/marissa/GRASSdata/
locationCA
mapset  Aegypti
rows265
columns 230
north   452000
south   -608000
west-376000
east544000
nsres   4000
ewres   4000
projection  +proj=aea +lat_1=34 +lat_2=40.5 +lat_0=0 +lon_0=-120 +x_0=0
+y_0=-400 +no_defs +a=6378137 +rf=298.257222101
+towgs84=0.000,0.000,0.000 +to_meter=1
Warning message:
In dir.create(gisDbase) : 'C:\Users\marissa\GRASSdata' already exists

==> the last warning is not clear to me. If I set override=TRUE, I refer to
the mapset's gislock, hence the dir.create(gisDbase should not be done at
all. Is it a bug?


## Linux

> ncdata <- readRAST("elevation")
WARNING: 'cellhd/elevation' was found in more mapsets (also found in
 )
WARNING: Using 
WARNING: 'cellhd/elevation' was found in more mapsets (also found in
 )
WARNING: Using 
WARNING: 'cellhd/elevation' was found in more mapsets (also found in
 )
WARNING: Using 

==> these warning make probably sense in a GRASS session but IMHO here
less. They could be suppressed with --q in the respective GRASS module call.


Creating BIL support files...
Exporting raster as floating values (bytes=4)
 100%
Warning messages:
1: In execGRASS("r.info", flags = "g", map = vname[i], intern = TRUE,  :
  The command:
r.info -g map=elevation
produced at least one warning during execution:
WARNING: 'cellhd/elevation' was found in more mapsets (also found in
 )
WARNING: Using 
WARNING: 'cellhd/elevation' was found in more mapsets (also found in
 )
WARNING: Using 
WARNING: 'cellhd/elevation' was found in more mapsets (also found in
 )
WARNING: Using 

==> here it is, I suggest to use r.info --q

2: In execGRASS("r.info", flags = "r", map = vname[i], intern = TRUE,  :
  The command:
r.info -r map=elevation
produced at least one warning during execution:
WARNING: 'cellhd/elevation' was found in more mapsets (also found in
 )
WARNING: Using 
WARNING: 'cellhd/elevation' was found in more mapsets (also found in
 )
WARNING: Using 
WARNING: 'cellhd/elevation' was found in more mapsets (also found in
 )
WARNING: Using 

==> same thing

3: In execGRASS("r.out.bin", flags = rOutBinFlags, input = vname[i],  :
  The command:
r.out.bin -b -f input=elevation
output=/home/neteler/grassdata/nc_spm_08_grass7/user1/.tmp/pgis_north/elevation
bytes=4 null=54
produced at least one warning during execution:
WARNING: 'cellhd/elevation' was found in more mapsets (also found in
 )
WARNING: Using 
WARNING: 'cellhd/elevation' was found in more mapsets (also found in
 )
WARNING: Using 
WARNING: 'cellhd/elevation' was found in more mapsets (also found in
 )
WARNING: Using 

==> same thing

Creating BIL support files...
Exporting raster as floating values (bytes=4)
 100%

thanks
Markus
___
grass-stats mailing list
grass-stats@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-stats

Re: [GRASS-stats] rgrass7_0.1-2 on CRAN

[Markus Neteler]

On Mon, Aug 24, 2015 at 9:05 AM, Roger Bivand  wrote:
> I've just submitted a new version of rgrass7 to CRAN, and the source
package
> is now available. The Windows CRAN binary will follow shortly, but the OSX
> CRAN Mavericks binary may be delayed. This is because the new version
> suggests the most recent rgdal_1.0-6, which fixes an issue with the SQLite
> driver in GDAL2, seen when that driver is available.
>
> The main change is to move the vector interface to using the SQLite format
> for intermediate files if it is available, and to get around the field
name
> length restriction when using the shapefile format. Users should not see
> changes in behaviour,

This is excellent, thanks for having implemented this improvement.

> but I'd be grateful for reports to ensure that using
> these alternative mechanisms does not change results. Among other things,
> the laundering of SQLite field names is turned off, to prevent unintended
> conversion to lower case.


I have just made a test:

GRASS 7.0.2svn (nc_spm_08_grass7):~ >

g.copy vect=zipcodes_wake,myzipcodes_wake

g.region raster=elevation -p
projection: 99 (Lambert Conformal Conic)
zone:   0
datum:  nad83
ellipsoid:  a=6378137 es=0.006694380022900787
north:  228500
south:  215000
west:   63
east:   645000
nsres:  10
ewres:  10
rows:   1350
cols:   1500
cells:  2025000

# generate very long column names with long prefix:
v.rast.stats myzipcodes_wake raster=elevation   column_prefix=elev_data
method=minimum,maximum,average,stddev,percentile   percentile=95
Processing data (13 categories)...
Updating the database .

v.info -c myzipcodes_wake
Displaying column types/names for database connection of layer <1>:
INTEGER|cat
INTEGER|OBJECTID
DOUBLE PRECISION|WAKE_ZIPCO
DOUBLE PRECISION|PERIMETER
DOUBLE PRECISION|ZIPCODE_
DOUBLE PRECISION|ZIPCODE_ID
CHARACTER|ZIPNAME
DOUBLE PRECISION|ZIPNUM
CHARACTER|ZIPCODE
CHARACTER|NAME
DOUBLE PRECISION|SHAPE_Leng
DOUBLE PRECISION|SHAPE_Area
DOUBLE PRECISION|elev_data_minimum
DOUBLE PRECISION|elev_data_maximum
DOUBLE PRECISION|elev_data_average
DOUBLE PRECISION|elev_data_stddev
DOUBLE PRECISION|elev_data_percentile_95


GRASS 7.0.2svn (nc_spm_08_grass7):~ > R

R version 3.2.1 (2015-06-18) -- "World-Famous Astronaut"
...
> library(rgrass7)
Loading required package: sp
Loading required package: XML
GRASS GIS interface loaded with GRASS version: GRASS 7.0.2svn (2015)
and location: nc_spm_08_grass7
> mydata <- readVECT("myzipcodes_wake")
Exporting 48 areas (may take some time)...
 100%
v.out.ogr complete. 48 features (Polygon type) written to 
(SQLite format).
OGR data source with driver: SQLite
Source:
"/home/neteler/grassdata/nc_spm_08_grass7/user1/.tmp/oboe.localdomain/myzipcodes_wake",
layer: "myzipcodes_wake"
with 48 features
It has 17 fields
Warning message:
In rgdal::readOGR(dsn = RDSN, layer = LAYER, verbose = !ignore.stderr) :
  Z-dimension discarded

> summary(mydata)
Object of class SpatialPolygonsDataFrame
Coordinates:
   min  max
x 610047.9 677060.7
y 196327.5 258102.6
Is projected: TRUE
proj4string :
[+proj=lcc +lat_1=36.16 +lat_2=34.34
+lat_0=33.75 +lon_0=-79 +x_0=609601.22 +y_0=0 +datum=NAD83 +units=m
+no_defs +ellps=GRS80 +towgs84=0,0,0]
Data attributes:
  cat   OBJECTID   WAKE_ZIPCO  PERIMETER
 Min.   : 1.00   Min.   :  1.0   Min.   :5.951e+05   Min.   :  3226
 1st Qu.:11.75   1st Qu.: 16.5   1st Qu.:8.368e+07   1st Qu.: 51693
 Median :22.50   Median : 32.5   Median :5.698e+08   Median :135398
 Mean   :22.50   Mean   :103.4   Mean   :5.765e+08   Mean   :138404
 3rd Qu.:33.25   3rd Qu.:224.2   3rd Qu.:8.408e+08   3rd Qu.:199258
 Max.   :44.00   Max.   :301.0   Max.   :2.826e+09   Max.   :465259

ZIPCODE_   ZIPCODE_ID  ZIPNAME   ZIPNUM
 Min.   : 2.00   Min.   :  1.00   RALEIGH  :15   Min.   :27501
 1st Qu.:17.25   1st Qu.:  9.75   APEX : 4   1st Qu.:27526
 Median :32.00   Median : 18.00   CARY : 4   Median :27592
 Mean   :29.93   Mean   : 36.25   ANGIER   : 2   Mean   :27574
 3rd Qu.:43.25   3rd Qu.: 29.25   DURHAM   : 2   3rd Qu.:27607
 Max.   :53.00   Max.   :157.00   FUQUAY VARINA: 2   Max.   :27713
  (Other)  :15
ZIPCODE  NAME  SHAPE_Leng
 ANGIER 27501   : 2   RALEIGH  :15   Min.   :  3221
 APEX 27539 : 2   APEX : 4   1st Qu.: 44978
 FUQUAY VARINA 27526: 2   CARY : 4   Median :127213
 WILLOW SPRING 27592: 2   ANGIER   : 2   Mean   :132809
 YOUNGSVILLE 27596  : 2   DURHAM   : 2   3rd Qu.:193936
 APEX 27502 : 1   FUQUAY VARINA: 2   Max.   :477265
 (Other):33   (Other)  :15
   SHAPE_Areaelev_data_minimum elev_data_maximum elev_data_average
 Min.   :5.943e+05   Min.   : 55.58Min.   :107.5 Min.   : 80.94
 1st Qu.:7.061e+07   1st Qu.: 68.901st Qu.:117.6 1st Qu.: 97.35
 Median :5.267e+08  

Re: [GRASS-stats] error initGRASS - rgrass7

[Markus Neteler]

Hi,

On Fri, Jul 24, 2015 at 9:47 AM, Rainer M Krug rai...@krugs.de wrote:
 Markus Neteler nete...@osgeo.org writes:

 On Wed, Jul 22, 2015 at 3:11 PM, Rainer M Krug rai...@krugs.de wrote:
 Hi Veronica,

 Veronica Andreo veroand...@gmail.com writes:

 Hi,

 I'm trying to run GRASS from R using:

 library(rgrass7)
 initGRASS(gisBase=/home/veroandreo/software/grass-7.0.svn,
   home=tempdir(), gisDbase=/home/veroandreo/grassdata,
   location=latlong_wgs84, mapset=clorofila, override=TRUE)

 I assume you use Linux.


 but I get the following error:

 sh: g.gisenv: command not found

so, I found the trick:

In the first place, find out the path to the GRASS GIS library. This
can be easily done with the following command (still outside of R; or
through a system() call inside of R):

 grass70 --config path


It may report something like:
 /home/veroandreo/software/grass-7.0.svn/dist.x86_64-unknown-linux-gnu

This path must be used then:

library(rgrass7)

# initialisation and the use of North Carolina sample dataset
initGRASS(gisBase =
/home/veroandreo/software/grass-7.0.svn/dist.x86_64-unknown-linux-gnu,
home = tempdir(),
  gisDbase = /home/veroandreo/grassdata/,
  location = nc_spm_08_grass7, mapset = user1, SG=elevation,
  override = TRUE)
...

and it works fine.

I have updated the Wiki page accordingly:
http://grasswiki.osgeo.org/wiki/R_statistics/rgrass7#GRASS_within_R

Cheers
Markus
___
grass-stats mailing list
grass-stats@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-stats

Re: [GRASS-stats] error initGRASS - rgrass7

[Markus Neteler]

On Wed, Jul 22, 2015 at 3:11 PM, Rainer M Krug rai...@krugs.de wrote:
 Hi Veronica,

 Veronica Andreo veroand...@gmail.com writes:

 Hi,

 I'm trying to run GRASS from R using:

 library(rgrass7)
 initGRASS(gisBase=/home/veroandreo/software/grass-7.0.svn,
   home=tempdir(), gisDbase=/home/veroandreo/grassdata,
   location=latlong_wgs84, mapset=clorofila, override=TRUE)

 I assume you use Linux.


 but I get the following error:

 sh: g.gisenv: command not foundsh: g.gisenv: command not foundsh:
 g.gisenv: command not foundsh: g.gisenv: command not foundsh:
 g.gisenv: command not foundsh: g.version: command not foundError in
 system(paste(g.version, get(addEXE, envir = .GRASS_CACHE),  :
   error in running command


 Am I lacking something or is the function broken?? How should I use it??

 The easiest way of using R and GRASS GIS together, is starting GRASS GIS
 and then in starting R in GRASS. This way, initGRASS() is not needed
 anymore as the environment is already set up.

We (especially Veronica) worked during the recent Community Sprint on
the Wiki pages

http://grasswiki.osgeo.org/wiki/R_statistics

to improve it, move out subchapters into separate pages etc.
The scope is to explain both directions which used to work with spgrass6.

Best
Markus

 Are you sure that you gisBase is correct? Does GRASS work if you start
 it?

 Cheers,

 Rainer


 Any help is appretiated :)


 Thanks much in advance,

 Vero
 ___
 grass-stats mailing list
 grass-stats@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/grass-stats

 --
 Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, 
 UCT), Dipl. Phys. (Germany)

 Centre of Excellence for Invasion Biology
 Stellenbosch University
 South Africa

 Tel :   +33 - (0)9 53 10 27 44
 Cell:   +33 - (0)6 85 62 59 98
 Fax :   +33 - (0)9 58 10 27 44

 Fax (D):+49 - (0)3 21 21 25 22 44

 email:  rai...@krugs.de

 Skype:  RMkrug

 PGP: 0x0F52F982

 ___
 grass-stats mailing list
 grass-stats@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/grass-stats
___
grass-stats mailing list
grass-stats@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-stats

Re: [GRASS-stats] rgrass7: readVECT() issue with drivers other than ESRI Shapefile

[Markus Neteler]

Roger, all,

greetings from the community sprint:
http://grasswiki.osgeo.org/wiki/Talk:GRASS_Community_Sprint_Como_2015


On Fri, Jun 19, 2015 at 9:15 AM, Markus Neteler nete...@osgeo.org wrote:
 All,

 attached a simple (potentially ugly?) change to enable SQLite as a
 new driver for reading GRASS GIS 7 vector data into R
 (readVECT(vectmap, driver=SQLite)).
 I would really appreciate to see SQLite support added since it seems
 to be the only lossless OGR driver (e.g. unlike the default SHAPE
 file driver).

 I'll not commit this myself to r-forge since I am not sure if it
 should be implemented differently.
 Please verify.


Do you have any suggestions how to add SQLite support for a better
vector interface?

thanks
Markus
___
grass-stats mailing list
grass-stats@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-stats

Re: [GRASS-stats] rgrass7: readVECT() issue with drivers other than ESRI Shapefile

[Markus Neteler]

All,

attached a simple (potentially ugly?) change to enable SQLite as a
new driver for reading GRASS GIS 7 vector data into R
(readVECT(vectmap, driver=SQLite)).
I would really appreciate to see SQLite support added since it seems
to be the only lossless OGR driver (e.g. unlike the default SHAPE
file driver).

I'll not commit this myself to r-forge since I am not sure if it
should be implemented differently.
Please verify.

thanks,
Markus
Index: pkg/rgrass7/R/vect_link.R
===
--- pkg/rgrass7/R/vect_link.R   (revision 32)
+++ pkg/rgrass7/R/vect_link.R   (working copy)
@@ -86,7 +86,7 @@
 if (!(driver %in% sapply(ogrDGRASSs, [, 2)))
 stop(paste(Requested driver, driver, not available in GRASS))
 fDrivers - c(GML, SQLite)
-dDrivers - c(ESRI_Shapefile, MapInfo_File)
+dDrivers - c(ESRI_Shapefile, MapInfo_File, SQLite)
 if (!(gsub( , _, driver) %in% c(fDrivers, dDrivers)))
 stop(paste(Requested driver, driver, not supported))
 is_dDriver - TRUE
@@ -138,7 +138,10 @@
 res - rgdal::readOGR(dsn=RDSN, layer=LAYER, 
verbose=!ignore.stderr, 
   pointDropZ=pointDropZ)
 } else {
-res - rgdal::readOGR(dsn=rtmpfl1, layer=shname, 
verbose=!ignore.stderr)
+if (driver == SQLite)
+   res - rgdal::readOGR(dsn=RDSN, layer=tolower(shname), 
verbose=!ignore.stderr)
+else
+   res - rgdal::readOGR(dsn=rtmpfl1, layer=shname, 
verbose=!ignore.stderr)
 }
 },
 finally = {
___
grass-stats mailing list
grass-stats@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-stats

Re: [GRASS-stats] rgrass7: readVECT() issue with drivers other than ESRI Shapefile

[Markus Neteler]

Dear Roger,

On Thu, Jun 18, 2015 at 10:28 AM, Roger Bivand roger.biv...@nhh.no wrote:
 Dear Markus,

 You have commit rights, so please consider that route.

ok will do!

 Before committing, I increment Version: in rgrass7/DESCRIPTION, and run:

Should I put 0.2-0 or 0.1-1 ?

 R CMD build rgrass7

 in spgrass/pkg, creating rgrass7_0.1-*.tar.gz, then start GRASS 7 in the
 example location (NC basic), and run:

 R CMD check --run-dontrun --run-donttest rgrass7_0.1-*.tar.gz

 If it passes without obvious problems caused by the changes made, I commit.

My (small) changes do not cause any troubles but there is this unrelated issue:

GRASS 7.0.1RC1 (nc_basic_spm_grass7):~/software/rgrass7_svn/pkg  R
CMD check --run-dontrun --run-donttest rgrass7_0.2-*.tar.gz
* using log directory ‘/home/neteler/software/rgrass7_svn/pkg/rgrass7.Rcheck’
* using R version 3.2.0 (2015-04-16)
* using platform: x86_64-redhat-linux-gnu (64-bit)
...
* checking for unstated dependencies in examples ... OK
* checking examples ... ERROR
Running examples in ‘rgrass7-Ex.R’ failed
The error most likely occurred in:

 ### Name: initGRASS
 ### Title: Initiate GRASS session
 ### Aliases: initGRASS get.GIS_LOCK set.GIS_LOCK unset.GIS_LOCK
 ###   unlink_.gislock
 ### Keywords: spatial

 ### ** Examples


 initGRASS(/usr/bin/grass-7.0.0, home=tempdir())
Error in initGRASS(/usr/bin/grass-7.0.0, home = tempdir()) :
  A GRASS location is already in use; to override, set override=TRUE
Execution halted
* checking PDF version of manual ... OK
* DONE

Status: 1 ERROR
See
  ‘/home/neteler/software/rgrass7_svn/pkg/rgrass7.Rcheck/00check.log’
for details.

I don't know where the override=TRUE needs to be used.

 It may be worth adding a suitable example to the help page in man/, guarded
 in case some platform doesn't have the required driver on the rgdal side. I
 think that GML and GeoJSON are problematic because of the
 binary-string-binary conversions for coordinates, but we need working cases
 to start with.

Ok, my first commit will just be the small bugfix.

Regarding the idea to avoid SHAPE as internal data transfer:
The GeoJSON implementation failed because it does not accept a layer name.
But I have a (for me) working GML solution implemented which I would
prefer to send for inspection: a few lines but they look like a hack
to me. Not knowing well what's behind a rgdal call conditionalized
upon the rgdal package version, I likely implemented a workaround. At
least I can start with my analysis now :-)

 Of course, if it is more convenient for you, a diff for me to patch in would
 also be fine.

 Thanks for pushing (not a git pun) this!

I'm happy to commit.

Best wishes,
Markus
___
grass-stats mailing list
grass-stats@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-stats

Re: [GRASS-stats] Tests spgrass7 and RC2

[Markus Neteler]

On Feb 10, 2015 10:31 AM, Rainer M Krug rai...@krugs.de wrote:

 Hi

 I just checked spgrass7 with RC2 and no errors.

This is great news. I'll try to update the R page in the GRASS wiki over
the next days unless someone beats me (please do).

Best
Markus
___
grass-stats mailing list
grass-stats@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-stats

Re: [GRASS-stats] Towards spgrass7

[Markus Neteler]

Rainer,

which GRAS GIS 7 version do you use? Perhaps it is too old?

Last (European) night Michael Barton published RC1 which is needed here.

Best
Markus
___
grass-stats mailing list
grass-stats@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-stats

Re: [GRASS-stats] Towards spgrass7

[Markus Neteler]

Hi,

we came across another issue:

When importing a vector map but with type being defined (either
wrong type or by being selective in a multi-type vector map), then the
internal SHAPE files are not properly cleaned up and block further
import:

 myspear - readVECT(roads, with_c=TRUE, type=point)
WARNING: 825 line(s) found, but not requested to be exported. Verify 'type'
 parameter.
WARNING: No points found, but requested to be exported. Will skip this
 feature type.
Exporting 0 features...
 100%
WARNING: Output layer is empty, no features written
v.out.ogr complete. 0 features (Point type) written to roads
(ESRI_Shapefile format).
Error in rgdal::readOGR(dsn = rtmpfl1, layer = shname, verbose =
!ignore.stderr) :
  no features found
In addition: Warning messages:
1: In execGRASS(v.out.ogr, flags = flags, input = vname, type = type,  :
  The command:
v.out.ogr -e -c input=roads type=point layer=1
output=/home/neteler/grassdata/spearfish60_grass7/user1/.tmp/pgis_north
output_layer=roads format=ESRI_Shapefile
produced at least one warning during execution:
WARNING: 825 line(s) found, but not requested to be exported. Verify 'type'
 parameter.
WARNING: No points found, but requested to be exported. Will skip this
 feature type.
Exporting 0 features...
 100%
WARNING: Output layer is empty, no features written
v.out.ogr complete. 0 features (Point type) written to roads
(ESRI_Shapefile format).
2: In ogrFIDs(dsn = dsn, layer = layer) : no features found

-- this error is ok but now the problem occurs while rerunning the command:

 myspear - readVECT(roads, with_c=TRUE)
Error in execGRASS(v.out.ogr, flags = flags, input = vname, type = type,  :
  The command:
v.out.ogr -e -c input=roads type=line layer=1
output=/home/neteler/grassdata/spearfish60_grass7/user1/.tmp/pgis_north
output_layer=roads format=ESRI_Shapefile
produced an error (1) during execution:
ERROR: Layer roads already exists in OGR data source
   '/home/neteler/grassdata/spearfish60_grass7/user1/.tmp/pgis_north'


The reason is here (garbage left):

GRASS 7.0.0svn (spearfish60_grass7):~/software/spgrass  ls -la
/home/neteler/grassdata/spearfish60_grass7/user1/.tmp/pgis_north
total 24
drwxr-xr-x. 2 neteler gis 4096 Jan 21 15:03 ./
drwxr-xr-x. 3 neteler gis 4096 May 30  2014 ../
-rw-r--r--. 1 neteler gis   97 Jan 21 15:03 roads.dbf
-rw-r--r--. 1 neteler gis  414 Jan 21 15:03 roads.prj
-rw-r--r--. 1 neteler gis  100 Jan 21 15:03 roads.shp
-rw-r--r--. 1 neteler gis  100 Jan 21 15:03 roads.shx

It appears that these files are not cleaned up after readVECT()
execution in case of using the type parameter.
I am not sure where to fix that in the spgrass code.

thanks
Markus
___
grass-stats mailing list
grass-stats@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-stats

Re: [GRASS-stats] Towards spgrass7

[Markus Neteler]

On Mon, Jan 19, 2015 at 9:55 PM, Paulo van Breugel
p.vanbreu...@gmail.com wrote:
[...]
 About the help file of readRAST, one syntax change did not get through:

 execGRASS(g.region, rast=elevation.dem)

 This should be:

 execGRASS(g.region, raster=elevation.dem)

I have fixed that in the repository.

best
Markus
___
grass-stats mailing list
grass-stats@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-stats

Re: [GRASS-stats] error spgrass6 readRAST6

[Markus Neteler]

On Thu, Oct 20, 2011 at 3:40 PM, Jan Hendrik Blanke jan.bla...@gmx.de wrote:
 Hi,

 I am interested in using the GRASS/R interface spgrass6 and recently executed 
 the code given in the book Open Source GIS - A Grass GIS Approach for the 
 North Carolina dataset. Reading the first vector files (precipitation) works 
 perfectly, but when it comes to the first raster layer, I receive the 
 following error message:

 Error in deleteDataset(DS): GDAL Error 1: Deleting C:Documents and 
 Settings/.../GIS DataBase/North-Carolina/user1/.tmp/elev_state_500m failed:
 Permission denied

In that error message I observe C:Documents and Settings/ which is not
C://Documents and Settings/ (or with \\). Somehow it gets lost.

 I executed the following commands in the GRASS Command Line:

 g.region vect=precip_30ynormals res=1000 -ap
 R
 library(spgrass6)
 precip30n - readVECT6(precip_30ynormals, ignore.stderr=TRUE)
 ...
 elev - readRAST6(elev_state_500m, ignore.stderr=TRUE)

 After the last command, the given error message appears. The same happens 
 when I try to apply readRAST6 to personal data. ReadVECT6 again works fine.

That's interesting. Perhaps some path quoting is missing in  readRAST6()
which is present in readVECT6()? Or the called raster export function
from GRASS is an issue - we would need to know which is used.

...
 I am using GRASS 6.4.1 and R 2.12.2 and also tried R 2.13.2. The software 
 runs under Windows XP.

I don't know if the GDAL-GRASS plugin is used under Windows.

Markus
___
grass-stats mailing list
grass-stats@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-stats

[GRASS-stats] readRAST6() issue with NODATA

[Markus Neteler]

Dear Roger,

hope all is well.

I came across an issue with readRAST6():

 library(spgrass6)
Loading required package: sp
Loading required package: rgdal
Geospatial Data Abstraction Library extensions to R successfully loaded
Loaded GDAL runtime: GDAL 1.5.2, released 2008/05/29
Path to GDAL shared files: /home/neteler/binaries/share/gdal
Loaded PROJ.4 runtime: Rel. 4.6.1, 21 August 2008
Path to PROJ.4 shared files: (autodetected)
Loading required package: XML
GRASS GIS interface loaded with GRASS version: 6.4.0svn
and location: patUTM32
 mydata_raw -readRAST6(c(thresh_annual_over_11_celsius_2001_2008_avg, 
 italy_dem20_PHD_zone), cat=c(FALSE, FALSE))
/home/neteler/grassdata/patUTM32/zanzara_satellite/.tmp/fep/thresh_annual_over_11_celsius_2001_2008_avg
has GDAL driver GTiff
and has 601 rows and 1011 columns
WARNING: The given nodata value is present in rasterband
 italy_dem20_PHD_zone and would lead to data loss. Please specify
 a different nodata value with the nodata parameter.
ERROR: Raster export aborted.

Debugging r.out.gdal, I found that the value 10 was used.


GRASS 6.4.0svn (patUTM32):  r.info -r italy_dem20_PHD_zone
min=0
max=3890
GRASS 6.4.0svn (patUTM32):  r.info -t italy_dem20_PHD_zone
datatype=CELL

I hacked in -9 as NODATA value in the r.out.gdal calls
(spgrass6/R/bin_link.R).

I have no idea why 10 was used but from GRASS 6.4 onwards the r.out.gdal
module has an intelligent NODATA selection thanks to Markus Metz. I can
imagine what you don't want to clutter the code with conditions, but here it
would be great to let the NODATA selection job to r.out.gdal rather than
using the current r.info tricks.

What do you think?

Best,
Markus

PS: off for 2 weeks now
___
grass-stats mailing list
grass-stats@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-stats

Re: [GRASS-stats] readVECT6 not working

[Markus Neteler]

Dear Roger,

2009/10/22 Roger Bivand roger.biv...@nhh.no:
...
 vInfo() expects the output of v.info to be in English,
 otherwise it cannot be parsed. Change to an English locale and it will work.

This should not be needed, if...

 By the way, does anyone know of a non-localised way of retrieving the
 information needed - vInfo for bugsites returns:

  points      lines boundaries  centroids      areas    islands      faces
      90          0          0          0          0          0          0
   kernels
         0

... you use the -t flag for v.info which is not localised.

A related patch of vInfo should solve the problem. GRASS should
always offer a non-localised way to output such kind of information,
if missing please tell us and we add a related flag.

Best
Markus
___
grass-stats mailing list
grass-stats@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-stats

Re: [GRASS-stats] g.region: command not found using readRAST6 command

[Markus Neteler]

Tim Holland wrote:
 Dear all,

 Thank you very much for the help.  In the end, my problem was more
 basic than Augustin's suggestion.  Starting R from within GRASS was
 basically all I needed to do.  Also, Roger, thank you for the
 'pre-emptive' help with your comment about setting 'plugin=FALSE':
 sure enough, when I tried without that command, I got the following
 and R exited:

  x-readRAST6(GLC2000_Landcover_SEAsia)
 ERROR: Incompatible library version for module. You need to rebuild GRASS
or untangle multiple installations.

 But it worked fine with plugin=FALSE.

AFAIK this indicates in this case that the GRASS-GDAL plugin is out of sync
with GRASS. Rebuilding the plugin should help.

Background:
- first compile GDAL without GRASS support
- then compile GRASS (needs GDAL)
- then compile the GRASS-GDAL plugin (needs GDAL and GRASS)
- use R

Hope this helps,
Markus

___
grass-stats mailing list
grass-stats@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-stats

Re: [GRASS-stats] [Fwd: Re: [R-sig-Geo] Errror with gmeta6()]

[Markus Neteler]

2009/9/9 Agustin Lobo alobolis...@gmail.com:
 Any further help on this list?
 Agus
 On Wed, 9 Sep 2009, Agustin Lobo wrote:

 Hi!

 I've started spgrass6() with no problems
 (I get:
 GRASS GIS interface loaded with GRASS version: 6.4.0RC4
 and location: carlos

 but then get an error with gmeta6:

 gmeta6()

 g.region: error while loading shared libraries: libgrass_vect.so: cannot
 open shared object file: No such file or directory
 Error in if (file.exists(file) == FALSE) if (!missing(asText)  asText ==
  :
 argument is of length zero
 Error in parseGRASS(cmd) : g.region not parsed

 I'm using R  2.9.1 on ubuntu jaunty and just
 made install.packages(spgrass6)

 g.region -p  works fine in the grass console, but
  system(g.region -p)

 g.region: error while loading shared libraries: libgrass_vect.so: cannot
 open shared object file: No such file or directory

 This will be a dependency hell problem between GDAL and GRASS binaries,

I suspect that instead the LD link to the GRASS libraries is missing. I have
a file (create as root):

# something like this (adapt path):
cat /etc/ld.so.conf.d/grass.conf
/usr/local/grass640/dist.x86_64-unknown-linux-gnu/lib

The program ldconfig needs to be run afterwards.

Hope this helps
Markus
___
grass-stats mailing list
grass-stats@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-stats

Re: [GRASS-stats] [Fwd: Re: [R-sig-Geo] Errror with gmeta6()]

[Markus Neteler]

On Sun, Sep 13, 2009 at 10:02 PM, Agustin Lobo alobolis...@gmail.com wrote:
 Markus,

 gemeta6() works fine from any xterm console created
 from the grass console after changing
 /usr/lib/grass/lib
 to
 /usr/lib/grass64/lib

 in grass.conf
 as you suggested.

Excellent!

 I don't remember having made grass.conf though, is there any way
 for the installation to actually take place of this change of
 the grass directory name?

Indeed it is the job of the package manager which installs the
GRASS-GDAL plugin (or whereever this should happen). If needed,
please file a bug there in case it is missing on Ubuntu.

Glad to know it solved for now,
Markus
___
grass-stats mailing list
grass-stats@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-stats

Re: [GRASS-stats] creating a grid from a contour vector shape

[Markus Neteler]

Hi Alexandre,

On Sat, Sep 5, 2009 at 10:29 PM, alexandre
villersalexandre.vill...@cebc.cnrs.fr wrote:
 Good evening,

 I'm a beginner with GRASS. In order to analyse a dataset on the spatial 
 distribution of a bird's species, I wanted to create many spatial grids (with 
 increasing cell size, from 500 to 15000 meters)and then count birds in each 
 cell.

 I started with
 v.in.ogr to import a countour shape file for my observation window
 v.to.rast (countour)followed by r.mask to limit the work on that contour limit
 finally, v.mkgrid to create the grid with the required spatial resolution.

From your personal email I understand that contours are meant
here as boundaries of the study area.

Would this approach work?
http://grass.osgeo.org/wiki/Count_points_in_polygon

Best regards
Markus
___
grass-stats mailing list
grass-stats@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-stats

Re: [GRASS-stats] Sys.setlocale for GRASS6.4

[Markus Neteler]

(cc grass-dev)

@grass-dev: There are encoding issues with --interface-description
   which states UTF-8 also then the actual language encoding is different:

2009/9/4 Roger Bivand roger.biv...@nhh.no:
 OK, don't worry about that. I'll try to send an updated spgrass6 when I have
 adequate net access. The problem is that GRASS writes UTF-8 as the encoding
 into the XML header from --nterface-description, but the French translations
 seem (on my XP machine) to be in latin1, that is the 0x.. spell eacute
 (\'{e}) in latex, then fin from défine..., the first non-ASCII string in
 the output for g.region.

 The fix is to insert latin1 into the header, so I've updated the package
 to allow the user to do this from within R

This gave me another idea to check the .po files in GRASS 6.4:

grep charset locale/po/grass*_fr.po
locale/po/grasslibs_fr.po:Content-Type: text/plain; charset=ISO-8859-1\n
locale/po/grassmods_fr.po:Content-Type: text/plain; charset=ISO-8859-1\n
locale/po/grasstcl_fr.po:Content-Type: text/plain; charset=UTF-8\n
locale/po/grasswxpy_fr.po:Content-Type: text/plain; charset=UTF-8\n

Apparently the translators mixed several charsets instead of using one,
this is valid for various languages supported in GRASS.

@grass-dev: Should we harmonize the encodings to UTF-8 for all/subset
  of languages? If yes, how? With iconv?

@grass-stats: perhaps we need to do our homework first and fix the mess
  if it is a mess...

Markus
___
grass-stats mailing list
grass-stats@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-stats

Re: [GRASS-stats] Re: [R-sig-Geo] GRASS commands (fwd)

[Markus Neteler]

2009/9/1 Roger Bivand roger.biv...@nhh.no:
 Is this a bug in the interface description of v.mkgrid? It needs
 grid=rows,columns but sets multiple=NO, so wxpython fails (needing two
 values but getting one, but only providing an integer entry box).

It needs two values which are treated as one string, so it is correct.
(E.g. r.series accepts multiple input maps which are separate tokens which
required multiple=YES).

...
 grid=c(as.integer(100),as.integer(100)), box=c(5000, 5000),
 position=region))
 returns
 Erreur dans doGRASS(cmd, flags = flags, parameters = parameters) :
   Parameter grid has multiple values

 How do I specify the two values when multiple is not allowed. I did not
 get it

You used
 c(as.integer(100),as.integer(100))
[1] 100 100

 c(5000, 5000)
[1] 5000 5000

which leads to space separated values. But we want

 paste(as.integer(100), as.integer(100), sep=,)
[1] 100,100

 Consider the statsgrass list for use of the interface between R and 
GRASS,
 in this case there is an interaction between a possible bug in 
v.mkgrid and

 the parsing of its parameters.

 Since v.mkgrid does declare that grid does *not* take multiple 
values, the

 (current) logic of doGRASS() is defeated, as it checks that the multiple
 attribute if the GRASS parameter is not NO, see

 
http://trac.osgeo.org/grass/browser/grass/trunk/vector/v.mkgrid/main.c#L74


 The discrepancy between the code and the documentation is obvious.

There is no real discrepancy...
Hope above comments clarify it.

If not, we would need to see some debug output of doGRASS()...

Markus

--
Markus Neteler
Foundation Edmund Mach (FEM) - Research and Innovation Centre
Environment and Natural Resources Area
GIS and Remote Sensing Unit, Trento, Italy
Web:  http://gis.fem-environment.eu/

___
grass-stats mailing list
grass-stats@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-stats

Re: [GRASS-stats] Scatterplot thinning (points reduction)?

[Markus Neteler]

On Mon, Aug 17, 2009 at 9:33 AM, Roger Bivandroger.biv...@nhh.no wrote:
 On Sun, 16 Aug 2009, Markus Neteler wrote:

 Hi,

 I am plotting elevation against temperature and have the problem that
 including all points leads to heavy slow graphs... Reducing the raster
 resolution is not a solution since it does not maintain the
 characteristics
 of the graph (since GRASS is using nearest neighbor).

 One point initially. I'm assuming that you are using a Linux platform - on
 this platform, there is an order of magnitude speedup if you plot on screen
 without cairo, the default x11 type= - try using type=Xlib, which is
 much faster but not so refined.

(yes, Linux)
I have searched around bit I am not entirely sure to which function
this type parameter belongs.

 Given that, consider the cex= argument for varying symbol size, and maybe
 the pch=. possibility for using a single pt. point. They still all get
 drawn, so there is no time saving, but they may be more visible.

I am currently plotting like this:
plot(data$dem ~ data$raw)
points(data$dem ~ data$filt2, col=yellow, cex=0.5, pch=3)
points(data$dem ~ data$rst, col=green, xlab=LST value [°C],
ylab=elevation [m], pch=2)
abline(lm(data$dem ~ data$raw))
abline(lm(data$dem ~ data$filt2), col=yellow)
abline(lm(data$dem ~ data$rst), col=green, xlab=LST value [°C],
ylab=elevation [m])

So the backgound (largest) cloud comes in back circles,
the interim (smaller) in yellow crosses with many of them in the circles,
and the upper point could (smallest) in green triangles.
I guess the real problem are the 826896 * 3 points in the plot.

 For very large data sets, consider hexbin() in the hexbin package - I'm not
 sure how best to display three data sets. For single scatterplots, it is
 very powerful. Maybe contours of 2D densities of the extra data sets could
 be overlaid over a base hexbin plot? There is an informative vignette in
 hexbin.

Oh, this is interesting! Thanks,
Markus
___
grass-stats mailing list
grass-stats@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-stats

Re: [GRASS-stats] Scatterplot thinning (points reduction)?

[Markus Neteler]

On Mon, Aug 17, 2009 at 6:55 PM, Dylan Beaudettedebeaude...@ucdavis.edu wrote:
 On Monday 17 August 2009, Markus Neteler wrote:
 On Mon, Aug 17, 2009 at 9:33 AM, Roger Bivandroger.biv...@nhh.no wrote:
  On Sun, 16 Aug 2009, Markus Neteler wrote:
...
 just a quick note on style:

 # simpler notation:
 plot(dem ~ raw, data=data, xlab=LST value [°C], ylab=elevation [m])
 points(dem ~ filt2, data=data, col=yellow, cex=0.5, pch=3)
 points(dem ~ rst, data=data, col=green, pch=2)

Good point, thanks.

 also note that 'xlab' and other related commands need to be put into a
 high-level plotting command like 'plot()'

Sorry, I messed it up in my previous email: of course it works as you
indicate above...

 finally, you might be able to make the plot in one command with some
 incantation of xyplot() from the lattice package.

 did you have a chance to try the kde2() function from MASS?

Will try!

Best
Markus
___
grass-stats mailing list
grass-stats@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-stats

Re: [GRASS-stats] Scatterplot thinning (points reduction)?

[Markus Neteler]

Hi Dylan,

On Sun, Aug 16, 2009 at 8:02 PM, Dylan
Beaudettedylan.beaude...@gmail.com wrote:
 Hi Markus,

 Can you sample the original maps with v.random + v.what.rast first?

This gave me the idea: spsample() - I just read page 118 in Applied
spatial data analysis with R (great book, http://www.asdar-book.org/ !).

But apparently I am missing something... (I am certainly reading too fast):

# Spearfish example
 mydata - readRAST6(c(elevation.dem,soils))
 subdata - spsample(mydata, 500, type= random)

Looks good but...

 str(subdata)
Formal class 'SpatialPoints' [package sp] with 3 slots
  ..@ coords : num [1:497, 1:2] 600572 596804 599446 597732 600336 ...
  .. ..- attr(*, dimnames)=List of 2
  .. .. ..$ : NULL
  .. .. ..$ : chr [1:2] x y
  ..@ bbox   : num [1:2, 1:2] 590022 4914167 608953 4927981
  .. ..- attr(*, dimnames)=List of 2
  .. .. ..$ : chr [1:2] x y
  .. .. ..$ : chr [1:2] min max
  ..@ proj4string:Formal class 'CRS' [package sp] with 1 slots
  .. .. ..@ projargs: chr  +proj=utm +zone=13 +a=6378206.4
+rf=294.9786982 +no_defs
+nadgrids=/home/neteler/grass65/dist.x86_64-unknown-linux-gnu/etc/nad|
__truncated__

... where are the data?

The original looks like:
 str(mydata)
Formal class 'SpatialGridDataFrame' [package sp] with 6 slots
  ..@ data   :'data.frame': 2654802 obs. of  2 variables:
  .. ..$ elevation.dem: int [1:2654802] NA NA NA NA NA NA NA NA NA NA ...
  .. ..$ soils: int [1:2654802] NA NA NA NA NA NA NA NA NA NA ...
  ..@ grid   :Formal class 'GridTopology' [package sp] with 3 slots
  .. .. ..@ cellcentre.offset: Named num [1:2] 590015 4914025
  .. .. .. ..- attr(*, names)= chr [1:2] x y
  .. .. ..@ cellsize : num [1:2] 10 10
  .. .. ..@ cells.dim: int [1:2] 1899 1398
  ..@ grid.index : int(0)
  ..@ coords : num [1:2, 1:2] 590015 608995 4914025 4927995
  .. ..- attr(*, dimnames)=List of 2
  .. .. ..$ : NULL
  .. .. ..$ : chr [1:2] x y
  ..@ bbox   : num [1:2, 1:2] 590010 4914020 609000 4928000
  .. ..- attr(*, dimnames)=List of 2
  .. .. ..$ : chr [1:2] x y
  .. .. ..$ : chr [1:2] min max
  ..@ proj4string:Formal class 'CRS' [package sp] with 1 slots
  .. .. ..@ projargs: chr  +proj=utm +zone=13 +a=6378206.4
+rf=294.9786982 +no_defs
+nadgrids=/home/neteler/grass65/dist.x86_64-unknown-linux-gnu/etc/nad|
__truncated__

According to
showMethods(spsample)
grids are supported... I guess I am missing a trivial bit, might be
the time here...

thanks
Markus
___
grass-stats mailing list
grass-stats@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-stats

Re: [GRASS-stats] Mapset issue with vector data via OGR plugin

[Markus Neteler]

On Fri, Aug 14, 2009 at 11:40 AM, Roger Bivandroger.biv...@nhh.no wrote:
 On Fri, 14 Aug 2009, Markus Neteler wrote:
 I have some troubles when the vector map name contains the
 @mapset part:

 This is a consequence of the plugin only searching in the current user's
 mapset, so using extra code to scan other mapsets:

        if (is.null(mapset)) mapset - .g_findfile(vname[1], type=vector)
        dsn - paste(gg$GISDBASE, gg$LOCATION_NAME, mapset,
            vector, vname, head, sep=/)

 where .g_findfile() runs g.findfile. This seems to fail when @mapset is
 given.

I have made a test:

GRASS 6.5.svn (spearfish60):~  g.findfile element=vector
file=rand5k_elev_f...@neteler mapset=neteler
name='rand5k_elev_f...@neteler'
mapset='neteler'
fullname='rand5k_elev_f...@neteler'
file='/home/neteler/grassdata/spearfish60/neteler/vector/rand5k_elev_filt'

GRASS 6.5.svn (spearfish60):~  g.findfile element=vector
file=rand5k_elev_f...@claus mapset=neteler
ERROR: Parameter 'file' contains reference to claus mapset, but mapset
   parameter neteler does not correspond

At least it does not crash...

 I guess that the work-around is to use the argument mapset=neteler
 in readVECT6() and readRAST6() for now, but I could look at trying to detect
 the @ and use it (in the plugin case only) to assign to a null mapset,
 throwing an error if mapset is non-null and @ is used.

This would be nice. I am currently testing v.krige.py from Anne
and it (I guess the underlying GRASS wxGUI part) adds automatically
the @mapset part to the map even when it is in the current mapset.

I am not sure how to solve that in order to make the R code overly
complex.

 Hope this helps,

Thanks for you explanations (and potential error trapping),
Markus
___
grass-stats mailing list
grass-stats@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-stats

Re: [GRASS-stats] Mapset issue with vector data via OGR plugin

[Markus Neteler]

Dear Roger,

On Fri, Aug 14, 2009 at 6:22 PM, Roger Bivandroger.biv...@nhh.no wrote:
 On Fri, 14 Aug 2009, Markus Neteler wrote:

 On Fri, Aug 14, 2009 at 11:40 AM, Roger Bivandroger.biv...@nhh.no wrote:

 On Fri, 14 Aug 2009, Markus Neteler wrote:

 I have some troubles when the vector map name contains the
 @mapset part:

 This is a consequence of the plugin only searching in the current user's
 mapset, so using extra code to scan other mapsets:

        if (is.null(mapset)) mapset - .g_findfile(vname[1],
 type=vector)
        dsn - paste(gg$GISDBASE, gg$LOCATION_NAME, mapset,
            vector, vname, head, sep=/)

 where .g_findfile() runs g.findfile. This seems to fail when @mapset is
 given.

 Could you try out the revisions on sourceforge CVS:

 cvs -z3 \
 -d:pserver:anonym...@r-spatial.cvs.sourceforge.net:/cvsroot/r-spatial co \
 -P spgrass6

 I think it works, but checking wouldn't hurt!

Great, it works now:

# Test 1, now ok:
 data - readVECT6(rand5k_elev_f...@neteler, type= 'point')
OGR data source with driver: GRASS
Source: 
/home/neteler/grassdata/spearfish60/neteler/vector/rand5k_elev_filt/head,
layer: 1
with 4885 features and 5 fields
Feature type: wkbPoint with 2 dimensions

# Test2, ok as before
 data - readVECT6(rand5k_elev_filt, type= 'point')
OGR data source with driver: GRASS
Source: 
/home/neteler/grassdata/spearfish60/neteler/vector/rand5k_elev_filt/head,
layer: 1
with 4885 features and 5 fields
Feature type: wkbPoint with 2 dimensions

# Test 3: nonsense input
 data - readVECT6(rand5k_elev_f...@neteler, type= 'point', mapset=benno)
Error in ogrInfo(dsn = dsn, layer = layer, input_field_name_encoding =
input_field_name_encoding) :
  Cannot open file

Thanks for the quick fix,
Markus
___
grass-stats mailing list
grass-stats@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-stats

[GRASS-stats] Mapset issue with vector data via OGR plugin

[Markus Neteler]

Hi,

I have some troubles when the vector map name contains the
@mapset part:


R
R version 2.9.1 (2009-06-26)
...
 library(spgrass6)
Loading required package: sp
Loading required package: rgdal
Geospatial Data Abstraction Library extensions to R successfully loaded
Loaded GDAL runtime: GDAL 1.7.0dev, released 2008/11/26
Path to GDAL shared files: /usr/local/share/gdal
Loaded PROJ.4 runtime: Rel. 4.6.1, 21 August 2008
Path to PROJ.4 shared files: (autodetected)
Loading required package: XML

 data - readVECT6(rand5k_elev_f...@neteler, type= 'point')
Error in ogrInfo(dsn = dsn, layer = layer, input_field_name_encoding =
input_field_name_encoding) :
  Cannot open file

while this works:

 data - readVECT6(rand5k_elev_filt, type= 'point')
OGR data source with driver: GRASS
Source: 
/home/neteler/grassdata/spearfish60/neteler/vector/rand5k_elev_filt/head,
layer: 1
with 4885 features and 5 fields
Feature type: wkbPoint with 2 dimensions

I have used update.packages() and should have the latest sp* packages.
I tried to debug the problem but failed...

Can anyone confirm this problem?

thanks
Markus
___
grass-stats mailing list
grass-stats@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-stats

Re: [GRASS-stats] spgrass problem importing category 999 when plugin is FALSE

[Markus Neteler]

On Fri, Apr 3, 2009 at 9:07 AM, Roger Bivand roger.biv...@nhh.no wrote:
 On Fri, 3 Apr 2009, Jarek Jasiewicz wrote:

 Hi

 I during batch processing of couple of maps I found strange behaviour of
 readRAST6 when I import cell map with value 999.
 Instead of 999 Na is imported (?? _

 It is for me completely strange, so I test it with folowing:

 OK. This is a consequence of trying to guess the NODATA value to pass to
 r.out.gdal,

The C version of r.out.gdal has a nodata parameter.

 and I don't see it in 0.5-19 (my local slightly changed from
 CRAN latest 0.5-18). For certain range values retrieved from r.info, NODATA
 is assigned the value 999 (R/bin_link.R, about line 113). Please try 0.5-18,
 I suspect that the condition was changed. Alternatively, set NODATA to a
 suitable value outside the range of the data. Note that I don't have a 6.5
 GRASS, and if r.info output has changed format, the parsing will be wrong,

It didn't change the format to my knowledge. BUT:
To get the range, use
r.info -r test_map
min=999
max=999

The parsing of plain r.info will fail in non-English locales (or enforce C
locale).

...
 I guess that there is a smarter way of getting the raster min/max too, isn't
 there?

Yes, please always use the script output flags which are not subject to locale
and way easier to parse. If missing in a module, we are happy to add it.
It also exists in GRASS 6.3:
http://trac.osgeo.org/grass/browser/grass/branches/releasebranch_6_3/raster/r.info/main.c#L74

Best
Markus
___
grass-stats mailing list
grass-stats@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-stats

Re: [GRASS-stats] Re: [GRASS-user] Testing i.pca ~ prcomp(), m.eigensystem ~ princomp()

[Markus Neteler]

On Tue, Mar 31, 2009 at 5:00 PM, Markus Metz
markus.metz.gisw...@googlemail.com wrote:
 Nikos Alexandris wrote:
 Using MODIS (range varries between bands, up to max. ~5500):


 Sure? Valid range: -100 - 16000 for MODIS e.g. Surface Reflectance 8-Day L3
 Global 500m.

Remember that you have to rescale these data first:

https://lpdaac.usgs.gov/lpdaac/products/modis_products_table
- MOD09Q1  Terra   Surface Reflectance Bands 1–2   Tile250m8 Day

https://lpdaac.usgs.gov/lpdaac/products/modis_products_table/surface_reflectance/8_day_l3_global_250m/v5/terra
   - layers

... MULTIPLY BY SCALE FACTOR ...

best,
Markus
___
grass-stats mailing list
grass-stats@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-stats

[GRASS-stats] StatGIS 09 GeoInformatics for Environmental Surveillance

[Markus Neteler]

Conference announcement (last call):

StatGIS 09 GeoInformatics for Environmental Surveillance

Location: Milos Island, Greece. George Eliopoulos Milos Conference Centre
Conference Dates: June 17-19, 2009.
Conference Web Site: http://milos.conferences.gr/statgis2009/
Contact: statgis2...@heliotopos.net



Keynote Speakers:
--

We are pleased to announce the following keynote speakers for this event:

+ Noel Cressie, Ohio State University: Spatio-Temporal Random Effects Filtering

+ Hans Wackernagel, Ecole des Mines de Paris: Data assimilation for
epidemiological surveillance

+ Stefano Nativi, CNR-IMAA, University of Florence: Multidisciplinary
interoperability architectures, some GEOSS and GMES experiences


Conference Overview:
-

StatGIS is addressed to researchers in academia and research
institutes, as well as practitioners and industry professionals who
want to learn about recent developments in spatial statistics and
their applications, and to share their experiences in these areas.
Application fields of interest for this conference will include, but
not be limited, to: spatial environmental modelling, early warning
monitoring systems for the environment, geostatistics in natural
hazards prediction, optimum spatial design, space-time analysis and
renewable energy resources, remote sensing applications in land
reclamation after mining exploitation, spatial metrics for
biodiversity assessment and monitoring, etc.

The conference will provide an opportunity for researchers and
industry to meet and exchange the latest in spatial statistics and
geoinformatics with an emphasis on the main steps involved in
environmental monitoring and surveillance. We will start with the
collection of data from environmental sensors and monitoring networks
and further discuss their use by the web services and systems involved
in the processing of the information. The automated analysis of the
data and the detection of anomalies and changes will also be covered
before finally addressing the visualization and communication of the
generated information for efficient decision making.

The international character of the conference will be an opportunity
to focus on GMES (Global Monitoring for Environment and Security) and
GEOSS (Global Earth Observation System of Systems) related issues, in
particular on the need for cost-effective sustainable services.
StatGIS 2009 will therefore focus on generic solutions, re-usable
software solutions, in particular Open Source technology, and
interoperability of systems. Cross-border issues that affect the
homogeneity of geographic information (INSPIRE) and of global
environmental monitoring networks as well as the interoperability of
the systems will also be covered.

Those used to the tradition of StatGIS being an important meeting to
learn about the latest developments in geostatistics and spatial
statistics will not be disappointed by the challenges that will be
discussed in Milos. Statistical issues that will be covered range from
the analysis of data provided by heterogeneous networks, the automatic
detection of anomalies for early warning, to the real-time
interpolation of data collected by mobile devices or the fast
processing of environmental data for reducing computing times. The
monitoring of environmental risks using spatial statistics and
geoinformatics covers a large number of applications. These cover
issues as different as environmental radioactivity, global change,
biodiversity, pests, floods, droughts, fires or earthquakes but also
health risks associated with the spreading of viruses or any health
threats.

Key papers will be published in a special issue of Computers  Geosciences.


Conference Topics
---

Topic A. Monitoring networks and Sensor Webs
Topic B. Service Oriented Architectures for Environmental Monitoring
Topic C. Statistics and spatial metrics for Environmental Monitoring
Topic D. Open Source tools for Environmental Web Services
Topic E. Applications and Case Studies
Topic F. Visualisation and Decision-Making
Topic G. Socio-economical benefits of Service Oriented Architectures
for Environmental Monitoring


Workshop: Lessons learned from INTAMAP, an interoperable framework
for real-time automatic mapping of critical environmental variables


Important dates and deadlines
---

- Friday 13 February 2009 - Abstract submission.
- Friday 27 February 2009 – Notification of abstract acceptance
- Friday 2 April 2009 – Submission of full papers
- Friday 24 April 2009 – End of reviewing
- Friday 8 May 2009 – Submission of camera ready copies of corrected papers
- 17-19 June 2009: Conference in Milos, Greece


Conference Fees:
--

Early registration until April 25th
Students: 150 Euros
Regular: 300 Euros

Late registration
Students: 200 Euros
Regular: 350 Euros


Organizing Committee
-

Cornford, Dan (Aston University, UK)
Dubois, Gregoire (JRC, European 

Re: [GRASS-stats] Incompatible library version for module SOLVED but new problem with plugin=TRUE has emerged

[Markus Neteler]

On Sat, Jan 3, 2009 at 11:09 AM, Roger Bivand roger.biv...@nhh.no wrote:
 The current settings of readRAST6() will use the plugin if available (but
 try to check that the regions match) when plugin=NULL. If you want to force
 the use of r.out.gdal, set plugin=FALSE and useGDAL=TRUE (version 0.5-16).
 Please let me know if this helps.

I have installed R (R version 2.8.1 (2008-12-22)) + extensions from scratch.
I get now this message (GRASS book p. 358):

 elev - readRAST6(elev_state_500m, mapset=PERMANENT, ignore.stderr=TRUE)
   colsrows origin.northing  origin.easting
  FALSE   FALSE   FALSETRUE
Warning message:
In readRAST6(elev_state_500m, mapset = PERMANENT,  :
  set plugin=FALSE - raster/current window mismatch
  or plugin=TRUE to override; continuing with plugin=FALSE

To me it is not clear from the message that I should (better) set
useGDAL=TRUE

Ideally, the interface would work as simple as this
 elev - readRAST6(elev_state_500m)

which would
* find the map in the current mapset search path (internally, use g.findfile),
  in my tests I was in a mapset different from PERMANENT which leads to
 elev - readRAST6(elev_state_500m, ignore.stderr=TRUE)
 Error in .local(.Object, ...) :
GDAL Error 4:
`/home/neteler/grassdata/nc_spm_07/user1/cellhd/elev_state_500m' does
not exist in the file system,
and is not recognised as a supported dataset name.

* use the current region (internally, use r.in.gdal and not the plugin
if GRASS = 6.4)

Successfully, I have used today:
elev - readRAST6(elev_state_500m, mapset=PERMANENT,
ignore.stderr=TRUE, plugin=FALSE, useGDAL=TRUE)

which is rather long/complex.

Hope I am not asking too much - try to compensate with GRASS 6.4.x work :)

Markus
___
grass-stats mailing list
grass-stats@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-stats

Re: [GRASS-stats] Incompatible library version for module SOLVED but new problem with plugin=TRUE has emerged

[Markus Neteler]

On Sat, Jan 3, 2009 at 7:54 AM, Markus Neteler nete...@osgeo.org wrote:
 On Fri, Jan 2, 2009 at 7:38 PM, Jarek Jasiewicz jar...@amu.edu.pl wrote:
 but this means that plugin ignores current region setings!

 Yes. That's why I suggested to implement r.out.gdal usage
 in the GRASS-R extension time ago (see this list archive,
 dateSun, Jun 1, 2008 at 9:40 PM
 subject Re: [GRASS-stats] Speedup of readVECT6() with plugin
 ).

 There is a plugin switch which you set to plugin=TRUE, perhaps
 it needs to be FALSE to make use of the better + faster r.out.gdal
 which would solve your problem as it is resolution/region sensitive.

OK, I checked the source code of spgrass6_0.5-16.tar.gz
and the manual at
 http://cran.r-project.org/web/packages/spgrass6/index.html

which says:
useGDAL:
   default FALSE using r.out.bin or r.in.bin, if TRUE use r.out.gdal
or r.in.gdal,
   GTiff, and readGDAL or writeGDAL


So this switch should solve your problem.

Markus

PS: Upon a test if GRASS is = 6.4 I suggest to set useGDAL=TRUE
 in spgrass6.
___
grass-stats mailing list
grass-stats@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-stats

Re: [GRASS-stats] Rdbi Error in loadNamespace

[Markus Neteler]

On Tue, Jun 17, 2008 at 4:07 AM, Hamish [EMAIL PROTECTED] wrote:
 Stanislav wrote:
 I have a problem to connect my Postgre with R.
 I did everything after Markus tutorial. It worked.
 But next time I used it, I cannot go over this error:

  library(Rdbi)
 Loading required package: Rdbi
 Error in loadNamespace(package, c(which.lib.loc, lib.loc),
 keep.source = keep.source) :
   cyclic name space dependencies are not supported
 Error : package 'Rdbi' could not be loaded
 Error : .onLoad failed in 'loadNamespace' for
 'Rdbi'
 Error: package/namespace load failed for 'Rdbi'
 

 I also tried to reinstall R, did not help.

 maybe a silly question, but is the Rdbi package already loaded at that point?

Loading is done like this (maybe silly suggestion again):

library(Rdbi)
library(RdbiPgSQL)

(I discovered the hard way some months ago that the second
command is also needed, it wasn't some years ago).

Then, evil can creep in after version change through .RData in
the current working directory.

Markus
___
grass-stats mailing list
grass-stats@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-stats

Re: [GRASS-stats] Speedup of readVECT6() with plugin

[Markus Neteler]

On Sat, May 31, 2008 at 6:35 PM, Roger Bivand [EMAIL PROTECTED] wrote:
 On Sat, 31 May 2008, Markus Neteler wrote:
 On Sat, May 31, 2008 at 5:51 PM, Roger Bivand [EMAIL PROTECTED] wrote:
 On Sat, 31 May 2008, Markus Neteler wrote:
 I have to read in Lidar data from GRASS, so speed matters. I have
 modified the readVECT6() function to not export to SHAPE but
 read in directly via GRASS-GDAL/OGR plugin:

 Dear Markus,

 In theory maybe, but if I cannot make the plugin work (I use SELinux on
 F7 for trials, and I have not found out how to make it accept the *.so from
 GRASS), then I don't think that it is going to be very helpful.

 Sure. but I can help you if you like (got it running on various kinds of
 machines). It's also documented:

 http://grass.osgeo.org/wiki/Compile_and_install_GRASS_and_QGIS_with_GDAL/OGR_Plugin

 Including machines with SELinux running? It is very picky with ldconfig.

I have never tried SELinux.
But I simply use:

cat /etc/ld.so.conf.d/grass.conf
/home/neteler/grass64/dist.x86_64-unknown-linux-gnu/lib

(so I don't even run make install but use GRASS from
my home)


...
 Aha, I've been compiling with GRASS support, which was the old way. I'll try
 again.

thanks and good luck,
Markus
___
grass-stats mailing list
grass-stats@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-stats