Dwight Needels wrote:
On Jun 18, 2009, at 3:15 PM, Markus GRASS wrote:
Dangles shorter than thresh are removed sequentially until no dangles
remain. No dangles will remain if thresh 0.
PS: I hope you have now the world's cleanest hiking trails:-)
Thanks; I think I could have swept them
maven apache wrote:
This is a vector layer transfered from a raster and its general info
can be seen as follows:
|
| Projection: Universe Transverse Mercator (zone 0)
|
On 19/06/09 04:40, maven apache wrote:
This is a vector layer transfered from a raster and its general info can
be seen as follows:
++
| Layer: sw...@permanent
|
Micha Silver wrote:
Dwight Needels wrote:
On Jun 18, 2009, at 3:15 PM, Markus GRASS wrote:
Dangles shorter than thresh are removed sequentially until no
dangles remain. No dangles will remain if thresh 0.
PS: I hope you have now the world's cleanest hiking trails:-)
Thanks; I think I
On 19/06/09 09:27, Moritz Lennert wrote:
On 19/06/09 04:40, maven apache wrote:
This is a vector layer transfered from a raster and its general info
can be seen as follows:
++
| Layer:
sw...@permanent
G. Allegri wrote:
IMHO, this line shouldn't be written in either case. Code wishing to
use the SWIG bindings should explicitly use import grass.lib. Or,
preferably, import grass.lib.grass etc. Loading a dozen libraries
just in case is a waste of resources and a potential source of
Sorry; the __init__.py files for the packages need to exist, but they
shouldn't import the modules/packages. As it stands,
import grass.lib.grass will load *all* of the binary modules, and
all of their dependencies (i.e. including GDAL, and all of its
dependencies).
I'm new to grass 7 and
Hi,
2009/6/19 G. Allegri gioha...@gmail.com:
Sorry; the __init__.py files for the packages need to exist, but they
shouldn't import the modules/packages. As it stands,
import grass.lib.grass will load *all* of the binary modules, and
all of their dependencies (i.e. including GDAL, and all of
Moritz wrote:
Sorry, just reread your message, and my answer is probably
not really helpful. In fact v.out.ogr does transform your
data to EPSG 4326, as the following message shows:
Warning 1: Longitude 638073.992861 has been modified to fit into range
[-180,180]. This warning will not
2009/6/19 Hamish hamis...@yahoo.com
Moritz wrote:
Sorry, just reread your message, and my answer is probably
not really helpful. In fact v.out.ogr does transform your
data to EPSG 4326, as the following message shows:
Warning 1: Longitude 638073.992861 has been modified to fit into
On 19/06/09 10:57, Hamish wrote:
Moritz wrote:
Sorry, just reread your message, and my answer is probably
not really helpful. In fact v.out.ogr does transform your
data to EPSG 4326, as the following message shows:
Warning 1: Longitude 638073.992861 has been modified to fit into range
maven wrote:
I am trying to change the projection ,but have not successed..
create a new lat/lon WGS84 location with EPSG code # 4326, then pull
in maps from source mapset using r.proj, v.proj.
Hamish
___
grass-user mailing list
yes, how to dynamically add lib to __all__ list when swig/python is
build successfully?
I can't help, because I don't know the build system.
About the swig build I receive:
make[1]: shared: comando non trovato
make[1]: [_utils.so] Errore 127 (ignorato)
/usr/bin/install: impossibile eseguire
ok, I had a chance to look using a 1km^2 block of LIDAR data I had around.
(0.5M pts, uses ~ 750mb RAM on 64bit Linux)
I've never used the v.lidar tools much (I usually just do something
simple with r.in.xyz) so I can't offer too much expert help. But...
[half of what follows is aimed at
As it is writing the file (was at 6Mb after 3hrs), the mem usage is
on 114Mb with 1.4Gb free at the moment. It is not using the PageFile.
is that at 100%/4(25%) or 1% CPU?
The RAM was increasing gradually also. It's at 1% CPU.
I tried again with a 182kb tile and the process took 10mins
the command
v.infomap=''.
I wonder it is my problem or the grass?
-- next part --
An HTML attachment was scrubbed...
URL:
http://lists.osgeo.org/pipermail/grass-user/attachments/20090619/4faa1346/attachment.html
--
Dr. Peter Löwe
peter.lo...@gmx.de
GRATIS für alle
I have lose my heart so So many people have gave me help,...I can
not do it.
2009/6/19 Hamish hamis...@yahoo.com
maven wrote:
I am trying to change the projection ,but have not successed..
create a new lat/lon WGS84 location with EPSG code # 4326, then pull
in maps from
Hamish wrote:
It turns out that ~95% of the computational time is spent in the 3-deep
nested for loops of the Tcholetsky decomposition function.
(lidarlib/tcholDec())
for my data it ran 16 loops of:
{
1. Bilinear interpolation
2. Bicubic interpolation
3. Point classification (fast)
I am using 6.3,my tiff info:---
Coordinate System is:
PROJCS[WGS 84 / UTM zone 20S,
GEOGCS[WGS 84,
DATUM[WGS_1984,
SPHEROID[WGS 84,6378137,298.2572235630016,
AUTHORITY[EPSG,7030]],
AUTHORITY[EPSG,6326]],
maven wrote:
First I create location :g.proj -c georef=d:/swilAlphaTIFF.tif
datumtrans=0 location=newlocationthen import it
to the new location: get four raster maps(it has three
band),I composite them and then transfer the composted
raster to vector,then extract each category to a
2009/6/19 Hamish hamis...@yahoo.com
maven wrote:
First I create location :g.proj -c georef=d:/swilAlphaTIFF.tif
datumtrans=0 location=newlocationthen import it
to the new location: get four raster maps(it has three
band),I composite them and then transfer the composted
raster to
Hi all,
I tried compiled GRASS_RC5 in ubuntu jaunty 64 bits with this options
CFLAGS=-g -Wall ./configure -with-cxx --enable-64bit -with-postgres \
--with-postgres-includes=/usr/include/postgresql
--with-postgres-libs=/usr/lib64 \
/postgresql/8.3/lib -with-mysql
Hi,
2009/6/19 Jhon Ortiz eljhonj...@hotmail.com:
[...]
/usr/local/src/grass-6.4.0RC5/lib/nviz
/usr/local/src/grass-6.4.0RC5/gui/wxpython/nviz
/usr/local/src/grass-6.4.0RC5/visualization/nviz
/usr/local/src/grass-6.4.0RC5/visualization/nviz2/cmd
I'm not a expert linux user. Some advice
Hi,
2009/6/19 Jhon Ortiz eljhonj...@hotmail.com:
[...]
/usr/local/src/grass-6.4.0RC5/lib/nviz
/usr/local/src/grass-6.4.0RC5/gui/wxpython/nviz
/usr/local/src/grass-6.4.0RC5/visualization/nviz
/usr/local/src/grass-6.4.0RC5/visualization/nviz2/cmd
I'm not a expert linux user.
Hi,
2009/6/19 Jhon Ortiz eljhonj...@hotmail.com:
j...@cito:/usr/local/src/grass-6.4.0RC4/lib/nviz$ make
mkdir -p /usr/local/src/grass-6.4.0RC4/bin.
mkdir -p /usr/local/src/grass-6.4.0RC4/dist./include/grass
'dist.' is wrong dictionary, there is something wrong with the build system.
Martin
I actually get the same thing. For the first whiletheprocess runs in full use of one core, but once the process starts writing results to the db, the wholeprocessbogs down to a grindinghalt. CPU usage for v.lidar.edgedetection drops down to ~1% (1% of one core) and sqlite usage rises to ~16%.
Martin Landa wrote:
The __init__.py files are supposed to contain an __all__ array listing
the modules and/or sub-packages. This matters on Windows, so that e.g.
from grass.lib import * imports the modules with the correct case in
the event that the filesystem entries have been converted
Jhon Ortiz wrote:
I tried compiled GRASS_RC5 in ubuntu jaunty 64 bits with this options
CFLAGS=-g -Wall ./configure -with-cxx
All switches should have two dashes.
--enable-64bit -with-postgres \
--with-postgres-includes=/usr/include/postgresql
--with-postgres-libs=/usr/lib64 \
Hi all,
Using Grass 6.4.0 from Osgeo4W in WinXP. When I try to change my
mapset inside a grass section by typing, for example, g.mapset
PERMANENT at the prompt I get the error:
-
GRASS 6.4.0svn (utm23) g.mapset PERMANENT
ERROR: Unable to read GIS_LOCK environment
Hi,
2009/6/19 Jhon Ortiz eljhonj...@hotmail.com:
j...@cito:/usr/local/src/grass-6.4.0RC4/lib/nviz$ make
mkdir -p /usr/local/src/grass-6.4.0RC4/bin.
mkdir -p /usr/local/src/grass-6.4.0RC4/dist./include/grass
'dist.' is wrong dictionary, there is something wrong with the build system.
Hi all,
I tried to create a new GRASS location with location wizard and gave me this
errors:
/usr/local/grass-6.4.0RC5/etc/wxpython/gui_modules/gcmd.py:63:
DeprecationWarning: BaseException.message has been deprecated as of Python 2.6
self.message = message
Traceback (most recent call
Hello List,
I'm trying to figure out how to write python scripts using grass.py under
osgeo4w. I was hoping that python script (and the binary commands) would
behave similarly to the grass environment on my Ubuntu box. You know...just
type the command and the gui for that command comes up.
Daniel Victoria wrote:
Using Grass 6.4.0 from Osgeo4W in WinXP. When I try to change my
mapset inside a grass section by typing, for example, g.mapset
PERMANENT at the prompt I get the error:
-
GRASS 6.4.0svn (utm23) g.mapset PERMANENT
ERROR: Unable to read
Daniel Victoria wrote:
Using Grass 6.4.0 from Osgeo4W in WinXP. When I try to change my
mapset inside a grass section by typing, for example, g.mapset
PERMANENT at the prompt I get the error:
-
GRASS 6.4.0svn (utm23) g.mapset PERMANENT
ERROR: Unable to
Moskovitz, Bob wrote:
I'm trying to figure out how to write python scripts using grass.py
under osgeo4w. I was hoping that python script (and the binary
commands) would behave similarly to the grass environment on my Ubuntu
box. You know...just type the command and the gui for that command
Michael wrote:
I actually get the same thing.
For the first while the process runs in full use
of one core, but once the process starts writing results to
the db, the whole process bogs down to a
grinding halt. CPU usage for v.lidar.edgedetection
drops down to ~1% (1% of one core) and
John wrote:
p252 of 3rd edition '#build topology so that we can use all
vector tools'.
that should probably read most modules. The vector modules which
deal with huge LIDAR datasets have been specially modified to work with
no topology to avoid the finite per-point memory overheads.
Some of the nested for(;;) loops could be improved by
adjusting start and end values. Maybe the attached patch for
vector/lidar/lidarlib/TcholBand.c helps. No warranty!
tested with v.lidar.edgedetection, coor and dbf binary files identical
before and after the patch. Hopefully that module
38 matches
Mail list logo
