Re: [GRASS-dev] v.in.osm working?

On Thu, Aug 31, 2017 at 7:21 PM, Markus Metz <markus.metz.gisw...@gmail.com> wrote: > > I am not sure if v.in.ogr should be modified to use this special reading mode for one single OGR supported format. The GDAL/OGR API is very convenient because applications do not need to bother abou

Re: [GRASS-dev] v.in.osm working?

On Thu, Aug 24, 2017 at 3:37 PM, Even Rouault <even.roua...@spatialys.com> wrote: > > On jeudi 24 août 2017 15:34:11 CEST Markus Metz wrote: > > > On Thu, Aug 24, 2017 at 11:15 AM, Even Rouault < even.roua...@spatialys.com> > > > > > > wrote: > &

Re: [GRASS-dev] improve resolution of bands

On Sat, Oct 21, 2017 at 12:45 AM, Nikos Alexandris wrote: > > * Moritz Lennert [2017-10-20 15:08:18 +0200]: > >> On 20/10/17 11:37, Luca Delucchi wrote: >>> >>> Hi devs, >>> >>> I just discovered this [0], I think it could be really useful

Re: [GRASS-dev] Which v.* modules are working with v.external'ed data

On Wed, Nov 15, 2017 at 4:35 PM, Markus Neteler <nete...@osgeo.org> wrote: > > On Wed, Nov 15, 2017 at 3:49 PM, Markus Metz > <markus.metz.gisw...@gmail.com> wrote: > > On Wed, Nov 15, 2017 at 1:36 PM, Helmut Kudrnovsky <hel...@web.de> wrote: > >>

Re: [GRASS-dev] winGRASS not built/broken

On Tue, Nov 14, 2017 at 9:27 PM, Markus Metz <markus.metz.gisw...@gmail.com> wrote: > > > > On Tue, Nov 14, 2017 at 8:26 PM, Even Rouault <even.roua...@spatialys.com> wrote: > > > > On mardi 14 novembre 2017 19:56:25 CET Markus Metz wrote: > > > >

Re: [GRASS-dev] winGRASS not built/broken

On Tue, Nov 14, 2017 at 9:30 PM, Markus Metz <markus.metz.gisw...@gmail.com> wrote: > > > > On Tue, Nov 14, 2017 at 9:27 PM, Markus Metz < markus.metz.gisw...@gmail.com> wrote: > > > > > > > > On Tue, Nov 14, 2017 at 8:26 PM, Even Rouault < even

Re: [GRASS-dev] winGRASS not built/broken

On Tue, Nov 14, 2017 at 8:26 PM, Even Rouault <even.roua...@spatialys.com> wrote: > > On mardi 14 novembre 2017 19:56:25 CET Markus Metz wrote: > > > On Tue, Nov 14, 2017 at 3:13 PM, Even Rouault < even.roua...@spatialys.com> > > > > > > wrote:

Re: [GRASS-dev] Unresolved directions in r.fill.dir

Hi Vaclav, On Sun, Nov 26, 2017 at 1:31 AM, Vaclav Petras wrote: > > Hi all, > > r.fill.dir with the bellow artificial DEM leaves part of the directions unresolved and this area is marked in areas, although the area is filled in the output. Here is the code to reproduce: >

Re: [GRASS-dev] Fw: [OSGeo-Discuss] Geospatial devroom - Call for Participation

On Mon, Nov 20, 2017 at 4:49 PM, Moritz Lennert < mlenn...@club.worldonline.be> wrote: > > Has anyone proposed a GRASS talk for FOSDEM or is planning to do so ? > > I could easily propose a talk on GRASS GIS as a toolbox for remote > sensing. However, if anyone has something else to propose,

Re: [GRASS-dev] Unresolved directions in r.fill.dir

On Sun, Nov 26, 2017 at 10:12 PM, Anna Petrášová <kratocha...@gmail.com> wrote: > > On Sun, Nov 26, 2017 at 4:04 PM, Markus Metz > <markus.metz.gisw...@gmail.com> wrote: > > Hi Vaclav, > > > > On Sun, Nov 26, 2017 at 1:31 AM, Vaclav Petras <wen

Re: [GRASS-dev] GRASS GIS raster files: LZW compression?

<nete...@osgeo.org> wrote: > On Tue, Oct 31, 2017 at 8:35 PM, Markus Metz > <markus.metz.gisw...@gmail.com> wrote: > > On Tue, Oct 31, 2017 at 12:16 PM, Markus Neteler <nete...@osgeo.org> > wrote: > >> > >> On Mon, Oct 30, 2017 at 9:58 AM, Mar

Re: [GRASS-dev] [GRASS-PSC] GRASS add-on sharing and write access

need to compile GRASS from source in order to test your module, please read https://trac.osgeo.org/grass/wiki/CompileOnWindows HTH, Markus M > > Regarding the python code, thank you for pointing that out. I will surely review that part. > > All the best, > Nagy Edmond > >

Re: [GRASS-dev] how difficult would it be to modify i.edge to not load the entire image into memory ?

On Thu, Dec 14, 2017 at 12:44 PM, Markus Metz <markus.metz.gisw...@gmail.com> wrote: > > > > On Thu, Dec 14, 2017 at 11:47 AM, Moritz Lennert < mlenn...@club.worldonline.be> wrote: > > > > On 14/12/17 05:45, Vaclav Petras wrote: > >> > >> Hi Mo

Re: [GRASS-dev] [GRASS-PSC] GRASS add-on sharing and write access

On Fri, Dec 15, 2017 at 5:50 PM, Luca Delucchi wrote: > > Hi Nagy, > > Il 15 dic 2017 5:42 PM, "Nagy Edmond" ha scritto: > > Markus, thank you very much for helping. > > I have now included into the add-on directory the py, html and makefile >

Re: [GRASS-dev] how difficult would it be to modify i.edge to not load the entire image into memory ?

On Thu, Dec 14, 2017 at 11:47 AM, Moritz Lennert < mlenn...@club.worldonline.be> wrote: > > On 14/12/17 05:45, Vaclav Petras wrote: >> >> Hi Moritz, >> >> I'm currently at AGU > > > Enjoy ! :-) > >> and can't dig into the code, but yes, I think it can be rewritten with segment library, preferably

Re: [GRASS-dev] [GRASS-PSC] GRASS add-on sharing and write access

On Mon, Dec 18, 2017 at 9:21 AM, Moritz Lennert < mlenn...@club.worldonline.be> wrote: > > [CC'ing grass-dev where such discussion should be happening] > > On 17/12/17 22:37, Markus Neteler wrote: >> >> On Sun, Dec 17, 2017 at 9:14 PM, Markus Metz >> &

Re: [GRASS-dev] winGRASS not built/broken

On Thu, Nov 16, 2017 at 10:03 AM, Markus Metz <markus.metz.gisw...@gmail.com> wrote: > > > > On Tue, Nov 14, 2017 at 9:54 PM, Markus Metz < markus.metz.gisw...@gmail.com> wrote: > > > > > > > > On Tue, Nov 14, 2017 at 9:30 PM, Ma

Re: [GRASS-dev] winGRASS not built/broken

On Sat, Nov 11, 2017 at 4:25 PM, Helmut Kudrnovsky wrote: > > it seems there is an issue with winGRASS: > > 32 bit: > > https://wingrass.fsv.cvut.cz/grass73/x86/logs/log-r71641-1/error.log > > GRASS GIS 7.3.svn r71641 compilation log >

Re: [GRASS-dev] winGRASS not built/broken

On Sat, Nov 11, 2017 at 7:45 PM, Even Rouault wrote: > > > > > If GDALSetCacheMax64 must evaluate to GDALSetCacheMax64 ( int ), > > > > My hypothesis might be wrong, but if it is true, then it *wrongly* evaluates to GDALSetCacheMax64 ( int ) when currently called by

Re: [GRASS-dev] Different CRS matching in 7.2 and trunk

On Sat, Nov 11, 2017 at 8:05 PM, Helena Mitasova <hmit...@ncsu.edu> wrote: > > > On Nov 10, 2017, at 7:20 PM, Markus Metz <markus.metz.gisw...@gmail.com> wrote: > > > > On Sat, Nov 11, 2017 at 12:22 AM, Helena Mitasova <hmit...@ncsu.edu> wrote: > >

Re: [GRASS-dev] winGRASS not built/broken

On Sat, Nov 11, 2017 at 6:01 PM, Even Rouault <even.roua...@spatialys.com> wrote: > > On samedi 11 novembre 2017 17:44:18 CET Markus Metz wrote: > > > On Sat, Nov 11, 2017 at 4:25 PM, Helmut Kudrnovsky <hel...@web.de> wrote: > > > > it seems there is an issu

Re: [GRASS-dev] Different CRS matching in 7.2 and trunk

On Fri, Nov 10, 2017 at 6:08 PM, Vaclav Petras wrote: > > Hi all, > > I'm trying to understand a change of behavior between 7.2 and trunk. With 7.2, I can do the following: > > curl -SL http://fatra.cnr.ncsu.edu/foss4g2017/nc_tile_0793_016_spm.zip \ > >

Re: [GRASS-dev] Different CRS matching in 7.2 and trunk

On Fri, Nov 10, 2017 at 6:43 PM, Markus Metz <markus.metz.gisw...@gmail.com> wrote: > > > > On Fri, Nov 10, 2017 at 6:08 PM, Vaclav Petras <wenzesl...@gmail.com> wrote: > > > > Hi all, > > > > I'm trying to understand a change of behavior between

Re: [GRASS-dev] Different CRS matching in 7.2 and trunk

On Fri, Nov 10, 2017 at 8:46 PM, Vaclav Petras <wenzesl...@gmail.com> wrote: > > On Fri, Nov 10, 2017 at 2:21 PM, Markus Metz < markus.metz.gisw...@gmail.com> wrote: > > > > > > > > > > 7.2 considers this OK while trunk considers t

Re: [GRASS-dev] Different CRS matching in 7.2 and trunk

atum.table. Markus M > > Helena > > On Nov 10, 2017, at 5:30 PM, Markus Metz <markus.metz.gisw...@gmail.com> wrote: > > > > On Fri, Nov 10, 2017 at 8:46 PM, Vaclav Petras <wenzesl...@gmail.com> wrote: > > > > On Fri, Nov 10, 2017 at 2:21 PM, Markus Metz < m

Re: [GRASS-dev] Landsat MTL files

On Tue, Nov 14, 2017 at 9:22 AM, Stefan Blumentrath < stefan.blumentr...@nina.no> wrote: > > Hi, > > Sorry if I confuse something here or cause confusion... > > I do understand that it can be handy to handle Landsat scenes in different mapsets. And creating new mapsets at import can be a smart

Re: [GRASS-dev] winGRASS not built/broken

On Mon, Nov 13, 2017 at 10:30 PM, Markus Metz <markus.metz.gisw...@gmail.com> wrote: > > > > On Sun, Nov 12, 2017 at 12:13 AM, Even Rouault <even.roua...@spatialys.com> wrote: > > > > On dimanche 12 novembre 2017 00:07:49 CET Markus Metz wrote: > > >

Re: [GRASS-dev] r.mask: odd behavior?

On Sun, Nov 19, 2017 at 9:19 PM, Veronica Andreo wrote: > > Hi devs, > > I found that r.mask does not behave as I would expect and I would really appreciate some clarification. > > The issue is the following: I apply a mask, then I do some processing, I remove the mask and

[GRASS-dev] vector import bug fix

I just found and fixed a cryptic bug when importing vector data with polygons. This bug is most often the reason for warnings like WARNING: Number of incorrect boundaries: X during vector import. If such warnings appear, the result is corrupt. The bug was not in the code itself, but was caused

Re: [GRASS-dev] Different CRS matching in 7.2 and trunk

On Sun, Nov 12, 2017 at 12:21 AM, Markus Metz <markus.metz.gisw...@gmail.com> wrote: > > > > On Sat, Nov 11, 2017 at 8:05 PM, Helena Mitasova <hmit...@ncsu.edu> wrote: > > > > > > On Nov 10, 2017, at 7:20 PM, Markus Metz <markus.metz.gisw...@gmail.com

Re: [GRASS-dev] [release planning] 7.4.0

On Thu, Nov 16, 2017 at 9:57 PM, Markus Neteler <nete...@osgeo.org> wrote: > > On Thu, Nov 16, 2017 at 9:28 AM, Markus Metz > <markus.metz.gisw...@gmail.com> wrote:> > > On Tue, Nov 14, 2017 at 10:24 PM, Martin Landa <landa.mar...@gmail.com> > >> 2017

Re: [GRASS-dev] Which v.* modules are working with v.external'ed data

On Thu, Nov 16, 2017 at 10:02 PM, Markus Neteler <nete...@osgeo.org> wrote: > > On Wed, Nov 15, 2017 at 10:03 PM, Markus Metz > <markus.metz.gisw...@gmail.com> wrote > > On Wed, Nov 15, 2017 at 4:35 PM, Markus Neteler <nete...@osgeo.org> wrote: > >> &g

Re: [GRASS-dev] [release planning] 7.4.0

On Tue, Nov 14, 2017 at 10:24 PM, Martin Landa wrote: > > Hi, > > 2017-11-13 8:23 GMT+01:00 Martin Landa : > > please wait also for Windows daily binaries. It will take some time to > > set it up too. Ma > > wingrass builds consolidated: > > * no

Re: [GRASS-dev] winGRASS not built/broken

On Tue, Nov 14, 2017 at 9:54 PM, Markus Metz <markus.metz.gisw...@gmail.com> wrote: > > > > On Tue, Nov 14, 2017 at 9:30 PM, Markus Metz < markus.metz.gisw...@gmail.com> wrote: > > > > > > > > On Tue, Nov 14, 2017 at 9:27 PM, Ma

Re: [GRASS-dev] Which v.* modules are working with v.external'ed data

On Wed, Nov 15, 2017 at 1:36 PM, Helmut Kudrnovsky wrote: > > Background of the question in subject: the GRASS algs in upcoming QGIS3 are > working with v.external linked data. > > I've seen some modules doesn't work with such kind of data. > > Is there maybe a list already

Re: [GRASS-dev] winGRASS not built/broken

On Tue, Nov 14, 2017 at 3:13 PM, Even Rouault wrote: > > > --> > > > Index: port/cpl_port.h > > > === > > > --- port/cpl_port.h (revision 40701) > > > +++ port/cpl_port.h (working copy) > > > @@ -219,7

Re: [GRASS-dev] winGRASS not built/broken

On Sun, Nov 12, 2017 at 12:13 AM, Even Rouault <even.roua...@spatialys.com> wrote: > > On dimanche 12 novembre 2017 00:07:49 CET Markus Metz wrote: > > > Stupid question: such a #define has only effect on compile time. If GDAL > > > has been compiled withou

Re: [GRASS-dev] Does multi-threading apply to r.series.lwr?

including all steps. Obviously, step 3 is >>> practically the consumer. >>> >>> >>> Overall it took about 44 hours to build an LWR Smoothed LST STRDS. >>> >>> After proofing the concept, good use of the cluster concerns steps 2, 5, >>

Re: [GRASS-dev] Does multi-threading apply to r.series.lwr?

On Fri, Nov 3, 2017 at 7:08 PM, Nikos Alexandris wrote: > > Before processing tens of thousands of Landsat8 TIRS bands, a script > tests the workflow described below, for 74 scenes, that correspond to one > WRS2 tile. > > > The script takes as inputs: > > path to

Re: [GRASS-dev] Testing the new ZSTD raster compression - was: Re: GRASS GIS raster files: LZW compression?

On Wed, Dec 6, 2017 at 10:41 AM, Markus Neteler wrote: > [...] > > # null file > identical > > Curiosity: would it makes sense to compress the "nullcmpr" file according to the selected compression? Probably Markus M had already explained it but I don't remember... In short,

Re: [GRASS-dev] [GRASS-SVN] r71912 - grass/trunk/mswindows/osgeo4w

On Sat, Dec 9, 2017 at 12:10 PM, Helmut Kudrnovsky wrote: > > Martin Landa wrote > > 2017-12-09 12:03 GMT+01:00 Helmut Kudrnovsky > > > hellik@ > > > : > >> oh right. it should not be needed, but added to the instruction in the > >> wiki. > >> I'll change it. > > > > thanks, Ma >

Re: [GRASS-dev] GRASS GIS raster files: LZW compression?

4.0 should get out in time to make it into the next releases of major Linux distros. Markus M > > Cheers > Stefan > > -Original Message- > From: grass-dev [mailto:grass-dev-boun...@lists.osgeo.org] On Behalf Of Markus Neteler > Sent: tirsdag 5. desember 2017 10

Re: [GRASS-dev] GRASS GIS raster files: LZW compression?

On Fri, Oct 27, 2017 at 10:44 PM, Markus Metz <markus.metz.gisw...@gmail.com> wrote: > > > > On Thu, Oct 26, 2017 at 7:23 PM, Even Rouault <even.roua...@spatialys.com> wrote: > > > > On jeudi 26 octobre 2017 18:57:10 CEST Markus Neteler wrote: > > > >

Re: [GRASS-dev] GRASS GIS raster files: LZW compression?

On Wed, Oct 25, 2017 at 10:40 PM, Markus Neteler wrote: > > Hi devs, > > while playing with the SRTM 30m world I see that there is a difference > of 66GB in size between LZ4 (larger) and DEFLATE (smaller). While this > is not a surprise I was wondering if LZW compression could

Re: [GRASS-dev] GRASS GIS raster files: LZW compression?

On Tue, Oct 31, 2017 at 12:16 PM, Markus Neteler <nete...@osgeo.org> wrote: > > On Mon, Oct 30, 2017 at 9:58 AM, Markus Metz > <markus.metz.gisw...@gmail.com> wrote: > ... > > Some more tests: > > corine land cover 250 meter, relatively small, easy to compr

Re: [GRASS-dev] Different CRS matching in 7.2 and trunk

On Sun, Nov 19, 2017 at 10:33 PM, Markus Metz <markus.metz.gisw...@gmail.com> wrote: > > > > On Sun, Nov 12, 2017 at 12:21 AM, Markus Metz < markus.metz.gisw...@gmail.com> wrote: > > > > > > > > On Sat, Nov 11, 2017 at 8:05 PM, Helena Mitasova <h

Re: [GRASS-dev] [release planning] 7.4.1

On Fri, May 4, 2018 at 11:14 PM, Markus Neteler wrote: > > On Fri, May 4, 2018 at 10:02 PM, Martin Landa wrote: > > Hi, > > > > 2018-04-25 20:26 GMT+02:00 Markus Neteler : > >> If there are no objections, I'll prepare RC1 in the next

Re: [GRASS-dev] remove raster map in C code

Hi Luca, On Fri, May 11, 2018 at 10:26 AM, Luca Delucchi wrote: > > Hi devs, > > I would like to remove a raster map inside a C module, looking aroung > I found the M_do_remove function used in g.remove and r.reclass. So I > tried to use it but I get error in compilation >

Re: [GRASS-dev] remove raster map in C code

On Fri, May 11, 2018 at 11:54 AM, Luca Delucchi <lucadel...@gmail.com> wrote: > > On 11 May 2018 at 10:54, Markus Metz <markus.metz.gisw...@gmail.com> wrote: > > Hi Luca, > > > > Hi Markus, > > > On Fri, May 11, 2018 at 10:26 AM, Luca Delucchi <lu

Re: [GRASS-dev] v.extracy fails for type=boundary

On Fri, May 4, 2018 at 4:09 PM, Nikos Alexandris wrote: > > Dears, > > I get something unexpected using type=boundary with `v.external`: > > ``` > v.extract input=european_grid_10k_boundaries out=test type=boundary --v --o > Using native format > Extracting features... >

Re: [GRASS-dev] [release planning] 7.4.1

On Wed, May 16, 2018 at 12:43 AM, Helmut Kudrnovsky wrote: > > Markus Neteler wrote > > On Tue, May 15, 2018 at 11:46 AM, Martin Landa > > > landa.martin@ > > > wrote: > >> Hi Markus, > > ... > >> it's two weeks from RC1, I would go ahead with RC2. Any objections? > >> Martin > >

Re: [GRASS-dev] [release planning] 7.4.1

On Wed, May 16, 2018 at 10:33 AM, Martin Landa wrote: > > Hi, > > 2018-05-16 10:29 GMT+02:00 Moritz Lennert : > > I haven't had the possibility to test, yet, but the slow speed could be considered a bug, and so if you are confident that the

Re: [GRASS-dev] [GRASS-user] r.series weights to zero

On Fri, Jun 8, 2018 at 12:30 PM, Frank DAVID wrote: > > > > > Cordialement, > Frank David > > > Message d'origine > De : Markus Metz > Date :07/06/2018 17:30 (GMT+01:00) > À : Frank David > Cc : grass-user , GRASS developers list >

Re: [GRASS-dev] Testing the new ZSTD raster compression - was: Re: GRASS GIS raster files: LZW compression?

On Sat, Jun 9, 2018 at 8:26 AM, Nikos Alexandris wrote: > > * Markus Neteler [2017-12-06 10:41:19 +0100]: > >> Hi, >> >> (subject renamed for clarity, original thread: >> part 1: >> https://lists.osgeo.org/pipermail/grass-dev/2017-October/thread.html#86395 >> part 2: >>

Re: [GRASS-dev] Testing the new ZSTD raster compression - was: Re: GRASS GIS raster files: LZW compression?

On Sun, Jun 10, 2018 at 8:44 PM, Nikos Alexandris wrote: > > > Nikos: > >>> I am building a docker image, based on trunk, for which I need to ensure >>> that ZSTD is the default compressor. >>> >>> What is the way to pre-set this at the configuration step, before >>> compiling, so as to avoid to

Re: [GRASS-dev] [GRASS-user] r.series weights to zero

On Tue, Jun 5, 2018 at 2:51 PM, Frank David wrote: > > Hi all Grass users, > > It's seems that r.series weights does not accept zero as weight... Is it possible ? Yes, weights must be positive. > and so, why ? A zero weight means that all values in this map are ignored. Zero weights can also

Re: [GRASS-dev] non-zero return code -11 from v.in.ogr in python script

nd grass-dev-dbgsym packages provide this functionality as well… > > I`ll post again if/when I find out more… > > > > Cheers > > Stefan > > > > From: Markus Metz > Sent: Wednesday, June 13, 2018 12:27:03 PM > To: Stefan Blumentrath

Re: [GRASS-dev] non-zero return code -11 from v.in.ogr in python script

On Wed, Jun 13, 2018 at 11:34 AM, Stefan Blumentrath < stefan.blumentr...@nina.no> wrote: > > Hi, > > > > On a GRASS 7.4 installation from ubuntugis-unstable I get a “non-zero return code -11” error when I try to import data from PostGIS using v.in.ogr in a ython script. > > > > Looking at the

Re: [GRASS-dev] v.kernel: should the module take into account the resolution for default output ?

On Mon, May 28, 2018 at 6:16 PM, Moritz Lennert < mlenn...@club.worldonline.be> wrote: > > Hi, > > AFAIU kernel density calculations, one takes a number of points and redistributes this total number across the entire region using a specified kernel function as estimator as to the spatial pattern

Re: [GRASS-dev] v.kernel: should the module take into account the resolution for default output ?

On Tue, May 29, 2018 at 2:21 PM, Moritz Lennert < mlenn...@club.worldonline.be> wrote: > > Le Tue, 29 May 2018 08:59:47 +0200, > Markus Metz a écrit : > > > On Mon, May 28, 2018 at 6:16 PM, Moritz Lennert < > > mlenn...@club.worldonline.be> wrote: > > &g

Re: [GRASS-dev] Avoid the addition of @mymapset in output map name

Hi Roberta, On Tue, May 29, 2018 at 1:41 PM, Moritz Lennert < mlenn...@club.worldonline.be> wrote: > > Hi Roberta, > > Le Tue, 29 May 2018 13:16:48 +0200, > Roberta Fagandini a écrit : > > > Hi all! > > I'm working on the GUI of my module for clouds and shadows detection > > in Sentinel 2 images

Re: [GRASS-dev] unable to install my grass module from the GitHub repository

Hi Roberta, On Tue, Jun 5, 2018 at 2:38 PM, Roberta Fagandini wrote: > > Hi all! > I'm trying to install my module i.sentinel.mask from the GitHub repository [0] using g.extension but I get the following error: > > g.extension extension=i.sentinel.mask operation=add url=

Re: [GRASS-dev] v.kernel: should the module take into account the resolution for default output ?

On Tue, May 29, 2018 at 3:48 PM, Moritz Lennert < mlenn...@club.worldonline.be> wrote: > > Le Tue, 29 May 2018 15:19:39 +0200, > Markus Metz a écrit : > > > On Tue, May 29, 2018 at 2:21 PM, Moritz Lennert < > > mlenn...@club.worldonline.be> wrote: > >

Re: [GRASS-dev] compile 6S library in GRASS

On Wed, Jun 27, 2018 at 3:06 PM, Roberta Fagandini wrote: > > > > 2018-06-27 14:24 GMT+02:00 Markus Metz : >> >> >> >> On Wed, Jun 27, 2018 at 2:16 PM, Roberta Fagandini < robifagand...@gmail.com> wrote: >> > >> > I'm trying to create

Re: [GRASS-dev] compile 6S library in GRASS

>>> Il giorno mer 27 giu 2018 alle ore 13:47 Markus Metz < markus.metz.gisw...@gmail.com <mailto:markus.metz.gisw...@gmail.com>> ha scritto: >>> >>> Hi Roberta, >>> >>> On Wed, Jun 27, 2018 at 1:20 PM, Roberta Fagandini >>> ma

Re: [GRASS-dev] compile 6S library in GRASS

Hi Roberta, On Wed, Jun 27, 2018 at 1:20 PM, Roberta Fagandini wrote: > > Hi all! > I need to compile the 6S library in GRASS in order to install the python library Py6S [0]. do you really need Py6S? Can't you use i.atcorr instead? Markus M > The source code of 6S (v 1.1) is written in

Re: [GRASS-dev] [GRASS GIS] #3554: r.slope.aspect: add flag/functionality to not shrink

On Sun, Apr 29, 2018 at 7:36 AM, Steven Pawley wrote: > > Handling of nodata values at raster borders for modules which involve focal functions would be handy to have for several GRASS GIS modules, not just for r.slope.aspect. IMHO r.mapcalc, r.texture, and

Re: [GRASS-dev] Which are the strds 'columns'?

On Sun, Oct 22, 2017 at 9:47 PM, Sören Gebbert wrote: > > [snip] > > > (Sorry for bottom-posting, want to break the discussion to a new > > "thread") > > > > It is, and was, clear that the `t.rast.list` module does exactly > > what it is named for. It lists the

Re: [GRASS-dev] GRASS GIS raster files: LZW compression?

On Thu, Oct 26, 2017 at 7:23 PM, Even Rouault <even.roua...@spatialys.com> wrote: > > On jeudi 26 octobre 2017 18:57:10 CEST Markus Neteler wrote: > > > On Thu, Oct 26, 2017 at 9:25 AM, Markus Metz > > > > > > <markus.metz.gisw...@gmail.com> wrote: >

Re: [GRASS-dev] [release planning] 7.4.0

On Mon, Jan 8, 2018 at 10:47 AM, Markus Neteler wrote: > > Hi devs, > > if there are no objections, I'll package 7.4.0RC2 in the next few days. I have just submitted a fix for i.atcorr in r72055, in the hope that it still makes it into 7.4.0RC2. Markus M

Re: [GRASS-dev] [release planning] 7.4.0

On Mon, Jan 8, 2018 at 7:57 PM, Markus Neteler <nete...@osgeo.org> wrote: > > On Mon, Jan 8, 2018 at 4:30 PM, Markus Metz > <markus.metz.gisw...@gmail.com> wrote: > > On Mon, Jan 8, 2018 at 10:47 AM, Markus Neteler <nete...@osgeo.org> wrote: > >> > >

Re: [GRASS-dev] r.series with file option - too many files open

On Mon, Jan 15, 2018 at 4:12 PM, Paulo van Breugel wrote: > > Hi devs, > > I am trying to run r.series with a large number of input maps (5000). Given the large number of input maps, I am using the 'file' option. > > GRASS 7.5.svn (latlon):~ > r.series output=speciescount

Re: [GRASS-dev] r.series with file option - too many files open

On Mon, Jan 15, 2018 at 8:41 PM, Veronica Andreo <veroand...@gmail.com> wrote: > > Hi all, > > 2018-01-15 20:11 GMT+01:00 Markus Neteler <nete...@osgeo.org>: >> >> On Mon, Jan 15, 2018 at 5:27 PM, Paulo van Breugel >> <p.vanbreu...@gmail.com> w

Re: [GRASS-dev] i.atcorr produces 'nan' values for certain RapidEye bands

On Tue, Jan 16, 2018 at 8:32 AM, Markus Neteler <nete...@osgeo.org> wrote: > > On Fri, Jan 12, 2018 at 10:42 AM, Markus Metz > <markus.metz.gisw...@gmail.com> wrote: > > On Fri, Jan 12, 2018 at 8:58 AM, Markus Neteler <nete...@osgeo.org> wrote: > ... > >

Re: [GRASS-dev] i.atcorr produces 'nan' values for certain RapidEye bands

alled the latest version of "trunk" > > (code revision r71101, build date 2017-05-22). However, while at least one > > of the two bands that I included in my initial example seemed to work at > > that time using GRASS's release version, now with "trunk" both bands

Re: [GRASS-dev] [release planning] 7.4.0

On Thu, Jan 25, 2018 at 8:23 PM, Helmut Kudrnovsky wrote: > > Markus Neteler wrote > > Am 25.01.2018 6:37 nachm. schrieb "Martin Landa" > > > landa.martin@ > > > : > > > > Hi, > > > > 2018-01-25 17:52 GMT+01:00 Markus Neteler > > > neteler@ > > > : > >>> what about backporting

Re: [GRASS-dev] Compilation error in r.random.surface

On Fri, Jan 26, 2018 at 1:56 PM, Markus Neteler wrote: > > Hi, > > while trying to generate Fedora and EPEL packages of 7.4.0 on COPR [1] > I came accross this issue: > > /usr/bin/ld: Warning: size of symbol `Surface' changed from 8 in > OBJ.x86_64-redhat-linux-gnu/main.o to

Re: [GRASS-dev] r.in.gdal changes range of values for sentinel bands (?)

On Mon, Feb 5, 2018 at 1:14 PM, Veronica Andreo wrote: > > I tested also with 74 release branch... same result > > 2018-02-05 13:05 GMT+01:00 Veronica Andreo : >> >> Hi devs >> >> I'm testing Martin's new add-on, r.sentinel.import. I created an UTM21S

Re: [GRASS-dev] r.in.gdal changes range of values for sentinel bands (?)

G2000 >> NBITS=15 >> >> still differs a lot from what I get after importing into GRASS. >> >> System Info >> GRASS version: 7.5.svn >> GRASS SVN revision: r72203 >> Build date: 2018-01-01 >> Build platform: x86_64-pc-linux-gnu >

Re: [GRASS-dev] Problems installing the r.pi suite using g.extension [was: Re: [GRASS-user] LSMetrics - addon development]

On Fri, Feb 16, 2018 at 12:47 PM, Moritz Lennert < mlenn...@club.worldonline.be> wrote: > > Moving this over to grass-dev... > > On 16/02/18 10:14, Markus Metz wrote: >> >> >> >> On Fri, Feb 16, 2018 at 10:05 AM, Markus Neteler <nete..

Re: [GRASS-dev] using g.mapset in python script

On Sun, Dec 24, 2017 at 3:10 PM, Paulo van Breugel wrote: > > Hi devs, > > I am trying to create a new mapset and open that mapset using g.mapset. When doing this from the command line, I can import layers in the new mapset using r.in.gdal without problems.However, running

Re: [GRASS-dev] [GRASS-SVN] r71967 - grass/trunk/raster/r.path

On Fri, Dec 22, 2017 at 11:39 PM, Markus Neteler wrote: > > Hi, > > sorry for a > > > > On Fri, Dec 22, 2017 at 8:55 PM, wrote: > > New Revision: 71967 > ... > > > > > > - > > + > > ...we spent notable time during the sprint in Enschede to

Re: [GRASS-dev] v.to.rast for polygons not overlapping center of raster cell

On Mon, Feb 26, 2018 at 11:40 PM, Veronica Andreo wrote: > > Hi devs, > > I have hundreds of vector maps corresponding to a time series of burned areas in the state of Victoria, Australia. To be able to extract the number of classes (diversity) and the most common LC/slope

Re: [GRASS-dev] segmentation fault with temporal commands

On Mon, Jul 30, 2018 at 1:37 PM, Markus Neteler wrote: > > Hi again, > > On Mon, Jul 30, 2018 at 1:05 PM, Markus Neteler wrote: > ... > > Thread 1 "python" received signal SIGSEGV, Segmentation fault. > > 0x7fffd7ac305b in blas_shutdown () from /lib64/libopenblaso.so.0 > > (gdb) bt full > >

Re: [GRASS-dev] No 'count' method for r.statistics

On Wed, Aug 1, 2018 at 11:59 AM, Nikos Alexandris wrote: > > `r.statistics` which was/is meant for categorical raster maps, does not > provide for a 'count' method. > > `r.stats.zonal`, on the other hand, which is meant for floating point > raster maps, does so. > > This is rather unexpected.

Re: [GRASS-dev] r.in.pdal

2018-08-06 12:12 GMT+02:00 Anika Bettge : > > Hi all, > > I just uploaded my first GRASS GIS addon r.in.pdal: > > https://trac.osgeo.org/grass/browser/grass-addons/grass7/raster/r.in.pdal. Thanks a lot to your contribution Anika! A few cosmetic suggestions: the print command in L268 should be

Re: [GRASS-dev] [GRASS GIS] #3448: v.buffer native failures

On Thu, Aug 23, 2018 at 1:39 PM Stefan Blumentrath < stefan.blumentr...@nina.no> wrote: > > Hi Marcus, > > I am not too familiar with C and the like so I might confuse some things here... > > I noticed that using .buffer() in PyGRASS gives a lot of "using native format" output. this "using native

Re: [GRASS-dev] Fwd: [QGIS Application - Bug report #19733] v.rast.stats is broken due to parsing error of double underscore in column names

On Sat, Sep 1, 2018 at 7:58 AM Markus Neteler wrote: > > Hi devs, > > does anyone have an idea how to fix this issue in QGIS processing? this is a GDAL error message also happening in GRASS directly: [...] > v.out.ogr --overwrite -s -e input=tmp15356101025715

Re: [GRASS-dev] Fwd: [QGIS Application - Bug report #19733] v.rast.stats is broken due to parsing error of double underscore in column names

On Sat, Sep 1, 2018 at 6:07 PM Markus Metz wrote: > > > > On Sat, Sep 1, 2018 at 7:58 AM Markus Neteler wrote: > > > > Hi devs, > > > > does anyone have an idea how to fix this issue in QGIS processing? > > this is a GDAL error message also happening

Re: [GRASS-dev] [GRASS-user] experimental Python 3 support in trunk

On Wed, Sep 5, 2018 at 9:41 PM Martin Landa wrote: > > Hi, > > st 5. 9. 2018 v 21:38 odesílatel Markus Metz > napsal: > > alternatively, the shebang in GRASS *.py files can be changed to python3 (should be changed to python3 according to Python developer's Guide PEP

Re: [GRASS-dev] [GRASS-user] experimental Python 3 support in trunk

On Mon, Sep 3, 2018 at 8:28 AM Markus Neteler wrote: [...] > > Could you please post a few lines how to properly do the testing with > virtualenv? If python3 with all required packages is already installed on the system, there is a simpler solution than virtualenv: mkdir ~/bin_p3 ln -s

Re: [GRASS-dev] Using grass.message in Python: Why does G_message() print to stderr and not stdout?

On Sun, Sep 9, 2018 at 3:47 PM Markus Neteler wrote: > > Hi, > > Why does G_message() print to stderr and not stdout? > https://trac.osgeo.org/grass/browser/grass/trunk/lib/gis/error.c#L84 Messages, warnings and errors are not output. Consider g.region -g, r.info -g, r.univar -g or any module

Re: [GRASS-dev] Using grass.message in Python: Why does G_message() print to stderr and not stdout?

On Sun, Sep 9, 2018 at 4:46 PM Markus Neteler wrote: > > On Sun, Sep 9, 2018 at 4:23 PM Markus Metz > wrote: > > On Sun, Sep 9, 2018 at 3:47 PM Markus Neteler wrote: > > > > > > Hi, > > > > > > Why does G_message() print to stderr and not stdou

Re: [GRASS-dev] Python and delayed or missing stderr output

On Wed, Sep 5, 2018 at 10:43 AM Markus Neteler wrote: > > Hi, > > AFAIK Python buffers (i.e. effectively delays) stderr output which is > unhelpful in the GRASS GIS context. > > Searching for a solution, I found this reference: sys.stdout.flush() > e.g. >

Re: [GRASS-dev] [GRASS-user] experimental Python 3 support in trunk

On Thu, Sep 6, 2018 at 5:28 AM Vaclav Petras wrote: > > > > On Wed, Sep 5, 2018 at 3:57 PM Markus Metz wrote: >> >> >> >> On Wed, Sep 5, 2018 at 9:41 PM Martin Landa wrote: >> > >> > Hi, >> > >> > st 5. 9. 2018 v 21:3

Re: [GRASS-dev] Python and delayed or missing stderr output

On Sun, Sep 9, 2018 at 9:47 PM Markus Metz wrote: > > > > On Wed, Sep 5, 2018 at 10:43 AM Markus Neteler wrote: > > > > Hi, > > > > AFAIK Python buffers (i.e. effectively delays) stderr output which is > > unhelpful in the GRASS GIS context.

Re: [GRASS-dev] r.series method=minimum yields float map when integer maps are used as input

On Tue, Aug 28, 2018 at 1:49 PM Veronica Andreo wrote: > > Sorry, I pressed send earlier than intended... > > El mar., 28 ago. 2018 a las 13:45, Veronica Andreo () escribió: >> >> Thanks for the explanation, Glynn :) >> >> El mar., 28 ago. 2018 a las 11:01, Glynn Clements (<

Re: [GRASS-dev] Compiler error in /lib/calc

Michael, the includes changed with trunk r72940, you also need to update include/ because f_ceil and f_floor are declared in include/defs/calc.h Markus M On Fri, Jul 6, 2018 at 12:06 AM, Michael Barton wrote: > PS: The errors are undeclared identifiers. Is there something missing that >

Re: [GRASS-dev] New CLI GSoC Idea: Comments, Mentors, Students Needed

On Sun, Mar 11, 2018 at 4:33 AM, Vaclav Petras wrote: > > Dear list, > > I just compiled a another idea for this year GSoC: > > https://trac.osgeo.org/grass/wiki/GSoC/2018#Neweasy-to-useCLIandAPIforGRASSGIS > > All: You may remember this idea from 2015. Since then I

Re: [GRASS-dev] GSOC 2018 project for GRASS GIS

On Wed, Feb 28, 2018 at 3:38 PM, Markus Neteler wrote: > > Hi Sanjeet, > > On Tue, Feb 27, 2018 at 3:08 AM, Sanjeet wrote: > > Hi, > > > > My name is Sanjeet Bhatti and I am an MSc. student in Computer Science > > from University of Saskatchewan, Canada.

<    5   6   7   8   9   10   11   12   >