Hamish wrote:
btw, please do not add _() i18n to module output sent to stdout,
scripts parsing the result get confused. only for G_message()s.
Hmm, original and restored behaviour is to print non-i18n for -g and
i18n for -p output. The -p output does go to stdout but is much more
difficult to
Hamish wrote:
Hamish wrote:
You need to run db.connect to select a database backend to
use first. (There is no VAR file in the mapset yet)
hopefully fixed ready for testing in 6.5svn r42988 (v.edit).
devs:
maybe do this for 'v.in.ascii -e' and 'v.digit -n' too?
or move this into
Markus Neteler wrote:
Hi again,
Markus Neteler:
Hi,
proposal for action plan:
As before I suggest:
- release 6.4.0 now as-is
- increment SVN release branch to 6.4.1
- start immediately to backport relevant patches into 6.4.1
- winGRASS binaries will become available through josef
Moritz Lennert wrote:
Nikos Alexandris wrote:
v.distance is slow (for the impatient user) with very large vectors
(from my
memory I estimate that it took ~20h for ~600.000 features). Trying to get
the
dmax= first in order to tell v.distance to look for features within a
certain radius,
to the spatial index ? And is v.distance faster with spatial index
on file in grass7 ?
Markus Metz:
No consistent speed difference between grass 6.x and grass 7.
Sometimes grass 6 is faster, sometimes grass 7, but nothing dramatic.
The time-consuming parts are distance calculations and tests
Nikos Alexandris wrote:
@Markus M: Thank you Markus. Below I have put more questions (before reading
the document) on purpose. No need to reply (except if you have the time) -
it's for the sake of a potential beginner's question and answer wiki-page.
Some short answers below.
Nikos A wrote:
OK, here comes (soon) a speed-up for v.distance
test case is nc
I generated 1 random vector points with r.random, all within North
Carolina. As areas I used boundary_municp, scattered areas, some
points are within an area, most are outside any area. No dmax used
with v.distance
Original:
Moritz Lennert wrote:
Markus Metz wrote:
OK, here comes (soon) a speed-up for v.distance
[...]
Results for the 1 points are identical (distance to nearest area
and category of nearest area).
The code is now a bit more complicated, but reducing processing time
for distance
Moritz Lennert wrote:
As a final (at least for today ;-) )follow-up, just for the record:
On 11/08/10 13:42, Moritz Lennert wrote:
Then testing the idea from the link Markus N added to your bug report:
time v.db.update mygrid col=count value=(SELECT count(*) from mypoints
WHERE
On Wed, Aug 11, 2010 at 2:53 PM, Markus Metz
markus.metz.gisw...@googlemail.com wrote:
Moritz Lennert wrote:
As a final (at least for today ;-) )follow-up, just for the record:
On 11/08/10 13:42, Moritz Lennert wrote:
Then testing the idea from the link Markus N added to your bug report
Nikos Alexandris wrote:
So here you go using data from spearfish60 [1][2][3]
# in grass70 before the latest update
time v.distance --v from=pareto_ref_points___pareto_ref_100m
Start from scratch:
I've put a new module in grass-addons, called v.vect.stats. It counts
points in polygons, fairly fast, but, as the name implies, can do a
bit more. Optionally, it calculates statistics for areas based on the
attributes of all points falling into an area. Currently supported
Moritz Lennert wrote:
Markus Metz wrote:
Start from scratch:
I've put a new module in grass-addons, called v.vect.stats. It counts
points in polygons, fairly fast, but, as the name implies, can do a
bit more. Optionally, it calculates statistics for areas based on the
attributes of all
Nikos Alexandris wrote:
Markus M:
I've put a new module in grass-addons, called v.vect.stats.
...
... The
module fails to compile though under grass64, grass_trunk
compiles now in 64, but no longer in 65 (stats library in 65 is
different from 64), 65 is a development version and will
Hamish wrote:
Markus Metz wrote:
compiles now in 64, but no longer in 65 (stats library
in 65 is different from 64),
til now we have only really worried about backward-
compatibility at the data and command-line level.
None the less, all attempts should be made to keep the C
API function
Helmut Kudrnovsky wrote:
Hi Martin,
-Ursprüngliche Nachricht-
Von: Martin Landa Gesendet:
14.08.2010 13:27:17
An: Helmut Kudrnovsky
Betreff: Re: [GRASS-dev] Nightly WinGrass-builds (65,70) broken
2010/8/14 Helmut Kudrnovsky
the nightly Wingrass65- and WinGrass70-builds seems to be
Martin Landa wrote:
Hi,
there is new problem with compiling grass7 on Windows
la...@geo1 /osgeo4w/usr/src/grass_trunk/raster3d/r3.in.v5d
$ make
gcc -I/c/OSGeo4W/apps/gdal-16/include -I/c/OSGeo4W/include -g -O2
-I/c/OSGeo4W/apps/gdal-16/include -I/c/OSGeo4W/include
Markus Metz wrote:
Martin Landa wrote:
Hi,
there is new problem with compiling grass7 on Windows
la...@geo1 /osgeo4w/usr/src/grass_trunk/raster3d/r3.in.v5d
$ make
gcc -I/c/OSGeo4W/apps/gdal-16/include -I/c/OSGeo4W/include -g -O2
-I/c/OSGeo4W/apps/gdal-16/include -I/c/OSGeo4W/include
-I
Markus Neteler wrote:
Martin Landa wrote:
Folks,
2010/6/22 Jürgen E. j...@norbit.de:
[...]
dependencies for cairo are pk-config and Glib
(http://en.wikipedia.org/wiki/GLib), but I had no luck
at the moment to build pk-config and Glib at the moment.
Maybe just wishful thinking, but I
Glynn Clements wrote:
Markus Metz wrote:
fixed in r43137
Regarding the comment:
LFS for wingrass: another old name. use typedef instead of define?
In general, you should use typedef's for types. #define should be a
last resort, as it affects all use of the name regardless of context
Glynn Clements wrote:
Markus Metz wrote:
Also, what is the reason for defining _NO_OLDNAMES? Is there no
alternative?
Looking for one, but I do not get the initial approach with
#define lseek lseek64
to work, see ticket #1131.
Right.
Try explicitly including io.h and/or stdio.h
Martin Landa:
Chris Carleton:
I haven't been able to find something in the mailing lists about this, but
if you know of somewhere that I can find a solution I'd appreciate the link.
I'm running GRASS 6.4 RC5 on Ubuntu LTS 10.04 with a Dell Precision T7500
Workstation. The region settings are
that I can find that seems to be
discussing it formally is here:
http://trac.osgeo.org/gdal/wiki/HDF
Does anyone have the answer handy or another link with instructions that are
more clear? Thanks,
Chris
On 24 August 2010 05:39, Markus Metz markus.metz.gisw...@googlemail.com
wrote
like that I can find that seems to be
discussing it formally is here:
http://trac.osgeo.org/gdal/wiki/HDF
Does anyone have the answer handy or another link with instructions that
are more clear? Thanks,
Chris
On 24 August 2010 05:39, Markus Metz markus.metz.gisw...@googlemail.com
wrote
Markus Neteler wrote:
Hi,
I am importing the national boundaries of Italy as SHAPE file (UTM32) which
has
been generated from two parts in QGIS (SHP merge tool).
GRASS 7.0.svn (patUTM32):/tmp/ddd v.in.ogr
italy_limits_minambiente_full_UTM32_WGS84.shp
Markus Neteler wrote:
Hi,
I am importing the national boundaries of Italy as SHAPE file (UTM32) which
has
been generated from two parts in QGIS (SHP merge tool).
GRASS 7.0.svn (patUTM32):/tmp/ddd v.in.ogr
italy_limits_minambiente_full_UTM32_WGS84.shp
Message:
3D view mode not available
Reason: /lib/libz.so.1.2.3: wrong ELF class: ELFCLASS32
Note that the wxGUI's 3D view mode is currently disabled on
MS Windows (hopefully this will be fixed soon). Please keep
an eye out for updated versions of GRASS. In the meantime
you can use NVIZ from the
Tested with a 144 million cells DEM and threshold=10, r.watershed
completes successfully here. Can you try to debug with gdb or
valgrind? See [1] for some info on GRASS debugging.
Markus M
[1] http://grass.osgeo.org/wiki/GRASS_Debugging
Markus Metz wrote:
Chris Carleton wrote
Anne Ghisla:
Martin Landa:
Hi,
Markus Neteler:
Helmut Kudrnovsky:
maybe http://trac.osgeo.org/grass/ticket/1143 should be fixed?
since this one was also fixed. I suggest to release later today.
Few hours left before FOSS4G 2010!
+1 for today. Martin
+1 for today from me as
from here. Any help is greatly
appreciated,
Chris
On 30 August 2010 07:55, Markus Metz markus.metz.gisw...@googlemail.com
wrote:
Tested with a 144 million cells DEM and threshold=10, r.watershed
completes successfully here. Can you try to debug with gdb or
valgrind? See [1] for some info
Dylan Beaudette wrote:
Hi,
There are times were dumping the results from v.rast.stats to a file is more
efficient than uploading to an attribute table. Would anyone be interested in
a slight modification to v.rast.stats that would allow this?
This functionality already exists in
Hamish wrote:
Hamish wrote:
for 6.5svn I would vote to add .zonal as another module if
you like, but do not replace r.univar.
well, actually the diff is not so huge to make code auditing that
much of a problem, but it would need to be well tested.
You helped yourself with development and
Hamish wrote:
Martin wrote:
wxGUI in GRASS 6.5 is mostly in sync with GRASS 7.0. In
opposite wxGUI in GRASS 6.4.0 has been frozen due to long
RC stage for one year and more. I am starting to think to
backport wxGUI from GRASS 6.5 to 6.4.1. What do you think
about that? It will bring new GUI
There is an alternative to the Georectifier in the wxGUI, available in
6.4.1 and above, which has all the functionality of the Georectifier,
all features (as far as feasible) of i.points, and some new features,
including a manual. The new wxGUI GCP Manager also addresses the
tickets 142, 220, 686,
Martin Landa wrote:
Hi,
2010/10/14 Michael Barton michael.bar...@asu.edu:
I agree with Martin and the rest. Backporting is a good idea. It will make
for a better final GRASS 6 (i.e., whatever 6.5 becomes) and it will be
minimal disruption to users since we already made the wxPython GUI the
Michael Barton wrote:
From: Michael Barton michael.bar...@asu.edumailto:michael.bar...@asu.edu
Date: October 14, 2010 6:57:37 PM MST
To: Martin Landa landa.mar...@gmail.commailto:landa.mar...@gmail.com
Subject: Re: [GRASS-dev] wxGUI in GRASS 6.4.1
I do the same thing, but nothing happens.
In i.rectify, I have implemented the interpolation methods available
in r.proj, and while testing discovered an offset of one cell (row +
1, col + 1 from source to target) between the source and target
imagery after rectifying (40+ automatically collected GCPs, order=1,
sub-pixel RMS errors,
Hamish wrote:
Markus Metz wrote:
In i.rectify, I have implemented the interpolation methods available
in r.proj, and while testing discovered an offset of one cell (row +
1, col + 1 from source to target) between the source and target
imagery after rectifying (40+ automatically collected GCPs
Glynn Clements wrote:
Glynn Clements wrote:
However, there is another issue with r.proj (7.0) and r.proj.seg
(6.x): bilinear and cubic interpolation give a small number of garbage
results due to incorrect use of the caching mechanism (blocks are
being replaced while references remain). I'll
On Fedora 14 with cairo 1.10.0, python 2.7, wxPython 2.8.11, the cairo
driver is not working.
In GRASS 7, it simply does nothing, the display remains white, but the
png driver works. In GRASS 6.5, using the cairo driver freezes the
wxGUI, again, the png driver works. I tried various debug levels,
Markus Metz wrote:
On Fedora 14 with cairo 1.10.0, python 2.7, wxPython 2.8.11, the cairo
driver is not working.
Solved by downgrading cairo. Bug in cairo-1.10 coming with F14.
In GRASS 7, it simply does nothing, the display remains white, but the
png driver works. In GRASS 6.5, using
Markus Metz wrote:
Markus Metz wrote:
On Fedora 14 with cairo 1.10.0, python 2.7, wxPython 2.8.11, the cairo
driver is not working.
Solved by downgrading cairo. Bug in cairo-1.10 coming with F14.
That was a bug in the GRASS cairo driver, fixed in trunk 44356.
In GRASS 7, it simply does
Martin Landa wrote:
Hi,
2010/11/22 Markus Neteler nete...@osgeo.org:
would it be possible to prepare some plan / schedule for releasing 6.4.1?
There are a few things that do not work in 6.4 but work in 6.5.
Although we just got through a semester with GRASS6.4 without any major
disaster,
Olivier Tournaire wrote:
Hi all,
I am currently developping a plugin for QGis. My input data are shapefiles,
and I would like to clean their geometries before doing some processing.
v.clean() seems to do the job.
However, I really have no idea on how to:
1) fill a grass vector layer with
Markus Neteler wrote:
On Mon, Nov 22, 2010 at 12:11 PM, Benjamin Ducke
benjamin.du...@oxfordarch.co.uk wrote:
Would it be possible to also sync r.in|out.gdal
r.in.gdal: already identical
r.out.gdal: only %f changed to %g many times (I would not backport to
not ruin all translations
and
On Thu, Dec 2, 2010 at 2:05 PM, Markus Neteler nete...@osgeo.org wrote:
On Thu, Dec 2, 2010 at 3:15 AM, Helena Mitasova hmit...@unity.ncsu.edu
wrote:
r43599 for v.surf.rst is in GRASS65 so it should go into GRASS64 (but I
have never tested this one).
The entire z support was not
and are not representative of the
official policy of the U.S.Fish and Wildlife Service or Dept. of the
Interior. Life is too short for undocumented, proprietary data formats.
*Markus Metz markus.metz.gisw...@googlemail.com*
01/03/2011 09:13 AM
To
Markus Neteler nete...@osgeo.org
cc
doug_newc...@fws.gov
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
On Tue, Jan 4, 2011 at 11:17 AM, Martin Landa landa.mar...@gmail.com 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
, if
Postgresql/Postgis/Spatialite support that many entries. Make sure you
use v.external -b (no topology building).
Markus M
Markus Metz markus.metz.gisw...@googlemail.com
01/04/2011 04:43 AM
To
doug_newc...@fws.gov
cc
grass-dev@lists.osgeo.org, Markus Neteler nete...@osgeo.org
Subject
On Thu, Jan 13, 2011 at 10:03 PM, Benjamin Ducke
benjamin.du...@oxfordarch.co.uk wrote:
The HTML manual page for v.surf.bspline
says:
A raster output map (raster=) of more than 2000x2000 (4 mill)
cells is not allowed. If an output map would exceed this size,
an error message is generated.
On Wed, Jan 19, 2011 at 9:14 AM, Anne Ghisla a.ghi...@gmail.com wrote:
On Wed, 2011-01-19 at 08:51 +0100, Markus Neteler wrote:
On Wed, Jan 19, 2011 at 12:37 AM, Dylan Beaudette
debeaude...@ucdavis.edu wrote:
On Tuesday, January 18, 2011, Benjamin Ducke wrote:
That's reassuring, thanks
On Wed, Jan 26, 2011 at 6:32 PM, Martin Landa landa.mar...@gmail.com wrote:
2011/1/26 svn_gr...@osgeo.org:
Author: mmetz
Date: 2011-01-26 09:21:48 -0800 (Wed, 26 Jan 2011)
New Revision: 45195
Modified:
grass/branches/releasebranch_6_4/raster/r.proj.seg/main.c
Log:
fix for #1262
On Thu, Jan 27, 2011 at 11:40 AM, Martin Landa landa.mar...@gmail.com wrote:
Hi,
2011/1/27 Moritz Lennert mlenn...@club.worldonline.be:
time to think about 6.4.1RC2 I think... any opinions what's missing to
release it asap?
I consider http://trac.osgeo.org/grass/ticket/699#comment:7 to be a
Markus Neteler wrote:
Hi,
I wonder if v.generalize should work in LatLong? I tried to use the
displacement but the result is identical. Maybe a map unit (threshold
given in meters but currently considered in map units = degree?).
I guess v.generalize uses map units, i.e. degrees for latlong,
2011/3/29 António Rocha antonio.ro...@deimos.com.pt:
Hello Markus
Unfortunely, I get this error when I run other datasets. In this case, a
landCover with all CELLS and spatial resolution of 30. The problem is that
North carolina sample is too small.
r.to.vect -v input=FULL@PERMANENT
On Tue, Apr 5, 2011 at 9:40 AM, Maris Nartiss maris@gmail.com wrote:
Hello,
I'm totally lost in v.buffer/2 issues. I recompiled v.buffer and
v.buffer2 on 6.5 and was trying out different use cases from trac. All
of them where working fine with v.buffer2. Old v.buffer was still
failing
On Tue, Apr 5, 2011 at 4:37 PM, Martin Landa landa.mar...@gmail.com wrote:
Hi,
2011/3/31 Margherita Di Leo direg...@gmail.com:
I am willing to participate as student to GSoC with a GRASS GIS related
project.
I'm a third year PhD student and my main research interests lie in
hydrological
On Tue, Apr 5, 2011 at 10:06 AM, Moritz Lennert
mlenn...@club.worldonline.be wrote:
On 05/04/11 09:40, Maris Nartiss wrote:
Hello,
I'm totally lost in v.buffer/2 issues. I recompiled v.buffer and
v.buffer2 on 6.5 and was trying out different use cases from trac. All
of them where working
Glynn Clements wrote:
Markus Metz wrote:
The segment lib implementation in trunk is considerably faster than in
6.x, but not as efficient as the caching method of r.proj. Some
reasons why the segment library is slower than the caching code in
r.proj are 1) write support in the segment lib
In the grass7 wxGUI there are two instances of
parentframe = self
which should probably read
parent = self
right? They are in gdialogs.py L1247 and mcalc_builder.py L570 and
give python errors like
unexpected keyword argument 'parentframe'
___
The stuff created in lib/python/ctypes differs between 6.x and 7.0,
the 6.x versions being rather messy.
The Make system in 6.x should be updated to clean up the mess,
particularly that z lib to avoid the following error on 64bit Linux:
/lib/libz.so.1: wrong ELF class: ELFCLASS32
IMHO, the
On Mon, Apr 18, 2011 at 11:57 AM, Martin Landa landa.mar...@gmail.com wrote:
Hi,
2011/4/18 Markus Metz markus.metz.gisw...@googlemail.com:
The stuff created in lib/python/ctypes differs between 6.x and 7.0,
the 6.x versions being rather messy.
The Make system in 6.x should be updated
On Mon, Apr 18, 2011 at 12:44 PM, Martin Landa landa.mar...@gmail.com wrote:
Hi,
2011/4/18 Markus Metz markus.metz.gisw...@googlemail.com:
right, I would be happy to backport GRASS 7 Makefile system to GRASS
6. It would solve most of problems, make backporting easier. We just
need to extend
On Mon, May 23, 2011 at 4:04 PM, Glynn Clements
gl...@gclements.plus.com wrote:
Anne Ghisla wrote:
I'd suggest adding a test target to the various *.make files, so you
can do e.g.:
make -C display test
make -C display/d.rast test
Good idea. Sadly I don't know makefile system
Hi Andrea,
the double-dash options are generic options available for every module
and not defined by the module: --overwrite, --verbose, --quiet. These
options are used to set global environment variables. Using
r.watershed as example, it could be called through python with e.g.
Hi all,
GRASS 7 has a new module v.in.lidar for importing LiDAR LAS files
(*.las or *.laz). The LAS file format is commonly used for storing
LiDAR point clouds, but is unfortunately not supported by OGR.
v.in.lidar uses the libLAS library [0] and is only compiled if the
libLAS library is present.
On Wed, May 25, 2011 at 1:31 PM, Glynn Clements
gl...@gclements.plus.com wrote:
Markus Metz wrote:
the double-dash options are generic options available for every module
and not defined by the module: --overwrite, --verbose, --quiet.
IOW, you could ignore these three double-dash options
On Wed, May 25, 2011 at 12:16 PM, Hamish hamis...@yahoo.com wrote:
Markus Metz wrote:
Hi all,
GRASS 7 has a new module v.in.lidar for importing LiDAR LAS files
(*.las or *.laz). The LAS file format is commonly used for storing
LiDAR point clouds, but is unfortunately not supported by OGR
On Wed, May 25, 2011 at 1:45 PM, doug_newc...@fws.gov wrote:
Yes Thank you Markus! Since you are using liblas 1.6.1 , I assume
that this command can read the losslessly compressed .laz format?
As long as libLAS is compiled with laszip support, yes (tested and
working).
On Wed, May 25, 2011 at 4:02 PM, Hamish hamis...@yahoo.com wrote:
Markus Metz wrote:
Note that las2txt does NOT apply scale and offset to x,y,z,
this would need to be done afterwards in order to obtain
correct coordinates.
Therefore the output of las2txt | v.in.ascii with the
sample las file
can't quit the wx vector digitizer, applies to 7.0 and 6.5 (did not test 6.4)
self.StartEditing(self.layers[selection])
File /home/metz/src/grass-6.5.svn/dist.x86_64-unknown-
linux-gnu/etc/wxpython/gui_modules/toolbars.py, line 1174,
in StartEditing
lmgr.toolbar.Enable('vdigit', enable =
On Wed, May 25, 2011 at 1:22 PM, Glynn Clements
gl...@gclements.plus.com wrote:
Markus Neteler wrote:
Something is odd now (yes, I did make distclean):
grass70 /grassdata/indonesia_utm49s/PERMANENT/
GRASS 7.0.svn (nc_spm_08):~ g.gisenv
MAPSET=neteler
GISDBASE=/grassdata
On Tue, May 31, 2011 at 10:00 AM, Martin Landa landa.mar...@gmail.com wrote:
Hi,
I have compiled liblas from the repo [1] and then grass7 with
`--with-liblas`, unfortunately without success
configure:6544: checking for liblas-config
configure:6599: gcc -o conftest -g -Wall
On Tue, May 31, 2011 at 6:03 PM, Glynn Clements
gl...@gclements.plus.com wrote:
Markus Metz wrote:
I have compiled liblas from the repo [1] and then grass7 with
`--with-liblas`, unfortunately without success
$ liblas-config --libs
-L/usr/local/lib -llas -llas_c -L/usr/lib
optimized
On Tue, May 31, 2011 at 6:22 PM, Martin Landa landa.mar...@gmail.com wrote:
Hi,
2011/5/31 Markus Metz markus.metz.gisw...@googlemail.com:
BTW, what version of libLAS are you using?
source from the repo
http://liblas.org/development/source.html#source
try the current stable release 1.6.1
On Tue, May 31, 2011 at 11:34 PM, Glynn Clements
gl...@gclements.plus.com wrote:
Markus Metz wrote:
Is this optimized; and ;debug; now a problem of GRASS or of libLAS?
libLAS. Although it / be an issue with CMake's FindBoost module
(search for optimized in FindBoost.cmake).
This seems
Service or Dept. of the
Interior. Life is too short for undocumented, proprietary data formats.
*Markus Metz markus.metz.gisw...@googlemail.com*
Sent by: grass-dev-boun...@lists.osgeo.org
06/03/2011 02:20 AM
To
Hamish hamis...@yahoo.com
cc
GRASS developers list grass-dev
On Fri, Jun 3, 2011 at 4:55 PM, Markus Neteler nete...@osgeo.org wrote:
Hi,
from other Linux applications I am used to mark test (say, module
messages) with the left mouse button and paste it with the
middle mouse button into a whatever text editor.
But in the wxGUI it is not possible, I am
Markus Metz wrote:
Hi all,
GRASS 7 has a new module v.in.lidar for importing LiDAR LAS files
(*.las or *.laz). The LAS file format is commonly used for storing
LiDAR point clouds, but is unfortunately not supported by OGR.
v.in.lidar uses the libLAS library [0] and is only compiled
On Tue, Jun 14, 2011 at 12:58 PM, Hamish hamis...@yahoo.com wrote:
Martin wrote:
right. On the other hand you need to bear in mind at which
point of release cycle you are. In the case that we would like to
release 6.4.2 in Nov/Dec we are slightly in the middle. I don't think
that we need to
On Tue, Jun 14, 2011 at 5:35 PM, Martin Landa landa.mar...@gmail.com wrote:
Hi,
2011/6/14 Markus Metz markus.metz.gisw...@googlemail.com:
A number of changes to 6.5 and 7.0 went in untested, which is IMHO not
a good idea, but being development branches, maybe sometimes
excusable. Any changes
Hi all,
we may want to think about an update of the sample datasets. I have
recently updated the documentation of the v.net.* modules including
examples and noticed that roads digitized as multilanes have wrong
line directions, i.e. not matching drive directions. This makes
assignment of
On Tue, Jun 21, 2011 at 1:58 PM, Maris Nartiss maris@gmail.com wrote:
I would suggest to change grass7 to something not GRASS release dependent.
See [0] and following lines for an example of file format versioning
independent of the release
[0]
to be used for GRASS tutorials and
testing should be in the data set)
On Jun 20, 2011, at 11:15 AM, Markus Metz wrote:
Hi all,
we may want to think about an update of the sample datasets. I have
recently updated the documentation of the v.net.* modules including
examples and noticed that roads
On Fri, Jun 24, 2011 at 11:13 AM, Markus Metz
markus.metz.gisw...@googlemail.com wrote:
On Thu, Jun 23, 2011 at 6:44 AM, Helena Mitasova hmit...@ncsu.edu wrote:
Below are some plans for data updates. It would be useful to put this on wiki
so that others can comment, add, modify. I was thinking
On Tue, Jun 28, 2011 at 1:05 AM, Hamish hamis...@yahoo.com wrote:
MMetz:
CMD=v.build map=${VECT}@${MAPSET}
- g.message $CMD
+ g.message message=$CMD
$CMD
done
MNeteler:
... is this a needed change?
...
Most are without this parameter...
Needed in this case because
When linking external raster maps with r.external, I have to manually
create a corresponding cats file, otherwise a number of modules, e.g.
d.rast do not work properly. Is there any reason why no corresponding
cats file is produced?
This patch for trunk works for me:
---
Index: main.c
On Tue, Jun 28, 2011 at 10:32 AM, Hamish hamis...@yahoo.com wrote:
CMD=v.build map=${VECT}@${MAPSET}
Hamish:
ps- those curly brackets do nothing..
Markus M:
also no harm
yes and no-
sure it's a minor issue, but they help propagate
the myth that curly brackets can be used to
On Wed, Jun 29, 2011 at 12:23 AM, Glynn Clements
gl...@gclements.plus.com wrote:
Markus Metz wrote:
When linking external raster maps with r.external, I have to manually
create a corresponding cats file, otherwise a number of modules, e.g.
d.rast do not work properly. Is there any reason why
On Wed, Jun 29, 2011 at 11:21 AM, Markus Metz
markus.metz.gisw...@googlemail.com wrote:
On Wed, Jun 29, 2011 at 12:23 AM, Glynn Clements
gl...@gclements.plus.com wrote:
Markus Metz wrote:
When linking external raster maps with r.external, I have to manually
create a corresponding cats file
On Fri, Jul 1, 2011 at 1:51 AM, Glynn Clements gl...@gclements.plus.com wrote:
Markus Metz wrote:
IMHO, modules should not be required to explicitly write a cats file.
GRASS 4.x is ancient history, and raster maps are no longer inherently
category-based.
I think this is true for all
Hi all,
the GRASS 7 vector topology format changed a bit. I have removed
redundant information (bounding boxes) from vector topology and
updated all affected components. The changes are numerous and require
make distclean
configure
make
This change also means that whenever you switch between
Hamish wrote:
Markus Metz wrote:
the GRASS 7 vector topology format changed a bit. I have
removed redundant information (bounding boxes) from vector
topology
Hi,
just wondering how redundant that is.. for point data completely,
but for a polygon of 500,000 vertices (forest boundary
On Fri, Jul 1, 2011 at 2:48 PM, doug_newc...@fws.gov wrote:
The new format offers new possibilities for the v.surf.* modules
because it is now possible to build (parts of the) topology even for
massive point clouds which in turn makes it possible to quickly
perform spatial queries with very low
Hamish wrote:
Markus Metz wrote:
IOW, the bounding boxes are not
gone, they are still there, but no longer stored in two
different locations, only in one location.
...
No, the new, reduced format performs better with larger
datasets. For small datasets, there should be not much
On Mon, Jul 4, 2011 at 12:13 PM, Martin Landa landa.mar...@gmail.com wrote:
Hi,
2011/7/4 Markus Metz markus.metz.gisw...@googlemail.com:
BTW, I have reduced file I/O for d.vect type=area in GRASS 7, now
waiting for d.mon to come back...
just note: currently working on d.mon...
wonderful
On Wed, Jul 13, 2011 at 2:08 AM, Pierre Roudier
pierre.roud...@gmail.com wrote:
Hi,
I've been trying to use v.in.lidar. It yields good results on one LAS
file, but I get a segfault when trying it on several files:
v.in.lidar in=BD32_1610.las,BD32_1611.las out=test_input_lidar -trb
with topology is at 2^31 -
1 (about 2 billion) features.
Markus M
Pierre Roudier pierre.roud...@gmail.com
Sent by: grass-dev-boun...@lists.osgeo.org
07/13/2011 03:05 AM
To
Markus Metz markus.metz.gisw...@googlemail.com
cc
grass-dev grass-dev@lists.osgeo.org
Subject
Re: [GRASS-dev
Dylan Beaudette wrote:
On Fri, Jul 29, 2011 at 8:34 AM, Dylan Beaudette
dylan.beaude...@gmail.com wrote:
On Thu, Jul 28, 2011 at 9:00 PM, Glynn Clements
gl...@gclements.plus.com wrote:
Dylan Beaudette wrote:
With this morning's SVN from GRASS 6.5 and 7, I am getting a strange
error on the
601 - 700 of 1175 matches
Mail list logo
