Re: [GRASS-dev] Debugging, parallelism, etc.

[Moritz Lennert]

Am 09.10.2022 20:45 schrieb Brad ReDacted:

Those variables would be...? Is this documented somewhere? If not, can
we get it documented?


https://grasswiki.osgeo.org/wiki/Working_with_GRASS_without_starting_it_explicitly



OpenMP can do far more than just loop "unrolling", these days. Tasking
sections to run concurrent is also quite trivial. It can also offload
to GPU, etc. Check out the v4.5+ spec. It's pretty impressive. I
believe it can do most of what pthreads does, but you certainly lose
control of implementation details. Some compilers have an omp library
while others convert to pthreads.

I do find myself rewriting algorithms so that OpenMP can handle them.
It doesn't seem to handle nested loops with breaks very well and I'm
not entirely sure why.

On 10/9/2022 10:43 AM, William Hargrove wrote:
Can still run GRASS outside the shell by setting all of the 
environment variables appropriately ...


OpenMP just works by "unrolling" all of the determinate loops, i.e., 
the ones that iterate a fixed number of times.  No speedups to 
anything else.


Speedup from OpenMP will be limited, depending on the number of 
determinate loops present, and how much of the load they represent.


pthreads are totally flexible, but the programmer has to specify 
everything, very carefully ...


But pthreads can speed up lots of stuff outside of determinate loops 
...



HTH,

Bill H.


On 10/9/2022 12:37 PM, Brad ReDacted wrote:

Hello,

I'm working on adding parallelism to modules, but debugging is 
turning out to be a logistical nightmare:


Why do I not get any reporting from GCC option 
'-fsanitize=address|thread"?


I am also having trouble getting the profiler to work properly inside 
GRASS (I assume due to shell?). The gmon.out file produced has no 
usable data.


OpenMP is extremely poorly supported by most tools. valgrind with 
helgrind reports a lot of nonsense. I can't seem to get the Intel 
linux tools to work properly, either.


BTW, we are supporting both pthreads and OpenMP. While this isn't an 
issue in most cases, there can be races and deadlocks if not handled 
properly. Pthreads aren't entirely portable. OpenMP is. However, 
pthreads gives us a more control. May I suggest using OpenMP for most 
modules and reserve Pthreads to libraries, etc? Or should we start 
moving away from pthreads?


Any suggestions would be greatly appreciated!





--
Best Regards,
-Brad

___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev


___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] multiprocessing problem

[Moritz Lennert]

Hi Luca,

Just two brainstorming ideas:

- From a rapid glance at the code it seems to me that you create a separate 
worker for each row in the raster. Correct ? AFAIR, spawning workers does 
create quite a bit of overhead. Depending on the row to column ratio of your 
raster, maybe you would be better off sending larger chunks to workers ?

- Depending on the number of parallel jobs, disk access can quickly become the 
bottleneck on non parallelized file systems. So it would be interesting to see 
if using fewer processes might actually speed up things. Then it is a question 
of finding the equilibrium.

Moritz 

Le 8 avril 2022 07:32:37 GMT+02:00, Luca Delucchi  a 
écrit :
>Hi devs,
>
>I wrote an addons to calculate Rao's Q diversity index [0], I would
>like to speed it up using multiprocessing but with multiprocessing it
>took 2/3 times longer than a single process. Could someone look at the
>code and explain to me what I'm doing wrong?
>A colleague of mine suggested using cython with prange function [1]
>but I would avoid it since I need to study it and how to compile it in
>GRASS and I have no time to spend on it.
>
>thanks a lot
>Luca
>
>[0] https://github.com/lucadelu/grass-addons/tree/raoq/src/raster/r.raoq.area
>[1] https://cython.readthedocs.io/en/latest/src/userguide/parallelism.html
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Invitation: End of year toast :)

[Moritz Lennert]

Hi everyone,

Won't be able to join you tonight. I wish everyone a happy new year 2022 with 
many great releases of GRASS GIS !

Moritz

Le 27 décembre 2021 13:46:10 GMT+01:00, Veronica Andreo  
a écrit :
>Dear all,
>
>We'd like to invite you all to a virtual end of year toast on *Wednesday,
>December 29th at 20:00 UTC* (See some local times:
>https://www.timeanddate.com/worldclock/meetingdetails.html?year=2021=12=29=20=0=0=485=48=207=197
>)
>
>We'll share the link on this thread a couple of hours before the event.
>Mark your calendars!
>
>Looking forward to seeing you!
>Vero
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Release of 7.8.6 ?

[Moritz Lennert]

Great news ! Thanks a lot for all your work, Martin !

Moritz

Le 11 octobre 2021 13:14:45 GMT+02:00, Martin Landa  a 
écrit :
>Dear all,
>
>čt 7. 10. 2021 v 23:21 odesílatel Veronica Andreo  
>napsal:
>>> > Let's release 7.8.6 as it is (with an already big delay). If there are
>>> > no objections I will prepare a 7.8.6 release in upcoming days. Martin
>>
>>
>> Big +1!!
>
>7.8.6 is out [1]!
>
>* trac page updated [2] - feel free to improve
>* PR for website prepared [3] - please contribute/review (we need a
>new fancy screenshot for announcement)
>* WinGRASS binaries 64 ready for testing (standalone installer [4] and
>osgeo4w v2 [5])
>* WinGRASS addons build activated [6]
>
>What is missing:
>
>* wingrass 32bits (will do it today)
>* ubuntugis unstable (will do in next days)
>* do marketing [7]
>
>Martin
>
>[1] https://github.com/OSGeo/grass/releases/tag/7.8.6
>[2] https://trac.osgeo.org/grass/wiki/Release/7.8.6-News
>[3] https://github.com/OSGeo/grass-website/pull/271
>[4] 
>https://grass.osgeo.org/grass78/binary/mswindows/native/x86_64/WinGRASS-7.8.6-1-Setup-x86_64.exe
>[5] http://download.osgeo.org/osgeo4w/v2/osgeo4w-setup.exe
>[6] https://wingrass.fsv.cvut.cz/grass78/x86_64/addons/grass-7.8.6/logs/
>[7] 
>https://github.com/OSGeo/grass/blob/main/doc/howto_release.md#marketing---tell-others-about-release
>
>-- 
>Martin Landa
>http://geo.fsv.cvut.cz/gwiki/Landa
>http://gismentors.cz/mentors/landa
>___
>grass-dev mailing list
>grass-dev@lists.osgeo.org
>https://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Release of 7.8.6 ?

[Moritz Lennert]

Martin, Vaclav,

Where are we at concerning the 7.8.6 release ? Did you work on this 
during your code sprint ? (sorry I was busy with a code sprint of my own 
at work, so I couldn't join).


Moritz

Am 03.10.2021 10:13 schrieb Nicklas Larsson:

Hi All!

There are some fixes that are labeled for backport for 7.8.6 [1] and
yet another bunch without milestone [2], but haven't been backported.

I know this is in the nick of time, after the release of RC3, but if
there is a very important fix it shouldn't be left out. Otherwise the
milestone should be set/bumped to 7.8.7.

Best, Nicklas



[1] 
https://github.com/OSGeo/grass/pulls?q=is%3Apr+is%3Aclosed+label%3Abackport_needed+milestone%3A7.8.6
[2] 
https://github.com/OSGeo/grass/pulls?q=is%3Apr+is%3Aclosed+label%3Abackport_needed+no%3Amilestone





  
Pull requests · OSGeo/grass
GRASS GIS - free and open source Geographic Information System (GIS) -
Pull requests · OSGeo/grass  





On Wednesday, 29 September 2021, 19:21:00 CEST, Martin Landa
 wrote:





Hi,

čt 23. 9. 2021 v 8:56 odesílatel Martin Landa  
napsal:

right, 7.8.6 needs to release ASAP. New release also fixes
g.extension. It would be nice to merge [1] before release.


recently I made necessary changes (see related PR [1]) in order to
build a `grass` package on the top of OSGeo4W v2 including a
standalone installer, which you can test [2].

I would suggest publishing RC3 after merging PR mentioned above. If
there are no objections I will merge PR above and release RC3 in the
next few days.

Martin

[1] https://github.com/OSGeo/grass/pull/1893
[2] https://github.com/OSGeo/grass/pull/1893#issuecomment-930361434


--
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev


___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Community sprint at FOSS4G 2021

[Moritz Lennert]

Hi all,

I wanted to at least pop by and say hi, but I don't see anyone on the 
map in the code sprint room. There are four different jitsi meeting 
rooms in that map, but only one is currently used.


If we decide to use another Jiitsi link for GRASS GIS discussions, we 
are asked to include that into the wiki (and ideally also post it in the 
Code sprint channel on the foss4g venueless site.


So, is anyone currently somewhere ? :-)

Moritz

On 2/10/21 10:32, Stefan Blumentrath wrote:

Hi,

It`s autumn holiday around Oslo/Norway, so I will be a bit on and off 
today (unfortunately more off than on), but try to join at least in the 
European evening…


Main aim for the community sprint for me would be to get a GRASS 8.0 
packaged in OSGeo4W. Without PDAL support that is very close, but I 
really think not having PDAL support on MS Windows would be sad.


So, if anybody with C++ build experience (and maybe build experience on 
MS Win) would be available for a chat about possible paths to achieve 
that, I would be very glad. Please get in touch.


If I find the time I will likely work on some of my stale PRs …

That said, I briefly joined 
https://play.workadventu.re/@/osgeo/foss4g/codesprint 



But no one seems to be there at the moment…

Is there a Jitsi (or similar) room to meet? A chat maybe?

Cheers

Stefan

*From:*grass-dev  *On Behalf Of *Wolf 
Bergenheim

*Sent:* fredag 1. oktober 2021 16:32
*To:* Ondřej Pešek 
*Cc:* grass-dev@lists.osgeo.org
*Subject:* Re: [GRASS-dev] Community sprint at FOSS4G 2021

European morning works for me. Will be in and out, though. Mainly I'm 
looking for opportunities to contribute after 10 years away :P


--Wolf

*-- *

* ^.___*

*( ,__/
/ / Wolf Bergenheim*

On Fri, 1 Oct 2021 at 09:31, Ondřej Pešek > wrote:


Ciao,

st 29. 9. 2021 v 23:04 odesílatel Vaclav Petras
mailto:wenzesl...@gmail.com>> napsal:

We are having a community sprint on Saturday, October 2nd, 2021.

Is anybody interested in working together during the European
morning instead of waiting for the conference day to start?

I wanted to make a quick visit in the European morning, but just to
do something with the addons (as the grass8 branch is going to be
created for the sprint, right?). Maybe in the end I'll do also some
source GRASS work, but I am still not sure if I'll have enough time
for that.

___
grass-dev mailing list
grass-dev@lists.osgeo.org 
https://lists.osgeo.org/mailman/listinfo/grass-dev




___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev



___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Release of 7.8.6 ?

[Moritz Lennert]

Hi everyone,

Colleagues of mine are being bitten by 
https://github.com/OSGeo/grass/issues/1793 while teaching. It seems that 
wxpython 4.1 is becoming more widespread and so more and more people seem 
victim to this.

I was unaware of this bug. IMHO it probably should have warranted a quick 
release just for that solution, as it makes calling the module GUIs difficult, 
so basically rendering GRASS GIS useless for people who depend on the GUI.

So, where are we at with the release of 7.8.6 ? At the meeting last week we 
said it should be released ASAP. Anything some of us can do to speed the 
process ?

Moritz
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Fwd: [GRASS-web] New GIS mirror in Rabat, Morocco

[Moritz Lennert]

FYI

I think this needs some configuration because to get to the web site you 
need to go to https://mirror.marwan.ma/grass/html, but then none of the 
internal links work.


Does someone have more experience with mirroring than me and can give 
some hints here ?


Moritz

 Forwarded Message 
Subject: [GRASS-web] New GIS mirror in Rabat, Morocco
Date: Fri, 17 Sep 2021 11:11:37 +0100
From: Sami Ait Ali Oulahcen 
To: grass-...@lists.osgeo.org

Hi,

We're mirroring GIS at https://mirror.marwan.ma/grass/
We’re offering http, https, and rsync. The mirror is ipv4/ipv6 capable, 
and running behind a 5Gbps link.

Institution: MARWAN
Website: marwan.ma
Technical contact: n...@marwan.ma

Regards,
Sami
___
grass-web mailing list
grass-...@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-web
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [SoC] GSoC 2021 - Final Report [Parallelization of raster modules for GRASS GIS]

[Moritz Lennert]

Hi Aaron,

Works wonderfully, thanks ! I've had some issues when using a mask and 
errors related to ZSTD compression, but no idea if it is linked to your 
code, and no time today to follow up.


Moritz

Am 13.09.2021 17:43 schrieb Aaron Saw Min Sern:

Hi Moritz,

Yes, you can just apply the PR, either by checking into the branch, or
on your local machine, you can rebase the branch on top of the current
main branch (I don't think there will be any conflicts) Let me know if
there are any issues :)

Warm regards,
Aaron

-

FROM: Moritz Lennert 
 SENT: Monday, 13 September 2021, 23:33
 TO: Aaron Saw Min Sern
 CC: grass-dev@lists.osgeo.org
 SUBJECT: Re: [GRASS-dev] [SoC] GSoC 2021 - Final Report
[Parallelization of raster modules for GRASS GIS]

 - External Email -

 Hi Aaron,

 I have a use case for which I would like to try the parallelized
 r.neighbors. Do I just have to apply PR 1724 to current main to be
able
 to do this, or do I have to do something else ?

 Moritz

 Am 25.08.2021 15:59 schrieb Aaron Saw Min Sern:
 > Hi all,
 >
 > Thanks Vero for spotting the mistakes on the links. The formatting
of
 > the links must have gone wrong, but here's the links to the
respective
 > PR.
 >
 > * r.univar - 1634 [1]
 > * r.neighbors - 1724 [2]
 > * r.mfilter - 1708 [3]
 > * r.resamp.filter - 1759 [4]
 > * r.resamp.interp - 1771 [5]
 > * r.slope.aspect - 1767 [6]
 > * r.series - 1776 [7]
 > * r.patch - 1782 [8]
 >
 > I will still be working on getting the checklists completed in the
 > next few weeks.
 >
 > Warmest regards,
 > Aaron
 >
 > -
 >
 > FROM: Veronica Andreo 
 > SENT: Tuesday, August 24, 2021 8:48 PM
 > TO: Aaron Saw Min Sern 
 > CC: s...@lists.osgeo.org ;
 > grass-dev@lists.osgeo.org 
 > SUBJECT: Re: [GRASS-dev] [SoC] GSoC 2021 - Final Report
 > [Parallelization of raster modules for GRASS GIS]
 >
 > - External Email -
 >
 > Dear Aaron,
 >
 > Thanks for your report and all your work to make GRASS raster
modules
 > run faster, we like that :) Huge thanks as well to Vaclav, Huidae
and
 > Maris for their commitment to the project and mentoring! You all
did a
 > great team work!
 >
 > One question: are these changes planned to be merged before the
 > creation of grass 8 branch or will they remain for 8+? Maybe add a
 > milestone to clarify?
 >
 > One minor observation: all links currently point to the same PR
 >
 > We hope to keep seeing you around, Aaron!
 >
 > All the best,
 > Vero
 >
 > El mar, 24 ago 2021 a las 3:18, Aaron Saw Min Sern
 > () escribió:
 >
 >> Hello everyone,
 >>
 >> Here is my final report for GSoC 2021 project, _Parallelization of
 >> Raster Modules for GRASS GIS_.
 >>
 >> ABSTRACT
 >> The goal of this project is to introduce parallelization to
 >> existing raster modules in GRASS GIS using OpenMP. This will allow
 >> users to take advantage of more cores in their hardware to speed
up
 >> the computation time especially for large raster files with large
 >> computation cost. The key challenge of this project is to separate
 >> the parallelizable components from the sequential part of the
 >> modules without introducing too much overhead in terms of memory,
 >> disk or computation resources.
 >>
 >> MILESTONES
 >>
 >> In total, I have introduced OpenMP support to 8 raster modules in
 >> GRASS GIS. The pull requests to each module are as follows:
 >>
 >> * r.univar - https://github.com/OSGeo/grass/pull/1634 [1] [1]
 >> * r.neighbors - https://github.com/OSGeo/grass/pull/ [2] [1]1724
[2]
 >> * r.mfilter - https://github.com/OSGeo/grass/pull/ [2] [1]1708 [3]
 >> * r.resamp.filter - https://github.com/OSGeo/grass/pull/ [2]
[1]1759
 >> [4]
 >> * r.resamp.interp - https://github.com/OSGeo/grass/pull/ [2]
[1]1771
 >> [5]
 >> * r.slope.aspect - https://github.com/OSGeo/grass/pull/ [2]
[1]1767 [6]
 >> * r.series - https://github.com/OSGeo/grass/pull/ [2] [1]1776 [7]
 >> * r.patch - https://github.com/OSGeo/grass/pull/ [2] [1]1782 [8]
 >>
 >> Firstly, I have greatly underestimated the complexity of the work.
 >> Up to 20 modules were initially proposed at first but after the
 >> second week. However, it became clear that we had to cut down on
the
 >> number of target modules and focus more on designing the
algorithms.
 >> The modules we targeted behave differently as compared to some
 >> modules that had received OpenMP support in the past such as
 >> _r.sun_. In particular, the modules need to keep the same of
 >> behavior of having low memory footprint even after the
 >> parallelization, unlike _r.sun_ which loads the entire raster map
 >> 

Re: [GRASS-dev] [SoC] GSoC 2021 - Final Report [Parallelization of raster modules for GRASS GIS]

[Moritz Lennert]

Hi Aaron,

I have a use case for which I would like to try the parallelized 
r.neighbors. Do I just have to apply PR 1724 to current main to be able 
to do this, or do I have to do something else ?


Moritz

Am 25.08.2021 15:59 schrieb Aaron Saw Min Sern:

Hi all,

 Thanks Vero for spotting the mistakes on the links. The formatting of
the links must have gone wrong, but here's the links to the respective
PR.

* r.univar - 1634 [1]
* r.neighbors - 1724 [2]
* r.mfilter - 1708 [3]
* r.resamp.filter - 1759 [4]
* r.resamp.interp - 1771 [5]
* r.slope.aspect - 1767 [6]
* r.series - 1776 [7]
* r.patch - 1782 [8]

 I will still be working on getting the checklists completed in the
next few weeks.

 Warmest regards,
 Aaron

-

FROM: Veronica Andreo 
 SENT: Tuesday, August 24, 2021 8:48 PM
 TO: Aaron Saw Min Sern 
 CC: s...@lists.osgeo.org ;
grass-dev@lists.osgeo.org 
 SUBJECT: Re: [GRASS-dev] [SoC] GSoC 2021 - Final Report
[Parallelization of raster modules for GRASS GIS]

- External Email -

Dear Aaron,

Thanks for your report and all your work to make GRASS raster modules
run faster, we like that :) Huge thanks as well to Vaclav, Huidae and
Maris for their commitment to the project and mentoring! You all did a
great team work!

One question: are these changes planned to be merged before the
creation of grass 8 branch or will they remain for 8+? Maybe add a
milestone to clarify?

One minor observation: all links currently point to the same PR

We hope to keep seeing you around, Aaron!

All the best,
Vero

El mar, 24 ago 2021 a las 3:18, Aaron Saw Min Sern
() escribió:


Hello everyone,

Here is my final report for GSoC 2021 project, _Parallelization of
Raster Modules for GRASS GIS_.

ABSTRACT
The goal of this project is to introduce parallelization to
existing raster modules in GRASS GIS using OpenMP. This will allow
users to take advantage of more cores in their hardware to speed up
the computation time especially for large raster files with large
computation cost. The key challenge of this project is to separate
the parallelizable components from the sequential part of the
modules without introducing too much overhead in terms of memory,
disk or computation resources.

MILESTONES

In total, I have introduced OpenMP support to 8 raster modules in
GRASS GIS. The pull requests to each module are as follows:

* r.univar - https://github.com/OSGeo/grass/pull/1634 [1]
* r.neighbors - https://github.com/OSGeo/grass/pull/ [1]1724 [2]
* r.mfilter - https://github.com/OSGeo/grass/pull/ [1]1708 [3]
* r.resamp.filter - https://github.com/OSGeo/grass/pull/ [1]1759
[4]
* r.resamp.interp - https://github.com/OSGeo/grass/pull/ [1]1771
[5]
* r.slope.aspect - https://github.com/OSGeo/grass/pull/ [1]1767 [6]
* r.series - https://github.com/OSGeo/grass/pull/ [1]1776 [7]
* r.patch - https://github.com/OSGeo/grass/pull/ [1]1782 [8]

Firstly, I have greatly underestimated the complexity of the work.
Up to 20 modules were initially proposed at first but after the
second week. However, it became clear that we had to cut down on the
number of target modules and focus more on designing the algorithms.
The modules we targeted behave differently as compared to some
modules that had received OpenMP support in the past such as
_r.sun_. In particular, the modules need to keep the same of
behavior of having low memory footprint even after the
parallelization, unlike _r.sun_ which loads the entire raster map
in-memory.

During the first half of the GSoC, with the mentors’ discussion,
we have come out with three different approaches to introducing
parallel support to _r.neighbors_. After benchmarking their
performance and taking account of their memory/disk usage, we
decided to settle with the last approach which requires us to add an
extra parameter _memory_ to allow users to adjust their memory
consumption. With this approach, we have to allow the modules to
process the raster map by chunks. Once we settled about the design,
we started applying the same approach to other similar modules with
low memory footprints.

For more information regarding the implementation, see
https://grasswiki.osgeo.org/wiki/Raster_Parallelization_with_OpenMP
[9].

Furthermore, test scripts were included in the modules to ensure the
consistency of the results. Benchmark scripts were added to allow
users to easily benchmark the performance of the parallelization to
monitor the speedup in their own local machine. User documentations
were also modified to include sections detailing how to make use of
the newly added features.

FUTURE WORK

In the future, more raster modules can be parallelized using similar
approach. Then, we can consider tackling more complex modules such
as _r.watershed_ and _r.mapcalc_. Also, we could consider exploring
3D raster modules as well.

Furthermore, when we implement parallelization for _r.univar_, we
notice that modules that produce 

[GRASS-dev] GRASS GIS moves to Open Collective for collecting donations and thanks its many financial contributors

[Moritz Lennert]

Dear all,

In order to make money donations easier, the GRASS GIS project has 
decided to use the Open Collective platform with the Open Source 
Geospatial (OSGeo) Foundation as its fiscal host:  
https://opencollective.com/grass. You can donate money via credit card, 
PayPal, or bank transfer (US account - for EU account please contact 
us). This new platform replaces our old PayPal Money Pool.


Although most of the work on GRASS GIS happens on a voluntary basis (or 
donated by organizations and companies in the form of working time of 
their staff), money donations are very important for the development of 
GRASS GIS as they allow us to organize face-to-face coding sessions 
(sprints), finance infrastucture needs (web site, etc) and sometimes pay 
developers to work on important but tedious bug fixes or high community 
value enhancements. The new platform allows both individuals and 
companies or organizations to contribute to the GRASS GIS budget.


We would also like to take the opportunity to thank those who have 
already contributed money in the last years. You can see a complete list 
of sponsors on https://grasswiki.osgeo.org/wiki/Sponsors. Whatever the 
amount your help is deeply appreciated !


We particularly encourage companies and organizations that use GRASS GIS 
in their daily work to consider contributing. As an example of such 
company support we wish to highlight the very generous donation recently 
received from Bohannan Huston, Inc. (https://bhinc.com/). We asked 
Robert S. Dzur, Vice President Spatial Data, to explain their motivation 
behind supporting the project. Here is what he has to say:


"Our use of GRASS GIS is primarily related to areas of data inventory, 
visualization, quality assessment and analysis.  As data producers, we 
are regularly confronted with production challenges related to ingesting 
and visualizing high data volumes of imagery, elevation / point cloud 
and feature data.  GRASS GIS gives us the ability to quickly handle 
large datasets at any point in the production stage.  For example, we 
use r.in.lidar and its capacity to read large multi-billion point 
datasets from a text list and create derivative elevation data products 
often to support both quality assurance tasks as well as base maps for 
vector feature data development.  GRASS GIS's multiplatform (Windows, 
Mac, Linux) support and integration with GDAL/OGR is also a plus for us. 
 GRASS GIS gives us direct control, access, and the ability to interact 
with our data at very granular levels.  My colleague, Dennis Sandin also 
reminded me that one of the greatest benefits of GRASS GIS is that its 
environments gives us a plethora of options for manipulating data and 
testing/designing our automation/workflow processes. We also appreciate 
the GRASS GIS legacy and its long history of development dating back to 
its genesis with the US Army Corps of Engineers and the continued 
scientific foundations of its applications.


Over the past few years, we have been making a concerted effort on two 
fronts to 1) support the geospatial open-source community and 2) reduce 
our dependence on commercial software.  Typically, our support had been 
through sponsoring the broader community through code sprint events.  
Last year, however, with code sprints on-hold we decided to contribute 
to the QGIS crowdfunding campaign for point cloud functionality.  At the 
same time, we attempted to make a corresponding reduction in our 
commercial licensing contracts.  This year we have also been trying to 
reach out to some of our key clients and teach team how to use GRASS GIS 
on their own computing infrastructure.  Specifically, we engaged with 
one client to teach them how to use r.in.pdal to develop elevation range 
maps from LiDAR point cloud data as a complementary data element in 
their NDVI analysis to identify vegetation canopy.  Another client was 
interested in merging DEM data of differing source lineage and quality 
and we conducted a basic how to session on GRASS GIS with them and 
shared details about r.patch and r.patch.smooth.  Given those recent 
technical exchange efforts locally with some of our clients, our 
experience with GRASS GIS, and our objective to support a specific 
open-source project, this year we decided to contribute to the GRASS GIS 
project.


If there are companies or organizations like us who are not already 
using GRASS GIS to improve their workflows, they should be."


Convinced you want to support GRASS GIS financially ? Go to 
https://opencollective.com/grass !


The GRASS GIS development team
~
___
grass-psc mailing list
grass-...@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-psc

___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GitHub Discussions is enabled

[Moritz Lennert]

Am 03.09.2021 09:29 schrieb Nikos Alexandris:

Dear all,

GitHub Discussions is enabled
(https://github.com/OSGeo/grass/discussions/1841) -- obviously and
clearly _not_ replacing the mailing lists.

Warm regards, Nikos


Thanks, Nikos, for the dedication you are showing for this and for being 
willing to push it through !


:-)
Moritz

___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] GRASS GIS 8: create new release branch

[Moritz Lennert]

Le 16 août 2021 18:20:42 GMT+02:00, Veronica Andreo  a 
écrit :
>Hi all,
>
>El vie, 6 ago 2021 a las 4:29, Vaclav Petras ()
>escribió:
>
>> Are we ready to create the 8.0 release branch?
>>
>
>Seems we are!!
>
>Once we create it, we will need to backport (cherry-pick) updates from the
>> master branch when needed.
>>
>> Please see the following for the individual issues we still have and post
>> here if you see some priorities.
>>
>> On Wed, Jul 14, 2021 at 5:24 PM Vaclav Petras 
>> wrote:
>>
>>>
>>>
 Windows build & test is just bad (no bug or PR so far?),
>>>
>>>
>>> Can someone give an update on that, please?
>>>
>>
>>
>>> #1683 is not merged yet, but missing sh in the test environment is not a
>>> blocker in this case.
>>>
>>
>> https://github.com/OSGeo/grass/pull/1683
>>
>> Tests are running!
>>
>>
>>>  CentOS is too
>>>
 old (#1709) & needs auto tools update to fix it (or at least env
 variable in build script as I just have done to enable testing in
 #1501),
>>>
>>>
>>> ...or CentOS 8, CentOS Stream, or remove the CentOS test.
>>>
>>> https://github.com/OSGeo/grass/issues/1709#issuecomment-880215427
>>>
>>
>> It would be better if Autotools are updated, but CentOS build works now.
>> Are there any pressing issues?
>>
>>
>>> I would also strongly advocate merging ctypes upgrade before 8.0

>>>
>>> Seems to be close to being finished too.
>>>
>>
>> ctypes update is closer everyday, but not finished yet. Maybe not needed
>> for 8.0?
>>
>> https://github.com/OSGeo/grass/pull/1651
>>
>
>Milestone was changed to 8.2 and Nicklas suggest to move forward with
>release branch 8
>
>>
>> On Wed, Jul 28, 2021 at 4:28 AM Maris Nartiss  wrote:
>>
>>> 2021-07-27 18:26 GMT+03:00, Vaclav Petras :
>>> >
>>> > From what has the milestone 8.0 and is not mentioned below and is
>>> major, I
>>> > see only #1454 and #1501 which are related to band references. Maybe we
>>> > should again consider reverting the band references in order to get 8.0
>>> out
>>> > or how do you see the status of #1454 and #1501, Martin and Maris?
>>> >
>>> > https://github.com/OSGeo/grass/milestone/4
>>> > https://github.com/OSGeo/grass/pull/1454
>>> > https://github.com/OSGeo/grass/pull/1501
>>>
>>> For #1454 the main remaining (and unsolvable) issue is semantics of a
>>> mapset layout and its management functions. I just commited a more
>>> clean workaround and thus it should be ready for a merge. A proper
>>> solution will have to wait for GRASS 9 when we could reorganize mapset
>>> structure and thus also clean-up naming, handling functions etc.
>>>
>>
>> #1501 (Integrate band references into portable signature files) is close
>> to being merged.
>>
>
>this one was merged just after you posted this
>
>#1454 (TGIS DB v3 backward compatible with v2) has perhaps lower priority
>> since there is both upgrade and downgrade.
>>
>> As for issues linked to the milestone, please review what is there. See
>> what needs to stay there and what can be moved. For example, all issues
>> which are features and are not changing existing API can be moved to 8.2
>> milestone.
>>
>> https://github.com/OSGeo/grass/milestone/4
>>
>
> If no further objections I'd suggest to move forward with grass8 release
>branch creation

+1

Moritz
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [SoC] GSoC 2021 - Parallelization of raster modules for GRASS GIS

[Moritz Lennert]

Hi Aaron,

I haven't had the chance to test all this, yet, but it's great work ! One 
suggestion:

Le 9 août 2021 14:44:43 GMT+02:00, Aaron Saw Min Sern  a 
écrit :
>Hi everyone,
>
>Week 9 has concluded and here's my report for this week.
>
>1) What did I get done this week?
>
>r.univar 
>[https://github.com/OSGeo/grass/pull/1634]
>
>  *   Refactor previous implementation
>
>r.series 
>[https://github.com/OSGeo/grass/pull/1776]
>
>  *   Implement parallelization
>
>Implementation for r.patch is yet to be completed.
>
>2) What do I plan on doing next week?
>
>  *   Finish implementing r.patch parallelization
>  *   Write documentation on manual pages for each of the modules that have 
> been implemented
>Specifically, a section titled "Performance" to include user parameters for 
>parallel processing and expected behavior and issues.
> *   r.univar
> *   r.mfilter
> *   r.neighbors
> *   r.slope.aspect
> *   r.resamp.filter
> *   r.resamp.interp
> *   r.series
> *   r.patch
>  *   Include a wiki page on the general OpenMP implementation and the 
> benchmark results of each module
>
>Please let me know if there are any ideas for better documentation. Thanks!


I don't know what you plan on including in this wiki page, but if there is some 
sort of boiler plate code that could be used for parallelization of other 
modules, it would be great to have that somewhere, with detailed comments about 
each part does and what potential issues are.

Moritz
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] GRASS GIS 8: create new release branch

[Moritz Lennert]

Le 29 mai 2021 08:58:59 GMT+00:00, Markus Neteler  a écrit :

>If there are no objections I'd merge PR 1597 in the next days.

+1

I think at this stage it should just happen, especially if it's a throw-away 
branch.

Moritz
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] Enable Zenodo before 7.8.6 and 8.0.0

[Moritz Lennert]

Clear +1 from me. 

Moritz

Le 24 mai 2021 03:08:06 GMT+01:00, Vaclav Petras  a écrit 
:
>Hi all,
>
>Let's enable the Zenodo link before 7.8.6 and 8.0(.0?) releases to get DOIs
>and Zenodo records.
>
>Solving the whole DOI linking and Zenodo archiving for the old versions may
>be complex [1], but enabling the link between GitHub and Zenodo is trivial
>(one click) and every newly created GitHub release (we do those) will be
>automatically registered and receive DOI.
>
>Zenodo uses a system of DOI versions and a main DOI (Concept DOI). Whether
>it is an ideal system, that's a question, but it is currently the expected
>one since it is the same for everything on Zenodo. It is used automatically
>when using the GitHub-Zenodo integration.
>
>It seems I have the permissions to enable it for GRASS GIS. The one who
>enables that becomes a maintainer of it. I'm fine with that, but I won't be
>uploading any older versions. The maintainer can be changed later by
>contacting Zenodo support [2].
>
>Although there are things to figure out in terms of next steps, I don't see
>much risk in enabling it. There are no choices available in the setup or in
>terms of alternatives. DOI and some kind of registration are expected more
>and more.
>
>Thoughts?
>
>Vaclav
>
>[1] https://grasswiki.osgeo.org/wiki/GitHub-Zenodo_linkage
>[2] https://github.com/zenodo/zenodo/issues/826
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GSoC welcome

[Moritz Lennert]

Welcome and congratulations to all three of you !

I'm looking forward to your three exciting projects.

Moritz

On 18/05/21 05:12, Anna Petrášová wrote:

Hi GRASS devs and new (and old) GSoC students!

Congrats to Linda, Caitlin and Aaron for being selected to participate 
in GSoC this year [1], we hope this will be productive for all and a 
great learning experience for the students. During this community 
bonding period (until June 7th when the coding starts) students should 
work with mentors and the broader community to refine the project ideas, 
so that it's clear what to do and perhaps start working on the project 
itself.


I think it would be nice to have a call to introduce students and 
mentors, I will try to set up something soon. In the meantime, students 
should reach out to mentors to start discussing their respective 
projects. Let me know if you have any questions or concerns.


Best,
Anna

[1] 
https://summerofcode.withgoogle.com/organizations/5336634351943680/#projects 



___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev



___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] GRASS GIS 7.8.6

[Moritz Lennert]

On 6/05/21 10:29, Stefan Blumentrath wrote:

Hi,

I did a quick check with GRASS 7.8.5: 
https://gist.github.com/ninsbl/8051f51d372b565ca6f5a29b480d2463
~ 25 AddOn modules are affected for various reasons.
Most common issues are lack of manual pages...

For some it may be fixed on the addon site, but for modules with libraries, 
g.extention might have to be fixed (did not look at the details yet).


Problems that are caused by the addons themselves should obviously not 
be considered blockers of a release, so we should focus on the issues 
directly caused by g.extension.


IIUC, they all are caused because the addon is either a toolset with 
several modules, or there are library files in the directory or in 
subdirectories (e.g. i.segment.hierarchical and r.estimap.recreation). 
The relevant zip file does contain all necessary files for running the 
addon, so it is g.extension that is looking for info that it shouldn't 
look for.


Moritz



-Original Message-
From: grass-dev  On Behalf Of Moritz Lennert
Sent: torsdag 6. mai 2021 08:10
To: grass-dev@lists.osgeo.org; Markus Neteler ; GRASS developers 
list 
Subject: Re: [GRASS-dev] [release planning] GRASS GIS 7.8.6



Am 5. Mai 2021 23:03:04 MESZ schrieb Markus Neteler :

Hi devs,

On Mon, Apr 12, 2021 at 7:33 PM Markus Neteler  wrote:

On Sun, Mar 21, 2021 at 9:21 AM Markus Neteler  wrote:
...

What's still to be done for 7.8.6? See the 7.8.6 milestone, it is
showing the remaining open issues:
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fg
ithub.com%2FOSGeo%2Fgrass%2Fmilestone%2F6data=04%7C01%7C%7C335
d0aa4554c4afef30608d910558cf7%7C6cef373021314901831055b3abf02c73%7C
0%7C0%7C637558781906330143%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAw
MDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata
=zwJNFpzyVz5beaiy297ECcgzFBmaNRgU%2B7rENlhDWyU%3Dreserved=0
--> 78% complete


--> 84% complete


--> 100% as I have bumped the remaining six open PRs to the new milestone 7.8.7.


Open questions for anyone with Windows (Helli? Others?):
- Is g.extension failing for all add-ons or only for a few? A new
blocker or not?


We are stuck here. But I do not want to postpone the release forever.


I don't want to block the release, but in my experience g.extension not working 
correctly is something that leads to a very frustrating user experience on 
Windows, so would be great if this could be solved before.

Moritz
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.osgeo.org%2Fmailman%2Flistinfo%2Fgrass-devdata=04%7C01%7C%7C335d0aa4554c4afef30608d910558cf7%7C6cef373021314901831055b3abf02c73%7C0%7C0%7C637558781906340135%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=eiiNrrJ47kkJwKG%2BkQDNs1s9V0yfr9%2BFb5uT4pAWHIc%3Dreserved=0



___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [release planning] GRASS GIS 7.8.6

[Moritz Lennert]

Am 5. Mai 2021 23:03:04 MESZ schrieb Markus Neteler :
>Hi devs,
>
>On Mon, Apr 12, 2021 at 7:33 PM Markus Neteler  wrote:
>> On Sun, Mar 21, 2021 at 9:21 AM Markus Neteler  wrote:
>> ...
>> > What's still to be done for 7.8.6? See the 7.8.6 milestone, it is
>> > showing the remaining open issues:
>> > https://github.com/OSGeo/grass/milestone/6
>> > --> 78% complete
>>
>> --> 84% complete
>
>--> 100% as I have bumped the remaining six open PRs to the new milestone 
>7.8.7.
>
>> Open questions for anyone with Windows (Helli? Others?):
>> - Is g.extension failing for all add-ons or only for a few? A new
>> blocker or not?
>
>We are stuck here. But I do not want to postpone the release forever.

I don't want to block the release, but in my experience g.extension not working 
correctly is something that leads to a very frustrating user experience on 
Windows, so would be great if this could be solved before.

Moritz
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Add-ons not building since January

[Moritz Lennert]

On 16/03/21 14:45, Anna Petrášová wrote:



On Tue, Mar 16, 2021 at 8:55 AM Moritz Lennert 
mailto:mlenn...@club.worldonline.be>> wrote:


On 16/03/21 06:57, Luca Delucchi wrote:
 > On Tue, 16 Mar 2021 at 01:10, Veronica Andreo
mailto:veroand...@gmail.com>> wrote:
 >>
 >> Hi devs,
 >>
 >
 > Hi Vero,
 >
 >> I'm teaching a GRASS course and one of the students using
windows told me that he didn't have i.landsat.qa <http://i.landsat.qa>.
 >>
 >> Checking the log, the last building date seems to be January
26th [0]. i.landsat.qa <http://i.landsat.qa> was added a couple of
weeks later, hence not there.
 >>
 >> Is there a way to re trigger the building of add-ons for
windows? Or an alternative solution for windows users to install
add-ons?
 >>
 >
 > I'm not a windows user, so I could say something wrong, since it is a
 > python script could be enough to copy the python file into addons
 > folder and make it executable (on Unix it works)
 >

I think in MS Windows, this implies creating a .bat file which then
call
the .py script. Look at how the current version of the scripts in
i.landsat (or any other Python addons) are organized.

You can create the zip file yourself and make it available to the
students and they can point to the file directly with url=.

Spo yes, it is definitely possible, but it is always a bummer when you
have to use such an approach to install an extension when g.extension
should "just work". Just makes GRASS GIS less credible.

The recently added r.centroid is not available either. Maybe we can


It's completely missing for grass78, but for grass79dev it's there, but 
it had issues with compiling its manual, which is fixed now.


Yes, there seems to be a specific issue with the grass78 addons. This 
said: is there any special reason to differentiate between grass78 and 
grass79 addons for Python scripts ?


Vero, you could try if the student can install by pointing url to 
https://wingrass.fsv.cvut.cz/grass79/x86_64/addons/grass-7.9.dev/i.landsat.zip.


Moritz
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Add-ons not building since January

[Moritz Lennert]

On 16/03/21 06:57, Luca Delucchi wrote:

On Tue, 16 Mar 2021 at 01:10, Veronica Andreo  wrote:


Hi devs,



Hi Vero,


I'm teaching a GRASS course and one of the students using windows told me that 
he didn't have i.landsat.qa.

Checking the log, the last building date seems to be January 26th [0]. 
i.landsat.qa was added a couple of weeks later, hence not there.

Is there a way to re trigger the building of add-ons for windows? Or an 
alternative solution for windows users to install add-ons?



I'm not a windows user, so I could say something wrong, since it is a
python script could be enough to copy the python file into addons
folder and make it executable (on Unix it works)



I think in MS Windows, this implies creating a .bat file which then call 
the .py script. Look at how the current version of the scripts in 
i.landsat (or any other Python addons) are organized.


You can create the zip file yourself and make it available to the 
students and they can point to the file directly with url=.


Spo yes, it is definitely possible, but it is always a bummer when you 
have to use such an approach to install an extension when g.extension 
should "just work". Just makes GRASS GIS less credible.


The recently added r.centroid is not available either. Maybe we can 
think of some github-based testing of addon compilation for MS Windows ? 
Triggered whenever a module is modified on github ?


Moritz
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS-PSC] Min. req. of programming language standard support, GRASS GIS 8

[Moritz Lennert]

On 26/02/21 19:44, Veronica Andreo wrote:

Dear Nicklas,

Thanks much for such a clearly written RFC! I only made very minor 
cosmetic changes.


Are there any other comments, objections or suggestions? Or further 
aspects to be discussed?

If no, maybe we can vote on it soon-ish, no?


No objections on my side. The RFC is clear and the discussion has 
already taken place, so +1 for bringing this to a vote.


Moritz
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Need a mentor for GSoC parallelization topic

[Moritz Lennert]

Hi Huidae,

Am 18. Februar 2021 06:05:09 MEZ schrieb Huidae Cho :
>Thanks. I'm not familiar with the process. The deadline for mentoring
>organization applications is approaching. Have we already applied with all
>those project ideas in the wiki (one application per organization I guess,
>not per project idea)?

OSGeo is the organization applying. Once it is accepted we will know for how 
many slots and once the student application period is over, there will be an 
arbitration within OSGeo about the distribution of these slots among the OSGeo 
projects.

Moritz


>
>Best,
>Huidae
>
>On Wed, Feb 17, 2021 at 11:49 PM Anna Petrášová 
>wrote:
>
>>
>>
>> On Wed, Feb 17, 2021 at 11:51 AM Huidae Cho  wrote:
>>
>>> Anna,
>>>
>>> Thanks! I just updated the wiki and filled out the form. Will I receive
>>> further communications from OSGeo (e.g., rejected, accepted, how to
>>> proceed...)?
>>>
>>
>>  I believe they will inform us about the OSGeo application status on OSGeo
>> discuss and soc mailing lists. Here is the timeline:
>> https://developers.google.com/open-source/gsoc/timeline
>>
>> Best,
>> Anna
>>
>>>
>>> Regards,
>>> Huidae
>>>
>>> On Wed, Feb 17, 2021 at 11:29 AM Anna Petrášová 
>>> wrote:
>>>


 On Tue, Feb 16, 2021 at 2:37 PM Huidae Cho  wrote:

> Anna,
>
> It sounds like an interesting topic and I'm open to mentoring him even
> though I have limited experience with OpenMP. If anyone else has more
> experience with it and is interested in mentoring, that will be even 
> better.
>

 Thanks Huidae, I think you are more than qualified for being a mentor
 for this topic. Please put your name on the wiki page and fill out the
 form. If others would be interested in helping out (e.g. testing, reviews),
 that would be great, we need a co-mentor and ideally it wouldn't be me,
 since I may be a mentor elsewhere.

 Thanks again!
 Anna

>
> Best,
> Huidae
>
> On Tue, Feb 16, 2021 at 10:14 AM Anna Petrášová 
> wrote:
>
>> Hi devs,
>>
>> would you consider being a GSoC mentor for this topic [1]? I suggested
>> this topic in hope this could be impactful for GRASS and fairly 
>> accessible
>> for students with CS background.
>>
>> We need somebody with C experience, ideally also OpenMP experience. I
>> have only limited experience, and I would probably be mentoring a 
>> different
>> project, so I can't be the main mentor here.
>>
>> There is already a student who would be interested in that, so we need
>> to make sure there is somebody who can mentor him.
>>
>> This is all theoretical so far, OSGeo is not even accepted yet. If you
>> are interested, please also fill this form [2].
>>
>> Thank you for considering this,
>>
>> Anna
>>
>> [1]
>> https://trac.osgeo.org/grass/wiki/GSoC/2021#Parallelizationofexistingmodules
>> [2] https://forms.gle/9Na1vzGX3ESxqgpj9
>>
>
>
> --
> Huidae Cho, Ph.D., GISP, /hidɛ t͡ɕo/, 조희대, 曺喜大
> GRASS GIS Developer
> https://idea.isnew.info
>

>>>
>>> --
>>> Huidae Cho, Ph.D., GISP, /hidɛ t͡ɕo/, 조희대, 曺喜大
>>> GRASS GIS Developer
>>> https://idea.isnew.info
>>>
>>
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS-user] Code sprint is now (OGC-OSGeo-ASF 2021)

[Moritz Lennert]

Am 17. Februar 2021 17:40:03 MEZ schrieb Luca Delucchi :
>Hi all,
>
>On Wed, 17 Feb 2021 at 17:29, Vaclav Petras  wrote:
>>
>> Code sprint is now!
>>
>
>I'm trying to connect sometime, specially during Italian evening time
>
>>
>> Post you plan here:
>>
>> https://github.com/opengeospatial/joint-ogc-osgeo-asf-sprint-2021/issues/2
>>
>
>could make sense to start a v.in.ogc.features to import features from
>OGC API Feature service using owslib library?

+1

Moritz
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Min. req. of programming language standard support, GRASS GIS 8

[Moritz Lennert]

Am 11. Februar 2021 13:29:10 MEZ schrieb Nicklas Larsson :
> 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.


Great, thanks a lot !

Moritz

>
>[1] https://trac.osgeo.org/grass/wiki/RFC
>
>
>
> On Thursday, 11 February 2021, 12:54:30 CET, Moritz Lennert 
>  wrote:  
> 
> On 10/02/21 13:16, Nicklas Larsson wrote:
>> It would be most favourable for all contributors and the project if the 
>> community could come to an agreement on this topic. I see no reason to 
>> postpone a decision on this much longer.
>> 
>> The final word on this need to be that of the PSC's. Whether through 
>> simple vote or a RFC. However, a sounding of the opinion of the 
>> dev-community on this matter is of equal importance and can be of help 
>> for the PSC.
>
>Thanks a lot, Nicklas, for this very comprehensive summary !
>
>A suggestion made at the first meeting of the new PSC was to use this 
>discussion as a use case for a more extensive usage of RFC's to put 
>important decisions into more permanent documents than mailing list 
>archives and to provoke a formal decision as you suggest. Would you be 
>willing to write a first draft of such an RFC ?
>
>Moritz
>  
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Min. req. of programming language standard support, GRASS GIS 8

[Moritz Lennert]

On 10/02/21 13:16, Nicklas Larsson wrote:
It would be most favourable for all contributors and the project if the 
community could come to an agreement on this topic. I see no reason to 
postpone a decision on this much longer.


The final word on this need to be that of the PSC's. Whether through 
simple vote or a RFC. However, a sounding of the opinion of the 
dev-community on this matter is of equal importance and can be of help 
for the PSC.


Thanks a lot, Nicklas, for this very comprehensive summary !

A suggestion made at the first meeting of the new PSC was to use this 
discussion as a use case for a more extensive usage of RFC's to put 
important decisions into more permanent documents than mailing list 
archives and to provoke a formal decision as you suggest. Would you be 
willing to write a first draft of such an RFC ?


Moritz
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Elections results and new GRASS GIS PSC

[Moritz Lennert]

[Online version of this announcement: 
https://grass.osgeo.org/news/2021_02_05_new_grass_psc/ 
<https://grass.osgeo.org/news/2021_02_05_new_grass_psc/>]



 New GRASS GIS Project Steering Committee

By the end of last year, the GRASS GIS project called for PSC members 
election. A total of/13 GRASS GIS contributors/were nominated by the 
community to cover the nine PSC positions.


After the election itself, the new GRASS GIS PSC is composed of the 
following nine members ranked by number of votes:


 * Markus Neteler (95)
 * Anna Petrášová (88)
 * Helena Mitášová (86)
 * Martin Landa (83)
 * Verónica Andreo (76)
 * Moritz Lennert (74)
 * Václav Petráš (68)
 * Michael Barton (58)
 * Huidae Cho (56)

For completeness, all relevant candidacy communications, as well as 
details about the voting process, have been published 
at:https://trac.osgeo.org/grass/wiki/PSC/Election2020 
<https://trac.osgeo.org/grass/wiki/PSC/Election2020>


On behalf of the GRASS GIS project, we would like to thank/Hernán De 
Angelis/who agreed to serve as Chief Returning Officer (CRO) and all 
community members for their participation. Furthermore, we want to 
acknowledge the contributions of former PSC members and all nominees. 
The development of GRASS GIS is a collective effort and we are all part 
of it regardless of our role. So,*CONGRATS to everyone!*



 New PSC chair person

There’s yet one more change to report. GRASS GIS PSC has a new chair 
person:*Veronica Andreo* <https://veroandreo.gitlab.io/>. She works as a 
researcher in Argentina focusing on environmental drivers of 
vector-borne disease outbreaks and works primarily with satellite 
imagery and GIS-based time series analysis. For years, Vero has been 
very active in the GRASS GIS project, especially with documenting 
complex topics in a user friendly way, testing, development of the new 
website, coding of addons, outreach, social media and more. She 
regularly introduces GRASS GIS to new users and teaches introductory and 
advanced courses and workshops. We thank Vero for accepting this challenge!


We want to acknowledge and thank*Markus Neteler* 
<https://www.mundialis.de/neteler/>for his enormous efforts and 
passionate work on pushing the GRASS GIS development for more than 20 
years. While Markus was re-elected as PSC member, he preferred to pass 
on the position of chairperson to a new PSC member. Markus is one of the 
long runners in the project, as he already started to discover the 
software in 1993 as a student. In 1998, he set up a “European GRASS 
site” at the University of Hannover, which evolved into an international 
development team. From manual source code management, he was part of the 
journey to a modern, GitHub-based development system including code 
quality testing. Markus is known to be active in conferences, code 
sprints, bug fixing, user support, infrastructure management, project 
and release management, etc. He will continue to do so!



 PSC roles & tasks

In addition to the chair role, in the firstPSC 
<https://trac.osgeo.org/grass/wiki/PSC>meeting, we have defined some 
basic areas/tasks and PSC members responsible for them:


 * Treasurer - Moritz
 * Release manager - Markus, Martin
 * Infrastructure manager - Markus
 * Translation manager - Huidae
 * Website & Marketing manager - Michael, Vero
 * Github manager - Vaclav

Of course, *everyone is invited to join and contribute*in these and 
other areas:https://trac.osgeo.org/grass/wiki/PSC/Roles 
<https://trac.osgeo.org/grass/wiki/PSC/Roles>.


/The GRASS Development Team, Feb 2021/

___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Should we use GitHub Discussions?

[Moritz Lennert]

On 9/02/21 10:00, Markus Neteler wrote:

On Tue, Feb 9, 2021 at 5:40 AM Vaclav Petras  wrote:

On Tue, Feb 2, 2021 at 5:49 PM Luca Delucchi  wrote:


On Thu, 21 Jan 2021 at 08:49, massimo di stefano
 wrote:

‘’’
  I think emails (and mailing lists) are awesome, but mailing lists are 
increasingly seen as archaic and not accessible
‘’’

What about migrating our mailing list to mailman3?
The postorius interface looks modern and when integrated with hyper kitty, 
allows an easy access to the list archives (including search and post 
statistics).



I fully agree with this proposal, but this should be done at OSGeo
Level, Massimo do you want to investigate this solution with SAC?


Did anyone open a ticket for that? I didn't see it yet in case.


Or I can click on that one checkbox in GitHub settings. :-)


Not sure.
Please also note that QGIS is actually closing their GitHub
Discussions for reasons also having mentioned here.
See
https://lists.osgeo.org/pipermail/qgis-psc/2021-February/009244.html



I especially like this argument:
https://lists.osgeo.org/pipermail/qgis-psc/2021-February/009247.html

Moritz
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Min. req. of programming language standard support, GRASS GIS 8

[Moritz Lennert]

Am 7. Februar 2021 05:01:38 MEZ schrieb "Anna Petrášová" 
:
>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 Friday, 29 January 2021, 18:50:34 CET, Anna Petrášová <
>>> kratocha...@gmail.com> wrote:
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Thu, Jan 28, 2021 at 4:28 AM Nicklas Larsson via grass-dev <
>>> grass-dev@lists.osgeo.org> wrote:
>>> > Dear Devs!
>>> >
>>> > As a relatively new member of the GRASS GIS dev community, I have had
>>> to search for information on mailing lists, old trac comments etc.
>>> regarding coding practice and in particular minimum programming language
>>> standard support. Ending up in not entirely conclusive understanding. Up
>>> until now, I have been mostly involved in Python development and I’m still
>>> not absolutely certain, although I assume 3.5 is minimum version. And I’m
>>> not alone, see e.g. [1].
>>> >
>>> > Now, I’ve encountered a similar dilemma with C standard support,
>>> attempting to address compiler warnings [2], in particular with the PR
>>> #1256 [3].
>>> >
>>> > I would be great if there were a (one) place where the min support of
>>> Python version, C (C89, C99, C11, C17…) and C++ (C++03, C++11, C++14 …)
>>> standard is stated -- loud and clear. Obviously, there has to be a
>>> consensus in the community on these matters for that to happen. Such a
>>> statement will also have to be revised now and then. (A related question is
>>> also whether or not to support 32 bit, which I know have been raised
>>> recently).
>>> >
>>> > I’d appreciate your opinion is on this issue!
>>> > Let me put up a a suggestion for min. req. for coming GRASS GIS 8 as a
>>> starting point of discussion:
>>> > - Python 3.7
>>> > - C11
>>> > - C++11
>>> >
>>> >
>>> > Best regards,
>>> > Nicklas
>>> >
>>>
>>> Regarding Python, not sure if we shouldn't set 3.6 as minimum for G8, it
>>> is still used e.g. in Ubuntu 18. Any reason to set 3.7 as minimum, some
>>> specific features we would want to use?
>>>
>>> Anna
>>>
>>> >
>>> >
>>> > [1] https://github.com/OSGeo/grass/issues/1241
>>> > [2] https://github.com/OSGeo/grass/issues/1247
>>> > [3] https://github.com/OSGeo/grass/pull/1256
>>> >
>>> > ___
>>> > grass-dev mailing list
>>> > grass-dev@lists.osgeo.org
>>> > https://lists.osgeo.org/mailman/listinfo/grass-dev
>>> >
>>> >
>>>
>>>
>>>
>>> Well, I don’t have a very strong opinion regarding 3.7, but personally
>>> I’d say 3.6 is an absolute minimum. I presume, for example, most of us
>>> would prefer to use f-strings for string formatting.
>>>
>>
>> yes, f-strings are nice although they have limitations for using with
>> translatable strings (Vashek can expand on that)
>>
>>>
>>>
>>> On the other hand, 3.6 will reach end-of-support at the end of this year
>>> right after its 5th birthday party and the support for data classes in 3.7
>>> may potentially offer intriguing applications in G8.
>>>
>>
>> I noticed the data classes as well. Given 3.6 is reaching end-of-support
>> soon, I agree with 3.7 for G8. I assume grass would be compatible with 3.6
>> for a while anyway.
>>
>>
>>> Ubuntu 18 has Python 3.6 and Debian 9 has Python 3.5! What will make the
>>> lowest common denominator? Debian 10 and Ubuntu 20 actually supports Python
>>> 3.7 and 3.8 respectively. Forgive me if I’m ignorant, but isn’t it possible
>>> to upgrade Python version on Ubuntu? Or is it just a pain with package
>>> dependencies? Relying on default Python has never/rarely been a luxury for
>>> other platforms.
>>>
>>> That being said, I think the most important part of this is that the
>>> community make a clear decision on min. supported Python version.
>>>
>>
>This GDAL's RFC [1] is helpful in summarizing the issue with Python.
>Looking more into this, I suggest to go have a longer term strategy for
>dropping support for Python versions, which would be relatively simple.
>Basically we would keep the lowest Python version that wouldn't reach end
>of life at the time of a major release of GRASS. E.g. when we release G8
>this year, 3.6 will be minimum maintained version. Since 3.6 ends Dec 2021,
>we could drop 3.6 support next year. I am not saying we need to be strict
>about that, but might be helpful as a guidance, and it is independent on
>distributions (which is probably both advantage and disadvantage). I am
>unsure how this decision impacts packaging of grass, i.e. once we set 3.7
>as minimum, would maintainers need to make that Python a dependency of
>GRASS? Anyway, to summarize, I am for Python 3.6 at this point, but we need
>to reevaluate that with each new major GRASS version. I think this is
>conservative enough and perhaps more in line with the C standards
>discussion.
>

+1

Moritz
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Support GRASS GIS financially !

[Moritz Lennert]

Dear all,

We just received our very first sponsorship contribution of 2021 (thank 
you !) and we want to take this occasion to thank all those who sponsored us 
last year and remind you that the GRASS 
GIS project needs financial support in order to:

- organize very valuable face-to-face meetings and sprints gathering 
developers and the wider community for a few days to concentrate on 
improving GRASS GIS

- fund specific fixes or enhancements (this year the use of 
micro-budgets for such fixes is planned)

- maintain our website

- produce marketing material to spread the word

You can see the list of past individual and corporate sponsors here:

https://grasswiki.osgeo.org/wiki/Sponsors

As you can see, no amount is too small: if all GRASS GIS users give just 
a small amount regularly, we will already have a sizeable budget to work 
with ! And I challenge you to find software that does all that GRASS GIS 
does for 5€/$ or 10 €/$ a year ;-)

So, just go to https://grass.osgeo.org/contribute/sponsoring/ and help 
us make GRASS GIS better.

If you want to see more details about how we use the money, note that 
the project budgets are public. For 2021 see 
https://grasswiki.osgeo.org/wiki/GRASS_GIS_Budget_2021.

The GRASS GIS Project Steering Committee
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Min. req. of programming language standard support, GRASS GIS 8

[Moritz Lennert]

Am 31. Januar 2021 22:15:53 MEZ schrieb Markus Metz 
:
>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  wrote:
>> >>
>> >> Markus,
>> >>
>> >> I think we have to think about what benefits it would bring to us by
>> >modernizing C code. Probably, not much at all. Personally, I would keep
>it
>> >as is because the minimum set of anything (e.g., ANSI C with no new
>> >features) would probably be more portable, I believe. In other words,
>what
>> >are we missing from C99?
>> >
>> >as I mentioned, there is no need to modernize the GRASS C code. The
>> >question is if we officially allow C99 features.
>> >
>> >For example a number of useful math-related functions and macros are only
>> >available with C99. See /usr/include/math.h on your system and search for
>> >C99. Also a number of features related to data types, particularly for
>> >various int datatypes (stdint.h), become available with C99. And the
>> >geographic lib in PROJ with src/geodesic.c wants C99. For new PROJ
>> >versions, C99 is a requirement.
>>
>>
>> If proj requires it, doesn't it automatically become a requirement for
>GRASS as well ?
>
>No, because the code base of other libs might have completely different
>compile requirements. A software can use functions and libs of other
>software packages, but does not need to follow the compile standards of
>those other software packages, because they are compiled independently.
>

Thanks for the clarification.

In light of that I agree that we should choose the oldest standard possible, 
unless we _really_ need something only present in a more recent version.

@those who want to use more recent standards: what are your reasons for that ?

Moritz
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Min. req. of programming language standard support, GRASS GIS 8

[Moritz Lennert]

Am 29. Januar 2021 20:54:06 GMT+00:00 schrieb Markus Metz 
:
>Hi Huidae,
>
>On Thu, Jan 28, 2021 at 6:30 PM Huidae Cho  wrote:
>>
>> Markus,
>>
>> I think we have to think about what benefits it would bring to us by
>modernizing C code. Probably, not much at all. Personally, I would keep it
>as is because the minimum set of anything (e.g., ANSI C with no new
>features) would probably be more portable, I believe. In other words, what
>are we missing from C99?
>
>as I mentioned, there is no need to modernize the GRASS C code. The
>question is if we officially allow C99 features.
>
>For example a number of useful math-related functions and macros are only
>available with C99. See /usr/include/math.h on your system and search for
>C99. Also a number of features related to data types, particularly for
>various int datatypes (stdint.h), become available with C99. And the
>geographic lib in PROJ with src/geodesic.c wants C99. For new PROJ
>versions, C99 is a requirement.


If proj requires it, doesn't it automatically become a requirement for GRASS as 
well ?

Moritz
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS Elections 2020] Voting phase closed, presentation of results

[Moritz Lennert]

Dear all !

Thank you very much for the honor of being part of the new PSC !

Looking forward to working with everyone, whether elected or not, on bringing 
this great project forward.

Special kudos to Hernán for the great job !

Moritz

Am 25. Januar 2021 12:30:46 GMT+00:00 schrieb "Chief Return Officer (CRO) - 
GRASS GIS election 2020" :
>Dear members of the GRASS GIS community,
>
>The voting phase of the GRASS GIS Election 2020 is now finished. Out of 
>245 registered voters, 98 completed the survey. The results are shown 
>below and are now available in the Trac Wiki.
>
>
>Voting result (ranking, name, number of votes):
>
>  1. Markus Neteler 95
>  2. Anna Petrášová 88
>  3. Helena Mitasova  86
>  4. Martin Landa   83
>  5. Verónica Andreo76
>  6. Moritz Lennert 74
>  7. Vaclav Petras  68
>  8. Michael Barton 58
>  9. Huidae Cho 56
>10. Helmut Kudrnovsky   55
>11. Peter Löwe  52
>12. Māris Nartišs   47
>13. Stefan Blumentrath  44
>
>
>
>The new PSC is then composed of the following 9 members:
>
>  1. Markus Neteler 95
>  2. Anna Petrášová 88
>  3. Helena Mitasova      86
>  4. Martin Landa   83
>  5. Verónica Andreo76
>  6. Moritz Lennert 74
>  7. Vaclav Petras  68
>  8. Michael Barton 58
>  9. Huidae Cho 56
>
>
>
>Regards,
>
>
>Hernán
>
>Chief Return Officer (CRO)
>
>
>
>
>
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Should we use GitHub Discussions?

[Moritz Lennert]

I hear your arguments, Vaclav, and understand that new generations have other 
approaches to communication on the net, and use other tools. I have been 
confronted with students to whom I suggested to ask their questions on a 
mailing list only to realize a bit later that they had no idea what a mailing 
list was, but were a bit afraid to ask. SoI agree that if relevant we need to 
adapt.

I personally am in the same logic as Zoltan: I like way how mailing lists allow 
to passively receive the info. But I understand the barrier that signing up to 
a mailing list can represent.

So, the issue here is not so much about specific tools (why not push Twitter, 
Instagram, etc as tools - I know people who search twitter whenever they have 
question). My issue is about dispersal of communication. On my side it is 
probably more related to communication between devs where I witness an 
increased difficulty of following important discussions because they happen in 
github PRs and I find it difficult to sort through all github mails and 
identify the important ones.

Your concern is more with new users and possibly new devs, but probably those 
coming from a bit further away. So these are probably different questions and 
should be discussed separately, but the issue of dispersal of forces needs to 
be discussed even in the context of user support.

I would be curious to get an idea of the numbers and proportions linked to the 
problem you describe: How much potential interest do we really loose because of 
the absence of a forum ? Of those, how many actually have a github account ? I 
feel the discussion to be a bit in the dark.

For the issue you raise, given the discussion since, the ideal would probably a 
solution in the form of a forum that allows you to also receive and contribute 
message by sending mails. This would satisfy both worlds.

For the issue I raised, it is probably more a discussion of how to identify and 
focus important discussions into one channel, and less about the tools.

Moritz

Am 21. Januar 2021 04:31:43 MEZ schrieb Vaclav Petras :
>Let me finally write some arguments for GitHub Discussions.
>
>First of all, I think it is a tradeoff, so I agree that the issues here are
>valid, at least to a point. My question now is if it is worth enabling
>GitHub Discussions anyway.
>
>As I mentioned earlier, people are asking for a web-based solution (see
>e.g. post from November on grass-user [1]). I think emails (and mailing
>lists) are awesome, but mailing lists are increasingly seen as archaic and
>not accessible. Nabble does not seem to cut it and it was even demoted on
>the mailing list for its link instability (which I think is a concern). It
>seems that if the Nabble situation would be fixable, it would be fixed
>already. Signup to receive all emails for a specific mailing list before
>posting a question is a big commitment, especially when people are using
>multiple software packages or are just trying out GRASS GIS. Is it clear to
>everybody they need to sign up before posting anyway? When you are already
>committed to GRASS GIS, they might not show stoppers, but when you are not,
>they certainly can be. Conclusion: If we want even the uncommitted users to
>ask questions, we need something which feels light, you already have an
>account there, and it does not require you to manage email filtering.
>
>There are already web-based forums, namely GIS StackExchange and
>StackOverflow proper where GRASS-related questions are being asked. This
>demonstrates the interest in the web-based Q platform, however when you
>look at the posts there, you see that it does not work that great. First,
>many of the original posts and consequently answers are actually not a good
>fit for that kind of platform - often a back and forth discussion is
>required. And perhaps more importantly, there are only a few GRASS power
>users answering there compared to mailing lists and comparing to how many
>people from the GRASS community have an account on GitHub. Conclusion: Even
>if we don't direct users to a platform and support that platform, people
>will use it anyway resulting in harm as questions are not properly answered.
>
>GitHub Discussions is a good web-based forum for three reasons, 1) GitHub
>is a platform we are already committed to, 2) devs, core+addon
>contributors, and bug-reporting users all have an account there, 3) a lot
>of potential users already have account there. The last point is especially
>interesting because not only that a lot of code-aware GIS users or
>scientists have an account there, but a lot of developers have an account
>there and we are very very interested in attracting developers.
>Developers/programmers need to combine multiple projects to create whatever
>they are creating. Asking them to subscribe to a mailing list in order to
>ask a question is exactly the reason why they will try their luck with
>another project. Conclusion: To attract more users, especially those who
>are 

Re: [GRASS-dev] Should we use GitHub Discussions?

[Moritz Lennert]

Am 17. Januar 2021 06:31:22 MEZ schrieb Vaclav Petras :
>Dear all,
>
>What about enabling GitHub Discussions [1] on grass repo? Enabling is easy
>[2], so the question really is, do we want them? They are for open ended
>discussions, questions, etc. Right, like mailing list, but on GitHub. We do
>get asked periodically for a web-based (as opposed to email-based) forum
>which is what GitHub Discussions can fulfill. I'm not saying we should
>abandon the mailing list, but GitHub Discussions may be easier for some
>users, so it would open another avenue for people to ask or get engaged on
>a platform we are already using anyway.

I have never used GitHub discussions, so I have no opinion as such on its 
usefulness for us.

I do have a more fundamental issue, however: ever since we've moved to GitHub, 
discussions about important feature decisions seem to me to be more and more 
dispersed across PRs and less centrally visible. Currently, there are 
discussions about starting GRASS GIS by default without a terminal window [1], 
how to handle GUI startup when the last used mapset is not available, whether 
GRASS GIS can be considered as an "app" and if yes, whether this should be 
reflected in the name of the startup script [3], and probably others I forgot 
or that I am not aware of.

All of these are interesting discussions with solid points made, but I have the 
feeling that they are really confidential, involving only a very limited number 
of developers because others do not think that they the PR as such is relevant 
to them, and so they miss the fact that there are discussions going on that 
will have an impact on how GRASS GIS runs and/or is perceived.

If we create yet another forum I'm afraid that things will get even worse.

Maybe this is just a sign that our community is growing so rapidly and activity 
has increased so much that no one can follow every important discussion, but I 
do think this is also linked to the multiplication of tools used. Maybe it's 
also due to my bad personal organization if the information flows.

I would be happy to hear other opinions about this (and possibly some best 
practices on how others handle this problem). Depending on the answers to this, 
I think we might have to have a fundamental discussion on development decision 
making that ensures a somewhat larger group, while not stifling the enthousiasm 
behind the different initiatives and proposals.

Moritz

[1] https://github.com/OSGeo/grass/pull/1221

[2] https://github.com/OSGeo/grass/issues/1251

[3] https://github.com/OSGeo/grass/pull/1208
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] minor tweak to new website

[Moritz Lennert]

Am 15. Januar 2021 17:35:43 MEZ schrieb Michael Barton :
>On the new download pages, I just noticed that the dev versions are referenced 
>like this:
>
>GRASS GIS 7.9 devel (unstable)
>
>This implies that GRASS 7.9 is risky and perhaps minimally useable. The 
>reality is that it works very well but has some new features that might be 
>buggy or might change. While we want to indicate these differences from the 
>current stable version, we don’t want to discourage people from trying it (and 
>reporting any issues).
>
>I suggest that we reference it as
>
>GRASS GIS 7.9 devel (development)

+1

Moritz
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Statement Moritz Lennert

[Moritz Lennert]

Dear all,

I thank those who nominated me for putting my name up once again. Most 
of you will have seen me around as I'm one of the old ones, active in 
the GRASS GIS community for over 20 years now.


In the past I've have worked on many different parts of GRASS: 
documentation, the first attempts of a native MS Windows port, a series 
of modules, with, in the last years, a specific focus on remote sensing 
and particularly the entire tool chain for object-based image assessment.


I have been in the GRASS PSC since 2012, and have been active as GSoc 
mentor, "volunteered" as financial / bank manager of the project, 
contributor of presentations at different FOSS4G conferences, 
participated in several sprints, etc Having spent over 20 years in 
academia, I have also taught with GRASS GIS at university for quite a 
long time. I'm also one of the co-founders of the Belgian chapter of the 
OSGeo foundation and co-organiser of the Belgian foss4g.be conferences.


Recently, I have left university, however, and am now employed by a 
private company, https://bluesquarehub.com, that develops technologies 
for the health sector in developing countries. I was hired to develop 
the geospatial data aspect of their work (they do use GRASS GIS in a 
model of health facility accessibility we developed for them when I was 
still at university). As this is still quite new I don't know, yet, how 
much time I will have for actively contributing to GRASS GIS, nor for 
even just following all of the exiting continuous developments and 
discussions on the lists and in github. If elected, my presence will 
probably be more subdued, but I do promise to actively play the role of 
"old wise guy" and upholder of some of the historical traditions and 
values of GRASS GIS development.


At the same time, I would be more than happy to see new faces in the PSC 
and to leave my place to them if the community so desires. I promise 
that I will continue to hang around whatever the results of the 
elections and to manage our bank account and paypal money pool :-).


I'm proud to be part of such a wonderfully friendly and innovative 
community !


All the best,
Moritz
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2895: Define dependencies for GRASS addons

[Moritz Lennert]

Am 18. Dezember 2020 09:57:53 MEZ schrieb GRASS GIS :
>#2895: Define dependencies for GRASS addons
>--+-
>  Reporter:  pmav99   |  Owner:  grass-dev@…
>  Type:  enhancement  | Status:  new
>  Priority:  normal   |  Milestone:  7.8.3
> Component:  Default  |Version:  unspecified
>Resolution:   |   Keywords:  g.extension
>   CPU:  Unspecified  |   Platform:  Unspecified
>--+-
>
>Comment (by sbl):
>
> Replying to [comment:20 wenzeslaus]:
> > > Silently installing stuff can be a bit scary...
> >
> > Why do you think it is scary for GRASS GIS? pip, R, conda, apt, yum, ...
> all install dependencies of a package you asked for. Why this should not
> happen for GRASS GIS?

I would personally plead for the automatic installation of dependencies only as 
optional. I always prefer to install dependencies via my distribution's package 
manager instead of automatic installation via tools such as conda, pip or 
others. And I don't think it realistic to take into account all different 
package management systems within GRASS GIS.

So, +1 to a dependency check accompanied by the option to install the missing 
dependencies, but not automatic installation per se.

 




>
> Yes, you are right.
>
> So, how would we setup a requirements.txt?
>
> Should it contain different sections, like e.g.
> {{{
> GRASS_addons
> r.area
>
> R_packages
> ggplot2
>
> Python_libraries
> rpy2>=1.1
>
> cmd_tools
> iconv
> cs2cs
>
> libraries
> libgdal-grass
> }}}
>
> Cause the way these dependencies are installed varies a bit, with a
> dpendency_check function for each of them...
>
> Maybe better with a dependency json:
>
> {{{
> {
> "GRASS_addons": [
> {
>   "name": "r.area"
> }],
> "Python_libraries": [
> {
>   "name": "rpy2",
>   "version": "1.1"
>   "version_check": ">="
> }], ...
> }
> }}}
>
>
> In the functions we might have to think about OS specific aspects (package
> manager (incl. conda vs. pip), library names) as well as maybe versions
> (e.g. numpy>=1.17).
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Call for candidates for Chief Return Officer(s) to oversee election of new Project Steering Committee

[Moritz Lennert]

Dear all,

Many thanks to Hernán De Angelis who has agreed to serve as CRO !

We will put things in place with him to launch the entire process as soon as 
possible.

Moritz

Am 10. Dezember 2020 09:14:55 MEZ schrieb Moritz Lennert 
:
>Dear all,
>
>As part of the effort to guarantee a solid and sustainable governance of 
>GRASS GIS development, and in accordance with OSGeo guidelines, we have 
>a Project Steering Committee (PSC) [1]. Although most decisions are 
>taken by consensus via the mailing lists or via discussions in github 
>issues, some decisions go through this committee: annual budget, 
>admission of new developers into the core development team, and some 
>fundamental decisions (recent example: phasing out of a 32-bit version 
>for MS Windows).
>
>The last election for this committee was in 2016 and at the time we 
>decided that the PSC should be renewed approximately every 3 years. We 
>are already beyond this time frame and so a new election should happen, 
>soon. The general outline of the procedure has been drafted [2].
>
>The first step in that procedure is the nomination of one (or several) 
>Chief Return Officer(s) (CRO) who will oversee the election process and 
>who should not be a member of the current PSC, nor aim at becoming a 
>member of the new PSC.
>
>Is anyone willing to play this role ? You can just respond directly here 
>on the list to display your interest.
>
>In a second step, we will be looking for candidates for the new PSC. For 
>an overview of the (fairly low-noise) activity of the PSC, you can 
>browse through the archives of its public mailing list [3]. You will see 
>that it is not a job that requires a lot of work, but it is an essential 
>job nevertheless. Also: no need to be a developer to be part of the PSC, 
>users should also be represented.
>
>On behalf of the current PSC,
>Moritz
>
>[1] https://trac.osgeo.org/grass/wiki/PSC 
><https://trac.osgeo.org/grass/wiki/PSC>
>
>[2] https://trac.osgeo.org/grass/wiki/PSC/Election2020
>
>[3] https://lists.osgeo.org/pipermail/grass-psc/
>___
>grass-dev mailing list
>grass-dev@lists.osgeo.org
>https://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Call for candidates for Chief Return Officer(s) to oversee election of new Project Steering Committee

[Moritz Lennert]

Dear all,

As part of the effort to guarantee a solid and sustainable governance of 
GRASS GIS development, and in accordance with OSGeo guidelines, we have 
a Project Steering Committee (PSC) [1]. Although most decisions are 
taken by consensus via the mailing lists or via discussions in github 
issues, some decisions go through this committee: annual budget, 
admission of new developers into the core development team, and some 
fundamental decisions (recent example: phasing out of a 32-bit version 
for MS Windows).


The last election for this committee was in 2016 and at the time we 
decided that the PSC should be renewed approximately every 3 years. We 
are already beyond this time frame and so a new election should happen, 
soon. The general outline of the procedure has been drafted [2].


The first step in that procedure is the nomination of one (or several) 
Chief Return Officer(s) (CRO) who will oversee the election process and 
who should not be a member of the current PSC, nor aim at becoming a 
member of the new PSC.


Is anyone willing to play this role ? You can just respond directly here 
on the list to display your interest.


In a second step, we will be looking for candidates for the new PSC. For 
an overview of the (fairly low-noise) activity of the PSC, you can 
browse through the archives of its public mailing list [3]. You will see 
that it is not a job that requires a lot of work, but it is an essential 
job nevertheless. Also: no need to be a developer to be part of the PSC, 
users should also be represented.


On behalf of the current PSC,
Moritz

[1] https://trac.osgeo.org/grass/wiki/PSC 



[2] https://trac.osgeo.org/grass/wiki/PSC/Election2020

[3] https://lists.osgeo.org/pipermail/grass-psc/
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Read-access to data in a different location with same SRS

[Moritz Lennert]

Am 19. November 2020 15:52:18 MEZ schrieb "Anna Petrášová" 
:
>Hi,
>
>On Thu, Nov 19, 2020 at 8:02 AM Moritz Lennert 
>wrote:
>
>> Hi,
>>
>> It was great seeing some of you last night via jitsi !
>>
>
>indeed!
>
>>
>> In the context of the discussion of "location" vs "project", several of us
>> pointed to the fact that we organize our data into locations by reference
>> system with mapsets as project directories. PERMANENT (and other mapsets)
>> can then be used for data that is common to many projects and can thus be
>> accessed read-only from their respective mapsets. This helps avoiding data
>> duplication across projects.
>>
>> In the perspective where each location is a project we this would somehow
>> get lost, as this concept invites duplication into each project.
>>
>
>Right, just wanted to perhaps clarify my use case. I typically work with
>high resolution data so my study areas tend to be fairly small. But they do
>have common CRS (e.g. all study areas are in NC). So for me it makes sense
>to create a new location (with the same CRS) for each project and then I
>use mapsets to better organize my analysis, so that I don't have too many
>maps in there. So the code duplication doesn't typically bother me, but I
>of course I see your point.
>
>>
>> However, Luca raised an interesting point in the chat which we didn't get
>> to discuss: it might be possible to define some mechanism to make data in
>> one location readable from another location as long as they are in the same
>> SRS. An easy and dirty way is obviously to just use symbolic links as Luca
>> seemed to suggest, but that means there is no control over the actual
>> correspondence of location definitions. Also I don't know how
>> cross-platform this would be.
>>
>
>We started to use it on HPC, where we have backed-up storage with PERMANENT
>location containing all the base data and only I have permissions to write
>there and then other users including me symlink this mapset to their
>locations in scratch spaces, so they can read from there and work on their
>stuff. This has been working really well.
>

Yes, this is a typical workflow several of us use regularly. But again, this is 
very easy in *nix environments, but I'm not sure how portable it is...

>>
>> But maybe we could take this idea and create a more sophisticated
>> mechanism, extending g.mapsets to allow creating a read-only access to
>> mapsets even outside the current location, as long as the reference systems
>> are identical (would just requiring the PROJ files to be identical be
>> enough ? Too restrictive ?).
>>
>> This would possibly allow to go further in the idea of organizing data by
>> projects instead of locations, while also keeping
>> the idea of avoiding data duplication (people could create base data
>> projects with data common to many projects).
>>
>> How does that sound ?
>>
>
>Certainly worth exploring, however this seems to be more advanced, so not
>sure how this would help in introducing new people to GRASS.

I'm trying to find a way to reconcile your ideas behind renaming locations 
projects, while at the same time allowing people to continue to work in a way 
that resembles the original idea behind locations.

Obviously, people could just continue to use projects the same way they use 
locations now if all we do is a simple renaming, but I have the feeling that if 
we really want to make step in a new direction, we should fo all the way and 
not just apply beautiful new gift wrap (which I'm afraid would actually cause 
more confusion in the long run). So my idea is to go all the way and make 
current locations into real autonomous projects, with mapsets relabeled as 
project subdirectories (or similar) thus putting the whole concept more in line 
with what you have been advocating for as a more user friendly approach.

But making data usage across projects possible would be a prerequisite IMHO in 
order to allow current usage to continue. And I think using g.mapsets (or 
whatever this would then be called) to add a subdirectory of another project to 
those available in the current project would not be such a daunting challenge 
to new users either.

But as I said yesterday,  I'm not personally in demand for such change, as I 
don't find the current location and mapset concept so difficult to convey, so I 
won't insist on continuing along these lines of thought . ;-)

Moritz
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Read-access to data in a different location with same SRS

[Moritz Lennert]

Hi,

It was great seeing some of you last night via jitsi !

In the context of the discussion of "location" vs "project", several of us 
pointed to the fact that we organize our data into locations by reference 
system with mapsets as project directories. PERMANENT (and other mapsets) can 
then be used for data that is common to many projects and can thus be accessed 
read-only from their respective mapsets. This helps avoiding data duplication 
across projects.

In the perspective where each location is a project we this would somehow get 
lost, as this concept invites duplication into each project.

However, Luca raised an interesting point in the chat which we didn't get to 
discuss: it might be possible to define some mechanism to make data in one 
location readable from another location as long as they are in the same SRS. An 
easy and dirty way is obviously to just use symbolic links as Luca seemed to 
suggest, but that means there is no control over the actual correspondence of 
location definitions. Also I don't know how cross-platform this would be.

But maybe we could take this idea and create a more sophisticated mechanism, 
extending g.mapsets to allow creating a read-only access to mapsets even 
outside the current location, as long as the reference systems are identical 
(would just requiring the PROJ files to be identical be enough ? Too 
restrictive ?).

This would possibly allow to go further in the idea of organizing data by 
projects instead of locations, while also keeping
the idea of avoiding data duplication (people could create base data projects 
with data common to many projects).

How does that sound ?

Moritz
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS-user] Fwd: [OSGeo-Discuss] Reminder: OSGeo Virtual Community Sprint 2020 (17-19 November 2020)

[Moritz Lennert]

Hi everyone,

As several of you know already I've left the university and started a 
new job (at https://bluesquarehub.com/ for those of you who are 
curious). Because of that I don't have as much time for GRASS GIS 
development currently. However, if there is a specific meetting planned 
during this sprint, please let me know. I might be able to join for a 
little moment.


Moritz

On 17/11/20 10:29, Markus Neteler wrote:

Starting today - please join - open to anyone, no programming
knowledge required!

- Main zoom channel for kick off, presentations, free discussion and
daily reports https://zoom.us/j/95817956179?pwd=VGROK0NVK2lTaDg4eHJkdW1IdWNlUT09
- GRASS GIS related channel: https://meet.jit.si/GRASS
- IRC chat during the event: #tosprint on Server: irc.freenode.net
(https://webchat.freenode.net/)


-- Forwarded message -
From: Victoria Rautenbach 
Date: Mon, Nov 16, 2020 at 2:25 PM
Subject: [OSGeo-Discuss] Reminder: OSGeo Virtual Community Sprint 2020
(17-19 November 2020)
To: osgeolist , 

Dear All

We would like to remind everyone of the OSGeo Virtual Community Sprint
2020 that will take place 17-19 November 2020.
Information about schedule and meetings have been added to the wiki:
https://wiki.osgeo.org/wiki/OSGeo_Virtual_Community_Sprint_2020

The sprint will be open every day from 8am UTC to midnight UTC, with a
couple of special sessions scheduled (meeting links available in the
wiki):

A short kick off meeting will start at 8am UTC every day in the main room
A welcome session is planned for Tue 17 Nov 1pm UTC in the main room
At the end of each day, a daily report session is planned around 10pm UTC


The code sprint is also open to anyone! If you are interested in
getting involved in any of the projects, join one of the daily
sessions to get started.

Any questions can be posted also to any of the available communication
channels, 
https://wiki.osgeo.org/wiki/OSGeo_Virtual_Community_Sprint_2020#Communication

Happy coding,
OSGeo Board
___
Discuss mailing list
disc...@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/discuss
___
grass-user mailing list
grass-u...@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user



___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Milestone management: 7.8.5 or 7.10 or 8.0.0?

[Moritz Lennert]

On 11/10/20 19:15, Martin Landa wrote:

Hi,

so 10. 10. 2020 v 18:21 odesílatel Markus Neteler  napsal:

let's split obvious milestone from to-be-decided milestone.


we need to decide about the next milestone: do we want

- 7.8.5, or


refers to releasebranch_7_8 branch. GRASS 7.8.4 has been released
recently. There will be very probably another point version release in
three months (January 2021).


- 7.10 , or
- 8.0.0


Yes, it was discussed some time ago. I remember that we were inclined
to 8.0 [1] (scenario 3). Major reasons:

* image collections (breaks TGIS backward compatibility)
* new startup (GSoC)



+1

Moritz

___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] what use are the mysites and point maps in the demolocation ?

[Moritz Lennert]

On 4/08/20 23:16, Markus Neteler wrote:

On Tue, Aug 4, 2020 at 3:24 PM Moritz Lennert
 wrote:

Hello,

In the context of the complete revamping of the GRASS GIS GUI startup,
the idea is to use the existing demolocation as a possible basis for a
direct entry into GRASS GIS without going through complicated location
setup (which will then be offered through the data catalog). In that
context, I was wondering whether the mysites and point maps in that
demolocation are used by anything. I cannot find any in the code.

Try the "silver searcher" (`ag`) :-) Fast and accurate:

ag --html mysites
db/db.execute/db.execute.html
38:db.execute sql="INSERT INTO mysites (id,name,east,north) values
(30,'Ala',1657340,5072301)"

lib/db/sqlp/sql.html
137:v.db.select mysites where="id LIKE 'P__'"
140:v.db.select mysites where="id LIKE 'P%'"



Just a simple grep found those ;-), but comparing those to the mysites 
file in the demolocation indicatates that these examples have no 
relation with the mysites map in the demolocation.



There is no id field in the mysites maps, and certainly no name, east 
nor north...


Moritz
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] what use are the mysites and point maps in the demolocation ?

[Moritz Lennert]

Hello,

In the context of the complete revamping of the GRASS GIS GUI startup, 
the idea is to use the existing demolocation as a possible basis for a 
direct entry into GRASS GIS without going through complicated location 
setup (which will then be offered through the data catalog). In that 
context, I was wondering whether the mysites and point maps in that 
demolocation are used by anything. I cannot find any in the code. Would 
there be any opposition to removing them and only leaving the country 
borders ?


Moritz

___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] packagers' guidance on inclusion of small dataset into the GRASS GIS installation

[Moritz Lennert]

On 3/08/20 17:44, Sebastiaan Couwenberg wrote:

On 8/3/20 4:59 PM, Moritz Lennert wrote:



On 3/08/20 16:37, Sebastiaan Couwenberg wrote:

On 8/3/20 4:16 PM, Moritz Lennert wrote:

I have a small question concerning the best way to include a very small
dataset into the distribution of GRASS GIS. We are currently working on
the revamping of the GRASS GIS GUI startup experience, and have the
currently proposed solution is that GRASS GIS could start up
automatically creating a grassdata database and a default lat-long
location which would contain just a simple NaturalEarth world country
boundaries dataset.

In some OS (e.g. MS Windows), such a demolocation is included in the
distribution, but in Debian it is deleted before installation (IIUC what
happens in the rules file at [1]).

IIRC, Debian does normally not allow data to be distributed with
binaries. One option would be to put the data directly into the Python
code creating this location. Would that be acceptable for Debian ? What
kind of solution would you recommend ?


If the database can be built from source as part of the build process
e.g. like proj.db in PROJ, it can be included in the package (assuming
its license is DFSG compatible).

Where is "this location"?

If it's usr/lib/grassXY/demolocation, that's problematic because it's
not writable by unprivileged users. A subdirectory of $XDG_DATA_HOME
(e.g. $HOME/.local/share/grass) would be more suitable.


Actually, the idea currently is that a new user without any grassdata
will just get a grassdata directory automagically created during startup
and the /usr/lib/grassXY/demolocation would simply be copied into that
new grassdata directory. GRASS GIS would then directly start up into
that location.

So, the idea would be that during build /usr/lib/grassXY/demolocation is
created.


I don't know why the demolocation was never included in the package,
looking at the repo history it has always been like that since way
before I got involved.

I've pushed a change to include the directory in the grass-core package:

  
https://salsa.debian.org/debian-gis-team/grass/-/commit/faa570fd3357b1267d237fc0ee9b3386ce83479d

That can be used as the source for the user writable copy.


Thanks !

Moritz
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] packagers' guidance on inclusion of small dataset into the GRASS GIS installation

[Moritz Lennert]

On 3/08/20 16:37, Sebastiaan Couwenberg wrote:

On 8/3/20 4:16 PM, Moritz Lennert wrote:

I have a small question concerning the best way to include a very small
dataset into the distribution of GRASS GIS. We are currently working on
the revamping of the GRASS GIS GUI startup experience, and have the
currently proposed solution is that GRASS GIS could start up
automatically creating a grassdata database and a default lat-long
location which would contain just a simple NaturalEarth world country
boundaries dataset.

In some OS (e.g. MS Windows), such a demolocation is included in the
distribution, but in Debian it is deleted before installation (IIUC what
happens in the rules file at [1]).

IIRC, Debian does normally not allow data to be distributed with
binaries. One option would be to put the data directly into the Python
code creating this location. Would that be acceptable for Debian ? What
kind of solution would you recommend ?


If the database can be built from source as part of the build process
e.g. like proj.db in PROJ, it can be included in the package (assuming
its license is DFSG compatible).

Where is "this location"?

If it's usr/lib/grassXY/demolocation, that's problematic because it's
not writable by unprivileged users. A subdirectory of $XDG_DATA_HOME
(e.g. $HOME/.local/share/grass) would be more suitable.


Actually, the idea currently is that a new user without any grassdata 
will just get a grassdata directory automagically created during startup 
and the /usr/lib/grassXY/demolocation would simply be copied into that 
new grassdata directory. GRASS GIS would then directly start up into 
that location.


So, the idea would be that during build /usr/lib/grassXY/demolocation is 
created.


Moritz
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] packagers' guidance on inclusion of small dataset into the GRASS GIS installation

[Moritz Lennert]

Hi Bas, Hi any other packages who might want to weigh in,

I have a small question concerning the best way to include a very small 
dataset into the distribution of GRASS GIS. We are currently working on 
the revamping of the GRASS GIS GUI startup experience, and have the 
currently proposed solution is that GRASS GIS could start up 
automatically creating a grassdata database and a default lat-long 
location which would contain just a simple NaturalEarth world country 
boundaries dataset.


In some OS (e.g. MS Windows), such a demolocation is included in the 
distribution, but in Debian it is deleted before installation (IIUC what 
happens in the rules file at [1]).


IIRC, Debian does normally not allow data to be distributed with 
binaries. One option would be to put the data directly into the Python 
code creating this location. Would that be acceptable for Debian ? What 
kind of solution would you recommend ?


Thanks for any hints you can give us !

Moritz



[1] 
https://salsa.debian.org/debian-gis-team/grass/-/blob/master/debian/rules#L199

___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Unable to install grass-core on debian 10 (buster)

[Moritz Lennert]

On 18/05/20 14:48, Moritz Lennert wrote:

On 18/05/20 14:26, aborruso wrote:

Hi,
I would like to run some grass processes via sh scripts.

After running "sudo apt-get install grass-core", I have:


"The following packages have unmet dependencies:
  grass-core : Depends: libgdal26 (>= 2.2.0) but it is not going to be
installed
   Depends: libnetcdf18 (>= 3.6.1) but it is not going to be
installed
   Depends: libpdal-base10 (>= 1.8.0) but it is not going 
to be

installed
   Recommends: gdal-bin but it is not going to be installed
E: Unable to correct problems, you have held broken packages."

If I run "sudo apt-get install  libgdal26 libnetcdf18 libpdal-base10", I
have:

"The following packages have unmet dependencies:
  libgdal26 : Depends: libhdf5-103-1 but it is not going to be installed
  libnetcdf18 : Depends: libhdf5-103-1 but it is not going to be 
installed
    Depends: libhdf5-hl-100 but it is not going to be 
installed

E: Unable to correct problems, you have held broken packages."

And finally if I run "sudo apt-get install  libhdf5-103-1 
libhdf5-hl-100" I

have:

"The following packages have unmet dependencies:
  libhdf5-103-1 : Breaks: libhdf5-103 but 1.10.4+repack-11 is to be 
installed
  libhdf5-hl-100 : Conflicts: libhdf5-103 (< 1.10.5) but 
1.10.4+repack-11 is

to be installed
E: Unable to correct problems, you have held broken packages."


Looking at this again, I'm wondering: In buster, grass-core depends 
libgdal20 (2.4.0+dfsg-1 et autres)  and on libhdf5-103 
(1.10.4+repack-10), so why is it trying to install libgdal26 and 
libhdf5-103-1 and 1.10.4+repack-11 ? Have you added some other 
repositories to your apt configuration ?


Moritz
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Unable to install grass-core on debian 10 (buster)

[Moritz Lennert]

On 18/05/20 14:26, aborruso wrote:

Hi,
I would like to run some grass processes via sh scripts.

After running "sudo apt-get install grass-core", I have:


"The following packages have unmet dependencies:
  grass-core : Depends: libgdal26 (>= 2.2.0) but it is not going to be
installed
   Depends: libnetcdf18 (>= 3.6.1) but it is not going to be
installed
   Depends: libpdal-base10 (>= 1.8.0) but it is not going to be
installed
   Recommends: gdal-bin but it is not going to be installed
E: Unable to correct problems, you have held broken packages."

If I run "sudo apt-get install  libgdal26 libnetcdf18 libpdal-base10", I
have:

"The following packages have unmet dependencies:
  libgdal26 : Depends: libhdf5-103-1 but it is not going to be installed
  libnetcdf18 : Depends: libhdf5-103-1 but it is not going to be installed
Depends: libhdf5-hl-100 but it is not going to be installed
E: Unable to correct problems, you have held broken packages."

And finally if I run "sudo apt-get install  libhdf5-103-1 libhdf5-hl-100" I
have:

"The following packages have unmet dependencies:
  libhdf5-103-1 : Breaks: libhdf5-103 but 1.10.4+repack-11 is to be installed
  libhdf5-hl-100 : Conflicts: libhdf5-103 (< 1.10.5) but 1.10.4+repack-11 is
to be installed
E: Unable to correct problems, you have held broken packages."

Do you have some tips to solve these?


Try running 'sudo apt install -f' to fix installation problems.

Moritz
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] New GUI startup discussion

[Moritz Lennert]

On 16/05/20 18:08, Vaclav Petras wrote:



On Sat, May 16, 2020 at 8:25 AM Moritz Lennert 
mailto:mlenn...@club.worldonline.be>> wrote:


On 15/05/20 03:54, Vaclav Petras wrote:
 >
 >
 > On Thu, May 14, 2020 at 9:29 PM Robert Lagacé
 > mailto:robert.lagace...@gmail.com>
<mailto:robert.lagace...@gmail.com
<mailto:robert.lagace...@gmail.com>>> wrote:
 >
 >     Le 20-05-14 à 16 h 51, Vaclav Petras a écrit :
 >>
 >>     * A demo location with some minimal data should be part of the
 >>     installation and copied to some default palace for the
first-time
 >>     user.
 >     I like very much this one. For specific case or region, we
can just
 >     ask the user to replace those minimal data with a specific
data set
 >     before starting.
 >
 >
 > Yes, but even now you can something better than that in 7.6 and
7.8. See
 > my previous response. GRASS GIS tries to guess where is your
grassdata
 > directory. It needs to be named that way ("grassdata") and it
needs to
 > be in your home directory or in your Documents directory. (It should
 > work regardless of locale at least on Linux and Windows. From the
 > comments in the code [1], it seems I didn't study macOS when I
 > implemented that, but I would expected that to work.) Let us know if
 > this works for you. (Does it behave this way and is it what you are
 > looking for?)

Any reason you only look for grassdata in lower case ? I might be old
fashioned, but personnally I generally follow the idea of lowercase =
file, uppercase = directory. Why not check for grassdata regardless of
case, i.e. also accepting GRASSDATA or Grassdata or GRASSData?


Sound good. Just open an issue to discuss the details.


https://github.com/OSGeo/grass/issues/644

Moritz
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] New GUI startup discussion

[Moritz Lennert]

On 15/05/20 03:54, Vaclav Petras wrote:



On Thu, May 14, 2020 at 9:29 PM Robert Lagacé 
mailto:robert.lagace...@gmail.com>> wrote:


Le 20-05-14 à 16 h 51, Vaclav Petras a écrit :


* A demo location with some minimal data should be part of the
installation and copied to some default palace for the first-time
user.

I like very much this one. For specific case or region, we can just
ask the user to replace those minimal data with a specific data set
before starting.


Yes, but even now you can something better than that in 7.6 and 7.8. See 
my previous response. GRASS GIS tries to guess where is your grassdata 
directory. It needs to be named that way ("grassdata") and it needs to 
be in your home directory or in your Documents directory. (It should 
work regardless of locale at least on Linux and Windows. From the 
comments in the code [1], it seems I didn't study macOS when I 
implemented that, but I would expected that to work.) Let us know if 
this works for you. (Does it behave this way and is it what you are 
looking for?)


Any reason you only look for grassdata in lower case ? I might be old 
fashioned, but personnally I generally follow the idea of lowercase = 
file, uppercase = directory. Why not check for grassdata regardless of 
case, i.e. also accepting GRASSDATA or Grassdata or GRASSData?


Moritz
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] best practices for subject lines of PR

[Moritz Lennert]

On 16/05/20 03:32, Vaclav Petras wrote:



On Fri, May 8, 2020 at 1:04 PM Stefan Blumentrath 
mailto:stefan.blumentr...@nina.no>> wrote:


Hi,

Yes, I would also be very interested in some guidance on this!



Here are guidelines I wrote for commit messages for Subversion. A lot of 
it should still apply for both commits and PRs.


https://trac.osgeo.org/grass/wiki/Submitting/General#Commitmessages


That is a useful general guide, but the recent discussion was concerning 
labelling commits specifically for making it easier to decide which ones 
should be part of release news. I don't know if these guidelines are 
enough for that, or whether we should decide on specific tags (either 
github tags or [XYZ] tags in the commit message. Maybe MarkusN can give 
us his opinion as he has the experience of extracting the info.


Moritz
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS-user] Calling all imagery (especially i.maxlik and i.smap) users

[Moritz Lennert]

On 6/05/20 08:33, Maris Nartiss wrote:

Hello lists (sorry for cross-posting),
as GRASS 8 starts to look less Duke Nukem Forever (a.k.a. never), it
is a chance to change some things in imagery part. Thus if you heavy
relay on imagery part of GRASS GIS, please find some time to give
small feedback.

GRASS 7.8.0 imagery groups gained functionality of fully qualified
maps and thus could be used from other mapsets, still some issues
popped up.

#1 Should there be subgroups at all?
There has been a call to completely eliminate subgroups [1] and stick
only with groups. If you are using subgroups, this is the right moment
to share your user story (and not hypothetical one!).


Subgroups used to be very useful when imagery came without 
georeferencing. One would import the data into XY, and georeference all 
bands contained in one group. In the projected location one could then 
define subgroups to do the actual work on them.


In other word, they were (are?) useful when you have different parts of 
your workflow where one part concerns all bands while other parts only a 
subset of these bands.


As most imagery comes georeferenced nowadays, this workflow is much less 
frequent nowadays and for most of my usage of subgroups today, it could 
be replaced without any problem by the use of groups.




#2 Should i.maxlik add its output to the group?
Current implementation of i.maxlik adds classification result to the
input group [2]. This prevents use of i.maxlik with imagery group from
other mapset. I would vote to remove such feature. If you have a use
case where such functionality is needed, speak now, or forever hold
your peace.


+1 to remove this functionality.



#3 Should signature files be handled similarly to raster colors?
i.cluster, i.gensig and i.gensigset write signature files to imagery
subrgoup. This is not possible if group is located in other mapset. My
proposal — handle signatures as raster colours — signatures are always
saved in current mapset. Thus signatures created for a group in other
mapset would be not visible in other mapsets.


I do think that mapset-specific groups make sense and that for me 
personally I see a lot of potential for chaos if I could have signature 
files in a mapset that pertain to groups in other mapsets. It is so easy 
to create a group that I'm not sure what the significant added value 
would be.


So, I'm more skeptical about this one, without having a clear-cut opinion.

Moritz
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] best practices for subject lines of PR

[Moritz Lennert]

Hi,

A few days ago, we had a discussion about good labelling of PRs/commits 
in order to make it easier to create News pages for new releases. I just 
opened PR #601 [1] which changes the API of the v.distance module. Is 
there a specific label I should put into the subject line of this PR to 
mark the API change ?


Similar question for PR #534 [2] in which I added new functionality to 
v.neighbor. I added [NEW FUNCTIONALITY] into the subject line in order 
to make it apparent, but in a certain way this is redundant with the 
'enhancement' tag.


So, could anyone provide some guidance concerning the best way to 
label/tab/entitle these PRs ?


Moritz






[1] https://github.com/OSGeo/grass/pull/601
[2] https://github.com/OSGeo/grass/pull/534
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Fwd: [mlennert/grass] Run failed: CI - master (6669a4d)

[Moritz Lennert]

Am I right in my interpretation that below build failures are not linked 
to my PR ? IIUC, the errors are in Python scripts and linked to the 
flake8 changes ?


Moritz


 Forwarded Message 
Subject:[mlennert/grass] Run failed: CI - master (6669a4d)
Date:   Fri, 08 May 2020 10:07:33 + (UTC)
From:   mlennert 
Reply-To:   mlennert/grass 
To: mlennert/grass 
CC: Ci activity 



Run failed for master (6669a4d)

Repository: mlennert/grass
Workflow: CI
Duration: 46 minutes and 13.0 seconds
Finished: 2020-05-08 10:07:17 UTC

View results 

Jobs:

  * ubuntu-16.04 tests
 failed (1 
annotation)

  * ubuntu-18.04 tests
 succeeded (0
annotations)
  * ubuntu-16.04 build
 failed (1 
annotation)

  * ubuntu-18.04 build
 succeeded (0
annotations)

—
You are receiving this because this workflow ran on your branch.
Manage your GitHub Actions notifications here 
.


___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Let's talk about releases - 7.8.3, 7.10, 8.0

[Moritz Lennert]

Am 6. Mai 2020 15:17:08 MESZ schrieb Vaclav Petras :
>On Thu, Apr 30, 2020 at 9:59 PM Vaclav Petras 
>wrote:
>
>> Dear users and devs,
>>
>> I though it would be a good idea to video meet next week and talk
>about
>> what would be the best way of releasing GRASS GIS in the future. As
>always,
>> both contributors and users are invited to share ideas and opinions.
>>
>> ...
>>
>> PS: If you are answering to this email, I cross posted it to both
>user and
>> dev mailing lists, so you may want to take care to reply to just one
>> mailing list.
>>
>
>Scenario 2 on the following page is my attempt to capture the main
>scenario
>we talked about during the call. Thanks to all who participated!
>
>https://trac.osgeo.org/grass/wiki/Release/Schedule


+1 on your scenario 2, with only one possible change: looking at the past, I'm 
not sure it is realistic to wait until March for the x.0.1 release. Probably 
January is more realistic. This would then mean May and September for x.0.2 and 
x.0.3.

Moritz
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] staging.grass.osgeo.org - uptodate for review?

[Moritz Lennert]

Hi,

Am 4. April 2020 20:56:12 MESZ schrieb Helmut Kudrnovsky :
>hi,
>
>is staging.grass.osgeo.org uptodate for a review?

We are in a state of constant review for the moment and any additional eyes and 
opinions are always useful.



>
>I saw a lot of PRs to the website, though I lost a bit the overview
>what has
>been merged etc ... ;-D

A lot is being merged quite quickly, so you can already comment on that.

Currently the landing pages for Learn and Contribute have not been filled, yet. 
Most other pages already have content, although some still in draft version.

Just browse through the issues and pull requests of the grass-website 
repository to see the current discussions.

Moritz

___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Website: MD formatting vs html

[Moritz Lennert]

Hi Nick,

Using below message just as an illustration to my question: 

IIUC, Hugo is mainly markdown. Markdown provides it's own syntax, e.g. for 
lists it uses *.

Many of the pages currently in the new website use Html syntax. Is there a 
specific reason to do so ? Might it be better to impose markdown ?

This might also solve issues such as 
https://github.com/OSGeo/grass-website/issues/45.

Moritz

Am 1. April 2020 12:37:44 MESZ schrieb Markus Neteler 
:
>@neteler commented on this pull request.
>
>
>
>> @@ -140,6 +140,21 @@ grey-color-light-bg mb-2">
> 
> 
> 
>+### GRASS flyers
>+
>+
>+ For a simple overview of GRASS GIS you can download one of
>the two GRASS GIS flyer 
>+
>+  
>+  OSGeo one sheet flyer href="https://github.com/OSGeo/osgeo/raw/master/marketing/print/one-page-info/eu/grass_gis_a4.pdf;
>class="inl btn btn-primary" target="_blank">Download PDF
>+  
>+  GRASS community threefold flyer href="https://trac.osgeo.org/grass/export/74509/grass-promo/grassflyer/flyer_2016/en/grass_flyer.pdf;
>class="inl btn btn-primary" target="_blank">Download PDF
>
>```suggestion
>GRASS community threefold flyer href="https://trac.osgeo.org/grass/export/74509/grass-promo/grassflyer/flyer_2016/en/grass_flyer.pdf;
>class="inl btn btn-primary" target="_blank">Download PDF
>```
>
>better use a link to
>https://github.com/OSGeo/grass-promo/tree/master/grassflyer ?
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] generic address to access the manuals of the current stable version ?

[Moritz Lennert]

Hi,

ISTR some discussion about this (but maybe I just dreamed it ;-)), but 
how difficult would it be to create some sort of symlink to be able to 
point


https://grass.osgeo.org/grass/
or
https://grass.osgeo.org/grass-stable/

to the current stable version, i.e. now

https://grass.osgeo.org/grass78/

?

This would allow to point to the currently stable version of the manual 
pages from websites without having to worry about updating those links 
at each new release.


Not sure if this is an issue for the core code or for the website.

Moritz
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Let's work on the new GRASS website!

[Moritz Lennert]

On 26/03/20 23:26, Helmut Kudrnovsky wrote:

Hi Vero,


Maybe you want to vote in the doodle. We have a tie between >sunday and

monday evening

Do you have the doodle link at hand? ;-D


https://doodle.com/poll/884epdzezy9zphpe
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Let's work on the new GRASS website!

[Moritz Lennert]

Hi Vero,

On 26/03/20 22:18, Veronica Andreo wrote:

Hi Helli,

Maybe you want to vote in the doodle. We have a tie between sunday and 
monday evening



There still seems to be a tie. As you are the one who took the 
initiative, I would propose that you play the role of tie breaker and 
just decide on the day, as everyone seems to be available on both.


Moritz
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] db.copy gives error

[Moritz Lennert]

Am 14. März 2020 23:38:58 MEZ schrieb Markus Metz 
:
>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 from_driver=sqlite
>> from_database=/media/grassdb/biodiv/PERMANENT/sqlite/sqlite.db
>> from_table=vegetation_lookup to_driver=sqlite
>> to_database=$GISDBASE/$LOCATION_NAME/$MAPSET/sqlite/sqlite.db
>> to_table=vegetation_lookup
>
>Looking at the code of db.copy, it is not possible that this ever
>worked,
>you need to replace the variables with their actual values.

Well, it should work if you run 

eval $(g.gisenv -s) before, no ?

Moritz

___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] any special reason why choice of raster compression method is done via environmental variable ?

[Moritz Lennert]

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 
mailto:mlenn...@club.worldonline.be>> 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> 
<mailto:mlenn...@club.worldonline.be 
<mailto:mlenn...@club.worldonline.be>>> 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
 > >  > version of GRASS was not usable in an older version of GRASS.
 > >  >
 > >  > Now, I agree that generally the solution is to tell people to 
use the

 > >  > latest and greatest, but this is not always possible / it is not
 > >  > necessarily highest on the list of priorities of people to see 
how they

 > >  > can install the latest version of GRASS within their particular
 > > environment.
 > >  >
 > >  > Obviously, those with the latest version of GRASS can simple 
recompress

 > >  > using ZLIB. However, compression method is defined as an environment
 > >  > variable. This is somewhat daunting to many MS Windows users out 
there.

 > >  > Is there any specific reason that lead to the choice of not using a
 > >  > parameter to allow the choice of compression method (possibly to
 > >  > override a default that is still defined by an environment 
variable) ?

 > >
 > > Such a parameter would need to be added to every module creating raster
 > > output.
 >
 > My request is more linked to use cases where one would like to share
 > data (e.g. with r.pack) with other GRASS GIS users who do not
 > necessarily have access to the same compression method, not necessarily
 > to changing the default compression method. I was just wondering whether
 > it might be easily possible to just implement r.compress method= as a
 > quick way to recompress a specific map with a chosen method, overriding
 > the default method. Currently, to do that, you have to change the
 > default method by changing the env variable, run r.compress, then change
 > the variable back to the value one wishes generally to use as default.

recompressing an existing raster map seems like a waste of time. Why not 
compress it in the first place with the appropriate method?


Because what you consider the appropriate method at the time creation of 
the data (and still the appropriate method for your actual work) might 
not be the appropriate method for sharing with someone using a different 
system.




Recompressing an existing map with a chosen method via r.compress 
method=XY means that a new raster map should not be compressed with the 
default method but another supported method. This would require a new 
function in lib/raster like Rast_open_new_compression_method() that 
overrides the default compression method. Of course this is possible, 
but it requires substantial changes to lib/raster.


Ok, I understand that this is complicated.



About the use cases:
People want to share a mapset: in this case all GRASS raster maps should 
be compressed with the most compatible compression method (ZLIB). 
Currently, this can be done with an env var. Alternatively, a new 
mechanism via g.gisenv could be established.


This would already make life easier for Windows users who (for the 
majority) are not used to env variables (and this is becoming more and 
more true of GNU/Linux users as well...).


Another option could be to set the default compression method per 
mapset, to be stored in in the mapset's VAR file, to be set with e.g. 
r.compress method=.


That would probably be a nice solution. One could then create an 
"Export" mapset which can then be easily shared.



 > Obviously, you can always just export as tiff and share that, but that
 > just feels less elegant. Anyway, this is probably somewhat of a luxury
 > problem :-)

This only a luxury problem if you don't need to care about processing 
speed and disk usage. The different compression methods by now available 
in GRASS allow for optimization for speed (LZ4) or for optimization for 
disk usage (BZIP2 for larger CELL maps). An easy (easier) way to set the 
compression method seems reasonable.


I didn't mean that compression is a luxury problem, but rather that 
since the option exists of just exporting the map as a tiff, readable by 
most systems (and you can chose a sharable tiff compression method at 
export time), all the above is probably a bit less of a necessity, and 
I'm just making noise ;-)


Moritz


___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] missing logs for Windows addons

[Moritz Lennert]

On 6/01/20 13:29, Martin Landa wrote:

Ahoj,

po 6. 1. 2020 v 9:42 odesílatel Anna Petrášová  napsal:

Thanks for looking into this! Unfortunately, there is now a different problem, 
in 7.8 and 7.9, it looks like all c modules are not compiled, that's also the 
case of r.futures.pga (which is a c module within r.futures):


ops, opraveno. Martin



I see that r.object.activelearning also fails with:

"ModuleNotFoundError: No module named 'scipy'"

Should this module be changed somehow to wrap the import in a way to 
only make it fail at runtime ? ISTR, there was a technique for that, or ?


Moritz
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Fwd: [OSGeo-Discuss] Improving usability of INSPIRE data in FOSS4G client applications

[Moritz Lennert]

As a heads up:


 Forwarded Message 
Subject: 	[OSGeo-Discuss] Improving usability of INSPIRE data in FOSS4G 
client applications

Date:   Thu, 12 Dec 2019 17:09:13 +0100
From:   Marco Minghini 
To: disc...@lists.osgeo.org
CC: marco.mingh...@ec.europa.eu



Dear all,
at the European Commission - Joint Research Centre (JRC) we have been 
working with our Contractors (WeTransform and Epsilon Italia) on a set 
of actions aimed at improving the usability of INSPIRE data sets. For 
those who are not familiar with INSPIRE [1], this is the European 
Spatial Data Infrastructure (SDI) built on top EU Member States 
infrastructures to support European environmental policies.


The rationale behind these actions is that GML is the default encoding 
for INSPIRE data because INSPIRE xml schemas are generated automatically 
from the conceptual UML models. These schemas are complex and many 
existing (web, desktop and mobile) client applications are not able to 
fully consume or make use of data shared according to these schemas.


Two actions have been completed over the last year in order to:
1) improve client support for INSPIRE data
2) develop an alternative encoding for INSPIRE data (GeoJSON)

Within the first Action [2], we compiled a "can I use" matrix [3] 
describing which functionality associated with the consumption of 
INSPIRE data (both in GML and GeoJSON) is supported by which client. The 
clients tested are QGIS, GRASS GIS, hale studio, OpenLayers and 
LeafletJS as well as some proprietary solutions.


This e-mail is first of all to inform you about this Action and to show 
that, as you can notice in [3], open source solutions are currently the 
most successful ones, but some improvement is still possible. In this 
regard, we have established communication with the software PSC and/or 
communities and discussed the prioritisation of functionalities that 
should be improved or developed for each software to best satisfy user 
needs.


Whenever other encodings (e.g. GeoPackage) for INSPIRE data will become 
available, the same approach should be followed.


In addition, since the Action is formally completed but the outcomes 
will still be very important for the INSPIRE community in the future, we 
are currently exploring how to ensure the sustainability of the tool. In 
particular, we would open an invitation to anyone (project developers, 
users or communities, or simply interested people) to contribute to keep 
the matrix up-to-date by testing new/future versions of specific OSGeo 
tools (in particular those mentioned above - QGIS, GRASS GIS, OpenLayers 
and LeafletJS - but also other tools). The tests, described at [4], 
consist of general GIS tasks and do not require INSPIRE-specific 
knowledge. Interested people can also submit content through issues or 
pull requests in the GitHub repository [5] or contact us.


Thank you all for your attention.
Best regards,
Alex and Marco


[1] https://inspire.ec.europa.eu
[2] 
https://webgate.ec.europa.eu/fpfis/wikis/pages/viewpage.action?pageId=418580131

[3] https://inspire-mif.github.io/caniuse/generator/out.html
[4] https://github.com/INSPIRE-MIF/caniuse/tree/master/docs
[5] https://github.com/INSPIRE-MIF/caniuse
___
Discuss mailing list
disc...@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/discuss___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] any special reason why choice of raster compression method is done via environmental variable ?

[Moritz Lennert]

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 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
 > version of GRASS was not usable in an older version of GRASS.
 >
 > Now, I agree that generally the solution is to tell people to use the
 > latest and greatest, but this is not always possible / it is not
 > necessarily highest on the list of priorities of people to see how they
 > can install the latest version of GRASS within their particular 
environment.

 >
 > Obviously, those with the latest version of GRASS can simple recompress
 > using ZLIB. However, compression method is defined as an environment
 > variable. This is somewhat daunting to many MS Windows users out there.
 > Is there any specific reason that lead to the choice of not using a
 > parameter to allow the choice of compression method (possibly to
 > override a default that is still defined by an environment variable) ?

Such a parameter would need to be added to every module creating raster 
output.


My request is more linked to use cases where one would like to share 
data (e.g. with r.pack) with other GRASS GIS users who do not 
necessarily have access to the same compression method, not necessarily 
to changing the default compression method. I was just wondering whether 
it might be easily possible to just implement r.compress method= as a 
quick way to recompress a specific map with a chosen method, overriding 
the default method. Currently, to do that, you have to change the 
default method by changing the env variable, run r.compress, then change 
the variable back to the value one wishes generally to use as default.


Obviously, you can always just export as tiff and share that, but that 
just feels less elegant. Anyway, this is probably somewhat of a luxury 
problem :-)


Moritz
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] any special reason why choice of raster compression method is done via environmental variable ?

[Moritz Lennert]

Le Thu, 5 Dec 2019 08:30:43 +0200,
Maris Nartiss  a écrit :

> What should be the solution? Moving to choice set by g.gisenv?

As mentioned in my mail, I suggest to add a parameter to the module
which allows to override the default setting when compressing a
specific raster map.

Using a GRASS environment variable instead of a shell variable might be
an idea to make setting the default easier.

Moritz


> 
> trešd., 2019. g. 4. dec., plkst. 11:28 — lietotājs Moritz Lennert
> () rakstīja:
> >
> > 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
> > version of GRASS was not usable in an older version of GRASS.
> >
> > Now, I agree that generally the solution is to tell people to use
> > the latest and greatest, but this is not always possible / it is not
> > necessarily highest on the list of priorities of people to see how
> > they can install the latest version of GRASS within their
> > particular environment.
> >
> > Obviously, those with the latest version of GRASS can simple
> > recompress using ZLIB. However, compression method is defined as an
> > environment variable. This is somewhat daunting to many MS Windows
> > users out there. Is there any specific reason that lead to the
> > choice of not using a parameter to allow the choice of compression
> > method (possibly to override a default that is still defined by an
> > environment variable) ?
> >
> > Moritz
> >
> >
> > ___
> > grass-dev mailing list
> > grass-dev@lists.osgeo.org
> > https://lists.osgeo.org/mailman/listinfo/grass-dev  



-- 
Département Géosciences, Environnement et Société Université Libre de
Bruxelles Bureau: S.DB.6.138
CP 130/03
Av. F.D. Roosevelt 50
1050 Bruxelles
Belgique

tél. + 32 2 650.68.12 / 68.11 (secr.)
fax  + 32 2 650.68.30 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] any special reason why choice of raster compression method is done via environmental variable ?

[Moritz Lennert]

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 
version of GRASS was not usable in an older version of GRASS.


Now, I agree that generally the solution is to tell people to use the 
latest and greatest, but this is not always possible / it is not 
necessarily highest on the list of priorities of people to see how they 
can install the latest version of GRASS within their particular environment.


Obviously, those with the latest version of GRASS can simple recompress 
using ZLIB. However, compression method is defined as an environment 
variable. This is somewhat daunting to many MS Windows users out there. 
Is there any specific reason that lead to the choice of not using a 
parameter to allow the choice of compression method (possibly to 
override a default that is still defined by an environment variable) ?


Moritz


___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Fwd: [Belgium] Fwd: [Dutch] CfP Geospatial Devroom at FOSDEM 2020

[Moritz Lennert]

GRASS GIS contributions would be very welcome.

I don't know, yet, if I will be in Brussels at the time. If yes, I can 
try to propose something.


Moritz


 Forwarded Message 
Subject:[Belgium] Fwd: [Dutch] CfP Geospatial Devroom at FOSDEM 2020
Date:   Mon, 28 Oct 2019 08:57:21 +0100
From:   Johan Van de Wauw 
To: “belg...@lists.osgeo.org” 




Dear list,


FOSDEM is a free and non-commercial event bringing together about 8000 
developers in Brussels, Belgium. The next edition will take place on 1 & 
2 February 2020 and provide open source software developers, endusers 
and communities a place to share minds, tech and beer. Participation is 
free of charge, although donations are welcome.



Sunday 2 Feb 2019 from 9.00-17.00, the Geospatial Devroom offers – for 
the 6th consecutive time - a podium for everything open geospatial 
technology and information related.


Geospatial technologies and mapping used to be specialists work, but 
nowadays location intelligence is becoming part of many 
industries/products/projects/applications, which often use only a small 
subset of the possibilities the data and software have to offer.


The Geospatial Devroom is the right place to talk about open geospatial 
topics related to data, software and community. This includes standards, 
usage and tools, e.g. for (temporal-)spatial databases, and online 
mapping, temporal-spatial analysis, geospatial services, used for 
collection, storage, processing, delivery, analysis, and visualizing 
purposes.



We welcome submissions (projects, demo's, use cases, code wizardry, etc) :

 1. Web and desktop GIS applications;
 2. Interoperable geospatial web services and specifications;
 3. Collection of data using sensors / UAVs / satellites;
 4. Geo-analytic algorithms & libraries;
 5. Spatial extensions for classical databases (indexes, operations) and
dedicated databases;
 6. Big Geospatial Data processing, distributed and scalable in the Cloud;
 7. Geospatial intelligence for Smart Cities, IoT and Automotive;
 8. Volunteered & Crowdsourced data examples with e.g. OpenStreetMap
 9.  or something geospatial we did not think of !

HOW TO SUBMIT YOUR PROPOSAL FOR A TALK


Are you thrilled to present your work to other open source developers? 
Would you like to run a discussion? Any other ideas? Please submit your 
proposal at: https://penta.fosdem.org/submission/FOSDEM20 




Make sure to select the 'Geospatial devroom' as 'Track'. If you have an 
account from previous years, you should be using the same. Please 
specify in the notes if you prefer for your presentation either a short 
timeslot (lightning talks ~10 minutes) or a long timeslot (20 minutes 
presentation + discussion). However, note that time slots are indicative 
and will be assigned according to the timing of the session.



The DEADLINE for submissions is Sunday, 1st December 2019, 23.59 PM. 
Notification of acceptance will be sent to the Authors by 8/12/2017 at 
the latest.


Should you have any questions, please do not hesitate to get in touch 
with the organisers of the devroom via marcvloemans1  gmail  com.


Want to know what geospatial at FOSDEM is like? Check out the videos and 
the presentations of our previous editions via:


  * https://archive.fosdem.org/2017/schedule/track/geospatial/


  * https://archive.fosdem.org/2018/schedule/track/geospatial/


  * https://archive.fosdem.org/2019/schedule/track/geospatial/




Hope to see you then and there,


Marc Vloemans

LinkedIn: http://nl.linkedin.com/in/marcvloemans
Twitter: http://twitter.com/marcvloemans


___
Belgium mailing list
belg...@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/belgium
___
grass-dev mailing list
grass-dev@lists.osgeo.org

Re: [GRASS-dev] grass76 addons are taken from trac, but updates to addons happen on github

[Moritz Lennert]

On 31/10/19 11:58, Markus Neteler wrote:

Hi,

On Thu, Oct 31, 2019 at 11:08 AM Martin Landa  wrote:


Hi,

čt 31. 10. 2019 v 11:02 odesílatel Moritz Lennert
 napsal:

I would assume that there are still quite a lot of GRASS 7.6.0
installations out there (it was released less than a year ago). Would it


What about adding an Apache redirect rule for the addon downloads?


we definitely need to release 7.6.2 (not sure if all g.extension fixes
have been backported). Ma


diff -ru grass78_git/scripts/g.extension grass76_git/scripts/g.extension
--> no differences


But there is a difference between the 7.6.1 tag and 76_releasebranch.

Moritz
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] grass76 addons are taken from trac, but updates to addons happen on github

[Moritz Lennert]

On 31/10/19 11:08, Martin Landa wrote:

Hi,

čt 31. 10. 2019 v 11:02 odesílatel Moritz Lennert
 napsal:

I would assume that there are still quite a lot of GRASS 7.6.0
installations out there (it was released less than a year ago). Would it


we definitely need to release 7.6.2 (not sure if all g.extension fixes
have been backported). Ma


I agree that a release of 7.6.2 is part of the solution, but people will 
not switch immediately to that new version. Some way of ensuring that 
any 7.6.x will get the latest and greatest in addons would be good if 
feasible without too much work (some automatic github -> svn updates ?).


Moritz
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] grass76 addons are taken from trac, but updates to addons happen on github

[Moritz Lennert]

Hi,

After some intense doubts about my sanity, I noticed that I fell into a 
simple trap: I had fixed a bug in the i.segment.uspo addon quite a while 
ago, but the same bug kept on popping up, even though I have reinstalled 
the addon.


Finally, I remembered that on the university's HPC it is still version 
7.6.0 that is running, and that version gets its addons still from trac.


I would assume that there are still quite a lot of GRASS 7.6.0 
installations out there (it was released less than a year ago). Would it 
somehow be envisageable to automatically update the svn addon repository 
on trac with the updates in github ? I have no idea what this would mean 
in terms of work, but if it is a simple thing to do, it might be good to 
have in the transition period before we can assume that no 7.6.0 
installations are out there.


Moritz
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] i.fusion.hpf addon: observing strong range change

[Moritz Lennert]

On 29/10/19 19:11, Veronica Andreo wrote:
On the other hand, i.pansharpen does include a re-scaling step, but 
whatever bit depth is passed as input it will be re-scaled to 8-bit. If 
the input data is >8-bit, it is a bit of a loss of radiometric 
resolution (if the resulting values can be used for indices estimation)...


IIRC, this rescaling is due to the histogram matching step. This should 
probably be rewritten to allow arbitrary radiometric resolution.


Moritz
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] i.fusion.hpf addon: observing strong range change

[Moritz Lennert]

On 28/10/19 12:33, Markus Neteler wrote:

On Mon, Oct 28, 2019 at 10:46 AM Moritz Lennert
 wrote:

On 27/10/19 18:52, Markus Neteler wrote:

Hi,

I am using i.fusion.hpf on Worldview-2 data and see that the resulting
range is completely different:

# orig
r.info -r wv2_17OCT08182034_M2AS_058891334010_01_P001.5
min=0
max=1509

# HPF
r.info -r wv2_17OCT08182034_M2AS_058891334010_01_P001.5.hpf
min=-1045.79783524995
max=3416.06793724612


Just guessing here, but did you try the -c flag ?


Now yes:

i.fusion.hpf pan=$PAN msx=$(g.list raster pattern="$COLORPREFIX.?"
sep=comma) -c --o

# band 8
r.info -r wv2_17OCT08182034_M2AS_058891334010_01_P001.8
min=0
max=1605

r.info -r wv2_17OCT08182034_M2AS_058891334010_01_P001.8.hpf
min=-1163.98434592277
max=3879.99538075697

So, -c doesn't seem to have any effect here.



Sorry, wrong flag, should have been -l ("Linearly match histogram of 
Pan-sharpened output to Multi-Spectral input")


And if you rescale the output manually to the input value range, do you 
still see a good fusion result ? If yes, then this could be added as a 
last step to the module.


Moritz
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] i.fusion.hpf addon: observing strong range change

[Moritz Lennert]

On 27/10/19 18:52, Markus Neteler wrote:

Hi,

I am using i.fusion.hpf on Worldview-2 data and see that the resulting
range is completely different:

# orig
r.info -r wv2_17OCT08182034_M2AS_058891334010_01_P001.5
min=0
max=1509

# HPF
r.info -r wv2_17OCT08182034_M2AS_058891334010_01_P001.5.hpf
min=-1045.79783524995
max=3416.06793724612


Just guessing here, but did you try the -c flag ?

Moritz
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GRASS 7.8.1 ?

[Moritz Lennert]

On 14/10/19 20:51, Helmut Kudrnovsky wrote:

hi,

as winGRASS is on the way to come back, see [1]. locally here is already
winGRASS 7.8.0 running for testing.


This is great news !



there are already a few reported issues for python3 and git related to
winGRASS etc, e.g.

https://trac.osgeo.org/grass/ticket/3882
https://trac.osgeo.org/grass/ticket/3871
https://trac.osgeo.org/grass/ticket/3880
https://trac.osgeo.org/grass/ticket/3873

more will come with more testing

there have been some python 3 fixes in the last time, e.g.

[GRASS-git] [OSGeo/grass] b5b00f: wxGUI: fix deprecated wx.NewId
[GRASS-git] [OSGeo/grass] 623258: wxGUI/animation: fix deprecation warnings
(https:/...

cause of ticket/3882 winGRASS 7.8 isn't really usable for vector editing
cause of ticket/3880 winGRASS 7.8 won't be working with precombiled binary
addons

* is there any plan for a GRASS 7.8.1 ?
* what is the backport status from master to releasebranch_7_8



And what's the status of addons for Windows. I have a lot of colleagues 
suffering from their apparent absence.


Moritz
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Python scripts: trigger cleanup function at keyboard interrupt (CTRL-C)

[Moritz Lennert]

On 14/10/19 16:44, Anna Petrášová wrote:

This is used in many scripts and should work:
https://grasswiki.osgeo.org/wiki/GRASS_Python_Scripting_Library#Sophisticated_cleanup_procedure


Not sure this works on a Ctrl-C. ISTR it doesn't, but this would have to 
be verified.


Moritz



On Mon, Oct 14, 2019 at 10:00 AM Markus Neteler > wrote:


Hi,

in the GRASS GIS 6 shell scripts we used this code to clean up temp
files upon CTRL-C signal:

cleanup()
{
    g.message -v "Cleaning up ..."
    cd "$MSET_DIR"
    rm -rf "$TMP_DIR"
}
 trap ctrl-c so that we can clean up tmp
trap 'cleanup' 2 3 15

If there anything similar we could add to the python scripts?

thanks
Markus
___
grass-dev mailing list
grass-dev@lists.osgeo.org 
https://lists.osgeo.org/mailman/listinfo/grass-dev


___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev




___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] issue with the compilation of several addons: ImportError: No module named lib.gis

[Moritz Lennert]

Hi,

Several addon modules are currently not compiled (imagery/i.cutlines, 
imagery/i.fusion.hpf, imagery/i.image.bathymetry, raster/r.cell.area, 
raster/r.gradient, raster/r.series.filter, etc). All show the same error 
message: "ImportError: No module named lib.gis".


Any ideas where this comes from ?

Moritz
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] FOSS4G2019: State of GRASS GIS kind of presentation

[Moritz Lennert]

On 12/08/19 16:52, Markus Neteler wrote:

Hi,

I am starting to prepare our talk

"State of GRASS GIS Project: 35 years is nothing!"
https://talks.2019.foss4g.org/bucharest/talk/W3LWDV/

and would like to collect your ideas for that.

Of course
- Python 3 support
- SVN to git migration
- ...

The "floor" here is open for your suggestions!


Is the 2018 presentation available somewhere ? Just to get an idea what 
was already presented then ?


Some ideas:

- the work that has been done on all the remote sensing related modules 
(Sentinel, OBIA, etc).
- r.buildvrt (plus maybe some other efforts for "Big Data" / parallel 
computing)

- PROJ v.5/6 integration
- v.overlay and v.select (already in 7.4 IIRC) speedups and improvements
- ZSTD compression
- segment library all-in-memory cache
- Docker images

...

Moritz



___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GRASS GIS at FOSS4G

[Moritz Lennert]

On 23/07/19 15:17, Martin Landa wrote:

Hi Moritz,

po 15. 7. 2019 v 14:12 odesílatel Martin Landa  napsal:


- Have you all booked housing already ? If not, should we try to find
   some place (e.g. appartment) which could also be a place to work
   together, or should we ask whether a room might be available at the
   FOSS4G premises ?


we could join with Ondrej. Are you still available from such option?
What about others? Vero?



Sorry, I decided to really stay away from my mail during my vacation.

As there didn't seem much response to the idea at the time, I actually 
booked something on my own...


Moritz
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] dealing with null values in rasters only within mask

[Moritz Lennert]

Hi Markus,

On 28/06/19 22:08, Markus Metz wrote:

Hi Moritz,

On Fri, Jun 28, 2019 at 11:56 AM Moritz Lennert 
mailto: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 there is *|1 in the output you have NULL cells in the tile...

the fastest way to get the total number of cells and the number of 
non-NULL cells, ignoring any MASK, is r.info <http://r.info> -s, e.g.

cells=4917486    <-- total number of cells
n=4873149 <-- number of non-NULL cells

these numbers are stored in metadata and independent of the current region


But so this does not help in my problem which is to determine the number 
of NULL pixels within a given MASK.



 > > For filling NULLs with a given value you could do:
 > > r.mapcalc 
expression=tile_filled=if(MASK,if(isnull(tile),1,tile),null())


in this case, I recommend to create a custom mask that is not named MASK 
but e.g. mymask, and the r.mapcalc expression probably needs some 
modification regarding NULL values in mymask:
r.mapcalc expression="tile_filled = if(isnull(mymask) != 0 and mymask != 
0, if(isnull(tile), 1, tile), null())"


The reason is that if(MASK, ...) should return NULL if MASK is NULL 
which is not what you want, you want " if MASK is not NULL"


Right, thanks for the hint !

Moritz

___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] dealing with null values in rasters only within mask

[Moritz Lennert]

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 there is *|1 in the output you have NULL cells in the tile...


Nice trick, didn't actually know about the -N flag...



For filling NULLs with a given value you could do:
r.mapcalc expression=tile_filled=if(MASK,if(isnull(tile),1,tile),null())


Duh, now that I see this, it seems quite obvious.

Thanks Stefan !

(And thanks Ken for your ideas)

Moritz

___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] dealing with null values in rasters only within mask

[Moritz Lennert]

Hi to all,

As a followup of some recent discussions concerning the handling of null 
values, I have a fundamental issue, and would like some feedback:


I am working with irregular tiles of orthoimages. Each tile corresponds 
to the part of a large image mosaic that comes from a particular take.


Some of these tiles contain pixels with null values (generally due to 
sensor saturation).


I would like to be able to do the following:

- detect whether there are any null values in the tile

- replace the pixels values with a given value (or possibly use 
something like r.fill.stats)


For this, I am confronted to some issues:

- r.univar does not make a difference between null values in the data 
and those that are due to a mask 
(https://trac.osgeo.org/grass/ticket/3696). This means that if I create 
a mask to correspond to the irregular tile, I cannot use r.univar to 
detect whether there are any null values within the actual image tile.


- If I decide to just replace all null values with a given value, r.null 
also does not take into account the mask. IOW, it will fill all null 
pixels in the entire region outside the mask with that value.


- The same happens if I use r.mapcalc to replace null values with a 
given value.


Is there any way to solve this issues with existing tools, or would this 
demand a change in the code, in order to differentiate null values that 
are null because of a mask from other null values ? Any reflections on 
this ?


Moritz
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Port Dempster-Shafer module from grass6 to grass7

[Moritz Lennert]

Hi,

Colleagues of mine would be interested in the dst addon family of 
modules that currently exists for GRASS 6, but would need it for GRASS 
7. Does anyone have ann idea how difficult it would be to port them to 
GRASS7 ?


Moritz
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] error in v.overlay: Unable to write spatial index. Wrong node position

[Moritz Lennert]

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:

 >
 > 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 messages and see 
following

 >         details:
 >         Module run None ['v.overlay', 'binput=temp_30311', 
'operator=and',

 >         'olayer=0,1,0', 'ainput=sq_batiments',
 >         'output=walous_temp_batiment_tile_18980'] ended with error
 >         Process ended with non-zero return code 1. See errors in the 
(error)

 >         output.
 > **
 >
 > Any hint of what this might mean ? Should I file a bug report ?

That means there was an error while writing out a spatial index, the 
file size of the file holding the partially written out spatial index is 
smaller than expected. Is this error reproducible on a different 
partition/file system? Can you provide test data to reproduce?


This was running on one node in an HPC. Up to now I haven't been able to 
reproduce it, so it was probably some glitch on that node. If I have 
other occurences, I'll try to narrow it down and provide test data.



Moritz
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] error in v.overlay: Unable to write spatial index. Wrong node position

[Moritz Lennert]

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 messages and see following
   details:
   Module run None ['v.overlay', 'binput=temp_30311', 'operator=and',
   'olayer=0,1,0', 'ainput=sq_batiments',
   'output=walous_temp_batiment_tile_18980'] ended with error
   Process ended with non-zero return code 1. See errors in the (error)
   output.
**

Any hint of what this might mean ? Should I file a bug report ?

Moritz
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GRASS GIS at FOSS4G

[Moritz Lennert]

ping

On 5/06/19 22:21, Moritz Lennert wrote:

Hi everyone,

It seems that we have one workshop accepted on TGRASS, plus the general
"state of the project" presentation, plus several others where GRASS
GIS is used in different forms. Sounds like a nice programme !

I will be in Bucharest from Sunday, Aug 25 afternoon, until Saturday,
Aug 31, mid-day.

The TGRASS workshop is on August 27, 14:00 - 18:00.

I was wondering:

- Who else will be in town at the beginning of the
week ?
- Should we organise some form of small GRASS sprint on Monday and
   Tuesday ?
- Have you all booked housing already ? If not, should we try to find
   some place (e.g. appartment) which could also be a place to work
   together, or should we ask whether a room might be available at the
   FOSS4G premises ?

What do you think ?

Moritz
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev




___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] GRASS GIS at FOSS4G

[Moritz Lennert]

Hi everyone,

It seems that we have one workshop accepted on TGRASS, plus the general
"state of the project" presentation, plus several others where GRASS
GIS is used in different forms. Sounds like a nice programme !

I will be in Bucharest from Sunday, Aug 25 afternoon, until Saturday,
Aug 31, mid-day.

The TGRASS workshop is on August 27, 14:00 - 18:00.

I was wondering: 

- Who else will be in town at the beginning of the
week ? 
- Should we organise some form of small GRASS sprint on Monday and 
  Tuesday ?
- Have you all booked housing already ? If not, should we try to find
  some place (e.g. appartment) which could also be a place to work
  together, or should we ask whether a room might be available at the
  FOSS4G premises ?

What do you think ?

Moritz
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] svn/trac -> git/github migration plan

[Moritz Lennert]

On 12/05/19 18:19, Markus Neteler wrote:

On Fri, May 10, 2019 at 5:06 PM Martin Landa  wrote:


Hi,

út 7. 5. 2019 v 10:26 odesílatel Martin Landa  napsal:

commits can be referenced to github issues. Issue migration needs to
be also done on private repository. This would require to set up empty
private repo, migrate tickets and than transfer ticket using GitHub
API to public repo. This complicates procedure a bit. I would still
prefer to do source code and issues migration together even it will
take some time.


back to this topic, I added to trac an alternative scenario based on
two steps (source code and issues migration separated) [1]. Opinions
welcome. We are very close to day D.


Excellent.

IMHO the separate migration of source code and issues is the way to go.
Like that we can already work with the then completed migration next
weekend in Berlin and define workflows.



+1

I think we just need to get the ball rolling. There will certainly be 
some transition pain, but if we try to prepare everything to perfection 
it will never happen ;-)


Moritz
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] FYI: Season of the Docs

[Moritz Lennert]

On 9/05/19 10:08, Panagiotis Mavrogiorgos wrote:

Hello all,

This year google launched a new project similar to Summer of Code whose 
scope is improving documentation. The deadline has passed but it might 
make sense to keep it in mind for next year:


https://developers.google.com/season-of-docs/

There is an announcement mailing list, so it might be a good idea for 
some core member to subscribe: 
https://groups.google.com/forum/#!forum/season-of-docs-announce


Generally all GSoC or similar events are handled centrally via OSGeo 
with individual projects providing ideas.


This year, OSGeo has been accepted as organisation: 
https://wiki.osgeo.org/wiki/Season_Of_Docs_2019


For GSoC, see:
See https://wiki.osgeo.org/wiki/Google_Summer_of_Code_2019


Markus did transmit the info to the list:

https://lists.osgeo.org/pipermail/grass-dev/2019-April/091819.html


Moritz
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] v.to.db: next/prev line

[Moritz Lennert]

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 case. Also: what do you do in the 
case when three lines meet at a node. What would be the 'next_left_edge line' ?


right, these terms comes from TopoGeo model based described in ISO 13249-3:2006.

See eg.

http://freegis.fsv.cvut.cz/gwiki/PostGIS_Topology
https://trac.osgeo.org/postgis/attachment/ticket/3046/error_in_getRingedge.png


Right. That does make sens. I didn't think of left and right in that way.

I don't know what use cases are for this feature, compared to the ones I 
listed in my previous mail...


Moritz
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] v.to.db: next/prev line

[Moritz Lennert]

Hi Martin,

Am 8. Mai 2019 08:29:22 MESZ schrieb Martin Landa :
>Hi,
>
>I wonder whether there is a tool in GRASS which enables writing to
>attribute table information about next/previous lines. Basically info
>about next_right_edge/next_left_edge.
>
>My idea is to extend `v.to.db` option `sides` to work also for lines.
>
>v.to.db mysoils option=roads columns=left,right layer=2
>
>would write into `left` column next_left_edge line category, similarly
>for `right` column.
>
>Does it make sense to you or I am simply overlooking some existing
>tool in GRASS?



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 case. Also: what do you do in the 
case when three lines meet at a node. What would be the 'next_left_edge line' ?

I think this needs a little bit more thinking through...

I think a connectivity matrix between lines could be a possible alternative, as 
was recently discussed on the lists. Or possibly some form of association table 
node cats <-> line cats, knowing that will be n-to-n, so maybe best not to be 
directly integrated into the layers attribute table at least not the nodes' 
table. From the perspective of lines, one related lower hanging fruit I thought 
about was to extend v.to.db to include start_cat, stop_cat in addition to the 
current start/stop which provide the coordinates of nodes. This would then 
allow to easily identify lines that share common nodes.

Moritz
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Motion: Migrate SVN and trac tickets to github under OSGeo organization

[Moritz Lennert]

Am 25. April 2019 16:45:01 MESZ schrieb Martin Landa :
>Dear PSC,
>
>po 22. 4. 2019 v 17:27 odesílatel Markus Neteler 
>napsal:
>> Next steps of migration to Github:
>
>I will prepared detailed plan in the next days. Ma


Kudos to you, Martin, for all the work you are doing on this !

Moritz
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Addons manuals: logo and CSS file missing

[Moritz Lennert]

On 25/04/19 07:56, Markus Metz wrote:



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 includes.

zstd is not a required dependency, you can disable it with --with-zstd=no


This is the issue I raised with #3815. I don't think it is a good idea 
to use something as default if it is not a required dependency. As I 
described this can lead to the issue that without the user knowing it 
(e.g. using GRASS GIS that was compiled by someone (package manager, 
etc) with --with-zstd=yes) she creates raster maps that are compressed 
with zstd. If these maps are then moved to a machine that doesn't have 
zstd, the data is unusable.


That is why I proposed to make it a requirement. The other alternative, 
IMHO, would be to make ZLIB the default compression again and leave the 
use of ZSTD to power users.


Moritz


___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] which files are mandatory for raster maps

[Moritz Lennert]

On 16/04/19 18:10, Markus Neteler wrote:

Hi Moritz,

On Tue, Apr 16, 2019 at 2:56 PM Moritz Lennert
 wrote:


Hello,

I'm working with a large batch of raster maps (4550 * 4 bands) and
including all the auxiliary files this explodes my inode quota on our
university's HPC system.


Out of curiosity, which file system is that?



GPFS AFAIK.

But it is not an intrinsic limit to the system. It's them limiting 
individual access in order to be sure to be able to provide services to 
the potentionally thousands of users.





While waiting to see if they can increase this,
I was wondering which of the auxiliary files are absolutely mandatory.

Can I just erase colr/* and hist/* for example ?


I just tried:

r.info elevation
WARNING: Unable to get history information for 
...
[rest as usual]

So, it should not be a problem.

# idea r.external:
I just checked, it seems that r.external generates the same amount of
files, hence not helpful in this regard.

# idea find directories with most inode consumption (source [1]):
for i in `ls -1A | grep -v "\.\./" | grep -v "\./"`; do echo "`find $i
| sort -u | wc -l` $i"; done | sort -rn | head -10


Well, most are clearly in cell_misc as there are three files per raster 
map. But I do think these are necessary.




Maybe you can still delete something?


At this stage they've raised my quota, so I can go on working for now, 
but I'll explore this when I have the time.




Markus

PS: it happened to me in the past when exporting XFS over NFS (while
it worked ok inside the HPC system). In the end I had to reformat the
disk array...


I have to admit that I don't have the knowledge of exactly the different 
parts of the HPC system are connected.


Thanks for the help !

Moritz
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] which files are mandatory for raster maps

[Moritz Lennert]

Hello,

I'm working with a large batch of raster maps (4550 * 4 bands) and 
including all the auxiliary files this explodes my inode quota on our 
university's HPC system. While waiting to see if they can increase this, 
I was wondering which of the auxiliary files are absolutely mandatory.


Can I just erase colr/* and hist/* for example ?

Moritz

___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Nice opportunity to show off GRASS functionality and topological vector format ?

[Moritz Lennert]

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 the European Centre for 
Medium-Range Weather Forecasts (ECMWF) is a collabrative online 
programme to promote the development of weather-related open-source 
software."


More specificially:

https://github.com/esowc/challenges_2019

And even more, I think this challenge is a fairly low hanging fruit 
using GRASS GIS tools:


https://github.com/esowc/challenges_2019/issues/3


APPLICATION DEADLINE: SUNDAY, 21 APRIL 23:59 GMT


Moritz
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] include a 'nearest' option in r.walk ?

[Moritz Lennert]

On 11/04/19 09:36, Markus Metz wrote:

Hi Moritz,

On Wed, Apr 10, 2019 at 4:16 PM Moritz Lennert 
mailto:mlenn...@club.worldonline.be>> 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 existing 
tools ?

 >
 > A related question @Markus: As you know r.cost & r.walk the best, how
 > difficult would it be to include a 'nearest' option also in r.walk ?

not so difficult: done in trunk r74367.




Behold Markus "Lucky Luke" Metz who codes faster than his shadow !

Thanks a lot !

Moritz



___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev