#1798: all relevant vector modules should have cats and where parameters
--+-
Reporter: mlennert | Owner: grass-dev@…
Type: enhancement | Status: new
On 19/11/12 11:42, Nikos Alexandris wrote:
Hi all!
Using "v.db.dropcolumn" within from latest "grass_trunk",
I wonder why the "layer" parameter in "v.db.dropcolumn" is required to be a
string as stated in an error message while trying to run a py-grass script:
--%<---
File "/geo/osgeo/src/gras
Hi,
2012/11/21 Moritz Lennert :
> In GRASS7 you can name layers, which is used particularly for the direct OGR
> access. As the man page for v.db.dropcolumn says:
also GRASS vector layers is possible to access by names. By it's not
really used and probably also not fully supported. Most of module
Hi,
2012/11/21 Moritz Lennert :
[...]
>> Changed in r53917.
>
>
> Thanks ! Can this also be applied to the 6.4 release branch ?
done in r53946. Martin
--
Martin Landa * http://geo.fsv.cvut.cz/~landa
___
grass-dev mailing list
grass-dev@lists.osgeo.
Hi
I am working with the r.mapcalc graph function. When the input (number
of xy pairs) is very high, I am getting an error message:
"memory exhausted
Parse error
ERROR: parse error"
The largest possible number of xy pairs seems to be somewhere between
2400 and 2500. It runs with 2400 xy pair
Hi,
When running r.quantile with percentiles set at 0-100 at steps of 0.25, all
runs fine, the output would look like e.g (output in the recode rules
format - only first and last three shown) .,
2.879961:6.660391:1
6.660391:6.791101:2
6.791101:8.757845:3
.
.
.
9.144313:9.145126:397
9.145126:12.87
Hi,
2012/11/17 Aldo Clerici :
> v.db.connect map=roads1 table=roads2 layer=2
it's not enough. You need to defined also categories for layer '2',
see `v.category` for details. This module allows to change layer
number, but unfortunately not to copy categories from one layer to
another.
Motion:
v
On Wed, November 21, 2012 10:25, Martin Landa wrote:
> Hi,
>
> 2012/11/21 Moritz Lennert :
>
> [...]
>
>>> Changed in r53917.
>>
>>
>> Thanks ! Can this also be applied to the 6.4 release branch ?
>
> done in r53946. Martin
Thanks ! Now I hit the next problem in that same line:
Trying to save the
On Wed, November 21, 2012 14:12, Moritz Lennert wrote:
> On Wed, November 21, 2012 10:25, Martin Landa wrote:
>> Hi,
>>
>> 2012/11/21 Moritz Lennert :
>>
>> [...]
>>
Changed in r53917.
>>>
>>>
>>> Thanks ! Can this also be applied to the 6.4 release branch ?
>>
>> done in r53946. Martin
>
> Th
On Wed, November 21, 2012 14:20, Moritz Lennert wrote:
> On Wed, November 21, 2012 14:12, Moritz Lennert wrote:
>> On Wed, November 21, 2012 10:25, Martin Landa wrote:
>>> Hi,
>>>
>>> 2012/11/21 Moritz Lennert :
>>>
>>> [...]
>>>
> Changed in r53917.
Thanks ! Can this also be app
Trying to build a model with a loop in which the output map of a command
is the loop variable, I came across the following issue.
The model is just one command, r.neighbors, with output=%output. The loop
is defined as 'output in range(1995,1998)'. When trying to run this model,
I get this error:
On 21/11/12 13:02, Martin Landa wrote:
Hi,
2012/11/17 Aldo Clerici:
v.db.connect map=roads1 table=roads2 layer=2
it's not enough. You need to defined also categories for layer '2',
see `v.category` for details. This module allows to change layer
number, but unfortunately not to copy categorie
Hello Markus,
Your code in r53760 seems good. I would suggest to move it to some
library, still no idea where it should go. Probably Vlib? As it would
reduce code duplication and use of home-brew suboptimal code.
Thanks for good work,
Maris.
___
grass-de
Paulo van Breugel wrote:
> I am working with the r.mapcalc graph function. When the input (number
> of xy pairs) is very high, I am getting an error message:
>
> "memory exhausted
> Parse error
> ERROR: parse error"
>
> The largest possible number of xy pairs seems to be somewhere between
> 2
Hi,
> 2012/11/21 Moritz Lennert :
> Already exists in grass7: option=transfer
ops, I was accidentally checking 6.5. Too many versions installed ;-)
Thanks for the correction.
Martin
--
Martin Landa * http://geo.fsv.cvut.cz/~landa
___
grass-dev maili
Hi,
2012/11/21 Maris Nartiss :
> Your code in r53760 seems good. I would suggest to move it to some
> library, still no idea where it should go. Probably Vlib? As it would
> reduce code duplication and use of home-brew suboptimal code.
Vlib seems to be a good place, see also similar (more options
On Wed, Nov 21, 2012 at 3:59 PM, Martin Landa wrote:
> Hi,
>
> 2012/11/21 Maris Nartiss :
>> Your code in r53760 seems good. I would suggest to move it to some
>> library, still no idea where it should go. Probably Vlib? As it would
>> reduce code duplication and use of home-brew suboptimal code.
On Wed 21 Nov 2012 03:39:44 PM CET, Glynn Clements wrote:
Paulo van Breugel wrote:
I am working with the r.mapcalc graph function. When the input (number
of xy pairs) is very high, I am getting an error message:
"memory exhausted
Parse error
ERROR: parse error"
The largest possible number
Paulo van Breugel wrote:
> When running r.quantile with percentiles set at 0-100 at steps of 0.25, all
> runs fine
> When setting at smaller steps, e.g., 0.2, the output becomes strange
> 9.216583:0.00:407
> 0.00:0.00:408
> 0.00:0.00:409
> Any ideas why this is?
It uses an
#1803: GRASS 6.4.3RC1 on Win 7: grass64.bat fails due to UNIX line endings in
Init.bat
+---
Reporter: msieczka| Owner: grass-dev@…
Type: defect | Status: new
Great, thanks for the quick fix / improvement!
On Wed 21 Nov 2012 04:36:10 PM CET, Glynn Clements wrote:
Paulo van Breugel wrote:
When running r.quantile with percentiles set at 0-100 at steps of 0.25, all
runs fine
When setting at smaller steps, e.g., 0.2, the output becomes strange
Using a fresh checkout and compile from grass64_releasebranch, I have the
following issues trying to launch a python script. The executable bit is
set for the script.
- I tried putting the script into a directory called SCRIPTS. When I
choose 'Launch script' from the GUI Files menu, it asks if I w
#1804: r.clump NULL handling
-+--
Reporter: marisn | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone: 7.0.0
#1803: GRASS 6.4.3RC1 on Win 7: grass64.bat fails due to UNIX line endings in
Init.bat
+---
Reporter: msieczka| Owner: grass-dev@…
Type: defect | Status: new
#1803: GRASS 6.4.3RC1 on Win 7: grass64.bat fails due to UNIX line endings in
Init.bat
+---
Reporter: msieczka| Owner: grass-dev@…
Type: defect | Status: new
#1803: GRASS 6.4.3RC1 on Win 7: grass64.bat fails due to UNIX line endings in
Init.bat
+---
Reporter: msieczka| Owner: grass-dev@…
Type: defect | Status: new
#1804: r.clump NULL handling
-+--
Reporter: marisn | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone: 7.0.0
#1804: r.clump NULL handling
-+--
Reporter: marisn | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone: 7.0.0
#1800: v.kernel crashes after long execution
+---
Reporter: arencambre | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone: 6.4.3
Hi Glynn,
Your suggestion to use r.recode was spot on. It not only avoids the
mentioned limitations, it is also faster. (and it really is also much
simpler).
I am still wondering about these apparent memory limitations in the
r.mapcalc graph function.. but that is just curiosity, with your
altern
>Your suggestion to use r.recode was spot on. It not only avoids the
mentioned limitations, it is also
>faster. (and it really is also much simpler).
maybe something for the wiki (http://grasswiki.osgeo.org/wiki/Main_Page)?
-
best regards
Helmut
--
View this message in context:
http://osg
#1804: r.clump NULL handling
-+--
Reporter: marisn | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone: 7.0.0
Paulo van Breugel wrote:
> > The limit would depend upon the number of columns in the current
> > region and the amount of memory available.
>
> OK, but what I find strange is that using 2400 terms uses less then 2.5
> GB, I would not expect 2500 terms to use more then 12 GB (amount of RAM
> a
Hi all,
Could you please give me your advice:
i.rotate in add-ons will need to have some space around the image before
rotating it, then it should actually write to disk that enlarged (and
rotated) raster data.
In the GRASS GIS manual, it says that it is not recommended to play with
window sizes
34 matches
Mail list logo
