Hi Francesco,
the proposed change to r.neighbors is interesting, but maybe too specific:
you have introduced two new functions, and many more functions would be
needed to e.g. get the filtered standard deviation or median.
Therefore I suggest adding some filtering option to r.neighbors
Hi Even,
IMHO it has been a bit of a luxury that the GDAL GRASS driver was allowed
to exist as a regular GDAL supported format within frmts/grass. With every
new release of GDAL, you (the GDAL maintainers) also released a separate
new GDAL GRASS driver which was really nice of you!
Considering
On Fri, Sep 10, 2021 at 8:46 PM Vaclav Petras wrote:
>
> On Fri, Sep 10, 2021 at 2:30 PM Markus Metz
wrote:
>>
>> The reason for the rebase was that some tests were failing, apparently
because of a combination of renaming master to main and changes to GHA, and
a PR ca
On Fri, Sep 10, 2021 at 7:51 PM Vaclav Petras wrote:
>
>
>
> On Fri, Sep 10, 2021 at 1:16 PM Markus Metz
wrote:
>>
>> ...
>> $ git checkout raster_tempdir
>> $ git rebase main
>>
>> Successfully rebased and updated refs/heads/raster_tempdir.
>&g
Probably a silly question:
I'm having problems with rebasing my local feature branches for PRs, e.g.
for https://github.com/OSGeo/grass/pull/1786
My local main branch is up to date with the official main branch. In my
case the grass repo is the remote named origin, my fork is the remote named
> proj=7.0.0
> > gdal=3.0.4
> > geos=3.8.0
> > sqlite=3.22.0
> >
> > Cheers
> > Stefan
> >
> > -Original Message-
> > From: Maris Nartiss
> > Sent: tirsdag 24. august 2021 09:03
> > To: Stefan Blumentrath
> > Cc: Martin Land
On Fri, Mar 5, 2021 at 8:30 PM Benjamin Ducke wrote:
>
> Dear Devs,
>
> I am trying to find a way to inject GRASS modules (C code)
> compiled in a GRASS 7 source tree into an already installed
> version of GRASS. Even if I compile in a GRASS 7.8.5 tree and
> then copy into a GRASS 7.8.5 (i.e.
The functions defined in lib/gis/band_reference.c [0] are used for raster
imagery and should thus be removed from lib/gis. There is also
lib/raster/band_reference.c [1] which should be moved to lib/imagery and
the functions need to be renamed.
Martin, can you explain the reason for the existence
On Fri, Mar 5, 2021 at 8:11 PM Helmut Kudrnovsky wrote:
>
> Hi devs,
>
> in OSGeo4W actually:
>
> C:\>proj --version
> Rel. 6.3.2, May 1st, 2020
>
> OSGeo4W next generation is in a testing phase at the moment.
>
> one of the biggest steps forward is:
>
> >PROJ 7.2 <=
>
> is GRASS GIS ready for
On Thu, Feb 11, 2021 at 1:29 PM Nicklas Larsson wrote:
>
> Moritz,
>
> I'd be honoured!
> I will put it on GRASS Wiki [1] if you don't have another suggestion and
notify here when done.
>
Thanks a lot Nicklas for raising this discussion!
I am sure GRASS will benefit if we allow new C standard
, it will still
compile and work.
Increasing the Python version is not safe because existing GRASS Python
code might not be compatible with newer Python versions, thus the need for
a minimum required Python version.
Markus M
On Sun, Feb 7, 2021 at 10:36 PM Markus Metz
wrote:
>
>
>
> On Sun, Feb
On Sun, Feb 7, 2021 at 4:07 PM Moritz Lennert
wrote:
>
>
>
> Am 7. Februar 2021 05:01:38 MEZ schrieb "Anna Petrášová" <
kratocha...@gmail.com>:
> >On Wed, Feb 3, 2021 at 2:47 PM Anna Petrášová
wrote:
> >
> >>
> >>
> >> On Tue, Feb 2, 2021 at 11:20 AM Nicklas Larsson
> >> wrote:
> >>
> >>>
> >>>
On Fri, Feb 5, 2021 at 8:29 PM Markus Metz
wrote:
>
>
> On Thu, Feb 4, 2021 at 5:35 AM Vaclav Petras wrote:
>
> > Similarly to the GDAL and PROJ issue where I don't think it is
necessary to have GRASS C89/C++98 compliant when you need C++11 for GDAL
anyway.
>
> Th
On Fri, Feb 5, 2021 at 5:14 AM Vaclav Petras wrote:
>
> Dear all,
>
> I prepared a change to g.parser and related code which changes the option
definitions in scripts (aka script header) from:
>
> #%option
> #% key
> #%end
>
> to:
>
> # %option
> # % key
> # %end
>
> The reason is PEP8 compliance
On Thu, Feb 4, 2021 at 5:35 AM Vaclav Petras wrote:
> Similarly to the GDAL and PROJ issue where I don't think it is necessary
to have GRASS C89/C++98 compliant when you need C++11 for GDAL anyway.
The C code of GRASS master is currently compatible with a lot of GDAL and
PROJ versions, also
ots/platforms/
> [4] https://grass.osgeo.org/news/2008_04_23_announce_grass630/
>
>
> On Mon, Feb 1, 2021 at 4:25 PM Markus Metz
wrote:
>>
>> A pity that Nicklas did not answer in this thread, see his answer in
https://lists.osgeo.org/pipermail/grass-dev/2021-February/094913.html
>>
>&g
support C11
Markus M
On Mon, Feb 1, 2021 at 8:56 AM Moritz Lennert
wrote:
>
>
>
> Am 31. Januar 2021 22:15:53 MEZ schrieb Markus Metz <
markus.metz.gisw...@gmail.com>:
> >On Fri, Jan 29, 2021 at 11:19 PM Moritz Lennert <
> >mlenn...@club.worldonline.be> wrot
On Sat, Jan 30, 2021 at 5:13 AM Vaclav Petras wrote:
>
>
>
> On Fri, Jan 29, 2021 at 5:20 PM Moritz Lennert <
mlenn...@club.worldonline.be> wrote:
>>
>>
>>
>> Am 29. Januar 2021 20:54:06 GMT+00:00 schrieb Markus Metz <
markus.metz.gisw...@gmail.
On Fri, Jan 29, 2021 at 11:19 PM Moritz Lennert <
mlenn...@club.worldonline.be> wrote:
>
>
>
> Am 29. Januar 2021 20:54:06 GMT+00:00 schrieb Markus Metz <
markus.metz.gisw...@gmail.com>:
> >Hi Huidae,
> >
> >On Thu, Jan 28, 2021 at 6:30 PM Huidae Cho wro
requirement.
Markus M
>
> Regards,
> Huidae
>
> On Thu, Jan 28, 2021 at 12:19 PM Markus Metz <
markus.metz.gisw...@gmail.com> wrote:
>>
>> Hi all,
>>
>> regarding C, there is no need to modernize the code base because the
current C code written for C89 co
Hi all,
regarding C, there is no need to modernize the code base because the
current C code written for C89 compiles just fine with newer standards
which are backwards compatible it seems. The question is if we allow
features from a newer C standard, say C99, to be included in the code base.
In
Dear all,
I have prepared a rather large PR [0] to include proper support for PROJ6+
and WKT2.
The reason is that PROJ6+ uses a new mechanism based on spatial reference
id (authority name and code) and WKT2 for coordinate transformations. The
good old GRASS projection definition, a derivate of
,
GRASS_EPSILON will not detect meaningful differences. GRASS_EPSILON could
instead be modified with something like "max(abs(map_A), abs(map_B)) *
1.0e-15" to test for meaningful differences.
Markus M
On Sun, Jan 24, 2021 at 5:32 PM Markus Metz
wrote:
>
>
>
> On Sun, Jan 24, 20
liably measured. (De-)compression of the data and the operating
system's file cache have a much stronger influence on the runtime.
Markus M
>
> Thanks
> Ming
>
> Markus Metz 于2021年1月24日周日 上午10:57写道：
>>
>> Trying to answer the original question: with a DCELL map "c
Trying to answer the original question: with a DCELL map "cat1_acc_riv" and
a FCELL map "cat1_minacc", why is "float(cat1_acc_riv) ==
float(cat1_minacc)" not equal to "int(cat1_acc_riv) == int(cat1_minacc)" ?
int truncates to integer while float converts to single precision floating
point. E.g.
On Fri, Jan 22, 2021 at 2:51 PM wrote:
>
> Hi devs,
>
> does the default `percentiles=50` in `r.stats.quantile` equal to the
> median?
> Is the definition exclusive or inclusive?
The median is commonly defined as the 50% percentile, the "middle" item of
a sorted dataset. See
On Sat, Mar 14, 2020 at 3:27 PM Paulo van Breugel
wrote:
>
> Dear devs,
>
> I have a grassgis database with in the mapset 'Permanent' a table
> 'vegetation_lookup'. I want top copy this table to the current mapset.
> The following used to work I think, but now gives me some errors:
>
> db.copy
On Fri, Mar 6, 2020 at 8:50 AM Rainer M Krug wrote:
>
> OK. Looking at the parameters GRASS is compiled with (grass78 —config), I
get the following proj related parameter (the complete output at the end of
the email):
>
> --with-proj-includes=/usr/local/opt/osgeo-proj/include
>
On Wed, Feb 26, 2020 at 5:35 PM Vaclav Petras wrote:
>
> Dear all,
>
> In order to compile in a conda environment (where iconv is installed
through conda, not in the system), I'm trying to add a path to icon into
./configure(.in). The issue is that although GRASS happens to configure
properly,
On Wed, Feb 12, 2020 at 6:08 PM Markus Neteler wrote:
>
> Hi devs,
>
> We have accumulated a series of important fixes and would suggest that
> we consider a release in the very near future.
> There is a related 7.8.3 milestone in GH:
>
> https://github.com/OSGeo/grass/milestone/1
>
> along with
Hi Markus,
On Sat, Feb 8, 2020 at 11:21 AM Markus Neteler wrote:
>
> Hi again,
>
> The problem of the missing button seems to be solved (by actually
> re-running the permission assignment in the trac admin section after
> having edited trac.ini).
>
> Now there are two buttons at
On Fri, Feb 7, 2020 at 10:06 PM Vaclav Petras wrote:
>
> Hi Markus,
>
> On Fri, Feb 7, 2020 at 3:40 PM Markus Metz
wrote:
>>
>>
>> now and then I want to view existing GRASS trac tickets, but going to
https://trac.osgeo.org/grass and clicking on "View Tick
Hi all,
now and then I want to view existing GRASS trac tickets, but going to
https://trac.osgeo.org/grass and clicking on "View Tickets" leads me to
https://github.com/OSGeo/grass/issues. Can this redirection be reverted,
please? I need to be able to search GRASS trac tickets.
Markus M
On Fri, Jan 31, 2020 at 9:35 PM Markus Neteler wrote:
>
> On Fri, Jan 31, 2020 at 10:39 AM Pedro Venâncio
> wrote:
> >
> > Hi Anna and Markus,
> >
> > Thank you very much!
> >
> > A filled a ticket: https://github.com/OSGeo/grass/issues/319
>
> It was fixed in master f449ea5 and relbr78 fdd079c
On Tue, Jan 28, 2020 at 12:50 PM Pedro Venâncio
wrote:
>
> Hi all,
>
> I was testing r.slope.aspect with the "new" -n flag, also to include -e
and -n flags in QGIS Processing, but -n flag is giving aspect values of
flat areas as -9998, instead of -, when the precision choosed is CELL,
and the
On Mon, Jan 20, 2020 at 9:26 PM Helmut Kudrnovsky wrote:
>
> while starting
>
> --
> System Info
> GRASS version: 7.9.dev
> Code revision: 3a24c8c74
> Build date: 2020-01-18
> Build platform: x86_64-w64-mingw32
> GDAL: 3.0.2
> PROJ: 6.2.1
> GEOS: 3.8.0
> SQLite: 3.29.0
>
On Thu, Jan 16, 2020 at 10:56 AM Moritz Lennert <
mlenn...@club.worldonline.be> wrote:
>
> Coming back to this to continue the discussion:
>
> On 15/12/19 21:41, Markus Metz wrote:
> >
> >
> > On Tue, Dec 10, 2019 at 6:47 AM Moritz Lennert
> > m
On Sat, Dec 28, 2019 at 11:46 PM Paulo van Breugel
wrote:
>
> On Sat, Dec 28, 2019 at 10:45 PM Markus Metz
> wrote:
> >
> >
> >
> > On Fri, Dec 27, 2019 at 4:49 PM Paulo van Breugel <
p.vanbreu...@gmail.com> wrote:
> > >
> > > Hi de
On Fri, Dec 27, 2019 at 4:49 PM Paulo van Breugel
wrote:
>
> Hi devs,
>
> I am trying to import a vector layer from a PostGIS database in GRASS
> GIS (7.8.3dev, GDAL 3.0.2, Ubuntu 18.04) , but a large number of the
> polygons are skipped with the following warnings:
>
> WARNING: Skipping
On Tue, Dec 10, 2019 at 6:47 AM Moritz Lennert
wrote:
>
> On 9/12/19 22:50, Markus Metz wrote:
> > Hi Moritz,
> >
> > On Wed, Dec 4, 2019 at 10:28 AM Moritz Lennert
> > mailto:mlenn...@club.worldonline.be>>
wrote:
> > >
> > > Hi Mark
On Tue, Dec 10, 2019 at 9:27 AM Markus Neteler wrote:
>
> Hi,
>
> On Mon, Dec 9, 2019 at 11:32 PM Helmut Kudrnovsky <
notificati...@github.com> wrote:
>>
>> After backporting, another RC for 7.8.2 needed?
>>
>> —
>> You are receiving this because you are subscribed to this thread.
>> Reply to
Hi Moritz,
On Wed, Dec 4, 2019 at 10:28 AM Moritz Lennert
wrote:
>
> Hi Markus,
>
> In recent days, I've been confronted several times with the issue of
> people trying to share data among themselves, but using different
> versions of GRASS, and so raster data compressed in a more recent
>
On Wed, Dec 4, 2019 at 2:30 PM Anna Petrášová wrote:
>
> That might be it! Thanks for the answers.
>
> On Wed, Dec 4, 2019 at 1:51 PM Newcomb, Doug wrote:
>>
>> It may be an older version of the zstd library compiled on 7.6.0.
yes, there were some reports of zstd minor version (1.x vs 1.y)
Hi all,
we found a serious bug when importing polygons from a PostgreSQL/PostGIS
db: resultant areas might have wrong attributes because of a mix-up of the
connection from geometries to attributes. This bug has been fixed in master
and relbr78 (a new release of GRASS 7.8 should probably come out
On Wed, Nov 13, 2019 at 3:39 PM Markus Neteler wrote:
>
> On Wed, Nov 13, 2019 at 3:27 PM Pedro Venâncio
> wrote:
> >
> > Hi all again,
> >
> > I've tested GRASS standalone and I got the same error with
WinGRASS-7.8.1-1-Setup-x86_64.
> >
> > Then I uninstalled this version and installed
Regarding GDAL 3 support, we still need to add the new GDAL library
versions to lib/raster/gdal.c for r.external to work.
Markus M
On Tue, Nov 12, 2019 at 8:56 AM Markus Neteler wrote:
> What's new in a nutshell
>
> As a follow-up to the recent GRASS GIS 7.8.0 release we have pusblished
> the
On Fri, Nov 8, 2019 at 10:15 AM Martin Landa wrote:
>
> Hi,
>
> pá 8. 11. 2019 v 8:22 odesílatel Markus Metz
> napsal:
> > > I will try to reword my question. Are you aware of any related
> > > blockers which should avoid us packaging upcoming GRASS 7.8
On Thu, Nov 7, 2019 at 9:39 PM Martin Landa wrote:
>
> Hi Markus,
>
> čt 7. 11. 2019 v 19:50 odesílatel Markus Metz
> napsal:
> > yes, EPSG:3857 is causing trouble. This is the WGS 84 / Pseudo-Mercator
projection on a sphere with radius 6378137 that needs special treatment
On Thu, Nov 7, 2019 at 8:04 PM Even Rouault
wrote:
>
> On jeudi 7 novembre 2019 19:50:33 CET Markus Metz wrote:
> > On Thu, Nov 7, 2019 at 6:47 PM Martin Landa
wrote:
> > > Hi,
> > >
> > > čt 7. 11. 2019 v 15:17 odesílatel Markus Metz
> > >
On Thu, Nov 7, 2019 at 6:47 PM Martin Landa wrote:
>
> Hi,
>
> čt 7. 11. 2019 v 15:17 odesílatel Markus Metz
> napsal:
> > PROJ 6 support is not yet finished in GRASS. Currently it sort of works
in master and relbr78, but I expect troubles because GRASS is heavily
relyi
PROJ 6 support is not yet finished in GRASS. Currently it sort of works in
master and relbr78, but I expect troubles because GRASS is heavily relying
on deprecated proj strings as CRS definitions. This is becoming problematic
e.g. when creating locations from GDAL/OGR datasets because GRASS goes
On Mon, Oct 28, 2019 at 9:18 PM Helmut Kudrnovsky wrote:
>
> Helmut Kudrnovsky wrote
> >>I would like to get PROJ 6 support into G 7.8.1, can we get RC1 out >end
> of
> > this week?
> >
> > Will grass support then also GDAL 3?
Yes, GRASS will then work with GDAL 3 + PROJ 6 (just finished some
I would like to get PROJ 6 support into G 7.8.1, can we get RC1 out end of
this week?
Markus M
On Sun, Oct 20, 2019 at 2:30 PM Markus Neteler wrote:
> On Sat, Oct 19, 2019 at 8:20 PM Markus Neteler wrote:
> >
> > Hi,
> >
> > Anna Petrášová schrieb am Mo., 14. Okt. 2019,
> 21:11:
> >>
> >>
On Wed, Sep 25, 2019 at 10:55 PM Even Rouault
wrote:
>
> On mercredi 25 septembre 2019 22:47:21 CEST Markus Metz wrote:
> >
> > PROJ6 will not use the best method if any required datum transformation
> > grid is not available. Users will need to obtain the corresponding gr
, but if the user can not write to
/usr/share/proj, the grids need to be saved somewhere in $HOME, and PROJ6
must look at that place. This problem, i.e. the place where PROJ6 should
look for in $HOME is not yet solved AFAICT (proj-6.2.0).
Markus M
On Wed, Sep 4, 2019 at 9:46 PM Markus Metz
wrote
On Wed, Sep 4, 2019 at 6:01 PM Markus Neteler wrote:
>
> On Wed, Sep 4, 2019 at 4:31 AM Anna Petrášová
wrote:
> > On Tue, Sep 3, 2019 at 4:22 AM Markus Metz <
markus.metz.gisw...@gmail.com> wrote:
> >>
> >> Hi all,
> >>
> >> there is a new
On Sun, Sep 1, 2019 at 8:35 AM Markus Neteler wrote:
>
>
>
>
> Von: OSGeoLive
> Gesendet: 31. August 2019 17:38:31 OESZ
> Betreff: Re: [OSGeoLive] #2181: GRASS freezes when using r.import on file
without projection
>
> #2181: GRASS freezes when using r.import on
Hi all,
there is a new PR for PROJ6 support in GRASS
https://github.com/OSGeo/grass/pull/118
There are two important changes when using PROJ6:
First, reprojection with v.proj and r.proj is no longer always possible
without the user making informed decisions. The reason is that there can be
On Mon, Aug 5, 2019 at 3:55 PM Markus Neteler wrote:
>
> On Mon, Aug 5, 2019 at 9:11 AM Markus Neteler wrote:
> > On Mon, Aug 5, 2019 at 8:38 AM Markus Metz
> > wrote:
> > > On Sun, Aug 4, 2019 at 3:20 PM Markus Neteler
wrote:
> > > >
> > > >
On Sun, Aug 4, 2019 at 12:19 PM Markus Neteler wrote:
>
> Hi,
>
> On Sun, Aug 4, 2019 at 10:44 AM Markus Neteler wrote:
>
> >
> > as there were no objections, I have created the new
> >
> > https://github.com/OSGeo/grass/tree/releasebranch_7_8
>
> The needed grass77 -> grass78 updates are
On Sun, Aug 4, 2019 at 3:20 PM Markus Neteler wrote:
>
> Hi devs,
>
> since we now have the 7.8 release branch, I suggest to get rid of
> Python 2 support in master.
>
> This will greatly simplify the code. Python 2 is EOL anyway in a few
months.
I guess the first step would be to change the
On Tue, Jul 23, 2019 at 10:24 AM Jürgen E. Fischer wrote:
>
> Hi,
>
> On Tue, 23. Jul 2019 at 10:11:59 +1000, Nyall Dawson wrote:
> > Discussion welcome :)
>
> What's the state of GRASS with PROJ 6?
GRASS compiles with PROJ 6, but does not work properly with PROJ 6 because
PROJ 6 behaves
On Fri, Jul 12, 2019 at 4:23 PM Huidae Cho wrote:
>
> Greetings Developers,
>
> In https://trac.osgeo.org/grass/wiki/HowToGit, it is not clear who is
responsible for merging PRs when. Are individual core developers encouraged
(allowed?) or discouraged to merge them? I'm talking about core, not
Hi Moritz,
On Fri, Jun 28, 2019 at 11:56 AM Moritz Lennert <
mlenn...@club.worldonline.be> wrote:
>
> On 28/06/19 11:10, Stefan Blumentrath wrote:
> > Hi Moritz,
> >
> > Did you consider r.stats -N for checking for NULL values within the
masked area, like:
> > r.stats -N input=tile,MASK
> > if
On Thu, Jun 27, 2019 at 9:27 PM Paulo van Breugel
wrote:
>
> Hi devs,
>
> I am trying to import a shapefile using v.in.ogr, filtering on date
> using datetime, e.g.,
>
> v.in.ogr input=myshapefile.shp layer=myshapefile output=outputlayer
> where="datm_start >= datetime('2019-01-01')"
>
> I am
1020396
>
> Of the non-null cells:
> --
> n: 1004604
> minimum: 3.8147e-06
> maximum: 4.74686
> range: 4.74685
> mean: 0.00587574
> mean of absolute values: 0.00587574
> standard deviation: 0.08715
> variance: 0.00759513
> variation coe
On Fri, Jun 14, 2019 at 1:23 PM Stefan Blumentrath <
stefan.blumentr...@nina.no> wrote:
>
> Hi,
>
> While trying to make r.terraflow work with larger regions, I was
wondering if it would be doable to add a flag to r.hydrodem that forces the
module to perform only sink filling and no breaching /
On Tue, Jun 11, 2019 at 11:12 AM Moritz Lennert <
mlenn...@club.worldonline.be> wrote:
>
> On 10/06/19 21:39, Markus Metz wrote:
> >
> >
> > On Mon, Jun 10, 2019 at 6:12 PM Moritz Lennert
> > mailto:mlenn...@club.worldonline.be>>
wrote:
> > >
>
On Mon, Jun 10, 2019 at 6:12 PM Moritz Lennert
wrote:
>
> Hi,
>
> I just came across this error:
>
> **
> ERROR: Unable to write spatial index. Wrong node position (950329504) in
> file (should be 950333637).
> ERROR: Clipping steps failed. Check above error
example if you PR 28 is on local branch pr_28, branched from master you
can do:
>
> git checkout pr_28
> git diff master...
that's exactly what I was looking for, thanks!
Markus M
>
> P.
>
>
>
> On Wed, Jun 5, 2019 at 6:44 AM Ken Mankoff wrote:
>>
>>
&g
Hi git gurus,
I would like to speed up reviewing of a PR with multiple commits by reading
a single diff file. How is this possible with git? An example is
https://github.com/OSGeo/grass/pull/28
Is this only possible in github looking at the "Files changed"? If github
can do this, can git (on CLI
On Sun, Jun 2, 2019 at 11:12 PM Markus Neteler wrote:
>
> On Sun, Jun 2, 2019 at 10:52 PM Panagiotis Mavrogiorgos
> wrote:
> ...
> > Markus wrote:
> >> It there a way (magic flag?) to avoid this out-of-sync in the first
place?
> >> E.g., for the cronjobs I do not want to go there weekly and "git
On Sun, Jun 2, 2019 at 8:59 PM Veronica Andreo wrote:
>
> Hi devs
>
> Following instructions here:
https://trac.osgeo.org/grass/wiki/HowToGit#Keepyourlocalsourcecodeuptodate,
I get:
>
> [veroandreo@localhost grass7_trunk]$ git remote -v
> origin g...@github.com:veroandreo/grass.git (fetch)
>
On Tue, May 28, 2019 at 6:26 PM Paulo van Breugel
wrote:
>
>
>
> On Tue, May 28, 2019 at 5:30 PM Vaclav Petras
wrote:
>>
>>
>>
>> On Mon, May 27, 2019 at 3:25 PM Paulo van Breugel
wrote:
>>>
>>> Hi Václav / devs
>>>
>>> I am running r.forestfrag in Windows 10, grass 7.6.2 Computation with a
The main advantage of having all grass-addons in one repo is that they are
easy to manage (for core devs).
The main disadvantage of having all grass-addons in one repo is that a
contributor concerned about his single addon needs to get the whole repo,
wasting disk space.
There are probably two
Hi git gurus,
when I modify my local copy and do git commit + git push, I sometimes get
an error:
"failed to push some refs"
and a hint:
"Updates were rejected because the remote contains work that you do not
have locally. This is usually caused by another repository pushing to the
same ref. You
On Mon, May 20, 2019 at 8:43 PM Vaclav Petras wrote:
>
>
>
> On Mon, May 20, 2019 at 1:46 PM Markus Metz
wrote:
>>
>>
>> On Mon, May 20, 2019 at 7:18 PM Vaclav Petras
wrote:
>> >
>> > On Mon, May 20, 2019 at 11:57 AM Markus Metz <
markus.metz.g
On Mon, May 20, 2019 at 7:18 PM Vaclav Petras wrote:
>
>
>
> On Mon, May 20, 2019 at 11:57 AM Markus Metz <
markus.metz.gisw...@gmail.com> wrote:
>>
>>
>>
>> On Mon, May 20, 2019 at 5:39 PM Vaclav Petras
wrote:
>> >
>> > Hi MarkusM and
On Mon, May 20, 2019 at 5:39 PM Vaclav Petras wrote:
>
> Hi MarkusM and all,
>
> I'm trying to understand if the Segment_open() [1] function fills with
zeros or not. I don't think it does since it is calling G_malloc (malloc)
or Segment_format_nofill(). However, it is not completely clear to me
On Sun, May 19, 2019 at 5:24 PM Vaclav Petras wrote:
>
>
>
> On Sat, May 18, 2019 at 12:11 PM Markus Neteler wrote:
>>
>>
>> On Sat, May 18, 2019 at 5:59 PM Panagiotis Mavrogiorgos
>> wrote:
>> >
>> > I would suggest that:
>> >
>> > - even core devs fork the main repo
>> > - "origin" is the
On Thu, May 9, 2019 at 10:01 AM Panagiotis Mavrogiorgos
wrote:
>
> Thank you markus
>
> On Wed, May 8, 2019 at 10:54 PM Markus Metz
wrote:
>>
>> It depends. g.mapset changes the current mapset (and location and
database). It might also create a new mapset in an existing
On Wed, May 8, 2019 at 10:22 AM Panagiotis Mavrogiorgos
wrote:
>
>
>
> On Tue, May 7, 2019 at 11:03 PM Markus Metz
wrote:
>>
>>
>>
>> On Tue, May 7, 2019 at 10:20 AM Panagiotis Mavrogiorgos
wrote:
>> >
>> >
>> >
>> > On
On Wed, May 8, 2019 at 2:34 PM Moritz Lennert
wrote:
>
> On 8/05/19 11:44, Martin Landa wrote:
> > Hi,
> >
> > st 8. 5. 2019 v 11:31 odesílatel Moritz Lennert
> > napsal:
> >> I don't think we have a tool for this currently. However, I'm not sure
that right and left are relevant terms for this
On Tue, May 7, 2019 at 10:20 AM Panagiotis Mavrogiorgos
wrote:
>
>
>
> On Mon, May 6, 2019 at 9:38 PM Markus Metz
wrote:
>>
>>
>>
>> On Mon, May 6, 2019 at 6:21 PM Panagiotis Mavrogiorgos
wrote:
>> >
>> > Hello all,
>> >
>>
On Mon, May 6, 2019 at 6:21 PM Panagiotis Mavrogiorgos
wrote:
>
> Hello all,
>
> I am a bit confused WRT what the expected WIND should be when you create
a new mapset.
>
> Some functions copy DEFAULT_WIND from PERMANENT. E.g.:
>
> lib/gis/make_mapset.c
> pygrass.gis.make_mapset()
> the grass
On Sun, May 5, 2019 at 5:17 PM Helmut Kudrnovsky wrote:
>
> Hi,
>
> looking into winGRASS77svn compilation log:
>
> https://wingrass.fsv.cvut.cz/grass77/x86_64/logs/log-r74459-14/error.log
>
> #
> GRASS GIS 7.7.svn r74459M compilation log
>
Hi Panos,
IMHO the overhead of calling GRASS modules is insignificant because it is
in the range of milliseconds. I am much more concerned whether executing a
GRASS module takes days or hours or minutes.
Also note that the base of GRASS are C modules using the GRASS C library.
GRASS python
On Thu, Apr 25, 2019 at 7:42 AM Martin Landa wrote:
>
> Hi,
>
> st 24. 4. 2019 v 16:28 odesílatel Markus Neteler
napsal:
> > Could you please verify?
>
> yes, the reason is that G76 is not compiled on server due to a new
> required dependency:
>
> configure: error: *** Unable to locate zstd
On Wed, Apr 24, 2019 at 4:28 PM Markus Neteler wrote:
>
> Hi Martin,
>
> since the switch to use G76 as the basis for the addon manual pages,
> the two files
> grassdocs.css
> grass_logo.png
> are no longer put onto the server.
>
> I suspect that they are not picked up on the build server:
>
>
in the existing approaches and
what would you need to add in order to make you prototype work.
>
> Alternatively, or ideally in addition to the above, you can implement
couple of the test and training tasks from the proposal already linked by
Luca:
>
>
https://trac.osgeo.org/grass/wiki/GSoC/
On Thu, Apr 18, 2019 at 6:38 PM Markus Metz
wrote:
>
>
>
> On Tue, Apr 16, 2019 at 11:07 AM Moritz Lennert <
mlenn...@club.worldonline.be> wrote:
> >
> > Hi,
> >
> > If anyone has some time and wants to show off some GRASS GIS power:
> >
>
On Tue, Apr 16, 2019 at 11:07 AM Moritz Lennert <
mlenn...@club.worldonline.be> wrote:
>
> Hi,
>
> If anyone has some time and wants to show off some GRASS GIS power:
>
> https://www.ecmwf.int/en/learning/workshops/ecmwf-summer-weather-code-2019
>
> "The Summer of Weather Code(ESoWC) programme by
On Mon, Apr 15, 2019 at 8:50 AM Markus Neteler wrote:
>
> Hi,
>
> Thanks, all collected as bullet list items (so far) here:
> https://yourpart.eu/p/grassgis_at_foss4g2019
>
> The deadline is later today, so pls (all) let flow in your suggestions.
I have added support for PROJ 6 + GDAL 2.5, I
On Sat, Apr 13, 2019 at 7:24 PM Markus Neteler wrote:
>
> Hi devs,
>
> we still have an older copy of shapelib in
> lib/external/shapelib/
>
> Is that still needed/wanted for the upcoming 7.8.0 release?
> If yes, to be updated?
GRASS is only using the dbf driver of shapelib. Updating is not not
Hi Moritz,
On Wed, Apr 10, 2019 at 4:16 PM Moritz Lennert
wrote:
>
> Hi everyone,
>
> We are looking for a way to transform the r.walk output into a nearest
> neighbor by cost map, i.e. something like the 'nearest' output of r.cost.
>
> Does anyone have an idea of how this could be done with the
On Thu, Mar 28, 2019 at 9:02 AM Maris Nartiss wrote:
>
> Hello Facundo,
> the easiest way would be moving functions of v.generalize into a
> library (e.g. grass_generalize) and thus make available for calling
> via ctypes.
> In the past I have had a good success manipulating GRASS vectors via
>
On Wed, Mar 27, 2019 at 5:42 PM Luís Moreira de Sousa <
luis.de.so...@protonmail.ch> wrote:
>
> Hi all,
>
> I am working with vector layers (points) composed of more than 100 000
geometries. These layers are originally in a PostGis database and I import
them with v.in.ogr, using a formulation
On Sat, Mar 16, 2019 at 3:32 PM Markus Neteler wrote:
>
> Hi devs,
>
> GRASS GIS schrieb am Di., 12. März 2019, 08:45:
>>
>> #3790: Cleanup gettext usage for python code
>> --+-
>> Reporter: pmav99 | Owner: grass-dev@…
>> Type:
Dear Roger,
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
>
On Tue, Mar 12, 2019 at 6:51 PM Pablo J. Zader wrote:
>
> Hi list
>
> Currently, I need to specify in the "r.in.gdal" command, certain
configuration options provided by the gdal package. i.e .
> --config
> as described in the following report [1].
>
> Has this modification been implemented or
1 - 100 of 1175 matches
Mail list logo
