Re: [GRASS-dev] [GRASS GIS] #2032: r.mapcalc does not always respect MASK

[Paulo van Breugel]

On Tue, Jul 16, 2013 at 8:26 PM, GRASS GIS  wrote:

> #2032: r.mapcalc does not always respect MASK
>
> -+--
>   Reporter:  pvanbosgeo  |   Owner:  grass-dev@…
>   Type:  defect  |  Status:  closed
>   Priority:  normal  |   Milestone:  7.0.0
>  Component:  Raster  | Version:  unspecified
> Resolution:  invalid |Keywords:  r.mapcalc
>   Platform:  Linux   | Cpu:  Unspecified
>
> -+--
>
> Comment(by glynn):
>
>  Replying to [comment:2 pvanbosgeo]:
>  > OK, thanks, I didn't know that / hadn't read that part of the manual
>  carefully enough. Perhaps not something that the user will encounter
>  often, but nonetheless, it is something I can see others might overlook as
>  well when using r.mapcalc. Perhaps a short note of this can be added to
>  the r.mapcalc help file (which is where I looked to see where my
>  expectations of the behavior of r.mapcalc were wrong)?
>
>  The behaviour isn't specific to r.mapcalc. Except for a few special cases,
>  the MASK behaviour isn't implemented by the individual modules, but by the
>  raster I/O library. You can observe the same behaviour with e.g.
>  r.neighbors.
>
  The correct place to document this behaviour is wherever the MASK
>  behaviour is described, e.g. the rasterintro manual page and the r.mask
>  manual page. FWIW, the first sentence of the DESCRIPTION section of the
>  r.mask manual page (after the summary) is:
>  {{{
>  The MASK is only applied when reading an existing GRASS raster map,
>  for example when used in a module as an input map.
>  }}}
>

Just to clarify, of course the behaviour should be mentioned in the
mentioned manual pages. I merely suggested to add a reminder for this part
of the behaviour of MASK in the help file of r.mapcalc.

The reason I think such a reminder might be helpful is that modules like
r.neighbors always require an existing map as input and therefore the MASK
will normally be respected. For most other modules there is no reading of
an input map and thus the MASK has normally not influence (e.g.,
r.surf.fractal). For r.mapcalc, both are possible.

BTW, is the mentioning in e.g., the help file of r.neighbor that it
respects existing MASK not just that; a (useful imho) reminder of the
default behaviour mentioned in the raster intro page, viz.
"Raster input maps are automatically masked if a raster map named MASK
exists."?

Anyway, just to clarify my initial suggestion. I probably will not forget
this behaviour anyway :-).


>
> --
> Ticket URL: 
> GRASS GIS 
>
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] mapset permissions: only owner should have write permissions

[Hamish]

Markus Metz wrote:

>  In this case, would it be ok to enforce umask to 0022 in the start up 
> script?

two rules to thumb:

we shouldn't restrict others to the limits of our own imagination.
 (if someone wants to set their umask to allow 777 for whatever reason
  or need, why not let them?)

it's not broken == don't fix it


... my suggestion is just leave the thing alone. why make work for people?


regards,
Hamish

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

Re: [GRASS-dev] GRASS GIS 7 tech-preview release preparations

[Michael Barton]

I will make one as soon as I get a chance. Crazy day so far.

Michael

C. Michael Barton
Director, Center for Social Dynamics & Complexity 
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University

voice:  480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax:  480-965-7671 (SHESC),  480-727-0709 (CSDC)
www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu












On Jul 14, 2013, at 2:05 AM, Markus Neteler 
 wrote:

> On Sun, Jul 14, 2013 at 1:32 AM, Michael Barton  
> wrote:
>> It's really a bite that I cannot a working Mac version of GRASS 7 without
>> some post-compilation hacking. While I can create a useable Mac binary with
>> some effort, it could be a problem for others who wish to do so.
>> 
>> Glynn suggests that this is a ctypes issue and Anna thinks it may be
>> something that has consequences for numerous modules (I'm inclined to
>> agree). But so far, we're stuck.
> 
> Michael,
> 
> please send the ticket number for this... (don't find it)
> 
> Markus

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

Re: [GRASS-dev] [GRASS GIS] #2033: Moving g.pnmcomp to lib/display to improve render performance of wxGUI

[GRASS GIS]

#2033: Moving g.pnmcomp to lib/display to improve render performance of wxGUI
--+-
 Reporter:  huhabla   |   Owner:  grass-dev@…   
   
 Type:  enhancement   |  Status:  new   
   
 Priority:  major |   Milestone:  7.0.0 
   
Component:  wxGUI | Version:  svn-trunk 
   
 Keywords:  display, Python, multiprocessing  |Platform:  All   
   
  Cpu:  All   |  
--+-

Comment(by glynn):

 Replying to [ticket:2033 huhabla]:

 > My question would be if this is also possible with d.rast, d.vect and
 other display modules? Hence, moving the code from these modules into the
 display library and calling these functions from dedicated wxGUI sub-
 processes to speed up the rendering?

 Possible? Probably. Sane? No.

 Moving the guts of d.rast/d.vect/etc around won't make it run any faster.
 If the issue is with the communication of the raster data, there are
 faster methods than reading and writing PNM files.

 Both the PNG and cairo drivers support reading and writing 32-bpp BMP
 files where the raster data is correctly aligned for memory mapping.
 Setting GRASS_PNGFILE to a filename with a .bmp suffix selects this
 format, and setting GRASS_PNG_MAPPED=TRUE causes the drivers to mmap() the
 file rather than using read() and write().

 Once you have d.* commands generating BMP files, it shouldn't be necessary
 to add any binary blobs to wxGUI. Compositing should be perfectly viable
 within Python using either numpy, PIL or wxPython (having wxPython perform
 the compositing during rendering may be able to take advantage of video
 hardware).

 Additionally, on X11 (and provided that the cairo library supports it),
 the cairo driver supports rendering directly into an X pixmap which is
 retained in the server (typically in video memory) after the d.* program
 terminates. This has the added advantage that rendering will be performed
 using the video hardware.

 Setting GRASS_PNGFILE to a filename ending in ".xid" selects this option;
 the XID of the pixmap will be written to that file as a hexadecimal value.
 The g.cairocomp module can composite these pixmaps without the image data
 ever leaving video memory ("g.cairocomp -d ..." can be used to delete the
 pixmaps from the server).

 The only missing piece of the puzzle is a way to get wxPython to use an
 existing pixmap (ideally without pulling it into client memory then
 pushing it back out to the server). The cleanest approach would be via
 pycairo and wx.lib.wxcairo, which would also allow g.cairocomp to be
 eliminated, but that's yet another dependency.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] mapset permissions: only owner should have write permissions

[Glynn Clements]

Markus Metz wrote:

> > The convention is that programs should allow the user to control read
> > and write permissions via the umask, while execute permission is
> > determined by the program.
> 
> In this case, would it be ok to enforce umask to 0022 in the start up script?

Not literally. Those two bits can be *added*, i.e. it can be increased
from e.g. 002 to 022, but if it starts out at e.g. 077, it shouldn't
be lowered to 022.

Changing the umask in the startup script is an improvement over
forcing the mode in the code, as the user can always just change it
back again.

> > Programs creating files containing particularly-sensitive information
> > (e.g. encryption keys) may reasonably impose more restrictive
> > permissions.
> 
> With grass data on a network drive with multi-user access, I would
> regard e.g. the contents of the PERMANENT mapset as
> particularly-sensitive information.

Plenty of sites will treat PERMANENT as public data, to be shared by
all users.

The cases where forced 0600 is reasonable are those where the data is
invariably private, i.e. passwords and encryption keys.

-- 
Glynn Clements 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2032: r.mapcalc does not always respect MASK

[GRASS GIS]

#2032: r.mapcalc does not always respect MASK
-+--
  Reporter:  pvanbosgeo  |   Owner:  grass-dev@…  
  Type:  defect  |  Status:  closed   
  Priority:  normal  |   Milestone:  7.0.0
 Component:  Raster  | Version:  unspecified  
Resolution:  invalid |Keywords:  r.mapcalc
  Platform:  Linux   | Cpu:  Unspecified  
-+--

Comment(by glynn):

 Replying to [comment:2 pvanbosgeo]:
 > OK, thanks, I didn't know that / hadn't read that part of the manual
 carefully enough. Perhaps not something that the user will encounter
 often, but nonetheless, it is something I can see others might overlook as
 well when using r.mapcalc. Perhaps a short note of this can be added to
 the r.mapcalc help file (which is where I looked to see where my
 expectations of the behavior of r.mapcalc were wrong)?

 The behaviour isn't specific to r.mapcalc. Except for a few special cases,
 the MASK behaviour isn't implemented by the individual modules, but by the
 raster I/O library. You can observe the same behaviour with e.g.
 r.neighbors.

 The correct place to document this behaviour is wherever the MASK
 behaviour is described, e.g. the rasterintro manual page and the r.mask
 manual page. FWIW, the first sentence of the DESCRIPTION section of the
 r.mask manual page (after the summary) is:
 {{{
 The MASK is only applied when reading an existing GRASS raster map,
 for example when used in a module as an input map.
 }}}

-- 
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] [GRASS GIS] #2033: Moving g.pnmcomp to lib/display to improve render performance of wxGUI

[GRASS GIS]

#2033: Moving g.pnmcomp to lib/display to improve render performance of wxGUI
--+-
 Reporter:  huhabla   |   Owner:  grass-dev@…   
   
 Type:  enhancement   |  Status:  new   
   
 Priority:  major |   Milestone:  7.0.0 
   
Component:  wxGUI | Version:  svn-trunk 
   
 Keywords:  display, Python, multiprocessing  |Platform:  All   
   
  Cpu:  All   |  
--+-
 I would like to move the code of g.pnmcomp into the display library. So we
 can call it directly as C-function in the wxGUI to avoid file IO and to
 speedup the rendering process.

 I will use the Python multiprocessing module to avoid the crash of the GUI
 in case of a segmentation fault or in case of an exit call when a fatal
 error occurs. Hence, to call the C-Library function via ctypes or PyGRASS,
 a new process will be spawned. All data will be exchanged using Python
 objects and multiprocessing queues between the wxGUI and its sub-process
 child's. This can also be used to run several processes in parallel as
 g.gui.animation already does.

 I have implemented a prototype that makes use of this concept. The code is
 attached as diff to the current grass7 svn-trunk version. The code can be
 seen as a proof of concept that shows how it might work. The code will
 also show that it is still possible to call g.pnmcomp as usual.

 This concept may also lead to a new implementation guideline: to use more
 C-Library functions in the wxGUI to speedup the visualization.

 My question would be if this is also possible with d.rast, d.vect and
 other display modules? Hence, moving the code from these modules into the
 display library and calling these functions from dedicated wxGUI sub-
 processes to speed up the rendering?

-- 
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] From the current GRASS GIS Community Sprint in Prague - 16th July

[Anne Ghisla]

Hello all from Prague!

The sprint is progressing well, with another productive day!
Special thanks to Martin and MarkusN for the smooth organisation :)

The full list of what we did can be found here:
http://grasswiki.osgeo.org/wiki/Talk:GRASS_Community_Sprint_Prague_2013

Since last report, these are new joint activities:
- Presentation on vector conflation - TF with discussion
- Discussion on GRASS Toolboxes customisation - AP, VP
- Discussion on new v.kriging module and v.nna - ES, MN, SG
- GRASS wiki image processing update - MM, MN, YC

.. and individual efforts:
- Draft Doxygen'iation of the CDHC library for testing normality &
exponentiality
- r.stream.* modules: clean up before moving from addons to trunk
- standardizing options for v.db.* and db.* modules, updating
respective manuals 
- Discussion and implementation of the new temporal module
t.rast.accumulate and the use of a modified version of r.gdd
(MM) instead of r.mapcalc
- Writing and updating of temporal modules documentation 
- Bundle Block Adjustment files with Yann
- Implementing functions for if-statements in the temporal algebra 
- GUI translation to Polish 
- experiment: compile wxPython with wxGTK3/Broadway (HTML5) backend,
see discussion 
- v.kriging development (new C module) and discussion on existing
implementations, testing
- vector conflation - module development

And thanks to our sponsors!
http://grasswiki.osgeo.org/wiki/GRASS_Community_Sprint_Prague_2013#Thanks_to_our_sponsors

(Hint: donations yet welcome: http://grass.osgeo.org/donations)

Best!
Anne (et al. from Prague)
-- 
http://wiki.osgeo.org/wiki/User:Aghisla


signature.asc
Description: PGP signature
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] v.kcv - new version

[Helmut Kudrnovsky]

>Dear developers,
>
>in connection with attempts to rewrite some GRASS module with OpenMP we
>have rewrote the v.kcv module. The new version is much faster that the
>previous (no OpenMP is now needed - there is only one loop now with
>direct writing to the resulting layer). We believe that the new version
>of the module do the same work as original. We are not familiar with
>GRASS GIS development so the code is included in the attachment of this
>message. Hope that it could be useful. 

could you open an enhancement ticket in the tracker
(http://trac.osgeo.org/grass/)?

so your work isn't getting lost in the mailing list.



-
best regards
Helmut
--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/v-kcv-new-version-tp5066726p5066792.html
Sent from the Grass - Dev mailing list archive at Nabble.com.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Direct link from GRASS to R via C

[Rainer M Krug]

Vaclav Petras  writes:

> On 16 July 2013 09:59, Rainer M Krug  wrote:
>>
>> Vaclav Petras  writes:
>>
>>> Hi,
>> Hi,
>>
>>>
>>> you probably know, I've once started the discussion on this topic on
>>> grass-stats ML (very simple test code included) [1]. And I've also
>>> tried some basic example and experienced some problems [2].
>>
>> To my shame, I must say I overlooked your threads. I am aware of the
>> problem which Roger discussed, therefore I think it would be the best to
>> write a function in GRASS which is exported and is doing the access and
>> simply returns the column / block / complete raster (i.e. a *very basic*
>> exported raster access api for grass).
>>
>> This function could be called then from Rcpp and it would be much easier
>> then writing the complete access function in Rcpp (as you mention below,
>> I also think that the header files locations might be a problem).
>>
>>
>>> To the
>>> information you provided I would add that the new functionality have
>>> to be written in C++ since Rcpp is only for C++.
>>
>> I am always confused by these two and how they are linked together - can
>> I use C libraries from Rcpp, as described above?
>>
> Yes you can, see my example. Generally, you can call C functions from
> C++ code and create C wrapper for your C++ library (you can find
> documentation everywhere, note especially the extern "C" declaration).

Thanks - I'll look into it.

>
>> As you already have done some work (could you please mail it to me as I
>> can't access the attachment via gmane?), I would very much appreciate
>> your input - also my C / C++ experience is quite limited and input from
>> that side would be brilliant.
>>
> I have only that small example (attached) but it contains all you
> need, however there were also some problems [2].

Thanks - that looks interesting (and easier then I thought, judging from
the r.example included in GRASS). I will look at it in detail and come
back to you if I have any questions.

Thanks,

Rainer

>
>> Thanks,
>>
>> Rainer
>>
>>>
>>> Vaclav
>>>
>>> [1] http://lists.osgeo.org/pipermail/grass-stats/2012-July/001422.html
>>> [2] 
>>> http://lists.r-forge.r-project.org/pipermail/rcpp-devel/2012-July/004055.html
>>>
>>>
>>> On 15 July 2013 17:30, Rainer M Krug  wrote:
 The following message is a courtesy copy of an article
 that has been posted to gmane.comp.gis.grass.devel as well.

 Hi

 I posted on my blog an outline of an idea of how spatial data could be
 easily loaded from GRASS into R and written back.

 (see http://rmkrug.wordpress.com/2013/07/15/grassrlink-1/)

 In a nutshell, the idea would be to use the C functions in GRASS to
 write a function which returns a single column, column range or whole
 raster. This function could then be called from R (via Rcpp) to get the
 data into R without having to worry about intermittent exports and
 imports via the hdd.

 I would ike to have some input from the GRASS developer community what
 they think about such a function. This function should be usable as
 "stand alone", and not requiring the opening and buffer allocations et
 al as in the r.example, but rather simply take the mapset, raster name,
 column(s) to read, if MASK should be respected, ... arguments.

 I was thinking that it would be useful to have such a function in GRASS,
 as the compilation together with GRASS, in the same line as a module,
 would be quite easy.

 Initially, I was thinking about read and write support for rasters,
 which then could be extended to vectors and 3d-rasters and possibly even
 the temporal data.

 Could you give feedback on what y9ou think about the idea, and how you
 think it could be realized (simplicity to install would be important).

 Cheers and thanks,

 Rainer

 --
 Rainer M. Krug

 email: RMKruggmailcom
 ___
 grass-dev mailing list
 grass-dev@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/grass-dev
>>
>>
>> --
>> Rainer M. Krug
>>
>> email: RMKruggmailcom
>>
>> ___
>> grass-dev mailing list
>> grass-dev@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/grass-dev
>
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
<#secure method=pgpmime mode=sign>

-- 
Rainer M. Krug

email: RMKruggmailcom
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Direct link from GRASS to R via C

[Vaclav Petras]

On 16 July 2013 09:59, Rainer M Krug  wrote:
>
> Vaclav Petras  writes:
>
>> Hi,
> Hi,
>
>>
>> you probably know, I've once started the discussion on this topic on
>> grass-stats ML (very simple test code included) [1]. And I've also
>> tried some basic example and experienced some problems [2].
>
> To my shame, I must say I overlooked your threads. I am aware of the
> problem which Roger discussed, therefore I think it would be the best to
> write a function in GRASS which is exported and is doing the access and
> simply returns the column / block / complete raster (i.e. a *very basic*
> exported raster access api for grass).
>
> This function could be called then from Rcpp and it would be much easier
> then writing the complete access function in Rcpp (as you mention below,
> I also think that the header files locations might be a problem).
>
>
>> To the
>> information you provided I would add that the new functionality have
>> to be written in C++ since Rcpp is only for C++.
>
> I am always confused by these two and how they are linked together - can
> I use C libraries from Rcpp, as described above?
>
Yes you can, see my example. Generally, you can call C functions from
C++ code and create C wrapper for your C++ library (you can find
documentation everywhere, note especially the extern "C" declaration).

> As you already have done some work (could you please mail it to me as I
> can't access the attachment via gmane?), I would very much appreciate
> your input - also my C / C++ experience is quite limited and input from
> that side would be brilliant.
>
I have only that small example (attached) but it contains all you
need, however there were also some problems [2].

> Thanks,
>
> Rainer
>
>>
>> Vaclav
>>
>> [1] http://lists.osgeo.org/pipermail/grass-stats/2012-July/001422.html
>> [2] 
>> http://lists.r-forge.r-project.org/pipermail/rcpp-devel/2012-July/004055.html
>>
>>
>> On 15 July 2013 17:30, Rainer M Krug  wrote:
>>> The following message is a courtesy copy of an article
>>> that has been posted to gmane.comp.gis.grass.devel as well.
>>>
>>> Hi
>>>
>>> I posted on my blog an outline of an idea of how spatial data could be
>>> easily loaded from GRASS into R and written back.
>>>
>>> (see http://rmkrug.wordpress.com/2013/07/15/grassrlink-1/)
>>>
>>> In a nutshell, the idea would be to use the C functions in GRASS to
>>> write a function which returns a single column, column range or whole
>>> raster. This function could then be called from R (via Rcpp) to get the
>>> data into R without having to worry about intermittent exports and
>>> imports via the hdd.
>>>
>>> I would ike to have some input from the GRASS developer community what
>>> they think about such a function. This function should be usable as
>>> "stand alone", and not requiring the opening and buffer allocations et
>>> al as in the r.example, but rather simply take the mapset, raster name,
>>> column(s) to read, if MASK should be respected, ... arguments.
>>>
>>> I was thinking that it would be useful to have such a function in GRASS,
>>> as the compilation together with GRASS, in the same line as a module,
>>> would be quite easy.
>>>
>>> Initially, I was thinking about read and write support for rasters,
>>> which then could be extended to vectors and 3d-rasters and possibly even
>>> the temporal data.
>>>
>>> Could you give feedback on what y9ou think about the idea, and how you
>>> think it could be realized (simplicity to install would be important).
>>>
>>> Cheers and thanks,
>>>
>>> Rainer
>>>
>>> --
>>> Rainer M. Krug
>>>
>>> email: RMKruggmailcom
>>> ___
>>> grass-dev mailing list
>>> grass-dev@lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/grass-dev
>
>
> --
> Rainer M. Krug
>
> email: RMKruggmailcom
>
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev


test_rgrass.R
Description: Binary data
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] i.segment: invalid region id 0

[Nikos Alexandris]

Moritz Lennert wrote:

> > [..]
> >>  > time i.segment -w group=pan_r_ir out=seg_weighted_pan_r_ir
> >> threshold=0.01 memory=8192
> >> Loading input bands...
> >> Pass 1:
> >> ERROR: Invalid region id 0
> > [..]
> >> What could be the problem ?

Nikos Alexandris:

> > the same error today while performing a "random" test. Disk capacity and
> > RAM plenty here.

> > time i.segment group=pan out=pan_segmented_plantations_area_threshold_1
> > threshold=0.99

Markus Metz:

> In most cases, this threshold is too large. It should be between 0 and
> 1, and rather close to zero.

Testing up to the limits here... :-)

> > Pass 13:
> > ERROR: Invalid region id 0

> > real40m44.339s
> > user37m34.357s
> > sys 0m0.380s

> > Details

> > projection: 1 (UTM)
> > zone:   38
> > datum:  wgs84
> > ellipsoid:  wgs84
> > north:  -2571782.5
> > south:  -2574924.5
> > west:   359153.5
> > east:   359525
> > nsres:  0.5
> > ewres:  0.5
> > rows:   6284
> > cols:   743
> > cells:  4669012

This region is used for all test I am doing (posted earlier).

> > Let me know how I can help.

> Can you make the dataset available (off-list if need be)? I can not
> reproduce this error with the datasets I have.

I think not -- will ask though.

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

Re: [GRASS-dev] [GRASS GIS] #1290: WinGrass: v.krige not working due to missing rpy2 pkg for MS Windows

[GRASS GIS]

#1290: WinGrass: v.krige not working due to missing rpy2 pkg for MS Windows
---+
 Reporter:  hellik |   Owner:  grass-dev@…  
 Type:  defect |  Status:  new  
 Priority:  major  |   Milestone:  6.5.0
Component:  Vector | Version:  svn-develbranch6 
 Keywords:  wingrass, v.krige  |Platform:  MSWindows Vista  
  Cpu:  x86-32 |  
---+

Comment(by aghisla):

 MarkusN suggested me to put a condition in the Makefile, like i.fft module
 does, and skip v.krige compilation if dependencies are missing.

 Actually the only dependency visible at compile time is python-rpy2, that
 I plan to remove. In order to fix the compilation error with present
 codebase, I'd appreciate suggestions on how to check this Python
 dependency in the Makefile.

 Would it make sense to make a new configuration parameter, like --with-R ?

 Ideas welcome!

 Many thanks,
 Anne

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] i.segment: invalid region id 0

[Nikos Alexandris]

[previous discussion(s) erased]

A series of tests completed successfully for thresholds 0.1, 0.3, 0.5, 0.7, 
0.9, no matter if memory= 300 or 3.  For the extreme case threshold=0.99, 
the process failed for both memory= 300 or 3 settings.

Note, all tests reported below were performed in a data base stored in an 
external USB 3.0 HDD.

# grass version
g.version -g

version=7.0.svn
date=2013
revision=57074
build_date=2013-06-12


First the two failure cases:

# threshold 0.99, memory=300 (default setting)
time i.segment group=pan out=pan_segmented_threshold_0.99_memory_300 
threshold=0.99

Loading input band...
Pass 1:
Pass 2:
Pass 3:
Pass 4:
Pass 5:
Pass 6:
Pass 7:
Pass 8:
Pass 9:
Pass 10:
Pass 11:
Pass 12:
Pass 13:
ERROR: Invalid region id 0

and

# threshold 0.99, memory=3  ---  This is what I have previously reported
time i.segment group=pan out=pan_segmented_threshold_0.99_memory_3
threshold=0.99 memory=3
Loading input band...
Pass 1:
Pass 2:
Pass 3:
Pass 4:
Pass 5:
Pass 6:
Pass 7:
Pass 8:
Pass 9:
Pass 10:
Pass 11:
Pass 12:
Pass 13:
ERROR: Invalid region id 0

real37m24.352s
user37m14.000s
sys 0m0.784s


# ###
# A series of tests using default RAM

# threshold 0.1
time i.segment group=pan out=pan_segmented_threshold_0.1_memory_300 
threshold=0.1

Loading input band...
Pass 1:
Pass 2:
Pass 3:
Pass 4:
Pass 5:
Pass 6:
Pass 7:
Pass 8:
Pass 9:
Pass 10:
Pass 11:
Segmentation converged after 11 iterations.
Writing out segment IDs
i.segment complete. Number of segments created: 25407

real8m9.122s
user8m5.582s
sys 0m0.296s

# threshold 0.3
time i.segment group=pan out=pan_segmented_threshold_0.3_memory_300 
threshold=0.3

Loading input band...
Pass 1:
Pass 2:
Pass 3:
Pass 4:
Pass 5:
Pass 6:
Pass 7:
Pass 8:
Pass 9:
Pass 10:
Pass 11:
Segmentation converged after 11 iterations.
Writing out segment IDs
i.segment complete. Number of segments created: 11684

real12m20.273s
user12m19.466s
sys 0m0.256s

# threshold 0.5
time i.segment group=pan out=pan_segmented_threshold_0.5_memory_300 
threshold=0.5

Loading input band...
Pass 1:
Pass 2:
Pass 3:
Pass 4:
Pass 5:
Pass 6:
Pass 7:
Pass 8:
Pass 9:
Pass 10:
Pass 11:
Pass 12:
Segmentation converged after 12 iterations.
Writing out segment IDs
i.segment complete. Number of segments created: 5495

real17m35.330s
user17m34.302s
sys 0m0.264s

# threshold 0.7
time i.segment group=pan out=pan_segmented_threshold_0.7_memory_300 
threshold=0.7

Loading input band...
Pass 1:
Pass 2:
Pass 3:
Pass 4:
Pass 5:
Pass 6:
Pass 7:
Pass 8:
Pass 9:
Pass 10:
Pass 11:
Pass 12:
Segmentation converged after 12 iterations.
Writing out segment IDs
i.segment complete. Number of segments created: 4911

real18m15.143s
user18m11.188s
sys 0m0.300s

# threshold 0.9
time i.segment group=pan out=pan_segmented_threshold_0.9_memory_300 
threshold=0.9

Loading input band...
Pass 1:
Pass 2:
Pass 3:
Pass 4:
Pass 5:
Pass 6:
Pass 7:
Pass 8:
Pass 9:
Pass 10:
Pass 11:
Pass 12:
Pass 13:
Segmentation converged after 13 iterations.
Writing out segment IDs
i.segment complete. Number of segments created: 1276

real30m30.619s
user30m29.010s
sys 0m0.272s


# 
# Tests using max. RAM

# threshold 0.1
time i.segment group=pan out=pan_segmented_threshold_01 threshold=0.1 
memory=3

Loading input band...   


Pass 1: 


Pass 2: 


Pass 3: 


Pass 4: 


Pass 5: 


Pass 6: 


Pass 7:  

[GRASS-dev] v.kcv - new version

[Jan Růžička]

Dear developers,

in connection with attempts to rewrite some GRASS module with OpenMP we 
have rewrote the v.kcv module. The new version is much faster that the 
previous (no OpenMP is now needed - there is only one loop now with 
direct writing to the resulting layer). We believe that the new version 
of the module do the same work as original. We are not familiar with 
GRASS GIS development so the code is included in the attachment of this 
message. Hope that it could be useful.


Kind regards

Jan Ruzicka and Jan Vandrol
/*
 * from s.kcv
 * Copyright (C) 1993-1994. James Darrell McCauley.
 *
 * Author: James Darrell McCauley darr...@mccauley-usa.com
 *http://mccauley-usa.com/
 *
 * This program is free software; you can redistribute it and/or
 * modify it under the terms of the GNU General Public License
 * as published by the Free Software Foundation; either version 2
 * of the License, or (at your option) any later version.
 *
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 * GNU General Public License for more details.
 *
 * You should have received a copy of the GNU General Public License
 * along with this program; if not, write to the Free Software
 * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
 *
 * Modification History:
 * 4.2B <27 Jan 1994>  fixed RAND_MAX for Solaris 2.3
 * <13 Sep 2000> released under GPL
 * 10/2004 Upgrade to 5.7 Radim Blazek
 * 5/2013 Change algorithm to make it faster by Jan Vandrol and Jan Ruzicka
 */
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include "kcv.h"

#ifndef RAND_MAX
#define RAND_MAX (pow(2.0,31.0)-1)
#endif
#if defined(__CYGWIN__) || defined(__APPLE__) || defined(__MINGW32__)
double drand48()
{
return (rand() / 32767.0);
}

#define srand48(sv) (srand((unsigned)(sv)))
#else
double drand48();
void srand48();
#endif

struct Cell_head window;

int rand_range(int min_n, int max_n)
{
return rand() % (max_n - min_n + 1) + min_n;
}

int main(int argc, char *argv[])
{

int line, nlines, nlinks;
double (*rng) (), max, myrand();
int nsites, verbose, parts, np, *p, dcmp();
int *pnt_part, *part_count, *part_available;
struct Map_info In, Out;
char *mapset;
struct GModule *module;
struct Option *in_opt, *out_opt, *col_opt, *npart_opt;
struct Flag *drand48_flag, *q_flag;

/* Attributes */
struct field_info *Fi;
dbDriver *Driver;
char buf[2000];
dbString sql;

module = G_define_module();
module->keywords = _("vector, statistics");
module->description =
	_("Randomly partition points into test/train sets.");

in_opt = G_define_standard_option(G_OPT_V_INPUT);
out_opt = G_define_standard_option(G_OPT_V_OUTPUT);

npart_opt = G_define_option();
npart_opt->key = "k";
npart_opt->type = TYPE_INTEGER;
npart_opt->required = YES;
npart_opt->description = _("Number of partitions");
npart_opt->options = "1-32767";

col_opt = G_define_option();
col_opt->key = "column";
col_opt->type = TYPE_STRING;
col_opt->required = YES;
col_opt->multiple = NO;
col_opt->answer = "part";
col_opt->description =
	_("Name for new column to which partition number is written");

drand48_flag = G_define_flag();
drand48_flag->key = 'd';
drand48_flag->description = _("Use drand48()");

/* please remove in GRASS 7 */
q_flag = G_define_flag();
q_flag->key = 'q';
q_flag->description = _("Quiet");

G_gisinit(argv[0]);

if (G_parser(argc, argv))
	exit(EXIT_FAILURE);

verbose = (!q_flag->answer);
np = atoi(npart_opt->answer);

if (drand48_flag->answer) {
	rng = drand48;
	max = 1.0;
	srand48((long)getpid());
}
else {
	rng = myrand;
	max = RAND_MAX;
	srand(getpid());
}



/* open input vector */
if ((mapset = G_find_vector2(in_opt->answer, "")) == NULL) {
	G_fatal_error(_("Vector map <%s> not found"), in_opt->answer);
}

Vect_set_open_level(2);
if (Vect_open_old(&In, in_opt->answer, mapset) < 2) {
	G_fatal_error(_("Unable to open vector map <%s> at topological level %d"),
		  in_opt->answer, 2);
}

nsites = Vect_get_num_primitives(&In, GV_POINT);

if (nsites < np) {
	G_fatal_error("Sites found: %i\nMore partitions than sites.", nsites);
}

Vect_set_fatal_error(GV_FATAL_PRINT);
Vect_open_new(&Out, out_opt->answer, Vect_is_3d(&In));

Vect_copy_head_data(&In, &Out);
Vect_hist_copy(&In, &Out);
Vect_hist_command(&Out);

/* Copy vector lines */
Vect_copy_map_lines(&In, &Out);

/* Copy tables */
if (Vect_copy_tables(&In, &Out, 0))
	G_warning(_("Failed to copy attribute table to output map"));

/* Add column */
db_init_string(&sql);

/* Check if there is a database for output */
nlinks = Vect_get_num_db

Re: [GRASS-dev] standardized options

[Markus Metz]

You could try G_OPT_M_DIR. The comment says "directory input" but it
should also work for output, all it should return is the path to a
folder.

Markus M


On Mon, Jul 15, 2013 at 5:42 PM, Margherita Di Leo
 wrote:
> Dear Devs,
>
> in r57084 Martin has added standardized options to r.ipso (thanks!). I would
> like to learn more about their use, particularly, does it exist a standard
> variable defined for taking a path as input? (Not a path+file name as
> G_OPT_F_INPUT). For example this is useful in the case that a module
> produces some pictures and/or csv files and the user wants to set a folder
> for storing them. I digged into [1] but I seem not to find what I need.
> Should I just take the path as a string? Giving to the user the possibility
> to browse the folders instead of indicating a path would be IMHO more
> convenient. Could anyone point me out where to read in order to learn more
> about that?
>
> Thanks!
> madi
>
> [1] http://grass.osgeo.org/programming7/gis_8h_source.html
>
> --
> Best regards,
>
> Dr. Margherita DI LEO
> Scientific / technical project officer
>
> European Commission - DG JRC
> Institute for Environment and Sustainability (IES)
> Via Fermi, 2749
> I-21027 Ispra (VA) - Italy - TP 261
>
> Tel. +39 0332 78 3600
> margherita.di-...@jrc.ec.europa.eu
>
> Disclaimer: The views expressed are purely those of the writer and may not
> in any circumstance be regarded as stating an official position of the
> European Commission.
>
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #1196: v.krige.py fails with ImportError: No module named vkrige

[GRASS GIS]

#1196: v.krige.py fails with ImportError: No module named vkrige
-+--
  Reporter:  marisn  |   Owner:  grass-dev@…  
  Type:  defect  |  Status:  reopened 
  Priority:  normal  |   Milestone:  6.5.0
 Component:  Python  | Version:  svn-develbranch6 
Resolution:  |Keywords:  v.krige  
  Platform:  Linux   | Cpu:  x86-64   
-+--

Comment(by aghisla):

 Probably fixed in trunk #57146 , but keeping this one open until backport
 to devbr6.

 Greetings from Prague,
 Anne

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS GIS] #1619: v.krige won't load: ImportError: No module named globalvar

[GRASS GIS]

#1619: v.krige won't load: ImportError: No module named globalvar
-+--
  Reporter:  momsen  |   Owner:  grass-dev@…  
  Type:  defect  |  Status:  closed   
  Priority:  normal  |   Milestone:  7.0.0
 Component:  Python  | Version:  svn-trunk
Resolution:  fixed   |Keywords:  v.krige  
  Platform:  Linux   | Cpu:  x86-64   
-+--
Changes (by aghisla):

  * status:  new => closed
  * resolution:  => fixed


Comment:

 Hello all from GRASS Community Sprint in Prague!

 v.krige is now fixed in trunk. I moved the global variables into
 Controller class, and store them as attributes.

 Testing is welcome!

 I close this ticket and welcome you to open new ones with a proper title -
 this one is getting a bit too crowded.

 Thanks!
 Anne

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] i.segment: invalid region id 0

[Markus Metz]

On Mon, Jul 15, 2013 at 11:09 PM, Nikos Alexandris
 wrote:
> Moritz Lennert wrote:
>
> [..]
>>  > time i.segment -w group=pan_r_ir out=seg_weighted_pan_r_ir
>>
>> threshold=0.01 memory=8192
>> Loading input bands...
>> Pass 1:
>> ERROR: Invalid region id 0
>
> [..]
>
>> What could be the problem ?
>
> Moritz, Markus,
>
> the same error today while performing a "random" test. Disk capacity and RAM
> plenty here.
>
> time i.segment group=pan out=pan_segmented_plantations_area_threshold_1
> threshold=0.99

In most cases, this threshold is too large. It should be between 0 and
1, and rather close to zero.

>
[...]
> Pass 13:
> ERROR: Invalid region id 0
>
> real40m44.339s
> user37m34.357s
> sys 0m0.380s
>
> Details
>
> projection: 1 (UTM)
> zone:   38
> datum:  wgs84
> ellipsoid:  wgs84
> north:  -2571782.5
> south:  -2574924.5
> west:   359153.5
> east:   359525
> nsres:  0.5
> ewres:  0.5
> rows:   6284
> cols:   743
> cells:  4669012
>
> Let me know how I can help.

Can you make the dataset available (off-list if need be)? I can not
reproduce this error with the datasets I have.

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

Re: [GRASS-dev] mapset permissions: only owner should have write permissions

[Markus Metz]

On Mon, Jul 15, 2013 at 5:55 PM, Glynn Clements
 wrote:
>
> Markus Metz wrote:
>
>> >From within GRASS, only the owner of a mapset is allowed to start a
>> GRASS session in this mapset, i.e. only the owner of a mapset has
>> write permissions to this mapset. But a new mapset being a folder in
>> the file system is created with mode 0777, thus granting write
>> permissions to all. I suggest to change mode from 0777 to 0755 in
>> G_mkdir() and add mode = 0755 in gis_set.py. Any objections?
>
> I don't see why GRASS should be special in this regard.
>
> The convention is that programs should allow the user to control read
> and write permissions via the umask, while execute permission is
> determined by the program.

In this case, would it be ok to enforce umask to 0022 in the start up script?

>
> Programs creating files containing particularly-sensitive information
> (e.g. encryption keys) may reasonably impose more restrictive
> permissions.

With grass data on a network drive with multi-user access, I would
regard e.g. the contents of the PERMANENT mapset as
particularly-sensitive information.

>
> GRASS already includes its own ownership check to prevent users from
> shooting each other in the foot with shared directories (by creating
> subdirectories which the owner cannot remove). So I don't really see
> any reason to enforce the policy a second time through filesystem
> permissions.

An inexperienced user trying to make a backup of a grass dataset,
syncing the wrong way...

Anyway, I withdraw my suggestion to use 0755 as default mode for
mkdir(path, mode). It's probably safer to enforce the system's default
mask directly.

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

Re: [GRASS-dev] Direct link from GRASS to R via C

[Rainer M Krug]

Vaclav Petras  writes:

> Hi,
Hi,

>
> you probably know, I've once started the discussion on this topic on
> grass-stats ML (very simple test code included) [1]. And I've also
> tried some basic example and experienced some problems [2]. 

To my shame, I must say I overlooked your threads. I am aware of the
problem which Roger discussed, therefore I think it would be the best to
write a function in GRASS which is exported and is doing the access and
simply returns the column / block / complete raster (i.e. a *very basic*
exported raster access api for grass). 

This function could be called then from Rcpp and it would be much easier
then writing the complete access function in Rcpp (as you mention below,
I also think that the header files locations might be a problem).


> To the
> information you provided I would add that the new functionality have
> to be written in C++ since Rcpp is only for C++.

I am always confused by these two and how they are linked together - can
I use C libraries from Rcpp, as described above?

As you already have done some work (could you please mail it to me as I
can't access the attachment via gmane?), I would very much appreciate
your input - also my C / C++ experience is quite limited and input from
that side would be brilliant.

Thanks,

Rainer

>
> Vaclav
>
> [1] http://lists.osgeo.org/pipermail/grass-stats/2012-July/001422.html
> [2] 
> http://lists.r-forge.r-project.org/pipermail/rcpp-devel/2012-July/004055.html
>
>
> On 15 July 2013 17:30, Rainer M Krug  wrote:
>> The following message is a courtesy copy of an article
>> that has been posted to gmane.comp.gis.grass.devel as well.
>>
>> Hi
>>
>> I posted on my blog an outline of an idea of how spatial data could be
>> easily loaded from GRASS into R and written back.
>>
>> (see http://rmkrug.wordpress.com/2013/07/15/grassrlink-1/)
>>
>> In a nutshell, the idea would be to use the C functions in GRASS to
>> write a function which returns a single column, column range or whole
>> raster. This function could then be called from R (via Rcpp) to get the
>> data into R without having to worry about intermittent exports and
>> imports via the hdd.
>>
>> I would ike to have some input from the GRASS developer community what
>> they think about such a function. This function should be usable as
>> "stand alone", and not requiring the opening and buffer allocations et
>> al as in the r.example, but rather simply take the mapset, raster name,
>> column(s) to read, if MASK should be respected, ... arguments.
>>
>> I was thinking that it would be useful to have such a function in GRASS,
>> as the compilation together with GRASS, in the same line as a module,
>> would be quite easy.
>>
>> Initially, I was thinking about read and write support for rasters,
>> which then could be extended to vectors and 3d-rasters and possibly even
>> the temporal data.
>>
>> Could you give feedback on what y9ou think about the idea, and how you
>> think it could be realized (simplicity to install would be important).
>>
>> Cheers and thanks,
>>
>> Rainer
>>
>> --
>> Rainer M. Krug
>>
>> email: RMKruggmailcom
>> ___
>> grass-dev mailing list
>> grass-dev@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/grass-dev


-- 
Rainer M. Krug

email: RMKruggmailcom


pgpHp4HZZHXMx.pgp
Description: PGP signature
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Direct link from GRASS to R via C

[Vaclav Petras]

Hi,

you probably know, I've once started the discussion on this topic on
grass-stats ML (very simple test code included) [1]. And I've also
tried some basic example and experienced some problems [2]. To the
information you provided I would add that the new functionality have
to be written in C++ since Rcpp is only for C++.

Vaclav

[1] http://lists.osgeo.org/pipermail/grass-stats/2012-July/001422.html
[2] 
http://lists.r-forge.r-project.org/pipermail/rcpp-devel/2012-July/004055.html


On 15 July 2013 17:30, Rainer M Krug  wrote:
> The following message is a courtesy copy of an article
> that has been posted to gmane.comp.gis.grass.devel as well.
>
> Hi
>
> I posted on my blog an outline of an idea of how spatial data could be
> easily loaded from GRASS into R and written back.
>
> (see http://rmkrug.wordpress.com/2013/07/15/grassrlink-1/)
>
> In a nutshell, the idea would be to use the C functions in GRASS to
> write a function which returns a single column, column range or whole
> raster. This function could then be called from R (via Rcpp) to get the
> data into R without having to worry about intermittent exports and
> imports via the hdd.
>
> I would ike to have some input from the GRASS developer community what
> they think about such a function. This function should be usable as
> "stand alone", and not requiring the opening and buffer allocations et
> al as in the r.example, but rather simply take the mapset, raster name,
> column(s) to read, if MASK should be respected, ... arguments.
>
> I was thinking that it would be useful to have such a function in GRASS,
> as the compilation together with GRASS, in the same line as a module,
> would be quite easy.
>
> Initially, I was thinking about read and write support for rasters,
> which then could be extended to vectors and 3d-rasters and possibly even
> the temporal data.
>
> Could you give feedback on what y9ou think about the idea, and how you
> think it could be realized (simplicity to install would be important).
>
> Cheers and thanks,
>
> Rainer
>
> --
> Rainer M. Krug
>
> email: RMKruggmailcom
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev