On Mon, Feb 18, 2013 at 10:39 PM, Vaclav Petras wenzesl...@gmail.com wrote:
On 18 February 2013 20:08, Markus Metz markus.metz.gisw...@gmail.com wrote:
On Mon, Feb 18, 2013 at 6:51 PM, Vaclav Petras wenzesl...@gmail.com wrote:
On 18 February 2013 15:34, Martin Landa landa.mar...@gmail.com wrote
On Tue, Feb 19, 2013 at 11:25 AM, Markus Neteler nete...@osgeo.org wrote:
On Mon, Feb 18, 2013 at 11:03 PM, Markus Metz
markus.metz.gisw...@gmail.com wrote:
On Mon, Feb 18, 2013 at 10:39 PM, Vaclav Petras wenzesl...@gmail.com wrote:
On 18 February 2013 20:08, Markus Metz markus.metz.gisw
On Tue, Feb 19, 2013 at 1:14 PM, Anna Kratochvílová
kratocha...@gmail.com wrote:
On Tue, Feb 19, 2013 at 1:07 PM, Markus Metz
markus.metz.gisw...@gmail.com wrote:
On Tue, Feb 19, 2013 at 11:25 AM, Markus Neteler nete...@osgeo.org wrote:
On Mon, Feb 18, 2013 at 11:03 PM, Markus Metz
On Wed, Feb 20, 2013 at 3:27 PM, Nikos Alexandris
n...@nikosalexandris.net wrote:
On Wednesday 20 of February 2013 13:31:07 Nikos Alexandris wrote:
Greetings to the dev-list.
I successfully tested i.histo.match, by feeding it with 12 Landsat scenes
(working on identical bands, different
On Wed, Feb 20, 2013 at 4:19 PM, Nikos Alexandris
n...@nikosalexandris.net wrote:
Nikos Alexandris:
Markus Metz wrote:
For rescaling to 0-1000, you could try something like
r.mapcalc bandX_int = round(1000 * bandX)
Nice! But I wonder why round-ing is required?
rounding is not required
On Mon, Feb 25, 2013 at 2:49 AM, Newcomb, Doug doug_newc...@fws.gov wrote:
I've been playing with generating surfaces at home on an 8 core AMD vishera
system 3.5 ghz Ubuntu 12.04 system with G7 using this point layer:
Your point layer extents:
|
| N: 694901.76S:
On Mon, Feb 25, 2013 at 6:14 AM, Hamish hamis...@yahoo.com wrote:
Hi,
for v.surf.bspline my plan was to put each of the data subregions
in their own thread
Be aware that the order of the subregions matters right now. You will
need to rewrite lib/lidar and all modules that use the lidarlib in
On Wed, Feb 27, 2013 at 2:42 PM, Margherita Di Leo
dileomargher...@gmail.com wrote:
Hi,
A group of colleagues need to use for several runs r.cost with the really
useful option nearest (Name for output raster map with nearest start
point) which is present in GRASS7. The problem is that for
On Fri, Mar 1, 2013 at 9:42 PM, Markus Neteler nete...@osgeo.org wrote:
On Thu, Feb 28, 2013 at 6:04 AM, Helena Mitasova hmit...@ncsu.edu wrote:
I think that is a great project - Soeren thanks for proposing the idea and
volunteering as a mentor,
I fully agree!
+1
Markus M
I would like to propose a project for the next Google Summer of Code:
The current implementation of Vect_break_lines() is causing a lot of
headache for larger vector maps with high spatial detail.
Vect_break_lines() is already much faster in G7 than in G6, but still
sometimes so slow that the
On Fri, Mar 15, 2013 at 12:01 PM, Markus Neteler nete...@osgeo.org wrote:
(please keep this on the list)
On Fri, Mar 15, 2013 at 7:55 AM, Ivan Barka ivan.ba...@gmail.com wrote:
2013/3/14 Markus Neteler nete...@osgeo.org
what's inside of this directory?
On Fri, Mar 15, 2013 at 8:38 PM, Margherita Di Leo
dileomargher...@gmail.com wrote:
Hi all,
trying to rescale a map to 0:255 range, I run:
r.univar -g map
n=9599576
null_cells=0
cells=9599576
min=-1.55537462234497
max=274.231811523438
range=275.787186145782
mean=96.915776629461
Please make distclean before creating the GRASS 7 source snapshot.
Thanks!
Markus M
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
On Sun, Mar 17, 2013 at 11:29 AM, Markus Neteler nete...@osgeo.org wrote:
On Sun, Mar 17, 2013 at 10:52 AM, Markus Metz
markus.metz.gisw...@gmail.com wrote:
Please make distclean before creating the GRASS 7 source snapshot.
I guestimate that you mean the cronjobs.
I guestimate so too
On Sun, Mar 17, 2013 at 11:08 PM, Glynn Clements
gl...@gclements.plus.com wrote:
Markus Neteler wrote:
r39731 re-wrote it to use $host. Rather than trying to figure out the
correct $host value for each possible system (few of which were
available for testing), the sections for unused
I like the idea of a tech-preview release of GRASS7!
I think that no more (or at least not many) major changes will go into
GRASS 7, apart from the wxGUI code base. Therefore it would IMHO be
very beneficial to get more feedback on GRASS 7 in order to detect and
fix remaining bugs.
I also like
On Tue, Mar 19, 2013 at 6:24 PM, Patrice Dumas pertu...@free.fr wrote:
On Tue, Mar 19, 2013 at 02:39:33PM +0100, Anna Kratochvílová wrote:
Hi all,
I would like to change minimal required version of wxPython [1].
Currently we support (theoretically) version 2.8.1.1 (released 2007).
I suggest
does
not work with GRASS 7, only gmake (GNU make) works with GRASS 7.
Markus M
thanks for any help
Ivan
2013/3/18 Markus Metz markus.metz.gisw...@gmail.com
On Sun, Mar 17, 2013 at 11:08 PM, Glynn Clements
gl...@gclements.plus.com wrote:
Markus Neteler wrote:
r39731 re-wrote
On Wed, Mar 20, 2013 at 11:08 AM, Markus Metz
markus.metz.gisw...@gmail.com wrote:
On Wed, Mar 20, 2013 at 10:17 AM, Ivan Barka ivan.ba...@gmail.com wrote:
Hi devs,
so now I can configure G7 (revision 55464) on AIX 7.1 by command:
export PATH=$PATH:$HOME/apps/bin
CFLAGS=-lstdc
Hi Martin,
what is the reason for r54684? It breaks a core functionality, i.e.
the output of vector_columns in lib/python/scripts/vector.py has now
changed and various scripts rely on that output. I have reverted
r54684 in 55475. The commit comment does not make sense to me because
What is the reason to have a spin control for floating point values?
Could the spin control at least not use the number but the significant
digits (same like printing with %g) for spinning? E.g. for 0.0001
I see 0.000 which is wrong. IMHO the spin control should be reverted
to text input.
On Thu, Mar 21, 2013 at 8:53 PM, Anna Kratochvílová
kratocha...@gmail.com wrote:
On Thu, Mar 21, 2013 at 1:11 PM, Martin Landa landa.mar...@gmail.com wrote:
Hi,
2013/3/21 Markus Metz markus.metz.gisw...@gmail.com:
What is the reason to have a spin control for floating point values?
Could
On Fri, Mar 22, 2013 at 5:28 AM, Glynn Clements
gl...@gclements.plus.com wrote:
Markus Neteler wrote:
grass-7.0.svn/lib/datetime make
o
/afs/cluster/myuser/private/software/grass-7.0.svn/dist.powerpc-ibm-aix5.3.0.0/lib/libgrass_datetime.7.0.svn.so
make: o: Command not found
This
On Sat, Mar 23, 2013 at 7:01 PM, Martin Landa landa.mar...@gmail.com wrote:
Hi,
I am trying to find a way how to determine if an area forms an isle
using vlib API? Eg.
$ v.buffer in=roadsmajor out=rb dist=1000
produces
17 areas (1 area with category + 16 areas (without categories) forms
On Sat, Mar 23, 2013 at 5:37 PM, Martin Landa landa.mar...@gmail.com wrote:
Hi,
2013/3/21 Markus Metz markus.metz.gisw...@gmail.com:
what is the reason for r54684? It breaks a core functionality, i.e.
the output of vector_columns in lib/python/scripts/vector.py has now
changed and various
On Mon, Mar 25, 2013 at 2:09 PM, Vaclav Petras wenzesl...@gmail.com wrote:
Hi,
On 25 March 2013 09:49, Markus Metz markus.metz.gisw...@gmail.com wrote:
On Sat, Mar 23, 2013 at 5:37 PM, Martin Landa landa.mar...@gmail.com wrote:
Hi,
2013/3/21 Markus Metz markus.metz.gisw...@gmail.com:
what
On Tue, Mar 26, 2013 at 8:39 AM, Rashad M mohammedrasha...@gmail.com wrote:
Hi,
i.pca creates 6 raster maps for 6 input raster
eg:
i.pca
in=lsat7_2002_10,lsat7_2002_20,lsat7_2002_30,lsat7_2002_40,lsat7_2002_50,lsat7_2002_70
\
out=lsat7_2002_pca
I have a doubt here
Does the
On Tue, Mar 26, 2013 at 10:25 AM, Rashad M mohammedrasha...@gmail.com wrote:
On Tue, Mar 26, 2013 at 2:44 PM, Markus Metz markus.metz.gisw...@gmail.com
wrote:
On Tue, Mar 26, 2013 at 8:39 AM, Rashad M mohammedrasha...@gmail.com
wrote:
Hi,
i.pca creates 6 raster maps for 6 input
On Tue, Mar 26, 2013 at 1:00 PM, Martin Landa landa.mar...@gmail.com wrote:
Hi,
2013/3/25 Markus Metz markus.metz.gisw...@gmail.com:
[...]
All areas also form isles. You probably want to skip areas that are
part of isles which in turn are inside another area. The easiest way
I
@ row=0, col=0
P1= 21
P2= 112
mean=79.925
output= 138.4471
input= 72
Any thoughts?
You need to disable rescaling of the PC scores with i.pca rescale=0,0
Markus M
On Tue, Mar 26, 2013 at 4:54 PM, Markus Metz markus.metz.gisw...@gmail.com
wrote:
On Tue, Mar 26, 2013 at 12:10
, 2013 at 7:40 PM, Markus Metz markus.metz.gisw...@gmail.com
wrote:
On Tue, Mar 26, 2013 at 1:21 PM, Rashad M mohammedrasha...@gmail.com
wrote:
It seems like values are different using the forumla. I can provide a
test
case if you need
i tried this:
i.pca in=lsat7_2000_10
On Wed, Mar 27, 2013 at 10:00 PM, Markus Neteler nete...@osgeo.org wrote:
On Wed, Mar 27, 2013 at 8:18 PM, Markus Metz
markus.metz.gisw...@gmail.com wrote:
On Wed, Mar 27, 2013 at 2:50 PM, Ivan Barka ivan.ba...@gmail.com wrote:
Hi devs,
I tried again recent grass7 on AIX 7.1 with gcc.
I
r.in.gdal imports GDAL GDT_Float64 (64 bit floating point) as GRASS
FCELL (32 bit floating point). This leads to surprisingly large
differences between an original DCELL raster map and the re-import of
that map:
# nc_spm_08 dataset
g.region -p rast=elev_state_500m@PERMANENT res=100
On Thu, Apr 4, 2013 at 10:21 AM, Martin Landa landa.mar...@gmail.com wrote:
Hi,
2013/4/4 Markus Neteler nete...@osgeo.org:
On Thu, Nov 15, 2012 at 5:23 PM, Markus Neteler nete...@osgeo.org wrote:
since the r.stream.* modules are continuously requested and IMHO
sufficiently
tested
On Thu, Apr 4, 2013 at 9:39 PM, Benjamin Ducke bendu...@fastmail.fm wrote:
On 04/04/2013 09:15 PM, Hamish wrote:
Markus Metz wrote:
I changed r.in.gdal in r55625 such that GDAL GDT_Float64 is
now imported as GRASS DCELL (64 bit floating point). The
original and the
re-import are now
On Thu, Apr 4, 2013 at 9:39 PM, Benjamin Ducke bendu...@fastmail.fm wrote:
On 04/04/2013 09:15 PM, Hamish wrote:
Markus Metz wrote:
I changed r.in.gdal in r55625 such that GDAL GDT_Float64 is
now imported as GRASS DCELL (64 bit floating point). The
original and the
re-import are now
On Sat, Apr 6, 2013 at 6:27 PM, Martin Landa landa.mar...@gmail.com wrote:
Hi,
libgis defines
/* error codes */
#define G_FATAL_EXIT0
#define G_FATAL_PRINT 1
#define G_FATAL_RETURN 2
These defines are used by a few functions, eg.
G_check_input_output_name(). Other candidates
On Sun, Apr 7, 2013 at 11:21 AM, Martin Landa landa.mar...@gmail.com wrote:
Hi,
2013/4/6 Markus Metz markus.metz.gisw...@gmail.com:
These defines are used by a few functions, eg.
G_check_input_output_name(). Other candidates could eg.
Vect_open_old() and similar functions (eg. call G__error
On Fri, Apr 5, 2013 at 8:55 AM, Glynn Clements gl...@gclements.plus.com wrote:
Markus Metz wrote:
The range of the differences between the original and the re-import is
min=-6.10348170084762e-05
max=6.10349170528934e-05
which is magnitudes larger than the 32 bit floating point precision
On Sun, Apr 7, 2013 at 10:47 PM, Markus Neteler nete...@osgeo.org wrote:
On Sat, Apr 6, 2013 at 5:15 PM, epi massimodisa...@gmail.com wrote:
...
GRASS 7.0.svn (utm19N_wgs84):/home/epy r.fillnulls input=dtm1
output=dtm1fill --overwrite
Using RST interpolation...
Locating and isolating NULL
On Mon, Apr 8, 2013 at 11:44 AM, jos...@abo.fi wrote:
I discovered the following in r.watershed/ram/slope_len.c where the slope
length is calculated given two cell positions in the raster.
if (r == dr)
res = window.ns_res;
else if (c == dc)
res = window.ew_res;
else
res =
I found a rather cryptic integer overflow when importing double
precision attributes into a dbf table: the values are recognized as
integer if there are no decimal places, e.g. 4294967296. The proposed
fix for trunk is
---
Index: lib/db/sqlp/sqlp.l
On Mon, Apr 8, 2013 at 11:58 AM, Glynn Clements
gl...@gclements.plus.com wrote:
Markus Metz wrote:
I think I understand. If the largest values are in the range of 2^6 -
2^7, the ULP would have a magnitude of 2^-17 ~= 7.629395e-06?
Yes.
I am
asking because lately I observed slightly
On Wed, Apr 10, 2013 at 11:44 AM, Martin Landa landa.mar...@gmail.com wrote:
Hi all,
`v.out.ascii` (G7) doesn't export features without categories.
v.random out=n n=10 --o
v.category in=n out=n1 opt=del cat=-1 --o
v.out.ascii n1
WARNING: No points found, nothing to be exported
Is there
On Wed, Apr 10, 2013 at 2:58 PM, Glynn Clements
gl...@gclements.plus.com wrote:
Hamish wrote:
Markus Metz wrote:
Yes, but I would like to suggest a method to fix at least
floating-point rounding errors, wherever they come from.
a bit of a devil's advocate question: how could you ensure
On Wed, Apr 10, 2013 at 9:17 PM, Martin Landa landa.mar...@gmail.com wrote:
Hi,
2013/4/10 Markus Metz markus.metz.gisw...@gmail.com:
Is there any reason why `v.out.ascii` ignores features without
category? I would suggest to export also features without categories.
Probably also to add new
On Sat, Apr 13, 2013 at 2:33 PM, Hamish hamis...@yahoo.com wrote:
Markus N wrote:
... since Hamish currently backports more from dev6, I'll
postpone RC3 for some hours or whatever suitable.
thanks, I'm done for now, but there's one outstanding difference
between relbr64 and devbr6 for
On Wed, Apr 17, 2013 at 10:54 AM, Miroslav Talasek
miroslav.tala...@seznam.cz wrote:
hi all
i try make contours from DEM ASTER and i was successfull but contorus is
ugly i try use v.generalze but this function cant change firt and las point
, but some contrours is like loop (first and last
On Thu, May 9, 2013 at 7:17 PM, Newcomb, Doug doug_newc...@fws.gov wrote:
Hi Folks,
I've noticed that for point data sets about 200 million points and above ,
all open windows using the WxGUI are frozen when I use commands that call
v.category on the back end ( v.info, v.surf.rst, etc) until
PLEASE test before committing changes. Or carefully read the current
code base. For future reference: vector topology is optional and reset
if no topology is required. That means you should NOT store
non-topological information in topological structures. Thanks.
Markus M
On Mon, May 13, 2013 at 12:36 PM, Martin Landa landa.mar...@gmail.com wrote:
Hi,
2013/5/13 Martin Landa landa.mar...@gmail.com:
2013/5/13 Markus Metz markus.metz.gisw...@gmail.com:
PLEASE test before committing changes. Or carefully read the current
code base. For future reference: vector
PM, Miroslav Talasek wrote:
is it ok ?
it add new parameter loop_support which would be 1 or 0 for loop line
support in
sliging_averaging algo
On 04/17/2013 12:46 PM, Markus Metz wrote:
On Wed, Apr 17, 2013 at 10:54 AM, Miroslav Talasek
miroslav.tala...@seznam.cz wrote:
hi all
i
On Tue, May 14, 2013 at 4:46 PM, Markus Metz
markus.metz.gisw...@gmail.com wrote:
On Mon, Apr 22, 2013 at 10:40 AM, Miroslav Talasek
miroslav.tala...@seznam.cz wrote:
it this path ok ?
do you use it ?
I have added your loop support in r56252, with slight modifications:
loop support
On Wed, May 15, 2013 at 5:03 PM, Markus Neteler nete...@osgeo.org wrote:
On Wed, May 15, 2013 at 4:26 PM, Markus Metz
markus.metz.gisw...@gmail.com wrote:
On Tue, May 14, 2013 at 4:46 PM, Markus Metz
markus.metz.gisw...@gmail.com wrote:
On Mon, Apr 22, 2013 at 10:40 AM, Miroslav Talasek
On Fri, May 17, 2013 at 4:18 PM, Nikos Alexandris
n...@nikosalexandris.net wrote:
Nikos wrote:
# hm? ok... let's transfer the layer 1 to layer 2, 3
## ...to polygons_tmp -- why is this required?
Because you want to create a new vector map.
v.category polygons option=transfer layer=1,2,3
On Fri, May 17, 2013 at 5:13 PM, Paulo van Breugel
p.vanbreu...@gmail.com wrote:
Hi Glynn and Rainer
Happy to see this exchange of ideas. It would be great if this could be
implemented. Do you think it is useful I make a feature request on the bug
tracker (with link to this email thread) so
On Thu, May 16, 2013 at 11:37 AM, Sören Gebbert
soerengebb...@googlemail.com wrote:
Hi,
2013/5/16 Glynn Clements gl...@gclements.plus.com:
Martin Landa wrote:
recently I have added a standardized option for sampling interpolation
methods [1], based on lib/raster/sample.c and codes defined
On Thu, May 23, 2013 at 10:53 PM, Markus Neteler nete...@osgeo.org wrote:
Hi,
by chance I found this report in the Fedora 19 bugtracker:
FTBFS: segmentation fault in lib/vector/diglib/test.c
https://bugzilla.redhat.com/show_bug.cgi?id=961838
- Segmentation fault, looks like integer
On Fri, May 24, 2013 at 9:42 AM, Markus Neteler nete...@osgeo.org wrote:
On Fri, May 24, 2013 at 8:24 AM, Markus Metz
markus.metz.gisw...@gmail.com wrote:
On Thu, May 23, 2013 at 10:53 PM, Markus Neteler nete...@osgeo.org wrote:
Hi,
by chance I found this report in the Fedora 19 bugtracker
On Sun, May 26, 2013 at 10:32 AM, Anna Petrášová kratocha...@gmail.com wrote:
The problem why you don't see anything when you load both maps is that
flowacc has large extreme values, so the initial view is confused. Anyway
you should be able see something when you adjust the view to some
On Sun, May 26, 2013 at 11:21 AM, Anna Petrášová kratocha...@gmail.com wrote:
On Sun, May 26, 2013 at 11:08 AM, Markus Metz
markus.metz.gisw...@gmail.com wrote:
On Sun, May 26, 2013 at 10:32 AM, Anna Petrášová kratocha...@gmail.com
wrote:
The problem why you don't see anything when you
On Tue, May 28, 2013 at 6:50 AM, Yann Chemin yche...@gmail.com wrote:
Hi,
I am opening a new raster file of nrows 100 and ncols 100
writing a single row with values then closing the file.
I think you can not close the file before you have written all rows.
Markus M
It gives me this
On Tue, May 28, 2013 at 5:38 AM, Yann Chemin yche...@gmail.com wrote:
Hi,
is there a small way to open a new file and set all values to NULL?
The function would be something like Rast_open_new_null(),
Using a module:
r.mapcalc newmap = null()
Using C code:
int row, nrows;
int data_type;
On Wed, May 29, 2013 at 10:07 PM, Martin Landa landa.mar...@gmail.com wrote:
Hi,
2013/5/29 svn_gr...@osgeo.org:
Author: mmetz
Date: 2013-05-29 12:53:39 -0700 (Wed, 29 May 2013)
New Revision: 56493
Modified:
grass/trunk/gui/wxpython/gui_core/dialogs.py
Log:
wxGUI: disable nonsense
On Fri, May 31, 2013 at 10:06 PM, Nikos Alexandris
n...@nikosalexandris.net wrote:
Recently I did some tests (with Pietro Z) using i.segment on an RGB
orthophoto sample. If am not wrong, the module works with groups only.
Correct.
Driven by the discussion
ticket #1984: i.pca should accept
On Sun, Jun 2, 2013 at 8:16 PM, Michael Barton michael.bar...@asu.edu wrote:
Is there a way to create buffers around features that overlap when the
features are near to each other instead of merging?
In GRASS 7, with v.buffer -t
Markus M
___
On Mon, Jun 3, 2013 at 3:30 PM, Johannes Radinger
johannesradin...@gmail.com wrote:
Hi Markus,
Hi others,
I am coming back to the topic of running r.watershed on a rasterized river
network.
As recommended I buffered now my river raster. This river raster is a
thinned distance raster
with
the buffer. This
will create segments leading up to the start point, but excluding the
start point.
Markus M
cheers,
/johannes
On Mon, Jun 3, 2013 at 9:49 PM, Markus Metz markus.metz.gisw...@gmail.com
wrote:
On Mon, Jun 3, 2013 at 3:30 PM, Johannes Radinger
johannesradin...@gmail.com
Hi all,
I have added thin plate spline coordinate transformation to i.rectify,
needed for e.g. level 1 B satellite imagery such as NOAA AVHRR or
ENVISAT MERIS, or maybe also historical maps with unknown but serious
geometric distortions.
Additionally I have modified r.in.gdal a bit: previously
On Sat, Jun 8, 2013 at 8:55 PM, Michael Barton michael.bar...@asu.edu wrote:
I just came across something that is very disturbing.
I imported a batch of points from a CSV file.
2 points have the same geographic location (they are a single archaeological
site occupied at different time
sent again for the list
Switching to grass-dev
Helena Mitasova wrote:
Talking about SVN access - how about granting full SVN access to
Markus Metz to work on r.watershed in GRASS7
- he has not officially requested it but he expressed interest in it
and Markus N. encouraged him to post
dataset for using MFD mode.
h4In-memory mode and disk swap mode/h4
@@ -485,4 +485,4 @@
Markus Metz lt;markus.metz.giswork at gmail.comgt;
p
-iLast changed: $Date: 2008-12-08 10:11:19 +0100 (Mon, 08 Dec 2008) $/i
+iLast changed: $Date: 2008-12-09 10:18:19 +0100 (Tue, 09 Dec 2008) $/i
diff
Hamish wrote:
Glynn:
Is #73 actually a bug, or simply noting that programs which
claim to support TIFF invariably only support a (usually
unspecified) subset of the TIFF standard?
It's really a bug. The heart of it is us not enforcing data type limits.
We are silently allowing the
Michael Barton wrote:
I am running the new r.watershed (SVN from 10 December) and got an
error in calculating the ls factor.
r.watershed elevation=elevation@permanent length.slope=atest_rs_ls
memory=300
ERROR:
Complexity
Arizona State University
Phone: 480-965-6262
Fax: 480-965-7671
www: www.public.asu.edu/~cmbarton
On Dec 20, 2008, at 1:59 AM, Markus Metz wrote:
Michael Barton wrote:
Should r.watershed be giving negative accumulation values?
Yes. Negative accumulation values indicate that these cells
Michael Barton wrote:
This worked. Thanks.
Thanks Glynn, I couldn't figure out where this error came from. Patches
for this bug: no error if length.slope is requested without giving basin
threshold are attached to ticket 398 [1], separately for grass64 and
grass70.
Markus M
[1]
Fedora 8 64bit works too.
Minor complaint:
r.external menu entry missing in tcltk, present in wxpython as
Raster-Develop raster map-Link to GDAL. IMHO this wonderful module
deserves a menu entry also in tcltk :-)
Markus M
Jachym Cepicky wrote:
ubuntu works
j
2008/12/19 William
Michael Barton wrote:
I just updated and compiled today.
In case you have modified front/main.c to fix that length.slope bug,
there may now be a svn conflict in front/main.c. Maybe it works if you
delete front/main.c and svn up again to get a new copy. Then, after
updating, the patch sent
Michael Barton wrote:
On Jan 15, 2009, at 5:22 AM, grass-dev-requ...@lists.osgeo.org wrote:
[...]
Comment (by mmetz):
I have submitted a new version of r.watershed to trunk with various
changes
[...]
Markus,
Can this go into develbranch_6 too?
I hope so:-) But I would like to get the
Helena Mitasova wrote:
I am trying to get to test the new r.watershed but I am stuck at
compiling grass7
(I had it working OK without wxwidgets before I updated)
First, the issue with wxWidgets, when I include --with-wxwidgets
I get
checking whether to use wxWidgets... yes
checking for
I forgot, if gdal is compiled with grass support based on a previous
version, that doesn't work too, you have to compile gdal without grass
support again, then grass7 with gdal support. It's a bit of a hassle but
worth the effort, grass7 is really nice:-)
Markus M
Helena Mitasova wrote:
I
Michael Barton wrote:
On Jan 15, 2009, at 5:22 AM, grass-dev-requ...@lists.osgeo.org wrote:
[...]
Comment (by mmetz):
I have submitted a new version of r.watershed to trunk with various
changes
[..]
Markus,
Can this go into develbranch_6 too?
According to Markus Neteler, not as long
Helena Mitasova wrote:
just a quick note from the first run - it may be better to have SFD as
default so that the same command as in grass63
gives the same result. E.g. running
g.region rast=elevation
r.watershed elevation thresh=1 accum=accum_10K2
drain=draindir_10K2 basin=basin_10K2
Helena Mitasova wrote:
On Jan 17, 2009, at 12:07 AM, Michael Barton wrote:
Markus,
I compiled last night and was able to try this on my Mac this
evening. No problem at all with the North Carolina elev_lid792_1m
DEM. Everything ran very fast, of course--even though it runs at
32bit on
Helena Mitasova wrote:
[...]
Just run it with elevation in nc_spm. The MFD result is actually more
realistic because it simulates the existing
lakes but you would have to do additional processing if you need a
stream network
Have you looked at the stream segments output (option stream)?
In grass7 when zooming out the new display is not centred on the mouse
position, but on the mirror-position of the mouse position e.g. west is
not current[0] but current[0] - self.Map.width
I find this confusing, but maybe this is a matter of taste.
The Zoom function is in
Andreas Hörsken wrote:
I tried to compile grass on Macosx 10.4.11 (Tiger) today an got the
same error message when running configure:
...
checking for gdal-config...
/Library/Frameworks/GDAL.framework/Programs/gdal-config
configure: error: *** Unable to locate GDAL library.
The same
Glynn Clements wrote:
By Euclidified, I mean that the data is in a form such that code
which process it can treat -179 and +181 as being distinct points 360
units apart.
It seems that grass treats -179 and 179 as being 2 units apart, I do not
have to change it to 179 and 181. Latlon coords
Glynn Clements wrote:
Markus Metz wrote:
I think my questioning started because the region settings including map
extends are restricted to the 180 degree lon and 90 degree lat limits
whereas vector operations can exceed these limits causing problems later
on. To make grass handling
Glynn Clements wrote:
Markus Metz wrote:
How about reversing the current policy? Restrict both raster and vector
maps to the 180 degree lon and 90 degree lat limit, that avoids
duplicate features within a map. Allow the region to be set anywhere
between -360 and 360 lon but restrict
Glynn Clements wrote:
Markus Metz wrote:
Do you really mean 360 degrees plus the width of the window? That
would be max 720 degrees?
Wrong window ;)
I'm talking about the buffer/kernel/etc window, i.e. the size=
parameter for r.neighbors, 4 cells for r.proj method=cubic, etc.
E.g
While I looked into possibilities to optimize v.in.ogr I noticed that
grass does not support coor files larger than 2 GB. With topological
information stored in that file, and often many dead lines wasting
space, the coor file can easily exceed 2 GB nowadays. While v.in.ogr was
cleaning one
I tried to understand the grass wiki on Large File Support, sorry for
being a bit late with that!
Glynn Clements wrote:
Markus Metz wrote:
If the coor file size stored in the topo file is indeed needed to
properly process the coor file, the respective variables must be
something else
Glynn Clements wrote:
Markus Metz wrote:
I think I understand. So according to the grass wiki the steps to enable
large file support would be
1) add
ifneq ($(USE_LARGEFILES),)
EXTRA_CFLAGS = -D_FILE_OFFSET_BITS=64
endif
to all relevant Makefiles
Yes. Although this should
Glynn Clements wrote:
Markus Metz wrote:
[...]
How about
extern off_t G_ftell(FILE *fp)
{
#ifdef HAVE_LARGEFILES
return (ftello(fp);
#else
return (ftell(fp);
#endif
}
Yep, other than the extraneous open parenthesis (2 open, 1 close).
Oops, my sloppy
Hamish wrote:
Following r.cost @ 100%, I have changed cseg_open(16, 16, 8) to 256,256,64
locally.
FWIW, I found that r.watershed.seg is fastest with the equivalent of
cseg_open(200, 200, variable number of open segments). It seems
logical to use powers of 2, but 200, 200 is in
Glynn Clements wrote:
lseek() always uses off_t. Originally it used long (hence the name
lseek), but that's ancient history; you won't find such a system
outside of a museum.
_FILE_OFFSET_BITS determines whether off_t is 32 or 64 bits. If it's
64 bits, many of the POSIX I/O functions (open,
Glynn Clements wrote:
Markus Metz wrote:
I like the point of Ivan that off_t is the native type for file offsets.
Could G_fseek then use fseeko whenever fseeko is available (ditto for
ftello)?
Well, that's the general idea. The only advantage of fseek/ftell is
that they are always
Glynn Clements wrote:
I have added G_fseek() and G_ftell() to 7.0 in r35818.
:-)
I got confused by this endian-ness and confused low/high word with
first/second word. With the current code, the low word would be the
second word when doing 2 32bit reads on a 64bit sized buffer,
Glynn Clements wrote:
Markus Metz wrote:
BTW, display of grass7 with cairo appears to be half the speed of
grass65, I think it was faster last week (can't remember the revision).
Not sure if this justifies a complaint.
Almost everything related to display has changed between 6.x
301 - 400 of 1175 matches
Mail list logo
