[GRASS-dev] r.out.gdal, again

2008-08-19 Thread Markus Metz
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

Re: [GRASS-dev] r.out.gdal, again

2008-08-20 Thread Markus Metz
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

Re: [GRASS-dev] r.out.gdal, again

2008-08-20 Thread Markus Metz
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

[GRASS-dev] Re: big region r.watershed

2008-10-13 Thread Markus Metz
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

[GRASS-dev] r.watershed.fast in GRASS-Addons svn repository

2008-10-20 Thread Markus Metz
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

Re: [GRASS-dev] r.watershed.fast in GRASS-Addons svn repository

2008-10-20 Thread Markus Metz
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

[GRASS-dev] Re: [GRASS GIS] #73: r.out.gdal tiff output does not work

2008-10-24 Thread Markus Metz
--+- 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

Re: [GRASS-dev] testing results of r.watershed2 against old r.watershed

2008-11-29 Thread Markus Metz
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

Re: [GRASS-dev] testing results of r.watershed2 against old r.watershed

2008-12-01 Thread Markus Metz
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

Re: [GRASS-dev] testing results of r.watershed2 against old r.watershed

2008-12-02 Thread Markus Metz
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

[GRASS-dev] r.watershed2 with MFD

2008-12-05 Thread Markus Metz
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

Re: [GRASS-dev] r.watershed2 with MFD

2008-12-05 Thread Markus Metz
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

Re: [GRASS-dev] r.watershed2 with MFD

2008-12-05 Thread Markus Metz
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

Re: [GRASS-dev] error in georeferencing points on import with v.in.ascii

2013-06-09 Thread Markus Metz
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

Re: [GRASS-dev] trouble compiling v.in.ogr + math.h (all branches)

2013-06-10 Thread Markus Metz
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

Re: [GRASS-dev] bug in vector network analysis node costs

2013-06-11 Thread Markus Metz
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

Re: [GRASS-dev] spline interpolation over time series

2013-06-16 Thread Markus Metz
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

Re: [GRASS-dev] Unexpected EVI range from i.vi

2013-06-16 Thread Markus Metz
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

Re: [GRASS-dev] spline interpolation over time series

2013-06-16 Thread Markus Metz
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

Re: [GRASS-dev] Unexpected EVI range from i.vi

2013-06-18 Thread Markus Metz
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

Re: [GRASS-dev] compilation of grass on AIX 7.1

2013-06-19 Thread Markus Metz
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:

Re: [GRASS-dev] Unexpected EVI range from i.vi

2013-06-20 Thread Markus Metz
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

Re: [GRASS-dev] Unexpected EVI range from i.vi

2013-06-20 Thread Markus Metz
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

Re: [GRASS-dev] g.proj not found

2013-06-21 Thread Markus Metz
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')

Re: [GRASS-dev] Unexpected EVI range from i.vi

2013-06-22 Thread Markus Metz
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

Re: [GRASS-dev] Unexpected EVI range from i.vi

2013-06-24 Thread Markus Metz
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

Re: [GRASS-dev] compilation of grass on AIX 7.1

2013-06-26 Thread Markus Metz
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

Re: [GRASS-dev] compilation of grass on AIX 7.1

2013-06-28 Thread Markus Metz
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

Re: [GRASS-dev] compilation of grass on AIX 7.1

2013-06-28 Thread Markus Metz
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

Re: [GRASS-dev] G_distance( ) problem in r.slope.aspect?

2013-06-29 Thread Markus Metz
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

Re: [GRASS-dev] i.segment error: Ri is 0

2013-07-01 Thread Markus Metz
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

Re: [GRASS-dev] i.segment error: Ri is 0

2013-07-02 Thread Markus Metz
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

Re: [GRASS-dev] Status of r.cva?

2013-07-02 Thread Markus Metz
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:

[GRASS-dev] wingrass7 nightly builds broken

2013-07-03 Thread Markus Metz
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

Re: [GRASS-dev] wingrass7 nightly builds broken

2013-07-04 Thread Markus Metz
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

Re: [GRASS-dev] A few additional questions about i.segment

2013-07-04 Thread Markus Metz
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). ***

Re: [GRASS-dev] v.in.ogr fails to import from PostGIS with schema

2013-07-05 Thread Markus Metz
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

Re: [GRASS-dev] v.in.ogr fails to import from PostGIS with schema

2013-07-05 Thread Markus Metz
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

Re: [GRASS-dev] [SoC] Weekly report #3 - GRASS Interactive Scatter Plot Tool

2013-07-06 Thread Markus Metz
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

Re: [GRASS-dev] Compiling grass7_trunk in Funtoo

2013-07-07 Thread Markus Metz
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

Re: [GRASS-dev] i.segment on panchromatic band of Worldview 2 scene: what resources are necessary to complete segmentation ?

2013-07-08 Thread Markus Metz
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

Re: [GRASS-dev] GRASS 7 r.neighbours average method giving incorrect value

2013-07-11 Thread Markus Metz
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

Re: [GRASS-dev] i.segment: invalid region id 0

2013-07-12 Thread Markus Metz
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:

Re: [GRASS-dev] GRASS GIS 7 tech-preview release preparations

2013-07-12 Thread Markus Metz
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

Re: [GRASS-dev] GRASS GIS 7 tech-preview release preparations

2013-07-13 Thread Markus Metz
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

Re: [GRASS-dev] GRASS GIS 7 tech-preview release preparations

2013-07-14 Thread Markus Metz
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

[GRASS-dev] mapset permissions: only owner should have write permissions

2013-07-14 Thread Markus Metz
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

Re: [GRASS-dev] mapset permissions: only owner should have write permissions

2013-07-15 Thread Markus Metz
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

Re: [GRASS-dev] i.segment: invalid region id 0

2013-07-15 Thread Markus Metz
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

Re: [GRASS-dev] mapset permissions: only owner should have write permissions

2013-07-16 Thread Markus Metz
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

Re: [GRASS-dev] i.segment: invalid region id 0

2013-07-16 Thread Markus Metz
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

Re: [GRASS-dev] standardized options

2013-07-16 Thread Markus Metz
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

Re: [GRASS-dev] mapset permissions: only owner should have write permissions

2013-07-17 Thread Markus Metz
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

[GRASS-dev] r57119 v.pack: move db and proj file to the root, preparation for packaging multiple maps

2013-07-23 Thread Markus Metz
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

Re: [GRASS-dev] r57119 v.pack: move db and proj file to the root, preparation for packaging multiple maps

2013-07-24 Thread Markus Metz
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

Re: [GRASS-dev] Right way to use G_getl2

2013-09-13 Thread Markus Metz
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

Re: [GRASS-dev] v.neighbors in GRASS7 much slower ?

2013-09-13 Thread Markus Metz
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_

Re: [GRASS-dev] Right way to use G_getl2

2013-09-14 Thread Markus Metz
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

Re: [GRASS-dev] How to calculate mean coordinates from big point datasets?

2013-09-18 Thread Markus Metz
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:

Re: [GRASS-dev] How to calculate mean coordinates from big point datasets?

2013-09-19 Thread Markus Metz
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

Re: [GRASS-dev] How to calculate mean coordinates from big point datasets?

2013-09-20 Thread Markus Metz
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

Re: [GRASS-dev] How to calculate mean coordinates from big point datasets?

2013-09-20 Thread Markus Metz
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

Re: [GRASS-dev] How to calculate mean coordinates from big point datasets?

2013-09-22 Thread Markus Metz
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

Re: [GRASS-dev] v.kcv enahncement- was Re: How to calculate mean coordinates from big point datasets?

2013-09-23 Thread Markus Metz
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

Re: [GRASS-dev] How to calculate mean coordinates from big point datasets?

2013-09-25 Thread Markus Metz
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

Re: [GRASS-dev] compile error with v.in.ply

2013-09-25 Thread Markus Metz
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.

Re: [GRASS-dev] v.in.ogr: how to force sqlite instead of dbf for output location ? SEG-Y input (Geology/Seismic Data)

2013-09-26 Thread Markus Metz
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

Re: [GRASS-dev] GRASS 6.4.svn on AIX based supercomputers

2013-10-01 Thread Markus Metz
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

Re: [GRASS-dev] creation of turntable

2013-10-01 Thread Markus Metz
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

Re: [GRASS-dev] r.in.lidar tuning

2013-10-07 Thread Markus Metz
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

Re: [GRASS-dev] r.in.lidar tuning

2013-10-08 Thread Markus Metz
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

Re: [GRASS-dev] i.segment fails

2013-10-10 Thread Markus Metz
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

[GRASS-dev] WANTED: 64bit big endian test system

2013-10-13 Thread Markus Metz
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

Re: [GRASS-dev] test of skeleton functionality in v.voronoi

2013-10-22 Thread Markus Metz
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

Re: [GRASS-dev] new flag to interpolate from nearby raster cells for v.what.rast

2013-11-20 Thread Markus Metz
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

Re: [GRASS-dev] compilation of grass on AIX 7.1

2013-11-25 Thread Markus Metz
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,

Re: [GRASS-dev] compilation of grass on AIX 7.1

2013-11-25 Thread Markus Metz
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

Re: [GRASS-dev] Exporting maps as multilayer GeoTIFF - layer limit?

2013-11-25 Thread Markus Metz
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

Re: [GRASS-dev] i.pca doesn't have the '--o' flag

2013-11-26 Thread Markus Metz
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.

Re: [GRASS-dev] Aborted (core dumped), during v.build

2013-11-29 Thread Markus Metz
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

Re: [GRASS-dev] v.clean tool=break fails

2013-11-30 Thread Markus Metz
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

Re: [GRASS-dev] v.clean tool=break fails

2013-11-30 Thread Markus Metz
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

Re: [GRASS-dev] i.segment: Invalid region id -1

2013-12-02 Thread Markus Metz
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

Re: [GRASS-dev] v.clean tool=break fails

2013-12-02 Thread Markus Metz
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

Re: [GRASS-dev] i.segment: Invalid region id -1

2013-12-03 Thread Markus Metz
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

Re: [GRASS-dev] i.segment: Invalid region id -1

2013-12-03 Thread Markus Metz
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

Re: [GRASS-dev] PCA (i.pca) in G7: filtering and rescaling

2013-12-05 Thread Markus Metz
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,

Re: [GRASS-dev] PCA (i.pca) in G7: filtering and rescaling

2013-12-08 Thread Markus Metz
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

Re: [GRASS-dev] G7: v.loutlier Decomposition failed

2013-12-08 Thread Markus Metz
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

Re: [GRASS-dev] move v.polytoline?

2013-12-11 Thread Markus Metz
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

Re: [GRASS-dev] v.clean problem with rmarea (ERROR: Area merging failed)

2014-01-08 Thread Markus Metz
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

Re: [GRASS-dev] [GRASS-user] GCP GUI error

2014-01-10 Thread Markus Metz
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

Re: [GRASS-dev] [GRASS-user] GCP GUI error

2014-01-12 Thread Markus Metz
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,

Re: [GRASS-dev] [GRASS-user] GCP GUI error

2014-01-13 Thread Markus Metz
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

Re: [GRASS-dev] weren't r.stream going to core? was: r.stream.* problems on Ubuntu when installed via g.extensions

2014-01-20 Thread Markus Metz
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

Re: [GRASS-dev] Handling of Python scripts on MS Windows

2014-01-22 Thread Markus Metz
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

Re: [GRASS-dev] Handling of Python scripts on MS Windows

2014-01-25 Thread Markus Metz
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

Re: [GRASS-dev] Handling of Python scripts on MS Windows

2014-01-28 Thread Markus Metz
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

Re: [GRASS-dev] Handling of Python scripts on MS Windows

2014-01-28 Thread Markus Metz
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

Re: [GRASS-dev] Handling of Python scripts on MS Windows

2014-01-28 Thread Markus Metz
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   2   3   4   5   6   7   8   9   10   >