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

[Markus Neteler]

Dear Roger, all,

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:

# original, via SHAPE:
> system("date")
Sat May 31 12:17:05 CEST 2008
> lidar1 <- readVECT6("lidar1map3d", ignore.stderr=TRUE)
> system("date")
Sat May 31 12:28:33 CEST 2008


# simplified version using plugin:
> system("date")
Sat May 31 12:28:33 CEST 2008
> lidar1 <- myreadVECT6("lidar1map3d", ignore.stderr=TRUE)
> system("date")
Sat May 31 12:29:26 CEST 2008

I used directly readOGR():

# hack:
    res <- readOGR(dsn =
"/home/neteler/grassdata/eth_utm32/PERMANENT/vector/lidar1map3d/head",
layer = "1", verbose = !ignore.stderr)

Would it be possible to use this approach if the plugin
is present, otherwise fallback to SHAPE export as before?

Thanks
Markus
_______________________________________________
grass-stats mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-stats

[Roger Bivand]

On Sat, 31 May 2008, Markus Neteler wrote:

> Dear Roger, all,
>
> 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. In
addition, there is only a read driver, I believe.

However, using readOGR() directly is fine, and as you show, is far
superior to intermediate files if available.

The plugin circular dependencies are a common reason for GDAL and rgdal
not working, I'm afraid.

Best wishes,

Roger

>
> # original, via SHAPE:
>> system("date")
> Sat May 31 12:17:05 CEST 2008
>> lidar1 <- readVECT6("lidar1map3d", ignore.stderr=TRUE)
>> system("date")
> Sat May 31 12:28:33 CEST 2008
>
>
> # simplified version using plugin:
>> system("date")
> Sat May 31 12:28:33 CEST 2008
>> lidar1 <- myreadVECT6("lidar1map3d", ignore.stderr=TRUE)
>> system("date")
> Sat May 31 12:29:26 CEST 2008
>
> I used directly readOGR():
>
> # hack:
>    res <- readOGR(dsn =
> "/home/neteler/grassdata/eth_utm32/PERMANENT/vector/lidar1map3d/head",
> layer = "1", verbose = !ignore.stderr)
>
> Would it be possible to use this approach if the plugin
> is present, otherwise fallback to SHAPE export as before?
>
> Thanks
> Markus
> _______________________________________________
> grass-stats mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/grass-stats
>

--
Roger Bivand
Economic Geography Section, Department of Economics, Norwegian School of
Economics and Business Administration, Helleveien 30, N-5045 Bergen,
Norway. voice: [phone]; fax [phone]
e-mail: [hidden email]

_______________________________________________
grass-stats mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-stats

[Markus Neteler]

Dear Roger,

On Sat, May 31, 2008 at 5:51 PM, Roger Bivand <[hidden email]> wrote:

> On Sat, 31 May 2008, Markus Neteler wrote:
>
>> Dear Roger, all,
>>
>> 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

My idea was: use it then it is present. That's just an additional
if condition in the code. I'll figure out how to test that (I guess that
readOGR() may know which drivers it has).

> In addition, there is only a read driver, I believe.

Right. But accelerating read in would be quite welcome.

> However, using readOGR() directly is fine, and as you show, is far superior
> to intermediate files if available.
>
> The plugin circular dependencies are a common reason for GDAL and rgdal not
> working, I'm afraid.

I am not sure about this: I have all working here, just fetching things from
CRAN. GDAL should *not* be compiled with GRASS support. Then the
GDAL-GRASS plugin doesn't interfere and is only loaded on demand
internally from GRASS when the GRASS driver is called.

Best wishes,
Markus
_______________________________________________
grass-stats mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-stats

[Roger Bivand]

On Sat, 31 May 2008, Markus Neteler wrote:

> Dear Roger,
>
> On Sat, May 31, 2008 at 5:51 PM, Roger Bivand <[hidden email]> wrote:
>> On Sat, 31 May 2008, Markus Neteler wrote:
>>
>>> Dear Roger, all,
>>>
>>> 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.

>
> My idea was: use it then it is present. That's just an additional
> if condition in the code. I'll figure out how to test that (I guess that
> readOGR() may know which drivers it has).

ogrDrivers() gives the installed drivers, but there would be more to do to
check the arguments to readOGR().

>
>> In addition, there is only a read driver, I believe.
>
> Right. But accelerating read in would be quite welcome.
>
>> However, using readOGR() directly is fine, and as you show, is far superior
>> to intermediate files if available.
>>
>> The plugin circular dependencies are a common reason for GDAL and rgdal not
>> working, I'm afraid.
>
> I am not sure about this: I have all working here, just fetching things from
> CRAN. GDAL should *not* be compiled with GRASS support. Then the
> GDAL-GRASS plugin doesn't interfere and is only loaded on demand
> internally from GRASS when the GRASS driver is called.

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

Roger

>
> Best wishes,
> Markus
>

--
Roger Bivand
Economic Geography Section, Department of Economics, Norwegian School of
Economics and Business Administration, Helleveien 30, N-5045 Bergen,
Norway. voice: [phone]; fax [phone]
e-mail: [hidden email]

_______________________________________________
grass-stats mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-stats

[Markus Neteler]

On Sat, May 31, 2008 at 6:35 PM, Roger Bivand <[hidden email]> wrote:

> On Sat, 31 May 2008, Markus Neteler wrote:
>> On Sat, May 31, 2008 at 5:51 PM, Roger Bivand <[hidden email]> 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
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-stats

[Roger Bivand]

On Sat, 31 May 2008, Markus Neteler wrote:

> On Sat, May 31, 2008 at 6:35 PM, Roger Bivand <[hidden email]> wrote:
>> On Sat, 31 May 2008, Markus Neteler wrote:
>>> On Sat, May 31, 2008 at 5:51 PM, Roger Bivand <[hidden email]> 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:

The SELinux was a red herring, I simply hadn't understood the change in
plugin technology. The current CVS version works for me on F7 under
SELinux with the plugin built as described in the wiki.

Please try the CVS version at:

cvs -d:pserver:[hidden email]:/cvsroot/r-spatial
login

cvs -z3
-d:pserver:[hidden email]:/cvsroot/r-spatial co
-P spgrass6

or a variant that works. The vector version looks OK, the raster version
is basic (uses data resolution not window resolution, and only handles one
raster at a time without categories).

Roger

>
> 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
>

--
Roger Bivand
Economic Geography Section, Department of Economics, Norwegian School of
Economics and Business Administration, Helleveien 30, N-5045 Bergen,
Norway. voice: [phone]; fax [phone]
e-mail: [hidden email]

_______________________________________________
grass-stats mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-stats

[Markus Neteler]

On Sun, Jun 1, 2008 at 8:47 PM, Roger Bivand <[hidden email]> wrote:
> On Sat, 31 May 2008, Markus Neteler wrote:
>> On Sat, May 31, 2008 at 6:35 PM, Roger Bivand <[hidden email]> wrote:
>>> On Sat, 31 May 2008, Markus Neteler wrote:
>>>> On Sat, May 31, 2008 at 5:51 PM, Roger Bivand <[hidden email]> 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:
...
> The SELinux was a red herring, I simply hadn't understood the change in
> plugin technology. The current CVS version works for me on F7 under SELinux
> with the plugin built as described in the wiki.
>
> Please try the CVS version at:
>
> cvs -d:pserver:[hidden email]:/cvsroot/r-spatial login
>
> cvs -z3 -d:pserver:[hidden email]:/cvsroot/r-spatial co -P spgrass6


Dear Roger,

thanks for the high speed rewrite of the interface. Downloaded and installed
successfully (I see the new message
"GRASS GIS interface loaded with GRASS version: 6.4.svn"
).

> or a variant that works. The vector version looks OK,

I have made the test again but cannot observe a speed improvement.
I guess I have to debug it somehow.

> the raster version is
> basic (uses data resolution not window resolution, and only handles one
> raster at a time without categories).

AFAIK the plugin delivers only *original* raster resolution and extent (that's
why r.out.gdal was written in C to replace a former plugin based shell script).
So, unless the plugin is changed here it might not be that useful for raster
data *if* the GRASS behaviour of respecting raster settings during export
should be maintained.

thanks,
Markus
_______________________________________________
grass-stats mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-stats

[hamish-2]

Roger:
> > the raster version is basic (uses data resolution not window
> > resolution, and only handles one raster at a time without categories).

Markus:
> AFAIK the plugin delivers only *original* raster resolution
> and extent (that's why r.out.gdal was written in C to replace
> a former plugin based shell script).
> So, unless the plugin is changed here it might not be that
> useful for raster data *if* the GRASS behaviour of respecting raster
> settings during export should be maintained.

maybe the solution is just adding another line somewhere that does like
if( wind.region != map.region )
  r.mapcalc "tmp.R.outputmap.$$ = $inputmap"
else
  g.copy "$inputmap,tmp.R.outputmap.$$"

?

Or do the commands have to come from the R side, so no GRASS module commands can be used? Or else teach the user to do that cropping/resampling first (which is not a very nice solution IMO).


Hamish



     

_______________________________________________
grass-stats mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-stats

[Roger Bivand]

On Sun, 1 Jun 2008, Markus Neteler wrote:

> On Sun, Jun 1, 2008 at 8:47 PM, Roger Bivand <[hidden email]> wrote:
>> On Sat, 31 May 2008, Markus Neteler wrote:
>>> On Sat, May 31, 2008 at 6:35 PM, Roger Bivand <[hidden email]> wrote:
>>>> On Sat, 31 May 2008, Markus Neteler wrote:
>>>>> On Sat, May 31, 2008 at 5:51 PM, Roger Bivand <[hidden email]> 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:
> ...
>> The SELinux was a red herring, I simply hadn't understood the change in
>> plugin technology. The current CVS version works for me on F7 under SELinux
>> with the plugin built as described in the wiki.
>>
>> Please try the CVS version at:
>>
>> cvs -d:pserver:[hidden email]:/cvsroot/r-spatial login
>>
>> cvs -z3 -d:pserver:[hidden email]:/cvsroot/r-spatial co -P spgrass6
>
>
> Dear Roger,
>
> thanks for the high speed rewrite of the interface. Downloaded and installed
> successfully (I see the new message
> "GRASS GIS interface loaded with GRASS version: 6.4.svn"
> ).
>
>> or a variant that works. The vector version looks OK,
>
> I have made the test again but cannot observe a speed improvement.
> I guess I have to debug it somehow.

Markus,

For now, the plugin= argument defaults to FALSE. If NULL, it will
autodetect, if TRUE, it will try to use the plugin or fail. To avoid
breaking things for users with a plugin but scripts that might break, I
set plugin=FALSE for now. Once we have some experience, I'll increment the
version number from 0.5-* to 0.6-1, and set plugin=NULL by default.

Roger

>
>> the raster version is
>> basic (uses data resolution not window resolution, and only handles one
>> raster at a time without categories).
>
> AFAIK the plugin delivers only *original* raster resolution and extent (that's
> why r.out.gdal was written in C to replace a former plugin based shell script).
> So, unless the plugin is changed here it might not be that useful for raster
> data *if* the GRASS behaviour of respecting raster settings during export
> should be maintained.
>
> thanks,
> Markus
>

--
Roger Bivand
Economic Geography Section, Department of Economics, Norwegian School of
Economics and Business Administration, Helleveien 30, N-5045 Bergen,
Norway. voice: [phone]; fax [phone]
e-mail: [hidden email]

_______________________________________________
grass-stats mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-stats

[Roger Bivand]

On Sun, 1 Jun 2008, Hamish wrote:

> Roger:
>>> the raster version is basic (uses data resolution not window
>>> resolution, and only handles one raster at a time without categories).
>
> Markus:
>> AFAIK the plugin delivers only *original* raster resolution
>> and extent (that's why r.out.gdal was written in C to replace
>> a former plugin based shell script).
>> So, unless the plugin is changed here it might not be that
>> useful for raster data *if* the GRASS behaviour of respecting raster
>> settings during export should be maintained.
>
> maybe the solution is just adding another line somewhere that does like
> if( wind.region != map.region )
>  r.mapcalc "tmp.R.outputmap.$$ = $inputmap"
> else
>  g.copy "$inputmap,tmp.R.outputmap.$$"
>
> ?
>
> Or do the commands have to come from the R side, so no GRASS module
> commands can be used? Or else teach the user to do that
> cropping/resampling first (which is not a very nice solution IMO).

Hamish,

The direct way (with R running inside but on top of GRASS, R CLI) is to
use GRASS modules in system(). However, I'm close to using the discussion
of earlier this year to parse the --interface-description output from XML
to R-usable strings, so that it would be feasible to have a generic
interface from R to GRASS modules. Would anyone be interested in my adding
the draft code to the CVS site? If anyone would like to join in, I can
move spgrass6 to svn on R-forge and invite developers - on the
sourceforge cvs, all the sp modules have write access for developers, so
it isn't so sensible.

With this available, the resampling could either be done by the user under
better control than just using system() directly, or coded into the
interface functions (still using system but under control of things like
escaping). The code would be much cleaner than that currently used. I
think the variants for native Windows/Cygwin/others will still have to
co-exist, though.

Roger

>
>
> Hamish
>
>
>
>
>
>

--
Roger Bivand
Economic Geography Section, Department of Economics, Norwegian School of
Economics and Business Administration, Helleveien 30, N-5045 Bergen,
Norway. voice: [phone]; fax [phone]
e-mail: [hidden email]

_______________________________________________
grass-stats mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-stats

[Markus Neteler]

Dear Roger,

On Sun, Jun 1, 2008 at 11:22 PM, Markus Neteler <[hidden email]> wrote:
...
If I manually set plugin=TRUE, it fails:
> lidar1 <- readVECT6("lidar1map3d", ignore.stderr=TRUE, plugin=TRUE)
Error in ogrInfo(dsn = dsn, layer = layer) : Cannot open file

With debugging I found that the map is only searched in the
current mapset. In my case, however, the map is sitting in another mapset...
Would it be possible to add g.findfile there to construct the full
path to the map?

g.findfile element=vector file=gauss_random
name='gauss_random'
mapset='sqlite'
fullname='gauss_random@sqlite'
file='/home/neteler/grassdata/nc_spm_07/sqlite/vector/gauss_random'

The "file" line contains (almost) the dsn path (+ /head)

Best wishes,
Markus
_______________________________________________
grass-stats mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-stats

[Roger Bivand]

On Mon, 2 Jun 2008, Markus Neteler wrote:

> Dear Roger,
>
> On Sun, Jun 1, 2008 at 11:22 PM, Markus Neteler <[hidden email]> wrote:
> ...
> If I manually set plugin=TRUE, it fails:
>> lidar1 <- readVECT6("lidar1map3d", ignore.stderr=TRUE, plugin=TRUE)
> Error in ogrInfo(dsn = dsn, layer = layer) : Cannot open file
>
> With debugging I found that the map is only searched in the
> current mapset. In my case, however, the map is sitting in another mapset...
> Would it be possible to add g.findfile there to construct the full
> path to the map?

Please use the new mapset= argument in readVECT6() or readRAST6(). I
prefer this for the moment to trying to insert @ parsing or extra code.
The user can run system("g.findfile ...") to check.

Roger

>
> g.findfile element=vector file=gauss_random
> name='gauss_random'
> mapset='sqlite'
> fullname='gauss_random@sqlite'
> file='/home/neteler/grassdata/nc_spm_07/sqlite/vector/gauss_random'
>
> The "file" line contains (almost) the dsn path (+ /head)
>
> Best wishes,
> Markus
>

--
Roger Bivand
Economic Geography Section, Department of Economics, Norwegian School of
Economics and Business Administration, Helleveien 30, N-5045 Bergen,
Norway. voice: [phone]; fax [phone]
e-mail: [hidden email]

_______________________________________________
grass-stats mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-stats

[Markus Neteler]

Dear Roger,

On Mon, Jun 2, 2008 at 10:03 AM, Roger Bivand <[hidden email]> wrote:
> On Sun, 1 Jun 2008, Markus Neteler 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:
...
>> thanks for the high speed rewrite of the interface. Downloaded and
>> installed
>> successfully (I see the new message
>> "GRASS GIS interface loaded with GRASS version: 6.4.svn"
>> ).
>>
>>> or a variant that works. The vector version looks OK,
>>

> Markus,
>
> For now, the plugin= argument defaults to FALSE. If NULL, it will
> autodetect, if TRUE, it will try to use the plugin or fail. To avoid
> breaking things for users with a plugin but scripts that might break, I set
> plugin=FALSE for now. Once we have some experience, I'll increment the
> version number from 0.5-* to 0.6-1, and set plugin=NULL by default.
>

I have partially reinstalled R here. Should I continue to use the CVS
version for this improvement? I feel that things won't be tested widely
unless the code isn't easily available (i.e. CRAN).

Best wishes
Markus
_______________________________________________
grass-stats mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-stats

[Roger Bivand]

I've submitted spgrass6_0.5-9.tar.gz to CRAN, so barring accidents it
should be out soon. If you're using the raster or vector plugins and have
comments, please let me know - look for the new plugin= argument, which is
FALSE by default to avoid problems, but can be NULL for autodetection, or
TRUE to force use if the plugin is known to be available.

Roger

On Sun, 22 Jun 2008, Markus Neteler wrote:

> Dear Roger,
>
> On Mon, Jun 2, 2008 at 10:03 AM, Roger Bivand <[hidden email]> wrote:
>> On Sun, 1 Jun 2008, Markus Neteler 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:
> ...
>>> thanks for the high speed rewrite of the interface. Downloaded and
>>> installed
>>> successfully (I see the new message
>>> "GRASS GIS interface loaded with GRASS version: 6.4.svn"
>>> ).
>>>
>>>> or a variant that works. The vector version looks OK,
>>>
>
>> Markus,
>>
>> For now, the plugin= argument defaults to FALSE. If NULL, it will
>> autodetect, if TRUE, it will try to use the plugin or fail. To avoid
>> breaking things for users with a plugin but scripts that might break, I set
>> plugin=FALSE for now. Once we have some experience, I'll increment the
>> version number from 0.5-* to 0.6-1, and set plugin=NULL by default.
>>
>
> I have partially reinstalled R here. Should I continue to use the CVS
> version for this improvement? I feel that things won't be tested widely
> unless the code isn't easily available (i.e. CRAN).
>
> Best wishes
> Markus
>

--
Roger Bivand
Economic Geography Section, Department of Economics, Norwegian School of
Economics and Business Administration, Helleveien 30, N-5045 Bergen,
Norway. voice: [phone]; fax [phone]
e-mail: [hidden email]

_______________________________________________
grass-stats mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-stats

[Roger Bivand]

On Mon, 23 Jun 2008, Roger Bivand wrote:

> I've submitted spgrass6_0.5-9.tar.gz to CRAN, so barring accidents it should
> be out soon. If you're using the raster or vector plugins and have comments,
> please let me know - look for the new plugin= argument, which is FALSE by
> default to avoid problems, but can be NULL for autodetection, or TRUE to
> force use if the plugin is known to be available.

My apologies, 0.5-9 was released on CRAN three weeks ago, so no change.

What I do need is advice on whether to leave plugin=FALSE, or to set
plugin=NULL for autodetect, and risk foobars from existing user code
assuming the current region rather than the raster region seen by the
plugin if installed and autodetected.

My preference remains for plugin=FALSE, that is, users have to change to
NULL or TRUE themselves, and accept the consequences of mixing up regions.

Is there a shell-level utility in GRASS to check whether the region of a
raster is equal to the current working region - the function could call
that and create a copy of the required raster in current resolution if
they differ?

Roger

>
> Roger
>
> On Sun, 22 Jun 2008, Markus Neteler wrote:
>
>>  Dear Roger,
>>
>>  On Mon, Jun 2, 2008 at 10:03 AM, Roger Bivand <[hidden email]> wrote:
>> >  On Sun, 1 Jun 2008, Markus Neteler 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:
>>  ...
>> > >  thanks for the high speed rewrite of the interface. Downloaded and
>> > >  installed
>> > >  successfully (I see the new message
>> > >  "GRASS GIS interface loaded with GRASS version: 6.4.svn"
>> > > ) .
>> > >
>> > > >  or a variant that works. The vector version looks OK,
>> > >
>>
>> >  Markus,
>> >
>> >  For now, the plugin= argument defaults to FALSE. If NULL, it will
>> >  autodetect, if TRUE, it will try to use the plugin or fail. To avoid
>> >  breaking things for users with a plugin but scripts that might break, I
>> >  set
>> >  plugin=FALSE for now. Once we have some experience, I'll increment the
>> >  version number from 0.5-* to 0.6-1, and set plugin=NULL by default.
>> >
>>
>>  I have partially reinstalled R here. Should I continue to use the CVS
>>  version for this improvement? I feel that things won't be tested widely
>>  unless the code isn't easily available (i.e. CRAN).
>>
>>  Best wishes
>>  Markus
>>
>
>

--
Roger Bivand
Economic Geography Section, Department of Economics, Norwegian School of
Economics and Business Administration, Helleveien 30, N-5045 Bergen,
Norway. voice: [phone]; fax [phone]
e-mail: [hidden email]

_______________________________________________
grass-stats mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-stats

[Markus Neteler]

On Tue, Jun 24, 2008 at 12:23 PM, Roger Bivand <[hidden email]> wrote:
> On Mon, 23 Jun 2008, Roger Bivand wrote:
>
>> I've submitted spgrass6_0.5-9.tar.gz to CRAN, so barring accidents it
>> should be out soon. If you're using the raster or vector plugins and have
>> comments, please let me know - look for the new plugin= argument, which is
>> FALSE by default to avoid problems, but can be NULL for autodetection, or
>> TRUE to force use if the plugin is known to be available.
>
> My apologies, 0.5-9 was released on CRAN three weeks ago, so no change.

Dear Roger,

not sure what that means: can you upload only periodically from time to time?

> What I do need is advice on whether to leave plugin=FALSE, or to set
> plugin=NULL for autodetect, and risk foobars from existing user code
> assuming the current region rather than the raster region seen by the plugin
> if installed and autodetected.

Let me suggest:
The raster plugin behavior will be a problem (we should really fix that in GDAL)
while the vector plugin behaves well.
How about having two parameters:

rasterplugin = FALSE
vectorplugin = NULL
?

> My preference remains for plugin=FALSE, that is, users have to change to
> NULL or TRUE themselves, and accept the consequences of mixing up regions.

Above might help.

> Is there a shell-level utility in GRASS to check whether the region of a
> raster is equal to the current working region - the function could call that
> and create a copy of the required raster in current resolution if they
> differ?

The easiest way it to compare the output of

r.info -g map127
north=230000
south=214000
east=646000
west=628000

and
g.region -g | grep '^n=\|^s=\|^e=\|^w='
n=228513
s=214975.5
w=629992.5
e=645012

Markus
_______________________________________________
grass-stats mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-stats

[Roger Bivand]

On Tue, 24 Jun 2008, Markus Neteler wrote:

> On Tue, Jun 24, 2008 at 12:23 PM, Roger Bivand <[hidden email]> wrote:
>> On Mon, 23 Jun 2008, Roger Bivand wrote:
>>
>>> I've submitted spgrass6_0.5-9.tar.gz to CRAN, so barring accidents it
>>> should be out soon. If you're using the raster or vector plugins and have
>>> comments, please let me know - look for the new plugin= argument, which is
>>> FALSE by default to avoid problems, but can be NULL for autodetection, or
>>> TRUE to force use if the plugin is known to be available.
>>
>> My apologies, 0.5-9 was released on CRAN three weeks ago, so no change.
>
> Dear Roger,
>
> not sure what that means: can you upload only periodically from time to
> time?

No, I just forgot that I had released the package with the changes, and
tried to release an identical package, but the CRAN administrator asked if
I was aware of this!

>
>> What I do need is advice on whether to leave plugin=FALSE, or to set
>> plugin=NULL for autodetect, and risk foobars from existing user code
>> assuming the current region rather than the raster region seen by the plugin
>> if installed and autodetected.
>
> Let me suggest:
> The raster plugin behavior will be a problem (we should really fix that in GDAL)
> while the vector plugin behaves well.
> How about having two parameters:
>
> rasterplugin = FALSE
> vectorplugin = NULL
> ?

OK, will do for next release.

>
>> My preference remains for plugin=FALSE, that is, users have to change to
>> NULL or TRUE themselves, and accept the consequences of mixing up regions.
>
> Above might help.
>
>> Is there a shell-level utility in GRASS to check whether the region of a
>> raster is equal to the current working region - the function could call that
>> and create a copy of the required raster in current resolution if they
>> differ?
>
> The easiest way it to compare the output of
>
> r.info -g map127
> north=230000
> south=214000
> east=646000
> west=628000
>
> and
> g.region -g | grep '^n=\|^s=\|^e=\|^w='
> n=228513
> s=214975.5
> w=629992.5
> e=645012

But the resolution may differ too - I need a one shot comparison. Isn't
anything exposed - I've looked in g.copy and r.resample without seeing
anything. Maybe:

r.info -gs elevation.dem
g.region -g | grep '^n=\|^s=\|^e=\|^w=\|^ewres=\|^nsres='

but an internal match (where r.resample would be a no-op or not) would be
helpful.

Roger

>
> Markus
> _______________________________________________
> grass-stats mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/grass-stats
>

--
Roger Bivand
Economic Geography Section, Department of Economics, Norwegian School of
Economics and Business Administration, Helleveien 30, N-5045 Bergen,
Norway. voice: [phone]; fax [phone]
e-mail: [hidden email]

_______________________________________________
grass-stats mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-stats

[hamish-2]

Roger:
> Is there a shell-level utility in GRASS to check whether
> the region of a raster is equal to the current working
> region - the function could call that and create a copy
> of the required raster in current resolution if they differ?

no, but:

g.region -g
r.info -g $MAPNAME

and compare.


see also WIND_OVERRIDE in the GRASS variables.html help page, and
today's i.fusion.brovey script in SVN.
It lets you change the region internal to your process/script.


Hamish



     

_______________________________________________
grass-stats mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-stats

[hamish-2]

Roger
> >> Is there a shell-level utility in GRASS to check
> >> whether the region of a
> >> raster is equal to the current working region -

[g.region -g, r.info -g]

> But the resolution may differ too - I need a one shot
> comparison.

oh, 'r.info -g' just shows bounds. Try 'r.info -s' to get resolution.

and 'g.region -g' for region res.


Hamish




     

_______________________________________________
grass-stats mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/grass-stats