Re: [GRASS-dev] [GRASS-SVN] r66413 - grass-addons/grass7/vector/v.kriging

Vaclav Petras wrote: > I was not able to determine from svn why gmath.h contains la.h. AFAICT, it's because the functions are in lib/gmath. Of course, that then brings up the question why they're there, rather than in a separate library ... Incidentally, the whole of lib/gmath/la.c is

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

Hi Martin, Thanks for your patience. Here is my shell output: GRASS 7.1.svn (ETRS_32N):~/data_maintenance > env | grep GIS GISRC=/tmp/grass7-stefan-19203/gisrc GISBASE=/usr/local/grass-7.1.svn GIS_LOCK=19203 GRASS 7.1.svn (ETRS_32N):~/data_maintenance > env | grep GRASS GRASS_PYTHON=python

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

Hi, 2015-10-07 12:30 GMT+02:00 Paulo van Breugel : 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 ? Ma >

[GRASS-dev] Grass Data Explorer QGIS Plugin

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. It is not designed to run any GRASS GIS processing modules or to create, remove or modify GRASS GIS map layers. The Plugin is

Re: [GRASS-dev] [GRASS GIS] #2419: v.distance: hole considered as nearest area

#2419: v.distance: hole considered as nearest area --+- Reporter: mlennert | Owner: grass-dev@… Type: defect | Status: new Priority: normal | Milestone: 6.4.6 Component: Vector |Version:

Re: [GRASS-dev] v.rast.stats: NULL values for very small areas

2015-10-06 19:26 GMT+03:00 Moritz Lennert : >> I just wonder how to implement within Python script. > > > Get areas of all polygons (or lenghts of lines) with v.to.db and then divide > the features into those with areas above pixel size and those with areas > below.

Re: [GRASS-dev] v.rast.stats: NULL values for very small areas

Hi, What about a flag for checking if all polygon categories are present in the raster version of the vector map, and giving a warning if that is not the case. That will take more time but makes output more reliable. Maybe one can - in case of non-rasterized polygons/lines - edit the raster

Re: [GRASS-dev] v.rast.stats disables MASK

Hi, 2015-10-07 7:05 GMT+02:00 Maris Nartiss : > This definitely needs a flag + explanation in documentation. > > Taking into account philosophy behind GRASS raster processing, I would > say - default should be to apply MASK, as MASK affects all raster > reading operations

Re: [GRASS-dev] GRASS and Mac OS X El Capitan

Michael Barton writes: > But it was never clear what was and was not working. We have this > working fine in Yosemite. So far, you are the only ones to report a > problem with Yosemite. The problem we are reporting now is that it was > running on Yosemite and not running

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

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

Re: [GRASS-dev] [GRASS GIS] #2735: t.rast.mapcalc input problem

#2735: t.rast.mapcalc input problem --+ Reporter: leohardtke | Owner: grass-dev@… Type: defect | Status: reopened Priority: normal | Milestone: 7.0.1 Component: Temporal |Version: svn-trunk

Re: [GRASS-dev] GRASS and Mac OS X El Capitan

After updating, wxpython not working here but tcltk still works (grass 6.4 from kyngchaos), see below for results with 7.1 Launching 'wxpython' GUI in the background, please wait ... Traceback (most recent call last): File "/Applications/GRASS-6.4.app/Contents/MacOS/etc/wxpython/wxgui.py", line

Re: [GRASS-dev] I've tripled GRASS's I/O speed

On Wed, Oct 7, 2015 at 8:45 PM, Seth Price wrote: > I figured it out. I had to `make clean && make && sudo make install` to > get unit tests working as expected. > Makes sense. I should have suggested that. I was doing make distclean automatically out of a habit since the

Re: [GRASS-dev] I've tripled GRASS's I/O speed

I figured it out. I had to `make clean && make && sudo make install` to get unit tests working as expected. I just uploaded a new version of the code that shouldn't fail any additional unit tests, and I've added unit tests to r.compress that test reading/writing the different compression schemes.

Re: [GRASS-dev] [GRASS GIS] #2750: LZ4 when writing raster rows; better than double I/O bound r.mapcalc speed

#2750: LZ4 when writing raster rows; better than double I/O bound r.mapcalc speed --+--- Reporter: sprice | Owner: grass-dev@… Type: enhancement | Status: new Priority: normal | Milestone: 7.1.0 Component:

Re: [GRASS-dev] [GRASS GIS] #2750: LZ4 when writing raster rows; better than double I/O bound r.mapcalc speed

#2750: LZ4 when writing raster rows; better than double I/O bound r.mapcalc speed --+--- Reporter: sprice | Owner: grass-dev@… Type: enhancement | Status: new Priority: normal | Milestone: 7.1.0 Component:

Re: [GRASS-dev] [GRASS GIS] #2750: LZ4 when writing raster rows; better than double I/O bound r.mapcalc speed

#2750: LZ4 when writing raster rows; better than double I/O bound r.mapcalc speed --+--- Reporter: sprice | Owner: grass-dev@… Type: enhancement | Status: new Priority: normal | Milestone: 7.1.0 Component:

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

Hi, 2015-10-07 10:14 GMT+02:00 Paulo van Breugel : > 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

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

On Wed, Oct 7, 2015 at 11:48 AM, Martin Landa wrote: > Hi, > > 2015-10-07 10:14 GMT+02:00 Paulo van Breugel : > > make -C mdlib || echo > > /home/paulo/Software/spatial/grass-addons/gui/wxpython/wx.metadata/mdlib > >> > >

Re: [GRASS-dev] [GRASS GIS] #2734: v.distance: 3d point inside area is classified as outside

#2734: v.distance: 3d point inside area is classified as outside ---+- Reporter: annakrat | Owner: grass-dev@… Type: defect| Status: new Priority: normal| Milestone: 7.0.2 Component: Vector|Version:

Re: [GRASS-dev] v.rast.stats disables MASK

Hi, sorry I jumped so late into this discussion, but I think we can just remove any mask related code in v.rast.stats - it's apparently leftover from https://trac.osgeo.org/grass/changeset/4/ It used mask in the past, but now it uses r.univar zones instead. Anna On Wed, Oct 7, 2015 at 8:47

Re: [GRASS-dev] v.rast.stats disables MASK

+1 Agree. I've run into this before Doug On Wed, Oct 7, 2015 at 1:05 AM, Maris Nartiss wrote: > This definitely needs a flag + explanation in documentation. > > Taking into account philosophy behind GRASS raster processing, I would > say - default should be to apply MASK,

Re: [GRASS-dev] [Qgis-developer] New GRASS plugin: a test drive

On Tue, Oct 6, 2015 at 7:29 AM, Radim Blazek wrote: > On Mon, Oct 5, 2015 at 11:16 PM, Vaclav Petras > wrote: > > > > On Mon, Oct 5, 2015 at 1:16 PM, Radim Blazek > wrote: > >> > >> >> There is v.build.all in modules. > >> >

Re: [GRASS-dev] [GRASS-SVN] r66334 - in grass-addons/grass7: . temporal temporal/t.rast.whatcsv temporal/t.rast.whatcsv/testsuite

On Fri, Sep 25, 2015 at 11:39 AM, wrote: > > Author: neteler > New Revision: 66334 > > Added: >grass-addons/grass7/temporal/t.rast.whatcsv/t.rast.whatcsv.py > > Log: > t.rast.whatcsv Addon: new prototype module by Soeren Gebbert > > +from grass.gunittest.gmodules import

Re: [GRASS-dev] [GRASS-SVN] r66422 - grass/trunk/vector/v.mkgrid

On Tue, Oct 6, 2015 at 10:30 AM, wrote: > > Author: martinl > New Revision: 66422 > > v.mkgrid: finish progress (G_percent) info, be less verbose about progress > > Modified: grass/trunk/vector/v.mkgrid/main.c > > /* Create a grid of label points at the centres of the

Re: [GRASS-dev] [GRASS-SVN] r66422 - grass/trunk/vector/v.mkgrid

Hi, 2015-10-07 17:10 GMT+02:00 Vaclav Petras : > isn't G_verbose_message -> G_message making it in fact more verbose and not > "less verbose" as the commit message says or is my logic completely > confused? no your logic is correct. I just wrote "less" and meant "more" ;-)

Re: [GRASS-dev] GRASS and Mac OS X El Capitan

It is especially good news that GRASS compiles in El Capitan. I cannot use HomeBrew for binaries for distributions, but this means that I should be able to compile it after upgrading. Nonetheless, I’ll do at least one more binary compiled under Yosemite. Michael C. Michael

Re: [GRASS-dev] GRASS and Mac OS X El Capitan

Second error indicates on a misconfigured system. Add to ~/.bash_profile: export LC_ALL=en_US.UTF-8 export LANG=en_US.UTF-8 https://coderwall.com/p/-k_93g/mac-os-x-valueerror-unknown-locale-utf-8-in-python 2015-10-07 11:49 GMT+03:00 Agustin Diez Castillo : > After updating,

Re: [GRASS-dev] GRASS and Mac OS X El Capitan

On Wed, Oct 7, 2015 at 8:17 PM, Maris Nartiss wrote: > Second error indicates on a misconfigured system. > Add to ~/.bash_profile: > export LC_ALL=en_US.UTF-8 > export LANG=en_US.UTF-8 > > https://coderwall.com/p/-k_93g/mac-os-x-valueerror-unknown-locale-utf-8-in-python It

[GRASS-dev] Fwd: [OSGeo-Discuss] [Notice] Email List Maintenance

FYI -- Forwarded message -- From: Alex M Date: Wed, Oct 7, 2015 at 6:32 PM Subject: [OSGeo-Discuss] [Notice] Email List Maintenance To: "disc...@lists.osgeo.org" All of OSGeo email lists and aliases, will be migrated to the

Re: [GRASS-dev] [GRASS-SVN] r66334 - in grass-addons/grass7: . temporal temporal/t.rast.whatcsv temporal/t.rast.whatcsv/testsuite

Hi, 2015-10-07 17:25 GMT+02:00 Vaclav Petras : > > On Fri, Sep 25, 2015 at 11:39 AM, wrote: >> >> Author: neteler >> New Revision: 66334 >> >> Added: >>grass-addons/grass7/temporal/t.rast.whatcsv/t.rast.whatcsv.py >> >> Log: >> t.rast.whatcsv Addon:

Re: [GRASS-dev] [GRASS-SVN] r66334 - in grass-addons/grass7: . temporal temporal/t.rast.whatcsv temporal/t.rast.whatcsv/testsuite

On Wed, Oct 7, 2015 at 1:05 PM, Sören Gebbert wrote: > > > What is the reason for using SimpleModule from gunittest? In gunittest it is > > used to preset defaults which are needed everywhere in the gunittest. If it > > is advantageous perhaps we should move it to