On Tue, Sep 4, 2012 at 11:42 AM, Luca Delucchi lucadel...@gmail.com wrote:
I find that v.extract break where condition after 985 characters. I
try it with grass 6.4svn and grass7 and in both I have an error. If
this is a bug I think we should try to fix before 6.4.3 release.
Please try trunk
On Sat, Sep 1, 2012 at 2:07 PM, Markus Neteler nete...@osgeo.org wrote:
Hi,
to my understanding the r.grow.distance code lacks support for
LatLong locations. AFAIK G_begin_distance_calculations() and
G_distance() would be needed here.
The -m flag to use geodesic distance for latlong
On Sun, Aug 26, 2012 at 10:43 AM, Martin Landa landa.mar...@gmail.com wrote:
Hi,
6.4.3 is planned for September. As I wrote earlier creating release
branch for G7 at this stage of development is too early (from my POV).
I would say that we could create this branch later in the beginning of
On Thu, Aug 23, 2012 at 9:58 AM, Markus Neteler nete...@osgeo.org wrote:
On Fri, Aug 17, 2012 at 2:03 PM, Markus Neteler nete...@osgeo.org wrote:
Hi all,
it is about time to get 6.4.3 out of the doors. It would be nice to have
a RC1 for the upcoming Geostat 2012 in Muenster (full day of GRASS
Hi all,
even the GRASS website [0] gets confused about all those branches.
GRASS 6.4.3, the next stable release, is currently hidden under GRASS
6.4.2, current stable. Therefore there should be 4, not 3 sections:
6.4.2, 6.4.3, 6.5, 7.0. This is however IMHO too much, confusing for
users and a
On Wed, Aug 22, 2012 at 7:28 PM, Michael Barton michael.bar...@asu.edu wrote:
The way I thought I understood the plan is that we would have an odd
numbered version for development, testing, etc and an even numbered release
version. So it has seemed to me that 6.4.3 is the place where we were
On Wed, Aug 22, 2012 at 9:46 PM, Michael Barton michael.bar...@asu.edu wrote:
I ran into this problem too, working with people from NCAR this Spring. It
seemed there to be limited to Windows XP users. Workarounds were difficult.
This has been fixed in all branches 5 months ago. Please use
On Wed, Aug 22, 2012 at 8:13 PM, Helena Mitasova hmit...@ncsu.edu wrote:
in the current stable release I am getting the the following error
when trying to save the image from the display. We did not have the
problem in 6.4.1 and I am wondering whether it is fixed in 6.4.3,
It is.
Markus M
On Thu, Aug 23, 2012 at 12:25 AM, Helena Mitasova hmit...@ncsu.edu wrote:
On Aug 22, 2012, at 4:58 PM, Markus Metz wrote:
On Wed, Aug 22, 2012 at 9:46 PM, Michael Barton michael.bar...@asu.edu
wrote:
I ran into this problem too, working with people from NCAR this Spring. It
seemed
On Mon, Aug 20, 2012 at 10:29 AM, Markus Neteler nete...@osgeo.org wrote:
On Tue, Aug 14, 2012 at 2:52 PM, Luca Delucchi lucadel...@gmail.com wrote:
Is it correct leave empty a default answer in a module?
An example is in r.out.pov with zmod or objmod option
(it is about v.out.pov):
On Fri, Aug 10, 2012 at 11:44 AM, Martin Landa landa.mar...@gmail.com wrote:
Hi,
2012/8/10 Markus Neteler nete...@osgeo.org:
If this is a real problem, why fix the symptoms and not the cause?
That would probably be the macro defining _().
+1
It worked for the past 10-xx years, so I don't
What does gdalinfo --formats say?
When you compile GRASS with gdal, all the libraries that gdal needs
must be in the library path, even if GRASS itself does not link to
them directly. Therefore I guess that gdalinfo --formats and ogrinfo
--formats are currently not working on your system.
On Thu, Aug 9, 2012 at 10:35 PM, Hamish hamis...@yahoo.com wrote:
- G_fatal_error(_(Both seed map and coordinates cannot be specified));
+ G_fatal_error(%s, _(Both seed map and coordinates cannot be
specified));
Martin:
sorry for ignorance, but what is the sense of such changes?
Vaclav:
On Wed, Jul 25, 2012 at 5:59 AM, Hamish hamis...@yahoo.com wrote:
Markus Metz wrote:
An example for vector processing using the basins raster
created in the previous step:
1) convert the basins to vector areas with r.to.vect -v feature=area
2) load average elevation for each basin
On Mon, Jul 23, 2012 at 2:32 AM, Hamish hamis...@yahoo.com wrote:
There's a copy of the quickstart in the GRASS wiki. Note that
when I wrote it there was a GRASS workshop at the targeted FOSS4G
conference which was going to focus on vector processing, so I
didn't bother to put much of that in
On Fri, Jul 20, 2012 at 2:20 PM, Markus Neteler nete...@osgeo.org wrote:
On Fri, Jul 20, 2012 at 11:22 AM, Johannes Radinger jradin...@gmx.at wrote:
Hi,
Hi,
I don't know if this behavior is intended or not, I just
wanted to inform:
Using the GUI and selecting File - Import vector data
On Wed, Jul 18, 2012 at 9:00 AM, Margherita Di Leo
dileomargher...@gmail.com wrote:
Hi,
On Tue, Jul 17, 2012 at 4:51 PM, Margherita Di Leo
dileomargher...@gmail.com wrote:
Now tried:
gdalbuildvrt -input_file_list elenco_aster_europa mosaic.vrt
(all in the same folder)
then in GRASS:
On Sat, Jun 23, 2012 at 6:36 AM, Michael Barton michael.bar...@asu.edu wrote:
One of my students reported intermittent crashing of the digitizer when
saving a map in GRASS 7 with Mac Lion (OSX 10.7). I haven't used the
digitizer much lately but did a new build today to see if that helped.
I
On Tue, Jun 26, 2012 at 12:23 AM, Hamish hamis...@yahoo.com wrote:
FWIW,
See discussion and GRASS vs. R testing/validation w/Nikos from
c. March 2009. ( trac ticket #430)
Ticket #430 is fixed in all branches.
See also other open i.pca tickets:
i.pca fails to center data prior to analysis
An inverse PCA can be regarded as the inverse of a transformation
using matrix notation. PC scores are calculated with
b = A a
with A being the transformation matrix composed of the Eigenvectors, a
being the vector of the original values and b the PC scores. What you
now need is inverse of A,
. It needs to be done for heterogenous input data such as e.g.
rainfall, temperature, NDVI, etc. Rescaling is automatically applied
to the output of i.pca unless explicitly disabled with rescale=0,0.
Markus M
Thanks much
Michael
On Jun 25, 2012, at 10:11 AM, Markus Metz wrote:
An inverse PCA
On Mon, Jun 25, 2012 at 8:21 PM, Michael Barton michael.bar...@asu.edu wrote:
On Jun 25, 2012, at 12:03 PM, Markus Metz wrote:
Here is an example based on on the landsat imagery in mapset landsat,
North Carolina sample dataset:
i.pca without rescaling of the output:
i.pca input
On Thu, Jun 21, 2012 at 5:16 PM, Vaclav Petras wenzesl...@gmail.com wrote:
Hello,
I'm moving size_t topic from user to dev list.
As I understand, size_t should be used also for number of rows and
number of columns of a map. But for example Rast_window_{rows,cols}
returns int. So will this
' or
'to' features are not reachable.
Markus M
Thanks in advanced,
Roberto
2012/6/16 Markus Metz markus.metz.gisw...@googlemail.com
On Fri, Jun 15, 2012 at 6:12 PM, Roberto Marzocchi
roberto.marzoc...@gmail.com wrote:
Dear all,
I'm trying to use v.net.distance in grass7, which option seem
On Fri, Jun 15, 2012 at 6:12 PM, Roberto Marzocchi
roberto.marzoc...@gmail.com wrote:
Dear all,
I'm trying to use v.net.distance in grass7, which option seem be corrected
respect of teh version of grass65 (alayer, nlayer and consequently costs).
First of all, I noted that the option output
On Fri, Jun 8, 2012 at 8:26 PM, Michael Barton michael.bar...@asu.edu wrote:
I've run into an odd issue that could be a problem for anyone needing precise
calculations from a landsat (or possibly other) image.
I have a landsat ETM image with a resolution of 28.5m for the bands 1-5, 7
and
Hi Martin,
I find the newly introduced level 3 for topology confusing because 1)
level 3 could sometime in the future mean 3D topology, 2) level 3
applies only to PostGIS. Before that change, the open level had the
same meaning independent of the vector format (GRASS, PGR, PostGIS).
The open
On Wed, Jun 6, 2012 at 3:27 PM, Martin Landa landa.mar...@gmail.com wrote:
2012/6/6 Martin Landa landa.mar...@gmail.com:
[...]
I was worried about introducing level 3 in this sense, you just made
me sure, that it was not a good idea. I will revert it back to the two
levels (keep level 3 for
Benjamin Ducke wrote:
Theoretically, it wouldn't be very hard to read the labels
from the mapset in which SEXTANTE is storing the (temporary)
GRASS datasets; they are saved as plain ASCII there.
However, the host GIS for SEXTANTE must then somehow deal
with this additional data in some
On Tue, May 29, 2012 at 5:23 PM, Eric Momsen eric.mom...@gmail.com wrote:
On Tue, May 29, 2012 at 5:08 AM, Moritz Lennert
mlenn...@club.worldonline.be wrote:
On 28/05/12 06:14, Eric Momsen wrote:
On Sat, May 26, 2012 at 8:10 AM, Moritz Lennert
mlenn...@club.worldonline.be
On Thu, May 24, 2012 at 7:29 PM, Eric Momsen eric.mom...@gmail.com wrote:
Hi,
Thanks everyone for the nice greetings, I'm very impressed with how polite
and helpful the GRASS community is.
There is a wiki [1] and source code repository [2] for the Image
Segmentation - Google Summer of Code
Damien O'Grady wrote:
Hi there
I would like to contribute a script that I have used in my research to
the broader field. The script carries out linear regression, except
that rather than using two rasters for the x and y variables, it uses
any number of pairs of rasters, allowing the
Glynn Clements wrote:
Markus Metz wrote:
With WORKERS=1, the r.mapcalc result is identical to pthreads
disabled, i.e. correct. Do you need more info?
More info:
I think the bug is not caused by the combination of pthreads with
eval(), min(), or max(), but rather when the same raster
Markus Metz wrote:
Glynn Clements wrote:
Markus Metz wrote:
I am observing corrupted output from r.mapcalc in trunk if compiled
--with-pthread. The result is not identical to the one obtained
--without-pthread. The mapcalc expression included the functions
eval(), min(), and max(), in case
On Thu, May 17, 2012 at 7:33 AM, Glynn Clements
gl...@gclements.plus.com wrote:
Markus Metz wrote:
I am observing corrupted output from r.mapcalc in trunk if compiled
--with-pthread. The result is not identical to the one obtained
--without-pthread. The mapcalc expression included
I am observing corrupted output from r.mapcalc in trunk if compiled
--with-pthread. The result is not identical to the one obtained
--without-pthread. The mapcalc expression included the functions
eval(), min(), and max(), in case that helps. Open a ticket?
Markus M
Hi all,
in grass7 addons [0], there is a new version of v.net.salesman with
optional tour optimization. The current algorithm to find the shortest
tour is heuristic and often does not find the optimal tour for more
than 10 nodes to visit. The optimization methods available are
bootstrapping and a
On Tue, May 1, 2012 at 5:01 PM, Glynn Clements gl...@gclements.plus.com wrote:
Markus Neteler wrote:
Author: mmetz
Date: 2012-05-01 01:37:26 -0700 (Tue, 01 May 2012)
New Revision: 51583
Modified:
grass/trunk/vector/v.buffer/Makefile
Log:
add again GEOSLIBS ??? should be
On Thu, Apr 12, 2012 at 7:14 PM, Luca Delucchi lucadel...@gmail.com wrote:
2012/4/12 Martin Landa landa.mar...@gmail.com:
Hi,
`g.mapset` has currently several options to set/add/remove mapsets
from the search path
mapset Name(s) of existing mapset(s)
addmapset Name(s) of
On Wed, Apr 11, 2012 at 12:19 AM, Michael Barton michael.bar...@asu.edu wrote:
In GRASS 7, how can you fix the following error?
Coor file of vector map coast3@SAA2012_survey_analysis is larger than it
should be (154662962 bytes excess)
That can happen if a module exists with an error before
The one-cell areas are correct, at least within the logic of vector
topology. If you used r.to.vect with the -v flag, the one-cell areas
will have the same category like the neighboring areas belonging to
the same basin, that is, area calculations for basins done with
v.to.db will be correct and
On Wed, Apr 4, 2012 at 8:11 AM, Moritz Lennert
mlenn...@club.worldonline.be wrote:
On 04/04/12 07:56, Michael Barton wrote:
I'm trying to do a dissolve but keep getting an error saying that it
only works with integer or string columns. But the column I'm using for
the dissolve IS string.
On Mon, Apr 2, 2012 at 6:54 PM, stepan.turek stepan.tu...@seznam.cz wrote:
Hello,
I would like to introduce my topic for GSoC.
My proposal for GSoC is porting of module i.ortho.photo into GRASS 7. The
module is based on x monitors, which support was removed from
GRASS 7, so
it is
On Sun, Apr 1, 2012 at 12:16 AM, Pietro peter.z...@gmail.com wrote:
Hi everyone!
I'm Pietro Zambelli a ph.D student of Trento University, I would like
to apply to the GSoC, my idea in short is: extend the python GRASS API
to make it more pythonic :-).
I would like to interact with region,
On Sun, Mar 25, 2012 at 2:50 PM, matteo poletti pollo1...@yahoo.it wrote:
Hi,
I am a 2th year student in Compuer Science at the University of Trento, in
Italy. I would like to apply for Gsoc with the GRASS project: I am interested
in implementing parallelization support for some raster
On Wed, Mar 28, 2012 at 1:15 PM, Margherita Di Leo
dileomargher...@gmail.com wrote:
Hi,
I would like to know if it is possible to display labels for a vector layer
using the cartographic composer.
You would need to prepare labels with v.label first, then add the
labels with the label keyword.
Hi,
I have implemented parallelization with openmp in r.proj. On a
quad-core system this gives me a 50% speed increase (twice as fast)
compared to the regular single thread version, tested with all
interpolation methods. The speed increase is consistent and the
results are identical to single
On 3/5/12, Martin Landa landa.mar...@gmail.com wrote:
Hi,
2012/3/5 Markus Neteler nete...@osgeo.org:
-struct ilist *List; ---
-BOUND_BOX box;
+struct boxlist *List;---
+struct bound_box box;
`boxlist` and `bound_box` have been introduced in GRASS 7.
On 3/2/12, Benjamin Ducke bendu...@fastmail.fm wrote:
I think I understand your error. You confuse feature id with category
value. The feature order in the output file depends on the feature
order of the GRASS input vector, and the feature order of the GRASS
input vector has absolutely nothing
On Thu, Mar 1, 2012 at 8:16 PM, Benjamin Ducke bendu...@fastmail.fm wrote:
No, this is because the i-th feature does not need to have category i,
it can have any category and multiple categories. Selecting all
attributes at once for all categories is also not memory-safe for
larger vectors.
On Wed, Feb 29, 2012 at 8:23 AM, Benjamin Ducke bendu...@fastmail.fm wrote:
Dear Devs,
A while ago, I submitted a small patch for v.out.ogr
that moves the SQL SELECT out of the mk_att() function,
so that this costly operation does not have to be
performed multiple times:
In the wxGUI, save display to graphic file is not working in
wingrass and should not work in linux, because SaveToFile uses
wx.BufferedPaintDC() which is in this case illegal because it can only
be used inside of an EVT_PAINT event handler [0], and SaveToFile is
not an EVT_PAINT event handler,
On Fri, Feb 17, 2012 at 1:45 PM, Markus Neteler nete...@osgeo.org wrote:
On Fri, Feb 17, 2012 at 1:25 PM, Helmut Kudrnovsky hel...@web.de wrote:
Hi Markus,
Would it be possible to activate that?
in principle yes, it should work (tested a little bit locally).
AFAIK liblas needs the
On Wed, Feb 15, 2012 at 10:46 PM, Helmut Kudrnovsky hel...@web.de wrote:
what does it means? Any reference? Main channel established in real network
or algorithms of modeling main channel?
the mentionned real mainchannel is the part of real Austrian river network
(i.e. listed in the annual
On Mon, Feb 13, 2012 at 10:27 AM, Andy Wickert wick...@colorado.edu wrote:
Hi developers,
I have just taken a script that uses r.buffer in GRASS 6.4 and moved
it to GRASS 7.0. I am using geographic coordinates, and in GRASS 6.4,
r.buffer (as advertised) worked just fine in meters by doing the
Hi Sören,
2012/2/1 Sören Gebbert soerengebb...@googlemail.com:
Dear developer,
i would like to inform about my plans to modify the header format of
raster3d maps.
The reason is the integration of vertical unit support to distinguish
between 3d spatial voxel cubes
and space time (2d + 1d)
On Mon, Jan 30, 2012 at 11:38 AM, Markus Neteler nete...@osgeo.org wrote:
Hi
to my knowledge no DBMI function exists yet to check if a column exists
in (vector) table.
Suggestions:
db_get_column(driver, hcolumn,key, column);
if (!column)
G_fatal_error(_(Missing column %s
On Mon, Jan 30, 2012 at 12:04 PM, Martin Landa landa.mar...@gmail.com wrote:
Hi,
2012/1/30 Markus Metz markus.metz.gisw...@googlemail.com:
db_get_column(driver, hcolumn,key, column);
if (!column)
G_fatal_error(_(Missing column %s in table %s), hcolumn,
table
I don't really understand why the projection code (one of 0, 1, 2, 3,
99) could be a safety check for mis-copying. A projection is defined
by several parameters, and for UTM, only the zone number is not
sufficient. I would rather discard that info, or keep the full
projection info with each map.
On Fri, Jan 27, 2012 at 9:57 PM, Hamish hamis...@yahoo.com wrote:
Moritz ha scritto:
typemask is not an option for v.centroid, but a grass-plugin
specific parameter. What does it do ?
Paolo:
it filters out the type of maps that appears on the list.
Martin:
AFAIU, it's related to `type`
On Wed, Jan 25, 2012 at 2:46 AM, Martin Landa landa.mar...@gmail.com wrote:
Hi,
2012/1/25 Hamish hamis...@yahoo.com:
Map_info-proj likely needs some work to finish taking advantage of it in
the libs modules, if this assert failsafe is to be used with vector
maps. (for my 2c I think it is
2012/1/25 Sören Gebbert soerengebb...@googlemail.com:
Hi Martin,
many thanks for your example. It works fine with two layer.
But is there a way to add categories to a number of layers larger than
two using the same vector map?
This will add new categories to a new layer, irrespective of how
2012/1/25 Sören Gebbert soerengebb...@googlemail.com:
2012/1/25 Markus Metz markus.metz.gisw...@googlemail.com:
Note that a GRASS layer is defined by the existence of at least one
vector feature with at least one category value in that layer. That
layer may or may not be attached
Hi Sören,
2012/1/25 Sören Gebbert soerengebb...@googlemail.com:
Hi Markus,
2012/1/25 Markus Metz markus.metz.gisw...@googlemail.com:
2012/1/25 Sören Gebbert soerengebb...@googlemail.com:
2012/1/25 Markus Metz markus.metz.gisw...@googlemail.com:
Note that a GRASS layer is defined
Starting GRASS GIS...
Traceback (most recent call last):
File
/home/metz/src/grass-7.0.svn/dist.x86_64-unknown-linux-gnu/etc/gui/wxpython/gis_set.py,
line 41, in module
from gui_core.ghelp import HelpFrame
File
On Tue, Jan 24, 2012 at 5:31 PM, Martin Landa landa.mar...@gmail.com wrote:
Hi,
2012/1/24 Markus Metz markus.metz.gisw...@googlemail.com:
[...]
I think the problem is circularity because core.utils is already imported.
ops, hopefully fixed in r50415.
Working, thanks for the quick fix
2012/1/22 Sören Gebbert soerengebb...@googlemail.com:
Dear all,
what do you think about a new approach of handling vector maps and
assigned database layer?
To access the vector/layer combination in a vector module, the user
must separately define the vector name and its layer number/name.
On Sun, Jan 22, 2012 at 8:26 PM, Martin Landa landa.mar...@gmail.com wrote:
Hi,
2012/1/21 Markus Metz markus.metz.gisw...@googlemail.com:
Yes, because Vect_get_proj_name() and _zone() are typically unset?!
it should be set [1] by Vect__open_old(). Probably when creating
vector map
Martin Landa wrote:
Hi all,
currently dimension of vector map is stored in three different places (vlib)
Map-plus.spidx_with_z (Plus_head) - spatial index
That is coming from GRASS 5 and used as a safety check that the
spatial index has the same dimensions like the coordinates. It can
On Sat, Jan 21, 2012 at 7:31 PM, Markus Neteler nete...@osgeo.org wrote:
GRASS 6.4.2svn (piemonte_utm32_wgs84):/grassdata v.info beni_urbanistici
++
| Layer: beni_urbanistici
On Wed, Jan 18, 2012 at 10:50 PM, Martin Landa landa.mar...@gmail.com wrote:
Hi,
ids of area boundaries can be negative (N2-N1), I think that
Vect_get_area_boundaries() should return list of non-negative ids [1].
Vect_list_append(List, abs(line));
Similar for Vect_get_isle_boundaries() or
current working directory
in a GRASS environment variable?
Markus M
Helena
On Jan 12, 2012, at 9:33 AM, Markus Metz wrote:
Would there be interest to have in the wxGUI the possibility to change
the current working directory for a GRASS session? By default this is
under windows the documents
Would there be interest to have in the wxGUI the possibility to change
the current working directory for a GRASS session? By default this is
under windows the documents and settings folder of the current user,
but project-related data and output may well be somewhere else. This
somewhere else
On Tue, Jan 10, 2012 at 1:03 PM, Jan Trochta j.troc...@gmail.com wrote:
Hi Folks,
I am try to use GRASS7 SVN on win 7. I tested new modul r.viewshed on
large dataset. But some problem with memory.
not shure if it is my mistake or bug.
Jan Trochta
The memory-related warnings can be ignored.
2012/1/4 Sören Gebbert soerengebb...@googlemail.com:
2012/1/4 Martin Landa landa.mar...@gmail.com:
Hi,
2011/12/31 Sören Gebbert soerengebb...@googlemail.com:
great! Just a small note, maybe we should follow same naming
convention, see `r.resamp.interp`.
Oh what a pity, interpol sounds so
When trying to install an extension in trunk wingrass, I get an error
that the requested addon is not found because the url used is
http://wingrass.fsv.cvut.cz/grass70/addons7.0.svn
which should be
http://wingrass.fsv.cvut.cz/grass70/addons
Commenting out lines 650,651 in
On Wed, Jan 4, 2012 at 6:24 PM, Martin Landa landa.mar...@gmail.com wrote:
Hi,
2012/1/4 Markus Metz markus.metz.gisw...@googlemail.com:
When trying to install an extension in trunk wingrass, I get an error
that the requested addon is not found because the url used is
hopefully fixed
:
1. r.grow by one cell on area of interest. (It's an important step. Thanks
to Markus Metz for this tip.) Time taken by the module: approximately 2
hours.
2. r.stream.extract on my area of interest.(42000*42000 cells) with 100
sq.km. as threshold (12345 in number of cells.)
Above you said
in trunk r49877 the GUI fails with
Traceback (most recent call last):
File
/home/metz/src/grass-7.0.svn/dist.x86_64-unknown-linux-gnu/etc/gui/wxpython/wxgui.py,
line 34, in module
from lmgr.frame import GMFrame
File
trunk because the imagery lib does a better
job at transforming coordinates.
Markus M
On Fri, Dec 23, 2011 at 11:40 AM, Markus Metz
markus.metz.gisw...@googlemail.com wrote:
in trunk r49877 the GUI fails with
Traceback (most recent call last):
File
/home/metz/src/grass-7.0.svn/dist.x86_64
The easiest way to create a different GUI is probably to write a
simple script (bash for GRASS 6, Python for GRASS 7) where you can
change the name of options and in what GUI section they are to appear,
and then within the script create the command line for the regular
r.watershed and execute that
On Mon, Dec 19, 2011 at 6:13 AM, Markus Neteler nete...@osgeo.org wrote:
On Sun, Dec 18, 2011 at 12:07 PM, Markus Metz
markus.metz.gisw...@googlemail.com wrote:
On Wed, Nov 30, 2011 at 10:24 PM, Dylan Beaudette
debeaude...@ucdavis.edu wrote:
Just noticed a nasty bug when using v.db.dropcolumn
2011/12/19 Anna Kratochvílová kratocha...@gmail.com:
Hi,
I can't compile grass7, r49838
Anna
Errors in:
/usr/local/src/trunk/vector/v.rectify
Please try r49839
Markus M
anna@dell-desktop:/usr/local/src/trunk/vector/v.rectify$ make
gcc -g -Wall -Werror-implicit-function-declaration
On Wed, Nov 30, 2011 at 10:24 PM, Dylan Beaudette
debeaude...@ucdavis.edu wrote:
Just noticed a nasty bug when using v.db.dropcolumn and v.db.join with a
sqlite back-end. This seems to happen whenever a table is modified using the
'coltypes' as reported by the GRASS-DB API:
Please try trunk
On Sun, Dec 18, 2011 at 6:13 PM, Mohammed Rashad
mohammedrasha...@gmail.com wrote:
On Sun, Dec 18, 2011 at 9:13 PM, Martin Landa landa.mar...@gmail.com
wrote:
2011/12/18 Mohammed Rashad mohammedrasha...@gmail.com:
echo /usr/lib/grass64/lib /etc/ld.so.conf
ldconfig
Hi Hamish
I
On Sun, Dec 18, 2011 at 7:30 PM, Martin Landa landa.mar...@gmail.com wrote:
Hi,
2011/12/17 Hamish hamis...@yahoo.com:
btw, my current feeling about the ~/.grass$MAJOR/addons$MAJOR.$MINOR.$BUGVER
specific path to protect from binary GIS_H incompatibility is that it
may be better to create a
On Wed, Dec 14, 2011 at 8:16 AM, Maris Nartiss maris@gmail.com wrote:
OK. When creating a new test dataset I understood where's the problem:
v.clean rmdupl will remove duplicate geometries and will merge
categories resulting in single geometry, multiple categories
(acceptable in GRASS)
On Mon, Dec 12, 2011 at 5:29 PM, Dylan Beaudette
debeaude...@ucdavis.edu wrote:
On Friday, December 02, 2011, Markus Metz wrote:
On Fri, Dec 2, 2011 at 5:36 AM, Dylan Beaudette
dylan.beaude...@gmail.com wrote:
On Thu, Dec 1, 2011 at 1:25 AM, Markus Metz
markus.metz.gisw...@googlemail.com
Hamish wrote:
Michael wrote:
I lost the previous thread but wanted to respond
to your question about which modules might
benefit from speedup.
In our recursive landscape evolution module
(r.landscape.evol.py), the two GRASS modules that
take the most time are r.watershed, r.stats, and
On Mon, Dec 5, 2011 at 11:30 AM, Hamish hamis...@yahoo.com wrote:
Hamish:
wrt r.walk: I would think to start with parallelizing r.cost, then
porting the method over to r.walk. Both modules use the segment
library, so coding it to process each segment in its own thread
seems like the way
G. Allegri wrote:
I resume (first as a repeat to myself) what I've learned from the various
email on the topic
Vectors can be:
LEVEL 1:
- no topology - very limited use
LEVEL 2:
- unclean topology - limited use
- clean topology - full support
I previously thought that LEVEL 2 was
Hamish wrote:
Markus Neteler wrote:
how about replacing r.los with r.viewshed?
needs fixing:
grass65/dist.i686-pc-linux-gnu/include/grass/iostream/replacementHeapBlock.h:146:
warning: 'str' may be used uninitialized in this function
(3 times).
Did you ever have a look at the compiler
On Fri, Dec 2, 2011 at 5:36 AM, Dylan Beaudette
dylan.beaude...@gmail.com wrote:
On Thu, Dec 1, 2011 at 1:25 AM, Markus Metz
markus.metz.gisw...@googlemail.com wrote:
Dylan Beaudette wrote:
Just noticed a nasty bug when using v.db.dropcolumn and v.db.join with a
sqlite back-end. This seems
Dylan Beaudette wrote:
Just noticed a nasty bug when using v.db.dropcolumn and v.db.join with a
sqlite back-end. This seems to happen whenever a table is modified using the
'coltypes' as reported by the GRASS-DB API:
Here are the coltypes reported from a vector newly imported
Roger Bivand wrote:
Hi,
I first tried 6.4.2 RC2, now also checked out SVN 49406, with the same
result. With fresh Fedora 16, building from source (with 6.4.1 the proj
arguments were never needed), there is trouble loading the GUI:
wxNviz has been disabled only 3 days ago in 6.4, latest svn
Martin Landa wrote:
Hi,
2011/11/10 Michael Barton michael.bar...@asu.edu:
I think this is a good idea. The only thing is that the proposed directory
structure seems a bit over-complicated. To actually make a change, fix a
bug, or add a new feature, it is necessary to alter code in several
Sören Gebbert:
Hi all,
i agree with Martins point of view. Having just a single flag -g to
print all available information in shell style makes IMHO much more
sense. It reduces the need for many flags which may change over time
and which confuses module developer and API designer.
Having
Hamish wrote:
Martin wrote:
shrug, `-g` is mainly used for shell script output,
I think it would be better update `r.info` and `v.info` to
follow this logic, g.region is an exception. You are going to
the opposite direction!
AFAIR g.region was the original, using -g to display region
Martin Landa wrote:
2011/11/9 Martin Landa landa.mar...@gmail.com:
At this stage I would like to propose more structured layout based on
several packages (core, gui_core, forms, lmgr or mapdisp) and non-core
sub-packages in `modules` package.
probably I would replace `modules` with something
Benjamin Ducke wrote:
Does v.clean currently check and ensure that
all vertices of a polygon lie in the same plane?
Also if the vertices have Z coordinates?
No. GRASS vector topology is pure 2D, Z coordinates are only dragged
along while cleaning.
Markus M
701 - 800 of 1175 matches
Mail list logo
