Just did an update from the svn release branch this morning and am testing
GRASS 6.4.1
There is a piece of left over testing code in toolbox.tcl from v.digit (line
55) that puts the button number to the screen. Can I just remove it and commit
or do I need to do something special with respect t
#1248: r.thin may be broken
--+-
Reporter: cmbarton | Owner: grass-...@…
Type: defect | Status: reopened
Priority: normal | Milestone: 7.0.0
Hi psr,
(not a noise removal specialist)
but FFT can remove specific noise if combining FFT forward image with
some filters (i.e. FFT*filter_image) and FFT inverse it.
You have to look into the noise structure and detect noise pixel with
the FFT trick above, Identify noise pixels and set them to
hi sirs,
apologized me indeed for disturbing this list but I really have questions if
grass were able to use for image processing ?
for example, I have a photo of gamma irradiation of some materials and want
to remove noises, a dot or dots generated not from material , from that
photograph, is it
2011/1/4 Maris Nartiss :
> Just made a svn up && make distclean && make dance and everything
> works just fine, still I'm running GRASS from source directory (no
> make install) step.
same as me.
> still running 6.5, as 7 (GUI) performance is awfull.
what do you mean by "GUI performance", probab
Just made a svn up && make distclean && make dance and everything
works just fine, still I'm running GRASS from source directory (no
make install) step.
Maris,
still running 6.5, as 7 (GUI) performance is awfull.
2011/1/4, Martin Landa :
> 2011/1/4 Martin Landa :
>>> GRASS 6.5 r44853
>>> ~AMD64
#1218: make htmldocs generates Python and not C documentation
--+-
Reporter: marisn | Owner: martinl
Type: defect | Status: closed
Priority: major| Milestone:
2011/1/4 Martin Landa :
>> GRASS 6.5 r44853
>> ~AMD64 2.6.36
>> Python 2.6.6 [GCC 4.4.4]
>
> right, it seems to be grass7-related issue.
btw, ctypes doesn't work at all in grass65.
Traceback (most recent call last):
File "/home/martin/smetiste/test3.py", line 2, in
from grass.lib.vector im
Hi,
2011/1/4 Maris Nartiss :
> Works here just fine.
>
> GRASS 6.5 r44853
> ~AMD64 2.6.36
> Python 2.6.6 [GCC 4.4.4]
right, it seems to be grass7-related issue.
Martin
--
Martin Landa * http://geo.fsv.cvut.cz/~landa
___
grass-dev mailing list
grass-
Works here just fine.
GRASS 6.5 r44853
~AMD64 2.6.36
Python 2.6.6 [GCC 4.4.4]
Maris.
2011/1/4, Martin Landa :
> Hi,
>
> 2011/1/4 Maris Nartiss :
>> This one should work. One has to be really carefull and track when
>
> No, it's not working.
>
>> map = Map_info()
>>
>> Vect_open_update(byref(map
Hi,
2011/1/4 Maris Nartiss :
> This one should work. One has to be really carefull and track when
No, it's not working.
> map = Map_info()
>
> Vect_open_update(byref(map), "vector", "mapset")
btw, if you need a pointer (to reuse it), it's better to use pointer()
instead of byref()
map_obj = Ma
This one should work. One has to be really carefull and track when
pointers are required. Working with pointers and ctypes is a tricky
thing.
from ctypes import byref
from grass.lib.vector import *
map = Map_info()
Vect_open_update(byref(map), "vector", "mapset")
p = Vect_new_line_struct()
c =
Hi,
2011/1/4 Glynn Clements :
>> p = line_pnts()
>> Vect_append_point(byref(p), 1, 1, 0)
>
> You're passing an uninitialised line_pnts structure (i.e. with its
> fields containing garbage), and probably trashing the heap. Use
> Vect_new_line_struct() to allocate an empty line_pnts object.
somethi
#1218: make htmldocs generates Python and not C documentation
--+-
Reporter: marisn | Owner: martinl
Type: defect | Status: reopened
Priority: major| Milestone:
Martin Landa wrote:
> right, just facing to the strange problem, any idea?
> p = line_pnts()
> Vect_append_point(byref(p), 1, 1, 0)
You're passing an uninitialised line_pnts structure (i.e. with its
fields containing garbage), and probably trashing the heap. Use
Vect_new_line_struct() to alloca
#1218: make htmldocs generates Python and not C documentation
--+-
Reporter: marisn | Owner: martinl
Type: defect | Status: reopened
Priority: major| Milestone:
>>>Large file support does not help here because 8.5 billion points
>>>exceeds the number of supported features in GRASS vectors which is
>>>about 2 billion (2,147,483,647 to be precise).
>>I'll chop the inputfile into sections less than 2 billion then.
Is there any reason that the 2 bill
Thanks. I'll give it a try.
Michael
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University
voice: 480-965-6262 (SHESC), 480-727-9746 (CSDC)
fax: 480-965-7671
HI Yann,
did you solve this?
Markus
On Thu, Dec 16, 2010 at 1:36 AM, Yann Chemin wrote:
> Hello list,
>
> we are trying to get through i.atcorr for Aster and we seem to hit a
> wall of NULL values.
> Anybody had success so far with Aster in i.atcorr?
>
> For Aster Band 1 in Coleambally NSW Aust
#1248: r.thin may be broken
--+-
Reporter: cmbarton | Owner: grass-...@…
Type: defect | Status: reopened
Priority: normal | Milestone: 7.0.0
A first release candidate of GRASS 6.4.1 is now available.
Source code:
http://grass.osgeo.org/grass64/source/
http://grass.osgeo.org/grass64/source/grass-6.4.1RC1.tar.gz
Windows Binaries:
http://grass.osgeo.org/grass64/binary/mswindows/native/WinGRASS-6.4.1RC1-1-Setup.exe
More binaries will
Hi,
2011/1/4 Helmut Kudrnovsky :
> at the moment the modules mentioned above are included in the wxgui, but
> greyed out because not
> yet backported.
>
> at least the gui-entries should be removed for 6.4.1?
right, done in r44863.
Martin
--
Martin Landa * http://geo.fsv.cvut.cz/~landa
_
#1189: wingrass: 'g.region -l' fails
---+
Reporter: hamish | Owner: grass-...@…
Type: defect | Status: new
Priority: critical | Milestone: 6.4.1
#989: wx georectify: implement best features of i.points
--+-
Reporter: hamish| Owner: grass-...@…
Type: enhancement | Status: new
Priority: n
Hi,
>Hi,
>
>2011/1/4 Helmut Kudrnovsky
>>> since the i.ortho.photo fixes have been backported plus other changes
>>> (much
>>>work done by Martin), it is time to get out the first release
>>>candidate. If anything
>>>goes wrong, we can have RC2 immediately.
>>
> >in grass65 there are following
2011/1/4 Martin Landa :
> 2011/1/4 Martin Landa :
>> The map is opened correctly, Vect_level() works. Anyway
>> Vect_write_line() fails, seems to be that Map_info is corrupted. No
>> clue at this moment.
>
> when tracking pointer address of Map_info instance -
> Vect_open_update() and Vect_level()
2011/1/4 Markus Metz :
> Should be fixed in r44862. (You were faster updating than I was committing;-))
thanks, Martin
--
Martin Landa * http://geo.fsv.cvut.cz/~landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/
On Tue, Jan 4, 2011 at 11:17 AM, Martin Landa wrote:
> Hi,
>
> the commit seems to be incomplete
Should be fixed in r44862. (You were faster updating than I was committing;-))
>
> mar...@pierre:~/src/grass_trunk/lib/vector/diglib$ make
> gcc -g -Wall -Werror-implicit-function-declaration -fno-co
The topological vector format of GRASS can require quite a bit of
memory for larger vectors, which can cause problems such as
out-of-memory errors or freezing the machine if a vector module uses
up all system memory and goes into swap space.
The largest component in GRASS vector topology is the sp
Hi,
the commit seems to be incomplete
mar...@pierre:~/src/grass_trunk/lib/vector/diglib$ make
gcc -g -Wall -Werror-implicit-function-declaration -fno-common
-Wextra -Wunused -fPIC
-I/usr/local/src/grass_trunk/dist.i686-pc-linux-gnu/include
-I/usr/local/src/grass_trunk/dist.i686-pc-linux-gnu/inc
2011/1/4 Martin Landa :
> The map is opened correctly, Vect_level() works. Anyway
> Vect_write_line() fails, seems to be that Map_info is corrupted. No
> clue at this moment.
when tracking pointer address of Map_info instance -
Vect_open_update() and Vect_level() points to the same address.
Pointe
2011/1/4 Martin Landa :
>> should they be backported to grass6.4.1 for release?
>
> too late, it can be done for 6.4.2. Now we are in RC stage.
recorded at http://trac.osgeo.org/grass/wiki/Grass6Planning#GRASS6.4.2
Martin
--
Martin Landa * http://geo.fsv.cvut.cz/~landa
On Mon, Jan 3, 2011 at 4:01 PM, wrote:
>
> Markus M.,
>
> >Large file support does not help here because 8.5 billion points
> >exceeds the number of supported features in GRASS vectors which is
> >about 2 billion (2,147,483,647 to be precise).
> I'll chop the inputfile into sections less
Hi,
2011/1/4 Helmut Kudrnovsky :
>> since the i.ortho.photo fixes have been backported plus other changes (much
>>work done by Martin), it is time to get out the first release
>>candidate. If anything
>>goes wrong, we can have RC2 immediately.
>
> in grass65 there are following v.net.*-modules:
#1254: v.build error
-+--
Reporter: akbgf| Owner: grass-...@…
Type: defect | Status: new
Priority: normal | Milestone: 7.0.0
Component:
hi,
> since the i.ortho.photo fixes have been backported plus other changes (much
>work done by Martin), it is time to get out the first release
>candidate. If anything
>goes wrong, we can have RC2 immediately.
in grass65 there are following v.net.*-modules:
v.neighbors
v.net.alloc
v.net
#1254: v.build error
-+--
Reporter: akbgf| Owner: grass-...@…
Type: defect | Status: new
Priority: normal | Milestone: 7.0.0
Component:
37 matches
Mail list logo
