Dear Paulo,
as explained by Vaclav:
"If you change region in C or using ctypes in Python, it is affecting
only the current process." [0].
Therefore the pygrass Region, that it is using C through ctypes, it is
working only on the current process.
"On the hand, if you change region using g.region
On Mon, Feb 16, 2015 at 10:50 PM, Paulo van Breugel
wrote:
> On Sat, Feb 14, 2015 at 7:29 PM, Vaclav Petras wrote:
>> On Sat, Feb 14, 2015 at 11:47 AM, Paulo van Breugel
>> wrote:
>>> For a quick solution, what about using r.tile to split the input data in
>>> tiles and compute the mahalanobis d
On Sat, Feb 14, 2015 at 7:29 PM, Vaclav Petras 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 PyGR
On Mon, Feb 16, 2015 at 3:54 PM, Martin Landa
wrote:
> Hi, are you planing to backport it to relbr70?
I guess I could do that right away in this case. Just out of habit, I'm not
backporting things immediately after commit.
> BTW, I was always
> thinking about moving scripts which are duplicat
Hi, are you planing to backport it to relbr70? BTW, I was always
thinking about moving scripts which are duplicated in various branches
to one common place. Martin
2015-02-16 21:05 GMT+01:00 :
> Author: wenzeslaus
> Date: 2015-02-16 12:05:05 -0800 (Mon, 16 Feb 2015)
> New Revision: 64658
>
> Modi
#2583: v.net: crash on Windows
-+--
Reporter: mlennert | Owner: grass-dev@…
Type: defect | Status: new
Priority: blocker | Milestone: 7.0.0
I am trying to repeatedly change the region in a script. To get the current
region I would normally use
>>>reg1 = grass.script.region()
When using pygrass, I can also use
>>>import grass.pygrass.gis.region as region
>>>reg2 = region.Region()
The first time I run this reg1 = reg2
Now, when I ch
Hi all,
when running the tests on MS Windows doctest for grass.temporal does not
continue when fatal error was issued by libgis server. stderr ends with:
C:\...\grass_trunk_r64651\lib\python\temporal\testsuite>python
test_doctests.py
Default TGIS driver / database set to:
driv
#2583: v.net: crash on Windows
-+--
Reporter: mlennert | Owner: grass-dev@…
Type: defect | Status: new
Priority: blocker | Milestone: 7.0.0
#1982: v.rast.stats: running generates "Unable to fetch interface description
for
command" error
--+-
Reporter: neteler | Owner: grass-dev@…
Type: defect | Status: closed
#2583: v.net: crash on Windows
-+--
Reporter: mlennert | Owner: grass-dev@…
Type: defect | Status: new
Priority: blocker | Milestone: 7.0.0
Hi Martin,
On Mon, Feb 16, 2015 at 3:20 PM, Martin Landa wrote:
> Hi,
>
> 2015-02-16 14:36 GMT+01:00 :
>> Author: zarch
>> Date: 2015-02-16 05:36:51 -0800 (Mon, 16 Feb 2015)
>> New Revision: 64649
>>
>> Modified:
>>
>> grass-addons/grass7/raster/r.green/r.green.biomassfor/r.green.biomassfor.
Hi Martin,
> I have added py extension in `rules` file [1] and requested for the
> new build. Should be available in 10min.
Thanks for the fix.
It already percolated into the ubuntu package grass70
Version: 7.0.0+1svn64634~ubuntu14.04.1
g.extension fails now because it can not find the html m
Tests are back at 85% and the number of tests is growing [1], please keep
it that way.
http://fatra.cnr.ncsu.edu/grassgistests/summary_report/nc/info_plot.png
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gr
2015-02-16 15:20 GMT+01:00 Martin Landa :
> why so much nested? The right naming should be
> grass-addons/grass7/raster/r.green/r.green.biomassfor/Makefile
or just grass-addons/grass7/raster/r.green.biomassfor if there is no
common lib for r.green modules. Please make life for g.extension
easier ;
Hi,
2015-02-16 14:36 GMT+01:00 :
> Author: zarch
> Date: 2015-02-16 05:36:51 -0800 (Mon, 16 Feb 2015)
> New Revision: 64649
>
> Modified:
>
> grass-addons/grass7/raster/r.green/r.green.biomassfor/r.green.biomassfor.economic/Makefile
why so much nested? The right naming should be
grass-addons
That would be great, I would like to learn and help doing that!
El 16/02/2015 12:07, "Paulo van Breugel" escribió:
> 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
#2583: v.net: crash on Windows
-+--
Reporter: mlennert | Owner: grass-dev@…
Type: defect | Status: new
Priority: blocker | Milestone: 7.0.0
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 (o
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 lar
On Thu, Feb 12, 2015 at 12:26 AM, Markus Neteler wrote:
> Hi devs,
>
> according to our
> http://trac.osgeo.org/grass/wiki/RFC/4_ReleaseProcedure
>
> the final release is due on 15th of February.
>
> Please check/update
> http://trac.osgeo.org/grass/wiki/Grass7Planning#Planningongoing
Due to the
21 matches
Mail list logo
