Re: [GRASS-dev] Looking for >8 bit satellite imagery to test

On Mon, Mar 11, 2019 at 10:09 PM Michael Barton wrote: > > So I downloaded this. What do I do with it? I have gdal 2.3.3 but it doesn't list DIMAP or Spot as a format it recognizes. This is strange because DIMAP has been available in GDAL since before 1.6.0, and the driver is compiled by

Re: [GRASS-dev] [PROJ] GRASS GIS + PROJ 6 + GDAL 2.5

On Fri, Mar 8, 2019 at 5:56 PM Even Rouault wrote: > > On vendredi 8 mars 2019 17:01:57 CET Markus Metz wrote: > > > > My question is, what should GRASS do with a SRS without proj string? The > > best answer is probably: use WKT instead of a proj string. But most of

Re: [GRASS-dev] [PROJ] GRASS GIS + PROJ 6 + GDAL 2.5

On Fri, Mar 8, 2019 at 12:41 PM Even Rouault wrote: > > On vendredi 8 mars 2019 12:27:37 CET Markus Metz wrote: > > On Fri, Mar 8, 2019 at 10:49 AM Roger Bivand wrote: > > > Since rgdal::make_EPSG() is facing the same problems of listing tabulated > > > EPSG fields

Re: [GRASS-dev] GRASS GIS + PROJ 6 + GDAL 2.5

On Fri, Mar 8, 2019 at 10:49 AM Roger Bivand wrote: > > Since rgdal::make_EPSG() is facing the same problems of listing tabulated > EPSG fields as g.proj -l, I was very happy to see Markus' code in > g.proj/main.c mentioned in this thread, and have used this approach in >

Re: [GRASS-dev] GRASS GIS + PROJ 6 + GDAL 2.5

On Thu, Mar 7, 2019 at 5:17 PM Markus Metz wrote: > > > > On Mon, Feb 25, 2019 at 9:42 PM Even Rouault wrote: > > > > On lundi 25 février 2019 15:10:10 CET Markus Metz wrote: > > > Hi all, > > > > > > GRASS needs some adjustments in

Re: [GRASS-dev] GRASS GIS + PROJ 6 + GDAL 2.5

On Mon, Feb 25, 2019 at 9:42 PM Even Rouault wrote: > > On lundi 25 février 2019 15:10:10 CET Markus Metz wrote: > > Hi all, > > > > GRASS needs some adjustments in order to be compatible with PROJ 6 + GDAL > > 2.5 > > > > The plain text file &qu

Re: [GRASS-dev] SVN hint: less disk consumption after "svn cleanup"

On Tue, Mar 5, 2019 at 1:11 PM Markus Neteler wrote: > > Hi devs, > > esp. for those who are contributing to GRASS GIS for while and have > .svn/ directory/-ies in their local source code copy, here a hint to > save (notably) disk space: > running "svn cleanup" shrinks the respective svn control

[GRASS-dev] GRASS GIS + PROJ 6 + GDAL 2.5

Hi all, GRASS needs some adjustments in order to be compatible with PROJ 6 + GDAL 2.5 The plain text file "share/proj/epsg" no longer exists. This file is currently required by the GUI location wizard to retrieve a list of known EPSG codes. Now there is a sqlite db "proj.db", and a new PROJ

Re: [GRASS-dev] Fwd: [PROJ] PROJ 6RC2

er be available in recent PROJ. > > > > Is there anything to do in GRASS GIS (trunk)? > > From what I can see in > https://github.com/GRASS-GIS/grass-ci/blob/master/lib/proj/do_proj.c > Markus Metz made use of proj.h API of PROJ 5. This should still work with PROJ > 6. > > Howe

Re: [GRASS-dev] Fwd: [PROJ] PROJ 6RC2

On Sat, Feb 23, 2019 at 5:17 PM Sebastiaan Couwenberg wrote: > > On 2/23/19 3:59 PM, Markus Neteler wrote: > > there is some discussion about packages that need to be patched to use > > proj_api.h or proj.h which will no longer be available in recent PROJ. > > To clarify, the discussion is about

Re: [GRASS-dev] v.select: increasing memory consumption

EAK SUMMARY: > > ==5173==definitely lost: 956 bytes in 39 blocks > > ==5173==indirectly lost: 72 bytes in 10 blocks > > ==5173== possibly lost: 79 bytes in 4 blocks > > ==5173==still reachable: 9,025,026,330 bytes in 188,201,312 blocks > > ==5173==

Re: [GRASS-dev] v.select: increasing memory consumption

rectly lost: 72 bytes in 10 blocks > ==13217== possibly lost: 79 bytes in 4 blocks > ==13217==still reachable: 9,025,026,330 bytes in 188,201,312 blocks this is the problem, please run valgrind again with --show-reachable=yes we need to find out where these 9,025,026,330 bytes have b

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

Stefan > > Fra: grass-dev på vegne av Markus Neteler > Sendt: mandag 11. februar 2019 20.54 > Til: Nikos Alexandris > Kopi: GRASS-GIS development mailing list > Emne: Re: [GRASS-dev] No 'count' method for r.statistics > > Hi, > > On Fr

[GRASS-dev] closing tickets as wontfix because of "No activity"

Hi Martin, I don't think it is a good idea to close tickets as "wontfix" because of "No activity". The issues might still be relevant. I suggest to ping the appropriate maintainer(s) instead. "wontfix" should IMHO be used if a ticket can not be fixed for technical reasons. my2c Markus M

Re: [GRASS-dev] [GRASS-user] Unable to read .prj file

On Sat, Feb 9, 2019 at 12:05 PM Markus Neteler wrote: > > (adding grass-dev) > > On Sat, Feb 9, 2019 at 11:14 AM Markus Neteler wrote: > > On Sat, Feb 9, 2019 at 10:57 AM Helmut Kudrnovsky wrote: > > > > > > >Just the GRASS GIS logics (still) prevent from accepting a .prj file as > > > input. >

Re: [GRASS-dev] gdal version question

On Thu, Feb 7, 2019 at 8:49 PM Michael Barton wrote: > > Can GRASS work with GDAL versions higher than 2.0, including version 3.x? GDAL 3.x does not exist. GRASS works with all released GDAL versions. Markus M > > I'd like to import new Sentinel-SAFE files and it seems like I need a newer

Re: [GRASS-dev] [GRASS-SVN] r73995 - grass/trunk/scripts/v.db.addtable

On Wed, Jan 30, 2019 at 9:42 AM Markus Metz wrote: > > > > On Tue, Jan 29, 2019 at 11:37 PM Huidae Cho wrote: > > > > Just for our records, actually, PostgreSQL 9.5+ supports CREATE INDEX IF NOT EXISTS, which the grass sqlite driver already does (this is why we

Re: [GRASS-dev] [GRASS-SVN] r73995 - grass/trunk/scripts/v.db.addtable

ct "if" no modules rely on v.db.connect for creating the unique index. >>> >>> Huidae >>> >>> >>> >>> >>> On Tue, Jan 29, 2019 at 3:51 PM Markus Metz < markus.metz.gisw...@gmail.com> wrote: >>>> >>>> >>>>

Re: [GRASS-dev] [GRASS-SVN] r73995 - grass/trunk/scripts/v.db.addtable

odules rely on v.db.connect for creating the unique index. >> >> Huidae >> >> >> >> >> On Tue, Jan 29, 2019 at 3:51 PM Markus Metz < markus.metz.gisw...@gmail.com> wrote: >>> >>> >>> >>> On Tue, Jan 29, 2019 at 4:12 PM Huida

Re: [GRASS-dev] [GRASS-SVN] r73995 - grass/trunk/scripts/v.db.addtable

eate unique index tmp2_cat on tmp2 ( cat ) > ERROR: relation "tmp2_cat" already exists > > > WARNING: Cannot create index > here > WARNING: Values in column will be overwritten > Reading features... > 100% > Updating database... > 100% > > Huidae > > O

Re: [GRASS-dev] [GRASS-SVN] r73995 - grass/trunk/scripts/v.db.addtable

On Sun, Jan 27, 2019 at 11:21 AM Markus Metz wrote: > > > > On Sat, Jan 26, 2019 at 2:50 PM Huidae Cho wrote: > > > > Markus, > > > > If there is a linked table, v.db.addtable stops in line 106. If not, this script doesn't create a unique index and calls v.db.

Re: [GRASS-dev] [GRASS-SVN] r73995 - grass/trunk/scripts/v.db.addtable

On Sat, Jan 26, 2019 at 2:50 PM Huidae Cho wrote: > > Markus, > > If there is a linked table, v.db.addtable stops in line 106. If not, this script doesn't create a unique index and calls v.db.connect. v.db.connect adds a db link in line 317 and creates a unique index (db_create_index2) in line

Re: [GRASS-dev] difference between r.drain and r.path

In GRASS 7.6+, r.drain = (r.fill.dir + )r.path, i.e. r.path and r.drain are not the same. Historically, r.drain has been cloned from r.fill.dir and enhanced to extract paths following directions created with the method of r.fill.dir which is included in r.drain. r.drain has been adjusted to also

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

On Sun, Jan 20, 2019 at 10:28 PM Markus Neteler wrote: > > On Thu, Jan 17, 2019 at 10:17 AM Markus Neteler wrote: > > Done - GRASS GIS 7.6.0 has been released! > > Vero and me (thanks to Helli for several screenshots!) have spend some > more hours on writing/updating these two pages: > > #

Re: [GRASS-dev] v.select: increasing memory consumption

On Fri, Jan 18, 2019 at 8:29 AM Stefan Blumentrath < stefan.blumentr...@nina.no> wrote: > > THanks, we`ll try and report back. > > -Original Message- > From: Markus Neteler > Sent: fredag 18. januar 2019 07:52 > To: Stefan Blumentrath > Cc: GRASS developers list

Re: [GRASS-dev] [release planning] GRASS GIS 7.4.4 - as a "friendship release" for QGIS

On Mon, Jan 7, 2019 at 9:50 PM Martin Landa wrote: > > Hi, > > po 7. 1. 2019 v 21:40 odesílatel Markus Metz > napsal: > > What is the reason to include the point release number in the path: %OSGEO4W_ROOT%\apps\grass\grass-7.4.2\lib ? > > probably inspired by possibili

Re: [GRASS-dev] [release planning] GRASS GIS 7.4.4 - as a "friendship release" for QGIS

On Mon, Jan 7, 2019 at 12:28 PM Pedro Venâncio wrote: > > Hi Martin, > > QGIS batch files in OSGeo4W are still calling GRASS 7.4.2, instead of 7.4.4: > > call "%OSGEO4W_ROOT%"\apps\grass\grass-7.4.4\etc\env.bat > path

Re: [GRASS-dev] how to increase performance of v.out.ogr to geopackage ?

On Thu, Dec 20, 2018 at 10:34 AM Markus Metz wrote: > > > > On Thu, Nov 29, 2018 at 3:43 PM Moritz Lennert < mlenn...@club.worldonline.be> wrote: > > > > Hi, > > > > I have large amount of vector maps (~ 400) which each has hundreds of > > thousa

Re: [GRASS-dev] how to increase performance of v.out.ogr to geopackage ?

On Thu, Nov 29, 2018 at 3:43 PM Moritz Lennert wrote: > > Hi, > > I have large amount of vector maps (~ 400) which each has hundreds of > thousands of areas and over 150 attribute columns. I'm looking for the > most efficient way to export these to a format I can share with > non-GRASS GIS users.

Re: [GRASS-dev] [GRASS-SVN] r73692 - grass/trunk/lib/init

On Sun, Nov 25, 2018 at 4:06 AM Vaclav Petras wrote: > > > > On Sat, Nov 24, 2018 at 9:58 PM Vaclav Petras wrote: >> >> >> On Sat, Nov 24, 2018 at 5:54 AM Markus Metz < markus.metz.gisw...@gmail.com> wrote: >>> >>> >>> >>>

Re: [GRASS-dev] [GRASS-SVN] r73692 - grass/trunk/lib/init

On Thu, Nov 22, 2018 at 11:33 PM Vaclav Petras wrote: > > > > On Thu, Nov 22, 2018 at 10:57 AM Markus Metz < markus.metz.gisw...@gmail.com> wrote: >> >> >> >> On Thu, Nov 22, 2018 at 3:31 PM Vaclav Petras wrote: >> > >> > &

Re: [GRASS-dev] g.region "Illegal instruction (core dumped)"

On Fri, Nov 23, 2018 at 11:06 AM Luca Delucchi wrote: > > Hi devs, > > I installed GRASS 7.6 on a Singularity container [0] but I have > problems with some commands that return "Illegal instruction (core > dumped)", one of this is g.region. The reason is that the GRASS version you are running

Re: [GRASS-dev] [GRASS-SVN] r73692 - grass/trunk/lib/init

On Thu, Nov 22, 2018 at 3:31 PM Vaclav Petras wrote: > > > > On Wed, Nov 21, 2018 at 2:12 PM Martin Landa wrote: >> >> Hi, >> >> st 21. 11. 2018 v 20:05 odesílatel napsal: >> > +# clean the sqlite db >> > +from grass.script import db as gdb >> > +from grass.script import

Re: [GRASS-dev] [GRASS-user] r.covar vs layerStats in R

On Tue, Nov 20, 2018 at 7:59 PM Micha Silver wrote: > > > On 11/19/18 12:41 PM, Markus Neteler wrote: > > On Sun, Nov 18, 2018 at 10:32 PM Micha Silver wrote: > >> I am preparing a correlation matrix for 7 raster layers. The results using the r.covar module are different from the R layerStats

Re: [GRASS-dev] Location creation failure in docker with latest grass trunk version

On Mon, Nov 12, 2018 at 4:24 PM Nikos Alexandris wrote: > > Hi, this is maybe similar to ticket #3693 [0]. > > @neteler In [0], the first example to create a Location, is performed as > root. Curious, why so? Why not as a simple user? > > I just try to update my grassyan Dockerfile [0] and it

Re: [GRASS-dev] [GRASS-user] Create_iwave.py script error for template creation -i.atcorr module-reg

On Wed, Oct 24, 2018 at 8:28 AM kameswari devi wrote: > > Please check the file i have used and error received as an > attachment.I tried to interpolate using Create_iwave.py script for > i.atcorr module but errors are observed. please suggest me thank you Using create_iwave.py in GRASS 7.7,

Re: [GRASS-dev] quickest way to test whether a raster contains any non-null values in the current computational region ?

On Fri, Oct 19, 2018 at 4:04 PM Moritz Lennert wrote: > > On 19/10/18 15:48, Michel Wortmann wrote: > > Hi Moritz, > > How about this: > > > > info = grass.parse_command('r.univar', map='raster_xyz', flags='g') > > print(int(info['n']), int(info['null_cells'])) > > Thanks ! > > Yes, this is one

Re: [GRASS-dev] OSGeo4W-winGRASS 7.7 with new gdal, geos, proj4

On Thu, Oct 18, 2018 at 1:43 PM Martin Landa wrote: > > Hi, > > st 17. 10. 2018 v 17:54 odesílatel Helmut Kudrnovsky napsal: > > - PROJ 5.2.0 (from 4.9.3; plus datumgrids) > > - GEOS 3.7.0 (from 3.6.2) > > - SpatiaLite 4.3.0a (from 4.3.0; also with lwgeom from postgis 2.5) > > - GDAL 2.3.2 (from

Re: [GRASS-dev] Python assertion error in GRASS GIS script

On Fri, Oct 12, 2018 at 11:22 PM Nikos Alexandris wrote: > > > Nikos wrote: > [...] > > >1.001 is most probably a too small difference to 1 considering > >floating point precision limits. > > It is. But then again, how do I decide how "loose" it can be? > > 1.01? > 1.001? > 1.0001?

Re: [GRASS-dev] Python assertion error in GRASS GIS script

On Mon, Oct 8, 2018 at 6:43 PM Nikos Alexandris wrote: > > Dears, > > I try to understand why the following assertion fails to work, as > expected, in a Python GRASS GIS script? > > The following fragment of code > ``` > fraction_categories = grass.parse_command('r.category', >

Re: [GRASS-dev] v.in.ogr and v.import do not import all features in gpkg file

On Thu, Oct 11, 2018 at 9:37 AM Maris Nartiss wrote: > > trešd., 2018. g. 10. okt., plkst. 16:04 — lietotājs Markus Metz > () rakstīja: > > > > >> I am not sure what to do about this. Disable this safety check again? > > > > > > > > > Maybe t

Re: [GRASS-dev] v.in.ogr and v.import do not import all features in gpkg file

On Tue, Oct 9, 2018 at 8:32 PM Veronica Andreo wrote: > > Hi Markus, > > Many thanks for your answer :) > > El mar., 9 oct. 2018 a las 19:42, Markus Metz (< markus.metz.gisw...@gmail.com>) escribió: >> >> >> >> On Tue, Oct 9, 2018 at 2:11

Re: [GRASS-dev] v.in.ogr and v.import do not import all features in gpkg file

On Tue, Oct 9, 2018 at 2:11 PM Veronica Andreo wrote: > > A follow up: > > If I convert the gpkg to shapefile and import into GRASS, then all points are imported: > > v.import input=central.shp layer=central output=central --overwrite > Check if OGR layer contains polygons... > Creating

Re: [GRASS-dev] area calculations in several GIS

ive area size which stays relatively constant. Is there an easy explanation for this divergence increasing with the number of vertices? Markus M > > /Kristian > > -Oprindelig meddelelse- > Fra: Charles Karney På vegne af Charles Karney > Sendt: 2. oktober 2018 22:46 >

Re: [GRASS-dev] area calculations in several GIS

M, Kristian Evers wrote: > > Sorry, I don’t know. It’s possible there’s a bug somewhere. > > > > Charles, do you have any insights here? > > > > /Kristian > > > > *Fra:*Markus Metz > > *Sendt:* 2. oktober 2018 15:01 > > *Til:* Kristian E

Re: [GRASS-dev] area calculations in several GIS

. At some point the calculated areas should start to diverge significantly. I suspect it happens somewhere between county and country. > > > > /Kristian > > > > Fra: Markus Metz > Sendt: 2. oktober 2018 11:51 > Til: Kristian Evers > Cc: GRASS developers list ; Hel

Re: [GRASS-dev] area calculations in several GIS

ea, especially for large polygons, and I would not advice using it as reference for ellipsoidal area calculations. The question is, what can be used as reference? And is the test polygon a "large" polygon, causing "large" deviations from the true area when measured in LAEA?

Re: [GRASS-dev] area calculations in several GIS

in "EU LAEA" and "UTM 33 N" suitable as reference? Discussion started on http://osgeo-org.1560.x6.nabble.com/Re-Qgis-user-New-Features-in-Shape-Tools-3-2-0-td5378898.html Markus M On Mon, Oct 1, 2018 at 2:56 PM Markus Metz wrote: > > > On Tue, Sep 25, 2018 at 7:3

Re: [GRASS-dev] area calculations in several GIS

On Tue, Sep 25, 2018 at 7:38 PM Helmut Kudrnovsky wrote: > > fyi see > https://lists.osgeo.org/pipermail/qgis-developer/2018-September/054644.html > > with GRASS mentioned > -- > Kristian Evers: > > Right, here are the calculated areas as returned by a number of different > GIS

Re: [GRASS-dev] r.tileset and cs2cs / cct

On Fri, Sep 21, 2018 at 3:44 PM Stefan Blumentrath < stefan.blumentr...@nina.no> wrote: > > Hi, > > On my Ubuntu 16.04 box I get the following error message in GRASS 7.4.1 (package install from UbuntuGIS) with r.tileset: > > r.tileset sourceproj=+init=epsg:25833 maxrows=1 maxcols=1 | wc -l

Re: [GRASS-dev] [GRASS-SVN] r73360 - grass/branches/releasebranch_7_6/scripts/r.import

On Mon, Sep 17, 2018 at 3:39 PM Moritz Lennert wrote: > > Markus, > > Could you explain this ? Does this mean that the memory parameter in > r.in.gdal is now automagic ? Or why doesn't it make sens to let the user > define in r.import the memory size ? Markus N and me were discussing this

Re: [GRASS-dev] Issue with v.external.out and GPKG

On Thu, Sep 13, 2018 at 5:03 PM Martin Landa wrote: > > Hi, > > čt 13. 9. 2018 v 16:10 odesílatel Markus Neteler napsal: > > v.external.out output=$outdir format=GPKG > > $outdir should point to GPKG file not to directory, eg. > > v.external.out output=/tmp/test.gpkg format=GPKG > >

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] 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] 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] 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] [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] [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] 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] 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] 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] [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] 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] 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] 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] 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] compile 6S library in GRASS

On Thu, Jun 28, 2018 at 12:17 PM, Roberta Fagandini wrote: > > > > 2018-06-28 10:26 GMT+02:00 Moritz Lennert : >> >> On 27/06/18 15:40, Roberto Marzocchi wrote: >>> >>> >>> >>> Il giorno mer 27 giu 2018 alle ore 15:25 Markus M

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

550nm in the 6s input file are ignored. I added a short note in trunk r72917. Markus M > > > > Maybe something you could have a look at in your GSoC project, Roberta? > > > > Cheers > > Stefan > > > > 1: https://grass.osgeo.org/grass75/manuals/i.atc

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

bility with v = exp(-log(taer55 / 2.7628f) / 0.79902f); Markus M > > > > Cheers > > Stefan > > > > > > From: grass-dev On Behalf Of Yann Chemin > Sent: torsdag 28. juni 2018 13:38 > To: mlenn...@club.worldonline.be > Cc: Markus Metz ; GRASS-dev <

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] 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] 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 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] [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] 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] 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] 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] [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] [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] 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] 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] [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] 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] 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] [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] Default content for the "answer" to G_OPT_F_INPUT

On Tue, Apr 17, 2018 at 4:21 PM, Nikos Alexandris wrote: > > * Moritz Lennert [2018-04-17 15:56:10 +0200]: > >> On 17/04/18 15:31, Nikos Alexandris wrote: >>> >>> Dear developers, >>> >>> is there a way to set a string as the content of a

Re: [GRASS-dev] r.in.gdal -r and r.import extent=region not working properly?

On Mon, Apr 16, 2018 at 6:46 PM, Markus Neteler <nete...@osgeo.org> wrote: > > On Mon, Apr 16, 2018 at 11:39 AM, Markus Metz > <markus.metz.gisw...@gmail.com> wrote: > > On Mon, Apr 16, 2018 at 11:35 AM, Martin Landa <landa.mar...@gmail.com> > > wrote: >

Re: [GRASS-dev] r.in.gdal -r and r.import extent=region not working properly?

On Mon, Apr 16, 2018 at 5:23 PM, Markus Neteler <nete...@osgeo.org> wrote: > > On Mon, Apr 16, 2018 at 11:39 AM, Markus Metz > <markus.metz.gisw...@gmail.com> wrote: > > On Mon, Apr 16, 2018 at 11:35 AM, Martin Landa <landa.mar...@gmail.com> > > wrote: >

Re: [GRASS-dev] r.in.gdal -r and r.import extent=region not working properly?

On Mon, Apr 16, 2018 at 12:28 PM, Nikos Alexandris wrote: > > * Markus Neteler [2018-04-15 22:49:09 +0200]: > >> On Sun, Apr 15, 2018 at 9:46 PM, Markus Neteler wrote: >>> >>> On Sun, Apr 15, 2018 at 8:48 PM, Veronica Andreo

Re: [GRASS-dev] r.in.gdal -r and r.import extent=region not working properly?

On Mon, Apr 16, 2018 at 11:35 AM, Martin Landa <landa.mar...@gmail.com> wrote: > > Hi, > > 2018-04-16 11:32 GMT+02:00 Markus Metz <markus.metz.gisw...@gmail.com>: > > fixed in trunk r72620 and relbr74 r72621. That was a rather serious bug in > > r.in.gdal -r, th

Re: [GRASS-dev] r.in.gdal -r and r.import extent=region not working properly?

On Sun, Apr 15, 2018 at 10:49 PM, Markus Neteler wrote: > > On Sun, Apr 15, 2018 at 9:46 PM, Markus Neteler wrote: > > On Sun, Apr 15, 2018 at 8:48 PM, Veronica Andreo wrote: > >> Hi devs, > >> > >> I just found something odd. I have a

Re: [GRASS-dev] [gdal-dev] PROJ 5 support in trunk

nd then transform from the hub datum to the custom CRS. It will be a best guess as to how to that transformation but better than nothing, and probably correct in most cases. > > I might have overlooked something, so no promises on the final implementation yet! > > > > /Kristian &g

Re: [GRASS-dev] [GRASS-SVN] r72590 - grass/trunk/general/g.region

On Thu, Apr 5, 2018 at 1:09 PM, Jachym Cepicky wrote: > > Hi, > > sorry for too rush approach, you can certainly revert the commit I agree with Martin, the commit does not make sense, and you should revert the commit yourself. Thanks, Markus M > > Jachym > > čt 5. 4.

<    1   2   3   4   5   6   7   8   9   10   >