, only region for
subprocesses is changed but library functions are not affected. So, g.region
will affect pygrass.modules.Module but not pygrass.raster, pygrass.vector
and others. [1]
I hope this make the things clearer.
Best regards
Pietro
[0] https://lists.osgeo.org/pipermail/grass-dev/2014
graphs.
http://dask.readthedocs.org/en/latest/array.html
I didn't have a chance to try it yet, but it support a numpy array
syntax, and since you are using quite basic functionalities I think
you should be able to work with it.
All the best
Pietro
On Thu, Feb 5, 2015 at 2:48 PM, Markus Neteler nete...@osgeo.org wrote:
Hi Pietro,
(back to an older email)
On Tue, Dec 10, 2013 at 11:38 PM, Pietro Zambelli peter.z...@gmail.com
wrote:
On Sunday 08 Dec 2013 23:51:22 you wrote:
It might be nice to define a threshold for large maps
Hi Martin,
On Sat, Jan 31, 2015 at 12:10 PM, Martin Landa landa.mar...@gmail.com wrote:
Hi,
2015-01-31 11:16 GMT+01:00 Pietro peter.z...@gmail.com:
Yes, here an example, write a new map:
btw, are these examples collected somewhere (on the wiki)? Thanks! Martin
I collected some training
:', census.number_of('areas'))
...for area in census.viter('areas'):
...if area.area()400:
...print(area.id, area.area())
}}}
All the best
Pietro
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo
))
...
}}}
and read again the modified map:
{{{
with VectorTopo('mypoits', mode='r') as my:
...for p in my:
...print(p)
...
POINT(0.00 10.00)
POINT(5.00 15.00)
POINT(10.00 10.00)
POINT(15.00 15.00)
}}}
All the best
Pietro
Hi Vaclav,
On Sat, Jan 24, 2015 at 4:48 PM, Vaclav Petras wenzesl...@gmail.com wrote:
it seems that r64226 broke a PyGRASS module interface parsing
Thanks to report this, should be fix in r64295, or at least tests are
now passing on my computer.
All the best
Pietro
you so much Anna for the quick fix!
Pietro
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Dear devs,
when I'm using g.remove (gui), If I select to remove a raster map the
menu (name) does not work, instead if I select vector works without
problems...
I'm using grass7 (r64189), do you have the same problem?
Best regards
Pietro
___
grass
On Wed, Jan 14, 2015 at 3:59 PM, Vaclav Petras wenzesl...@gmail.com wrote:
Can this have a description? I'm not sure where we would show it but it
might be useful.
I did a naive mockup showing two options with OR relationship.
However, I'm against introducing some general inter-option
info,
?
Best regards
Pietro
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
On Wed, Jan 14, 2015 at 10:19 AM, Nikos Alexandris
n...@nikosalexandris.net wrote:
this thread
http://lists.osgeo.org/pipermail/grass-dev/2014-November/071908.html is
of interest, I guess, as well.
Thanks Nikos, I've missed this thread! It is really interesting
perhaps should be possible to
On Wed, Jan 14, 2015 at 10:33 AM, Moritz Lennert
mlenn...@club.worldonline.be wrote:
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?
If you add
#% label
and
#% description
value and user don't
have to rely on the manual for every single option. The basic info are
provided in the GUI and you can find these and further
details/material in the manual, e.g. examples, images, etc.
Best regards
Pietro
___
grass-dev mailing list
this morning. Should be fixed in r63972.
Pietro
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
such a shrinking?
r.slope.aspect compute the first derivative (1 pixel less) and depends
on the outputs that are selected the second derivative (2 pixels
less), this is not a bug.
Have a nice Sunday.
Pietro
___
grass-dev mailing list
grass-dev
|
| Database:/home/pietro/docdat/gis/ |
| Title: NC State University bus service Wolfline route 6 (lines m |
| Map scale: 1:1 |
| Name of creator: helena
[:]
new.put_row(newrow)
}}}
Any concern on this?
Best regards
Pietro
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
on it...
Best regards
Pietro
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
in the
function that should emit a debug message.
{{{
from grass.pygrass.messages import get_msgr
get_msgr().debug(1, self.get_bash())
}}}
What do you think?
Pietro do you have any objections ... or does my approach does not
solve the problem?
No objections from my side.
I'm going to remove
, this point...
Why the decorator must_be_open it seems to work so far?
which is the difference between @must_be_open[0] and @mdebug[1]?
Any Ideas?
Pietro
[0] http://trac.osgeo.org/grass/browser/grass/trunk/lib/python/pygrass/errors.py
[1]
http://trac.osgeo.org/grass/browser/grass/trunk/lib/python
On Mon, Nov 17, 2014 at 11:32 AM, Markus Metz
markus.metz.gisw...@gmail.com wrote:
BTW, the test suite does not run with Python 2.6 because import
argparse fails, this module is new in Python 2.7.
but can be installed:
https://pypi.python.org/pypi/argparse
Best regards
Pietro
On Tue, Nov 11, 2014 at 11:32 PM, Vaclav Petras wenzesl...@gmail.com wrote:
Maybe it can go to GRASS GIS 7.0.1 but not to 7.0.0.
Personally I think we should include the gunittest to grass 7.0.0.
It is just an extra functionality that does not affect GRASS
modules/GUI/libraries in any way.
So
/2014-October/071126.html
Good night
Pietro
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
On Thu, Oct 30, 2014 at 10:49 AM, Markus Neteler wrote:
On Thu, Oct 30, 2014 at 8:40 AM, Glynn Clements wrote:
Are the replacements sufficient? g.setproj had a lot of logic for
dealing with the relationships between various parameters. Has that
been incorporated into the GUI? Is it
grass.script.core as gscore
+1
Pietro
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Hi,
On Sun, Oct 26, 2014 at 9:50 PM, Markus Neteler nete...@osgeo.org wrote:
On Sun, Oct 26, 2014 at 9:05 PM, Martin Landa landa.mar...@gmail.com wrote:
2014-10-26 17:51 GMT+01:00 Markus Neteler nete...@osgeo.org:
-the python API back port
it seems to be done by Pietro in r62382. Martin
.
hm, Soeren/Pietro any idea why it fails? Thanks, Martin
yes I think it fails because has broken the pickability of the
Module instance.
It should be fix in r62374.
However, I would like to revert your change... :-)
Introduce the debug message in the Module class it is a bad idea
because
Hi,
On Fri, Oct 24, 2014 at 12:56 PM, Sören Gebbert
soerengebb...@googlemail.com wrote:
However, I would like to revert your change... :-)
Introduce the debug message in the Module class it is a bad idea
because in this way also Module class is indirectly using ctypes.
Therefore all the
On Fri, Oct 24, 2014 at 1:05 PM, Martin Landa landa.mar...@gmail.com wrote:
2014-10-24 12:04 GMT+02:00 Pietro peter.z...@gmail.com:
However, I would like to revert your change... :-)
Introduce the debug message in the Module class it is a bad idea
because in this way also Module class
On Wed, Oct 22, 2014 at 10:49 AM, Martin Landa landa.mar...@gmail.com wrote:
Hi,
it's seems that currently PyGRASS doesn't support shorten parameters, eg.
Module('v.db.addcolumn', map='p5', col='vymera_ha double')
[cut]
grass.pygrass.errors.ParameterError: col is not a valid parameter.
On Wed, Oct 22, 2014 at 11:12 AM, Martin Landa landa.mar...@gmail.com wrote:
there is also another issue where pyGRASS seems to be too much strict, eg.
Module('d.vect', map='p6', type='point', color='purple',
icon='basic/star', size=10)
fails with
File ./u01.py, line 37, in compute
On Wed, Oct 22, 2014 at 5:40 PM, Martin Landa landa.mar...@gmail.com wrote:
2014-10-22 17:36 GMT+02:00 Pietro peter.z...@gmail.com:
Any chance to change this behaviour?
Actually I don't like the idea of shorten parameters... :-)
So I wont fix this.
well, pyGRASS should behave similarly
On Wed, Oct 22, 2014 at 5:45 PM, Martin Landa landa.mar...@gmail.com wrote:
This is fixed in grass71, should be backported.
are you planning to to this? Martin
Yes, I would like to do it...
The main problem are the difference between grass70 and grass71 on the
exception...
I would like to
On Wed, Oct 8, 2014 at 12:38 PM, Glynn Clements
gl...@gclements.plus.com wrote:
do you think could be useful?
Not really. Just use r.info (or r.univar if you want the min/max for
the current region) and substitute the result into the expression.
Yes, I did in this way.
Thank you.
Pietro
On Wed, Oct 8, 2014 at 11:24 AM, Glynn Clements
gl...@gclements.plus.com wrote:
Pietro wrote:
So even if I'm explicitly casting the result in the scaler function
with dtype(...), the result is not properly casted, do you have an
idea on how could I solve this problem?
This is a bug
if it is a good idea to make pygrass a dependency of
the GUI.
I'm not able to reproduce the problem, what kind of error did you get?
Any way I will work in the __init__ file to isolate the ctypes stuff.
All the best
Pietro
___
grass-dev mailing list
grass
++
| Map: el Date: Mon Oct 6 10:29:19 2014|
| Mapset: user1 Login of Creator: pietro |
| Location: nc_basic_spm_grass7 |
| DataBase: /home/pietro/docdat/gis
casting the result in the scaler function
with dtype(...), the result is not properly casted, do you have an
idea on how could I solve this problem?
All the best
Pietro
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman
On Mon, Oct 6, 2014 at 2:25 PM, Anna Petrášová kratocha...@gmail.com wrote:
On Mon, Oct 6, 2014 at 4:51 AM, Pietro peter.z...@gmail.com wrote:
Again everything is NULL, I'm doing something wrong or it is a bug?
Glynn could perhaps give you some more precise comment, but basically, max
On Mon, Oct 6, 2014 at 3:17 PM, Moritz Lennert
mlenn...@club.worldonline.be wrote:
On 06/10/14 14:54, Pietro wrote:
Trying to circumvent the r.mapcalc min/max limit,
Just out of curiosity: why don't you just use r.recode or r.rescale ?
r.rescale was my first option, but it just reclassify
Il 06/ott/2014 17:04 Moritz Lennert mlenn...@club.worldonline.be ha
scritto:
On 06/10/14 16:14, Pietro wrote:
On Mon, Oct 6, 2014 at 3:17 PM, Moritz Lennert
mlenn...@club.worldonline.be wrote:
On 06/10/14 14:54, Pietro wrote:
Trying to circumvent the r.mapcalc min/max limit,
Just out
to test
the existing libraries, and I#m not able to understand where the
problem.is.
Best regards
Pietro
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Hi Sören,
On Sat, Sep 27, 2014 at 3:23 PM, Sören Gebbert
soerengebb...@googlemail.com wrote:
I would like to directly link to the source code
docs, hence referencing temporal framework Python functions and
classes in this document. But i don't know how? Are there any code
examples howto link
Il 14/set/2014 19:33 Markus Neteler nete...@osgeo.org ha scritto:
how will this be solved? Then we could start backporting python lib etc
to relbr7.
I will fix this tomorrow...
Pietro
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http
programming in python? are you using
a shell or the gui?
I suspect that is missing grass, the following line is working on my pc:
from grass.pygrass.modules.shortcuts import raster as r
Pietro
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http
import raster as r
from grass.pygrass.modules.shortcuts import imagery as i
I believe that you are using grass6.*, and unfortunately the pygrass
modules is available only on grass7.*
Let me know.
Pietro
___
grass-dev mailing list
grass-dev@lists.osgeo.org
]: Module('r.mapcalc')
}}}
but I think is less intuitive, do you see any other solutions?
Kind regards
Pietro
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
a vector map, created
some months ago, the g.gui.iclass crashed (without errors...).
I'm working on grass trunk on Linux.
It is working for you?
Best regards.
Pietro
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman
any effect.
I found the same thing some months ago:
https://lists.osgeo.org/pipermail/grass-dev/2014-February/067543.html
as explained by Vaclav:
If you change region in C or using ctypes in Python, it is affecting
only the current process.
best regards
Pietro
, otherwise please ask me! :-)
Pietro
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Hi Vaclav,
On Mon, Jul 7, 2014 at 2:57 PM, Vaclav Petras wenzesl...@gmail.com wrote:
On Thu, Jul 3, 2014 at 11:35 AM, Pietro peter.z...@gmail.com wrote:
What do you think if we unify all our custom exceptions in one common
file? [snip]
Looking into the code I found the following custom
On Fri, Jul 4, 2014 at 8:53 AM, Luca Delucchi lucadel...@gmail.com wrote:
On 3 July 2014 17:35, Pietro peter.z...@gmail.com wrote:
What do you think if we unify all our custom exceptions in one common file?
Just to avoid code repetitions and help consistency.
Perhaps we could create a new
in grass.script.errors or
grass.script.exceptions, or outside script so something like
grass.errors or grass.exceptions.
Do you think it is a bad idea?
Best regards
Pietro
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass
, in module
m.inputs['elevation'] = elevation
File
/home/pietro/docdat/src/gis/grass71/dist.x86_64-unknown-linux-gnu/etc/python/grass/pygrass/modules/interface/typedict.py,
line 40, in __setitem__
raise TypeError(str_err % (value, self._type.__name__))
TypeError: The value: 'elevation
a Parameter instance.
Se the method that is called when you are trying to set an item to a
TypeDict is __setitem__.
I hope it makes sense.
Best regards
Pietro
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass
and wxGUI.
The compilation failures in temporal are a consequence of
lib/python/pygrass/gis/__init__.py calling grass.script.gisenv() at
the top level, which it shouldn't be doing.
Thanks to pointed out this! It was my fault sorry for that.
Removed in r60909
Pietro
Hi Yann,
On Fri, Jun 20, 2014 at 7:21 AM, Yann Chemin yche...@gmail.com wrote:
line 86, in __init__
self.typedesc = diz['gisprompt']['prompt']
KeyError: u'prompt'
Thanks to find out this bug, should be fix in r60881.
Let me know.
Pietro
/ wxguiclean
make[1]: Entering directory
'/home/pietro/docdat/src/gis/grass71/gui/wxpython/docs/wxgui_sphinx'
rm -rf _build/*
rm -f _templates/layout.html
make[1]: Leaving directory
'/home/pietro/docdat/src/gis/grass71/gui/wxpython/docs/wxgui_sphinx'
make -C ./gui/wxpython/docs/wxgui_sphinx/ wxguiapidoc
On Fri, Jun 13, 2014 at 1:59 PM, Pietro peter.z...@gmail.com wrote:
I'm trying to build the docs with: make sphinxdoc , I think the
problem is that on my system the default python interpreter is
python3
Solved using the follow command:
{{{
$ make SPHINXBUILD=sphinx-build2 sphinxdoc
Hi Glynn,
On Tue, Jun 3, 2014 at 8:55 AM, Martin Landa landa.mar...@gmail.com wrote:
Reminder for all Windows users, please note that winGRASS 7.1 no.981
will be broken (calling python script from python script issue - eg.
wxGUI Extension manager) again.
2014-06-03 7:24 GMT+02:00
',
u'build_polylines',
u'category',
...
u'what_rast',
u'what_rast3',
u'what_vect']
Someone has a deeper understanding on how the auto-complete works on
ipython/GRASS shell, Do you have any idea on where could be the
problem and how we could fix it?
Thanks
Pietro
[0]
http://trac.osgeo.org/grass
Dear dev,
I would like to know just a quick info that seems to be missing in the
r.watershed manual...
Are the basin or the stream number sorted hierarchically? from the
main to the smaller stream?
Pietro
___
grass-dev mailing list
grass-dev
for user scripts,
but in wxGUI I still prefer to use GRASS Scripting Library to call
GRASS commands on the background.
+1, or using pygrass through Soeren's RPC interface.
Pietro
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http
be much clearer...
Pietro
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
that using Sphinx and reStructuredText for Python will be beneficial.
Sphinx has support for python/C/C++/javascript [0].
May be we could reconsider [1] to move everything under sphinx.
But I'm not sure it is feasible.
Best regards
Pietro
[0] http://sphinx-doc.org/domains.html
[1] https
these parts separately, leaving
the decision to split in several packages to the package maintainer of
each distribution (Debian, Fedora, etc.).
Regards
Pietro
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
to set to nan some values, so I think is
a bug in the RasterNumpy class, the weird thing is that it seems to
work for the first two lines...
I have no time to work on it at the moment.
Best regards
Pietro
___
grass-dev mailing list
grass-dev
. does the file
C:\Users\Pietro\Desktop\GRASS_FILE\ncb7\user1\WIND
exist?
yes, it exists, and I can use GRASS inside this mapset without problems.
Pietro
#print(sys.executable)
C:\Program Files (x86)\GRASS GIS 7.0.svn\extrabin\python.exe
#pprint(script.region())
{}
#pprint(os.environ
out as a tiff file instead to avoid this problem?
Why not using r.out.tiff [1]?
Thank you for testing.
Pietro
[0] http://trac.osgeo.org/grass/changeset/59192
[1] http://grass.osgeo.org/grass70/manuals/r.out.tiff.html
___
grass-dev mailing list
grass
Hi Javier,
On Tue, Mar 4, 2014 at 5:26 PM, Javier Martínez-López
javi.martinez.lo...@gmail.com wrote:
Thank you Pietro! I will try again! However, there seems to be a bug
(at least in version 59147) since I am getting NaN values reading some
maps with RasterNumpy, which are perfectly fine when
chars in people’s names though.
I don’t see the reason to avoid source code in utf-8, at least on
python files, in particular when it is explicitly declare in the file
header like this (as in PEP 0263):
# -*- coding: utf-8 -*-
regards
Pietro
___
grass
chars in people’s names though.
I don’t see the reason to avoid source code in utf-8, at least on
python files, in particular when it is explicitly declare in the file
header like this (as in PEP 0263):
# -*- coding: utf-8 -*-
regards
Pietro
ps: sorry my previous email lost the format
to the python interpreter in use and the
dictionary is the result of the script.core.region function.
Why is not working?
How can I fix this?
Pietro
# -*- coding: utf-8 -*-
START GRASS #
import os
import sys
## set PATHs
if sys.platform.startswith('linux
Hi Javier,
On Thu, Feb 27, 2014 at 4:45 PM, Javier Martínez-López
javi.martinez.lo...@gmail.com wrote:
I have a couple of problems when using pygrass for analyzing raster
maps stored in GRASS with the numpy library:
The RasterNumpy class was quite buggy, I did some changes last week
that
=0.006694380022900787
north: 228500
south: 215000
west: 63
east: 645000
nsres: 10
ewres: 10
rows: 1350
cols: 1500
cells: 2025000
after100.0135100.0150
Any Ideas?
Pietro
___
grass-dev mailing list
grass
Hi All,
On Tue, Feb 11, 2014 at 11:12 PM, Hamish hamis...@yahoo.com wrote:
Pietro wrote:
So are you agree to change the requirements for grass70
from Python = 2.4 to Python = 2.7 or Python = 2.6?
to add another me too for keeping support for python 2.6,
Debian/Squeeze: Python 2.6.6
Ubuntu
or not (and it is!) :-D.
Between python 2.6 and 2.7, as far as I know, there are not big
differences in term of portability to python3, so both versions should
be fine.
Pietro
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman
= 2.6?
Best regards.
Pietro
[0] http://www.python.org/getit/releases/2.6.9/
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
On Mon, Feb 10, 2014 at 10:43 AM, Martin Landa landa.mar...@gmail.com wrote:
2014-02-10 11:39 GMT+01:00 Pietro peter.z...@gmail.com:
So are you agree to change the requirements for grass70 from Python =
2.4 to Python = 2.7 or Python = 2.6?
personally I would keep support for Python 2.6
also help users to move they bash
scripts to python.
All the best.
Pietro
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
On Fri, Jan 31, 2014 at 3:53 PM, Vaclav Petras wenzesl...@gmail.com wrote:
I've used doctest to cover some of the pygrass' functions and modules,
but I don't like too much, at the moment to test the pygrass' doctest
you have to be inside the NorthCarolina/user1 location/mapset, that is
not
that setuptools could be the solution for our
problems, at least not in the short term. And I agree with you,
creating .bat files, it seems the best/easier solution so far.
Pietro
ps: Small note: python 3.3 insert the native support for virtual
environment in the standard library
(http://docs.python.org/3
that it does not
affect their ArcGIS installation, with it's own ESRI - specific version of
python.
I completely agree.
Personally I see a complete isolate python installation as a plus in that case.
Pietro
___
grass-dev mailing list
grass-dev@lists.osgeo.org
the knowledge to set
and configure a setup.py file for such complex project like GRASS.
Pietro
[0] https://pypi.python.org/pypi/setuptools
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
, with_statement, print_function, unicode_literals)
so we can start slowly to move from python2 = python3
what do you think?
Pietro
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
data set.
All the best.
Pietro
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
.
Best regards
Pietro
[0] http://www.gdal.org/ogr/drv_shapefile.html
[1] http://scikit-learn.org/
[2] http://mlpy.sourceforge.net/
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
, and compute also some extra values.
Pietro
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
On Sunday 08 Dec 2013 22:37:34 Markus Neteler wrote:
On Sat, Dec 7, 2013 at 12:58 AM, Glynn Clements
gl...@gclements.plus.com wrote:
...
Don't use r.univar -e, particularly for large maps. r.quantile
and r.statistics3 are far more efficient.
It might be nice to define a threshold for
=Combabula_Nearmap.red zones=seg005_64_zones
percentile=90. output=red.csv -e --o
The module termanate with:
D1/1: G_find_raster(): name=MASK mapset=pietro
Current region rows: 28545, cols: 27645
ERROR: G_realloc: unable to allocate 68000 bytes of memory at
r.univar_main.c:327
Any idea?
Maybe is a stupid
Hi,
I'm trying to convert a segment map into a vector map, I'm using GRASS7
(r58321), but I got:
G70 r.to.vect --o --v input=seg_0.05_final@pietro output=seg005 type=area
WARNING: Vector map seg005 already exists and will be overwritten
Using native format
Extracting areas...
100%
Writing
On Friday 29 Nov 2013 06:54:59 you wrote:
What it is wrong and how to fix it? Any ideas?
Please try make distclean,I had similar problems some day ago
I did, actually, so should be something else I guess...
Pietro
___
grass-dev mailing list
grass
table, could gain in usability too if avoid
to use v.db.select, and start to use directly the python API...
and I think should avoid to load the whole table and load only the
first 250 rows [0].
Best regards
Pietro
[0] http://trac.osgeo.org/grass/ticket/2124
On Monday 11 Nov 2013 00:46:20 GRASS GIS wrote:
I would like to put the attached file {{{__init__.py}}} into a new
pygrass directory lib/python/pygrass/messenger, if there are no
objections against it.
Personally I have no objections! :-)
Well done.
Pietro
table.
Anyone against this new flag/option?
Best regards
Pietro
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
?
Vaclav, tell me that I have to use: g.gisenv set=DEBUG=0 instead.
Maybe we should improve the documentation string to make it more
clear. What do you think?
Best regards
Pietro
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org
rewrite the categories to
link the new layer with the geometry features? Or if not define the
geometry features inherit the categories from the previous layer?
Best regards
Pietro
[0] http://grass.osgeo.org/programming7/structdblinks.html
___
grass-dev
On Thu, Oct 31, 2013 at 3:03 PM, Luca Delucchi lucadel...@gmail.com wrote:
[0] https://github.com/zarch/i.segment.hierarchical
Could I suggest you to use the grass-addons repository ;-)
Ok, moved (i.segment.hierarchical) to grass-addons (r58137).
Pietro
the
category of the training vector map. I'm working on it (so no code ready
yet!)
So I can write here as soon as I have something to test... :-)
Best regards
Pietro
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman
101 - 200 of 276 matches
Mail list logo
