Hi,
I have a wishlist for r.out.gdal together with a new version (link
below), and would like to put it up for discussion:
Changes in my version are:
Colortable export
A new flag -c is provided to export a colortable, default to no.
Colortables in GeoTIFF files are sometimes not properly
Maciej Sieczka wrote:
Markus Metz pisze:
Nodata value handling
If a nodata value was supplied, this value is tested whether it is
within the range of the selected data type and adjusted if necessary.
Specifying e.g. a nodata value of - and using Byte as data type
(range 0 - 255
Dylan Beaudette wrote:
On Wednesday 20 August 2008, Glynn Clements wrote:
Markus Metz wrote:
r.out.gdal nodata handling could be changed so that the user has to
provide a nodata value if there are NULLs in the raster, otherwise
r.out.gdal aborts with an error.
That's
Hamish wrote:
Markus Metz wrote:
The original version uses very little memory, so assuming that GRASS
runs today on systems where at least 500MB RAM are available I changed
the parameters for the seg mode, more data are kept in memory, speeding
up the seg mode. Looking at other modules
Hi all,
r.watershed.fast is now in the GRASS AddOns svn repository and I added
an entry in the GRASS AddOns wiki page. I hope everything went all right
and is at the proper place: in the svn repository I made a new directory
r.watershed.fast in directory raster and the new entry in the GRASS
As requested in the psc mailing list, I have renamed the new version to
r.watershed2 both in the svn repository and the GRASS wiki. I have read
the request for renaming only now, sorry for the confusion!
Markus
Markus Metz wrote:
Hi all,
r.watershed.fast is now in the GRASS AddOns svn
--+-
Comment (by neteler):
Markus (Metz),
what about integrating your fixes from
http://markus.metz.giswork.googlepages.com/r.out.gdal.conservative.tar.gz
?
Markus
Sure, no objections from my side, I'm using this version only. But
r.out.gdal is a very
in the hope
to support svn change tracking and to avoid the confusion caused by
adding a module that appears new as far as svn is concerned.
Markus Metz
Hamish wrote:
Hi,
I did a bit more syncing between what is now in devbr6 for r.watershed1
and 2.
a minimized diff for review can be found here
Hamish wrote:
Markus Metz wrote:
Actually I wanted to apply the changes of the r.watershed version in
grass-7 to r.watershed2, especially naming of options without points
and uppercase, but didn't get yet to it.
done. ('svn merge' did 99% of the work after devbr6 was solved
Hamish wrote:
Hamish:
see the man page for an example of making a nicely colored accum map
based on standard deviations.
MMetz:
Why not setting colors for accum in the module?
If you like, but a simple linear color model will not work well:
Hmm, it does work with
output.
The color coding of the example image above has been adjusted a bit to
show more detail, but abs log of rainbow looks nice too!
Markus Metz
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Sorry, a mistake in the additional time requirements for MFD on
elev_lid1972_1m:
r.watershed2 with SFD: 0.7 seconds
r.watershed2 with MFD: 1.0 seconds
Markus Metz wrote:
I took the request for MFD support in r.watershed by Helena and Dylan to
heart and implemented it, but still need a few more
on this in
grass7 - do you have SVN commit access?
Helena
On Dec 5, 2008, at 3:02 PM, Markus Metz wrote:
Dylan Beaudette wrote:
On Fri, Dec 5, 2008 at 1:55 AM, Markus Metz [EMAIL PROTECTED] wrote:
I took the request for MFD support in r.watershed by Helena and
Dylan to
heart and implemented
On Sun, Jun 9, 2013 at 2:50 AM, Hamish hamis...@yahoo.com wrote:
Michael wrote:
Here is the command:
v.in.ascii --overwrite input=/Users/cmbarton/sites_out
/sites_out.csv output=sites_test separator=, skip=1 x=15
y=16 cat=0
Here is the csv file:
(got it)
Once imported, take a look at
On Mon, Jun 10, 2013 at 3:11 PM, Glynn Clements
gl...@gclements.plus.com wrote:
I'd suggest using:
int exp;
new_snap = frexp(xmax, exp);
exp -= 52;
new_snap = ldexp(new_snap, exp);
frexp() and ldexp() are C89, don't introduce rounding errors, and
handle
On Mon, Jun 10, 2013 at 10:29 PM, Štěpán Turek stepan.tu...@seznam.cz wrote:
Hi all,
Probably I found bug in nodes cost in vector network analysis (tested in G7,
probably it affects all branches). Problem is in lib/vector/Vlib/net.c:
int cost;
...
(* dglInt32_t)(dglInt32_t) cost
int
On Sun, Jun 16, 2013 at 8:50 PM, Sören Gebbert
soerengebb...@googlemail.com wrote:
Hi,
Nikos is absolutely right, the ideal candidate for spline interpolation in
time for raster maps is r.series.interp. There is no other module that
performs temporal interpolation.
r.hants does temporal
Feeding the test values and the evi(2) formula to r.mapcalc, the
results are more or less in the expected range, still beyond [-1, 1],
but not much. Obviously, there is a bug in i.vi. Furthermore, i.vi is
slower than r.mapcalc. I recommend to replace the C module i.vi with a
i.vi script that calls
On Sun, Jun 16, 2013 at 10:20 PM, Margherita Di Leo
dileomargher...@gmail.com wrote:
Hi,
On Sun, Jun 16, 2013 at 9:19 PM, Markus Metz markus.metz.gisw...@gmail.com
wrote:
On Sun, Jun 16, 2013 at 8:50 PM, Sören Gebbert
soerengebb...@googlemail.com wrote:
Hi,
Nikos is absolutely right
On Mon, Jun 17, 2013 at 10:58 PM, Nikos Alexandris
n...@nikosalexandris.net wrote:
Markus Metz wrote:
Feeding the test values and the evi(2) formula to r.mapcalc, the
results are more or less in the expected range, still beyond [-1, 1],
but not much.
[cut]
Yes, but feeding the suspect
On Wed, Jun 19, 2013 at 6:10 AM, Hamish hamis...@yahoo.com wrote:
Markus N wrote:
- diglib test updated in lib/vector/diglib/
-- still failing there, we try to understand
That has been fixed in 56699, it was related to LFS.
hmm, this is quite similar, I wonder if it is related:
I think I figured it out:
The EVI formula in i.vi is for MODIS. The generic formula is
G * ( nir - red) / (nir + C1 * red - C2 * blue + L)
where G is a gain factor, C1, C2 are coefficients to correct for
aerosol influences in the red band using the blue band and L is the
canopy background
On Thu, Jun 20, 2013 at 6:24 PM, Nikos Alexandris
n...@nikosalexandris.net wrote:
Markus Metz wrote:
I think I figured it out:
The EVI formula in i.vi is for MODIS.
That's precise, EVI is MODIS specific. We should clearly describe this in the
manual (I will try to alter the respective
On Fri, Jun 21, 2013 at 9:58 AM, Luca Delucchi lucadel...@gmail.com wrote:
Hi devs,
just update grass7 and the gui doesn't start, the problem seems
related to missing module g.proj, but I think probably is related to
find_program.
find_program('r.proj','help') and also find_program('r.proj')
On Fri, Jun 21, 2013 at 10:04 PM, Nikos Alexandris
n...@nikosalexandris.net wrote:
Markus Metz wrote:
I think I figured it out:
The EVI formula in i.vi is for MODIS.
Nikos A:
That's precise, EVI is MODIS specific. We should clearly describe this in
the manual (I will try to alter
Markus Metz wrote:
I am pretty sure that the EVI2 formula in i.vi is not cross-sensor,
but also tailored to unscaled MODIS input bands:
EVI2 = G * ( nir - red) / (nir + C1 * red + L)
Hmm, no, it seems that the coefficients for both EVI and EVI2 are
meant for scaled MODIS input bands (top
around this with e.g.:
#include fcntl.h
#undef open
Markus Metz figured it out, fixed locally (see attachment).
Submit or not?
The fix is based on the hack proposed in
http://gcc.gnu.org/ml/gcc-patches/2012-09/msg01957.html
which is IMHO a hack, not a fix. Anyway, the hack has
On Fri, Jun 28, 2013 at 7:13 AM, Markus Neteler nete...@osgeo.org wrote:
On Wed, Jun 26, 2013 at 7:40 PM, Markus Neteler nete...@osgeo.org wrote:
...
Now trying to get shared libraries enabled (almost there).
Also enabled in SVN (thanks to Markus Metz).
Interestingly, when *starting* GRASS
On Fri, Jun 28, 2013 at 9:09 PM, Markus Neteler nete...@osgeo.org wrote:
On Fri, Jun 28, 2013 at 8:29 PM, Markus Metz
markus.metz.gisw...@gmail.com wrote:
On Fri, Jun 28, 2013 at 7:13 AM, Markus Neteler nete...@osgeo.org wrote:
...
How to tell GRASS 7 in configure to pick up the /opt
Try
r.in.gdal input=as_dem_30s.bil output=dem_asia_hydrosheds_30s
# check extents and range
r.info dem_asia_hydrosheds_30s
# set the region
g.region -p rast=dem_asia_hydrosheds_30s
r.colors map=dem_asia_hydrosheds_30s rules=srtm
r.slope.aspect elevation=dem_asia_hydrosheds_30s
On Mon, Jul 1, 2013 at 3:56 PM, Moritz Lennert
mlenn...@club.worldonline.be wrote:
Hi Eric and Markus,
Trying to use i.segment in grass7 checked out and compiled a few days ago
(rev 56918), I came upon the following error and the resulting segments file
was not created. I can file this as a
On Tue, Jul 2, 2013 at 9:58 AM, Moritz Lennert
mlenn...@club.worldonline.be wrote:
On 01/07/13 21:04, Markus Metz wrote:
On Mon, Jul 1, 2013 at 3:56 PM, Moritz Lennert
mlenn...@club.worldonline.be wrote:
Hi Eric and Markus,
Trying to use i.segment in grass7 checked out and compiled a few
On Tue, Jul 2, 2013 at 1:15 PM, Nikos Alexandris
n...@nikosalexandris.net wrote:
a friend needs to use r.cva [0,1] (and r.viewshed [2]).
[2] Module/manual exists only for G7
http://grass.osgeo.org/grass70/manuals/r.viewshed.html, not for G64!
r.viewshed is available as add-on for G6:
For the last two days, the nightly builds for trunk are broken.
Configure fails [0] with
[...]
checking whether to use regex... yes
checking for location of regex includes...
checking for regex.h... no
configure: error: *** Unable to locate regex includes.
I guess some osgeo4w update moved or
2013/7/3 Jürgen E. j...@norbit.de:
Hi Markus,
On Wed, 03. Jul 2013 at 20:17:46 +0200, Markus Metz wrote:
I guess some osgeo4w update moved or removed regex?
AFAICT no. apps/msys/include/regex.h is in still in msys-1.0.11-13 (and
that's from Apr 13th).
Then it seems to be a problem
On Thu, Jul 4, 2013 at 11:13 AM, Moritz Lennert
mlenn...@club.worldonline.be wrote:
As you might have gathered from my other messages on the list, we are
currently running tests of i.segment in our department. A few questions came
up (with my attempts at answers).
***
On Fri, Jul 5, 2013 at 10:02 AM, Blumentrath, Stefan
stefan.blumentr...@nina.no wrote:
Dear all
I am reposting this message, because the problem, that I cannot import lines
from PostGIS is still present in GRASS 7 svn-revision 57009 (and in 6.4.3svn
(older revision) too.)
Do you think this
n50_2013_utm33n.n50_2013_arealdekke_lines
contains polygons...
Markus M
Stefan
-Original Message-
From: Markus Metz [mailto:markus.metz.gisw...@gmail.com]
Sent: 5. juli 2013 10:51
To: Blumentrath, Stefan
Cc: grass-dev@lists.osgeo.org
Subject: Re: [GRASS-dev] v.in.ogr fails to import from
On Sat, Jul 6, 2013 at 4:19 PM, Štěpán Turek stepan.tu...@seznam.cz wrote:
Hi Hamish and Michael,
your questions are connected I will try to explain both.
The scatter plot tool backend is run in same process as wxGUI. If you select
some area in scatter plot, then data from numpy arrays are
On Sun, Jul 7, 2013 at 10:25 AM, Nikos Alexandris
n...@nikosalexandris.net wrote:
Hi devs!
Hope that some advanced Gentoo user is tuned-in. I am trying to compile
grass7_trunk in Funtoo. I managed to get a clean configuration of almost
everything required (except for LAPACK, BLAS and
On Mon, Jul 8, 2013 at 2:18 PM, Moritz Lennert
mlenn...@club.worldonline.be wrote:
After some improvements to the module by MarkusM, I tried again during the
night, but it got stuck again with heavy swapping going on. I'm definitively
giving up to segment the panchromatic image in its entirety
On Thu, Jul 11, 2013 at 1:30 PM, Glynn Clements
gl...@gclements.plus.com wrote:
Allar Haav wrote:
I noticed today that average method in r.neighbours gives an incorrect
value. Let me give you an example:
3) Judging from previous steps, it should be only logical that the
output raster has
On Fri, Jul 12, 2013 at 4:36 PM, Moritz Lennert
mlenn...@club.worldonline.be wrote:
Proxmox(Openvz) container running Debian testing, 200GB disk space, 10GB
RAM, 4 i7 CPUs
g.region -p
projection: 1 (UTM)
zone: 33
datum: wgs84
ellipsoid: wgs84
north: 4876400
south:
On Fri, Jul 12, 2013 at 3:21 PM, Moritz Lennert
mlenn...@club.worldonline.be wrote:
Main issues I see for grass7 currently to get it preview-release ready:
[...]
- LFS handling in Windows
https://trac.osgeo.org/grass/ticket/1131 (not sure I understand where we are
at with this)
Global LFS
On Sat, Jul 13, 2013 at 12:16 PM, Moritz Lennert
mlenn...@club.worldonline.be wrote:
On Fri, July 12, 2013 22:04, Markus Metz wrote:
On Fri, Jul 12, 2013 at 3:21 PM, Moritz Lennert
mlenn...@club.worldonline.be wrote:
Main issues I see for grass7 currently to get it preview-release ready
On Sat, Jul 13, 2013 at 11:47 PM, Hamish hamis...@yahoo.com wrote:
- LFS handling in Windows
https://trac.osgeo.org/grass/ticket/1131
MarkusM:
Global LFS is enabled by default and working on all officially
supported platforms, plus *BSD and some UNIX systems.
Moritz:
That means we can
From within GRASS, only the owner of a mapset is allowed to start a
GRASS session in this mapset, i.e. only the owner of a mapset has
write permissions to this mapset. But a new mapset being a folder in
the file system is created with mode 0777, thus granting write
permissions to all. I suggest to
On Sun, Jul 14, 2013 at 10:42 PM, Hamish hamis...@yahoo.com wrote:
Hi,
Markus M:
From within GRASS, only the owner of a mapset is allowed to start a
GRASS session in this mapset, i.e. only the owner of a mapset has
write permissions to this mapset. But a new mapset being a folder in
the
On Mon, Jul 15, 2013 at 10:04 AM, Moritz Lennert
mlenn...@club.worldonline.be wrote:
On Fri, July 12, 2013 21:59, Markus Metz wrote:
On Fri, Jul 12, 2013 at 4:36 PM, Moritz Lennert
mlenn...@club.worldonline.be wrote:
Proxmox(Openvz) container running Debian testing, 200GB disk space, 10GB
RAM
On Mon, Jul 15, 2013 at 5:55 PM, Glynn Clements
gl...@gclements.plus.com wrote:
Markus Metz wrote:
From within GRASS, only the owner of a mapset is allowed to start a
GRASS session in this mapset, i.e. only the owner of a mapset has
write permissions to this mapset. But a new mapset being
On Mon, Jul 15, 2013 at 11:09 PM, Nikos Alexandris
n...@nikosalexandris.net wrote:
Moritz Lennert wrote:
[..]
time i.segment -w group=pan_r_ir out=seg_weighted_pan_r_ir
threshold=0.01 memory=8192
Loading input bands...
Pass 1:
ERROR: Invalid region id 0
[..]
What could be the
You could try G_OPT_M_DIR. The comment says directory input but it
should also work for output, all it should return is the path to a
folder.
Markus M
On Mon, Jul 15, 2013 at 5:42 PM, Margherita Di Leo
dileomargher...@gmail.com wrote:
Dear Devs,
in r57084 Martin has added standardized
On Tue, Jul 16, 2013 at 10:38 PM, Hamish hamis...@yahoo.com wrote:
Markus Metz wrote:
In this case, would it be ok to enforce umask to 0022 in the start up
script?
two rules to thumb:
we shouldn't restrict others to the limits of our own imagination.
(if someone wants to set their umask
Please update v.unpack accordingly.
Thanks,
Markus M
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
On Tue, Jul 23, 2013 at 11:10 PM, Martin Landa landa.mar...@gmail.com wrote:
Hi,
2013/7/23 Markus Metz markus.metz.gisw...@gmail.com:
Please update v.unpack accordingly.
I checked `v.unpack`. What exactly is not working? I haven't found any
problem related to db [1] and proj file [2
I think the confusion arises because G_getl2(char *buf, int n, FILE *
fd) reads in at most n - 1 characters, not n characters. The next
character is always set to '\0' and guaranteed to be at most the n-th
character. That also means that G_getl() does not check if the buffer
is large enough to
On Fri, Sep 13, 2013 at 5:02 PM, Moritz Lennert
mlenn...@club.worldonline.be wrote:
Hi,
In grass64release, running:
v.distance from=hospitals@PERMANENT to=hospitals@PERMANENT col=to_cat,dist
up=cat,dist -p dmin=0.0001
gives me an almost instant response.
In grass7, it takes _much_
Glynn Clements wrote:
FWIW, I suggest changing the existing behaviour [of G_getl2()] so that it
always
reads an entire line, even if it can't store it all. IOW, read until
EOL or EOF, stop storing characters once the buffer is full.
+1
Unlike with fgets(), which stores the line terminator
On Wed, Sep 18, 2013 at 11:41 AM, Moritz Lennert
mlenn...@club.worldonline.be wrote:
On 18/09/13 10:51, Luca Delucchi wrote:
On 17 September 2013 22:10, Markus Netelernete...@osgeo.org wrote:
Hi,
I came across this question:
On Thu, Sep 19, 2013 at 9:15 AM, Moritz Lennert
mlenn...@club.worldonline.be wrote:
On 18/09/13 16:24, Markus Metz wrote:
Moritz Lennert wrote:
Here's a little test:
$time v.median in=elev_lid792_randpts
638648.50|220378.50
Should be 638648|220378. It seems that numpy gets
Glynn Clements wrote:
Luca Delucchi wrote:
maybe v.median [0] could help?
Not for large datasets. First, it requires that the data will fit into
RAM. Second, numpy.median() sorts the entire array and takes the
middle value, which is somewhere between O(n.log(n)) for the typical
case and
On Fri, Sep 20, 2013 at 5:38 PM, Markus Metz
markus.metz.gisw...@gmail.com wrote:
Glynn Clements wrote:
Luca Delucchi wrote:
maybe v.median [0] could help?
Not for large datasets. First, it requires that the data will fit into
RAM. Second, numpy.median() sorts the entire array and takes
Markus Neteler wrote:
Hi,
I came across this question:
http://gis.stackexchange.com/questions/71734/how-to-calculate-mean-coordinates-from-big-point-datasets
Please try the new addon v.centerpoint [0]. It calculates various
center points for point clouds, lines, and areas. Standard options
Helena Mitasova wrote:
Markus,
when you are at it, can you also have a look at v.kcv?
http://grass.osgeo.org/grass70/manuals/v.kcv.html
I am wondering whether it works efficiently with lidar data sets (millions of
points) - I heard that it takes forever,
but that was about a year ago and
Glynn Clements wrote:
Markus Metz wrote:
Please try the new addon v.centerpoint [0]. It calculates various
center points for point clouds, lines, and areas. Standard options are
the geometric mean (center of gravity)
That's the arithmetic mean.
The geometric mean of a set of N values
Paulo van Breugel wrote:
I am trying to compile GRASS GIS 7.0 (revision 57836) and I am getting an
error when running make related to v.in.ply and v.out.ply. When running make
in the vector folder, I am getting the following error message:
make: *** v.in.ply: No such file or directory. Stop.
Peter Löwe wrote:
When trying to ingest SEG-Y data (geology/seismics) into a new location via
v.in.ogr (GDAL 1.9.0) this error is thrown since the new location is set by
default (?) to dbf:
[...]
The initial location from which v.in.ogr was invoked was already switched to
a
Have you included -R,/opt/freeware/lib in LDFLAGS? If not, you
probably should. See also GRASS wiki [0], there the entry for AIX 7.x.
Markus M
[0] http://grasswiki.osgeo.org/wiki/Compile_and_Install#AIX
On Mon, Sep 30, 2013 at 9:35 PM, Markus Neteler nete...@osgeo.org wrote:
Hi,
I
Moritz Lennert wrote:
On 30/09/13 09:45, Štěpán Turek wrote:
Hi,
working on integration of turns support into GRASS 7 I see two
possibilities how to integrate creation of the turntable.
New module v.net.turntable can be added,which will manage creation of
the turntable.
There already
Markus Neteler wrote:
PS: if the LAS file is not accessible, r.in.lidar happily segfaults.
My attempts to fix that were yet unsuccessful.
Fixed in r57951,2 for [r|v].in.lidar
Markus M
___
grass-dev mailing list
grass-dev@lists.osgeo.org
Markus Neteler wrote:
One more wish comes to mind (indeed, I started cross-porting but :-)
v.in.lidar comes with a filter (which should perhaps be generalized to
the nth return; or, the last *is* the nth return but then mid could
be more than one in this case?):
Yes, for n returns, the
Javier Martínez-López wrote:
Dear list,
I am trying to run the i.segment function but I always get the same
error during the first pass: 'invalid region id 0'. What does it mean?
can it be solved? I have read some e-mails about this problem but have
found no solution yet. Trying with
We would like to make GRASS GIS portable to 32 bit and 64 bit systems
as well as little endian and big endian systems. To our knowledge, all
combinations of bitness and endianness are supported, with the
exception of 64bit big endian test systems. Therefore we need access
to a 64 bit big endian
Moritz Lennert wrote:
Markus M,
I know this is still very fresh, but I was excited about seeing your
addition to v.voronoi allowing to calculate skeletons and longest lines for
areas. Amongst others, this could be useful for calculating some shape
parameters of polygons for region-based
On Thu, Nov 14, 2013 at 11:15 AM, Hamish hamis...@yahoo.com wrote:
Hi,
I just added in the dev branches two new flags for v.what.rast.
[...]
The second flag changes the default containing-grid-cell method to a
weighted avg. of the 4 nearest raster cell centers (IDW). The search radius
is
if some libraries are in a non-standard location, you might need to add
-Wl,-bsvr4,-R,/opt/freeware/lib
or equivalent to LDFLAGS [0].
Markus M
[0] http://grasswiki.osgeo.org/wiki/Compile_and_Install#AIX
On Sun, Nov 24, 2013 at 8:16 PM, Markus Neteler nete...@osgeo.org wrote:
On Sun, Nov 24,
On Mon, Nov 25, 2013 at 10:25 AM, Markus Metz
markus.metz.gisw...@gmail.com wrote:
if some libraries are in a non-standard location, you might need to add
-Wl,-bsvr4,-R,/opt/freeware/lib
or equivalent
e.g. -Wl,-R,/opt/freeware/lib/gcc/powerpc-ibm-aix6.1.0.0/4.2.0/ppc64/
to LDFLAGS [0
Markus Neteler wrote:
Hi,
I struggle to export a time series as multilayer GeoTIFF: it stops at layer
145.
I have generated a time series with 365 maps and added all into a
group. Exporting that in order to export as multilayer GeoTIFF, it
fails:
GRASS 7.0.svn (nc_spm_08):~ r.out.gdal
On Thu, Nov 21, 2013 at 11:09 PM, Markus Neteler nete...@osgeo.org wrote:
On Thu, Nov 21, 2013 at 10:48 PM, Nikos Alexandris
n...@nikosalexandris.net wrote:
Shouldn't i.pca have, in both G64x and G7, the overwrite flag?
Ideally yes. It will be lacking due to the prefix= approach used therein.
It looks very much like an out-of-memory error. In the gdb backtrace I see
#4 0x76601ebd in RTreeNewListBranch (t=0x609c30) at node.c:441
p = 0x0
which means that memory allocation failed.
Try
export GRASS_VECTOR_LOWMEM=1
r.to.vect --o --v input=seg_0.05_final@pietro
On Sat, Nov 30, 2013 at 12:26 PM, Martin Landa landa.mar...@gmail.com wrote:
Hi all,
recently I found problem when breaking lines using `v.clean`.
I have a patched map that contains boundaries and centroids.
$ v.info x3 -t
nodes=8219
points=0
lines=0
boundaries=11807
centroids=4876
On Sat, Nov 30, 2013 at 6:02 PM, Martin Landa landa.mar...@gmail.com wrote:
Hi Markus,
2013/11/30 Markus Metz markus.metz.gisw...@gmail.com:
[...]
Tool: Break lines at intersections
0..ERROR: Nodes not available for line 11725
Defining `type` explicitly helps
$ v.clean in=x3 out=x4
On Tue, Dec 3, 2013 at 1:05 AM, Nikos Alexandris
n...@nikosalexandris.net wrote:
Nikos Alexandris wrote:
..
I've tested this with at least three different similar cases. All work fine
without the seed map! All fail with a seed map supplied. I guess, the only
real difference is time for the
On Mon, Dec 2, 2013 at 4:21 AM, Martin Landa landa.mar...@gmail.com wrote:
Hi Markus,
2013/11/30 Markus Metz markus.metz.gisw...@gmail.com:
How did you discover that bug in Vect_merge_lines()? To my knowledge
all modules calling Vect_merge_lines() set the correct type (lines
discovered that I mixed 8-bit (the Pan images) for the
seed map and 16-bit (the Multi-Spectral images). So, seed - 8-bit,
group to be segmented - 16-bit. Does this play a role?
Markus Metz:
No, the seed map must be integer (not more than 32 bit int), that's
the only limitation. The data
Nikos Alexandris wrote:
Markus M:
But it does not make sense to use a pan band as seeds when segmenting
the other bands. Seeds are typically the result of a previous run of
i.segment or the result of a previous classification of the same
data.
Nikos A:
Then I have inserted a
On Wed, Dec 4, 2013 at 3:42 PM, Nikos Alexandris
n...@nikosalexandris.net wrote:
Nikos Alexandris wrote:
1) I can't see any differences in the derived Principal Components
..
okay, to clarify: I mean the resulting images which, initially are
Principal Components (synthetic images) and,
On Thu, Dec 5, 2013 at 1:15 PM, Nikos Alexandris
n...@nikosalexandris.net wrote:
Nikos Alexandris:
...we need those extra digits to make it easy rejecting last Principal
Component(s) prior to the backward PCA. Might be one, two or numerous (?)
depending on the dimensions.
Markus M:
I
On Fri, Dec 6, 2013 at 1:17 PM, Blumentrath, Stefan
stefan.blumentr...@nina.no wrote:
Hi
Maybe it is not of importance, because no one else would use such extreme
settings, but in case someone considers it as a bug:
I was testing a bit with v.outlier in GRASS 7 on dense LiDAR data (~4 points
On Tue, Dec 10, 2013 at 11:14 AM, Luca Delucchi lucadel...@gmail.com wrote:
Hi devs,
Some days ago I create a really simple script to convert polygon to line [0].
I would like to know what do you think to move it to main code?
I'm not sure if it could be useful for end user or not let me
On Tue, Dec 31, 2013 at 5:23 AM, Yann Chemin yche...@gmail.com wrote:
Hi,
(SVN G7)
it does work with thres inferior to 600, but not above...
---
v.clean input=vnir4567_seg_0 output=vnir4567_seg_0_no_small_areas type=area
tool=rmarea thres=1.00 --overwrite
On Fri, Jan 10, 2014 at 1:31 AM, Ahmadou Dicko dicko.ahma...@gmail.com wrote:
Hi,
I'm using the GRASS GIS 7 :
g.version -g
version=7.0.svn
date=2014
revision=58660
build_date=2014-01-10
And since my last build (today) I can't use properly the gcp gui, more
precisely I can't select a
On Sat, Jan 11, 2014 at 6:44 PM, Martin Landa landa.mar...@gmail.com wrote:
Hi,
2014/1/11 Ahmadou Dicko dicko.ahma...@gmail.com:
Not the first page but at the second page when you click on 'create or edit
group'.
I just have two mapsets in my source location (one + PERMANENT).
right,
On Sun, Jan 12, 2014 at 12:10 PM, Martin Landa landa.mar...@gmail.com wrote:
Hi,
2014/1/12 Markus Metz markus.metz.gisw...@gmail.com:
The GUI for [r|v].ptoj is still not working: the list of mapsets does
not match the selected location.
thanks for reminder, should be fixed r58679. Anyway
On Sun, Jan 19, 2014 at 9:08 PM, Helena Mitasova hmit...@ncsu.edu wrote:
On Jan 19, 2014, at 3:01 PM, Martin Landa wrote:
Hi,
2014/1/19 Helena Mitasova hmit...@ncsu.edu:
Maybe it just waits for somebody to put it there, we would like to see it
in the core as well.
r.stream.extract is
Helmut Kudrnovsky wrote:
Moritz Lennert wrote
Glynn Clements:
Where it gets problematic is if the user already has a Python
installation but it's not suitable for whatever reason. In the worst
case they may be faced with a choice between using GRASS or using
whatever the existing Python was
with GRASS.
No, there are different versions of Python 2.7, and not all work with
GRASS, see e.g. ticket 2015
On Jan 24, 2014, at 3:03 PM, Glynn Clements wrote:
Markus Metz wrote:
Where it gets problematic is if the user already has a Python
installation but it's not suitable for whatever reason
On Mon, Jan 27, 2014 at 12:16 AM, Glynn Clements
gl...@gclements.plus.com wrote:
Markus Metz wrote:
On Sat, Jan 25, 2014 at 3:59 PM, Helena Mitasova hmit...@ncsu.edu wrote:
Just a note, given that most of these problems were caused by conflicts
with python installed by ArcGIS,
I checked
On Tue, Jan 28, 2014 at 5:13 PM, Pietro peter.z...@gmail.com wrote:
On Tue, Jan 28, 2014 at 3:52 PM, Moritz Lennert
mlenn...@club.worldonline.be wrote:
On 28/01/14 16:07, Vaclav Petras wrote:
The current problem is that there
is a incompatibility between Python 2.7.3 and 2.7.4; some import
Trying a summary on this discussion.
AFAIU, the whole discussion boils down to the question if we want to
require a system-wide installation of Python with correct python file
associations in the registry, potentially deactivating an existing
Python installation, or not.
There seems to be
1 - 100 of 1175 matches
Mail list logo