Re: [GRASS-dev] Making start of GRASS GIS easier for newcomers

[Paulo van Breugel]

On Fri, Jan 23, 2015 at 11:16 AM, Martin Landa landa.mar...@gmail.com
wrote:

 Hi,

 2015-01-23 9:20 GMT+01:00 Markus Neteler nete...@osgeo.org:
  my motivation to discuss the current welcome screen is that too many
  potential new users try to launch GRASS, do not get past that screen and
  walk away (too difficult). Yes, and they will likely not read the
 manual
  but just take another GIS.
  This is a multiple times reported fact.

 I have met a lot of GIS specialists who told me: I tried several times
 to use GRASS in different decades and I end up with the same result, I
 didn't managed to get my data in, so I gave up.

 It' a sign in my eyes that we should think how to simplify this step ;-)


That isn't a terribly good sign indeed... but, and I am asking, not trying
to counter your argument.. is this not often a result to stricter data
requirements of GRASS rather then difficulty of (start-up) menu's? I know
GRASS reasonably well, but still am sometimes struggling to import a data
layer that opens without problem in QGIS (using the right projection,
etc.). Anyway, that's another subject of course.



 Martin

 --
 Martin Landa
 http://geo.fsv.cvut.cz/gwiki/Landa
 http://gismentors.eu/mentors/landa
 ___
 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] Compute mahalanobis distance using Scipy

[Paulo van Breugel]

On Fri, Jan 30, 2015 at 3:39 PM, Glynn Clements gl...@gclements.plus.com
wrote:


 Paulo van Breugel wrote:

  I would like to compute a raster layer with for each raster cell the
  mahalanobis distance to the centre of the environmental space formed by
 all
  reference data points (raster cells). In R this can be done as explained
  here [1].
 
  . I would like to do this using python only (no dependency on R). I came
 up
  with the following, which works, but is very slow. I guess this is
 because
  it loops over every raster cell to compute the mahalanobis distance? Any
  idea how this can be done faster (I am very new to python, so bear with
 me
  if I am making stupid mistakes)

 The main speed-up will come from inlining distance.mahalanobis(),
 which is essentially:

 delta = u - v
 m = np.dot(np.dot(delta, VI), delta)
 return np.sqrt(m)

 np.dot(v, m) is equivalent to np.sum(v * m,axis=0), and np.dot(u,v) is
 equivalent to np.sum(u * v), so the second line above is equivalent to

 m = np.sum(np.sum(delta[:,None] * VI * delta[None,:], axis=-1),
 axis=-1)



Smart! I can follow the logic, but I am not sure how to solve the problem
below:

   Traceback (most recent call last):
File stdin, line 1, in module
ValueError: operands could not be broadcast together with shapes
(3,1,77,78) (3,3)

Which refers to the different dimensions of delta and VI?


 Thus, delta can be extended from a 1-D array to 3-D, changing the
 result from a scalar to a 2-D array. The calculation of stat_mah then
 becomes:

 VI = np.linalg.inv(covar)
 delta = dat_ref - stat_mean[:,None,None]
 m = np.sum(np.sum(delta[:,:,:,None] * delta[:,:,None,:] *
 VI[None,None,:,:],axis=-1),axis=-1)
 stat_mah = np.sqrt(m)

 This moves the loops from Python into C, which usually results in a
 significant speed increase.


 --
 Glynn Clements gl...@gclements.plus.com

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

Re: [GRASS-dev] compile gdal with grass

[Paulo van Breugel]

Great, thanks, I'll try it out a.s.a.p.

On Mon, Jan 5, 2015 at 3:50 PM, Martin Landa landa.mar...@gmail.com wrote:

 Hi,

 2015-01-05 15:32 GMT+01:00 Markus Neteler nete...@osgeo.org:
  On Mon, Jan 5, 2015 at 12:56 PM, Martin Landa landa.mar...@gmail.com
 wrote:
  ...
  these errors are related to the recent API changes in GRASS 7. I fixed
  that in gdal trunk [1] and later will do backport it to gdal 1.11
  branch.

 done in r28291. To compile GDAL against GRASS you need at least GDAL
 1.11 from svn branch [1].

 Martin

 [1] http://svn.osgeo.org/gdal/branches/1.11/

 --
 Martin Landa
 http://geo.fsv.cvut.cz/gwiki/Landa
 http://gismentors.eu/mentors/landa

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

[GRASS-dev] remove layer fails because of MASK reclass (but MASK has been removed already)

[Paulo van Breugel]

Hi, I can't remove a raster which previously was used to create a MASK
(which was subsequently removed) without forcing it using the b-flag in
g.remove. Steps:

1) create a MASK based on layer A.
2) remove the mask with r.mask -r.
3) remove layer A with g.remove: this gives the error:

WARNING: Raster map A is a base map. Remove reclassed map MASK@env first.

Going through the database folders I noticed that in the
GRASSdb/location/mapset/cell_misc/A folder there is the file 'reclassed_to'
which contains the pointer to the MASK. Removing this file solves the
problem.

So I guess when removing the mask this file should be removed too.

I am running GRASS 7 trunk on Ubuntu 14.04
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] installing metadata addon fails

[Paulo van Breugel]

Installation went fine.. but in g.gui.metadata when trying to edit /create
metadata for a layer, I get the following error (not sure if this is the
same as the one you report)

GRASS 7.1.svn (LatLongTest):~  g.gui.metadata
Traceback (most recent call last):
  File /home/paulo/.grass7/addons/scripts/g.gui.metadata, line 1031, in
onEdit
ok = self.GetParent().onEditMapMetadata()
  File /home/paulo/.grass7/addons/scripts/g.gui.metadata, line 257, in
onEditMapMetadata
self.mdCreator.createGrassBasicISO()
  File /home/paulo/.grass7/addons/etc/mdlib/mdgrass.py, line 186, in
createGrassBasicISO
self.md.identification.title =
mdutil.replaceXMLReservedChar(self.md_grass['title'])
KeyError: 'title'


On Thu, Jan 8, 2015 at 6:44 PM, Martin Landa landa.mar...@gmail.com wrote:

 Hi,

 2015-01-08 16:37 GMT+01:00 Paulo van Breugel p.vanbreu...@gmail.com:
  The installation of the metadata addon on GRASS 7 (trunk) fails, with the
  message below. Any ideas?

 I have fixed installation in r63999-64001. But `r.info.iso` fails

 r.info.iso dmt
 WARNING: date of creation: unknown date format
 Traceback (most recent call last):
   File /home/martin/.grass7/addons/scripts/r.info.iso, line 83, in
 module
 main()
   File /home/martin/.grass7/addons/scripts/r.info.iso, line 75, in main
 overwrite=os.getenv('GRASS_OVERWRITE', False))
   File /home/martin/.grass7/addons/etc/mdlib/mdgrass.py, line 346, in
 saveXML
 template = env.get_template(self.template)
   File
 /usr/local/lib/python2.7/dist-packages/Jinja2-2.8_devdev_20140629-py2.7.egg/jinja2/environment.py,
 line 801, in get_template
 return self._load_template(name, self.make_globals(globals))
   File
 /usr/local/lib/python2.7/dist-packages/Jinja2-2.8_devdev_20140629-py2.7.egg/jinja2/environment.py,
 line 763, in _load_template
 cache_key = self.loader.get_source(self, name)[1]
   File
 /usr/local/lib/python2.7/dist-packages/Jinja2-2.8_devdev_20140629-py2.7.egg/jinja2/loaders.py,
 line 187, in get_source
 raise TemplateNotFound(template)
 jinja2.exceptions.TemplateNotFound:
 /home/martin/.grass7/addons/etc/templates/basicTemplate.xml

 The mystery is that the file
 (/home/martin/.grass7/addons/etc/templates/basicTemplate.xml) exists:

 $ file /home/martin/.grass7/addons/etc/templates/basicTemplate.xml
 /home/martin/.grass7/addons/etc/templates/basicTemplate.xml: XML document
 text

 I hope that the original author (Matej in cc) will know more. Martin

 --
 Martin Landa
 http://geo.fsv.cvut.cz/gwiki/Landa
 http://gismentors.eu/mentors/landa

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

Re: [GRASS-dev] module header definitions add: text/multiline and latex support?

[Paulo van Breugel]

+1 for adding description option

On Wed, Jan 14, 2015 at 9:42 AM, Pietro peter.z...@gmail.com wrote:

 Dear devs,

 sometimes I would like to add some multiline text on the module GUI to
 help to understand the meaning of the parameter, and/or understand the
 logic of the module.

 Do you think that would be possible to have a description option that
 it does not take any input but allow us to be more descriptive inside
 the module interface?

 for instance if I have two mutual exclusive options like:

 {{{
 #%module
 #%  description: test script
 #%end
 ...
 #%option
 #% key: raster
 #% type: string
 #% gisprompt: old,cell,raster
 #% description: Raster input map:
 #% required : no
 #%end
 #%option
 #% type: description
 #% answer: OR
 #%end
 #%option
 #% key: vector
 #% type: string
 #% gisprompt: old,vector,vector
 #% description: Vector input map
 #% required : no
 #%end
 }}}

 So in the gui of the module I will have:

 Raster input map:
 - raster menu

 OR

 Vector input map:
 - vector menu

 or add a relation, to do something like:

 {{{
 #%module
 #%  description: test script
 #%end
 ...
 #%option
 #% key: raster
 #% type: string
 #% gisprompt: old,cell,raster
 #% description: Raster input map:
 #% required : yes
 #%end
 #%option
 #% key: vector
 #% type: string
 #% gisprompt: old,vector,vector
 #% description: Vector input map
 #% required : yes
 #%end
 #%keyrelation: raster OR vector
 }}}

 Is it this possible already? If yes how? Do you have some links?

 Do you think that would be feasible add also a LaTex option?
 To do something like:

 {{{
 #%module
 #%  description: test script
 #%end
 ...
 #%option
 #% guisection: Costs
 #% type: description
 #% answer: This option is used to compute the total
 #% cost of  using this formula:
 #%end
 #%option
 #%option
 #% guisection: Costs
 #% type: latex
 #% answer: \rho = \frac{\gamma}{\pi}
 #%end
 #%option
 #% guisection: Costs
 #% key: gamma
 #% type: double
 #% description: $\gamma$ value
 #% required : no
 #% answer: 12.45
 #%end
 #%option
 #% guisection: Costs
 #% key: currency
 #% type: string
 #% description: the currency
 #% required : no
 #% answer: €
 #%end
 }}}

 In this way the GUI could be more descriptive and clearer.

 I have not idea if this could be feasible or not... What do you think?

 Best regards

 Pietro
 ___
 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] Compute mahalanobis distance using Scipy

[Paulo van Breugel]

On Sat, Feb 14, 2015 at 4:38 AM, Glynn Clements gl...@gclements.plus.com
wrote:


 Paulo van Breugel wrote:

   With memmap you still have a limits of 2Gb I guess, you should try:
 dask
  
  
  Just reading the memmap manual page, where it reads: Memory-mapped
 arrays
  use the Python memory-map object which (prior to Python 2.5) does not
 allow
  files to be larger than a certain size depending on the platform. This
 size
  is always  2GB even on 64-bit systems.. Which is unclear to me; I am
 not
  sure if that means that this limit is different or does not apply when on
  Python 2.5 or newer (what is the minimum python version for GRASS?)

 Even if Python itself no longer imposes a 2 GiB limit, you would
 probably need to be using a 64-bit platform, the system would need
 enough memory for the operation, and it would need to allow the
 process to use that much memory.

 The problem here is that

 mahdist = np.sum(np.sum(delta[None,:,:,:] * VI[:,:,None,None],axis=1) *
 delta,axis=0)

 expands both delta and VI to 4-D arrays then calculates their product
 element-wise, then sums them over two axes. The intermediate array of
 products could potentially be very large.

 It may be possible to avoid this issue using numpy.tensordot, e.g.

 mahdist = np.sum(np.tensordot(VI, delta, (1,0)) * delta,axis=0)

 I don't know for sure whether this actually uses less memory. It could
 do, as it rearranges the matrices so that the sum-of-products is
 calculated using np.dot, which is a built-in function.


I did some quick testing, it seems to use slightly less memory. The dask
solution seems promising, with the disadvantage that it is not widely
available / still experimental according to the website.

For a quick solution, what about using r.tile to split the input data in
tiles and compute the mahalanobis distance per tile. Or would that come
with too much overhead or other clear disadvantages?


 --
 Glynn Clements gl...@gclements.plus.com

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

Re: [GRASS-dev] Compute mahalanobis distance using Scipy

[Paulo van Breugel]

Hi Javier,

This looks really useful, thanks! My python skills are very limited, so I
will have to look at it better to see what I can understand. But to start,
the parallel function, does that also solve the handling of potentially
very large raster layers?

Btw, this does look like a very useful set of functions, any plan to
develop this into a GRASS addon or function?

Paulo


On Sun, Feb 15, 2015 at 9:22 PM, Javier Martínez-López 
javi.martinez.lo...@gmail.com wrote:

 Hi Paulo,

 you can see an implementation of the mahalanobis distance computed in
 parallel (using all computer processors) for a single image here:

 https://github.com/javimarlop/eHabpy/blob/master/ehab.py

 see lines 32-86 and 597. I hope it helps! Cheers, Javier

 On Sat, Feb 14, 2015 at 7:29 PM, Vaclav Petras wenzesl...@gmail.com
 wrote:
 
  On Sat, Feb 14, 2015 at 11:47 AM, Paulo van Breugel 
 p.vanbreu...@gmail.com
  wrote:
 
 
  For a quick solution, what about using r.tile to split the input data in
  tiles and compute the mahalanobis distance per tile.
 
 
  See PyGRASS GridModule class which will do tiling (and a lot of other
  things) for you.
 
 
 http://grass.osgeo.org/grass70/manuals/libpython/pygrass.modules.grid.html
 
  ___
  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] Compute mahalanobis distance using Scipy

[Paulo van Breugel]

Hi Javier,

Thanks. I need to test whether the mahalanobis function you provided is
faster than the one I used (which Glynn wrote, based on the numpy function
I believe); I think I can use both together with the function to run it in
parallel, so it would be a matter of selecting the fastest one (or the one
using less memory, if there is such a difference).

I am not sure if I understand the parallel part, but it seems the data is
'sliced' in subsets to compute the distance. If so, that should indeed
solve the problem with large files? Anyway, I'll try how it works for me.

For now I do the partitioning of the data in subsets in GRASS (create a
dummy layer, split that in tiles using r.tile, set the region to match tile
1, import the input layers in python (which will be restricted to the
region defined by tile 1), run the function and import the result back in
GRASS, set region to match tile 2, impor the data... etc). Much slower I
guess (not really tested yet), but should be able to handle any data size
that GRASS can handle.

To create a grass plugin to compute the mahalanobis distance based on that
code would be trivial I think, I can give that a try if you want. As for
the rest of the code, I would be interested to help, but my grass/python
programming are very limited, so hopefully there are others interested as
well.

Cheers,

Paulo



On Mon, Feb 16, 2015 at 11:35 AM, Javier Martínez-López 
javi.martinez.lo...@gmail.com wrote:

 Hi Paulo,

 to use it with python just copy the mahalanobis function definitions,
 import all necessary libraries and use it as in line 597 (the
 covariance matrix and the mean are computed just before this line). I
 am sorry that the code is not documented yet. I am not sure if this
 will solve the large raster layers problem but you can try it. As you
 can see in the script, I did not write the parallel mahalanobis
 functions (Sturla Molden in CC did it) and it works perfectly for me,
 so I agree that it would be great to implement it also in GRASS (maybe
 as an add on?). However, I am not so experienced with that. The
 ehab.py script also does a lot data preprocessing to allow batch runs
 using heterogeneous data sources and finally performs some patch
 analysis and metrics out of the resulting similarity maps using the
 ndimage library (scipy). Any help on how to implement it in GRASS
 would be more than welcome! Cheers, Javier

 On Sun, Feb 15, 2015 at 10:21 PM, Paulo van Breugel
 p.vanbreu...@gmail.com wrote:
  Hi Javier,
 
  This looks really useful, thanks! My python skills are very limited, so I
  will have to look at it better to see what I can understand. But to
 start,
  the parallel function, does that also solve the handling of potentially
 very
  large raster layers?
 
  Btw, this does look like a very useful set of functions, any plan to
 develop
  this into a GRASS addon or function?
 
  Paulo
 
 
  On Sun, Feb 15, 2015 at 9:22 PM, Javier Martínez-López
  javi.martinez.lo...@gmail.com wrote:
 
  Hi Paulo,
 
  you can see an implementation of the mahalanobis distance computed in
  parallel (using all computer processors) for a single image here:
 
  https://github.com/javimarlop/eHabpy/blob/master/ehab.py
 
  see lines 32-86 and 597. I hope it helps! Cheers, Javier
 
  On Sat, Feb 14, 2015 at 7:29 PM, Vaclav Petras wenzesl...@gmail.com
  wrote:
  
   On Sat, Feb 14, 2015 at 11:47 AM, Paulo van Breugel
   p.vanbreu...@gmail.com
   wrote:
  
  
   For a quick solution, what about using r.tile to split the input data
   in
   tiles and compute the mahalanobis distance per tile.
  
  
   See PyGRASS GridModule class which will do tiling (and a lot of other
   things) for you.
  
  
  
 http://grass.osgeo.org/grass70/manuals/libpython/pygrass.modules.grid.html
  
   ___
   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

[GRASS-dev] compile gdal with grass

[Paulo van Breugel]

Just compiled the latest gdal (1.11) and grass (trunk - rev 63950) and now
want to compile gdal again with grass support. However, I am getting an
error, which appears to be a problem in gdal/frmts/grass (see below). Any
idea how to solve this?


paulo@paulo-HP-Z600-Workstation:~/Software/spatial/gdal/frmts/grass$ make
/bin/bash /home/paulo/Software/spatial/gdal/libtool --mode=compile
--tag=CXX g++ -g -O2 -DHAVE_SSE_AT_COMPILE_TIME  -Wall
-DGRASS_GISBASE=\/usr/local/grass7/grass-7.1.svn\
-I/usr/local/grass7/grass-7.1.svn/include
-I/home/paulo/Software/spatial/gdal/port
-I/home/paulo/Software/spatial/gdal/gcore
-I/home/paulo/Software/spatial/gdal/alg
-I/home/paulo/Software/spatial/gdal/ogr
-I/home/paulo/Software/spatial/gdal/ogr/ogrsf_frmts -DOGR_ENABLED
-I/home/paulo/Software/spatial/gdal/port  -c -o grass57dataset.lo
grass57dataset.cpp
libtool: compile:  g++ -g -O2 -DHAVE_SSE_AT_COMPILE_TIME -Wall
-DGRASS_GISBASE=\/usr/local/grass7/grass-7.1.svn\
-I/usr/local/grass7/grass-7.1.svn/include
-I/home/paulo/Software/spatial/gdal/port
-I/home/paulo/Software/spatial/gdal/gcore
-I/home/paulo/Software/spatial/gdal/alg
-I/home/paulo/Software/spatial/gdal/ogr
-I/home/paulo/Software/spatial/gdal/ogr/ogrsf_frmts -DOGR_ENABLED
-I/home/paulo/Software/spatial/gdal/port -c grass57dataset.cpp  -fPIC -DPIC
-o .libs/grass57dataset.o
grass57dataset.cpp: In member function 'CPLErr
GRASSRasterBand::ResetReading(Cell_head*)':
grass57dataset.cpp:440:61: error: 'G__setenv' was not declared in this scope
  G__setenv( GISDBASE, ((GRASSDataset *)poDS)-pszGisdbase );
 ^
grass57dataset.cpp: In static member function 'static GDALDataset*
GRASSDataset::Open(GDALOpenInfo*)':
grass57dataset.cpp:899:37: error: 'G__setenv' was not declared in this scope
 G__setenv( GISDBASE, pszGisdb );
 ^
make: *** [grass57dataset.lo] Error 1
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] compile gdal with grass

[Paulo van Breugel]

On Sun, Jan 4, 2015 at 10:30 PM, Markus Neteler nete...@osgeo.org wrote:

 On Sun, Jan 4, 2015 at 3:48 PM, Paulo van Breugel
 p.vanbreu...@gmail.com wrote:
  Just compiled the latest gdal (1.11) and grass (trunk - rev 63950) and
 now
  want to compile gdal again with grass support.

 It is recommended to compile the plugin (way easier than dealing with
 circular dependencies):
 http://grasswiki.osgeo.org/wiki/Compile_and_install_GDAL-GRASS_plugin


Compiling gdal with grass support takes more time but isn't terribly
difficult. If it works, which it did for the last half a year or so (during
which I updated grass various times, each time also recompiling gdal). But
yes, I would rather use the plugin as that is quicker. However, with grass7
I have never got it to work. The problem is that I don't really understand
how to use the various patches and suggestions in above-mentioned ticket.
Perhaps somebody could summarize how to do this in the wiki?


  However, I am getting an
  error, which appears to be a problem in gdal/frmts/grass (see below). Any
  idea how to solve this?

 Convince the GDAL developers to take care of
 http://trac.osgeo.org/gdal/ticket/2953

 I would try if I knew how. To file a bug report I would need to understand
what the issue is, which I don't really get from the ticket mentioned above


 Markus

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

[GRASS-dev] installing metadata addon fails

[Paulo van Breugel]

The installation of the metadata addon on GRASS 7 (trunk) fails, with the
message below. Any ideas?

Fetching wx.metadata from GRASS-Addons SVN repository (be patient)...
Compiling...
Makefile:19: warning: overriding commands for target
`/tmp/tmpF3gAGc/wx.metadata/etc'
/usr/local/grass7/grass-7.1.svn/include/Make/Rules.make:16:
warning: ignoring old commands for target
`/tmp/tmpF3gAGc/wx.metadata/etc'
Makefile:18: warning: overriding commands for target
`/tmp/tmpF3gAGc/wx.metadata/etc'
/usr/local/grass7/grass-7.1.svn/include/Make/Rules.make:16:
warning: ignoring old commands for target
`/tmp/tmpF3gAGc/wx.metadata/etc'
Traceback (most recent call last):
  File /tmp/tmpF3gAGc/wx.metadata/scripts/g.gui.metadata,
line 46, in module
import mdgrass
ImportError: No module named mdgrass
make[2]: *** [g.gui.metadata.tmp.html] Error 1
Installing...
Makefile:19: warning: overriding commands for target
`/tmp/tmpF3gAGc/wx.metadata/etc'
/usr/local/grass7/grass-7.1.svn/include/Make/Rules.make:16:
warning: ignoring old commands for target
`/tmp/tmpF3gAGc/wx.metadata/etc'
Makefile:18: warning: overriding commands for target
`/tmp/tmpF3gAGc/wx.metadata/etc'
/usr/local/grass7/grass-7.1.svn/include/Make/Rules.make:16:
warning: ignoring old commands for target
`/tmp/tmpF3gAGc/wx.metadata/etc'
/usr/bin/install: cannot stat ‘/tmp/tmpF3gAGc/wx.metadata/
docs/html/g.gui.metadata.html’: No such file or directory
make[1]: *** [install] Error 1
make: *** [install] Error 2
WARNING: Installation failed, sorry. Please check above error messages.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] point cloud analysis: new features

[Paulo van Breugel]

On Mon, Jan 5, 2015 at 12:17 PM, Benjamin Ducke bendu...@fastmail.fm
wrote:

 On 04/01/15 23:00, Paulo van Breugel wrote:
  Tried it out, and it works like a charm, great!
 
  One question/request, would it be terribly difficult to add an option to
  compute an user-defined number of clusters of equal size?
 

 I think you are looking for a completely different algorithm
 there. There are many clustering methods that will produce
 exactly k clusters. But what do you mean by size: number of
 points per cluster or spatial extent/area?


Yes, I was looking at something similar to what the function stratify in
the R spcosa package does: Methods for partitioning a spatial object into
compact strata by means of k-means. The objective function to minimize is
the mean squared shortest distance (MSSD). Optionally, the strata may be
forced to be of equal size. This facilitates field work in case of
stratified simple random sampling for composites. The key here is to
create as compact strata as possible, optionally of equal size (number of
points per cluster).



 In both cases, I am not sure how you would reconcile the
 two opposing goals: (A) find the actual cluster shapes,
 (B) make the cluster shapes so that all clusters are of
 equal size.

 (please see also my comment to Markus below).

 
 
  On Sun, Jan 4, 2015 at 9:02 PM, Markus Metz
  markus.metz.gisw...@gmail.com mailto:markus.metz.gisw...@gmail.com
  wrote:
 
 
  Done in trunk r63952 as v.cluster. It is not a GRASS7 addon because
 it
  does not work with G7.0. At the moment it only identifies and labels
  clusters. Connectivity graphs and cluster shapes are not implemented.
  In future, I would like to add OPTICS because OPTICS can better
 handle
  different clusters with different densities.
 

 Thanks Markus, this is excellent progress.
 It seems to me that the approximation of cluster shapes from grouped
 points is a generic problem that would best be solved with a separate
 module. As long as the shapes are roughly convex, the existing v.hull
 should work fine. For concave shapes, AFAIK things become messy because
 common methods such as alpha shapes require the user to provide
 threshold values.

 Cheers,

 Ben

  Markus M
 
  
   There is a reference implementation (albeit in Java) that you can
   use to compare it with other clustering algorithms:
  
 http://elki.dbs.ifi.lmu.de/
  
   An implementation in C (that I have not tried) is here:
  
 https://github.com/siddharth950/DBSCAN
  
   The one drawback of DBSCAN is that it needs an efficient spatial
   index to perform well -- and you have just taken care of that!
  
   - point cloud thinning: a sample can be generated from a large
 point
   cloud by specifying a minimum distance between sample points. To
 be
   implemented.
  
   The new k-d tree is now used by v.clean tool=snap
  (Vect_snap_lines()),
   reducing both memory consumption and processing time.
  
  
   I would also like to point out that SAGA GIS is moving into
   the same direction, i.e. more efficient processing of very
   large point clouds. The latest release includes a number
   of new point cloud tools. Perhaps it's worth a look.
  
   Most importantly, SAGA GIS has introduced a new file format,
   the SAGA Pointcloud (.spc) format. It is compact and yet
   flexible enough for a variety of purposes. I recommend to
   consider implementing import/export of this format in GRASS 7,
   preferably not via v.in.ogr, to avoid the OGR model conversion
   overhead.
  
   If you think this would be an interesting option, then you can
   find a summary on our tracker:
  
 http://gvsigce.sourceforge.net/mantis/view.php?id=595
  
   (we are going to implement .spc in gvSIG CE, as well).
  
   Best wishes,
  
   Ben
  
  
   More technical:
   the new k-d tree finds the exact nearest neighbor(s), not some
   approximation. It supports up to 255 dimensions. It is dynamic,
 i.e.
   points can be inserted and removed at any time. It is balanced to
   improve search performance. It provides k nearest neighbor search
   (find k neighbors to a given coordinate) as well as radius or
  distance
   search (find all neighbors within radius, i.e. not farther away
 than
   radius to a given coordinate).
  
   Markus M
   ___
   grass-dev mailing list
   grass-dev@lists.osgeo.org mailto:grass-dev@lists.osgeo.org
   http://lists.osgeo.org/mailman/listinfo/grass-dev
  
  
  
  
   --
   Dr. Benjamin Ducke
   {*} Geospatial Consultant
   {*} GIS Developer
  
   Spatial technology for the masses, not the classes:
   experience free and open source GIS at http://gvsigce.org

Re: [GRASS-dev] compile gdal with grass

[Paulo van Breugel]

Hi Martin, just recompiled GDAL against GRASS, and I can confirm it works.
Thanks for the fix!


On Mon, Jan 5, 2015 at 3:50 PM, Martin Landa landa.mar...@gmail.com wrote:

 Hi,

 2015-01-05 15:32 GMT+01:00 Markus Neteler nete...@osgeo.org:
  On Mon, Jan 5, 2015 at 12:56 PM, Martin Landa landa.mar...@gmail.com
 wrote:
  ...
  these errors are related to the recent API changes in GRASS 7. I fixed
  that in gdal trunk [1] and later will do backport it to gdal 1.11
  branch.

 done in r28291. To compile GDAL against GRASS you need at least GDAL
 1.11 from svn branch [1].

 Martin

 [1] http://svn.osgeo.org/gdal/branches/1.11/

 --
 Martin Landa
 http://geo.fsv.cvut.cz/gwiki/Landa
 http://gismentors.eu/mentors/landa

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

Re: [GRASS-dev] R in winGRASS

[Paulo van Breugel]

Hi Anna,

You need to define the path to R. I wrote a short explanation here:
https://pvanb.wordpress.com/2014/12/17/access-r-from-grass-gis-on-windows/

Hope that helps,

Paulo

On Mon, Mar 16, 2015 at 11:12 PM, Anna Petrášová kratocha...@gmail.com
wrote:



 On Mon, Mar 16, 2015 at 6:05 PM, Anna Petrášová kratocha...@gmail.com
 wrote:

 Hi,

 I am having troubles with running R in winGRASS. I installed R using this
 tutorial:

 http://www.r-bloggers.com/installing-rcpp-on-windows-7-for-r-and-c-integration/

 In normal windows command line, it works. In GRASS session, I get this
 when running R:

 C:\Users\akratocR
 '\R.exe' is not recognized as an internal or external command,
 operable program or batch file.

 Any idea?


 I just read on the wiki, you have to install R first, then GRASS, so I
 reinstalled GRASS, but still no success.


 Thank you

 Anna



 ___
 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] Compute mahalanobis distance using Scipy

[Paulo van Breugel]

On Mon, Mar 16, 2015 at 3:30 PM, Glynn Clements gl...@gclements.plus.com
wrote:


 Paulo van Breugel wrote:

  When running the tiled_function function you wrote [1] I am getting the
  error below.
 
  {{{
  tiled_function(raster_inputs=ref, raster_output=out_mah1,
  func=mahalanobis_distances)
  }}}
 
  ERROR: No null file for out_mah1
 
  Any idea what is wrong?

 That error message is from lib/raster, and indicates that the null
 file couldn't be created (Rast_open_new() should probably generate an
 error or warning if this happens; the fact that it doesn't suggests
 that it isn't a common occurrence).

 Were there any other warnings prior to that? Check the permissions on
 the mapset directory, the cell_misc subdirectory, and the
 cell_misc/out_mah1 subdirectory (if it exists).


No prior warnings, as far as I could see. Permissions on those folders are
OK. No cell_misc/out_mah1, but that makes sense I guess as that is the
raster file that should be created by the tiled_function.



 Alternatively, it might indicate an issue in the PyGrass library; that
 code is relatively new.


OK, hopefully the PyGrass gurus can have a look at it.


 --
 Glynn Clements gl...@gclements.plus.com

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

[GRASS-dev] Compute mahalanobis distance using Scipy

[Paulo van Breugel]

Hi Pietro,

When running the tiled_function function you wrote [1] I am getting the
error below.

{{{
tiled_function(raster_inputs=ref, raster_output=out_mah1,
func=mahalanobis_distances)
}}}

ERROR: No null file for out_mah1

Any idea what is wrong?

Best wishes,

Paulo


[1] http://lists.osgeo.org/pipermail/grass-dev/2015-February/074049.html
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] r.to.rast3

[Paulo van Breugel]

On the manual page for r.to.rast3, under Notes, it says If fewer 2D raster
maps are provided than depths, the last give 2D map is used to fill up the
RASTER3D slices to the top. How do you define the depths?

Perhaps related, in Example 2 it says that it shows how to convert 3 maps
into 3d map with 6 layers. Why 6 layers, what determines that 6 layers are
created?
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Compute mahalanobis distance using Scipy

[Paulo van Breugel]

Great, I'll do that



On Mon, Mar 16, 2015 at 9:56 PM, Pietro peter.z...@gmail.com wrote:

 Hi Paulo,

 On Mon, Mar 16, 2015 at 9:23 PM, Paulo van Breugel
 p.vanbreu...@gmail.com wrote:
  Paulo van Breugel wrote:
  Alternatively, it might indicate an issue in the PyGrass library; that
  code is relatively new.
 
 
  OK, hopefully the PyGrass gurus can have a look at it.

 Ofcourse I will look into it, but since I need two/three weeks, may be
 could a good idea to open a ticket on track, just to not forget this
 problem.
 Thank you for reporting this.

 Pietro

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

Re: [GRASS-dev] r.to.rast3

[Paulo van Breugel]

Thanks, clear now :-)

Op di 17 mrt. 2015 09:49 schreef Sören Gebbert soerengebb...@googlemail.com
:

 Hi,
 you can specify the 3D region with g.region, which includes the top,
 bottom and res3/tbres settings. These settings define the number of
 depths. Its the same principle as for row and columns.

 r3.info will show you the number of depths for a voxel map.

 Best regards
 Soeren

 2015-03-17 9:45 GMT+01:00 Paulo van Breugel p.vanbreu...@gmail.com:
  On the manual page for r.to.rast3, under Notes, it says If fewer 2D
 raster
  maps are provided than depths, the last give 2D map is used to fill up
 the
  RASTER3D slices to the top. How do you define the depths?
 
  Perhaps related, in Example 2 it says that it shows how to convert 3
 maps
  into 3d map with 6 layers. Why 6 layers, what determines that 6 layers
 are
  created?
 
 
 
  ___
  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] r.to.rast3

[Paulo van Breugel]

On Tue, Mar 17, 2015 at 2:40 PM, Markus Neteler nete...@osgeo.org wrote:

 On Tue, Mar 17, 2015 at 10:09 AM, Paulo van Breugel
 p.vanbreu...@gmail.com wrote:
  Thanks, clear now :-)

 Please suggest manual improvements...


 thanks
 Markus


I have no experience using the 3D rasters, so I will keep it to some more
generic suggestions:

Perhaps a suggestion would be to start both examples with a line in which
the region in set, e.g., g.region b=0 t=600 tbres=100 res3=100

In the description, perhaps adding more explicitly that one needs to take
care to set the 3d region settings, including number or layers and depth of
layer, with g.region.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] raster digitizer

[Paulo van Breugel]

When editing a raster using the raster digitizer, the resolution is changes
(lower resolution) after saving the edits. Is this the intended behaviour,
and if so, what is determining the resolution?

My prefered behaviour would be that the resolution used follows that of the
region settings.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] raster digitizer

[Paulo van Breugel]

Hi Anna,

OK, I did some further testing in another mapset, and it seems it was a
problem with the region settings. After setting the region using 'set
computational region from selected map(s)' the region wasn't set correctly.
It seems to work fine now though. Sorry for the buzz.
















On Wed, Mar 4, 2015 at 7:36 PM, Anna Petrášová kratocha...@gmail.com
wrote:



 On Wed, Mar 4, 2015 at 12:49 PM, Paulo van Breugel p.vanbreu...@gmail.com
  wrote:

 When editing a raster using the raster digitizer, the resolution is
 changes (lower resolution) after saving the edits. Is this the intended
 behaviour, and if so, what is determining the resolution?

 My prefered behaviour would be that the resolution used follows that of
 the region settings.


 Hm, that's how it should behave. Are you sure it's not doing that? I don't
 change region anywhere in the code so it must use the computational region.

 Anna


 ___
 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] New stable release: GRASS GIS 7.0.0

[Paulo van Breugel]

Congratulations to all developers!!

On Sun, Feb 22, 2015 at 10:51 PM, Markus Neteler nete...@osgeo.org wrote:

 Press release

 The GRASS GIS Development team has announced the release of the new
 major version GRASS GIS 7.0.0. This version provides many new
 functionalities including spatio-temporal database support, image
 segmentation, estimation of evapotranspiration and emissivity from
 satellite imagery, automatic line vertex densification during
 reprojection, more LIDAR support and a strongly improved graphical
 user interface experience. GRASS GIS 7.0.0 also offers significantly
 improved performance for many raster and vector modules: Many
 processes that would take hours now take less than a minute, even on
 my small laptop! explains Markus Neteler, the coordinator of the
 development team composed of academics and GIS professionals from
 around the world. The software is available for Linux, MS-Windows, Mac
 OSX and other operating systems.

 Detailed announcement and software download:

 http://grass.osgeo.org/news/42/15/GRASS-GIS-7-0-0/


 About GRASS GIS

 The Geographic Resources Analysis Support System
 (http://grass.osgeo.org/), commonly referred to as GRASS GIS, is an
 Open Source Geographic Information System providing powerful raster,
 vector and geospatial processing capabilities in a single integrated
 software suite. GRASS GIS includes tools for spatial modeling,
 visualization of raster and vector data, management and analysis of
 geospatial data, and the processing of satellite and aerial imagery.
 It also provides the capability to produce sophisticated presentation
 graphics and hardcopy maps. GRASS GIS has been translated into about
 twenty languages and supports a huge array of data formats. It can be
 used either as a stand-alone application or as backend for other
 software packages such as QGIS and R geostatistics. It is distributed
 freely under the terms of the GNU General Public License (GPL). GRASS
 GIS is a founding member of the Open Source Geospatial Foundation
 (OSGeo).
 ___
 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

[GRASS-dev] Make it clearer that GRASS 7.0 is the version to go for now

[Paulo van Breugel]

On http://grass.osgeo.org/download/software/sources/ it reads:

GRASS GIS 6.4 (stable): Most users will want to install this officially
released version.
GRASS GIS 7.0 (new stable): New stable. See announcement. Very promising
(see New Features) and usually works.

Should this be changed, with GRASS GIS 7.0 being the version that most
users want to install? And I would change GRASS GIS 6.4 (stable) to GRASS
GIS 6.4 (previous version). This makes it implicitly clear that it is
stable version too, but more relevant, it emphasizes that people should
start using GRASS 7
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Make it clearer that GRASS 7.0 is the version to go for now

[Paulo van Breugel]

On Tue, Feb 24, 2015 at 4:58 PM, Markus Neteler nete...@osgeo.org wrote:

 On Tue, Feb 24, 2015 at 4:25 PM, Margherita Di Leo direg...@gmail.com
 wrote:
  Probably also
  http://grass.osgeo.org/documentation/general-overview/#AboutGRASS6
  http://grass.osgeo.org/documentation/general-overview/#AboutGRASS7
 
  Should be updated accordingly. (GRASS GIS 7 is under development with a
  first releases in preparation)
 
  Perhaps the about GRASS6 should become less visible, as now is the
 first
  that meets the eye.



Agree, and therefore I would put 'About GRASS GIS 7' first, followed by the
'About GRASS GIS 6' paragraph (or leave the latter out altogether).

That paragraph also links to the wikipedia about GRASS should perhaps be
added to the paragraph 'About GRASS GIS 7' instead (The *GRASS GIS 7*
(Wikipedia
entry http://en.wikipedia.org/wiki/GRASS_GIS) ...). And there is a small
typo in that paragraph: A full temporal framwork - e missing in framework.

This btw means the Wikipedia article should be adapted too. I would suggest
the sentence 'GRASS 6.4.0 introduced a new generation of graphical user
interface called *wxGUI*. wxGUI is designed using Python
http://en.wikipedia.org/wiki/Python_%28programming_language%29
programming language and wxPython http://en.wikipedia.org/wiki/WxPython
graphical library' should be replaced with the short description, perhaps
based on the above mentioned 'About GRASS GIS 7' paragraph?, i.e.,

The latest  stable release version (LTS) is GRASS GIS 7, which is available
since 2015. It offers, amongst others, large data support, an improved
topological 2D/3D vector engine and much improved vector network analysis.
Attributes are managed by default in SQLite format. The display manager has
been improved for usability. The NVIZ visualization tool was completely
rewritten. Image processing has also been improved. A full temporal
framework has been added. See more details at New Features
https://trac.osgeo.org/grass/wiki/Grass7/NewFeatures.

Anybody who normally takes care of that?





 Modifications done. Please check (and suggest if further changes desired).






 Markus

 --
 http://courses.neteler.org
 http://gis.cri.fmach.it/neteler/

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

Re: [GRASS-dev] Make it clearer that GRASS 7.0 is the version to go for now

[Paulo van Breugel]

On Tue, Feb 24, 2015 at 6:17 PM, Markus Neteler nete...@osgeo.org wrote:

 All done, see again
  http://grass.osgeo.org/documentation/general-overview

 Markus

 PS: the Wikipedia update I'll leave to others


I made some changes to the Wikipedia page, please have a look if OK. As it
includes a history section, it might be nice to add a brief overview of
when the different versions where released, perhaps with some key
improvements. Is there anywhere such an overview (I admittedly haven't
looked hard, just came up as an idea).
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Inconsistent number of columns in the table

[Paulo van Breugel]

After importing a vector map in GRASS GIS, when I try to open the table
manager, I get the message that there is a Inconsistent number of columns
in the table reptiles_east_Africa

I can open the same table without problems in sqlite managers such as
navigat and sqlite manager.

I suspect the text in one or more of the entries contains a character that
is interpreted as delimiter by the table manager. What characters are
interpreted as delimiters by the table manager (so I know what to look
for)? Or is there another likely reason for this problem?

Paulo

Running GRASS 7dev on Linux.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Inconsistent number of columns in the table

[Paulo van Breugel]

On Fri, Apr 3, 2015 at 4:42 PM, Anna Petrášová kratocha...@gmail.com
wrote:



 On Fri, Apr 3, 2015 at 8:34 AM, Anna Petrášová kratocha...@gmail.com
 wrote:



 On Fri, Apr 3, 2015 at 5:22 AM, Paulo van Breugel p.vanbreu...@gmail.com
  wrote:

 After importing a vector map in GRASS GIS, when I try to open the table
 manager, I get the message that there is a Inconsistent number of columns
 in the table reptiles_east_Africa

 I can open the same table without problems in sqlite managers such as
 navigat and sqlite manager.

 I suspect the text in one or more of the entries contains a character
 that is interpreted as delimiter by the table manager. What characters are
 interpreted as delimiters by the table manager (so I know what to look
 for)? Or is there another likely reason for this problem?


 That's weird because the separator is composed of multiple characters (it
 is string '{_sep_}'), so very unlikely to be in the data. Could you share
 the data to test?


 New ticket:
 http://trac.osgeo.org/grass/ticket/2640

 There is a newline in record #406, try to remove it first (it shouldn't be
 there anyway in this case), then it should work.


Thanks Anna. Out of curiosity, and so I can find this kind of problems
myself next time, how did you find the problematic line?




 Anna


 Paulo

 Running GRASS 7dev on Linux.



 ___
 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

[GRASS-dev] Any plans to port r.out.mbtiles to GRASS 7

[Paulo van Breugel]

Hi, I am looking at r.out.mbtiles, which looks like a very useful addon and
would like to check if there are any plans to port this to python / GRASS
GIS 7.0 (Hamish?)?

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

[GRASS-dev] v.db.addtable turns column headers in lower case

[Paulo van Breugel]

If I add a new table to a vector layer, column names are always in lower
case, even if defined with capital letters. For example:

{{{v.db.addtable map=test table=test columns=TEST1 INTEGER,TEST2
VARCHAR(25)}}}

Results in a table with the columns cat, test1, test2. Is this
intentional?

Adding columns to a table withv.db.addcolumn does not show this behavious
(i.e., it will retain capitalization of column headers).
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GSOC 2015: Improved Metadata for GRASS GIS

[Paulo van Breugel]

Hi Matej

Thanks for the quick reply. I did indeed manage to install it now. 
However, when trying to run g.gui.metadata, I got the error message below:


Installation of wx.metadata successfully finished

(Wed Apr 29 21:58:43 2015) Command finished (8 sec)

Traceback (most recent call last):

  File /usr/local/grass7/grass-7.1.svn/gui/wxpython/gui_cor

e/prompt.py, line 263, in OnItemSelected

self.cmdDesc = gtask.parse_interface(cmd)

  File /usr/local/grass7/grass-7.1.svn/etc/python/grass/scr

ipt/task.py, line 509, in parse_interface

tree = etree.fromstring(get_interface_description(name))

  File /usr/local/grass7/grass-7.1.svn/etc/python/grass/scr

ipt/task.py, line 493, in get_interface_description

\n\nDetails: %(det)s) % {'cmd': cmd, 'det': e}

grass.exceptions

.

ScriptError

:

Unable to fetch interface description for command

'g.mui.metadata'.

Details: [Errno 2] No such file or directory


Any idea?

Best wishes

Paulo

On 29-04-15 21:53, Matej Krejci wrote:
Now it should work. The problem was in modification/remove 
of GuiModuleMain from core.utils.


2015-04-28 20:55 GMT+02:00 Paulo van Breugel p.vanbreu...@gmail.com 
mailto:p.vanbreu...@gmail.com:


Is the addon working in GRASS 7.1? I can't compile it.


On Tue, Apr 28, 2015 at 8:16 PM, Matej Krejci
matejkre...@gmail.com mailto:matejkre...@gmail.com wrote:

Hi,
Thanks for the chance to participate on GSOC 2015. The page
about project is on wiki site[1]. Thank you for ideas and
notes in advance.

Matej

[1] http://trac.osgeo.org/grass/wiki/GSoC/2015/ImprovedMetadata

2015-03-11 1:55 GMT+01:00 Matej Krejci matejkre...@gmail.com
mailto:matejkre...@gmail.com:

Hi all,

Last GSOC I was working on ISO based metadata management
for GRASS. In this term I was created 'package'
wx.metadata which is currently available in GRASS add-ons.
This part was essential. During playing with possibilities
of implementation I did a draft of metadata catalogue
which is the main task of current GSOC topic[1]. Moreover
to implement additional functions (see list[1]) for
current metadata modules is more than suitable.
Since last GSOC I am still slightly in coding for GRASS
and I like to continue in this topic. Please let me know
if the topic is still free.

Thanks in advance,
Matej


[1]

http://trac.osgeo.org/grass/wiki/GSoC/2015#ImprovedMetadataforGRASSGIS



___
grass-dev mailing list
grass-dev@lists.osgeo.org mailto: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

[GRASS-dev] r.relief

[Paulo van Breugel]

Hi,

When running r.relief (in GRASS7.1) on a integer DEM raster, the output 
is an integer map. Is this intended behavior? Would it be possible to 
have r.relief convert the layer to double precision / float 
automatically if the DEM is of CELL type?


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

Re: [GRASS-dev] r.relief

[Paulo van Breugel]

Out of curiosity, what are those reasons? From a user perspective it 
might not be that obvious (well, it wasn't for me at least). If the 
current implementation is maintained, perhaps it would be useful to add 
a note to the manual page?


Paulo



On 30-04-15 15:15, Helena Mitasova wrote:

I think that user should do the conversion (in most cases it needs to be 
reinterpolated).
I think that the current behavior is right for many reasons,

Helena



On Apr 30, 2015, at 8:25 AM, Paulo van Breugel p.vanbreu...@gmail.com wrote:

Hi,

When running r.relief (in GRASS7.1) on a integer DEM raster, the output is an 
integer map. Is this intended behavior? Would it be possible to have r.relief 
convert the layer to double precision / float automatically if the DEM is of 
CELL type?

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

Helena Mitasova
Professor at the Department of Marine,
Earth, and Atmospheric Sciences
and Center for Geospatial Analytics
North Carolina State University
Raleigh, NC 27695-8208
hmit...@ncsu.edu
http://geospatial.ncsu.edu/osgeorel/
All electronic mail messages in connection with State business which are sent 
to or received by this account are subject to the NC Public Records Law and may be 
disclosed to third parties.”



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

Re: [GRASS-dev] GSOC 2015: Improved Metadata for GRASS GIS

[Paulo van Breugel]

Is the addon working in GRASS 7.1? I can't compile it.


On Tue, Apr 28, 2015 at 8:16 PM, Matej Krejci matejkre...@gmail.com wrote:

 Hi,
 Thanks for the chance to participate on GSOC 2015. The page about project
 is on wiki site[1]. Thank you for ideas and notes in advance.

 Matej

 [1] http://trac.osgeo.org/grass/wiki/GSoC/2015/ImprovedMetadata

 2015-03-11 1:55 GMT+01:00 Matej Krejci matejkre...@gmail.com:

 Hi all,

 Last GSOC I was working on ISO based metadata management for GRASS. In
 this term I was created 'package' wx.metadata which is currently available
 in GRASS add-ons. This part was essential. During playing with
 possibilities of implementation I did a draft of metadata catalogue which
 is the main task of current GSOC topic[1]. Moreover to implement additional
 functions (see list[1]) for current metadata modules is more than suitable.
 Since last GSOC I am still slightly in coding for GRASS and I like to
 continue in this topic. Please let me know if the topic is still free.

 Thanks in advance,
 Matej


 [1]
 http://trac.osgeo.org/grass/wiki/GSoC/2015#ImprovedMetadataforGRASSGIS



 ___
 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] Compute mahalanobis distance using Scipy

[Paulo van Breugel]

Hi Pietro

I would just like to check if you had a change to look at the problem 
described in http://trac.osgeo.org/grass/ticket/2629?


Cheers

Paulo


On 16-03-15 22:01, Paulo van Breugel wrote:

Great, I'll do that



On Mon, Mar 16, 2015 at 9:56 PM, Pietro peter.z...@gmail.com 
mailto:peter.z...@gmail.com wrote:


Hi Paulo,

On Mon, Mar 16, 2015 at 9:23 PM, Paulo van Breugel
p.vanbreu...@gmail.com mailto:p.vanbreu...@gmail.com wrote:
 Paulo van Breugel wrote:
 Alternatively, it might indicate an issue in the PyGrass library; that
 code is relatively new.


 OK, hopefully the PyGrass gurus can have a look at it.

Ofcourse I will look into it, but since I need two/three weeks, may be
could a good idea to open a ticket on track, just to not forget this
problem.
Thank you for reporting this.

Pietro




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

Re: [GRASS-dev] r.relief

[Paulo van Breugel]

Thanks for the explanation, and yes, it does makes sense to leave it as 
an option to the user.


Rgds,

Paulo

On 30-04-15 16:44, Helena Mitasova wrote:

In areas of low relief the integer DEMs have steps (you get alternating flat 
and steep areas, with steep
areas along contours which you may be seeing in your shaded relief map), so 
when you run
r.relief and you get a nice smooth map because the data were converted to float 
using bilinear interpolation
you do not realize that you have the steps (you don’t see them on the 2D 
elevation map).
Then you run some modeling or analysis using slope or flow routing running 
through these flats (which could be quite large) and you get various artificial 
patterns of the modeling results in these flat areas or you run some 
statistical analysis you will get serious bias in the histogram
see the slide #14 here
http://courses.ncsu.edu/mea582/common/GIS_anal_lecture/GIS_Anal_Ltopoanal.ppt

If you convert to float using nearest neighbor you may still get the flats 
depending on the resolution.
Integer DEMs are pretty much a pain to work with if you are doing more than 
just visualizing
the terrain and the steps along 1m contours
are quite hard to get rid of in areas of low relief - you pretty much have to 
reinterpolate the DEM.
Integer shaded relief output alerts user that the data are integer and they may 
have a problem,
or if it is in mountains that the integers are not an issue.

So what may be a convenience for one user may cause problems for other users, 
so if we want to conversion it should be a flag (similar situation like the -a 
flag in r.watershed).

Helena




On Apr 30, 2015, at 10:00 AM, Paulo van Breugel p.vanbreu...@gmail.com wrote:

Out of curiosity, what are those reasons? From a user perspective it might not 
be that obvious (well, it wasn't for me at least). If the current 
implementation is maintained, perhaps it would be useful to add a note to the 
manual page?

Paulo



On 30-04-15 15:15, Helena Mitasova wrote:

I think that user should do the conversion (in most cases it needs to be 
reinterpolated).
I think that the current behavior is right for many reasons,

Helena



On Apr 30, 2015, at 8:25 AM, Paulo van Breugel p.vanbreu...@gmail.com wrote:

Hi,

When running r.relief (in GRASS7.1) on a integer DEM raster, the output is an 
integer map. Is this intended behavior? Would it be possible to have r.relief 
convert the layer to double precision / float automatically if the DEM is of 
CELL type?

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

Helena Mitasova
Professor at the Department of Marine,
Earth, and Atmospheric Sciences
and Center for Geospatial Analytics
North Carolina State University
Raleigh, NC 27695-8208
hmit...@ncsu.edu
http://geospatial.ncsu.edu/osgeorel/
All electronic mail messages in connection with State business which are sent 
to or received by this account are subject to the NC Public Records Law and may be 
disclosed to third parties.”


Helena Mitasova
Professor at the Department of Marine,
Earth, and Atmospheric Sciences
and Center for Geospatial Analytics
North Carolina State University
Raleigh, NC 27695-8208
hmit...@ncsu.edu
http://geospatial.ncsu.edu/osgeorel/
All electronic mail messages in connection with State business which are sent 
to or received by this account are subject to the NC Public Records Law and may be 
disclosed to third parties.”



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

Re: [GRASS-dev] Error reading null row 8 for MASK

[Paulo van Breugel]

On 04-05-15 20:36, Markus Neteler wrote:

On Mon, May 4, 2015 at 8:05 PM, Alba German albager...@gmail.com wrote:

Hello!
I am running a loop with several r.mapcalc. I am using GRASS 7.1. The
function stops with an error:

ERROR: Error reading null row 8 for MASK

I've noticed that Paulo van Breugel, had the same error but I didn't see the
solution to it.


You are referring to this email: 
http://lists.osgeo.org/pipermail/grass-dev/2014-September/070584.html. 
Can't recall how / if I solved this, but I haven't encountered it 
recently. The difficult part of it was that it appeared to happen at 
random, i.e., the same function and same data would run without problem 
in one instance and end with the above-mentioned error in another instance.



Obviously it has something to do with the raster called
MASK, created with r.mask before running the loop of multiple r.mapcalc.
The code itself has no problem and is very simple and works just fine with
the same list of images, but without running r.mask first.

Hi Alba,

could you post that part of the code e.g. here
http://pastebin.com/

? It sounds like a race condition...

Markus
___
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] g.region zoom?

[Paulo van Breugel]

On Mon, May 11, 2015 at 5:58 PM, Anna Petrášová kratocha...@gmail.com
wrote:

 Hi,

 I just realized how g.region zoom actually works and I am wondering if it
 is supposed to be obvious. I always thought it will set the region to the
 raster map minimum bounding box, but it takes current region and only
 shrinks it. The behavior is written in the manual (I eventually realized),
 but it doesn't strike me as particularly useful.


What for example if you want to restrict calculations to the region defined
by the non-null values of a particular map that has a different resolution
than the maps you are using in your calculations?


 At least I would suggest to change the g.region zoom behavior in the GUI
 - right click on layer - Set computational region from selected map
 (ignore NULLS) to:

 g.region raster=map zoom=map


That does indeed seems the more obvious / intuitive behaviour to me


 instead of

 g.region zoom=map

 Any thoughts on that?

 Thanks,

 Anna


 ___
 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] g.region zoom?

[Paulo van Breugel]

On Mon, May 11, 2015 at 11:48 PM, Anna Petrášová kratocha...@gmail.com
wrote:



 On Mon, May 11, 2015 at 5:01 PM, Paulo van Breugel p.vanbreu...@gmail.com
  wrote:



 On Mon, May 11, 2015 at 5:58 PM, Anna Petrášová kratocha...@gmail.com
 wrote:

 Hi,

 I just realized how g.region zoom actually works and I am wondering if
 it is supposed to be obvious. I always thought it will set the region to
 the raster map minimum bounding box, but it takes current region and only
 shrinks it. The behavior is written in the manual (I eventually realized),
 but it doesn't strike me as particularly useful.


 What for example if you want to restrict calculations to the region
 defined by the non-null values of a particular map that has a different
 resolution than the maps you are using in your calculations?


 I am not concerned with resolution but extent. I was mostly confused from
 the case when I have region smaller than the extent of the raster (from
 previous computation) and then I expected g.region zoom  to set the region
 on the whole raster extent, but instead it shrinks even more if there are
 nulls or it stays the same. So the result of the g.region zoom depends on
 you previous region settings which was unexpected for me.


Ah, never got that situation, but that would be unexpected to me too.



 At least I would suggest to change the g.region zoom behavior in the GUI
 - right click on layer - Set computational region from selected map
 (ignore NULLS) to:

 g.region raster=map zoom=map


 That does indeed seems the more obvious / intuitive behaviour to me



 I will do that, thanks!


 instead of

 g.region zoom=map

 Any thoughts on that?

 Thanks,

 Anna


 ___
 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

[GRASS-dev] Error messages when installing addons

[Paulo van Breugel]

I updated a number of extensions, all which installed successfully.
However, for four (g.cloud, r.mcda.roughset, r.futures, v.area.stats) I got
some error messages. Not sure they are relevant, but though I might as well
report them. I am running GRASS dev (rev 65027) on Linux (Ubuntu 14.04).

*g.cloud*
g.extension extension=g.cloud
operation=add
WARNING: Extension g.cloud already installed. Re-installing...
Fetching g.cloud from GRASS-Addons SVN repository (be patient)...
Compiling...
Makefile:16: warning: overriding commands for target
`/tmp/tmpIdTTFc/g.cloud/etc/g.cloud'
/usr/local/grass7/grass-7.1.svn/include/Make/ScriptRules.mak
e:19: warning: ignoring old commands for target
`/tmp/tmpIdTTFc/g.cloud/etc/g.cloud'
Installing...
Makefile:16: warning: overriding commands for target
`/tmp/tmpIdTTFc/g.cloud/etc/g.cloud'
/usr/local/grass7/grass-7.1.svn/include/Make/ScriptRules.mak
e:19: warning: ignoring old commands for target
`/tmp/tmpIdTTFc/g.cloud/etc/g.cloud'
Updating addons metadata file...
Installation of g.cloud successfully finished

*r.mcda.roughset*
g.extension extension=r.mcda.roughset
operation=add
WARNING: Extension r.mcda.roughset already installed. Re-installing...
Fetching r.mcda.roughset from GRASS-Addons SVN repository (be patient)...
Compiling...
WARNING: BUG in option name, 'outputMap' is not valid
WARNING: BUG in option name, 'outputTxt' is not valid
Installing...
Updating addons metadata file...
Installation of r.mcda.roughset successfully finished

*r.futures*
g.extension extension=r.futures
operation=add
WARNING: Extension r.futures already installed. Re-installing...
Fetching r.futures from GRASS-Addons SVN repository (be patient)...
Compiling...
main.cpp: In function ‘int main(int, char**)’:
main.cpp:2512:67: warning: suggest parentheses around
assignment used as truth value [-Wparentheses]
 if (pPtr =
strchr(inBuff, ',')) {
   ^
main.cpp: In function ‘void
findAndSortProbsAll(t_Landscape*, t_Params*, int)’:
main.cpp:2663:55: warning: comparison between signed and
unsigned integer expressions [-Wsign-compare]
 pLandscape-asUndevs[id].size())
   ^
main.cpp: In function ‘int readData(t_Landscape*,
t_Params*)’:
main.cpp:639:71: warning: ‘iVal’ may be used
uninitialized in this function [-Wmaybe-uninitialized]
pLandscape-asCells[i].bUndeveloped = iVal;
   ^
main.cpp:689:52: warning: ‘y’ may be used uninitialized
in this function [-Wmaybe-uninitialized]
 G_message(_(x=%d y=%d), x, y);
^
main.cpp: In function ‘int main(int, char**)’:
main.cpp:2426:21: warning: ‘seed_value’ may be used
uninitialized in this function [-Wmaybe-uninitialized]
 srand(seed_value);
 ^
Installing...
Updating addons metadata file...
Installation of r.futures successfully finished

*v.area.stats*
g.extension extension=v.area.stats
operation=add
WARNING: Extension v.area.stats already installed. Re-installing...
Fetching v.area.stats from GRASS-Addons SVN repository (be patient)...
Compiling...
export.c: In function ‘export2csv’:
export.c:97:4: warning: format not a string literal and no
format arguments [-Wformat-security]
printf(buf);
^
Installing...
Updating addons metadata file...
Installation of v.area.stats successfully finished
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] r.sample.category

[Paulo van Breugel]

Hi Anna

I was thinking about the option for the user to (1) define a separate 
percentage for each category or (2) one percentage for the whole raster 
(e.g., 10% -- 10% of cells in each category is sampled).


If you implement the second option, you would more or less have your 6th 
TODO (specify number of points and distribute them according to 
histogram) I guess?


Cheers,

Paulo



On 23-06-15 04:01, Anna Petrášová wrote:


Hi Paulo,

On Tue, Jun 16, 2015 at 5:38 AM, Paulo van Breugel 
p.vanbreu...@gmail.com mailto:p.vanbreu...@gmail.com wrote:


I am having a look at the new r.sample.category addon. Great idea.
I would like to make a suggestion; to allow the user to define the
number of points as a percentage, similar to r.random.


do you mean number of points should be based on percentage of cells in 
each category or the entire raster? There are some other TODOs in

https://trac.osgeo.org/grass/browser/grass-addons/grass7/raster/r.sample.category/r.sample.category.py#L47

Best,

Anna


Rgds,

Paulo




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

[GRASS-dev] r.sample.category

[Paulo van Breugel]

I am having a look at the new r.sample.category addon. Great idea. I would
like to make a suggestion; to allow the user to define the number of points
as a percentage, similar to r.random.

Rgds,

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

[GRASS-dev] maps not showing in Data catalog

[Paulo van Breugel]

In one of my mapsets, raster layers are not showing in the Data catalog
(vector layers are). They do also not show in the metadata editor
(g.gui.metadata), which I guess is a related problem.

The list of raster layers do show in d.rast and in the layer selection
window opened with Ctrl+L.

Any hint where to look for the problem. Is there a place where the layers
are registered per mapset?

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

Re: [GRASS-dev] what is the meaning of: Error reading raster data for row 239 of MASK

[Paulo van Breugel]

On 03-07-15 11:04, Moritz Lennert wrote:

On 02/07/15 19:26, Markus Neteler wrote:

On Jul 2, 2015 5:18 PM, Moritz Lennert mlenn...@club.worldonline.be
mailto:mlenn...@club.worldonline.be wrote:
 
  Hello,
 
  When I run a script that loops over a long series of point data sets
and then does a series of raster calculations based on these data sets,
I sometimes get the following error:
 
  ERROR: Error reading raster data for row 239 of MASK
 
  Can someone explain what this means and how to debug this ?



Just to note that this does not seem to be an isolated problem:

* http://lists.osgeo.org/pipermail/grass-dev/2014-September/070584.html
* http://lists.osgeo.org/pipermail/grass-dev/2015-May/074937.html



Maybe some off_t issue?
Please post the region settings and related info...



 g.version -reb
GRASS 7.1.svn (2015)

 ./configure  --prefix=/usr/lib --sysconfdir=/etc 
--sharedstatedir=/var --enable-socket --enable-shared 
--enable-largefile --with-postgres --with-mysql --with-pthread 
--with-cxx --with-x --with-gdal --with-freetype --with-motif 
--with-readline --with-nls --with-odbc --with-sqlite 
--with-freetype-includes=/usr/include/freetype2 
--with-tcltk-includes=/usr/include/tcl 
--with-postgres-includes=/usr/include/postgresql 
--with-mysql-includes=/usr/include/mysql 
--with-proj-share=/usr/share/proj --with-python=/usr/bin/python-config 
--with-cairo --with-geos --with-blas --with-lapack 
--with-liblas=/usr/bin/liblas-config

libgis Revision: 64732
libgis Date: 2015-02-25 01:54:05 +0100 (mer 25 fév 2015)
PROJ.4: 4.9.1
GDAL/OGR: 1.10.1
GEOS: 3.4.2
SQLite: 3.8.10.2


 g.region -p
projection: 99 (Lambert Azimuthal Equal Area)
zone:   0
datum:  etrs89
ellipsoid:  grs80
north:  3177000
south:  2937000
west:   379
east:   4071000
nsres:  1000
ewres:  1000
rows:   240
cols:   281
cells:  67440


 r.info -g MASKnorth=3177000
south=2937000
east=4071000
west=379
nsres=1000
ewres=1000
rows=240
cols=281
cells=67440
datatype=CELL
ncats=1

Here's the error:

ERREUR: Error reading raster data for row 239 of MASK
Traceback (most recent call last):
  File ../../calulate_huff.py, line 346, in module
quiet=True)
  File 
/data/home/mlennert/SRC/GRASS/grass_trunk/dist.x86_64-unknown-linux-gnu/etc/python/grass/script/core.py, 
line 376, in run_command

return handle_errors(returncode, returncode, args, kwargs)
  File 
/data/home/mlennert/SRC/GRASS/grass_trunk/dist.x86_64-unknown-linux-gnu/etc/python/grass/script/core.py, 
line 312, in handle_errors

returncode=returncode)
grass.exceptions.CalledModuleError: Module run None ['r.mapcalc', 
'--o', '--q', 'expression=temp_prob = float(firm_rate_364596) / 
float(sum_rates)'] ended with error
Process ended with non-zero return code 1. See errors in the (error) 
output.


And here the info for the two maps in the r.mapcalc call:

 r.info -g firm_rate_364596
north=3177000
south=2937000
east=4071000
west=379
nsres=1000
ewres=1000
rows=240
cols=281
cells=67440
datatype=DCELL
ncats=0

 r.info -g sum_rates
north=3177000
south=2937000
east=4071000
west=379
nsres=1000
ewres=1000
rows=240
cols=281
cells=67440
datatype=DCELL
ncats=0


But running the same script on the same maps, the error always appears 
at a different stage (other firm_rate_* map).


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

[GRASS-dev] error g.gui.animation when using changing region

[Paulo van Breugel]

Hi, when I define to regions in g.gui.animation (under the advanced tab),
and press OK and OK again, the 'Rendering map layers' gets as far as (3 out
of 12) and then the g.gui.animation freezes. Error messages in the console
below.

Any idea whether this is a bug or if I am doing something wrong?

Paulo

g.gui.animation strds=tmean@Worlclim

Description:
 Manages the boundary definitions for the geographic region.
Keywords:
 general, settings
Usage:
 g.region [-dsplectwmn3bgau] [region=name]
[raster=name[,name,...]]
   [raster_3d=name] [vector=name[,name,...]] [n=value]
[s=value]
   [e=value] [w=value] [t=value] [b=value] [rows=value]
[cols=value]
   [res=value] [res3=value] [nsres=value] [ewres=value]
[tbres=value]
   [zoom=name] [align=name] [save=name] [--overwrite]
[--help]
   [--verbose] [--quiet] [--ui]
Flags:
  -d   Set from default region
  -s   Save as default region
Only possible from the PERMANENT mapset
  -p   Print the current region
  -l   Print the current region in lat/long using the
current ellipsoid/datum
  -e   Print the current region extent
  -c   Print the current region map center coordinates
  -t   Print the current region in GMT style
  -w   Print the current region in WMS style
  -m   Print region resolution in meters (geodesic)
  -n   Print the convergence angle (degrees CCW)
The difference between the projection's grid north
and true north, measured at the center coordinates of the
current region.
  -3   Print also 3D settings
  -b   Print the maximum bounding box in lat/long on WGS84
  -g   Print in shell script style
  -a   Align region to resolution (default = align to
bounds, works only for 2D resolution)
  -u   Do not update the current region
 --o   Allow output files to overwrite existing files
 --h   Print usage summary
 --v   Verbose module output
 --q   Quiet module output
 --ui  Force launching GUI dialog
Parameters:
 region   Set current region from named region
 raster   Set region to match raster map(s)
  raster_3d   Set region to match 3D raster map(s) (both 2D
and 3D values)
 vector   Set region to match vector map(s)
  n   Value for the northern edge
  s   Value for the southern edge
  e   Value for the eastern edge
  w   Value for the western edge
  t   Value for the top edge
  b   Value for the bottom edge
   rows   Number of rows in the new region
   cols   Number of columns in the new region
res   2D grid resolution (north-south and east-west)
   res3   3D grid resolution (north-south, east-west and
top-bottom)
  nsres   North-south 2D grid resolution
  ewres   East-west 2D grid resolution
  tbres   Top-bottom 3D grid resolution
   zoom   Shrink region until it meets non-NULL data
from this raster map
  align   Adjust region cells to cleanly align with this
raster map
   save   Save current region settings in named region
file
ERROR: g.region: Sorry, projection is not a valid
parameter
ERROR: g.region: Sorry, zone is not a valid parameter
Process Process-27:
Traceback (most recent call last):
  File /usr/lib/python2.7/multiprocessing/process.py, line
258, in _bootstrap
self.run()
  File /usr/lib/python2.7/multiprocessing/process.py, line
114, in run
self._target(*self._args, **self._kwargs)
  File /usr/local/grass7/grass-7.1.svn/gui/wxpython/animati
on/provider.py, line 493, in RenderProcess2D
os.environ['GRASS_REGION'] = gcore.region_env(**region)
  File /usr/local/grass7/grass-7.1.svn/etc/python/grass/scr
ipt/core.py, line 1003, in region_env
s = read_command('g.region', flags=flgs, **kwargs)
  File /usr/local/grass7/grass-7.1.svn/etc/python/grass/scr
ipt/core.py, line 427, in read_command
return handle_errors(returncode, stdout, args, kwargs)
  File /usr/local/grass7/grass-7.1.svn/etc/python/grass/scr
ipt/core.py, line 312, in handle_errors
returncode=returncode)
CalledModuleError: Module run None ['g.region', '-ug',
'e=47.991667', 'projection=3', 'zone=0', 'n=14.9',
's=3.317', 'w=32.991667',
'ewres=0.0188442211055', 'nsres=0.024540960452'] ended with
error
Process ended with non-zero return code 1. See errors in the
(error) output.
Description:
 Manages the boundary definitions for the geographic region.
Keywords:
 general, settings
Usage:
 g.region [-dsplectwmn3bgau] [region=name]
[raster=name[,name,...]]
   [raster_3d=name] [vector=name[,name,...]] [n=value]
[s=value]
   [e=value] [w=value] [t=value] [b=value] [rows=value]
[cols=value]
   [res=value] [res3=value] [nsres=value] [ewres=value]
[tbres=value]
   [zoom=name] [align=name] [save=name] [--overwrite]
[--help]
   [--verbose] [--quiet] [--ui]
Flags:
  -d   Set from default region
  -s   Save as default region
Only possible from the PERMANENT mapset
  -p   Print the current region
  -l   Print the current region in lat/long using the
current ellipsoid/datum
  -e   Print the current region extent
  -c   Print the current region map 

Re: [GRASS-dev] how to work around Arument list too long error in a GRASS python script ?

[Paulo van Breugel]

On 11-06-15 19:22, Anna Petrášová wrote:



On Thu, Jun 11, 2015 at 12:37 PM, Moritz Lennert 
mlenn...@club.worldonline.be mailto:mlenn...@club.worldonline.be 
wrote:


Hello,

In a python script I have the following call:

grass.run_command('r.series',
   input = rate_maps,
   output = sum_rates,
   method = 'sum',
   overwrite = True,
   quiet=True)

rate_maps is a list which in one instance contains 8559 map names,
leading to an OSError: [Errno 7] Argument list too long.

I know that in the shell I could use xargs to work around such a
problem. But how to do this in python ?

I could obviously loop through all maps and thus sum them
individually, but this just seems horribly inefficient.

Does anyone have a better solution ?

Moritz


It seems we are hitting these issues quite often, we should consider 
add input file as an option like many temporal modules already have. 
But splitting as Nikos suggests has the advantage that you can 
parallelize the computation.


+1 add input file as an option



Anna

___
grass-dev mailing list
grass-dev@lists.osgeo.org mailto: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


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

Re: [GRASS-dev] error g.gui.animation when using changing region

[Paulo van Breugel]

On Mon, Jul 6, 2015 at 8:24 PM, Anna Petrášová kratocha...@gmail.com
wrote:



 On Mon, Jul 6, 2015 at 2:08 PM, Paulo van Breugel p.vanbreu...@gmail.com
 wrote:

 Hi, when I define to regions in g.gui.animation (under the advanced tab),
 and press OK and OK again, the 'Rendering map layers' gets as far as (3 out
 of 12) and then the g.gui.animation freezes. Error messages in the console
 below.

 Any idea whether this is a bug or if I am doing something wrong?


 This happens in trunk, right? Could you try r65540?


Yes, sorry, forgot to mention. Just updated to latest revision, and it
works beautifully. Thanks!




 Paulo

 g.gui.animation strds=tmean@Worlclim

 Description:
  Manages the boundary definitions for the geographic region.
 Keywords:
  general, settings
 Usage:
  g.region [-dsplectwmn3bgau] [region=name]
 [raster=name[,name,...]]
[raster_3d=name] [vector=name[,name,...]] [n=value]
 [s=value]
[e=value] [w=value] [t=value] [b=value] [rows=value]
 [cols=value]
[res=value] [res3=value] [nsres=value] [ewres=value]
 [tbres=value]
[zoom=name] [align=name] [save=name] [--overwrite]
 [--help]
[--verbose] [--quiet] [--ui]
 Flags:
   -d   Set from default region
   -s   Save as default region
 Only possible from the PERMANENT mapset
   -p   Print the current region
   -l   Print the current region in lat/long using the
 current ellipsoid/datum
   -e   Print the current region extent
   -c   Print the current region map center coordinates
   -t   Print the current region in GMT style
   -w   Print the current region in WMS style
   -m   Print region resolution in meters (geodesic)
   -n   Print the convergence angle (degrees CCW)
 The difference between the projection's grid north
 and true north, measured at the center coordinates of the
 current region.
   -3   Print also 3D settings
   -b   Print the maximum bounding box in lat/long on WGS84
   -g   Print in shell script style
   -a   Align region to resolution (default = align to
 bounds, works only for 2D resolution)
   -u   Do not update the current region
  --o   Allow output files to overwrite existing files
  --h   Print usage summary
  --v   Verbose module output
  --q   Quiet module output
  --ui  Force launching GUI dialog
 Parameters:
  region   Set current region from named region
  raster   Set region to match raster map(s)
   raster_3d   Set region to match 3D raster map(s) (both 2D
 and 3D values)
  vector   Set region to match vector map(s)
   n   Value for the northern edge
   s   Value for the southern edge
   e   Value for the eastern edge
   w   Value for the western edge
   t   Value for the top edge
   b   Value for the bottom edge
rows   Number of rows in the new region
cols   Number of columns in the new region
 res   2D grid resolution (north-south and east-west)
res3   3D grid resolution (north-south, east-west and
 top-bottom)
   nsres   North-south 2D grid resolution
   ewres   East-west 2D grid resolution
   tbres   Top-bottom 3D grid resolution
zoom   Shrink region until it meets non-NULL data
 from this raster map
   align   Adjust region cells to cleanly align with this
 raster map
save   Save current region settings in named region
 file
 ERROR: g.region: Sorry, projection is not a valid
 parameter
 ERROR: g.region: Sorry, zone is not a valid parameter
 Process Process-27:
 Traceback (most recent call last):
   File /usr/lib/python2.7/multiprocessing/process.py, line
 258, in _bootstrap
 self.run()
   File /usr/lib/python2.7/multiprocessing/process.py, line
 114, in run
 self._target(*self._args, **self._kwargs)
   File /usr/local/grass7/grass-7.1.svn/gui/wxpython/animati
 on/provider.py, line 493, in RenderProcess2D
 os.environ['GRASS_REGION'] = gcore.region_env(**region)
   File /usr/local/grass7/grass-7.1.svn/etc/python/grass/scr
 ipt/core.py, line 1003, in region_env
 s = read_command('g.region', flags=flgs, **kwargs)
   File /usr/local/grass7/grass-7.1.svn/etc/python/grass/scr
 ipt/core.py, line 427, in read_command
 return handle_errors(returncode, stdout, args, kwargs)
   File /usr/local/grass7/grass-7.1.svn/etc/python/grass/scr
 ipt/core.py, line 312, in handle_errors
 returncode=returncode)
 CalledModuleError: Module run None ['g.region', '-ug',
 'e=47.991667', 'projection=3', 'zone=0', 'n=14.9',
 's=3.317', 'w=32.991667',
 'ewres=0.0188442211055', 'nsres=0.024540960452'] ended with
 error
 Process ended with non-zero return code 1. See errors in the
 (error) output.
 Description:
  Manages the boundary definitions for the geographic region.
 Keywords:
  general, settings
 Usage:
  g.region [-dsplectwmn3bgau] [region=name]
 [raster=name[,name,...]]
[raster_3d=name] [vector=name[,name,...]] [n=value]
 [s=value]
[e=value] [w=value] [t=value] [b=value] [rows=value]
 [cols=value]
[res=value] [res3=value

Re: [GRASS-dev] installing v.mapcalc fails

[Paulo van Breugel]

Hi Markus

On Linux (Ubuntu 14.04). Tried it again, with another error message this
time:

g.extension extension=v.mapcalc svnurl=
http://svn.osgeo.org/grass/grass-addons/grass7
Fetching v.mapcalc from GRASS-Addons SVN repository (be patient)...
Compiling...
yylex.c:9:27: fatal error: v.mapcalc.tab.h: No such file or
directory
 #include v.mapcalc.tab.h
   ^
compilation terminated.
make: *** [OBJ.x86_64-unknown-linux-gnu/yylex.o] Error 1
ERROR: Compilation failed, sorry. Please check above error messages.



On Sun, Aug 2, 2015 at 8:38 PM, Markus Neteler nete...@osgeo.org wrote:

 On Fri, Jul 24, 2015 at 11:49 AM, Paulo van Breugel
 p.vanbreu...@gmail.com wrote:
  installing v.mapcalc fails,

 Which operating system?

  with the following:
 
  g.extension extension=v.mapcalc
  svnurl=http://svn.osgeo.org/grass/grass-addons/grass7
  Fetching v.mapcalc from GRASS-Addons SVN repository (be patient)...
  Compiling...
  yylex.c: In function ‘yylex’:
  yylex.c:32:7: warning: ignoring return value of ‘scanf’,
  declared with attribute warn_unused_result [-Wunused-result]
scanf(%lf, yylval.dbl);
 ^
  make: *** [v.mapcalc.tmp.html] Error 1
  ERROR: Compilation failed, sorry. Please check above error messages.

 I have applied some Makefile fixes (perhaps unrelated), pls try again.

 Markus

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

Re: [GRASS-dev] installing v.mapcalc fails

[Paulo van Breugel]

On Sun, Aug 2, 2015 at 8:51 PM, Markus Neteler nete...@osgeo.org wrote:

 On Sun, Aug 2, 2015 at 8:45 PM, Paulo van Breugel
 p.vanbreu...@gmail.com wrote:
  Hi Markus
 
  On Linux (Ubuntu 14.04). Tried it again, with another error message this
  time:
 
  g.extension extension=v.mapcalc
  svnurl=http://svn.osgeo.org/grass/grass-addons/grass7
  Fetching v.mapcalc from GRASS-Addons SVN repository (be patient)...
  Compiling...
  yylex.c:9:27: fatal error: v.mapcalc.tab.h: No such file or
  directory
   #include v.mapcalc.tab.h
 ^
  compilation terminated.
  make: *** [OBJ.x86_64-unknown-linux-gnu/yylex.o] Error 1
  ERROR: Compilation failed, sorry. Please check above error messages.

 I tried on my Fedora 21 box:

 GRASS 7.0.2svn (nc_spm_08_grass7):~  g.extension extension=v.mapcalc
 Fetching v.mapcalc from GRASS-Addons SVN repository (be patient)...
 Compiling...
 In file included from /usr/include/stdio.h:27:0,
  from number.c:3:
 /usr/include/features.h:148:3: warning: #warning _BSD_SOURCE and
 _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE [-Wcpp]
  # warning _BSD_SOURCE and _SVID_SOURCE are deprecated, use
 _DEFAULT_SOURCE
^
 Installing...
 Updating addons metadata file...
 Installation of v.mapcalc successfully finished

 No issues...

 The file missing seems to be generated on the fly:

 [neteler@oboe v.mapcalc]$ grep v.mapcalc.tab.h *
 Makefile:yylex.c: v.mapcalc.tab.h
 Makefile:.INTERMEDIATE: v.mapcalc.tab.c v.mapcalc.tab.h v.mapcalc.output
 grep: OBJ.x86_64-unknown-linux-gnu: Is a directory
 grep: plugins: Is a directory
 yylex.c:#include v.mapcalc.tab.h

 Do you have the 'bison' program installed? That's needed.


Yes (it is, I think, also needed to compile grass itself?). Just to be
complete, off all the ones I tried, this is the only one not installing.


 Markus

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

Re: [GRASS-dev] g.extensions problems

[Paulo van Breugel]

On Mon, Aug 3, 2015 at 5:51 PM, Markus Neteler nete...@osgeo.org wrote:

 On Mon, Aug 3, 2015 at 4:06 PM, Paulo van Breugel
 p.vanbreu...@gmail.com wrote:
  There seems to be a problem with addons metadata when installing using
  g.extension. Installing of addons is successful, but with the following
  error message:
 
  WARNING: Unable to parse
  'https://svn.osgeo.org/grass/grass-addons/grass7/modules.xml': syntax
 error:
  line 1, column 49

 The file is simply not (yet) there after the recent server hardware
 migration.

 Work in progress...


Ah, ok, good to know.. so no need to report these issues


 Markus

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

[GRASS-dev] installing v.mapcalc fails

[Paulo van Breugel]

installing v.mapcalc fails, with the following:

g.extension extension=v.mapcalc svnurl=
http://svn.osgeo.org/grass/grass-addons/grass7
Fetching v.mapcalc from GRASS-Addons SVN repository (be patient)...
Compiling...
yylex.c: In function ‘yylex’:
yylex.c:32:7: warning: ignoring return value of ‘scanf’,
declared with attribute warn_unused_result [-Wunused-result]
  scanf(%lf, yylval.dbl);
   ^
make: *** [v.mapcalc.tmp.html] Error 1
ERROR: Compilation failed, sorry. Please check above error messages.

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

[GRASS-dev] Installing wx.metadata fails

[Paulo van Breugel]

Hi, I am trying to install the metadata module (on Ubuntu 14.04, GRASS
7.1dev), but with no luck. See error message below. As far as I can see I
have installed all dependencies. I have also tried again after a complete
fresh start (removing the addon folder (.grass7) and fresh install of
GRASS), also without further success, so I am a bit at loss how to proceed.
I have seen a similar message before, but I don't think I have seen a
solution?

Paulo



GRASS 7.1.svn (latlon):~ > g.extension extension=wx.metadata
Fetching  from GRASS GIS Addons repository (be patient)...
Compiling...
Traceback (most recent call last):
  File
"/tmp/grass7-paulo-18211/tmpcbl2Z1/wx.metadata/scripts/db.csw.admin", line
127, in 
from cswutil import *
ImportError: No module named cswutil
make[1]: *** [db.csw.admin.tmp.html] Error 1
Traceback (most recent call last):
  File
"/tmp/grass7-paulo-18211/tmpcbl2Z1/wx.metadata/scripts/g.gui.cswbrowser",
line 22, in 
from cswlib import CSWBrowserPanel, CSWConnectionPanel
ImportError: No module named cswlib
make[1]: *** [g.gui.cswbrowser.tmp.html] Error 1
Traceback (most recent call last):
  File
"/tmp/grass7-paulo-18211/tmpcbl2Z1/wx.metadata/scripts/g.gui.metadata",
line 38, in 
import mdgrass
ImportError: No module named mdgrass
make[1]: *** [g.gui.metadata.tmp.html] Error 1
Installing...
/usr/bin/install: cannot stat
‘/tmp/grass7-paulo-18211/tmpcbl2Z1/wx.metadata/docs/html/db.csw.admin.html’:
No such file or directory
make[1]: *** [install] Error 1
/usr/bin/install: cannot stat
‘/tmp/grass7-paulo-18211/tmpcbl2Z1/wx.metadata/docs/html/g.gui.cswbrowser.html’:
No such file or directory
make[1]: *** [install] Error 1
/usr/bin/install: cannot stat
‘/tmp/grass7-paulo-18211/tmpcbl2Z1/wx.metadata/docs/html/g.gui.metadata.html’:
No such file or directory
make[1]: *** [install] Error 1
make: *** [installsubdirs] Error 2
WARNING: Installation failed, sorry. Please check above error messages.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] compiling GRASS fails at configure, unable to locate GDAL library

[Paulo van Breugel]

On Thu, Oct 29, 2015 at 12:10 PM, Markus Neteler <nete...@osgeo.org> wrote:

> On Thu, Oct 29, 2015 at 12:03 PM, Paulo van Breugel
> <p.vanbreu...@gmail.com> wrote:
> > On 29-10-15 11:38, Markus Neteler wrote:
> >> This is not recommended - instead use the GDAL-GRASS plugin to
> >> disentangle them properly.
> >
> > Thanks Marcus for the feedback. Yes I did compile GDAL with GRASS
> support,
> > mostly because using the GDAL-GRASS plugin has always been problematic,
>
> ... indeed it is asking for troubles :)
> That's why the plugin was developed.
>

I know that is the idea. However, for me since I started to use GRASS 7 it
has been the other way around for me. Getting things to work with the
plugin has always provided me with much more (unsolvable) trouble than the
admittedly more cumbersome compiling GDAL with GRASS support route. The
last time I gave it a try was about half a year or bit more ago I think, so
perhaps things have improved since.


>
> > something I never have managed to solve, while compiling GDAL with GRASS
> GIS
> > support always have worked without problem for me. But it has been a
> while I
> > tried last, so I will try again, see if it works this time.
>
> Be sure to pick the right version, e.g.
> http://download.osgeo.org/gdal/1.11.3/
> --> gdal-grass-1.11.3.tar.gz
>

And in the meantime I realize what went wrong. It is indeed the kind of
trouble you were referring too. I usually do the following steps to make a
fresh install of GRASS:1) Get a fresh copy of the source files, 2) run
configure, 3) run make, 4) remove the old GRASS program folder in
/usr/local, 5) run make install.

For no particular reason, this time I started by removing the GRASS program
folder. Now, what I didn't realize is that during configuration of GRASS
there is a check whether GDAL is installed properly. It is, except that I
just removed the GRASS program folder. Because GDAL is compiled with GRASS
support, the check for a properly installed GDAL throws an error of GDAL
not finding GRASS.

Keeping the order as outlined above, removing the GRASS folder only just
before running 'make install' works.

I still agree I should try to use the GDAL-GRASS plugin instead of using
GDAL compiled with GRASS support. Will do that when I have a little bit
more time at hand.

Thanks for the feedback Marcus, appreciated.




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

Re: [GRASS-dev] Planning of 7.0.2 release

[Paulo van Breugel]

On 29-10-15 12:00, Markus Neteler wrote:

Hi,

I just saw that r.import and v.import are absent from the menu.
I suggest that they be closest possible to "Common formats import".

Any suggestions for the wording?


Import with on-the-fly reprojection?
or, if it need to be shorter, import with OTF reprojection?



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

[GRASS-dev] compiling GRASS fails at configure, unable to locate GDAL library

[Paulo van Breugel]

Hi, I am trying to make a fresh install of GRASS master, something I do 
routinely about every week (on Ubuntu 14.04). This time however, when 
running .configure (see below), I get the error message that the gdal 
library cannot be found. However, it is there, and in fact nothing 
changed since the last successful install of GRASS. Any ideas?


./configure --prefix=/usr/local/grass7 --enable-64bit 
--with-libs=/lib64 --with-sqlite --with-odbc --with-cairo --with-geos 
--with-cxx=yes --with-gdal=/usr/local/bin/ --with-python=yes 
--with-wxwidgets=/usr/bin/wx-config --with-readline --with-freetype 
--with-freetype-includes=/usr/include/freetype2 --enable-largefile 
--with-motif --with-motif-includes=/usr/include 
--with-proj-share=/usr/share/proj --with-postgres 
--with-postgres-libs=/usr/include/postgresql/libpq 
--with-postgres-includes=/usr/include/postgresql --with-lapack 
--with-blas --with-opencl --with-pthread 



Gives me


checking for gdal-config... /usr/local/bin/gdal-config
configure: error: *** Unable to locate GDAL library.
...
...
...
checking for gdal-config... /usr/local/bin/gdal-config
configure: error: *** Unable to locate GDAL library.



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

Re: [GRASS-dev] compiling GRASS fails at configure, unable to locate GDAL library

[Paulo van Breugel]

On Thu, Oct 29, 2015 at 10:52 AM, Markus Neteler <nete...@osgeo.org> wrote:

> On Thu, Oct 29, 2015 at 10:49 AM, Paulo van Breugel
> <p.vanbreu...@gmail.com> wrote:
> > Hi, I am trying to make a fresh install of GRASS master, something I do
> > routinely about every week (on Ubuntu 14.04).
> ...
> > --with-pthread
>
> (not sure if you want that, see other discussions here)
>

Yes, because of that discussion I had added that to see if it would give
any problem. None that I have noticed by the way. I will probably remove it
though.



>
> ...
> >> checking for gdal-config... /usr/local/bin/gdal-config
> >> configure: error: *** Unable to locate GDAL library.
>
> As usual, check config.log for the problem.
>

I do not really understand the log info, but I guess the below is the
relevant part?

configure:6098:9: warning: ignoring return value of 'GDALOpen', declared
with attribute warn_unused_result [-Wunused-result]
 GDALOpen("foo", GA_ReadOnly);
 ^
/usr/bin/ld: warning: libgrass_vector.so, needed by
/usr/local/gdal/lib/libgdal.so, not found (try using -rpath or -rpath-link)
/usr/bin/ld: warning: libgrass_dig2.so, needed by
/usr/local/gdal/lib/libgdal.so, not found (try using -rpath or -rpath-link)
/usr/bin/ld: warning: libgrass_dgl.so, needed by
/usr/local/gdal/lib/libgdal.so, not found (try using -rpath or -rpath-link)
/usr/bin/ld: warning: libgrass_rtree.so, needed by
/usr/local/gdal/lib/libgdal.so, not found (try using -rpath or -rpath-link)
/usr/bin/ld: warning: libgrass_linkm.so, needed by
/usr/local/gdal/lib/libgdal.so, not found (try using -rpath or -rpath-link)
/usr/bin/ld: warning: libgrass_dbmiclient.so, needed by
/usr/local/gdal/lib/libgdal.so, not found (try using -rpath or -rpath-link)
/usr/bin/ld: warning: libgrass_dbmibase.so, needed by
/usr/local/gdal/lib/libgdal.so, not found (try using -rpath or -rpath-link)
/usr/bin/ld: warning: libgrass_raster.so, needed by
/usr/local/gdal/lib/libgdal.so, not found (try using -rpath or -rpath-link)
/usr/bin/ld: warning: libgrass_imagery.so, needed by
/usr/local/gdal/lib/libgdal.so, not found (try using -rpath or -rpath-link)
/usr/bin/ld: warning: libgrass_gproj.so, needed by
/usr/local/gdal/lib/libgdal.so, not found (try using -rpath or -rpath-link)
/usr/bin/ld: warning: libgrass_gis.so, needed by
/usr/local/gdal/lib/libgdal.so, not found (try using -rpath or -rpath-link)
/usr/bin/ld: warning: libgrass_datetime.so, needed by
/usr/local/gdal/lib/libgdal.so, not found (try using -rpath or -rpath-link)
/usr/local/gdal/lib/libgdal.so: undefined reference to `Rast_map_type'
/usr/local/gdal/lib/libgdal.so: undefined reference to
`Rast_get_fp_color_rule'
...
...
/usr/local/gdal/lib/libgdal.so: undefined reference to
`Vect_new_line_struct'
collect2: error: ld returned 1 exit status
configure: failed program was:
#line 6095 "configure"
#include "confdefs.h"
#include 
int main() {
GDALOpen("foo", GA_ReadOnly);
; return 0; }
configure:6118: gcc -o conftest -g -O2  -I/usr/local/gdal/include
-Wl,--export-dynamic  -L/lib64 conftest.c  -L/usr/local/gdal/lib -lgdal
-lproj -lfreexl -lm -L/usr/lib -lgeos_c -lodbc -lodbcinst -lkmldom
-lkmlbase -lkmlengine -lkmlconvenience -lminizip -luriparser -lexpat
-ljasper -lnetcdf -lhdf5 -lmfhdf -ldf -logdi
-L/usr/local/grass7/grass-7.1.svn/lib -lgrass_vector -lgrass_dig2
-lgrass_dgl -lgrass_rtree -lgrass_linkm -lgrass_dbmiclient -lgrass_dbmibase
-lgrass_raster -lgrass_imagery -lgrass_gproj -lgrass_gmath -lgrass_gis
-lgrass_datetime -L/usr/lib -lpq -lz -lpthread -lm -lrt -ldl -lspatialite
-lsqlite3 -lpcre -L/usr/lib/x86_64-linux-gnu -lcurl -lxml2 1>&5
configure: In function 'main':
configure:6114:9: warning: ignoring return value of 'GDALOpen', declared
with attribute warn_unused_result [-Wunused-result]
 GDALOpen("foo", GA_ReadOnly);
 ^
/usr/bin/ld: cannot find -lgrass_vector
/usr/bin/ld: cannot find -lgrass_dig2
/usr/bin/ld: cannot find -lgrass_dgl
/usr/bin/ld: cannot find -lgrass_rtree
/usr/bin/ld: cannot find -lgrass_linkm
/usr/bin/ld: cannot find -lgrass_dbmiclient
/usr/bin/ld: cannot find -lgrass_dbmibase
/usr/bin/ld: cannot find -lgrass_raster
/usr/bin/ld: cannot find -lgrass_imagery
/usr/bin/ld: cannot find -lgrass_gproj
/usr/bin/ld: cannot find -lgrass_gmath
/usr/bin/ld: cannot find -lgrass_gis
/usr/bin/ld: cannot find -lgrass_datetime
collect2: error: ld returned 1 exit status
configure: failed program was:
#line 6111 "configure"
#include "confdefs.h"
#include 
int main() {
GDALOpen("foo", GA_ReadOnly);
; return 0; }







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

Re: [GRASS-dev] compiling GRASS fails at configure, unable to locate GDAL library

[Paulo van Breugel]

On 29-10-15 11:38, Markus Neteler wrote:

On Thu, Oct 29, 2015 at 11:29 AM, Paulo van Breugel
<p.vanbreu...@gmail.com> wrote:

I do not really understand the log info, but I guess the below is the
relevant part?

configure:6098:9: warning: ignoring return value of 'GDALOpen', declared
with attribute warn_unused_result [-Wunused-result]
  GDALOpen("foo", GA_ReadOnly);
  ^
/usr/bin/ld: warning: libgrass_vector.so, needed by
/usr/local/gdal/lib/libgdal.so, not found (try using -rpath or -rpath-link)

...

/usr/local/gdal/lib/libgdal.so, not found (try using -rpath or -rpath-link)
/usr/local/gdal/lib/libgdal.so: undefined reference to `Rast_map_type'
/usr/local/gdal/lib/libgdal.so: undefined reference to
`Rast_get_fp_color_rule'
...
...
/usr/local/gdal/lib/libgdal.so: undefined reference to
`Vect_new_line_struct'

Did you compile GDAL with GRASS GIS support?

If yes:
This is not recommended - instead use the GDAL-GRASS plugin to
disentangle them properly.
Thanks Marcus for the feedback. Yes I did compile GDAL with GRASS 
support, mostly because using the GDAL-GRASS plugin has always been 
problematic, something I never have managed to solve, while compiling 
GDAL with GRASS GIS support always have worked without problem for me. 
But it has been a while I tried last, so I will try again, see if it 
works this time. Nevertheless, I am not sure I understand why compiling 
GRASS now suddenly doesn't work; as I mentioned, the only thing that has 
changed since the last time I compiled GRASS (about a week ago) is that 
I got a fresh download of the GRASS.





Markus


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

[GRASS-dev] r.quantile not respecting region and mask

[Paulo van Breugel]

Hi,

Am I correct that r.quantile does not use/respect the region and mask? 
In the examples on the manual page (version 7.0 and 7.1) the region is 
first set to the input raster, which implies that the region settings do 
matter. No word on the mask in the manual page. In general, I would 
expect GRASS GIS functions to respect both the region and mask. If they 
do not, it might be a good idea to explicitly mention this in the manual 
page (as in most such cases is done I think)?


Assuming that the above is no bug, would it be possible to add an option 
to have r.quantiles compute the quantiles respecting the region and mask?


Regards,

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

Re: [GRASS-dev] r.quantile not respecting region and mask

[Paulo van Breugel]

On Mon, Nov 9, 2015 at 4:03 PM, Anna Petrášová <kratocha...@gmail.com>
wrote:

>
>
> On Mon, Nov 9, 2015 at 9:11 AM, Paulo van Breugel <p.vanbreu...@gmail.com>
> wrote:
>
>> Hi,
>>
>> Am I correct that r.quantile does not use/respect the region and mask? In
>> the examples on the manual page (version 7.0 and 7.1) the region is first
>> set to the input raster, which implies that the region settings do matter.
>> No word on the mask in the manual page. In general, I would expect GRASS
>> GIS functions to respect both the region and mask. If they do not, it might
>> be a good idea to explicitly mention this in the manual page (as in most
>> such cases is done I think)?
>>
>> Assuming that the above is no bug, would it be possible to add an option
>> to have r.quantiles compute the quantiles respecting the region and mask?
>>
>> Regards,
>>
>> Paulo
>>
>
> Just quick test, but it seems to work for me, setting different region
> changes results, as well setting mask. The actual values looked meaningful.
> Could you provide a test case where it doesn't work?
>


Mmm, I actually can't. Sorry, for wasting your time. Not sure what
happened, but I can't replicate this anymore after a reboot of GRASS.


>
> Anna
>
>
>> ___
>> 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] Python equivalent of piping results from one function to another

[Paulo van Breugel]

On 19-10-15 07:12, Pietro wrote:

Dear Paulo,


On Sun, Oct 18, 2015 at 8:03 PM, Paulo van Breugel
<p.vanbreu...@gmail.com> wrote:

What would be the python equivalent of:

r.category mymap | r.category mymap rules=-

Let's split the problem in two step.

First capture the output of a module (the python equivalent of bash pipe):

{{{

from subprocess import PIPE  # from the standard library import PIPE costant
from grass.pygrass.modules import Module  # import the Module class from pygrass
rcat = Module('r.category', 'landuse', stdout_=PIPE)  # use the spacial 
parameter stdout_
rcat.outputs.stdout   # the stdout is an attribute of the instanced class

'1\tdeveloped\n2\tagriculture\n3\therbaceous\n4\tshrubland\n5\tforest\n6\twater\n7\tsediment\n'

print(rcat.outputs.stdout)

1   developed
2   agriculture
3   herbaceous
4   shrubland
5   forest
6   water
7   sediment
}}}

Second provide a string as stdinput of a module:

{{{

Module('r.category', 'mymap', rules='-', 
stdin_='1\tdeveloped\n2\tagriculture\n3\therbaceous\n4\tshrubland\n5\tforest\n6\twater\n7\tsediment\n')

Module('r.category')
}}}

or to do both things in one line:

{{{
Module('r.category', 'mymap', rules='-', stdin_=Module('r.category',
'landuse', stdout_=PIPE).outputs.stdout)
}}}

You can use a shourtcut to have a cleaner syntax close to bash:

{{{

from grass.pygrass.modules.shortcuts import raster as r
r.category('mymap', rules='-', stdin_=r.category('landuse', 
stdout_=PIPE).outputs.stdout)

Module('r.category')
}}}


Dear Pietro, this is brilliant, thanks a  lot!


There is an example in the documentation using r.colors but it is not
rendered corectly [0]
I tried out the examples on that page, but I couldn't get it all to 
work. For example, there are some examples that use of "stdout_=PIPE" 
and stdin_=PIPE. I though that might be what I was looking for, but 
after trying (and failing) to run the examples I basically do not 
understand what is done there. The solution you describe above is 
actually more easy to intuitively understand. It would be a great 
example to include on the manual page.


About the manual pages, although very detailed, they are sometimes a bit 
hard to understand (perhaps mostly for non-programmers like me), and 
could benefit from worked out examples like you provide above. I would 
not mind providing input, but lack a proper understanding of the code. 
On the other hand, I have had feedback with great examples / 
explanations for two or three times now which I though would be great to 
include in the manual. What is the best place for such feedback / 
suggestions?




Have fun!

Pietro

[0] 
https://grass.osgeo.org/grass71/manuals/libpython/pygrass.modules.interface.html#pygrass.modules.interface.module.Module




I had seen the example, but to be honest even after rereading it isn't 
all clear to me


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

Re: [GRASS-dev] wx.metadata ready for testing

[Paulo van Breugel]

On 06-10-15 11:40, Martin Landa wrote:

Hi,

2015-10-05 10:39 GMT+02:00 Matej Krejci :

  I just checked .grass7/addons/etc/wx.metadata and installation deployed
only /mdlib dir but no /configure and /profiles dirs. It is the same issue
like r.green[1]. Correctly placed directories should looks like:

should be fixed in r66417. Testing welcome. Martin


Hi, just tried to install wx.metadata, using g.extension and by 
compiling directly. As far as I know all dependencies are installed. The 
full output when compiling from source:


make -C mdlib || echo 
/home/paulo/Software/spatial/grass-addons/gui/wxpython/wx.metadata/mdlib >> 
/usr/local/grass7/grass-7.1.svn/error.log

make[1]: Entering directory 
`/home/paulo/Software/spatial/grass-addons/gui/wxpython/wx.metadata/mdlib'

make[1]: Nothing to be done for `first'.

make[1]: Leaving directory 
`/home/paulo/Software/spatial/grass-addons/gui/wxpython/wx.metadata/mdlib'

make -C profiles || echo 
/home/paulo/Software/spatial/grass-addons/gui/wxpython/wx.metadata/profiles >> 
/usr/local/grass7/grass-7.1.svn/error.log

make[1]: Entering directory 
`/home/paulo/Software/spatial/grass-addons/gui/wxpython/wx.metadata/profiles'

make[1]: Nothing to be done for `first'.

make[1]: Leaving directory 
`/home/paulo/Software/spatial/grass-addons/gui/wxpython/wx.metadata/profiles'

make -C config || echo 
/home/paulo/Software/spatial/grass-addons/gui/wxpython/wx.metadata/config >> 
/usr/local/grass7/grass-7.1.svn/error.log

make[1]: Entering directory 
`/home/paulo/Software/spatial/grass-addons/gui/wxpython/wx.metadata/config'

make[1]: Nothing to be done for `first'.

make[1]: Leaving directory 
`/home/paulo/Software/spatial/grass-addons/gui/wxpython/wx.metadata/config'

make -C r.info.iso || echo 
/home/paulo/Software/spatial/grass-addons/gui/wxpython/wx.metadata/r.info.iso 
>> /usr/local/grass7/grass-7.1.svn/error.log

make[1]: Entering directory 
`/home/paulo/Software/spatial/grass-addons/gui/wxpython/wx.metadata/r.info.iso'

GISRC=/usr/local/grass7/grass-7.1.svn/demolocation/.grassrc71 GISBASE=/usr/local/grass7/grass-7.1.svn 
PATH="/usr/local/grass7/grass-7.1.svn/bin:/usr/local/grass7/grass-7.1.svn/bin:/usr/local/grass7/grass-7.1.svn/scripts:$PATH" 
PYTHONPATH="/usr/local/grass7/grass-7.1.svn/etc/python:/usr/local/grass7/grass-7.1.svn/gui/wxpython:$PYTHONPATH" 
LD_LIBRARY_PATH="/usr/local/grass7/grass-7.1.svn/bin:/usr/local/grass7/grass-7.1.svn/scripts:/usr/local/grass7/grass-7.1.svn/lib:/usr/local/grass7/grass-7.1.svn/lib::/lib:/usr/local/lib:/usr/local/gdal/lib"
 LC_ALL=C g.parser -t r.info.iso.py | sed s/\"/\"/g | sed 's/.*/_("&")/' > 
/usr/local/grass7/grass-7.1.svn/locale/scriptstrings/r.info.iso_to_translate.c

/bin/sh: 1: cannot create 
/usr/local/grass7/grass-7.1.svn/locale/scriptstrings/r.info.iso_to_translate.c: 
Directory nonexistent

make[1]: 
[/usr/local/grass7/grass-7.1.svn/locale/scriptstrings/r.info.iso_to_translate.c]
 Error 2 (ignored)

make[1]: Leaving directory 
`/home/paulo/Software/spatial/grass-addons/gui/wxpython/wx.metadata/r.info.iso'

make -C v.info.iso || echo 
/home/paulo/Software/spatial/grass-addons/gui/wxpython/wx.metadata/v.info.iso 
>> /usr/local/grass7/grass-7.1.svn/error.log

make[1]: Entering directory 
`/home/paulo/Software/spatial/grass-addons/gui/wxpython/wx.metadata/v.info.iso'

GISRC=/usr/local/grass7/grass-7.1.svn/demolocation/.grassrc71 GISBASE=/usr/local/grass7/grass-7.1.svn 
PATH="/usr/local/grass7/grass-7.1.svn/bin:/usr/local/grass7/grass-7.1.svn/bin:/usr/local/grass7/grass-7.1.svn/scripts:$PATH" 
PYTHONPATH="/usr/local/grass7/grass-7.1.svn/etc/python:/usr/local/grass7/grass-7.1.svn/gui/wxpython:$PYTHONPATH" 
LD_LIBRARY_PATH="/usr/local/grass7/grass-7.1.svn/bin:/usr/local/grass7/grass-7.1.svn/scripts:/usr/local/grass7/grass-7.1.svn/lib:/usr/local/grass7/grass-7.1.svn/lib::/lib:/usr/local/lib:/usr/local/gdal/lib"
 LC_ALL=C g.parser -t v.info.iso.py | sed s/\"/\"/g | sed 's/.*/_("&")/' > 
/usr/local/grass7/grass-7.1.svn/locale/scriptstrings/v.info.iso_to_translate.c

/bin/sh: 1: cannot create 
/usr/local/grass7/grass-7.1.svn/locale/scriptstrings/v.info.iso_to_translate.c: 
Directory nonexistent

make[1]: 
[/usr/local/grass7/grass-7.1.svn/locale/scriptstrings/v.info.iso_to_translate.c]
 Error 2 (ignored)

make[1]: Leaving directory 
`/home/paulo/Software/spatial/grass-addons/gui/wxpython/wx.metadata/v.info.iso'

make -C t.info.iso || echo 
/home/paulo/Software/spatial/grass-addons/gui/wxpython/wx.metadata/t.info.iso 
>> /usr/local/grass7/grass-7.1.svn/error.log

make[1]: Entering directory 
`/home/paulo/Software/spatial/grass-addons/gui/wxpython/wx.metadata/t.info.iso'

GISRC=/usr/local/grass7/grass-7.1.svn/demolocation/.grassrc71 GISBASE=/usr/local/grass7/grass-7.1.svn 
PATH="/usr/local/grass7/grass-7.1.svn/bin:/usr/local/grass7/grass-7.1.svn/bin:/usr/local/grass7/grass-7.1.svn/scripts:$PATH" 

Re: [GRASS-dev] wx.metadata ready for testing

[Paulo van Breugel]

On 07-10-15 22:29, Martin Landa wrote:

Hi,

2015-10-07 12:30 GMT+02:00 Paulo van Breugel <p.vanbreu...@gmail.com>:

I tried fresh installation (trunk) in installed to /usr/local. I
cannot reproduce any of reported errors. Please send me related
environmental variables:

env | grep GIS

env | grep GRASS


Hi Martin, here they are:

GRASS 7.1.svn (Data_latlon):~ > env | grep GIS

GISRC=/tmp/grass7-paulo-13351/gisrc

GISBASE=/usr/local/grass7/grass-7.1.svn

GIS_LOCK=13351

GRASS 7.1.svn (Data_latlon):~ > env | grep GRASS

GRASS_PYTHON=python

GRASS_GNUPLOT=gnuplot -persist

GRASS_PAGER=more

GRASS_PROJSHARE=/usr/share/proj

GRASS_VERSION=7.1.svn

GRASS_HTML_BROWSER=xdg-open

GRASS_ADDON_BASE=/home/paulo/.grass7/addons

HISTFILE=/media/HD2/Data/GRASSdb/Data_latlon/VECEA_species/.bash_history






?

Ma


ware/spatial/grass-addons/gui/wxpython/wx.metadata/g.gui.metadata

/usr/local/grass7/grass-7.1.svn/error.log

make[1]: Entering directory

`/home/paulo/Software/spatial/grass-addons/gui/wxpython/wx.metadata/g.gui.metadata'

if [ "/usr/local/grass7/grass-7.1.svn/scripts/g.gui.metadata" != "" ] ;
then
GISRC=/usr/local/grass7/grass-7.1.svn/demolocation/.grassrc71
GISBASE=/usr/local/grass7/grass-7.1.svn

PATH="/usr/local/grass7/grass-7.1.svn/bin:/usr/local/grass7/grass-7.1.svn/bin:/usr/local/grass7/grass-7.1.svn/scripts:$PATH"

PYTHONPATH="/usr/local/grass7/grass-7.1.svn/etc/python:/usr/local/grass7/grass-7.1.svn/gui/wxpython:$PYTHONPATH"

LD_LIBRARY_PATH="/usr/local/grass7/grass-7.1.svn/bin:/usr/local/grass7/grass-7.1.svn/scripts:/usr/local/grass7/grass-7.1.svn/lib:/usr/local/grass7/grass-7.1.svn/lib::/lib:/usr/local/lib:/usr/local/gdal/lib"
LC_ALL=C /usr/local/grass7/grass-7.1.svn/scripts/g.gui.metadata
--html-description < /dev/null | grep -v '\|' >
g.gui.metadata.tmp.html ; fi

Traceback (most recent call last):

   File "/usr/local/grass7/grass-7.1.svn/scripts/g.gui.metadata", line
35, in


 import mdgrass

ImportError: No module named mdgrass

make[1]: *** [g.gui.metadata.tmp.html] Error 1

rm g.gui.metadata.tmp.html

make[1]: Leaving directory

`/home/paulo/Software/spatial/grass-addons/gui/wxpython/wx.metadata/g.gui.metadata'






--
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa







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

[GRASS-dev] Python equivalent of piping results from one function to another

[Paulo van Breugel]

What would be the python equivalent of:

r.category mymap | r.category mymap rules=-

I have been looking at the pygrass interface
,
but I didn't understand things well enough to see how to proceed.

Any pointers would be appreciated

Cheers,

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

Re: [GRASS-dev] Grass Data Explorer QGIS Plugin

[Paulo van Breugel]

On 10-10-15 21:59, Markus Neteler wrote:

On Thu, Oct 8, 2015 at 1:04 AM, Sören Gebbert
 wrote:

Dear all,
just for your information:

I have implemented a simple QGIS Plugin to browse and visualize GRASS
GIS raster, vector and time series data in a fast way.

...

The Plugin is available here:
https://bitbucket.org/huhabla/grass-data-explorer/wiki/Home

Congratulations, Soeren! This is a really cool plugin.

I tried it with raster, vector data as well as STRDS from

https://grass.osgeo.org/download/sample-data/
--> GRASS 7 Climatic data time series NC location
nc_climate_spm_2000_2012 (zip, 643MB)

It is incredibly fast!
Tried it as well (with QGIS dev, on Ubuntu 14.04).. works really well, 
also on mapsets with many (large) layers. Great!


Best
Markus
___
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] wx.metadata ready for testing

[Paulo van Breugel]

On Wed, Oct 7, 2015 at 11:48 AM, Martin Landa <landa.mar...@gmail.com>
wrote:

> Hi,
>
> 2015-10-07 10:14 GMT+02:00 Paulo van Breugel <p.vanbreu...@gmail.com>:
> > make -C mdlib || echo
> > /home/paulo/Software/spatial/grass-addons/gui/wxpython/wx.metadata/mdlib
> >>
> > /usr/local/grass7/grass-7.1.svn/error.log
>
> it seems to me that `g.extension` is trying to install addons to
> /usr/local. Are you sure that you are not using `-s` flag or
> GRASS_ADDON_BASE which points to /usr/local/grass7 ... ?
>

Not that I know. Also, all other addons install fine. I tried it again,
after removing the folder .grass7 first (i.e., clean start). Using
g.extention, the output was:

Fetching  from GRASS GIS Addons repository (be patient)...
Compiling...
Traceback (most recent call last):
  File "/tmp/grass7-paulo-27306/tmpqqEFqa/wx.metadata/script
s/db.csw.admin", line 127, in 
from cswutil import *
ImportError: No module named cswutil
make[1]: *** [db.csw.admin.tmp.html] Error 1
Traceback (most recent call last):
  File "/tmp/grass7-paulo-27306/tmpqqEFqa/wx.metadata/script
s/g.gui.cswbrowser", line 22, in 
from cswlib import CSWBrowserPanel, CSWConnectionPanel
ImportError: No module named cswlib
make[1]: *** [g.gui.cswbrowser.tmp.html] Error 1
Traceback (most recent call last):
  File "/tmp/grass7-paulo-27306/tmpqqEFqa/wx.metadata/script
s/g.gui.metadata", line 35, in 
import mdgrass
ImportError: No module named mdgrass
make[1]: *** [g.gui.metadata.tmp.html] Error 1
Installing...
/usr/bin/install: cannot stat ‘/tmp/grass7-paulo-27306/tmp
qqEFqa/wx.metadata/docs/html/db.csw.admin.html’: No such
file or directory
make[1]: *** [install] Error 1
/usr/bin/install: cannot stat ‘/tmp/grass7-paulo-27306/tmp
qqEFqa/wx.metadata/docs/html/g.gui.cswbrowser.html’: No
such file or directory
make[1]: *** [install] Error 1
/usr/bin/install: cannot stat ‘/tmp/grass7-paulo-27306/tmp
qqEFqa/wx.metadata/docs/html/g.gui.metadata.html’: No such
file or directory
make[1]: *** [install] Error 1
make: *** [installsubdirs] Error 2
WARNING: Installation failed, sorry. Please check above error messages.



>
> Martin
>
> >
> > rm g.gui.cswbrowser.tmp.html
> >
> > make[1]: Leaving directory
> >
> `/home/paulo/Software/spatial/grass-addons/gui/wxpython/wx.metadata/g.gui.cswbrowser'
> >
> > make -C g.gui.metadata || echo
> >
> /home/paulo/Software/spatial/grass-addons/gui/wxpython/wx.metadata/g.gui.metadata
> >>> /usr/local/grass7/grass-7.1.svn/error.log
> >
> > make[1]: Entering directory
> >
> `/home/paulo/Software/spatial/grass-addons/gui/wxpython/wx.metadata/g.gui.metadata'
> >
> > if [ "/usr/local/grass7/grass-7.1.svn/scripts/g.gui.metadata" != "" ] ;
> then
> > GISRC=/usr/local/grass7/grass-7.1.svn/demolocation/.grassrc71
> > GISBASE=/usr/local/grass7/grass-7.1.svn
> >
> PATH="/usr/local/grass7/grass-7.1.svn/bin:/usr/local/grass7/grass-7.1.svn/bin:/usr/local/grass7/grass-7.1.svn/scripts:$PATH"
> >
> PYTHONPATH="/usr/local/grass7/grass-7.1.svn/etc/python:/usr/local/grass7/grass-7.1.svn/gui/wxpython:$PYTHONPATH"
> >
> LD_LIBRARY_PATH="/usr/local/grass7/grass-7.1.svn/bin:/usr/local/grass7/grass-7.1.svn/scripts:/usr/local/grass7/grass-7.1.svn/lib:/usr/local/grass7/grass-7.1.svn/lib::/lib:/usr/local/lib:/usr/local/gdal/lib"
> > LC_ALL=C /usr/local/grass7/grass-7.1.svn/scripts/g.gui.metadata
> > --html-description < /dev/null | grep -v '\|' >
> > g.gui.metadata.tmp.html ; fi
> >
> > Traceback (most recent call last):
> >
> >   File "/usr/local/grass7/grass-7.1.svn/scripts/g.gui.metadata", line
> 35, in
> > 
> >
> > import mdgrass
> >
> > ImportError: No module named mdgrass
> >
> > make[1]: *** [g.gui.metadata.tmp.html] Error 1
> >
> > rm g.gui.metadata.tmp.html
> >
> > make[1]: Leaving directory
> >
> `/home/paulo/Software/spatial/grass-addons/gui/wxpython/wx.metadata/g.gui.metadata'
> >
> >
> >
> >>
> >
>
>
>
> --
> Martin Landa
> http://geo.fsv.cvut.cz/gwiki/Landa
> http://gismentors.cz/mentors/landa
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2757: r.import: ERROR: Input raster map is outside current region

[Paulo van Breugel]

On 13-10-15 15:37, Anna Petrášová wrote:



On Tue, Oct 13, 2015 at 9:03 AM, Markus Neteler > wrote:


On Tue, Oct 13, 2015 at 1:07 PM, Moritz Lennert
> wrote:
> The -n flag comes from r.proj and is explained as such in the
r.proj man
> page:

Right.

> "When reprojecting whole-world maps the user should disable
map-trimming
> with the -n flag. Trimming is not useful here because the module
has the
> whole map in memory anyway.

^^^ already here I am lost :-) Trimming is doing what (also
compared to -l)?



I was asking myself the same some time ago. Perhaps this option does not 
need to be hidden, but it would be good to have a positive definition of 
what trimming means (also in the manual page of r.proj)? I would be 
inclined to think that if even Markus does not know what this means, 
many users won't know either ;-)




> Besides that, world "edges" are hard (or
> impossible) to find in projections other than latitude-longitude
so results
> may be odd with trimming."

All quite complicated and contradicting a bit the purpose of r.import.
Can the usage of -n be made automated for r.import and not exposed to
the user?


It can be there by default, but maybe it could be harmful in certain 
cases?


(in case I suggest to hide -n for now for the 7.0.2 release, it can be
introduced later if not avoidable).


It is sort of hidden in the Optional tab, I am not sure if we gain 
much by hiding it completely.



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


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

Re: [GRASS-dev] installing v.mapcalc fails

[Paulo van Breugel]

On 02-10-15 10:50, Moritz Lennert wrote:

On 01/10/15 12:38, Glynn Clements wrote:


Moritz Lennert wrote:


yylex.c:9:27: fatal error: v.mapcalc.tab.h: No such file or directory

#include "v.mapcalc.tab.h"

  ^

compilation terminated.

make: *** [OBJ.x86_64-unknown-linux-gnu/yylex.o] Error 1

ERROR: Compilation failed, sorry. Please check above error messages.


Glynn, can you help us on this ? We need to find the correct Makefile
for the v.mapcalc addon [1]


That header is generated by yacc (or byacc, bison, etc) via a pattern
rule in include/Make/Compile.make:

%.output %.tab.h %.tab.c: %.y
$(YACC) -b$* $(YFLAGS) $<

The problem with v.mapcalc is that it tries to compile yylex.c before
v.mapcalc.tab.h has been generated, which fails. It requires:

-yylex.c: v.mapcalc.tab.h
+$(OBJDIR)/yylex.o: v.mapcalc.tab.h

The header is a dependency of the object file; the source file doesn't
have dependencies (it's a source file, not generated).

Committed in r66392.



Thanks for the fix and the explanation ! It works for me now.


Sorry for the late follow up. The add-on installs now. When trying to 
run it, however, nothing happens. I don't know if it has anything to do 
with the error/warning message I got when installing (below)?


Fetching  from GRASS GIS Addons repository (be patient)...

Compiling...

yylex.c: In function ‘yylex’:

yylex.c:32:7: warning: ignoring return value of ‘scanf’, declared with 
attribute warn_unused_result [-Wunused-result]

  scanf("%lf", );

   ^

Installing...

Updating addons metadata file...

WARNING: No addons metadata available. Addons metadata file not updated.

Installation of  successfully finished


The 'no addons metadata available' is something I see more often, and is 
probably a problem at the server side if I understood well from other 
email treads.






Moritz



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

Re: [GRASS-dev] installing v.mapcalc fails

[Paulo van Breugel]

On Fri, Oct 9, 2015 at 12:30 PM, Markus Neteler <nete...@osgeo.org> wrote:

> On Fri, Oct 9, 2015 at 9:54 AM, Paulo van Breugel
> <p.vanbreu...@gmail.com> wrote:
> ...
> > Sorry for the late follow up. The add-on installs now. When trying to run
> > it, however, nothing happens.
>
> It does not have a parser (yet?), so I suppose it reads from stdin.
>

OK, thanks for the clarification

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

Re: [GRASS-dev] r.resample.rst behavior does not match manual

[Paulo van Breugel]

On Sun, Sep 6, 2015 at 3:26 PM, Markus Neteler  wrote:

> On Mon, Aug 31, 2015 at 1:55 AM, Michael Barton 
> wrote:
> > Thanks for the clarification Stefan.
> >
> > It sounds like, unlike other resampling commands (unless they, too, are
> in
> > error), r.resample.rst needs to be run at the resolution of the original
> > map, not the output map.
>
> Yes. It has been implemented like that (not sure if there is any
> technical reason), yet going a bit against the "normal" workflow.
>

This seems indeed to go totally against the normal work flow. If not for a
technical reason, would it be possible / desirable changing this?


>
> > The output resolution will be determined by the
> > command, not by the region settings. This should go into the manual too,
> > along with the revised text you suggested.
>
> Stefan, Michael, please send a text snipped to me for the manual.
>
> > In a somewhat related question, do you have any idea how
> r.resample.filter
> > works? The manual is not very informative
>
> True - thanks to my long term inbox I found material here
> https://trac.osgeo.org/grass/ticket/1401#comment:8
>
> and merged it into the manual page:
> https://grass.osgeo.org/grass70/manuals/r.resamp.filter.html
> https://grass.osgeo.org/grass71/manuals/r.resamp.filter.html
>
> (please revise as needed).
>
> > and I couldn’t get any useful
> > downscaling results (lower to higher resolution) with my spot tests.
>
> Adding some examples there would be important.
>
> > r.resample.interp doesn’t seem to give expected results either. I’ll do a
> > test with demo data when I have a few minutes this week. I did get very
> good
> > downscaling results with r.resample.bspline, but it took a very long
> time.
>
> Perhaps time to expand
>
> https://grasswiki.osgeo.org/wiki/Interpolation#Resampling_of_raster_maps_to_finer_resolution
> ?
>
> Markus
> ___
> 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] addon mismatch

[Paulo van Breugel]

On 10-09-15 16:29, Markus Neteler wrote:

On Thu, Sep 10, 2015 at 4:15 PM, Vaclav Petras  wrote:

On Thu, Sep 10, 2015 at 10:01 AM, Helmut Kudrnovsky  wrote:

e.g. the addon v.in.gbif

https://trac.osgeo.org/grass/browser/grass-addons/grass7/vector/v.in.gbif

it seems the addon is built ok:

...

but the manual can't be find here:

https://grass.osgeo.org/grass70/manuals/addons/

...

I think it is because it is missing in this Makefile:

...

https://trac.osgeo.org/grass/browser/grass-addons/grass7/vector/Makefile

yes, that's the reason (likewise for others).


I'm not sure if there is a documentation for this. We probably miss, how the
create an addon.

I have started a section here:
https://trac.osgeo.org/grass/wiki/Submitting#GRASSGISAddons


A related / similar issue, I have added an add-on 
https://trac.osgeo.org/grass/browser/grass-addons/grass7/raster/r.biodiversity 
and added it to the parent Make file. I can't recall having done 
anything else then just uploading an add-on in the past, but it is not 
available through g.extension, nor does it show up in the online manual 
pages. From the links mentioned above, I am not clear what else I should 
do, or whether I did something wrong during upload?





Markus
___
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] #2625: r.stats's nsteps is not region-sensitive

[Paulo van Breugel]

On 14-09-15 11:39, GRASS GIS wrote:

#2625: r.stats's nsteps is not region-sensitive
--+-
   Reporter:  martinl  |  Owner:  grass-dev@…
   Type:  defect   | Status:  new
   Priority:  major|  Milestone:  7.0.2
  Component:  Raster   |Version:  svn-trunk
Resolution:   |   Keywords:  r.stats, nsteps
CPU:  Unspecified  |   Platform:  Unspecified
--+-

Comment (by mlennert):

  Replying to [comment:2 martinl]:
  > Any opinion / feedback? Thanks.

  Both region-specific bins and map-specific bins can be useful. The latter
  allow easier comparison between different subregions, whereas the former
  allow getting the number of bins asked for in each subregion.

  So, the ideal solution IMHO would be to have both.
+1 Between the two options, I would prefer it to respect the region 
(following the common approach in GRASS). But I agree that having both 
options would even be better.

In the meantime, the
  fact that bins are calculated on the entire map's value range should be at
  least documented explicitly.


The documentation now says that "analysis uses the current geographic 
region (g.region) and mask settings (r.mask)". So the fact that /nsteps/ 
does not respects this is an exception apparently (and it is an 
exception to the general GRASS GIS approach), which should indeed by 
very clearly documented.


--
Ticket URL: 
GRASS GIS 

___
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] all categories copied over to new map

[Paulo van Breugel]

On 16-09-15 09:49, Moritz Lennert wrote:

On 15/09/15 20:08, Paulo van Breugel wrote:

Suppose I have a categorical raster map and I want to 'cut out' a subset
(with g.region to set a small region and r.mapcalc to create the new
map). This map has a smaller number of categories, as is shown using
e.g., r.category. However, when plotting the legend, all the categories
of the original map are included in the legend. Checking the 'cats' file
shows that it indeed lists all original categories and labels, including
for those categories not present in the new map. This doesn't make sense
to me, but perhaps I am missing something here?


AFAIK, the legend is determined by the color table, and the color 
table is probably just copied as is from the input to the output map. 
You can check with r.colors.out. If you redefine a color table with 
only the relevant categories, then the legend should reflect that.


Hi Moritz, that is what I thought, and as the whole color table does 
indeed get copied over, I wrote a small script to remove the 'redundant 
color definitions. However, that did not help, the whole 'old' legend is 
still showing.  I had missed that -n flag, so I'll give that a try. Is 
there a similar option in ps.map to omit categories without label?


From a more conceptual point of view, is there any reason the whole 
category table is copied over to the new cats file?


You could also try d.legend with the -n flag to only show categories 
which have a label.


Moritz


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

Re: [GRASS-dev] addon mismatch

[Paulo van Breugel]

On 11-09-15 19:31, Vaclav Petras wrote:


On Fri, Sep 11, 2015 at 1:13 PM, Paulo van Breugel 
<p.vanbreu...@gmail.com <mailto:p.vanbreu...@gmail.com>> wrote:



PS: no idea what "WARNING: No addons metadata available. Addons
metadata file not updated." means

No clue either, but maybe the reason it doesn't show in the
g.extension GUI?


Well, I did pretty heavy changes in trunk's g.extension but I was not 
getting this warning. It means that it can't find a particular XML on 
the server. Does this happen for other addons or just r.biodiversity?
It seems not, I just tried to (re) install two others (r.bioclim and 
r.mess) and I did not get such warning
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] addon mismatch

[Paulo van Breugel]

On 11-09-15 19:37, Paulo van Breugel wrote:

On 11-09-15 19:31, Vaclav Petras wrote:


On Fri, Sep 11, 2015 at 1:13 PM, Paulo van Breugel 
<p.vanbreu...@gmail.com> wrote:



PS: no idea what "WARNING: No addons metadata available. Addons
metadata file not updated." means

No clue either, but maybe the reason it doesn't show in the
g.extension GUI?


Well, I did pretty heavy changes in trunk's g.extension but I was not 
getting this warning. It means that it can't find a particular XML on 
the server. Does this happen for other addons or just r.biodiversity?
It seems not, I just tried to (re) install two others (r.bioclim and 
r.mess) and I did not get such warning 
Just to add the note that those are add-ons that are already in the svn 
for some time, while r.biodiversity was just added. Not sure that makes 
a difference? Perhaps the XML file concerned is not renewed / updated?



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

Re: [GRASS-dev] addon mismatch

[Paulo van Breugel]

On 11-09-15 18:56, Markus Neteler wrote:

On Fri, Sep 11, 2015 at 12:48 AM, Paulo van Breugel
<p.vanbreu...@gmail.com> wrote:

A related / similar issue, I have added an add-on
https://trac.osgeo.org/grass/browser/grass-addons/grass7/raster/r.biodiversity
and added it to the parent Make file. I can't recall having done anything
else then just uploading an add-on in the past, but it is not available
through g.extension,

Yes it is!

GRASS 7.1.svn (eu_laea):~ > g.extension r.biodiversity
Fetching  from GRASS GIS Addons repository (be patient)...
Compiling...
Installing...
Updating addons metadata file...
WARNING: No addons metadata available. Addons metadata file not updated.
Installation of  successfully finished
GRASS 7.1.svn (eu_laea):~ >
You are right :-) on the command line it worked. I had only checked 
using the g.extension GUI, where the extension is not shown



Markus

PS: no idea what "WARNING: No addons metadata available. Addons
metadata file not updated." means

No clue either, but maybe the reason it doesn't show in the g.extension GUI?

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

[GRASS-dev] installing v.mapcalc fails

[Paulo van Breugel]

I am trying to install v.mapcalc through g.extension, but I am getting 
the following error message:


Fetching  from GRASS GIS Addons repository (be patient)...

Compiling...

yylex.c:9:27: fatal error: v.mapcalc.tab.h: No such file or

directory

 #include "v.mapcalc.tab.h"

   ^

compilation terminated.

make: *** [OBJ.x86_64-unknown-linux-gnu/yylex.o] Error 1

ERROR: Compilation failed, sorry. Please check above error messages.


Any idea?

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

Re: [GRASS-dev] addon mismatch

[Paulo van Breugel]

On 11-09-15 19:44, Vaclav Petras wrote:



On Fri, Sep 11, 2015 at 1:37 PM, Paulo van Breugel 
<p.vanbreu...@gmail.com <mailto:p.vanbreu...@gmail.com>> wrote:


On 11-09-15 19:31, Vaclav Petras wrote:


On Fri, Sep 11, 2015 at 1:13 PM, Paulo van Breugel
<p.vanbreu...@gmail.com <mailto:p.vanbreu...@gmail.com>> wrote:


PS: no idea what "WARNING: No addons metadata available. Addons
metadata file not updated." means

No clue either, but maybe the reason it doesn't show in the
g.extension GUI?


Well, I did pretty heavy changes in trunk's g.extension but I was
not getting this warning. It means that it can't find a
particular XML on the server. Does this happen for other addons
or just r.biodiversity?

It seems not, I just tried to (re) install two others (r.bioclim
and r.mess) and I did not get such warning


I don't know if the server-side XMLs are generated for 71 or just 70 
but probably they are.


Yes, that is it. When using the 
https://svn.osgeo.org/grass/grass-addons/grass7/ address, things work as 
expected, the addon appears in the list and no error message. Would it 
be possible to make this work for v71 as well?


Then I can also see that the addons page [1] data in the bottom is 
some completely old one (Út srp 18 means Tuesday, August 18). Since it 
is happening just for the new addon, it might be just because of some 
delay in generating all server side things; I always have the feeling 
that there is some delay, although it should be just 24 max.


[1] https://grass.osgeo.org/grass70/manuals/addons/


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

Re: [GRASS-dev] installing v.mapcalc fails

[Paulo van Breugel]

 

On 11 September 2015 15:46:41 CEST, Vaclav Petras <wenzesl...@gmail.com> wrote:
>On Fri, Sep 11, 2015 at 4:56 AM, Paulo van Breugel
><p.vanbreu...@gmail.com>
>wrote:
>
>> I am trying to install v.mapcalc through g.extension, but I am
>getting the
>> following error message:
>>
>> Fetching  from GRASS GIS Addons repository (be patient)...
>>
>
>Have you tried t.vect.algebra module in trunk (7.1)? I'm not sure if it
>works on single vectors but it supports the following operations on a
>single vector: AND, OR, DISJOINT OR, XOR, NOT, buffer_p, buffer_l,
>buffer_a.

I haven't, but I'll have a look. Thanks.

>
>https://grass.osgeo.org/grass71/manuals/t.vect.algebra.html#spatial-vector-operators

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] installing v.mapcalc fails

[Paulo van Breugel]

On 11-09-15 12:31, Moritz Lennert wrote:

On 11/09/15 10:56, Paulo van Breugel wrote:

I am trying to install v.mapcalc through g.extension, but I am getting
the following error message:

Fetching  from GRASS GIS Addons repository (be patient)...

Compiling...

yylex.c:9:27: fatal error: v.mapcalc.tab.h: No such file or

directory

   #include "v.mapcalc.tab.h"

 ^

compilation terminated.

make: *** [OBJ.x86_64-unknown-linux-gnu/yylex.o] Error 1

ERROR: Compilation failed, sorry. Please check above error messages.


Any idea?


Well, the file does not exist. I don't know if it ever did (I can't 
find it in the older versions in trac). Could you just try without 
that include line ?


I only see it mentioned in the make file in the line

.INTERMEDIATE: v.mapcalc.tab.c v.mapcalc.tab.h v.mapcalc.output

I remove it from there?



Moritz


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

[GRASS-dev] all categories copied over to new map

[Paulo van Breugel]

Suppose I have a categorical raster map and I want to 'cut out' a subset 
(with g.region to set a small region and r.mapcalc to create the new 
map). This map has a smaller number of categories, as is shown using 
e.g., r.category. However, when plotting the legend, all the categories 
of the original map are included in the legend. Checking the 'cats' file 
shows that it indeed lists all original categories and labels, including 
for those categories not present in the new map. This doesn't make sense 
to me, but perhaps I am missing something here?


Rgds,

Paulo


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

Re: [GRASS-dev] all categories copied over to new map

[Paulo van Breugel]

On Thu, Sep 17, 2015 at 11:56 AM, Moritz Lennert <
mlenn...@club.worldonline.be> wrote:

> On 16/09/15 10:48, Paulo van Breugel wrote:
>
>>
>>
>> On 16-09-15 09:49, Moritz Lennert wrote:
>>
>>> On 15/09/15 20:08, Paulo van Breugel wrote:
>>>
>>>> Suppose I have a categorical raster map and I want to 'cut out' a subset
>>>> (with g.region to set a small region and r.mapcalc to create the new
>>>> map). This map has a smaller number of categories, as is shown using
>>>> e.g., r.category. However, when plotting the legend, all the categories
>>>> of the original map are included in the legend. Checking the 'cats' file
>>>> shows that it indeed lists all original categories and labels, including
>>>> for those categories not present in the new map. This doesn't make sense
>>>> to me, but perhaps I am missing something here?
>>>>
>>>
>>> AFAIK, the legend is determined by the color table, and the color
>>> table is probably just copied as is from the input to the output map.
>>> You can check with r.colors.out. If you redefine a color table with
>>> only the relevant categories, then the legend should reflect that.
>>>
>>
>> Hi Moritz, that is what I thought, and as the whole color table does
>> indeed get copied over, I wrote a small script to remove the 'redundant
>> color definitions. However, that did not help, the whole 'old' legend is
>> still showing.  I had missed that -n flag, so I'll give that a try. Is
>> there a similar option in ps.map to omit categories without label?
>>
>>   From a more conceptual point of view, is there any reason the whole
>> category table is copied over to the new cats file?
>>
>
> Probably not. IIUC, this only happens when you have a formula of the form
> "new = old".
>
> An easy work around:
>
> r.category new  | r.category new rules=-
>
> The resulting cats file only contains the cats actually present and you
> can thus use d.legend -n to only show those.
>

That is a very neat trick, thanks!

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

Re: [GRASS-dev] addon mismatch

[Paulo van Breugel]

On 12-09-15 13:44, Martin Landa wrote:

Hi,

2015-09-12 7:39 GMT+02:00 Markus Neteler :

If someone tells me where, I can simply add a link on the server.

I don't know why, but addons logs were last time generated on 18/8.
Now I launched jobs manually and I didn't find any problem [1]. Also
r.biodiversity has metadata up-to-date now.

$ g.extension r.biodiversity
Fetching  from GRASS GIS Addons repository (be patient)...
Compiling...
Installing...
Updating addons metadata file...
Installation of  successfully finished

I will investigate why cronjobs are not launched automatically after svn commit.


Thanks for checking and follow up!


Martin

[1] https://grass.osgeo.org/addons/grass7/logs/summary.html



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

[GRASS-dev] installing v.kriging addon fails

[Paulo van Breugel]

Installing v.kriging (on GRASS dev, Linux) addons fails with the following:

GRASS 7.1.svn (latlon):~ > g.extension v.kriging
WARNING: Extension  already installed. Re-installing...
Fetching  from GRASS GIS Addons repository (be patient)...
Compiling...
In file included from geostat.c:1:0:
local_proto.h:72:3: error: unknown type name ‘mat_struct’
   mat_struct *trend;
   ^
local_proto.h:113:3: error: unknown type name ‘mat_struct’
   mat_struct *gamma;// experimental variogram matrix
   ^
local_proto.h:124:3: error: unknown type name ‘mat_struct’
   mat_struct *A;   // plan matrix
   ^
local_proto.h:125:3: error: unknown type name ‘mat_struct’
   mat_struct *T;   // coefficients of theoretical variogram
   ^
local_proto.h:126:3: error: unknown type name ‘mat_struct’
   mat_struct *GM;  // GM = theor_var(dist: input, output points)
   ^
local_proto.h:218:1: error: unknown type name ‘mat_struct’
 mat_struct *LSM(mat_struct *, mat_struct *);
 ^
local_proto.h:218:17: error: unknown type name ‘mat_struct’
 mat_struct *LSM(mat_struct *, mat_struct *);
 ^
local_proto.h:218:31: error: unknown type name ‘mat_struct’
 mat_struct *LSM(mat_struct *, mat_struct *);
   ^
local_proto.h:219:1: error: unknown type name ‘mat_struct’
 mat_struct *nonlin_LMS(int , double *, double *);
 ^
local_proto.h:226:24: error: unknown type name ‘mat_struct’
 double bivar_sill(int, mat_struct *);
^
local_proto.h:245:68: error: unknown type name ‘mat_struct’
 void write2file_variogram_E(struct int_par *, struct parameters *,
mat_struct *);
^
local_proto.h:250:1: error: unknown type name ‘mat_struct’
 mat_struct *set_up_G(struct points *, struct parameters *, struct write *);
 ^
local_proto.h:251:1: error: unknown type name ‘mat_struct’
 mat_struct *set_up_g0(struct int_par *, struct points *, struct ilist *,
double *, struct parameters *);
 ^
local_proto.h:252:1: error: unknown type name ‘mat_struct’
 mat_struct *submatrix(struct ilist *, mat_struct *, struct write *);
 ^
local_proto.h:252:39: error: unknown type name ‘mat_struct’
 mat_struct *submatrix(struct ilist *, mat_struct *, struct write *);
   ^
local_proto.h:253:49: error: unknown type name ‘mat_struct’
 double result(struct points *, struct ilist *,  mat_struct *);
 ^
geostat.c: In function ‘E_variogram’:
geostat.c:101:5: error: unknown type name ‘mat_struct’
 mat_struct *gamma_M;// gamma matrix (hz, vert or bivar)
 ^
geostat.c:102:5: error: unknown type name ‘mat_struct’
 mat_struct *c_M;// matrix of # of dissimilarities
 ^
geostat.c:145:9: warning: assignment makes pointer from integer without a
cast [enabled by default]
 c_M = G_matrix_init(nrows, ncols, nrows);   // temporal matrix of
counts
 ^
geostat.c:146:13: warning: assignment makes pointer from integer without a
cast [enabled by default]
 gamma_M = G_matrix_init(nrows, ncols, nrows);   // temporal matrix
(vector) of gammas
 ^
geostat.c:158:13: error: request for member ‘vals’ in something not a
structure or union
 c = _M->vals[0];
 ^
geostat.c:159:21: error: request for member ‘vals’ in something not a
structure or union
 gamma = _M->vals[0];
 ^
geostat.c:308:21: warning: assignment makes pointer from integer without a
cast [enabled by default]
 var_pars->gamma = G_matrix_copy(gamma_M);
 ^
geostat.c: In function ‘ordinary_kriging’:
geostat.c:516:5: error: unknown type name ‘mat_struct’
 mat_struct *GM;
 ^
geostat.c:517:5: error: unknown type name ‘mat_struct’
 mat_struct *GM_sub; // submatrix of selected points
 ^
geostat.c:518:5: error: unknown type name ‘mat_struct’
 mat_struct *GM_Inv; // inverted GM (GM_sub) matrix
 ^
geostat.c:519:5: error: unknown type name ‘mat_struct’
 mat_struct *g0; // diffences between known and unknown
values = theor_var(dist)
 ^
geostat.c:520:5: error: unknown type name ‘mat_struct’
 mat_struct *w0; // weights of values located on the input
points
 ^
geostat.c:545:17: warning: assignment makes pointer from integer without a
cast [enabled by default]
 var_par->GM = G_matrix_copy(GM);// copy matrix because of cross
validation
 ^
geostat.c:589:28: warning: assignment makes pointer from integer without a
cast [enabled by default]
 GM_sub = submatrix(list, GM, report);   // make
submatrix for selected points
^
geostat.c:590:28: warning: assignment makes pointer from integer without a
cast [enabled by default]
 GM_Inv = G_matrix_inverse(GM_sub);  // invert submatrix
^
geostat.c:594:24: warning: assignment makes pointer 

[GRASS-dev] No addons metadata available.

[Paulo van Breugel]

Hi,

There seems to be a problem again with the addons metadata on the server.
Updating an addon works, but with the following warning:

Updating addons metadata file...
WARNING: Unable to parse 'http://grass.osgeo.org/addons/grass7/modules.xml':
no element found: line 105, column 0
WARNING: No addons metadata available. Addons metadata file not updated.

The g.extension GUI does not fetch the list with addons, which I guess
depends on the same xml file?

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

Re: [GRASS-dev] installing v.mapcalc fails

[Paulo van Breugel]

On 28-09-15 10:48, Markus Neteler wrote:

On Fri, Sep 11, 2015 at 2:40 PM, Moritz Lennert
 wrote:

The following patch seems to do the trick, but I'm not familiar enough with
make to judge whether this is the right solution:

Index: Makefile
===
--- Makefile(révision 66168)
+++ Makefile(copie de travail)
@@ -13,6 +13,8 @@

  default: cmd

+$(OBJDIR)/v.mapcalc.tab.o: v.mapcalc.tab.h
+
  yylex.c: v.mapcalc.tab.h

  .INTERMEDIATE: v.mapcalc.tab.c v.mapcalc.tab.h v.mapcalc.output


For the record: submitted in r66361 (otherwise we'll never figure it out).
Paulo, please test.

Tried to install it using g.extension, but still fails:

GRASS 7.1.svn (latlon):~ > g.extension v.mapcalc

Fetching  from GRASS GIS Addons repository (be patient)...

Compiling...

yylex.c:9:27: fatal error: v.mapcalc.tab.h: No such file or directory

 #include "v.mapcalc.tab.h"

   ^

compilation terminated.

make: *** [OBJ.x86_64-unknown-linux-gnu/yylex.o] Error 1

ERROR: Compilation failed, sorry. Please check above error messages.





Markus


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

[GRASS-dev] Write array to (point) attribute table

[Paulo van Breugel]

This must be a very basic question, but I can't find an easy/direct way to
do this. In python, if I have an array with values with a length equal to
the number of rows in an attribute table of a (point) vector layer, how can
I write those values to a new column in that attribute table. I can of
course first create the column, but than how to update that column with the
values in the array?

Cheers,

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

Re: [GRASS-dev] [GRASS GIS] #2723: error when running v.krige

[Paulo van Breugel]

Hi Markus,

I also took the liberty to make some changes to the page 
https://grasswiki.osgeo.org/wiki/V.krige_GSoC_2009#Installation, to 
include the information that for v.krige in GRASS 7 one needs the R 
package rgrass7 rather than spgrass6/. Hope that is OK.


Paulo



On 30-09-15 23:10, GRASS GIS wrote:

#2723: error when running v.krige
--+-
   Reporter:  pvanbosgeo   |  Owner:  grass-dev@…
   Type:  defect   | Status:  new
   Priority:  normal   |  Milestone:  7.0.1
  Component:  Default  |Version:  svn-trunk
Resolution:   |   Keywords:
CPU:  Unspecified  |   Platform:  Linux
--+-
Changes (by pvanbosgeo):

  * Attachment "v.krige.html.patch" added.

  Corrections, mostly to reflect the change in dependency from spgrass6 to
  rgrass7

--
Ticket URL: 
GRASS GIS 



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

Re: [GRASS-dev] Write array to (point) attribute table

[Paulo van Breugel]

On Wed, Sep 30, 2015 at 11:53 AM, Pietro <peter.z...@gmail.com> wrote:

> On Wed, Sep 30, 2015 at 9:51 AM, Paulo van Breugel
> <p.vanbreu...@gmail.com> wrote:
> >
> >
> > On Wed, Sep 30, 2015 at 2:02 AM, Anna Petrášová <kratocha...@gmail.com>
> > wrote:
> >>
> >>
> >>
> >> On Tue, Sep 29, 2015 at 6:09 PM, Paulo van Breugel
> >> <p.vanbreu...@gmail.com> wrote:
> >>>
> >>> This must be a very basic question, but I can't find an easy/direct way
> >>> to do this. In python, if I have an array with values with a length
> equal to
> >>> the number of rows in an attribute table of a (point) vector layer,
> how can
> >>> I write those values to a new column in that attribute table. I can of
> >>> course first create the column, but than how to update that column
> with the
> >>> values in the array?
> >>
> >>
> >> it should be pretty easy to do with pygrass, unfortunately there is no
> >> example on assigning attributes in the official documentation [1],  but
> it
> >> should be pretty easy, something like that (not tested):
> >>
> >> with VectorTopo('myvector', mode='w') as vectormap:
> >> for feature in vectormap:
> >> feature.attrs['mycolumn'] = value
> >>
> >>
> > Thanks, but that seems to write the vector back without attribute table
>
> You have to save the changes in the database out from your cycle, with:
>
> vectormap.table.conn.commit()
>

Thanks Pietro. I am, however, not sure I understand (I tried to use it, but
thanks to my limited experience in Python / pygrass not much luck). Just to
be more specific, I am trying to create a script that divides points in
training and test groups, similar to v.kcv, but with points clustered in
space. E.g.,

# Create vector
grass.run_command("v.random", output="testB", npoints=10, overwrite=True)
grass.run_command("v.db.addtable", map="testB", columns="X DOUBLE
PRECISION,Y DOUBLE PRECISION,GR INTEGER")
grass.run_command("v.to.db", map="test", option="coor", columns="X,Y")

# Create groups
vectmap = 'test'
cvals = array(grass.vector_db_select(vectmap, layer = int(1), columns =
'X,Y')['values'].values()).astype(np.float)
centroids,_ = kmeans(cvals,2)
idx,_ = vq(cvals,centroids)

# write results to tabel
Now I would like to write idx to the column 'GR' in the attribute table of
'test'.

p.s. I am first creating the XY columns now, but is there a function to get
the coordinates (cvals) in pygrass directly?




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

Re: [GRASS-dev] Write array to (point) attribute table

[Paulo van Breugel]

On 30-09-15 17:52, Paulo van Breugel wrote:



On 30-09-15 17:47, Anna Petrášová wrote:



On Wed, Sep 30, 2015 at 11:20 AM, Paulo van Breugel 
<p.vanbreu...@gmail.com> wrote:




On 30-09-15 16:18, Anna Petrášová wrote:



On Wed, Sep 30, 2015 at 9:27 AM, Paulo van Breugel
<p.vanbreu...@gmail.com <mailto:p.vanbreu...@gmail.com>> wrote:



On Wed, Sep 30, 2015 at 11:53 AM, Pietro
<peter.z...@gmail.com> wrote:

On Wed, Sep 30, 2015 at 9:51 AM, Paulo van Breugel
<p.vanbreu...@gmail.com> wrote:
>
>
> On Wed, Sep 30, 2015 at 2:02 AM, Anna Petrášová
<kratocha...@gmail.com>
> wrote:
>>
>>
        >>
>> On Tue, Sep 29, 2015 at 6:09 PM, Paulo van Breugel
>> <p.vanbreu...@gmail.com> wrote:
>>>
>>> This must be a very basic question, but I can't find
an easy/direct way
>>> to do this. In python, if I have an array with
values with a length equal to
>>> the number of rows in an attribute table of a
(point) vector layer, how can
>>> I write those values to a new column in that
attribute table. I can of
>>> course first create the column, but than how to
update that column with the
>>> values in the array?
>>
>>
>> it should be pretty easy to do with pygrass,
unfortunately there is no
>> example on assigning attributes in the official
documentation [1], but it
>> should be pretty easy, something like that (not tested):
>>
>> with VectorTopo('myvector', mode='w') as vectormap:
>> for feature in vectormap:
>>  feature.attrs['mycolumn'] = value
>>
>>
> Thanks, but that seems to write the vector back
without attribute table

You have to save the changes in the database out from
your cycle, with:

vectormap.table.conn.commit()


Thanks Pietro. I am, however, not sure I understand (I tried
to use it, but thanks to my limited experience in Python /
pygrass not much luck). Just to be more specific, I am
trying to create a script that divides points in training
and test groups, similar to v.kcv, but with points clustered
in space. E.g.,

# Create vector
grass.run_command("v.random", output="testB", npoints=10,
overwrite=True)
grass.run_command("v.db.addtable", map="testB", columns="X
DOUBLE PRECISION,Y DOUBLE PRECISION,GR INTEGER")
grass.run_command("v.to.db", map="test", option="coor",
columns="X,Y")

# Create groups
vectmap = 'test'
cvals = array(grass.vector_db_select(vectmap, layer =
int(1), columns = 'X,Y')['values'].values()).astype(np.float)
centroids,_ = kmeans(cvals,2)
idx,_ = vq(cvals,centroids)

# write results to tabel
Now I would like to write idx to the column 'GR' in the
attribute table of 'test'.

p.s. I am first creating the XY columns now, but is there a
function to get the coordinates (cvals) in pygrass directly?


I don't fully understand the example,


Thanks for the quick response. I basically have a list with
values (idx in the example above) which I like to add as a column
to the attribute table of an existing vector (point layer). The
length of idx is equal to the number of rows in the attribute
table. The solution of Anna seems like an elegant solution (and
easier and more flexible than other solutions I tried using e.g.,
sqlite3). However, as I wrote, I end up with a vector without
attribute table. You wrote that I "have to save the changes in
the database out from your cycle, with:
vectormap.table.conn.commit()". I am, however, not sure what you
mean with 'out from your cycle' or how to implement that.


probably after the for cycle ends you would call this 
'vectormap.table.conn.commit()', if it doesn't works, try to put it 
in the cycle (I am not sure what is supposed to work).


I did try both, with no luck so-far. I'll give it another try though, 
perhaps I did something else wrong.


Tried out again, but after running the code below, I end up with an 
empty vector layer (no points and no attribute table). Same if I put the 
vectormap.table.conn.commit() in the for cycle.


import grass.script as grass

from grass.pygrass.vecto

Re: [GRASS-dev] installing v.kriging addon fails

[Paulo van Breugel]

On 29-09-15 15:46, Anna Petrášová wrote:



On Tue, Sep 29, 2015 at 8:25 AM, Moritz Lennert 
<mlenn...@club.worldonline.be <mailto:mlenn...@club.worldonline.be>> 
wrote:


On 29/09/15 11:09, Paulo van Breugel wrote:

Installing v.kriging (on GRASS dev, Linux) addons fails with
the following:

GRASS 7.1.svn (latlon):~ > g.extension v.kriging
WARNING: Extension  already installed. Re-installing...
Fetching  from GRASS GIS Addons repository (be
patient)...
Compiling...
In file included from geostat.c:1:0:
local_proto.h:72:3: error: unknown type name ‘mat_struct’
mat_struct *trend;
^
local_proto.h:113:3: error: unknown type name ‘mat_struct’
mat_struct *gamma;// experimental variogram matrix
^
local_proto.h:124:3: error: unknown type name ‘mat_struct’
mat_struct *A;   // plan matrix
^
local_proto.h:125:3: error: unknown type name ‘mat_struct’
mat_struct *T;   // coefficients of theoretical
variogram
^
local_proto.h:126:3: error: unknown type name ‘mat_struct’
mat_struct *GM;  // GM = theor_var(dist: input,
output points)
^
local_proto.h:218:1: error: unknown type name ‘mat_struct’
  mat_struct *LSM(mat_struct *, mat_struct *);
  ^
local_proto.h:218:17: error: unknown type name ‘mat_struct’
  mat_struct *LSM(mat_struct *, mat_struct *);
  ^
local_proto.h:218:31: error: unknown type name ‘mat_struct’
  mat_struct *LSM(mat_struct *, mat_struct *);
^
local_proto.h:219:1: error: unknown type name ‘mat_struct’
  mat_struct *nonlin_LMS(int , double *, double *);
  ^
local_proto.h:226:24: error: unknown type name ‘mat_struct’
  double bivar_sill(int, mat_struct *);
 ^
local_proto.h:245:68: error: unknown type name ‘mat_struct’
  void write2file_variogram_E(struct int_par *, struct
parameters *,
mat_struct *);
 ^
local_proto.h:250:1: error: unknown type name ‘mat_struct’
  mat_struct *set_up_G(struct points *, struct parameters *,
struct
write *);
  ^
local_proto.h:251:1: error: unknown type name ‘mat_struct’
  mat_struct *set_up_g0(struct int_par *, struct points *,
struct ilist
*, double *, struct parameters *);
  ^
local_proto.h:252:1: error: unknown type name ‘mat_struct’
  mat_struct *submatrix(struct ilist *, mat_struct *, struct
write *);
  ^
local_proto.h:252:39: error: unknown type name ‘mat_struct’
  mat_struct *submatrix(struct ilist *, mat_struct *, struct
write *);
^
local_proto.h:253:49: error: unknown type name ‘mat_struct’
  double result(struct points *, struct ilist *, mat_struct *);
  ^
geostat.c: In function ‘E_variogram’:
geostat.c:101:5: error: unknown type name ‘mat_struct’
  mat_struct *gamma_M;// gamma matrix (hz, vert or
bivar)
  ^
geostat.c:102:5: error: unknown type name ‘mat_struct’
  mat_struct *c_M;// matrix of # of
dissimilarities
  ^
geostat.c:145:9: warning: assignment makes pointer from
integer without
a cast [enabled by default]
  c_M = G_matrix_init(nrows, ncols, nrows);   // temporal
matrix of
counts
  ^
geostat.c:146:13: warning: assignment makes pointer from
integer without
a cast [enabled by default]
  gamma_M = G_matrix_init(nrows, ncols, nrows);  //
temporal
matrix (vector) of gammas
  ^
geostat.c:158:13: error: request for member ‘vals’ in
something not a
structure or union
  c = _M->vals[0];
  ^
geostat.c:159:21: error: request for member ‘vals’ in
something not a
structure or union
  gamma = _M->vals[0];
  ^
geostat.c:308:21: warning: assignment makes pointer from
integer without
a cast [enabled by default]
  var_pars->gamma = G_matrix_copy(gamma_M);
  ^
geostat.c: In function ‘ordinary_kriging’:
geostat.c:516:5: error: unknown type name ‘mat_struct’
  mat_struct *GM;
  ^
geostat.c:517:5: error: unknown type name ‘mat_struct’
  mat_struct *GM_sub; // submatrix of selected points
 

Re: [GRASS-dev] installing v.kriging addon fails

[Paulo van Breugel]

On 01-10-15 14:36, Markus Neteler wrote:

On Thu, Oct 1, 2015 at 12:51 PM, Paulo van Breugel
<p.vanbreu...@gmail.com> wrote:

I already had GRASS compiled with both blas and lapack, so that doesn't seem
to help in my case (just tried again, still no luck).

You may try to checkout the Addon code from SVN and compile there:

cd grass-addons/grass7/vector/v.kriging/

make MODULE_TOPDIR=/path/to/grass7


Tried it, but no luck:

paulo@paulo-HPZ600:~/Software/spatial/grass-addons/vector/v.kriging$ make 
MODULE_TOPDIR=/usr/local/grass7/grass-7.1.svn

gcc  -g -O2   -I/usr/local/grass7/grass-7.1.svn/include -I/usr/local/grass7/grass-7.1.svn/include   
-I/usr/local/gdal/include -I/usr/include -DPACKAGE=\""grassmods"\"  
-I/usr/include/postgresql -I/usr/local/gdal/include -I/usr/local/grass7/grass-7.1.svn/include 
-I/usr/local/grass7/grass-7.1.svn/include 
-DRELDIR=\"/home/paulo/Software/spatial/grass-addons/vector/v.kriging\" -o 
OBJ.x86_64-unknown-linux-gnu/geostat.o -c geostat.c

In file included from geostat.c:1:0:

local_proto.h:72:3: error: unknown type name ‘mat_struct’

   mat_struct *trend;

   ^

local_proto.h:113:3: error: unknown type name ‘mat_struct’

   mat_struct *gamma;// experimental variogram matrix

   ^

local_proto.h:124:3: error: unknown type name ‘mat_struct’

   mat_struct *A;   // plan matrix

   ^

local_proto.h:125:3: error: unknown type name ‘mat_struct’

   mat_struct *T;   // coefficients of theoretical variogram

   ^

local_proto.h:126:3: error: unknown type name ‘mat_struct’

   mat_struct *GM;  // GM = theor_var(dist: input, output points)

   ^

local_proto.h:218:1: error: unknown type name ‘mat_struct’

 mat_struct *LSM(mat_struct *, mat_struct *);

 ^

local_proto.h:218:17: error: unknown type name ‘mat_struct’

 mat_struct *LSM(mat_struct *, mat_struct *);

 ^

local_proto.h:218:31: error: unknown type name ‘mat_struct’

 mat_struct *LSM(mat_struct *, mat_struct *);

   ^

local_proto.h:219:1: error: unknown type name ‘mat_struct’

 mat_struct *nonlin_LMS(int , double *, double *);

 ^

local_proto.h:226:24: error: unknown type name ‘mat_struct’

 double bivar_sill(int, mat_struct *);

^

local_proto.h:245:68: error: unknown type name ‘mat_struct’

 void write2file_variogram_E(struct int_par *, struct parameters *, mat_struct 
*);

^

local_proto.h:250:1: error: unknown type name ‘mat_struct’

 mat_struct *set_up_G(struct points *, struct parameters *, struct write *);

 ^

local_proto.h:251:1: error: unknown type name ‘mat_struct’

 mat_struct *set_up_g0(struct int_par *, struct points *, struct ilist *, 
double *, struct parameters *);

 ^

local_proto.h:252:1: error: unknown type name ‘mat_struct’

 mat_struct *submatrix(struct ilist *, mat_struct *, struct write *);

 ^

local_proto.h:252:39: error: unknown type name ‘mat_struct’

 mat_struct *submatrix(struct ilist *, mat_struct *, struct write *);

   ^

local_proto.h:253:49: error: unknown type name ‘mat_struct’

 double result(struct points *, struct ilist *,  mat_struct *);

 ^

geostat.c: In function ‘E_variogram’:

geostat.c:101:5: error: unknown type name ‘mat_struct’

 mat_struct *gamma_M;// gamma matrix (hz, vert or bivar)

 ^

geostat.c:102:5: error: unknown type name ‘mat_struct’

 mat_struct *c_M;// matrix of # of dissimilarities

 ^

geostat.c:145:9: warning: assignment makes pointer from integer without a cast 
[enabled by default]

 c_M = G_matrix_init(nrows, ncols, nrows);   // temporal matrix of counts

 ^

geostat.c:146:13: warning: assignment makes pointer from integer without a cast 
[enabled by default]

 gamma_M = G_matrix_init(nrows, ncols, nrows);   // temporal matrix 
(vector) of gammas

 ^

geostat.c:158:13: error: request for member ‘vals’ in something not a structure 
or union

 c = _M->vals[0];

 ^

geostat.c:159:21: error: request for member ‘vals’ in something not a structure 
or union

 gamma = _M->vals[0];

 ^

geostat.c:308:21: warning: assignment makes pointer from integer without a cast 
[enabled by default]

 var_pars->gamma = G_matrix_copy(gamma_M);

 ^

geostat.c: In function ‘ordinary_kriging’:

geostat.c:516:5: error: unknown type name ‘mat_struct’

 mat_struct *GM;

 ^

geostat.c:517:5: error: unknown type name ‘mat_struct’

 mat_struct *GM_sub; // submatrix of selected points

 ^

geostat.c:518:5: error: unknown type name ‘mat_struct’

 mat_struct *GM_Inv; // inverted GM (GM_sub) matrix

 ^

geostat.c:519:5: error: unknown type name ‘mat_struct’

 mat_struct *g0; // diffences between known and unknown val

Re: [GRASS-dev] installing v.kriging addon fails

[Paulo van Breugel]

On 01-10-15 15:35, Vaclav Petras wrote:


On Thu, Oct 1, 2015 at 9:29 AM, Markus Neteler > wrote:

>
> > In file included from geostat.c:1:0:
> >
> > local_proto.h:72:3: error: unknown type name ‘mat_struct’
> >
> >mat_struct *trend;
> >
> >^
>
> ok - next check:
>
>
> cd /where/your/grass/is/lib
>
> ldd libgrass_gmath.so | grep 'blas\|lapack'
>liblapack.so.3 => /lib64/liblapack.so.3 (0x7f640ac4f000)
>libblas.so.3 => /lib64/libblas.so.3 (0x7f640a9f5000)
>
> Is your GMATH lib properly linked to BLAS/LAPACK? Here it is and it 
compiles.


"unknown type name ‘xy’" really looks like that GRASS is not compiled 
with BLAS and LAPACK. I suggest to double check the configuration. You 
can also try to compile i.spec.unmix which always had an explicit 
check for BLAS and LAPACK configuration. (v.kriging compiles for me.)


Did a completely clean install of GRASS, which did the trick.. v.kriging 
compiles now without problems. Thanks.



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

[GRASS-dev] no addons metadata

[Paulo van Breugel]

The same problem as reported earlier is back it seems, no addons 
metadata available. This was a problem for 7.1 I think?


WARNING: Unable to parse

 'http://grass.osgeo.org/addons/grass7/modules.xml': no element

 found: line 105, column 0

WARNING: No addons metadata available. Addons metadata file not updated.

Installation of  successfully finished


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

Re: [GRASS-dev] Write array to (point) attribute table

[Paulo van Breugel]

Hi Michel,

Thanks! I think I got the suggestions by Anna, Pietro and Moritz 
working, but this certainly looks like an handy function to have at 
hand. One possible disadvantage if using this in a script to be shared 
with others is that it would add an dependency on pandas, wouldn't it?


Cheers,

Paulo


On 01-10-15 10:01, Michel Wortmann wrote:

Hi Paulo,
I had the same problem some time ago. I am using pandas for a lot of 
things and discovered the quickest way to append a column to a vector 
table is using pandas' .to_sql dataframe method. Here is my full 
function for it:


import pandas as pa
dataframe = pa.DataFrame( ... )
def appendColumns(vecttbl,dataframe,join=None,layer=1):
 '''Upload a DataFrame (Series should be first converted into a sql 
compliant datafram)
 to a grass vector table. Join is a valid column in vecttbl or if None take 
categories.
 Always joins on df.index, which is not uploaded.'''
 # get sqlite.db info
 db = grass.vector_db(vecttbl)[layer]
 con = sqlite3.connect(db['database'])
 # decide join indeces
 itbl = {False:db['key'],True:join}[join!=None]
 # make series to dataframe
 dataframe.to_sql('pandas_temp',con,if_exists='replace',index_label='ix') # 
index label?
 # join columns to vecttbl
 grass.run_command('v.db.join',map=vecttbl,column=itbl,
other_table='pandas_temp',other_column='ix',
subset_columns=','.join(map(str,dataframe.columns)))
 # remove temp table
 cur = con.cursor()
 cur.execute('DROP TABLE IF EXISTS pandas_temp')
 con.commit(); con.close()
 return

The dataframe.to_sql line is essentially all you need, the rest of the 
function is just prepping.

Hope it helps,
Michel


On 10/01/2015 12:05 AM, Paulo van Breugel wrote:



On 30-09-15 17:52, Paulo van Breugel wrote:



On 30-09-15 17:47, Anna Petrášová wrote:



On Wed, Sep 30, 2015 at 11:20 AM, Paulo van Breugel 
<p.vanbreu...@gmail.com> wrote:




On 30-09-15 16:18, Anna Petrášová wrote:



On Wed, Sep 30, 2015 at 9:27 AM, Paulo van Breugel
<p.vanbreu...@gmail.com <mailto:p.vanbreu...@gmail.com>> wrote:



On Wed, Sep 30, 2015 at 11:53 AM, Pietro
<peter.z...@gmail.com> wrote:

On Wed, Sep 30, 2015 at 9:51 AM, Paulo van Breugel
<p.vanbreu...@gmail.com> wrote:
>
>
> On Wed, Sep 30, 2015 at 2:02 AM, Anna Petrášová
<kratocha...@gmail.com>
> wrote:
>>
>>
        >>
>> On Tue, Sep 29, 2015 at 6:09 PM, Paulo van Breugel
>> <p.vanbreu...@gmail.com> wrote:
>>>
>>> This must be a very basic question, but I can't
find an easy/direct way
>>> to do this. In python, if I have an array with
values with a length equal to
>>> the number of rows in an attribute table of a
(point) vector layer, how can
>>> I write those values to a new column in that
attribute table. I can of
>>> course first create the column, but than how to
update that column with the
>>> values in the array?
>>
>>
>> it should be pretty easy to do with pygrass,
unfortunately there is no
>> example on assigning attributes in the official
documentation [1],  but it
>> should be pretty easy, something like that (not
tested):
>>
>> with VectorTopo('myvector', mode='w') as vectormap:
>> for feature in vectormap:
>>  feature.attrs['mycolumn'] = value
>>
>>
> Thanks, but that seems to write the vector back
without attribute table

You have to save the changes in the database out from
your cycle, with:

vectormap.table.conn.commit()


Thanks Pietro. I am, however, not sure I understand (I
tried to use it, but thanks to my limited experience in
Python / pygrass not much luck). Just to be more specific,
I am trying to create a script that divides points in
training and test groups, similar to v.kcv, but with
points clustered in space. E.g.,

# Create vector
grass.run_command("v.random", output="testB", npoints=10,
overwrite=True)
grass.run_command("v.db.addtable", map="testB", columns="X
DOUBLE PRECISION,Y DOUBLE PRECISION,GR INTEGER")
grass.run_command("v.to.db", map="test", option="coor",
columns="X,Y")

   

Re: [GRASS-dev] Write array to (point) attribute table

[Paulo van Breugel]

On 01-10-15 09:15, Moritz Lennert wrote:

On 01/10/15 00:05, Paulo van Breugel wrote:



On 30-09-15 17:52, Paulo van Breugel wrote:



On 30-09-15 17:47, Anna Petrášová wrote:



On Wed, Sep 30, 2015 at 11:20 AM, Paulo van Breugel
<p.vanbreu...@gmail.com> wrote:



On 30-09-15 16:18, Anna Petrášová wrote:



On Wed, Sep 30, 2015 at 9:27 AM, Paulo van Breugel
<p.vanbreu...@gmail.com <mailto:p.vanbreu...@gmail.com>> wrote:



On Wed, Sep 30, 2015 at 11:53 AM, Pietro
<peter.z...@gmail.com> wrote:

On Wed, Sep 30, 2015 at 9:51 AM, Paulo van Breugel
<p.vanbreu...@gmail.com> wrote:
>
>
> On Wed, Sep 30, 2015 at 2:02 AM, Anna Petrášová
<kratocha...@gmail.com>
> wrote:
>>
>>
        >>
>> On Tue, Sep 29, 2015 at 6:09 PM, Paulo van Breugel
>> <p.vanbreu...@gmail.com> wrote:
>>>
>>> This must be a very basic question, but I can't find
an easy/direct way
>>> to do this. In python, if I have an array with
values with a length equal to
>>> the number of rows in an attribute table of a
(point) vector layer, how can
>>> I write those values to a new column in that
attribute table. I can of
>>> course first create the column, but than how to
update that column with the
>>> values in the array?
>>
>>
>> it should be pretty easy to do with pygrass,
unfortunately there is no
>> example on assigning attributes in the official
documentation [1], but it
>> should be pretty easy, something like that (not 
tested):

>>
>> with VectorTopo('myvector', mode='w') as vectormap:
>> for feature in vectormap:
>>  feature.attrs['mycolumn'] = value
>>
>>
> Thanks, but that seems to write the vector back
without attribute table

You have to save the changes in the database out from
your cycle, with:

vectormap.table.conn.commit()


Thanks Pietro. I am, however, not sure I understand (I tried
to use it, but thanks to my limited experience in Python /
pygrass not much luck). Just to be more specific, I am
trying to create a script that divides points in training
and test groups, similar to v.kcv, but with points clustered
in space. E.g.,

# Create vector
grass.run_command("v.random", output="testB", npoints=10,
overwrite=True)
grass.run_command("v.db.addtable", map="testB", columns="X
DOUBLE PRECISION,Y DOUBLE PRECISION,GR INTEGER")
grass.run_command("v.to.db", map="test", option="coor",
columns="X,Y")

# Create groups
vectmap = 'test'
cvals = array(grass.vector_db_select(vectmap, layer =
int(1), columns = 'X,Y')['values'].values()).astype(np.float)
centroids,_ = kmeans(cvals,2)
idx,_ = vq(cvals,centroids)

# write results to tabel
Now I would like to write idx to the column 'GR' in the
attribute table of 'test'.

p.s. I am first creating the XY columns now, but is there a
function to get the coordinates (cvals) in pygrass directly?


I don't fully understand the example,


Thanks for the quick response. I basically have a list with
values (idx in the example above) which I like to add as a column
to the attribute table of an existing vector (point layer). The
length of idx is equal to the number of rows in the attribute
table. The solution of Anna seems like an elegant solution (and
easier and more flexible than other solutions I tried using e.g.,
sqlite3). However, as I wrote, I end up with a vector without
attribute table. You wrote that I "have to save the changes in
the database out from your cycle, with:
vectormap.table.conn.commit()". I am, however, not sure what you
mean with 'out from your cycle' or how to implement that.


probably after the for cycle ends you would call this
'vectormap.table.conn.commit()', if it doesn't works, try to put it
in the cycle (I am not sure what is supposed to work).


I did try both, with no luck so-far. I'll give it another try though,
perhaps I did something else wrong.


Tried out again, but after running the code below, I end up with an
empty vector layer (no points and no attribute table). Same if I put the
vectormap.table.conn.c

Re: [GRASS-dev] installing v.mapcalc fails

[Paulo van Breugel]

On 29-09-15 14:12, Moritz Lennert wrote:

On 29/09/15 13:14, Markus Neteler wrote:

On Tue, Sep 29, 2015 at 11:11 AM, Paulo van Breugel
<p.vanbreu...@gmail.com> wrote:

On 28-09-15 10:48, Markus Neteler wrote:

...

GRASS 7.1.svn (latlon):~ > g.extension v.mapcalc

Fetching  from GRASS GIS Addons repository (be patient)...

Compiling...

yylex.c:9:27: fatal error: v.mapcalc.tab.h: No such file or directory

  #include "v.mapcalc.tab.h"

^

compilation terminated.

make: *** [OBJ.x86_64-unknown-linux-gnu/yylex.o] Error 1

ERROR: Compilation failed, sorry. Please check above error messages.


Please try r66377.


I still get the same error.


Yes, for me too, still the same error


Moritz


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

Re: [GRASS-dev] Write array to (point) attribute table

[Paulo van Breugel]

On 01-10-15 17:49, Vaclav Petras wrote:


On Thu, Oct 1, 2015 at 11:28 AM, Paulo van Breugel 
<p.vanbreu...@gmail.com <mailto:p.vanbreu...@gmail.com>> wrote:


with VectorTopo('testB', mode='rw') as vectormap:


At the and it makes sense. 'w' removes the vectors and starts over. 
'rw' keep the file but ones it for writing. Perhaps 'a' would make 
better sense in this case. What the documentation says?


On https://grass.osgeo.org/grass70/manuals/libpython/pygrass_vector.html 
it is mentioned that:


"/The open() method supports a number of option arguments (see the Info 
documentation for a complete list). In particular, the mode argument can 
take a a value of r for reading, w for writing, or rw for 
reading/writing." [...] /"/If a vector map is opened with the mode w or 
rw, then the user can write new features to the dataset/".


I think this description is somewhat ambiguous. Especially the mode='w' 
is unclear to me; I could clearly not write new features to an 
(existing) vector layer. It might be nice to have a short one-line 
explanation of each of these options, explaining the difference.




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

Re: [GRASS-dev] Write array to (point) attribute table

[Paulo van Breugel]

On 30-09-15 17:47, Anna Petrášová wrote:



On Wed, Sep 30, 2015 at 11:20 AM, Paulo van Breugel 
<p.vanbreu...@gmail.com <mailto:p.vanbreu...@gmail.com>> wrote:




On 30-09-15 16:18, Anna Petrášová wrote:



On Wed, Sep 30, 2015 at 9:27 AM, Paulo van Breugel
<p.vanbreu...@gmail.com <mailto:p.vanbreu...@gmail.com>> wrote:



On Wed, Sep 30, 2015 at 11:53 AM, Pietro
<peter.z...@gmail.com <mailto:peter.z...@gmail.com>> wrote:

    On Wed, Sep 30, 2015 at 9:51 AM, Paulo van Breugel
<p.vanbreu...@gmail.com <mailto:p.vanbreu...@gmail.com>>
wrote:
>
>
> On Wed, Sep 30, 2015 at 2:02 AM, Anna Petrášová
<kratocha...@gmail.com <mailto:kratocha...@gmail.com>>
> wrote:
>>
        >>
>>
>> On Tue, Sep 29, 2015 at 6:09 PM, Paulo van Breugel
>> <p.vanbreu...@gmail.com
<mailto:p.vanbreu...@gmail.com>> wrote:
>>>
>>> This must be a very basic question, but I can't find
an easy/direct way
>>> to do this. In python, if I have an array with values
with a length equal to
>>> the number of rows in an attribute table of a (point)
vector layer, how can
>>> I write those values to a new column in that
attribute table. I can of
>>> course first create the column, but than how to
update that column with the
>>> values in the array?
>>
>>
>> it should be pretty easy to do with pygrass,
unfortunately there is no
>> example on assigning attributes in the official
documentation [1],  but it
>> should be pretty easy, something like that (not tested):
>>
>> with VectorTopo('myvector', mode='w') as vectormap:
>> for feature in vectormap:
>>  feature.attrs['mycolumn'] = value
>>
>>
> Thanks, but that seems to write the vector back without
attribute table

You have to save the changes in the database out from
your cycle, with:

vectormap.table.conn.commit()


Thanks Pietro. I am, however, not sure I understand (I tried
to use it, but thanks to my limited experience in Python /
pygrass not much luck). Just to be more specific, I am trying
to create a script that divides points in training and test
groups, similar to v.kcv, but with points clustered in space.
E.g.,

# Create vector
grass.run_command("v.random", output="testB", npoints=10,
overwrite=True)
grass.run_command("v.db.addtable", map="testB", columns="X
DOUBLE PRECISION,Y DOUBLE PRECISION,GR INTEGER")
grass.run_command("v.to.db", map="test", option="coor",
columns="X,Y")

# Create groups
vectmap = 'test'
cvals = array(grass.vector_db_select(vectmap, layer = int(1),
columns = 'X,Y')['values'].values()).astype(np.float)
centroids,_ = kmeans(cvals,2)
idx,_ = vq(cvals,centroids)

# write results to tabel
Now I would like to write idx to the column 'GR' in the
attribute table of 'test'.

p.s. I am first creating the XY columns now, but is there a
function to get the coordinates (cvals) in pygrass directly?


I don't fully understand the example,


Thanks for the quick response. I basically have a list with values
(idx in the example above) which I like to add as a column to the
attribute table of an existing vector (point layer). The length of
idx is equal to the number of rows in the attribute table. The
solution of Anna seems like an elegant solution (and easier and
more flexible than other solutions I tried using e.g., sqlite3).
However, as I wrote, I end up with a vector without attribute
table. You wrote that I "have to save the changes in the database
out from your cycle, with: vectormap.table.conn.commit()". I am,
however, not sure what you mean with 'out from your cycle' or how
to implement that.


probably after the for cycle ends you would call this 
'vectormap.table.conn.commit()', if it doesn't works, try to put it in 
the cycle (I am not sure what is supposed to work).


I did try both, with no luck so-far. I'll give it another try though, 
perhaps I did something else wrong.




but yes, you can get coordinates:

with VectorTopo('myvector', mode

Re: [GRASS-dev] Write array to (point) attribute table

[Paulo van Breugel]

On 30-09-15 16:18, Anna Petrášová wrote:



On Wed, Sep 30, 2015 at 9:27 AM, Paulo van Breugel 
<p.vanbreu...@gmail.com <mailto:p.vanbreu...@gmail.com>> wrote:




On Wed, Sep 30, 2015 at 11:53 AM, Pietro <peter.z...@gmail.com
<mailto:peter.z...@gmail.com>> wrote:

On Wed, Sep 30, 2015 at 9:51 AM, Paulo van Breugel
<p.vanbreu...@gmail.com <mailto:p.vanbreu...@gmail.com>> wrote:
>
>
> On Wed, Sep 30, 2015 at 2:02 AM, Anna Petrášová
<kratocha...@gmail.com <mailto:kratocha...@gmail.com>>
> wrote:
>>
    >>
>>
>> On Tue, Sep 29, 2015 at 6:09 PM, Paulo van Breugel
>> <p.vanbreu...@gmail.com <mailto:p.vanbreu...@gmail.com>> wrote:
>>>
>>> This must be a very basic question, but I can't find an
easy/direct way
>>> to do this. In python, if I have an array with values with
a length equal to
>>> the number of rows in an attribute table of a (point)
vector layer, how can
>>> I write those values to a new column in that attribute
table. I can of
>>> course first create the column, but than how to update
that column with the
>>> values in the array?
>>
>>
>> it should be pretty easy to do with pygrass, unfortunately
there is no
>> example on assigning attributes in the official
documentation [1],  but it
>> should be pretty easy, something like that (not tested):
>>
>> with VectorTopo('myvector', mode='w') as vectormap:
>> for feature in vectormap:
>> feature.attrs['mycolumn'] = value
>>
>>
> Thanks, but that seems to write the vector back without
attribute table

You have to save the changes in the database out from your
cycle, with:

vectormap.table.conn.commit()


Thanks Pietro. I am, however, not sure I understand (I tried to
use it, but thanks to my limited experience in Python / pygrass
not much luck). Just to be more specific, I am trying to create a
script that divides points in training and test groups, similar to
v.kcv, but with points clustered in space. E.g.,

# Create vector
grass.run_command("v.random", output="testB", npoints=10,
overwrite=True)
grass.run_command("v.db.addtable", map="testB", columns="X DOUBLE
PRECISION,Y DOUBLE PRECISION,GR INTEGER")
grass.run_command("v.to.db", map="test", option="coor", columns="X,Y")

# Create groups
vectmap = 'test'
cvals = array(grass.vector_db_select(vectmap, layer = int(1),
columns = 'X,Y')['values'].values()).astype(np.float)
centroids,_ = kmeans(cvals,2)
idx,_ = vq(cvals,centroids)

# write results to tabel
Now I would like to write idx to the column 'GR' in the attribute
table of 'test'.

p.s. I am first creating the XY columns now, but is there a
function to get the coordinates (cvals) in pygrass directly?


I don't fully understand the example,


Thanks for the quick response. I basically have a list with values (idx 
in the example above) which I like to add as a column to the attribute 
table of an existing vector (point layer). The length of idx is equal to 
the number of rows in the attribute table. The solution of Anna seems 
like an elegant solution (and easier and more flexible than other 
solutions I tried using e.g., sqlite3). However, as I wrote, I end up 
with a vector without attribute table. You wrote that I "have to save 
the changes in the database out from your cycle, with: 
vectormap.table.conn.commit()". I am, however, not sure what you mean 
with 'out from your cycle' or how to implement that.



but yes, you can get coordinates:

with VectorTopo('myvector', mode='w') as vectormap:
for feature in vectormap:
print feature.x
  print feature.y


Great, thanks. I did not find this in the manual. If it is not there, 
perhaps it would be something worth including? I would not mind 
providing a text, but I am not sure what would be the best way to do that.





Pietro





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