Re: [GRASS-dev] GSoC 2024

[Anna Petrášová via grass-dev]

Just a reminder, we are meeting today to kick off the Google Summer of Code
community bonding period:

Time: May 8, 2024 01:00 PM Eastern Time (US and Canada)
https://www.timeanddate.com/worldclock/meetingdetails.html?year=2024=5=8=17=0=0=207=48=51=671

Join Zoom Meeting
https://ncsu.zoom.us/j/91478802764?pwd=NzlNc3ZvN3FMMzZxcVNzUEFsYWV3dz09

On Thu, May 2, 2024 at 3:48 PM Markus Neteler  wrote:

> On Thu, May 2, 2024 at 5:29 PM Anna Petrášová via grass-dev
>  wrote:
> >
> > Hi devs,
> >
> > We plan to have a call with the new Google Summer of Code students. If
> you want to learn more about the projects and meet the students, please
> join the call:
> >
> > Topic: GRASS GIS GSoC 2024
> > Time: May 8, 2024 01:00 PM Eastern Time (US and Canada)
> >
> > Join Zoom Meeting
> > https://ncsu.zoom.us/j/91478802764?pwd=NzlNc3ZvN3FMMzZxcVNzUEFsYWV3dz09
> >
> > Meeting ID: 914 7880 2764
> > Passcode: 868437
> >
> > Best,
> > Anna
>
> Here in some other timezones:
>
> https://www.timeanddate.com/worldclock/meetingdetails.html?year=2024=5=8=17=0=0=207=48=51=671
>
> (hope I got it right)
>
> Markus
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] GSoC 2024

[Anna Petrášová via grass-dev]

Hi devs,

We plan to have a call with the new Google Summer of Code students. If you
want to learn more about the projects and meet the students, please join
the call:

Topic: GRASS GIS GSoC 2024
Time: May 8, 2024 01:00 PM Eastern Time (US and Canada)

Join Zoom Meeting
https://ncsu.zoom.us/j/91478802764?pwd=NzlNc3ZvN3FMMzZxcVNzUEFsYWV3dz09

Meeting ID: 914 7880 2764
Passcode: 868437

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

Re: [GRASS-dev] An applicant for GSoC 2024

[Anna Petrášová via grass-dev]

Hi Hamish, good to hear from you! Thanks for pointing that out, I added it
to the GSoC ideas wiki, so in case it won't happen this year, we can try
later.

Anna

On Sun, Apr 7, 2024 at 7:30 AM Hamish B via grass-dev <
grass-dev@lists.osgeo.org> wrote:

> Welcome Chung-Yuan,
>
> Huidae wrote:
> > Please check this feature request at
> https://github.com/OSGeo/grass/issues/2644
> > for testing your skills and let me know if you have any questions.
>
> For whatever it is worth, it always struck me that v.surf.bspline was
> low hanging fruit for OpenMP parallelization, as the code already
> splits the data up into a manageable number of overlapping
> tiles/segments, then processes them serially before recombining them.
>
> See
> https://github.com/OSGeo/grass/blob/main/vector/v.surf.bspline/main.c#L529
> and further comment on line 607 and debug message on line 475.
>
>
> all the best from deep in the South Pacific,
> Hamish
> ___
> 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] [GSoC 2024] OSGeo Grass: Add JSON output to different tools in C

[Anna Petrášová via grass-dev]

Hi Kriti,

I think you can go ahead and submit it!

Anna

On Wed, Mar 27, 2024 at 3:22 PM Kriti Birda 
wrote:

> Hi Anna,
>
> Thanks for the feedback and the insights. I had put 1 per week as a
> conservative estimate but yes I think more should be doable too. Please let
> me know if I should make any other changes to the proposal.
>
> Regards.
>
> On Thu, Mar 28, 2024 at 12:38 AM Anna Petrášová 
> wrote:
>
>> Hi Kriti,
>>
>> Welcome and thank you for your interest! I provided some suggestions in
>> terms of which tools to prioritize. I put two tools per week, I think it's
>> feasible, but please understand this is flexible and one tool a week would
>> be a success as well. The priority of the tools may change as well based on
>> the community input and other factors.
>>
>> Best,
>> Anna
>>
>>
>> On Wed, Mar 27, 2024 at 9:44 AM Kriti Birda via grass-dev <
>> grass-dev@lists.osgeo.org> wrote:
>>
>>> Hello Grass devs,
>>>
>>> I am Kriti Birda, an undergraduate student of Bachelor of Science at
>>> Indian Institute of Technology, Madras. I would like to apply to your
>>> organisation for Google Summer of Code this year. I find the idea to add
>>> JSON output to various tools in Grass particularly interesting. I have also
>>> worked closely with Grass devs over the past few days to add JSON output
>>> support to one module (https://github.com/OSGeo/grass/pull/3528). Here
>>> is a draft project proposal I wrote for my application:
>>> https://docs.google.com/document/d/1CQOAkjKINPeWt7pW561Jp1WEWV90ws-m_ybOQLIWvOM/edit?usp=sharing.
>>> It would be awesome if you could review and provide feedback on how I can
>>> improve it.
>>>
>>> Looking forward to hearing from you. Warm Regards.
>>> ___
>>> 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] [GSoC 2024] OSGeo Grass: Add JSON output to different tools in C

[Anna Petrášová via grass-dev]

Hi Kriti,

Welcome and thank you for your interest! I provided some suggestions in
terms of which tools to prioritize. I put two tools per week, I think it's
feasible, but please understand this is flexible and one tool a week would
be a success as well. The priority of the tools may change as well based on
the community input and other factors.

Best,
Anna


On Wed, Mar 27, 2024 at 9:44 AM Kriti Birda via grass-dev <
grass-dev@lists.osgeo.org> wrote:

> Hello Grass devs,
>
> I am Kriti Birda, an undergraduate student of Bachelor of Science at
> Indian Institute of Technology, Madras. I would like to apply to your
> organisation for Google Summer of Code this year. I find the idea to add
> JSON output to various tools in Grass particularly interesting. I have also
> worked closely with Grass devs over the past few days to add JSON output
> support to one module (https://github.com/OSGeo/grass/pull/3528). Here is
> a draft project proposal I wrote for my application:
> https://docs.google.com/document/d/1CQOAkjKINPeWt7pW561Jp1WEWV90ws-m_ybOQLIWvOM/edit?usp=sharing.
> It would be awesome if you could review and provide feedback on how I can
> improve it.
>
> Looking forward to hearing from you. Warm Regards.
> ___
> 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 8.3.2

[Anna Petrášová via grass-dev]

+1

Anna

On Wed, Mar 6, 2024 at 9:54 AM Martin Landa  wrote:

> Hi Markus,
>
> I'd now move on and publish GRASS GIS 8.3.2 unless there are objections
>>
>
> +1
>
> Martin
>
> Markus
>>
>> --
>> Markus Neteler, PhD
>> https://www.mundialis.de - company
>> https://grass.osgeo.org - FOSS
>> https://neteler.org - freelancing & blog
>> ___
>> 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] GSoC Ideas

[Anna Petrášová via grass-dev]

On Sun, Mar 3, 2024 at 4:07 PM Luca Delucchi  wrote:

> Hi Anna,
>
> On Fri, 1 Mar 2024 at 17:30, Anna Petrášová  wrote:
> >
> > We have already students wanting to work on github issues linked as test
> of skills. Martin and Luca, your ideas don't have a test of skills, please
> add it there as soon as possible, otherwise we can't really use the idea,
> test of skills is required by OSGeo.
> >
>
> Thanks for the reminder, I created this issue
> https://github.com/OSGeo/grass-addons/issues/1033, is it doable or too
> complicated?
>
> Sure, that works!


> > Thank you
> >
>
> --
> ciao
> Luca
>
> www.lucadelu.org
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Can GRASS import a *.ige file?

[Anna Petrášová via grass-dev]

There should be an .img file, try open that instead.

On Fri, Mar 1, 2024 at 4:51 PM Michael Barton via grass-dev <
grass-dev@lists.osgeo.org> wrote:

> It doesn't look like r.in.gdal does this. Is there an extension or other
> way to import an ERDAS *.ige file?
>
> Michael
> _
>
> C. Michael Barton
> Associate Director, School of Complex Adaptive Systems (
> https://scas.asu.edu)
> Professor, School of Human Evolution & Social Change (
> https://shesc.asu.edu)
> Director, Center for Social Dynamics & Complexity (
> https://complexity.asu.edu)
> Arizona State University
> Tempe, AZ 85287-2701
> USA
>
> Executive Director, Open Modeling Foundation (
> https://openmodelingfoundation.github.io)
> Director, Network for Computational Modeling in Social & Ecological
> Sciences (https://comses.net)
>
> personal website: http://www.public.asu.edu/~cmbarton
>
>
> ___
> 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] GSoC Ideas

[Anna Petrášová via grass-dev]

Martin, how about using https://github.com/OSGeo/grass/issues/2599 as a
test?

On Fri, Mar 1, 2024 at 11:29 AM Anna Petrášová 
wrote:

> We have already students wanting to work on github issues linked as test
> of skills. Martin and Luca, your ideas don't have a test of skills, please
> add it there as soon as possible, otherwise we can't really use the idea,
> test of skills is required by OSGeo.
>
> Thank you
>
> On Mon, Feb 26, 2024 at 1:32 PM Anna Petrášová 
> wrote:
>
>> Good news, OSGeo was accepted [1]. We need to do some advertising now.
>>
>> [1] https://lists.osgeo.org/pipermail/discuss/2024-February/040113.html
>>
>> On Sat, Feb 24, 2024 at 9:04 AM Anna Petrášová 
>> wrote:
>>
>>>
>>>
>>> On Fri, Feb 23, 2024, 6:11 PM Martin Landa 
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> so 3. 2. 2024 v 5:34 odesílatel Anna Petrášová via grass-dev <
>>>> grass-dev@lists.osgeo.org> napsal:
>>>>
>>>>> I created a GSoC Ideas 2024 page on grasswiki (as opposed to trac
>>>>> wiki, which I think we should be moving away from):
>>>>> https://grasswiki.osgeo.org/wiki/GRASS_GSoC_Ideas_2024
>>>>>
>>>>> It's not updated yet, I plan to add more topics. If you want to mentor
>>>>> a topic, we can discuss it here.
>>>>>
>>>>
>>>> I add a new topic related to space-time datasets and Data Catalog [1].
>>>> Martin
>>>>
>>>
>>> Thanks for adding the topic, please also include a test of skills and at
>>> least for now assign yourself as a mentor, I can be a co-mentor.
>>>
>>> Anna
>>>
>>>>
>>>> [1]
>>>> https://grasswiki.osgeo.org/wiki/GRASS_GSoC_Ideas_2024#GUI%3A_Add_space-time_datasets_support_in_Data_Catalog
>>>>
>>>> --
>>>> Martin Landa
>>>> https://geomatics.fsv.cvut.cz/en/employees/martin-landa/
>>>> http://gismentors.cz/mentors/landa
>>>>
>>>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GSoC Ideas

[Anna Petrášová via grass-dev]

We have already students wanting to work on github issues linked as test of
skills. Martin and Luca, your ideas don't have a test of skills, please add
it there as soon as possible, otherwise we can't really use the idea, test
of skills is required by OSGeo.

Thank you

On Mon, Feb 26, 2024 at 1:32 PM Anna Petrášová 
wrote:

> Good news, OSGeo was accepted [1]. We need to do some advertising now.
>
> [1] https://lists.osgeo.org/pipermail/discuss/2024-February/040113.html
>
> On Sat, Feb 24, 2024 at 9:04 AM Anna Petrášová 
> wrote:
>
>>
>>
>> On Fri, Feb 23, 2024, 6:11 PM Martin Landa 
>> wrote:
>>
>>> Hi,
>>>
>>> so 3. 2. 2024 v 5:34 odesílatel Anna Petrášová via grass-dev <
>>> grass-dev@lists.osgeo.org> napsal:
>>>
>>>> I created a GSoC Ideas 2024 page on grasswiki (as opposed to trac wiki,
>>>> which I think we should be moving away from):
>>>> https://grasswiki.osgeo.org/wiki/GRASS_GSoC_Ideas_2024
>>>>
>>>> It's not updated yet, I plan to add more topics. If you want to mentor
>>>> a topic, we can discuss it here.
>>>>
>>>
>>> I add a new topic related to space-time datasets and Data Catalog [1].
>>> Martin
>>>
>>
>> Thanks for adding the topic, please also include a test of skills and at
>> least for now assign yourself as a mentor, I can be a co-mentor.
>>
>> Anna
>>
>>>
>>> [1]
>>> https://grasswiki.osgeo.org/wiki/GRASS_GSoC_Ideas_2024#GUI%3A_Add_space-time_datasets_support_in_Data_Catalog
>>>
>>> --
>>> Martin Landa
>>> https://geomatics.fsv.cvut.cz/en/employees/martin-landa/
>>> http://gismentors.cz/mentors/landa
>>>
>>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GSoC Ideas

[Anna Petrášová via grass-dev]

Good news, OSGeo was accepted [1]. We need to do some advertising now.

[1] https://lists.osgeo.org/pipermail/discuss/2024-February/040113.html

On Sat, Feb 24, 2024 at 9:04 AM Anna Petrášová 
wrote:

>
>
> On Fri, Feb 23, 2024, 6:11 PM Martin Landa  wrote:
>
>> Hi,
>>
>> so 3. 2. 2024 v 5:34 odesílatel Anna Petrášová via grass-dev <
>> grass-dev@lists.osgeo.org> napsal:
>>
>>> I created a GSoC Ideas 2024 page on grasswiki (as opposed to trac wiki,
>>> which I think we should be moving away from):
>>> https://grasswiki.osgeo.org/wiki/GRASS_GSoC_Ideas_2024
>>>
>>> It's not updated yet, I plan to add more topics. If you want to mentor a
>>> topic, we can discuss it here.
>>>
>>
>> I add a new topic related to space-time datasets and Data Catalog [1].
>> Martin
>>
>
> Thanks for adding the topic, please also include a test of skills and at
> least for now assign yourself as a mentor, I can be a co-mentor.
>
> Anna
>
>>
>> [1]
>> https://grasswiki.osgeo.org/wiki/GRASS_GSoC_Ideas_2024#GUI%3A_Add_space-time_datasets_support_in_Data_Catalog
>>
>> --
>> Martin Landa
>> https://geomatics.fsv.cvut.cz/en/employees/martin-landa/
>> http://gismentors.cz/mentors/landa
>>
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GSoC Ideas

[Anna Petrášová via grass-dev]

On Fri, Feb 23, 2024, 6:11 PM Martin Landa  wrote:

> Hi,
>
> so 3. 2. 2024 v 5:34 odesílatel Anna Petrášová via grass-dev <
> grass-dev@lists.osgeo.org> napsal:
>
>> I created a GSoC Ideas 2024 page on grasswiki (as opposed to trac wiki,
>> which I think we should be moving away from):
>> https://grasswiki.osgeo.org/wiki/GRASS_GSoC_Ideas_2024
>>
>> It's not updated yet, I plan to add more topics. If you want to mentor a
>> topic, we can discuss it here.
>>
>
> I add a new topic related to space-time datasets and Data Catalog [1].
> Martin
>

Thanks for adding the topic, please also include a test of skills and at
least for now assign yourself as a mentor, I can be a co-mentor.

Anna

>
> [1]
> https://grasswiki.osgeo.org/wiki/GRASS_GSoC_Ideas_2024#GUI%3A_Add_space-time_datasets_support_in_Data_Catalog
>
> --
> Martin Landa
> https://geomatics.fsv.cvut.cz/en/employees/martin-landa/
> http://gismentors.cz/mentors/landa
>
___
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.3.2

[Anna Petrášová via grass-dev]

On Thu, Feb 22, 2024 at 12:33 PM Markus Neteler  wrote:

> On Thu, Feb 22, 2024 at 3:59 PM Anna Petrášová 
> wrote:
> > On Tue, Feb 20, 2024 at 5:45 PM Markus Neteler via grass-dev <
> grass-dev@lists.osgeo.org> wrote:
> ...
> >> Hopefully no RC2 is needed.
> >
> > Markus,
> >
> > a bug in r.horizon came up on gitter recently:
> > https://github.com/OSGeo/grass/pull/3441
> >
> > It would be nice to include it in 8.3.2 (with all the other fixes in
> r.horizon) but at the same time I don't want to
> > trigger RC2 because of this... The bug fix is a small change in
> r.horizon not impacting anything else, so
> > perhaps we wouldn't need RC2? What do you think?
>
> For me that's okay as it is very isolated.
> Feel free to backport it.
>
>
Done!


> Markus
>
___
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.3.2

[Anna Petrášová via grass-dev]

On Tue, Feb 20, 2024 at 5:45 PM Markus Neteler via grass-dev <
grass-dev@lists.osgeo.org> wrote:

> Hi devs,
>
> On Thu, Feb 1, 2024 at 10:40 PM Markus Neteler  wrote:
> > We have accumulated a number of fixes in the past weeks.
> >
> > Here the milestone:
> > https://github.com/OSGeo/grass/milestone/24
>
> The RC1 release is now available, please test it:
> https://github.com/OSGeo/grass/releases/tag/8.3.2RC1
>
> The open issues/PR I have moved to a new 8.3.3 milestone. But let's
> focus on 8.4.0.
>
> And yay, the Zenodo bridge works again:
> Version 8.3.2RC1: https://zenodo.org/records/10685321
> DOI: https://doi.org/10.5281/zenodo.10685321 (resolver link will work
> in some hs from now)
>
> Hopefully no RC2 is needed.
>

Markus,

a bug in r.horizon came up on gitter recently:
https://github.com/OSGeo/grass/pull/3441

It would be nice to include it in 8.3.2 (with all the other fixes in
r.horizon) but at the same time I don't want to trigger RC2 because of
this... The bug fix is a small change in r.horizon not impacting anything
else, so perhaps we wouldn't need RC2? What do you think?


> Thanks to all contributors,
> Markus
>
> --
> Markus Neteler, PhD
> https://www.mundialis.de - company
> https://grass.osgeo.org - FOSS
> https://neteler.org - freelancing & blog
> ___
> 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] GSoC Ideas

[Anna Petrášová via grass-dev]

gt; our intro tutorials, including opening a web browser with the chosen
> tutorial and adding some layers to the map view; two clicks (+ file
> browsing) to have users raster or vector data displayed).
>

 I think Vashek's point was to gently remind you there has been a lot of
discussion going on in the past, not to resurrect one of those ideas:)

>
> Linda, in your paper you wrote: „Since both options were favorably
> rated (85% responded positively to the first-run wizard and 74% to
> info bars), we decided to implement an info bar as a technically
> simpler and more flexible solution.“ The idea of this GSOC proposal
> was to implement in some form the second option that would allow to
> perform A/B testing with real users. As you (et al.) have done a huge
> work with the codebase, now it would be much easier to implement than
> some years a go.
> I also understand that users want to start working with the software
> right away. But here is a catch – most likely nobody will start GRASS
> to work with data provided by the demo project. Either they will start
> GRASS to do some exercises in a training course / to follow a tutorial
> (= download one of sample datasets, add some layer to the map view),
> or to work with data they have to solve the analysis problem they are
> facing (= create a new project from supplied data, import file, add it
> to the map view, display warning about computational region in your
> info bar, if imported data were vectors and not raster). If user
> cancels the wizard, just fine. Let him enjoy the demo project and
> display first time screen also on the next startup iff there is no
> project with data in the GISDBASE. This would not interfere with a
> big, fat warning if someone tries to import external data into sample
> projects (NC, Spearfish, ...) or any other enhancements that could be
> done.
>

 I agree with a lot of points you are making but I guess I still don't
understand exactly what your suggestion is and how it would make things
better and for whom...


> Huh, I think I answered most of points from previous emails (except
> going into details of potential architecture (thus Anna for wxPython
> expertise) or user friendliness (thus Vero)). Thank you to everyone
> who read this far and sorry for all unintentional fuss I caused.
> Probably Linda you are right – it is too ambitious for an experimental
> project that might get tossed away at the end. I see that Anna has
> already removed the idea from the wiki, most likely for good. Do not
> restore it, let it be so. We can return to this idea at any point
> later if we feel need for it. I have plenty to do to fix pointer
> juggling bugs in the new module I have almost finished (anisotropic
> smoothing).
> Māris.
>
> piektd., 2024. g. 16. febr., plkst. 10:41 — lietotājs Linda Kladivová
> () rakstīja:
> >
> > Hello Māris,
> >
> > just to add some other info, we did several surveys among GRASS users
> about first-time user experience with Anna, Martin and Vashek and we also
> tested old and new startup mechanisms in a real environment within the
> usability testing - you can have a look at our article:
> https://www.mdpi.com/2220-9964/12/9/376.
> >
> > As Anna has already written, the results of usability testing were
> indeed mixed but I would like to emphasize one thing - most of the
> usability participants (first-time users) said to me that they simply
> expect they will be directly redirected to the main software window where
> they can start working without knowing anything about the software. The
> current "info bar" solution goes in that direction and although I have to
> admit that it has flaws there are ways how to make it better and Anna has
> already written some points.
> >
> > I think it would be nice to focus on how to make the current solution
> better (it is definitely doable and even desirable) and not go back to some
> alternatives to the old solution.
> > Above that, it would be extremely time-consuming to implement any dialog
> wizards and at the same time the impact of that "dialog" solution is very
> uncertain - one important thing we also learned from surveys and
> discussions inside/outside the community is that the one good generally
> acceptable solution simply does not exist here - it will always be a
> compromise.
> >
> > Just my two cents. :-)
> > Linda
> >
> > -- Původní e-mail --
> > Od: Maris Nartiss via grass-dev 
> > Komu: Anna Petrášová , Veronica Andreo <
> veroand...@gmail.com>
> > Kopie: GRASS-dev 
> > Datum: 15. 2. 2024 13:04:24
> > Předmět: Re: [GRASS-dev] GSoC Ideas
> >
> > Hello Anna, Vero.
> > I added the welcome s

Re: [GRASS-dev] GSoC Ideas

[Anna Petrášová via grass-dev]

I believe the welcome screen would most likely be dismissed. The other
possible solutions Brendan brings up may be difficult to implement with
wxpython. But we tried to do something similar with Linda using the info
bar, which shows info/buttons for first-time users. She tested that with
mixed results, people often just dismissed it. But I think it could be
further refined. For example, maybe we could move it to map display to make
it more prominent. The other direction is to better detect when users are
doing something likely wrong (import projected data to default project) and
then suggest alternatives.

On Thu, Feb 15, 2024 at 12:05 PM Brendan  wrote:

> Personally I like the new interface, but Maris' proposal for wizards to
> create new projects sounds helpful. Rather than a startup screen that
> stalls users, there could be temporary icons floating on the map canvas
> that prompt users to create a new project in different ways. Would
> disappear as soon as data is added to the map. A helpful guide/shortcut
> that users could choose to ignore. Still, any startup hints might be
> annoying like Clippy the infamous paperclip. I can find an example from
> other software if the idea is of interest. Or the logo that pops up when
> you start GRASS could have buttons for creating new projects; if a user
> doesn't click on them while GRASS is starting, then it will open in the
> default / previous project.
> Best, Brendan
>
> On Thu, Feb 15, 2024 at 8:35 AM Anna Petrášová via grass-dev <
> grass-dev@lists.osgeo.org> wrote:
>
>> I agree with Vero. I am not sure we had enough time to evaluate the
>> current state yet. I don't remember the details of our discussions, so if
>> you provide a description of what exactly you mean, that would be helpful.
>> In terms of a GSoC project, the main issue I see is that the mentors need
>> to provide clear instructions on what the student should do, especially for
>> this case, and we apparently don't have a consensus here. So I would be
>> willing to mentor it only as long as we develop a plan ahead of time we can
>> all agree on. Given the past experience, I am somewhat skeptical we can all
>> agree on something:) But I'll try to be open to ideas!
>>
>> On Thu, Feb 15, 2024 at 8:12 AM Veronica Andreo 
>> wrote:
>>
>>> Hi Maris,
>>>
>>> Would you mind sharing more details on this idea? I'm afraid I was not
>>> able to attend/hear the discussion about this welcome screen in Prague. I
>>> hope though we do not end up with a new startup screen. It took so much
>>> time to reach an agreement and finally remove it.
>>>
>>> Vero
>>>
>>> El jue, 15 feb 2024 a las 9:00, Maris Nartiss ()
>>> escribió:
>>>
>>>> Hello Anna, Vero.
>>>> I added the welcome screen idea we discussed during our Prague
>>>> meeting. I think it would be a good GSOC project as it is quite easy
>>>> and at the same time will allow to understand if it is the way to go.
>>>> Anna, would you be able to be a co-mentor as it is a GUI project? Or
>>>> who else could be?
>>>> Vero, your user-centric view also would be valuable.
>>>> Please edit the wiki accordingly.
>>>>
>>>> Thanks,
>>>> Māris.
>>>>
>>>> sestd., 2024. g. 3. febr., plkst. 06:34 — lietotājs Anna Petrášová via
>>>> grass-dev () rakstīja:
>>>> >
>>>> > Hi,
>>>> >
>>>> > I created a GSoC Ideas 2024 page on grasswiki (as opposed to trac
>>>> wiki, which I think we should be moving away from):
>>>> > https://grasswiki.osgeo.org/wiki/GRASS_GSoC_Ideas_2024
>>>> >
>>>> > It's not updated yet, I plan to add more topics. If you want to
>>>> mentor a topic, we can discuss it here.
>>>> >
>>>> > Anna
>>>> > ___
>>>> > grass-dev mailing list
>>>> > grass-dev@lists.osgeo.org
>>>> > https://lists.osgeo.org/mailman/listinfo/grass-dev
>>>>
>>>
>>>
>>> --
>>> Dra. Verónica Andreo
>>> Investigadora Adjunta de CONICET
>>> Instituto Gulich (CONAE - UNC)
>>> Centro Espacial Teófilo Tabanera (CETT)
>>> Falda del Cañete - Córdoba, Argentina
>>> +54 3547 40 int. 1153
>>> https://veroandreo.gitlab.io/
>>>
>> ___
>> 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] GSoC Ideas

[Anna Petrášová via grass-dev]

I agree with Vero. I am not sure we had enough time to evaluate the current
state yet. I don't remember the details of our discussions, so if you
provide a description of what exactly you mean, that would be helpful. In
terms of a GSoC project, the main issue I see is that the mentors need to
provide clear instructions on what the student should do, especially for
this case, and we apparently don't have a consensus here. So I would be
willing to mentor it only as long as we develop a plan ahead of time we can
all agree on. Given the past experience, I am somewhat skeptical we can all
agree on something:) But I'll try to be open to ideas!

On Thu, Feb 15, 2024 at 8:12 AM Veronica Andreo 
wrote:

> Hi Maris,
>
> Would you mind sharing more details on this idea? I'm afraid I was not
> able to attend/hear the discussion about this welcome screen in Prague. I
> hope though we do not end up with a new startup screen. It took so much
> time to reach an agreement and finally remove it.
>
> Vero
>
> El jue, 15 feb 2024 a las 9:00, Maris Nartiss ()
> escribió:
>
>> Hello Anna, Vero.
>> I added the welcome screen idea we discussed during our Prague
>> meeting. I think it would be a good GSOC project as it is quite easy
>> and at the same time will allow to understand if it is the way to go.
>> Anna, would you be able to be a co-mentor as it is a GUI project? Or
>> who else could be?
>> Vero, your user-centric view also would be valuable.
>> Please edit the wiki accordingly.
>>
>> Thanks,
>> Māris.
>>
>> sestd., 2024. g. 3. febr., plkst. 06:34 — lietotājs Anna Petrášová via
>> grass-dev () rakstīja:
>> >
>> > Hi,
>> >
>> > I created a GSoC Ideas 2024 page on grasswiki (as opposed to trac wiki,
>> which I think we should be moving away from):
>> > https://grasswiki.osgeo.org/wiki/GRASS_GSoC_Ideas_2024
>> >
>> > It's not updated yet, I plan to add more topics. If you want to mentor
>> a topic, we can discuss it here.
>> >
>> > Anna
>> > ___
>> > grass-dev mailing list
>> > grass-dev@lists.osgeo.org
>> > https://lists.osgeo.org/mailman/listinfo/grass-dev
>>
>
>
> --
> Dra. Verónica Andreo
> Investigadora Adjunta de CONICET
> Instituto Gulich (CONAE - UNC)
> Centro Espacial Teófilo Tabanera (CETT)
> Falda del Cañete - Córdoba, Argentina
> +54 3547 40 int. 1153
> https://veroandreo.gitlab.io/
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GSoC Ideas

[Anna Petrášová via grass-dev]

I sent the ideas page to OSGeo admins (the deadline is today), although I
think we can keep adding topics. Please also fill out this form
https://forms.gle/dZDYovvmhrQRah73A if you plan to mentor.

Thanks,
Anna

On Mon, Feb 5, 2024 at 7:33 AM Veronica Andreo  wrote:

> That would be cool Luca! eodag allows you to download different EO
> datasets.
>
> Do you think of a GSoC project idea to include eodag support for
> i.sentinel.download, i.landsat.download and i.modis.download or as a new
> module to download EO data in general? If you are willing to mentor, I can
> be your second... mainly to test and make annoying questions :)
>
> Vero
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GSoC Ideas

[Anna Petrášová via grass-dev]

On Sat, Feb 3, 2024 at 4:39 AM Luca Delucchi  wrote:

>
>
> Il sab 3 feb 2024, 05:34 Anna Petrášová via grass-dev <
> grass-dev@lists.osgeo.org> ha scritto:
>
>> Hi,
>>
>> I created a GSoC Ideas 2024 page on grasswiki (as opposed to trac wiki,
>> which I think we should be moving away from):
>> https://grasswiki.osgeo.org/wiki/GRASS_GSoC_Ideas_2024
>>
>> It's not updated yet, I plan to add more topics. If you want to mentor a
>> topic, we can discuss it here.
>>
>
> Do you think an interface to eodag library, to download sentinel and
> Landsat images for example, could be a topic for gsoc?
>

I suppose so. As long as somebody (you?) would mentor it, we can add it
(including test of skills etc).


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

[GRASS-dev] GSoC Ideas

[Anna Petrášová via grass-dev]

Hi,

I created a GSoC Ideas 2024 page on grasswiki (as opposed to trac wiki,
which I think we should be moving away from):
https://grasswiki.osgeo.org/wiki/GRASS_GSoC_Ideas_2024

It's not updated yet, I plan to add more topics. If you want to mentor a
topic, we can discuss it here.

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

[GRASS-dev] NSF POSE project progress report

[Anna Petrášová via grass-dev]

Dear all,

In September we announced a new grant [1] that was awarded to enhance GRASS
GIS ecosystem. We would like to share a progress report for 1st quarter [2]
with the community to highlight the efforts that span various repositories
and include participation in several events. The report also includes the
project roadmap.

Best,
Anna for the POSE team (Helena, Vaclav, Anna, Huidae, Michael, Giuseppe)

[1] https://grass.osgeo.org/news/2023_09_06_nsf_grant_awarded/
[2] https://grasswiki.osgeo.org/wiki/NSF_POSE_Project_2023-2025_Timeline
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GRASS Windows issues

[Anna Petrášová via grass-dev]

Even if the GUI doesn't start, could you still type in:

g.findfile element=cell file=MASK

and also:

g.gisenv

and see what you get?

On Mon, Dec 11, 2023 at 3:04 AM Gandalf the Gray via grass-dev <
grass-dev@lists.osgeo.org> wrote:

> Hi Maris.
>
> Yes I always had ArcGIS installed and it has never given any issues with
> GRASS.
>
> Pieter
>
> On Mon, 11 Dec 2023, 09:19 Maris Nartiss,  wrote:
>
>> Windows issues are hard to debug as most of developers are on Linux boxes.
>> Do you have an ArcGIS install by any chance? In the past ArcGIS was a
>> source of different problems for GRASS as it would register its Python
>> globally and then GRASS would pick wrong Python version resulting
>> myriad of strange errors.
>>
>> M.
>>
>> svētd., 2023. g. 10. dec., plkst. 17:25 — lietotājs Gandalf the Gray
>> via grass-dev () rakstīja:
>> >
>> > Hi Jeff
>> >
>> > Thanks for the link.  I installed the 8.4 dev version. and it gives
>> exactly the same error as with GRASS standalone from grass,osgeo.org,
>> GRASS installed with OSGeo4W, and from the QGIS standalone installer.
>> >
>> > I am now suspecting that it might not be the wxpython included in the
>> installers, but my pc itself.
>> >
>> > Regards
>> >
>> > Pieter
>> >
>> > On Sun, Dec 10, 2023 at 2:52 PM Jeff McKenna via grass-dev <
>> grass-dev@lists.osgeo.org> wrote:
>> >>
>> >> Hi Pieter,
>> >>
>> >> I personally always recommend using WinGRASS, it is very reliable.
>> >> (thanks to MartinL)  https://wingrass.fsv.cvut.cz/grass84/
>> >>
>> >> Merry Christmas to you and the GRASS GIS family,
>> >>
>> >> -jeff
>> >>
>> >>
>> >>
>> >> --
>> >> Jeff McKenna
>> >> GatewayGeo: Developers of MS4W, & offering MapServer Consulting/Dev
>> >> co-founder of FOSS4G
>> >> http://gatewaygeo.com/
>> >>
>> >>
>> >>
>> >> On 2023-12-09 12:17 a.m., Gandalf the Gray via grass-dev wrote:
>> >> > Hi guys.
>> >> >
>> >> > In desperation I am posting to this list.  I have posted on the
>> OSGeo4W
>> >> > list a week ago to no avail.
>> >> >
>> >> > I hope someone can help me.
>> >> >
>> >> > On a clean install of OSGeo4W (and for that matter standalone QGIS
>> and
>> >> > GRASS installers), I get the following error (see attached
>> screenshot)
>> >> > starting any version of GRASS.
>> >> >
>> >> > On GRASS 7, I can do a mapset selection before crash, but the other 2
>> >> > just crashes.
>> >> >
>> >> > Install is on a machine that ran GRASS up until a week ago, until I
>> >> > uninstalled the OSGeo4W stack, and deleted everything.  There is
>> nothing
>> >> > strange about my Windows Setup
>> >> >
>> >> > I hope anyone can help me, and I hope you can see the screenshot.
>> >> >
>> >> > Regards
>> >> >
>> >> > Pieter
>> >> >
>> >> > _
>> >>
>> >> ___
>> >> 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 mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Parallelizing algorithms

[Anna Petrášová via grass-dev]

Hi Shreyas,

That's a great effort, would you be able to share the progress with us?
Usually, it's good if multiple people test it on different hardware, see
for example a previous parallelization contribution [1]. To measure the
performance, there is a benchmarking library [2] you can use. There are
benchmarking scripts in the source code for some tools, see for example [3]
or see a benchmarking example in a jupyter notebook [4].

Anna

[1] https://github.com/OSGeo/grass/pull/1782
[2] https://grass.osgeo.org/grass83/manuals/libpython/grass.benchmark.html
[3] https://github.com/OSGeo/grass/tree/main/raster/r.neighbors/benchmark
[4]
https://github.com/ncsu-geoforall-lab/grass-workshop-gis-week-2023/blob/main/01_intro_to_GRASS_parallelization.ipynb

On Tue, Dec 5, 2023 at 3:28 AM Shreyas Udaya via grass-dev <
grass-dev@lists.osgeo.org> wrote:

> I am currently parallelizing raster algorithms of grass using OpenMP and I
> am supposed to evaluate their performance compared to original algorithm.
> Is there any standard way to do this?
> ___
> 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] [GRASS-user] cost surface with negative friction odd behavior

[Anna Petrášová via grass-dev]

Michael, could you please create a PR for the documentation?

On Wed, Nov 29, 2023 at 3:56 PM Michael Barton via grass-user <
grass-u...@lists.osgeo.org> wrote:

> Thanks Anna and Doug,
>
> I did not expect it to work (thought it would be useful if it did). Rather
> I was surprised by the fact that r.walk DID run and that it gave very odd
> results.
>
> Adding to the docs is a good idea. Even better would also to have a
> friction map with a negative value (min<0) raise an error in r.walk, saying
> that all values in a friction map must be ≥ 0
>
> Michael
> _
>
> C. Michael Barton
> Associate Director, School of Complex Adaptive Systems (
> https://scas.asu.edu)
> Professor, School of Human Evolution & Social Change (
> https://shesc.asu.edu)
> Director, Center for Social Dynamics & Complexity (
> https://complexity.asu.edu)
> Arizona State University
> Tempe, AZ 85287-2701
> USA
>
> Executive Director, Open Modeling Foundation (
> https://openmodelingfoundation.github.io)
> Director, Network for Computational Modeling in Social & Ecological
> Sciences (https://comses.net)
>
> personal website: http://www.public.asu.edu/~cmbarton
>
>
> On Nov 29, 2023, at 1:00 PM, grass-user-requ...@lists.osgeo.org wrote:
>
> Date: Wed, 29 Nov 2023 10:17:19 -0500
> From: Anna Petr??ov? 
> To: Michael Barton 
> Cc: GRASS developers , GRASS user list
> 
> Subject: Re: [GRASS-user] cost surface with negative friction odd
> behavior
> Message-ID:
> 
> Content-Type: text/plain; charset="utf-8"
>
> I think r.walk was not written for negative friction and while I imagine
> some small (in absolute sense) negative values may work, your negative
> values are pretty extreme, meaning the resulting travel time through a cell
> would be negative. That can cause all kinds of issues in the algorithm. So
> I would say friction should not be negative. I am not sure I would check
> that in the code, because you would need to check that for each cell and I
> think it's unnecessary overhead. Maybe just adding a note to documentation
> may be enough. I haven't looked into the code itself, so this is just my
> guess.
>
> Anna
>
> On Tue, Nov 28, 2023 at 5:48?PM Michael Barton via grass-user <
> grass-u...@lists.osgeo.org> wrote:
>
>
> ___
> 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] [GRASS-user] cost surface with negative friction odd behavior

[Anna Petrášová via grass-dev]

I think r.walk was not written for negative friction and while I imagine
some small (in absolute sense) negative values may work, your negative
values are pretty extreme, meaning the resulting travel time through a cell
would be negative. That can cause all kinds of issues in the algorithm. So
I would say friction should not be negative. I am not sure I would check
that in the code, because you would need to check that for each cell and I
think it's unnecessary overhead. Maybe just adding a note to documentation
may be enough. I haven't looked into the code itself, so this is just my
guess.

Anna

On Tue, Nov 28, 2023 at 5:48 PM Michael Barton via grass-user <
grass-u...@lists.osgeo.org> wrote:

> In teaching a class about modeling movement, we talked about how to
> represent a cost surface when some areas of terrain (e.g., water or paved
> roads), could be crossed more rapidly than walking across unmodified
> topography. Since a friction map for r.walk adds cost in seconds/meter to
> the cost of walking across unmodified terrain, I wondered if a friction map
> with **negative costs** would decrease the movement costs across a
> landscape.
>
> Using the SC demo data set, I tried this with a set of maps I prepared for
> class. Previously, I had created a friction map from the landclass96 map
> such that cells with water (class 20) have a value of 90 sec/m, dense
> vegetation (classes 7-19) have a value of 20 sec/m, and the rest of the
> cells have a value of 0 sec/m. I generated a cost surface with r.walk using
> elevation and this friction map with a starting point from the Dorothea Dix
> Hospital.
>
> r.walk --overwrite -k elevation=elevation@PERMANENT
> friction=landclass96_friction output=dd_hospital_seconds_friction
> outdir=dd_hospital_directions_friction start_points=DD_hospital memory=1000
>
> This behaved as expected and created a cost surface that represented
> different degrees of difficulty in crossing vegetated and inundated
> terrain.
>
> To explore what would happen with a friction surface with negative
> numbers, I simply subtracted the previous friction map from 0 so that dense
> vegetation = -20, water = -90, and the rest of the cells = 0. Then I used
> it with r.walk and the elevation DEM.
>
> r.walk -k elevation=elevation@PERMANENT
> friction=landclass96_friction_negative
> output=dd_hospital_seconds_negativefriction
> outdir=dd_hospital_directions_negativefriction start_points=DD_hospital
> memory=2000
>
> There was no error, but the resulting cost surface is very strange.
>
> The data range of the original cost surface with the positive values
> friction map is:
>
> Range of data:min = 0  max = 103883.003593944 (max of 28.8 hours to
> reach the hospital given added costs of walking through dense vegetation or
> avoiding water).
>
> However, the data range of the cost surface made with the friction map
> with negative values is completely weird.
>
> Range of data:min = -166202271.811971  max = -154320.938078961 (-46167
> to -43 hours)
>
> Since a friction map simply adds cost to the cost surface, if a negative
> friction map did not work, I might expect it to raise an error or have no
> impact (values < 0 become 0). But the values in the resulting cost surface
> don't make any sense at all.
>
> Does anyone have any thoughts on this?
>
> I will try to attach attach the original friction map made from the SC
> landclass96 map, the cost surface made with elevation and friction map, and
> cost surface made with elevation and negative friction map.
>
> Michael
>
> _
>
> C. Michael Barton
> Associate Director, School of Complex Adaptive Systems (
> https://scas.asu.edu)
> Professor, School of Human Evolution & Social Change (
> https://shesc.asu.edu)
> Director, Center for Social Dynamics & Complexity (
> https://complexity.asu.edu)
> Arizona State University
> Tempe, AZ 85287-2701
> USA
>
> Executive Director, Open Modeling Foundation (
> https://openmodelingfoundation.github.io)
> Director, Network for Computational Modeling in Social & Ecological
> Sciences (https://comses.net)
>
> personal website: http://www.public.asu.edu/~cmbarton
>
>
> ___
> 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] Contents for FOSS4G Asia 2023

[Anna Petrášová via grass-dev]

I created a PR with some small improvements. Looks good!

On Fri, Nov 24, 2023 at 10:15 PM Huidae Cho  wrote:

> Dear All,
>
> I'm currently working on slides for FOSS4G Asia 2023 next week. If I
> missed any important things, please let me know or feel free to create PRs.
> Any help would be appreciated!
>
> https://github.com/HuidaeCho/grass-gis-talk-foss4g-asia-2023
>
> Best,
> Huidae
> --
> 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

[GRASS-dev] GRASS GIS Mentoring Program

[Anna Petrášová via grass-dev]

Dear all,

I would like to bring to your attention a newly started
development-oriented mentoring program focused on students, researchers,
and software developers who want to integrate GRASS GIS into their
projects. See the announcement with details and application form on GRASS
website:

https://grass.osgeo.org/news/2023_10_11_mentoring_program_announced/

Let me know if you have any questions about applying to the program and
please share this announcement in your circles.

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

Re: [GRASS-dev] GRASS Working Groups

[Anna Petrášová via grass-dev]

Thanks to everyone who responded! I will keep the survey [1] open until the
end of the week. Alternatively, just let me know directly if you want to
join.

Based on the responses I created wiki pages for the different working
groups [2] and added the respondents to the particular group. I assigned a
group coordinator to each group to get us started. For those of you who
already have access to the wiki, please add what kind of issues you are
interested in within the working group. If you don't have a GRASS wiki
account, you can either try to create it or ask me or the other group
coordinators to fill those details for you. There may be some changes in
the wiki authentication now [3], so I am unsure whether signing up at this
point is feasible or not.

The coordinators (me, Vashek, Helena) will reach out to the members of each
group to discuss preferred communication channels. We would like to use the
current development platform as much as possible so it would be helpful for
you to have a GitHub account.

Thanks again,
Anna


[1] https://forms.gle/BXzooNYBjgkjMmYk9
[2] https://grasswiki.osgeo.org/wiki/Working_Groups
[3] https://lists.osgeo.org/pipermail/grass-dev/2023-October/096070.html


On Tue, Oct 3, 2023 at 11:23 PM Anna Petrášová 
wrote:

> Dear all,
>
> We would like to establish working groups to better coordinate the GRASS
> community activities such as software development, documentation, promotion
> and fostering relations with other communities. If you are interested in
> any of these topics or are already involved in these activities, please
> consider joining the particular working group. Joining a working group is
> also a great way for you to provide feedback on various issues, plug into
> the community and contribute your expertise.
>
> See the form for the proposed working groups and consider signing up:
>
> https://forms.gle/BXzooNYBjgkjMmYk9
>
> There is also a place in the form for your feedback. Once we get your
> responses I will be back with more details to get the working groups
> started.
>
> Thank you,
> Anna
>
>
>
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] GRASS Working Groups

[Anna Petrášová via grass-dev]

Dear all,

We would like to establish working groups to better coordinate the GRASS
community activities such as software development, documentation, promotion
and fostering relations with other communities. If you are interested in
any of these topics or are already involved in these activities, please
consider joining the particular working group. Joining a working group is
also a great way for you to provide feedback on various issues, plug into
the community and contribute your expertise.

See the form for the proposed working groups and consider signing up:

https://forms.gle/BXzooNYBjgkjMmYk9

There is also a place in the form for your feedback. Once we get your
responses I will be back with more details to get the working groups
started.

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

Re: [GRASS-dev] [EXTERNAL] [release planning] GRASS GIS 8.3.1

[Anna Petrášová via grass-dev]

On Thu, Sep 28, 2023 at 1:15 AM Markus Neteler  wrote:

> Hi devs,
>
> May we schedule RC1 by end of the week?
>

+1 from me

>
> Markus
>
>
> Anna Petrášová  schrieb am Mo., 25. Sep. 2023,
> 23:08:
>
>>
>>
>> On Mon, Sep 25, 2023 at 3:23 PM Tomas Zigo via grass-dev <
>> grass-dev@lists.osgeo.org> wrote:
>>
>>> Citát Markus Neteler :
>>> > In addition, we have plenty of wxGUI fixes, which might well go in:
>>> >
>>> > https://github.com/OSGeo/grass/labels/backport%20to%208.3
>>> >
>>> > Markus
>>>
>>> I am in favor of including all necessary wxGUI fixes soon as possible
>>> in the 8.3.1 release.
>>>
>>> https://github.com/OSGeo/grass/labels/backport%20to%208.3
>>>
>>> Tomas
>>>
>>
>> Thanks for all the fixes, I started to go through them and will continue
>> the reviews.
>>
>> Anna
>>
>>>
>>>
>>>
>>> ___
>>> 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] [EXTERNAL] [release planning] GRASS GIS 8.3.1

[Anna Petrášová via grass-dev]

On Mon, Sep 25, 2023 at 3:23 PM Tomas Zigo via grass-dev <
grass-dev@lists.osgeo.org> wrote:

> Citát Markus Neteler :
> > In addition, we have plenty of wxGUI fixes, which might well go in:
> >
> > https://github.com/OSGeo/grass/labels/backport%20to%208.3
> >
> > Markus
>
> I am in favor of including all necessary wxGUI fixes soon as possible
> in the 8.3.1 release.
>
> https://github.com/OSGeo/grass/labels/backport%20to%208.3
>
> Tomas
>

Thanks for all the fixes, I started to go through them and will continue
the reviews.

Anna

>
>
>
> ___
> 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] Learn more about NSF funded project for GRASS ecosystem

[Anna Petrášová via grass-dev]

We just successfully finished the first session and the second one is
coming up tomorrow (EST/New York at 10am, CEST/Brussels at 4pm).
We recorded the presentation part, for those who joined late or can't join
tomorrow, I can privately share the recording.

Best,
Anna


On Tue, Sep 19, 2023 at 10:33 AM Anna Petrášová 
wrote:

> For those interested to join us, the first session is coming up this
> Thursday (EST/New York at 2pm, CEST/Brussels at 8pm). You can join with a
> zoom link:
> https://ncsu.zoom.us/j/97419521476?pwd=cmx3TitGYjZiYWxzd241U0J0TzVUdz09
>
> If you can't make it, you can join the second session on Friday (EST/New
> York at 10am, CEST/Brussels at 4pm).
>
> Looking forward to seeing you there!
>
> Anna
>
> On Mon, Sep 11, 2023 at 4:57 PM Anna Petrášová 
> wrote:
>
>> As a follow up on our announcement about the NSF funded project to
>> enhance GRASS ecosystem [1] I would like to invite everybody interested to
>> an info session! We will briefly explain what we hope to achieve in this
>> project and how you can get involved. There will be time for Q as well.
>> To allow as many people to join, we plan two 1-hour info sessions at
>> different days and times:
>>
>> * Thursday, September 21
>> <https://www.timeanddate.com/worldclock/meetingdetails.html?year=2023=9=21=18=0=0=207=51=48=197=3703>
>>  (EST
>> 2pm, Europe 8pm)
>> * Friday, September 22
>> <https://www.timeanddate.com/worldclock/meetingdetails.html?year=2023=9=22=14=0=0=207=51=48=197=3703>
>>  (EST
>> 10am, Europe 4pm)
>>
>> The content of both sessions will be the same. I will send zoom links a
>> day before each event.
>> Hope to see you there!
>>
>> Anna
>>
>>
>> [1] https://grass.osgeo.org/news/2023_09_06_nsf_grant_awarded/
>>
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Learn more about NSF funded project for GRASS ecosystem

[Anna Petrášová]

For those interested to join us, the first session is coming up this
Thursday (EST/New York at 2pm, CEST/Brussels at 8pm). You can join with a
zoom link:
https://ncsu.zoom.us/j/97419521476?pwd=cmx3TitGYjZiYWxzd241U0J0TzVUdz09

If you can't make it, you can join the second session on Friday (EST/New
York at 10am, CEST/Brussels at 4pm).

Looking forward to seeing you there!

Anna

On Mon, Sep 11, 2023 at 4:57 PM Anna Petrášová 
wrote:

> As a follow up on our announcement about the NSF funded project to enhance
> GRASS ecosystem [1] I would like to invite everybody interested to an info
> session! We will briefly explain what we hope to achieve in this project
> and how you can get involved. There will be time for Q as well.
> To allow as many people to join, we plan two 1-hour info sessions at
> different days and times:
>
> * Thursday, September 21
> <https://www.timeanddate.com/worldclock/meetingdetails.html?year=2023=9=21=18=0=0=207=51=48=197=3703>
>  (EST
> 2pm, Europe 8pm)
> * Friday, September 22
> <https://www.timeanddate.com/worldclock/meetingdetails.html?year=2023=9=22=14=0=0=207=51=48=197=3703>
>  (EST
> 10am, Europe 4pm)
>
> The content of both sessions will be the same. I will send zoom links a
> day before each event.
> Hope to see you there!
>
> Anna
>
>
> [1] https://grass.osgeo.org/news/2023_09_06_nsf_grant_awarded/
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] NSF Grant Awarded to Enhance GRASS GIS Ecosystem

[Anna Petrášová]

Thank you all!

And thank you Aashish, this is exactly what we are looking for and we will
get back to you.

Anna

On Fri, Sep 8, 2023 at 5:17 PM Aashish Chaudhary <
aashish.chaudh...@kitware.com> wrote:

> Congratulations! As the goal of this grant is to facilitate the adoption
> of GRASS GIS in the Industry, I would be glad to discuss how we could
> leverage GRASS GIS for current or future work.
>
> Thanks,
> Aashish
>
> On Fri, Sep 8, 2023 at 5:10 PM massimo di stefano <
> massimodisa...@gmail.com> wrote:
>
>> Bravi tutti!
>>
>> Congratulations <3 !
>>
>> Il giorno ven 8 set 2023 alle 20:38 Anna Petrášová 
>> ha scritto:
>>
>>> Dear all,
>>>
>>> On behalf of a team of researchers from four U.S. universities, I am
>>> excited to announce a new NSF funded project to support and expand the
>>> global GRASS GIS community. See the announcement below:
>>>
>>> https://grass.osgeo.org/news/2023_09_06_nsf_grant_awarded/
>>>
>>> Best,
>>> Anna
>>> ___
>>> 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
>>
>
>
> --
>
> <https://www.kitware.com/>
>
> *Aashish Chaudhary*
>
> Assistant Director of Business Development, D
>
> Kitware, Inc.
>
> (480) 275-0777
>
> www.kitware.com/aashish-chaudhary/ <http://www.kitware.com/matt-leotta/>
>
>
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Learn more about NSF funded project for GRASS ecosystem

[Anna Petrášová]

As a follow up on our announcement about the NSF funded project to enhance
GRASS ecosystem [1] I would like to invite everybody interested to an info
session! We will briefly explain what we hope to achieve in this project
and how you can get involved. There will be time for Q as well.
To allow as many people to join, we plan two 1-hour info sessions at
different days and times:

* Thursday, September 21

(EST
2pm, Europe 8pm)
* Friday, September 22

(EST
10am, Europe 4pm)

The content of both sessions will be the same. I will send zoom links a day
before each event.
Hope to see you there!

Anna


[1] https://grass.osgeo.org/news/2023_09_06_nsf_grant_awarded/
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] NSF Grant Awarded to Enhance GRASS GIS Ecosystem

[Anna Petrášová]

Dear all,

On behalf of a team of researchers from four U.S. universities, I am
excited to announce a new NSF funded project to support and expand the
global GRASS GIS community. See the announcement below:

https://grass.osgeo.org/news/2023_09_06_nsf_grant_awarded/

Best,
Anna
___
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.3.0

[Anna Petrášová]

On Wed, Jun 21, 2023 at 1:21 PM Martin Landa  wrote:

> Hi,
>
> st 21. 6. 2023 v 11:10 odesílatel Anna Petrášová 
> napsal:
>
>> https://github.com/OSGeo/grass/pull/3024
>>>
>>> would be nice to merge before 8.3.0. Martin
>>>
>>
>> Done. I would also like to get this digitizer fix, the digitizer bug was
>> fairly serious.
>>
>
> Thanks.
>
>
>> https://github.com/OSGeo/grass/pull/3027
>>
>>  It's ready to merge once the checks pass.
>>
>
> Checks passed. Please merge and backport to 8.3/8.2. Then I would say we
> are ready for 8.3.0. Martin
>

Done!

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

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

[Anna Petrášová]

On Tue, Jun 20, 2023 at 8:51 AM Martin Landa  wrote:

> Hi,
>
> út 20. 6. 2023 v 8:49 odesílatel Markus Neteler 
> napsal:
>
>> RC1 has been released 2 weeks ago. Is there anything missing in order to
>>> release 8.3.0 (what be nice to do for FOSS4G).
>>>
>>
>> Yes, let's release asap.
>> As there was no negative feedback, I'd suggest to release this week.
>> If there are no objections, I could do that eg later tonight.
>>
>
> https://github.com/OSGeo/grass/pull/3024
>
> would be nice to merge before 8.3.0. Martin
>

Done. I would also like to get this digitizer fix, the digitizer bug was
fairly serious.
https://github.com/OSGeo/grass/pull/3027

 It's ready to merge once the checks pass.

I am for a final release, too.

Anna

>
> --
> 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] no icons in the first toolbar Grass 8.2.2

[Anna Petrášová]

Using pip you should be able to install newest wxPython:

pip install -U -f
https://extras.wxpython.org/wxPython4/extras/linux/gtk3/ubuntu-22.04
wxPython

On Sun, Apr 9, 2023 at 9:15 PM Lizardo Reyna via grass-dev <
grass-dev@lists.osgeo.org> wrote:

> Thanks Markus,
>
> I'll try to install the patches to solve the problem. Then, I'll comment.
>
> Regards
>
> Lizardo
>
>
> On 2023-04-09 14:31, Markus Neteler wrote:
>
> Hi Lizardo,
>
>
> On Sun, Apr 9, 2023 at 5:10 PM Lizardo Reyna via grass-dev
>  wrote:
>
>
> Hi,
>
> I've compiled Grass 8.2.2 in ubuntu 22.04 (two times), the first toolbar
> do not have icons, only the description appers. The console shows this:
>
> Traceback (most recent call last):
>   File "/usr/lib/python3/dist-
> packages/wx/lib/agw/aui/auibar.py", line 3510, in OnPaint
>
> self._art.DrawButton(dc, self, item, item_rect)
>   File "/usr/lib/python3/dist-
> packages/wx/lib/agw/aui/auibar.py", line 1008, in DrawButton
>
> bmp_rect, text_rect = self.GetToolsPosition(dc, item, rect)
>   File "/usr/lib/python3/dist-
> packages/wx/lib/agw/aui/auibar.py", line 1508, in
> GetToolsPosition
>
> bmp_rect = wx.Rect(bmp_x, bmp_y, bmp_width, bmp_height)
> TypeError
> :
> Rect(): arguments did not match any overloaded call:
>   overload 1: too many arguments
>   overload 2: argument 1 has unexpected type 'float'
>   overload 3: argument 1 has unexpected type 'float'
>   overload 4: argument 1 has unexpected type 'float'
>   overload 5: argument 1 has unexpected type 'float'
>   overload 6: argument 1 has unexpected type 'float'
> Traceback (most recent call last):
>   File "/usr/lib/python3/dist-
> packages/wx/lib/agw/aui/auibar.py", line 3510, in OnPaint
>
> [...]
>
> You are hit by a bug in Ubuntu's wxpython4 package. Unlike e.g. Fedora
> they didn't add missing backports of float -> integer fixes.
>
> It was also discussed here:
> https://github.com/OSGeo/grass/issues/2019
> https://github.com/OSGeo/grass/issues/2078
>
> We had the same in OSGeoLive, I have created a report with bugfixes
> for Ubuntu here:
>
> https://bugs.launchpad.net/ubuntu/+source/wxpython4.0/+bug/2012205
>
> These options I see:
> - you install the patches offered in the bug report (not too difficult
> but needs a bit of knowledge how to use `patch`)
> - convince the Ubuntu packagers of wxpython4 to fix the bug using the
> provided patch
> - you try to install a more recent wxpython4 version.
>
> Best,
> Markus
>
> --
> Lizardo Reyna, PhD
> Universidad Técnica de Manabí
> [Address] Lodana, Manabí, Ecuador | [Mobile]  +593  982924637
> PGP Key: 0xa35a15b90ee64e8d
>
>
> --
> --
> Lizardo Reyna, PhD
> Universidad Técnica de Manabí
> [Address] Lodana, Manabí, Ecuador | [Mobile]  +593  982924637
> PGP Key: 0xa35a15b90ee64e8d
> ___
> 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] Candidate modules for OpenMP parallelization

[Anna Petrášová]

Great you can be a mentor! Have you registered as a mentor yet? If not
please ask OSGeo GSoC admins to help you with that.

Regarding the modules, I consider r.watershed as too complex for this. The
student doesn't have extensive experience with OpenMP, neither have I, so I
would prefer to choose something less complex. If you feel confident it's
doable with your help, I am open to that. r.stats looks easier. What I so
far suggested:
* r.proj - Markus Metz tried it 10 years ago, it was not quite working, but
perhaps we could try again with different approach, it would be an
impactful module to speed up
* r.horizon - seems doable, computes maps for different angles, so it looks
like a good fit, likely some rewrite needed
* r.texture - not as impactful, but perhaps easy when we use a similar
approach Aaron used
* v/r.surf.idw - IDW is slow, this could help a lot and it could be
impactful as well.
* r.fill.stats - it's already pretty fast, but it could be relatively easy

The student is interested in the shorter project, so realistically, I don't
think we can do more than 3 modules.
As I said, I am definitely not an expert on this, so I would appreciate
some feedback for others.

Anna

On Fri, Mar 31, 2023 at 7:24 AM Huidae Cho  wrote:

> Hi Anna,
>
> I'm not sure if these modules are "low hanging fruit" and even fairly
> parallelizable, but r.stats and r.watershed might be good candidates
> because r.stats is generic with no output rasters, and may be used a lot in
> different fields, and r.watershed calculates several important hydrologic
> rasters that are often used as input to other modules (i.e., as a first
> step for most hydrologic analyses based on my experience). Maybe,
> r.statistics as well?
>
> Since I now have access to HPC, I can help mentor him with some testing.
>
> Best,
> Huidae
>
> On Thu, Mar 30, 2023 at 9:42 AM Anna Petrášová 
> wrote:
>
>> Hi devs,
>>
>> We have a GSoC candidate who would like to do OpenMP parallelization. I
>> could mentor, anybody else is interested?
>>
>> At this point, we need to figure out (at least tentatively) which modules
>> he could work on. After Aaron's work in GSoC 2021, there are not that many
>> modules left that could be described as "low hanging fruit". Do you have
>> any suggestions?
>>
>> The proposal is due very soon.
>>
>> Thanks,
>> Anna
>>
>
>
> --
> Huidae Cho, Ph.D., GISP, /hidɛ <http://ipa-reader.xyz/?text=hid%C9%9B>
> 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

[GRASS-dev] Candidate modules for OpenMP parallelization

[Anna Petrášová]

Hi devs,

We have a GSoC candidate who would like to do OpenMP parallelization. I
could mentor, anybody else is interested?

At this point, we need to figure out (at least tentatively) which modules
he could work on. After Aaron's work in GSoC 2021, there are not that many
modules left that could be described as "low hanging fruit". Do you have
any suggestions?

The proposal is due very soon.

Thanks,
Anna
___
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.3.0

[Anna Petrášová]

On Thu, Mar 23, 2023 at 11:54 AM Ondřej Pešek 
wrote:

> čt 23. 3. 2023 v 10:53 odesílatel Markus Neteler 
> napsal:
> > - i.vi: support soil_line_slope for PVI #2561, pesekon2
>
> Merged in #2561. A follow-up update of the manual [1] is waiting for a
> review and ready to be merged.
>

Done, thanks!

>
> [1] https://github.com/OSGeo/grass/pull/2903
> ___
> 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] SIngle-Window GUI not working on Ubuntu 22.04

[Anna Petrášová]

Hi Paulo,

if you are getting the same problem, you should install the latest wxPython:

pip install -U -f
https://extras.wxpython.org/wxPython4/extras/linux/gtk3/ubuntu-22.04/
wxPython

That should fix it. The wxPython in packages may be old and not patched,
only 4.2.0 (released 2 weeks ago) has the fixes.

Anna

On Wed, Aug 17, 2022 at 9:05 AM Paulo van Breugel 
wrote:

> Dear devs,
>
> I just upgraded to the latest Ubuntu LT (22.04) and recompiled GRASS GIS.
> Unfortunately, the singe-window GUI does not work anymore.
>
> This problem was reported as a bug earlier, see
> https://github.com/OSGeo/grass/issues/2466, but I can't make the proposed
> solutions work. I wonder if this is on the radar, and if there are
> directions for a easier and more permanent solution, so we can enjoy this
> great new feature on Ubuntu as well.
>
> Cheers,
>
> Paulo
>
> ___
> 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] [GRASS-user] r.mapcalc radians vs degrees

[Anna Petrášová]

On Wed, Aug 10, 2022 at 11:20 AM Frank David  wrote:

> Hello,
>
> It seems to me that there is an error on r.mapcalc manual page. The angle
> should be entered in radians and not in degrees in the trigonometric
> functions...
>

Why do you think so? In the past I've used degrees in r.mapcalc without
problems and I don't think there was any change impacting this.

Anna


> Regards,
>
> Frank
> ___
> 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] multiprocessing problem

[Anna Petrášová]

As I said, you can sum the values for each pixel so you don't store all the
differences, that gets rid of the memory problem, but of course it will
still be slow if it's not parallelized:

vals = np.array([np.sum(np.abs(y - array.flat)) for y in array.flat])

Note that I didn't check thoroughly if the computation by itself is
correct, i.e. you get the correct value in terms of the index definition.
One other idea is to avoid some of the computations since you are in fact
computing the distances twice (distance from pixel 1 to pixel 2 and vice
versa). Also, do you actually need to compute this for the entire raster,
shouldn't this be more a moving window approach, so you would restrict the
distance computation only to a window around that pixel?

Anna

On Mon, Apr 11, 2022 at 2:09 AM Luca Delucchi  wrote:

> On Fri, 8 Apr 2022 at 16:33, Anna Petrášová  wrote:
> >
> > Hi Luca,
> >
>
> Hi Anna,
>
> > I would say the biggest problem is the memory, I tried to run it and it
> consumes way too much memory. Maybe you could process the differences from
> each pixel (compute the sum) as they are computed, not collect it and do it
> in the end. Otherwise you can significantly speed it up simply with one
> core by using numpy in a better way:
> >
> > vals = np.array([np.abs(y - array.flat) for y in array.flat])
> > ...
> > out = np.sum(vals) / number2
> >
>
> yes, this work better then my solution, but increasing the number of
> pixels I get the process killed. I have 16GB RAM and I was not able to
> process 8 cells
> I tried a few different solutions but the result is always the same.
>
> --
> ciao
> Luca
>
> www.lucadelu.org
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] multiprocessing problem

[Anna Petrášová]

Hi Luca,

I would say the biggest problem is the memory, I tried to run it and it
consumes way too much memory. Maybe you could process the differences from
each pixel (compute the sum) as they are computed, not collect it and do it
in the end. Otherwise you can significantly speed it up simply with one
core by using numpy in a better way:

vals = np.array([np.abs(y - array.flat) for y in array.flat])
...
out = np.sum(vals) / number2


On Fri, Apr 8, 2022 at 5:17 AM Stefan Blumentrath <
stefan.blumentr...@nina.no> wrote:

> Ciao Luca,
>
> Yes, you could also consider looping over e.g. rows (maybe in combination
> with "np.apply_along_axis") so you could put results easier back together
> to a map if needed at a later stage.
>
> In addition, since you use multiprocessing.Manager, you may try to use
> multiprocessing.Array:
> https://docs.python.org/3/library/multiprocessing.html#multiprocessing.Array
>
> E.g. here:
>
> https://github.com/lucadelu/grass-addons/blob/5ca56bdb8b3394ebeed23aa5b3240bf6690e51bf/src/raster/r.raoq.area/r.raoq.area.py#L81
>
> According to the post here:
> https://medium.com/analytics-vidhya/using-numpy-efficiently-between-processes-1bee17dcb01
> multiprocessing.Array is needed to put the numpy array into shared memory
> and avoid pickling.
>
> I have not tried or investigated myself, but maybe worth a try...
>
> Cheers
> Stefan
>
> -Original Message-
> From: grass-dev  On Behalf Of Luca
> Delucchi
> Sent: fredag 8. april 2022 10:46
> To: Moritz Lennert 
> Cc: GRASS-dev 
> Subject: Re: [GRASS-dev] multiprocessing problem
>
> On Fri, 8 Apr 2022 at 09:14, Moritz Lennert 
> wrote:
> >
> > Hi Luca,
> >
>
> Hi Moritz,
>
> > 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 ?
> >
>
> right now I creating a worker for each pixel to be checked against all the
> other pixels, yes it could be and idea to send larger chunks, I could split
> the array vertically according to the number of processor
>
> > - 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.
> >
>
> ok, this make sense
> thanks for your support
>
> > Moritz
> >
>
> --
> ciao
> Luca
>
>
> https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.lucadelu.org%2Fdata=04%7C01%7CStefan.Blumentrath%40nina.no%7C8821ac9b35674720f9b908da193c3cab%7C6cef373021314901831055b3abf02c73%7C0%7C0%7C637850043869911903%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=xt8x5QeXm3h1eJIYq9aRbBMHAWXaaYAI9yYNqKMj3mg%3Dreserved=0
> ___
> 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%7CStefan.Blumentrath%40nina.no%7C8821ac9b35674720f9b908da193c3cab%7C6cef373021314901831055b3abf02c73%7C0%7C0%7C637850043869911903%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=5Dd9Az3ZqLwd5wS7A9dM5jJz8boqwE3%2FPJFBK8texCQ%3Dreserved=0
> ___
> 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] Addons for windows not being updated

[Anna Petrášová]

Hi Martin,

I just noticed a change in r.sample.category addon 2 weeks ago [1] is not
in the zip [2] for 8.1.dev although the file has the most recent timestamp.
The log [3] looks fine. Didn't check other addons.

Anna

[1]
https://github.com/OSGeo/grass-addons/commit/140fd6e5ae693dafc87d006a3e419e0be4599754
[2]
https://wingrass.fsv.cvut.cz/grass81/addons/grass-8.1.dev/r.sample.category.zip
[3]
https://wingrass.fsv.cvut.cz/grass81/addons/grass-8.1.dev/logs/r.sample.category.log
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Replace GNU Indent with ClangFormat?

[Anna Petrášová]

+1

On Ubuntu 20.04 LTS, there is ClangFormat 12, I suppose there will be 13 in
the upcoming 22.04 release.

Anna

On Mon, Mar 21, 2022 at 10:01 AM Nicklas Larsson via grass-dev <
grass-dev@lists.osgeo.org> wrote:

> Formatting the C and C++ code, making a consistent coding style was
> proposed for G8 [1]. Unfortunately, it didn't make it. There were attempts
> to do this [2, 3], but numerous problem arose using `util/grass_indent.sh`
> and its batch script `util/grass_indent_ALL.sh`, which are based on GNU
> Indent [4]. These problem are probably originate in the comparatively
> limited functionality and lack of active development on GNU Indent.
>
> I just filed a PR [5] with the aim to replace GNU Indent with ClangFormat
> [6] and later (separately!) make a bulk formatting of all the code. Running
> clang-format on all *.h|*.c|*.cpp (some 3000+) files goes fine without any
> issues. I have created a `.clang-format` file with the settings as close as
> possible to the ones in `grass_indent.sh` (somewhat outdated described in
> [7]).
>
> ClangFormat is a working program in active development, therefore its
> performance is version dependent (similar to what we have had with Black
> for Python). On the other hand, its adaptation is increasing, now used in
> several big and small projects.
>
>
> Now the question is first of all: is using ClangFormat something the GRASS
> dev community (you) would want or could live with for this project?
> And if so, what version of ClangFormat should then be the starting point
> (what do you have reasonably easy available for your dev platform)? The
> present settings in the PR are derived from ClangFormat 13, but could
> possibly be back ported if really needed.
>
> Please check out the settings, as well as some code files formatted for
> illustrational purposes only, at the PR [5].
>
>
> Best,
> Nicklas
>
>
>
> [1]
> https://trac.osgeo.org/grass/wiki/Grass8Planning#Codeorganisationcodingstyles
> [2] https://github.com/OSGeo/grass/issues/1630
> [3] https://github.com/OSGeo/grass/pull/2270
> [4] https://www.gnu.org/software/indent/
> [5] https://github.com/OSGeo/grass/pull/2272
> [6] https://clang.llvm.org/docs/ClangFormat.html
> [7] https://trac.osgeo.org/grass/wiki/Submitting/C#Indentation
>
> ___
> 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] GSoC 2022

[Anna Petrášová]

Hi devs,

just a reminder, now is the time to update GSoC 2022 ideas page:
https://trac.osgeo.org/grass/wiki/GSoC/2022

So in case you would like to suggest a topic or sign-up as a (co)mentor,
please edit it within the next couple of weeks.

Note, this year GSoC is open to anybody (not just students) who is a
newcomer to open source development, so if you know somebody who could
benefit from this new rule, please let them know.

Best,
Anna
___
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.7

[Anna Petrášová]

On Wed, Dec 22, 2021 at 2:32 PM Markus Neteler  wrote:

> Hi devs,
>
> Some important fixes (incl. GUI related) have accumulated:
> https://github.com/OSGeo/grass/milestone/7?closed=1
>
> The still open ones we may bump to 7.8.8, if no objections:
> https://github.com/OSGeo/grass/milestone/7
> %3Aopen+is%3Aissue+label%3Ablocker+milestone%3A8.0.0
>
> except for (any volunteers to complete it?):
> "tgis db version mismatch: promote t.downgrade #2002"
>  https://github.com/OSGeo/grass/pull/2002
>
> Hence I would suggest that I create the 7.8.70RC1 by tomorrow.
>
> Any objections?
>

Given the problems with Python 3.10, it may be better to test that first
and fix at least the major problems. Most of these fixes are very simple
(integer needs to passed to a wx object instead of float). I can't easily
test at this point, but will try to fix any identified issues as soon as
possible.

Anna

>
> Best,
> Markus
>
> --
> Markus Neteler, PhD
> https://www.mundialis.de - free data with free software
> https://grass.osgeo.org
> https://courses.neteler.org/blog
> ___
> 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] Move r.stream* family of addon modules to core?

[Anna Petrášová]

See also https://trac.osgeo.org/grass/ticket/2237

I think there were some other concerns, other devs might know more. They
probably don't have tests, some code clean up needed etc. On the other
hand, it may be worth moving it now to core and then solve those issues.
Won't get into 8.0, but 8.2 may be more realistic.

Anna

On Tue, Nov 30, 2021 at 1:58 PM Robert Lagacé 
wrote:

> Thank you for the suggestion. I wanted to do it and I am glad that you
> propose it.
>
> It will make the life easier for the students and the non GIS users and it
> will help to promote GRASS for hydrology and river analysis.
> The installation of addons is problematic for students in my classes.
> Probbably we will need to identify the addons necessary for hydrology.
>
> One other possibility is to package groups of addons by interest.
>
> Thanks,
>
> Le 2021-11-30 à 11 h 33, Brendan a écrit :
>
> I was wondering if it might be time to move the r.stream family of modules
> from addons to core? Perhaps for the GRASS 8 release? They are an important
> part of GRASS's hydrology tools. While r.stream.extract is already a core
> module, others like r.stream.distance are still addons. Why keep so much
> potential hidden in addons? Do some of the modules need work? On a side
> note, only core modules show up as QGIS processing algorithms. Just a
> thought.
> Best, Brendan
>
> ___
> grass-dev mailing 
> listgrass-dev@lists.osgeo.orghttps://lists.osgeo.org/mailman/listinfo/grass-dev
>
>
> --
> ---
> Robert Lagacé, ing., agr., prof.titulaire
> Département de SGA
> 2425 de l'agriculture
> Université Laval
> Québec, Québec, G1V 0A6
> courriel : robert.lag...@fsaa.ulaval.ca 
> 
> tél: (418)-656-2131 poste 402276
> fax : (418)-656-3723
>
> ___
> 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] 78 manuals down

[Anna Petrášová]

Hi,

seems manual pages for 78 are not working right now:
https://grass.osgeo.org/grass78/manuals/index.html

Any idea why?

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

Re: [GRASS-dev] nc_spm_08_grass8?

[Anna Petrášová]

Hi Vero, Maris,

thanks for responding! This is concerning, I personally don't work a lot
with remote sensing data and temporal stuff, but it seems to be delaying
GRASS 8 release.

On Thu, Sep 9, 2021 at 4:46 AM Maris Nartiss  wrote:

> Hello Anna, Veronica.
>
> 2021-09-08 23:09 GMT+03:00, Veronica Andreo :
> > Hi Anna, all
> >
> > Good point! Thanks for raising this!
> >
> > Seems we are all trying to better understand band references and how they
> > integrate with existing functionality :)
>
> Band reference usage in the context of classification of imagery is
> explained in a scheme in the most recent GRASS 8 feature presentation:
> https://veroandreo.github.io/grass-gis-talks/wageningen2021.htmlmuch#/4/6
> 
>
> > In
> > https://github.com/OSGeo/grass/pull/1844/ we discuss temporal framework
> and
> > band references.
>
> I can not comment on band references in t.* modules as I do not
> understand their role there. Some changes might be needed there.
>
> > Indeed, we have a problem if all examples using Landsat will stop working
> > in grass 8, so if this is the case, then we might need a new version of
> the
> > sample data which by the way might also include the MODIS LST mapset (~10
> > Mb) to do some time series stuff.
>
> A new version of sample dataset would be good. Still existing version
> also works OK as long as you do an extra step of assigning band
> references at the first time. You'll find usage examples in manual
> pages of i.cluster with following in i.maxlik; and a full example in
> i.smap.
>
>
> https://github.com/OSGeo/grass/blob/main/imagery/i.cluster/i.cluster.html#L265
> https://github.com/OSGeo/grass/blob/main/imagery/i.maxlik/i.maxlik.html
> https://github.com/OSGeo/grass/blob/main/imagery/i.smap/i.smap.html#L144
>


> > In my opinion, band reference should be something optional, no?
>
> They are optional as long as you are not using i.maxlik or i.smap or
> i.svm.predict (and respective signature generation modules for them).
> Can't comment on t.* modules.
>
>
So in that case it seems we need a new version, which would at least have
the
band references assigned. Since you only assign them from the actual mapset,
the current dataset is more difficult to use for any classification
examples.
E.g. this would be confusing in a workshop.
I think sample data should be ready to be used. It seems the assigned band
references are ignored in 7.8 and
everything works (is that right, Maris?), so we could just update the
current dataset as a quick fix.
Adding more data would be certainly valuable, but the whole dataset would
deserve update.
Then also the dataset has grass7 in the name...


> > On the
> > other hand, I think I understood from Maris that with r.support we could
> > add band references and that the restrictions were relaxed but these
> > changes are not yet documented. There's this thread:
> > https://lists.osgeo.org/pipermail/grass-dev/2021-September/095377.html
>
> Band reference rules are relaxed and now any word can be a band
> reference as long as its length does not exceed GNAME_MAX and its
> symbol set is limited to a-Z 0-9 and "-", "_".
> https://github.com/OSGeo/grass/blob/main/lib/raster/raster_metadata.c#L149
> Can not comment on t.* modules as they are bypassing C library and
> doing some magick in Python instead of fully integrating with the rest
> of GRASS.
>
> It is pity that the PR relaxing band reference requirements got merged
> although it didn't change the documentation to reflect changes in the
> code. It is my fault as I wasn't fast enough to stop Markus Metz from
> merging without required changes. I hope Markus M. will fix his
> blunder and provide changes also to the documentation to reflect
> changes in the code made by him.
> https://github.com/OSGeo/grass/pull/1796


I cc'ed Markus.

>
>
> > Band references need some further discussion IMHO
>

+1

>
> Harmonization of t.* Python based band reference handling with C
> library based one should be done by someone who completely understands
> the Python part in t.* (as an idea and not only code). As
> functionality is required in both C and Python code, C has precedence
> over Python (functionality in C + wrapper functions for Python or just
> plain ctypes as it is done in tests).
>
> From the i.* module point of view, modules g.bands and i.bands are not
> required and are not used at all. Besides i.bands is a bad module name
> as bands are assigned to rasters and not groups thus it should be
> r.bands but the management functionality is already covered with
> r.support leaving only printing for i.bands without an alternative. I
> would drop i.bands completely unless it is completely reworked.
> g.bands is a nice idea but, unless someone implements editing part, it
> is of limited use.


> > my 2 cents
> > Vero
>
> Māris.
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org

[GRASS-dev] nc_spm_08_grass8?

[Anna Petrášová]

Hi devs,

given the changes with bands (which I still don't fully understand) do we
need to have a new sample dataset, in which the landsat scenes have bands?
Context: I was playing with basic classification examples (g.gui.iclass,
i.gensigset) and apparently it doesn't work and it's giving me error:

Raster map  lacks band reference

So my questions are:

1. Is that expected behavior? Seems little strict to me.
2. If yes, then what do I do when working with other data than Landsat,
Sentinel, etc - g.bands doesn't currently support user-defined references.
3. Also, if yes, do we need a sample dataset for GRASS8 then? Otherwise any
examples with landsat fail.

Sorry if I misunderstood anything.

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

Re: [GRASS-dev] No more compiler warnings

[Anna Petrášová]

That's great, thank you and others involved for working on this, it is an
impressive amount of work!

Anna

On Thu, Aug 26, 2021 at 4:22 PM Nicklas Larsson via grass-dev <
grass-dev@lists.osgeo.org> wrote:

> Hi all!
>
> At the beginning of this year, compiling GRASS raised a very high number
> of compiler warnings. For example with GCC there were about 140 and with
> Clang about 300 warnings. This was reported with GitHub issue #1247 [1].
> Since then these warnings has been addressed in a number of PRs. Today we
> have reached the point where there are no warnings at all (!) for either
> GCC and Clang (with default settings) on the main branch.
>
> To keep this level of warning frequency to zero, the compiler flag -Werror
> has been added to the GitHub "GCC C/C++ standards check" CI builds. This
> will treat a compiler warning as an error, and will cause the build to fail.
>
> For those who have a PR in the pipeline affecting C or C++ code, should
> consider making a rebase to main (or otherwise trigger a CI check) before
> merging.
>
> Cheers,
> Nicklas
>
>
> [1] https://github.com/OSGeo/grass/issues/1247
> ___
> 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] GRASS 7.8.5 compile errors

[Anna Petrášová]

On Tue, Aug 10, 2021 at 10:06 AM Thomas Adams  wrote:

> Hi all!
>
> I just upgraded from Ubuntu 18.04 to 20.04 and have to re-compile/install
> GRASS 7.8.5. I'm getting these errors:
>
> Errors in:
> /home/teaiii/grass-7.8.5/lib/python/ctypes
> /home/teaiii/grass-7.8.5/vector/v.out.ogr
> /home/teaiii/grass-7.8.5/man
>

What are the actual errors when you go in the directories and run make?

>
> I'm sure I have created some library incompatibilities, so I'm trying to
> identify where the problems are. I know I have python 3.8 installed, but
> when I run python -V I get:
>
> Python 2.7.18
>
> Do I need to compile against python 3.8; if so, how do I do that?
>
> My configure looks like this:
>
> CFLAGS="-O2 -Wall" LDFLAGS="-s" ./configure \
> --enable-64bit \
> --with-cxx \
> --enable-largefile=yes \
> --with-nls \
> --with-readline \
> --with-pthread \
> --with-gdal=/usr/local/bin/gdal-config \
> --with-proj --with-proj-share=/usr/local/share/proj \
> --with-proj-includes=/usr/local/include \
> --with-proj-libs=/usr/local/lib \
> --with-geos=/usr/local/bin/geos-config \
> --with-wxwidgets=/usr/local/bin/wx-config \
> --with-cairo \
> --with-opengl-libs=/usr/include/GL \
> --with-freetype=yes \
> --with-freetype-includes=/usr/include/freetype2/ \
> --with-postgres=yes \
> --with-postgres-includes=/usr/local/include \
> --with-sqlite=yes \
> --with-mysql=yes \
> --with-mysql-includes=/usr/include/mysql \
> --with-odbc=no \
> --with-blas \
> --with-lapack \
> --with-liblas=yes \
> --with-liblas-config=/usr/bin/liblas-config \
> --with-netcdf=/usr/local/bin/nc-config \
> --with-blas-libs=/usr/local/lib \
> --with-lapack-includes=/usr/include \
> --with-lapack-libs=/usr/lib \
> --with-blas-includes=/usr/local/include \
> --with-zstd \
> --with-zstd-includes=/usr/local/include \
> --with-zstd-libs=/usr/local/lib
>
> with no errors.
>
> Any/all suggestions are appreciated...
>
> Regards,
> Tom
>
> --
>
> ___
> 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] r.to.rast3 error messages

[Anna Petrášová]

On Mon, Jul 19, 2021 at 5:16 AM Paulo van Breugel 
wrote:

>
>
> On Mon, Jul 19, 2021 at 4:14 AM Anna Petrášová 
> wrote:
>
>>
>>
>> On Sun, Jul 18, 2021 at 5:57 AM Paulo van Breugel 
>> wrote:
>>
>>> Hi devs,
>>>
>>> When running r.to.rast3 with as input two integer maps:
>>>
>>> r.to.rast3 input=soc_0_5cm_mean,soc_5_15cm_mean output=test
>>>
>>> I am getting the following two warnings:
>>>
>>> WARNING: G__open_misc(read): Unable to open
>>> '/home/paulo/grassdb/Schijndel/soils/cell_misc/soc_5_15cm_mean/nullcmpr':
>>> Too many open files
>>> WARNING: G__open(read): Unable to open
>>> '/home/paulo/grassdb/Schijndel/soils/cellhd/soc_5_15cm_mean': Too many open
>>> files
>>>
>>> and the error message:
>>>
>>> ERROR: Error reading reclass file for raster map 
>>>
>>> I am really not sure what these messages are about. The warning messages
>>> do not seem to make sense, I am only using two files as input. I do not
>>> understand the error message either, or what the reclass is referring to.
>>>
>>> Any idea, is this a bug I should report, or something I am doing wrong?
>>>
>>
>> Any chance you are running something else at the same time? Generally,
>> there is a limit on the number of open files (see e.g. r.series man page).
>>
>
> I thought of that, but the same error occurred after running the function
> as first thing after restarting grass gis.
>

It could be influenced by other processes apart from GRASS, the limit is
not per program but per user (I think). Sorry, no better idea here.

>
>
>>
>>> Mvg.
>>>
>>> Paulo
>>>
>>>
>>> ___
>>> 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] r.to.rast3 error messages

[Anna Petrášová]

On Sun, Jul 18, 2021 at 5:57 AM Paulo van Breugel 
wrote:

> Hi devs,
>
> When running r.to.rast3 with as input two integer maps:
>
> r.to.rast3 input=soc_0_5cm_mean,soc_5_15cm_mean output=test
>
> I am getting the following two warnings:
>
> WARNING: G__open_misc(read): Unable to open
> '/home/paulo/grassdb/Schijndel/soils/cell_misc/soc_5_15cm_mean/nullcmpr':
> Too many open files
> WARNING: G__open(read): Unable to open
> '/home/paulo/grassdb/Schijndel/soils/cellhd/soc_5_15cm_mean': Too many open
> files
>
> and the error message:
>
> ERROR: Error reading reclass file for raster map 
>
> I am really not sure what these messages are about. The warning messages
> do not seem to make sense, I am only using two files as input. I do not
> understand the error message either, or what the reclass is referring to.
>
> Any idea, is this a bug I should report, or something I am doing wrong?
>

Any chance you are running something else at the same time? Generally,
there is a limit on the number of open files (see e.g. r.series man page).


> Mvg.
>
> Paulo
>
>
> ___
> 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 8: create new release branch

[Anna Petrášová]

Hi Markus and all,

was there a plan to release G8 from the previewbranch or are we branching
out? I am fine with either, we can always cherrypick the fixes since
branching previewbranch. I would like to soon merge changes from GSoC that
shouldn't go into release. We could also wait for the g.extension fixes and
then create the branch to minimize work.

Anna

On Sun, Jun 6, 2021 at 2:41 AM Markus Neteler  wrote:

> Hi all,
>
> The new 8.0.0alpha preview branch is ready:
>
> https://github.com/OSGeo/grass/tree/previewbranch_8_0
>
> Best,
> 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

Re: [GRASS-dev] Fwd: [OSGeo-Discuss] [FOSS4G] OSGeo Projects swag

[Anna Petrášová]

Hi,

what I think would be actually useful would be a GRASS cheatsheet,
something like this:
https://pandas.pydata.org/Pandas_Cheat_Sheet.pdf
That is obviously a lot of work, but maybe we could put together something
much simpler, at least for this occasion.

Anna


On Wed, Jul 7, 2021 at 10:04 AM Veronica Andreo 
wrote:

> hihihi
>
> I like Maris suggestion, sounds funny :)
>
> I also thought/recalled of a beautifully handcrafted grass logo that
> looked like a sticker made by Vaclav not so long ago. See:
> https://twitter.com/vaclavpetras/status/1359972415233789952/photo/1. We
> could offer it as a virtual sticker if Vashek agrees and kindly donates it,
> of course!
>
> A link to try GRASS online could also be something nice to promote and our
> twitter handle (which reached 3k followers today!)
>
> Vero
>
> El mié, 7 jul 2021 a las 9:02, Maris Nartiss ()
> escribió:
>
>> 2021-07-06 11:50 GMT+03:00, Luca Delucchi :
>> > Hi devs,
>> >
>> > Does anyone have any ideas?
>> >
>>
>> Tired of your lawn looking like a mess? Check out best gardening tips
>> at https://grass.osgeo.org
>>
>> GRASS – taking care of lawns since 1982.
>>
>>
>> Designing an advertisement around logo I leave to more skill full artists.
>> Māris.
>> ___
>> 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

Re: [GRASS-dev] ParallelModuleQueue freezes...

[Anna Petrášová]

On Fri, May 28, 2021 at 10:02 AM Stefan Blumentrath <
stefan.blumentr...@nina.no> wrote:

> Some more context.
> The t.rast.neighbors test seems to work with the current dev version
> "2048e1016" from 2021-05-19T09:38:49+00:00
> It fails however, with 7.8.5 from 2020-12-22T15:55:09+00:00 and an older
> development version "35edbf7dc"
> from 2020-06-03T16:03:52+00:00
>
> So, maybe one or more of the recent changes need backporting?
>
> https://github.com/OSGeo/grass/commits/master/python/grass/pygrass/modules/interface/module.py


This one:
https://github.com/OSGeo/grass/pull/1407

The reason I didn't backport it was there has been a small change in API
to make it work. But Python3 support is probably a good reason to backport
it.


>
>
> In the 7_8 release branch, the latest change is from May 2019:
>
> https://github.com/OSGeo/grass/commits/releasebranch_7_8/lib/python/pygrass/modules/interface/module.py
>
> Hope that helps identifying a solution?
>
> Cheers
> Stefan
>
> -Original Message-
> From: Stefan Blumentrath 
> Sent: torsdag 27. mai 2021 23:09
> To: Stefan Blumentrath ; Luca Delucchi <
> lucadel...@gmail.com>; Anna Petrášová 
> Cc: GRASS developers list 
> Subject: RE: [GRASS-dev] ParallelModuleQueue freezes...
>
> See:
>
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FOSGeo%2Fgrass%2Fpull%2F1600data=04%7C01%7C%7Cc5fe909715a647431c9308d92153b445%7C6cef373021314901831055b3abf02c73%7C0%7C0%7C637577465653048701%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=5yfxG5gjlYlzgJn6yTP9zbUk7GE1JdcYPxWIQFwUK%2Fo%3Dreserved=0
> Please test.
> Unittests for t.rast.neighbors should work again with this small change...
>
> -----Original Message-
> From: grass-dev  On Behalf Of Stefan
> Blumentrath
> Sent: torsdag 27. mai 2021 08:19
> To: Luca Delucchi ; Anna Petrášová <
> kratocha...@gmail.com>
> Cc: GRASS developers list 
> Subject: Re: [GRASS-dev] ParallelModuleQueue freezes...
>
> The combination ParallelModuleQueue and MultiModule is used in
> t.rast.neighbors:
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FOSGeo%2Fgrass%2Fblob%2Fmaster%2Ftemporal%2Ft.rast.neighbors%2Ft.rast.neighbors.pydata=04%7C01%7C%7Cc5fe909715a647431c9308d92153b445%7C6cef373021314901831055b3abf02c73%7C0%7C0%7C637577465653048701%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=5QyN%2FR1cXgoWWGS2lgjKi8%2BeLX77w37bfMQzcP6O4bM%3Dreserved=0
>
> The testsuite of that module is deactivated for Python > 2.
>
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FOSGeo%2Fgrass%2Fblob%2Fmaster%2Ftemporal%2Ft.rast.neighbors%2Ftestsuite%2Ftest_neighbors.pydata=04%7C01%7C%7Cc5fe909715a647431c9308d92153b445%7C6cef373021314901831055b3abf02c73%7C0%7C0%7C637577465653048701%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=nQTdDIGmefI6F37zdjhyMDBYUrIxVaC%2FiA5FzeUK2KU%3Dreserved=0
>
> If you activate it by commenting out line 15. You will see the behavior...
>
> Thanks for looking into this!
>
> Cheers
> Stefan
>
>
> -Original Message-
> From: Luca Delucchi 
> Sent: torsdag 27. mai 2021 06:07
> To: Anna Petrášová 
> Cc: Stefan Blumentrath ; GRASS developers
> list 
> Subject: Re: [GRASS-dev] ParallelModuleQueue freezes...
>
> On Thu, 27 May 2021 at 04:07, Anna Petrášová 
> wrote:
> >
> > Could you provide an example that is failing? The doctests are running
> for me. I spent some time fixing it a couple months ago. I use Python 3.6,
> I wonder if newer Python would cause some issues.
> >
>
>
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FOSGeo%2Fgrass-addons%2Fpull%2F523%2Ffilesdata=04%7C01%7C%7Cc5fe909715a647431c9308d92153b445%7C6cef373021314901831055b3abf02c73%7C0%7C0%7C637577465653048701%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=KT5h55J89LLXhK7uEujAmIwfksjPGyXEy2u7gYIc2Ns%3Dreserved=0
> line 544, the commented lines are not working for me..
> If you want to try t.vi just comment line 543 and uncomment the following
> lines..
>
> > Anna
> >
>
> --
> ciao
> Luca
>
>
> https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.lucadelu.org%2Fdata=04%7C01%7C%7Cc5fe909715a647431c9308d92153b445%7C6cef373021314901831055b3abf02c73%7C0%7C0%7C637577465653048701%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=hM8CpSgjw7SFjGKxM9SFfWI3G8U3nr8eeCqedZORdso%3Dreserved=0
> ___

Re: [GRASS-dev] ParallelModuleQueue freezes...

[Anna Petrášová]

Which Python do you have? The test is running just fine for me with 3.6.

On Thu, May 27, 2021 at 2:19 AM Stefan Blumentrath <
stefan.blumentr...@nina.no> wrote:

> The combination ParallelModuleQueue and MultiModule is used in
> t.rast.neighbors:
> https://github.com/OSGeo/grass/blob/master/temporal/t.rast.neighbors/t.rast.neighbors.py
>
> The testsuite of that module is deactivated for Python > 2.
>
> https://github.com/OSGeo/grass/blob/master/temporal/t.rast.neighbors/testsuite/test_neighbors.py
>
> If you activate it by commenting out line 15. You will see the behavior...
>
> Thanks for looking into this!
>
> Cheers
> Stefan
>
>
> -Original Message-
> From: Luca Delucchi 
> Sent: torsdag 27. mai 2021 06:07
> To: Anna Petrášová 
> Cc: Stefan Blumentrath ; GRASS developers
> list 
> Subject: Re: [GRASS-dev] ParallelModuleQueue freezes...
>
> On Thu, 27 May 2021 at 04:07, Anna Petrášová 
> wrote:
> >
> > Could you provide an example that is failing? The doctests are running
> for me. I spent some time fixing it a couple months ago. I use Python 3.6,
> I wonder if newer Python would cause some issues.
> >
>
>
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FOSGeo%2Fgrass-addons%2Fpull%2F523%2Ffilesdata=04%7C01%7C%7Cb35d171402fc441dfd7508d920c4edc3%7C6cef373021314901831055b3abf02c73%7C0%7C0%7C637576852445926368%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=a8JVAn3N77HwODX5FguDQjxI4PbUbkN4ZicO4RYuHqo%3Dreserved=0
> line 544, the commented lines are not working for me..
> If you want to try t.vi just comment line 543 and uncomment the following
> lines..
>
> > Anna
> >
>
> --
> ciao
> Luca
>
>
> https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.lucadelu.org%2Fdata=04%7C01%7C%7Cb35d171402fc441dfd7508d920c4edc3%7C6cef373021314901831055b3abf02c73%7C0%7C0%7C637576852445936369%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=RWkoI4e%2BbY9%2F5Ow%2BOMqPtEgHGS2BqWRL4pes%2B%2B5T%2BNA%3Dreserved=0
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Meet GSoC students

[Anna Petrášová]

Hi devs,

If anybody is interested to meet new GSoC students, say hello or ask some
questions regarding their projects, we plan to have a call on Friday May
28th 9am EDT (3pm CEST, 13 UTC [1]), I will send the zoom link just before
the event.

Anna

[1]
https://www.timeanddate.com/worldclock/meetingdetails.html?year=2021=5=28=13=0=0=207=236=204
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] ParallelModuleQueue freezes...

[Anna Petrášová]

Could you provide an example that is failing? The doctests are running for
me. I spent some time fixing it a couple months ago. I use Python 3.6, I
wonder if newer Python would cause some issues.

Anna

On Tue, May 25, 2021 at 8:33 AM Stefan Blumentrath <
stefan.blumentr...@nina.no> wrote:

> Dear devs,
>
>
>
> Currently, I am trying to run a combination of ParallelModuleQueue and
> MultiModule as described here in GRASS 7.8:
>
>
> https://grass.osgeo.org/grass79/manuals/libpython/pygrass.modules.interface.html?highlight=parallel%20module%20qu#pygrass.modules.interface.module.ParallelModuleQueue
>
>
>
> It seems – in contrast to the documentation - also the finish_= parameter
> needs to be set to True for the modules to run.
>
>
>
> However, after finishing the queue, the script stalls and does not seem to
> get over queue.wait().
>
> Just to be clear, also the code from the doc does not seem to work for me…
>
>
>
> Any ideas?
>
>
>
> Cheers,
>
> Stefan
> ___
> 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] GSoC welcome

[Anna Petrášová]

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

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

[Anna Petrášová]

On Tue, Apr 13, 2021 at 8:22 AM Markus Neteler  wrote:

> (moved back into email thread)
>
> On Mon, Apr 12, 2021 at 9:16 PM Helmut Kudrnovsky  wrote:
> > > Markus:
> > >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?
> >
> > winGRASS g.extension is failing for some of the addons where some
> encoding issues pops up.
> >
> > but see https://github.com/OSGeo/grass/pull/1496#issuecomment-812447963
> >
> > >manually set PYTHONUTF8 in C:\OSGeo4W64\apps\grass\grass79\etc\env.bat
> > >
> > >[...]
> > >set PYTHONUTF8=1
> > >set GRASS_PYTHON=%OSGEO4W_ROOT%\bin\python3.exe
> > >[...]
> > >
> > >then
> > >
> > >   g.extension extension=i.fusion.hpf
> > >   Downloading precompiled GRASS Addons ...
> > >   Fetching  from <
> http://wingrass.fsv.cvut.cz/grass79/x86_64/addons/grass-7.9.dev/i.fusion.hpf.zip>
> (be patient)...
> > >   Updating extensions metadata file...
> > >   Updating extension modules metadata file...
> > >   WARNING: No metadata available for module 'constants'.
> > >   WARNING: No metadata available for module 'high_pass_filter'.
> > >   ERROR: Unable to read manual page: [Errno 2] No such file or
> directory:
> 'C:\\Users\\youruser\\AppData\\Roaming\\GRASS7\\addons\\docs\\html\\constants.html'
>
> Well, does the file exist?
>
> > >at least no fileinput.FileInput error anymore
> >
> > g.extension works then with these encoding issue addons
> >
> > this is based upon
> https://docs.python.org/3/using/windows.html#utf-8-mode
> >
> > > Windows still uses legacy encodings for the system encoding (the ANSI
> Code Page). Python uses it for the default encoding of text files (e.g.
> locale.getpreferredencoding()).
> > >
> > > This may cause issues because UTF-8 is widely used on the internet and
> most Unix systems, including WSL (Windows Subsystem for Linux).
> > >
> > > You can use UTF-8 mode to change the default text encoding to UTF-8.
> >
> > I've tested a bit locally, g.extension works then (beside
> https://github.com/OSGeo/grass/issues/1499 , though that's a minor issue
> as all nested addons and helper libs are working, just a nasty warning );
> (localized) GUI is mostly working.
> >
> > though I have no idea if there are any possible side effects with set
> PYTHONUTF8=1 
> >
> > maybe Anna, Maris have some ideas?
>

Honestly this discussion is hard to follow, I would have to dive more in...
I think PYTHONUTF8=1 is fine, there may be a few issues, but probably worth
it.


>
> Unfortunately I don't...
>
> > should we activate it in master and see what CI test are reporting?
>
> Might be an option to find out.
>
> > kind regards
> > Helmut
>
> ciao,
> 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

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

[Anna Petrášová]

On Tue, Mar 16, 2021 at 8:55 AM Moritz Lennert 
wrote:

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

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


> 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
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Fwd: [OSGeo-Discuss] GSoC 2021: OSGeo Accepted as Mentor Organization!

[Anna Petrášová]

Good news, OSGeo has been accepted!

-- Forwarded message -
From: Rajat Shinde 
Date: Wed, Mar 10, 2021 at 12:59 AM
Subject: [OSGeo-Discuss] GSoC 2021: OSGeo Accepted as Mentor Organization!
To: OSGeo Discussions , OSGeo-SoC <
s...@lists.osgeo.org>, 
Cc: gsoc-adminosgeo.org , 


Dear All,

We are delighted to share that OSGeo has been accepted as one of the
mentoring organizations for the Google Summer of Code 2021. This will be
our 15th year participating as a mentoring organization starting 2007
onwards (Congratulations to all of us, this is indeed a great achievement).

The list of accepted organizations is at [0].
Our OSGeo GSoC 2021 application is available at [1].

Please note the Student Application Period opens *March 29 - April 13,
2021, 18:00 UTC*.
Students interested in participating with OSGeo are recommended to start
discussing the application ideas [2] with the OSGeo mentoring projects.
They shall register and submit their applications beginning March 29 till
April 13, 2021. All proposals must be submitted before the deadline of
April 13, 2021, 18:00 UTC.

We still have time for more projects to participate with ideas [2].
It is an amazing opportunity to:

   - Add functionality to your projects.
   - Attract more contributors participating in the projects; sometimes
   they become long-term contributors. :)

If you wish to participate, please send your project ideas list to us at
the gsoc-admin (AT) osgeo (DOT) org.
OSGeo projects, Incubating projects, and Community projects are welcome.

Stay tuned for further instructions on the next steps, and let us be
prepared for another geospatial GSoC with OSGeo!

Yours,
OSGeo GSoC Admins Team

[0] https://summerofcode.withgoogle.com/organizations/
[1] https://wiki.osgeo.org/wiki/Google_Summer_of_Code_Application_2021
[2] https://wiki.osgeo.org/wiki/Google_Summer_of_Code_2021_Ideas
___
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] [GRASS-PSC] Min. req. of programming language standard support, GRASS GIS 8

[Anna Petrášová]

On Fri, Feb 26, 2021 at 1:45 PM 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?
>
> Have a nice weekend :)
> Vero
>

Regarding Python support, I thought we could add more specific rules for
updating it, since that will happen fairly often. E.g. "For a new release
of a minor GRASS version, the Python minimum version should be raised if
the current minimum Python version reaches end of life or there are any
important technical reasons."
Once we need to update the min version (next year I suppose), would this
RFC be updated? I guess I am unsure if the RFC is supposed to work.

Anna

>
> El mar, 16 feb 2021 a las 15:36, Nicklas Larsson via grass-psc (<
> grass-...@lists.osgeo.org>) escribió:
>
>> I added the RFC draft to GRASS Wiki [1].
>>
>> Well, it's only a draft, so any thoughts, modifications, additions are
>> most welcome!
>>
>> Nicklas
>>
>>
>> [1] https://trac.osgeo.org/grass/wiki/RFC/7_LanguageStandardsSupport
>>
>>
>>
>> On Thursday, 11 February 2021, 14:34:44 CET, Moritz Lennert <
>> mlenn...@club.worldonline.be> wrote:
>>
>>
>>
>>
>> Am 11. Februar 2021 13:29:10 MEZ schrieb Nicklas Larsson <
>> n_lars...@yahoo.com>:
>> > 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 <
>> mlenn...@club.worldonline.be> 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-psc mailing list
>> grass-...@lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/grass-psc
>>
> ___
> 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] Need a mentor for GSoC parallelization topic

[Anna Petrášová]

On Thu, Feb 18, 2021 at 2:35 AM Maris Nartiss  wrote:

> 2021-02-17 18:28 GMT+02:00, Anna Petrášová :
> >
> > we need a co-mentor and ideally it wouldn't be me, since I
> > may be a mentor elsewhere.
>
> I don't have experience with OpenMP (yet), but if nobody more skilled
> steps up, I could be a co-mentor. I already filled the contact form
> and added myself (with a ? mark) in the wiki.
>

Great, thanks Maris!


> > Thanks again!
> > Anna
>
> Māris.
>
___
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

[Anna Petrášová]

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] Need a mentor for GSoC parallelization topic

[Anna Petrášová]

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
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

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

[Anna Petrášová]

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
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Fwd: [OSGeo-Discuss] [OSGeo @ GSoC 2021] Call for Projects to Prepare Project Ideas Page for Google Summer of Code 2021

[Anna Petrášová]

For potential GSoC (co)mentors, please fill out the form below:
https://forms.gle/9Na1vzGX3ESxqgpj9

-- Forwarded message -
From: Rajat Shinde 
Date: Thu, Feb 11, 2021 at 3:33 AM
Subject: Re: [OSGeo-Discuss] [OSGeo @ GSoC 2021] Call for Projects to
Prepare Project Ideas Page for Google Summer of Code 2021
To: Anna Petrášová 
Cc: gsoc-adminosgeo.org , GRASS-dev <
grass-dev@lists.osgeo.org>


Dear Anna,

Thanks for your email and also for updating the ideas page, we really
appreciate it. :)
We will surely add the GRASS GIS ideas page to the OSGeo GSoC 2021 Ideas
page soon.

Meanwhile, it's a humble request for all GRASS Mentors to fill the GSoC
2021 mentor's contact information form (https://forms.gle/9Na1vzGX3ESxqgpj9)
so that we can have the necessary information.

Thanks!
Kind regards,
OSGeo GSoC Admins

On Wed, Feb 10, 2021 at 9:14 AM Anna Petrášová 
wrote:

> Dear OSGeo GSoC Admin team,
>
> here is the project ideas page for GRASS GIS:
>
> https://trac.osgeo.org/grass/wiki/GSoC/2021
>
> Best,
> Anna
>
> On Thu, Jan 28, 2021 at 10:09 AM Rajat Shinde 
> wrote:
>
>> Dear All,
>>
>> Greetings!
>>
>> It is the time of the year to start preparing for the OSGeo's
>> participation with the Google Summer of Code 2021 [1] and we need your help
>> for the same. With a 100% success for all the GSoC 2020 student projects
>> [2], we are highly excited and motivated to invite the OSGeo projects
>> (Projects, Incubation projects, Guest Projects) to begin compiling the
>> project ideas for GSoC 2021.
>>
>> In order to participate in proposing ideas as a project under OSGeo
>> umbrella organisation, you just need to send us (admins:  > osgeo dot org>) the URL for your project's GSoC ideas Wiki page. If you are
>> participating for the first time, then you may visit [3] [4] for reference.
>>
>> Please remember that every idea should indicate:
>>
>> • A title
>> • A description
>> • 2 Mentors' Details
>> • A test for the students to submit to your evaluation. The test aims
>> at evaluating if the student is capable for the project, so please design
>> the test having in mind the basic skills required to complete the project.
>>
>> The organisation application period starts Jan 30, 2021 and will be open
>> till Feb 20, 2021. So, we expect all the URLs by Feb 10, 2021. Here is the
>> complete GSoC 2021 timeline [5].
>>
>> *Note:* GSoC 2021 comes with some new changes in the program. We
>> sincerely request to go through the announcement mentioning new changes [6].
>>
>> Thanks and please forward the information to your respective projects
>> mailing list!
>>
>> Kind regards,
>> Rahul and Rajat
>> (On behalf of the OSGeo GSoC Admins Team)
>>
>> [1] https://summerofcode.withgoogle.com/
>> [2] https://wiki.osgeo.org/wiki/Google_Summer_of_Code_2020
>> [3] https://github.com/pgRouting/pgrouting/wiki/GSoC-Ideas:-2021
>> [4] https://wiki.osgeo.org/wiki/Google_Summer_of_Code_2020_Ideas
>> [5] https://summerofcode.withgoogle.com/how-it-works/#timeline
>> [6]
>> https://opensource.googleblog.com/2020/10/google-summer-of-code-2021-is-bringing.html
>> ___
>> 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] ASF - OGC - OSGeo code sprint - Feb 17-19, 2021

[Anna Petrášová]

Hi Vero,

we registered for this, we probably won't participate 100% of the time, but
hope to see other GRASS devs there.

Anna & Vaclav

On Thu, Feb 11, 2021 at 9:16 AM Veronica Andreo 
wrote:

> Hello everyone :)
>
> Shall we join the 2021 Joint ASF – OGC – OSGeo Code Sprint [0]?
>
> AFAIU, the focus is on OGC standards implementation. Is anyone in the
> GRASS community currently working on that and wishes to participate? They
> have created a repo with further details [1] in case you are interested.
>
> Best,
> Vero
>
> [0] https://portal.ogc.org/public_ogc/register/20210217_code_sprint.php
> [1] https://github.com/opengeospatial/joint-ogc-osgeo-asf-sprint-2021
> ___
> 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] [OSGeo-Discuss] [OSGeo @ GSoC 2021] Call for Projects to Prepare Project Ideas Page for Google Summer of Code 2021

[Anna Petrášová]

Hi devs, please consider adding yourself as co-mentors here:

https://trac.osgeo.org/grass/wiki/GSoC/2021

On Tue, Feb 2, 2021 at 11:42 PM Anna Petrášová 
wrote:

> Dear all,
>
> please look at our 2021 GSoC page and if you are interested, add new ideas
> and add yourself as possible (co)mentors:
> https://trac.osgeo.org/grass/wiki/GSoC/2021
>
> Note that this year the projects are supposed to be smaller (175 hours
> instead of 350 hours), which in our case is not a huge problem, since the
> topics are quite flexible in this regard.
>
> Best,
> Anna
>
> -- Forwarded message -
> From: Rajat Shinde 
> Date: Thu, Jan 28, 2021 at 10:09 AM
> Subject: [OSGeo-Discuss] [OSGeo @ GSoC 2021] Call for Projects to Prepare
> Project Ideas Page for Google Summer of Code 2021
> To: OSGeo Discussions , OSGeo-SoC <
> s...@lists.osgeo.org>, 
> Cc: gsoc-adminosgeo.org 
>
>
> Dear All,
>
> Greetings!
>
> It is the time of the year to start preparing for the OSGeo's
> participation with the Google Summer of Code 2021 [1] and we need your help
> for the same. With a 100% success for all the GSoC 2020 student projects
> [2], we are highly excited and motivated to invite the OSGeo projects
> (Projects, Incubation projects, Guest Projects) to begin compiling the
> project ideas for GSoC 2021.
>
> In order to participate in proposing ideas as a project under OSGeo
> umbrella organisation, you just need to send us (admins:   osgeo dot org>) the URL for your project's GSoC ideas Wiki page. If you are
> participating for the first time, then you may visit [3] [4] for reference.
>
> Please remember that every idea should indicate:
>
> • A title
> • A description
> • 2 Mentors' Details
> • A test for the students to submit to your evaluation. The test aims
> at evaluating if the student is capable for the project, so please design
> the test having in mind the basic skills required to complete the project.
>
> The organisation application period starts Jan 30, 2021 and will be open
> till Feb 20, 2021. So, we expect all the URLs by Feb 10, 2021. Here is the
> complete GSoC 2021 timeline [5].
>
> *Note:* GSoC 2021 comes with some new changes in the program. We
> sincerely request to go through the announcement mentioning new changes [6].
>
> Thanks and please forward the information to your respective projects
> mailing list!
>
> Kind regards,
> Rahul and Rajat
> (On behalf of the OSGeo GSoC Admins Team)
>
> [1] https://summerofcode.withgoogle.com/
> [2] https://wiki.osgeo.org/wiki/Google_Summer_of_Code_2020
> [3] https://github.com/pgRouting/pgrouting/wiki/GSoC-Ideas:-2021
> [4] https://wiki.osgeo.org/wiki/Google_Summer_of_Code_2020_Ideas
> [5] https://summerofcode.withgoogle.com/how-it-works/#timeline
> [6]
> https://opensource.googleblog.com/2020/10/google-summer-of-code-2021-is-bringing.html
> ___
> 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] [OSGeo-Discuss] [OSGeo @ GSoC 2021] Call for Projects to Prepare Project Ideas Page for Google Summer of Code 2021

[Anna Petrášová]

Dear OSGeo GSoC Admin team,

here is the project ideas page for GRASS GIS:

https://trac.osgeo.org/grass/wiki/GSoC/2021

Best,
Anna

On Thu, Jan 28, 2021 at 10:09 AM Rajat Shinde 
wrote:

> Dear All,
>
> Greetings!
>
> It is the time of the year to start preparing for the OSGeo's
> participation with the Google Summer of Code 2021 [1] and we need your help
> for the same. With a 100% success for all the GSoC 2020 student projects
> [2], we are highly excited and motivated to invite the OSGeo projects
> (Projects, Incubation projects, Guest Projects) to begin compiling the
> project ideas for GSoC 2021.
>
> In order to participate in proposing ideas as a project under OSGeo
> umbrella organisation, you just need to send us (admins:   osgeo dot org>) the URL for your project's GSoC ideas Wiki page. If you are
> participating for the first time, then you may visit [3] [4] for reference.
>
> Please remember that every idea should indicate:
>
> • A title
> • A description
> • 2 Mentors' Details
> • A test for the students to submit to your evaluation. The test aims
> at evaluating if the student is capable for the project, so please design
> the test having in mind the basic skills required to complete the project.
>
> The organisation application period starts Jan 30, 2021 and will be open
> till Feb 20, 2021. So, we expect all the URLs by Feb 10, 2021. Here is the
> complete GSoC 2021 timeline [5].
>
> *Note:* GSoC 2021 comes with some new changes in the program. We
> sincerely request to go through the announcement mentioning new changes [6].
>
> Thanks and please forward the information to your respective projects
> mailing list!
>
> Kind regards,
> Rahul and Rajat
> (On behalf of the OSGeo GSoC Admins Team)
>
> [1] https://summerofcode.withgoogle.com/
> [2] https://wiki.osgeo.org/wiki/Google_Summer_of_Code_2020
> [3] https://github.com/pgRouting/pgrouting/wiki/GSoC-Ideas:-2021
> [4] https://wiki.osgeo.org/wiki/Google_Summer_of_Code_2020_Ideas
> [5] https://summerofcode.withgoogle.com/how-it-works/#timeline
> [6]
> https://opensource.googleblog.com/2020/10/google-summer-of-code-2021-is-bringing.html
> ___
> 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] Min. req. of programming language standard support, GRASS GIS 8

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

Anna

[1] https://gdal.org/development/rfc/rfc77_drop_python2_support.html


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

Re: [GRASS-dev] r.statistics being deprecated?

[Anna Petrášová]

On Thu, Feb 4, 2021 at 5:44 PM Markus Neteler  wrote:

> On Thu, Feb 4, 2021 at 8:19 PM Michael Barton 
> wrote:
> >
> > r.statistics no longer appears in the menu for GRASS 7.8.6 (and
> earlier?).
> >
> > Is it being deprecated and replaced by r.stats.zonal?
>
> I am not aware of that but indeed I don't see it in the menu under
>
> Raster > Reports and statistics
>
> Was it ever therein?
>
> Regarding replacement:
> https://grass.osgeo.org/grass79/manuals/r.stats.zonal.html#notes
> "r.stats.zonal is intended to be a partial replacement for
> r.statistics, with support for floating-point cover maps at the
> expense of not supporting quantiles."
>

See also https://lists.osgeo.org/pipermail/grass-dev/2014-March/068038.html

I believe r.statistics could be removed (perhaps moved to addons). It is
replaced by r.stats.zonal for the most part, and also r.stats.quantile and
r.mode.



> 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

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

[Anna Petrášová]

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.
>
>
> Best,
> Nicklas
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Fwd: [OSGeo-Discuss] [OSGeo @ GSoC 2021] Call for Projects to Prepare Project Ideas Page for Google Summer of Code 2021

[Anna Petrášová]

Dear all,

please look at our 2021 GSoC page and if you are interested, add new ideas
and add yourself as possible (co)mentors:
https://trac.osgeo.org/grass/wiki/GSoC/2021

Note that this year the projects are supposed to be smaller (175 hours
instead of 350 hours), which in our case is not a huge problem, since the
topics are quite flexible in this regard.

Best,
Anna

-- Forwarded message -
From: Rajat Shinde 
Date: Thu, Jan 28, 2021 at 10:09 AM
Subject: [OSGeo-Discuss] [OSGeo @ GSoC 2021] Call for Projects to Prepare
Project Ideas Page for Google Summer of Code 2021
To: OSGeo Discussions , OSGeo-SoC <
s...@lists.osgeo.org>, 
Cc: gsoc-adminosgeo.org 


Dear All,

Greetings!

It is the time of the year to start preparing for the OSGeo's participation
with the Google Summer of Code 2021 [1] and we need your help for the same.
With a 100% success for all the GSoC 2020 student projects [2], we are
highly excited and motivated to invite the OSGeo projects (Projects,
Incubation projects, Guest Projects) to begin compiling the project ideas
for GSoC 2021.

In order to participate in proposing ideas as a project under OSGeo
umbrella organisation, you just need to send us (admins:  ) the URL for your project's GSoC ideas Wiki page. If you are
participating for the first time, then you may visit [3] [4] for reference.

Please remember that every idea should indicate:

• A title
• A description
• 2 Mentors' Details
• A test for the students to submit to your evaluation. The test aims
at evaluating if the student is capable for the project, so please design
the test having in mind the basic skills required to complete the project.

The organisation application period starts Jan 30, 2021 and will be open
till Feb 20, 2021. So, we expect all the URLs by Feb 10, 2021. Here is the
complete GSoC 2021 timeline [5].

*Note:* GSoC 2021 comes with some new changes in the program. We sincerely
request to go through the announcement mentioning new changes [6].

Thanks and please forward the information to your respective projects
mailing list!

Kind regards,
Rahul and Rajat
(On behalf of the OSGeo GSoC Admins Team)

[1] https://summerofcode.withgoogle.com/
[2] https://wiki.osgeo.org/wiki/Google_Summer_of_Code_2020
[3] https://github.com/pgRouting/pgrouting/wiki/GSoC-Ideas:-2021
[4] https://wiki.osgeo.org/wiki/Google_Summer_of_Code_2020_Ideas
[5] https://summerofcode.withgoogle.com/how-it-works/#timeline
[6]
https://opensource.googleblog.com/2020/10/google-summer-of-code-2021-is-bringing.html
___
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] Min. req. of programming language standard support, GRASS GIS 8

[Anna Petrášová]

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
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] 7.8.5 windows installer broken. How to find 7.8.4?

[Anna Petrášová]

On Tue, Jan 19, 2021 at 3:48 PM Michael Barton 
wrote:

> Could someone let me know if and when the windows installer for GRASS
> 7.8.5 has been fixed?
>

I think the issue I sent you earlier gives the most up-to-date info, so I
would subscribe to that issue to get updates. I don't think we fully
understand the problem yet.

Anna

>
>
> Thanks
>
> Michael
>
>
>
> __
>
> C. Michael Barton
> Director, Center for Social Dynamics & Complexity
> Director, Network for Computational Modeling in Social & Ecological
> Sciences
> Associate Director, School of Complex Adaptive Systems
> Professor, School of Human Evolution & Social Change
> Arizona State University
> Tempe, AZ  85287-2402
> USA
>
> voice: 480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
> fax: 480-965-7671(SHESC), 480-727-0709 (CSDC)
> www: http://shesc.asu.edu,
>
> https://complexity.asu.edu,
>
> http://www.public.asu.edu/~cmbarton
>
>
>
> *From: *Michael Barton 
> *Date: *Wednesday, January 13, 2021 at 6:57 AM
> *To: *Anna Petrášová 
> *Cc: *GRASS developers 
> *Subject: *Re: [GRASS-dev] 7.8.5 windows installer broken. How to find
> 7.8.4?
>
> Thanks much Anna
>
> _
>
> C. Michael Barton
> Director, Center for Social Dynamics & Complexity
> Director, Network for Computational Modeling in Social & Ecological
> Sciences
> Associate Director, School of Complex Adaptive Systems
> Professor, School of Human Evolution & Social Change
> Arizona State University
> Tempe, AZ  85287-2402
> USA
>
> voice: 480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
> fax: 480-965-7671(SHESC), 480-727-0709 (CSDC)
> www: http://shesc.asu.edu, https://complexity.asu.edu,
> http://www.public.asu.edu/~cmbarton
>
>
>
> On Jan 12, 2021, at 7:54 PM, Anna Petrášová  wrote:
>
>
>
> Hi,
>
>
>
> On Tue, Jan 12, 2021 at 7:13 PM Michael Barton 
> wrote:
>
> I just launched my spatial tech class today. Most people use Windows. I
> don't and and can't test it regularly, but haven't worried much about it
> because so many people do use it.
>
>
>
> Nobody could get the standard Windows install to work for GRASS 7.8.5
> today. It simply launched a console with a bunch of error messages
> apparently, for everyone. I'm getting someone to send a screenshot so I can
> file a report.
>
>
>
> no need, here it is already:
>
> https://github.com/OSGeo/grass/issues/1218
> <https://urldefense.com/v3/__https:/github.com/OSGeo/grass/issues/1218__;!!IKRxdwAv5BmarQ!ICuWRUwB9h07Hc31kRbS2xXQ8spAJZ2RFE4YThl10RsuI7ABkZkTxkJc_dJmcZFaB0wDZ2w$>
>
>
>
>
> People were having trouble with 7.8.5 in OSGEO4W too. It did install but
> had problems running for some people.
>
>
>
> In the meantime, is there someplace to get 7.8.4?
>
>
>
> https://grass.osgeo.org/grass78/binary/mswindows/native/x86_64/
> <https://urldefense.com/v3/__https:/grass.osgeo.org/grass78/binary/mswindows/native/x86_64/__;!!IKRxdwAv5BmarQ!ICuWRUwB9h07Hc31kRbS2xXQ8spAJZ2RFE4YThl10RsuI7ABkZkTxkJc_dJmcZFapIij0O4$>
>
>
>
> This is indeed a problem...
>
>
>
>
>
>
>
> Thanks
>
> Michael
>
> _
>
> C. Michael Barton
> Director, Center for Social Dynamics & Complexity
> Director, Network for Computational Modeling in Social & Ecological
> Sciences
> Associate Director, School of Complex Adaptive Systems
> Professor, School of Human Evolution & Social Change
> Arizona State University
> Tempe, AZ  85287-2402
> USA
>
> voice: 480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
> fax: 480-965-7671(SHESC), 480-727-0709 (CSDC)
> www: http://shesc.asu.edu
> <https://urldefense.com/v3/__http:/shesc.asu.edu__;!!IKRxdwAv5BmarQ!ICuWRUwB9h07Hc31kRbS2xXQ8spAJZ2RFE4YThl10RsuI7ABkZkTxkJc_dJmcZFavzA1TmY$>
> , https://complexity.asu.edu
> <https://urldefense.com/v3/__https:/complexity.asu.edu__;!!IKRxdwAv5BmarQ!ICuWRUwB9h07Hc31kRbS2xXQ8spAJZ2RFE4YThl10RsuI7ABkZkTxkJc_dJmcZFaqIVnNAs$>
> , http://www.public.asu.edu/~cmbarton
> <https://urldefense.com/v3/__http:/www.public.asu.edu/*cmbarton__;fg!!IKRxdwAv5BmarQ!ICuWRUwB9h07Hc31kRbS2xXQ8spAJZ2RFE4YThl10RsuI7ABkZkTxkJc_dJmcZFaXRhVf5w$>
>
>
>
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
> <https://urldefense.com/v3/__https:/lists.osgeo.org/mailman/listinfo/grass-dev__;!!IKRxdwAv5BmarQ!ICuWRUwB9h07Hc31kRbS2xXQ8spAJZ2RFE4YThl10RsuI7ABkZkTxkJc_dJmcZFaZt2VfZ8$>
>
>
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Statement Anna Petrasova

[Anna Petrášová]

Dear GRASS community,

Thank you for the PSC nomination! I have been involved in GRASS GIS
development for ten years now, being a PSC member since 2016. I have been
mostly focusing on GUI development, but I am familiar with most parts of
the codebase. As a PhD student and now working in academia I have been
teaching geospatial modeling in GRASS, leading numerous workshops, and
helping students individually as well as supporting the broader scientific
community on mailing lists. After participating in Google Summer of Code as
a student, I mentored and co-mentored several GSoC students with projects
focusing e.g. on Python 3 support and new start-up.

I am really excited from the many changes GRASS underwent recently
including transitioning to GitHub, which increased the outside
contributions, attracted more developers, and increased code quality. I
would like to continue that trend by making sure current and new devs are
supported with high quality code reviews and more readable and documented
code in general. Also I hope to participate in programs attracting new
developers such as GSoC.

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

Re: [GRASS-dev] Fwd: [Projects] [Board] upcoming OSGeo/OGC/Apache code sprint

[Anna Petrášová]

+1

Anna

On Mon, Jan 11, 2021 at 4:32 PM Veronica Andreo 
wrote:

> Hello everyone!
>
> El dom, 10 ene 2021 a las 6:20, Luca Delucchi ()
> escribió:
>
>> Are we interested to participate?
>>
>
> +1 from my side!
>
> Vero
>
> -- Forwarded message -
>> Da: Angelos Tzotsos 
>> Date: ven 8 gen 2021, 14:16
>> Subject: Re: [Projects] [Board] upcoming OSGeo/OGC/Apache code sprint
>> To: 
>> Cc: osgeo-board List 
>>
>>
>> Hi all and happy new year!
>>
>> We will soon be able to announce dates for the code sprint.
>> If projects are willing to participate (and be listed in the official
>> announcement) please let us know.
>>
>> Best,
>> Angelos
>>
>> On 12/10/20 3:05 PM, Tom Kralidis wrote:
>> > Hi everyone: as part of our ongoing collaboration with OGC, and given
>> > the synergy of FOSS4G projects and OGC standards, we are working with
>> > OGC and the Apache Software Foundation to coordinate an OSGeo/OGC/ASF
>> > virtual code sprint in Q1 2021 (~February 2021).
>> >
>> > As with previous OSGeo presence at OGC Hackathons, we will document and
>> > report on OSGeo participation at the event.  This will provide
>> > value in terms of having a sense of FOSS4G projects involvement as part
>> > of our OGC collaboration.  This will also help coordinate involvement
>> > at future hackathons / code sprints at both OSGeo code sprints (i.e.
>> perhaps
>> > a dedicated interoperability theme), OGC Hackathons, or related ASF
>> events.
>> >
>> > We are working with OGC and ASF to coordinate dates for the events, as
>> well
>> > as a joint announcement to help advertise the event details in the
>> coming weeks.
>> >
>> > Given the synergy of FOSS4G projects and OGC standards, we kindly ask
>> > that projects
>> > consider participation in this important upcoming event.  This event
>> with also
>> > will be a first between OSGeo/OGC and ASF, and provides the opportunity
>> > for cross-pollination with ASF geospatial projects (see [1] as an
>> example of
>> > geospatial projects presented at ApacheCon 2020 as an example).
>> >
>> > Thanks
>> >
>> > ..Tom
>> >
>> > [1] https://apachecon.com/acah2020/tracks/geospatial.html
>> > ___
>> > Board mailing list
>> > bo...@lists.osgeo.org
>> > https://lists.osgeo.org/mailman/listinfo/board
>> > .
>>
>>
>> --
>> Angelos Tzotsos, PhD
>> President
>> Open Source Geospatial Foundation
>> http://users.ntua.gr/tzotsos
>>
>> ___
>> Projects mailing list
>> proje...@lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/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
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] 7.8.5 windows installer broken. How to find 7.8.4?

[Anna Petrášová]

Hi,

On Tue, Jan 12, 2021 at 7:13 PM Michael Barton 
wrote:

> I just launched my spatial tech class today. Most people use Windows. I
> don't and and can't test it regularly, but haven't worried much about it
> because so many people do use it.
>
> Nobody could get the standard Windows install to work for GRASS 7.8.5
> today. It simply launched a console with a bunch of error messages
> apparently, for everyone. I'm getting someone to send a screenshot so I can
> file a report.
>

no need, here it is already:
https://github.com/OSGeo/grass/issues/1218

>
> People were having trouble with 7.8.5 in OSGEO4W too. It did install but
> had problems running for some people.
>
> In the meantime, is there someplace to get 7.8.4?
>

https://grass.osgeo.org/grass78/binary/mswindows/native/x86_64/

This is indeed a problem...



>
> Thanks
> Michael
> _
> C. Michael Barton
> Director, Center for Social Dynamics & Complexity
> Director, Network for Computational Modeling in Social & Ecological
> Sciences
> Associate Director, School of Complex Adaptive Systems
> Professor, School of Human Evolution & Social Change
> Arizona State University
> Tempe, AZ  85287-2402
> USA
>
> voice: 480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
> fax: 480-965-7671(SHESC), 480-727-0709 (CSDC)
> www: http://shesc.asu.edu, https://complexity.asu.edu,
> http://www.public.asu.edu/~cmbarton
>
> ___
> 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] Daily build available at OSGeo4W 7.9.dev-6842631ae-366 does not start

[Anna Petrášová]

Thanks for reporting it, this has been fixed already, see
https://github.com/OSGeo/grass/issues/1097 for details.

Anna

On Tue, Nov 24, 2020 at 6:28 AM Pedro Venâncio 
wrote:

> Hi all,
>
> The last daily build available at OSGeo4W (7.9.dev-6842631ae-366) does not
> start:
>
> Starting GRASS GIS...
> ATENÇÃO: Concurrent mapset locking is not supported on Windows
> Cleaning up temporary files...
> D1/1: G_set_program_name(): clean_temp
>
>   __  ___   _____
>  / / __ \/   | / ___/ ___/   / /  _/ ___/
> / / __/ /_/ / /| | \__ \\_  \   / / __ / / \__ \
>/ /_/ / _, _/ ___ |___/ /__/ /  / /_/ // / ___/ /
>\/_/ |_/_/  |_///   \/___///
>
> Welcome to GRASS GIS 7.9.dev (6842631ae)
> GRASS GIS homepage:  https://grass.osgeo.org
> This version running through:Command Prompt
> (C:\WINDOWS\system32\cmd.exe)
> Help is available with the command:  g.manual -i
> See the licence terms with:  g.version -c
> See citation options with:   g.version -x
> If required, restart the GUI with:   g.gui wxpython
> When ready to quit enter:exit
>
> Launching  GUI in the background, please wait...
> Microsoft Windows [Version 10.0.19041.630]
> (c) 2020 Microsoft Corporation. Todos os direitos reservados.
>
> C:\>D1/1: G_set_program_name(): g.gisenv
> D1/1: grass.script.core.start_command(): g.gisenv -n
> D1/1: G_set_program_name(): g.gisenv
> Traceback (most recent call last):
>   File "C:\OSGEO4~1\apps\grass\grass79\gui\wxpython\wxgui.py", line 104,
> in OnInit
> from lmgr.frame import GMFrame
>   File "C:\OSGEO4~1\apps\grass\grass79\gui\wxpython\lmgr\frame.py", line
> 69, in 
> from datacatalog.catalog import DataCatalog
>   File
> "C:\OSGEO4~1\apps\grass\grass79\gui\wxpython\datacatalog\catalog.py", line
> 22, in 
> from datacatalog.tree import DataCatalogTree
>   File "C:\OSGEO4~1\apps\grass\grass79\gui\wxpython\datacatalog\tree.py",
> line 189, in 
> class MapWatch(PatternMatchingEventHandler):
> NameError: name 'PatternMatchingEventHandler' is not defined
> OnInit returned false, exiting...
>
>
> The previous one (GRASS GIS 7.9.dev-297c43fe8-365) works as expected.
>
> Best regards,
> Pedro Venâncio
> ___
> 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] Read-access to data in a different location with same SRS

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

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

Anna

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

Re: [GRASS-dev] r.sun.daily insolation time parameter

[Anna Petrášová]

On Tue, Oct 20, 2020 at 9:41 AM Pedro Venâncio 
wrote:

> Hi all,
>
> I was trying to use r.sun.daily to get the total insolation time between
> two dates, but I see that insol_time is not an available parameter in
> r.sun.daily.
>
> Was there any reason to not include insol_time in r.sun.daily script?
>

I don't remember any specific reason, it certainly looks like it would be
possible. You can create a feature request or even a PR:

https://github.com/OSGeo/grass-addons

the code is here:
https://github.com/OSGeo/grass-addons/blob/master/grass7/raster/r.sun.daily/r.sun.daily.py

>
> Thank you very much!
>
> Best regards,
> Pedro Venâncio
> ___
> 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] Milestone management: 7.8.5 or 7.10 or 8.0.0?

[Anna Petrášová]

Hi,

just to confirm what Martin and Vero were saying, the problem is we have
breaking changes (TGIS) in master and new, fairly major features (data
catalog, new startup mechanism) and probably some other things, so we can't
simply branch off 7.10 without disabling those. So that's why during the
recent call we had we leaned towards releasing 8. I agree beginning of 2021
should be realistic, although I am not sure what is the timeline of the
PROJ changes.
We have the GRASS 8 ideas here, so it would be worth reviewing what could
be realistically accomplished:
https://trac.osgeo.org/grass/wiki/Grass8Planning


Anna

On Sun, Oct 11, 2020 at 1:15 PM 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)
>
> I think it could be realistic to release 8.0.0 in the first quarter of
> 2021 (Feb?).
>
> Martin
>
> [1] https://trac.osgeo.org/grass/wiki/Release/Schedule#Scenario3
>
> --
> 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] Python: how to access the --quiet and --verbose flags?

[Anna Petrášová]

It's this one:
https://grass.osgeo.org/grass78/manuals/libpython/script.html?highlight=hidden#script.core.verbosity

On Tue, Sep 29, 2020 at 8:08 AM Markus Neteler  wrote:

> Hi devs,
>
> Maybe a simple question but I don't understand how to access in Python
> the --quiet and --verbose flags.
> I suppose that I have to make use of
>
>
> https://grass.osgeo.org/grass-stable/manuals/libpython/script.html?highlight=hidden#script.task.command_info
>
> but would appreciate an example.
>
> Thanks
> Markus
>
> PS: then to be added to
> https://grasswiki.osgeo.org/wiki/GRASS_Python_Scripting_Library
> ___
> 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.4

[Anna Petrášová]

There is a long list of merged PRs which have backport needed label:
https://github.com/OSGeo/grass/pulls?page=2=is%3Apr+is%3Aclosed+label%3Abackport_needed

We never discussed this, but I assumed when somebody backports a commit,
they would remove the label (of course it can happen you forget). I went
through a couple of them and some of them were backported and some not.
There is a long list, so I wonder if other devs can also review this and
make sure everything is backported or remove the label if the plan is not
to backport. Or did I misunderstand how to use the label?

Anna

On Wed, Aug 19, 2020 at 3:15 PM Markus Neteler  wrote:

> Hi devs,
>
> On Tue, Aug 11, 2020 at 7:50 PM Markus Neteler  wrote:
> >
> > Hi devs,
> >
> > We have accumulated a series of important fixes, suggesting to
> > consider the next release at the end of the month.
> > There is a related 7.8.4 milestone in GH:
> >
> > https://github.com/OSGeo/grass/milestone/2
> > --> Due by August 31, 2020 72% complete (15 open issues, 39 closed)
> >
> > (along with the "classical" milestone in trac:
> >  https://trac.osgeo.org/grass/milestone/7.8.4
> > )
> >
> > Some of the yet open issues may be close to be completed, please take a
> look.
>
> I'd start with RC1 in the next few days.
>
> 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

Re: [GRASS-dev] new startup and data tab

[Anna Petrášová]

Hi Paulo,

glad you like it! As for your comments, they are certainly valid and we
definitely need people's feedback. Could you please create issues on github
to keep track of them, that's the most convenient way for us.

Anna

On Fri, Aug 21, 2020 at 3:14 PM Paulo van Breugel 
wrote:

> Dear devs,
>
> I just compiled the grass gis master, which now opens directly, with the
> data tab. As a (fairly) long time user of grass gis, it took me a few
> seconds to get used to the idea ;-), but I am loving it!
>
> Apart from the start up, I really like the more prominent place and
> functionality of the data tab. I was already using it a lot, but e.g., the
> icons really provide a neat extra touch. And for new users a nice visual
> representation of the database structure. I
>
> One small remark about the options to add an existing or create a new
> database. I am not sure this is completely intuitive. Initially I thought
> the button 'Add new grass database' button would be to create a new
> database, and I was looking where to open an existing one. I found out
> quick enough that one can use the button to add an existing database as
> well, but perhaps wording the tooltip slightly different makes it more
> apparent (e.g., ' Add existing or create new database' ).
>
> When creating a new location, there is the option to change the database
> in which to create the location. This requires one to select the grass
> database folder. I wonder if it wouldn't be more intuitive and easier (from
> a user point of view) if the user can simply select the database from a
> list of 'connected' databases? Why would I want to create a location in a
> database that is not in the list? And if it is in the list, having to
> browse to the database folder feels like, well, something I would rather
> not (being lazy and all).
>
> Anyway, some feedback on some great improvements!
>
> Cheers,
>
> Paulo
>
>
> ___
> 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.3

[Anna Petrášová]

On Wed, Apr 29, 2020 at 4:34 AM Nicklas Larsson  wrote:

> Hi all,
>
>
> > On 28 Apr 2020, at 16:01, Anna Petrášová  wrote:
> >
> >
> > and https://github.com/OSGeo/grass/issues/564 (new wx release breaking
> stuff) but hopefully that should be relatively easy to fix
> >
> > Anna
> >
>
>
> Some thoughts: maybe we should skip support for wxPython 4.1.0 for the
> 7.8.3 release? Looking at the draft PR [1] addressing this, albeit not
> finished, quite a number of changes are required. This should be tested
> thoroughly, even the most seemingly innocent change can lead to unintended
> and unexpected bugs. Personally, I'm now quite glad we now -- at long last
> -- have a working and fairly stable version for mac.
>

Most changes are only in layout flags, these are easy to review and the
worst case is the layout may look strange, so I wouldn't worry about this
part too much. But I am more worried about the other things I didn't have
time to fix yet. For example opening file menu freezes my computer, memory
starts allocating. So I at least need more time to figure out the issues.
Also testing on other platforms would be great.

>
> The questions are how quick will the wxPython 4.1 be
> established/extensively used (how urgent is the support for it), and for
> how long are we willing to postpone this 7.8.3 release (for fixing and
> testing).
>

AFAICT, 4.1 is default in PyPI so when you install wx that way, you get
4.1. I am not sure at this point, I agree 7.8.3 should get released as soon
as possible.


>
> Perhaps a solution is to make an imminent GRASS 7.10 release with 4.1
> support as suggested elsewhere [2] including the numerous fixes to be made
> with flake8 and maybe black.
>
> (This is of course only relevant if the number of changes required
> increase substantially from the present PR draft.)
>
>
> /Nicklas
>
>
> [1] https://github.com/OSGeo/grass/pull/570
>
> [2] https://github.com/OSGeo/grass/issues/543#issuecomment-619229231
___
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.3

[Anna Petrášová]

On Tue, Apr 28, 2020 at 9:03 AM Martin Landa  wrote:

> Hi,
>
> út 28. 4. 2020 v 12:55 odesílatel Martin Landa 
> napsal:
> > packages available for testing:
> >
> > 1) wingrass:
>
> it seems that we have a new blocker [1] ;-)
>
> Ma
>
> [1] https://github.com/OSGeo/grass/issues/566
>
>
and https://github.com/OSGeo/grass/issues/564 (new wx release breaking
stuff) but hopefully that should be relatively easy to fix

Anna


> --
> 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] Proposal Draft: Creation of a new GRASS GIS startup mechanism (correct link)

[Anna Petrášová]

Please upload it to GSoC dashboard, I can't see it there.

On Sun, Mar 29, 2020 at 12:19 PM L.Kladivova  wrote:

> Hi All,
>
> I have accidentally shared the wrong link, thank you Martin for your
> notice! :-)
>
> The right one is here:
>
> https://docs.google.com/document/d/18bVt_bjCDgy2v79Y68rf6-nJgz8rTJkdkjbqN52YGmM/edit#heading=h.z80kwwj3ld9u
>
> Commenting should be enabled.
>
> Linda
> ___
> 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] silly question

[Anna Petrášová]

On Wed, Mar 4, 2020 at 11:29 PM Michael Barton 
wrote:

> See
>
> https://trac.osgeo.org/grass/wiki/HowToGit
>
> For example:
>
> git clone g...@github.com:your_GH_account/grass-addons.git
> cd grass-addons/
> git remote add upstream g...@github.com:OSGeo/grass-addons.git
>
> does not work for me at least. It needs to be:
>
> git clone g...@github.com/your_GH_account/grass-addons.git
> cd grass-addons/
> git remote add upstream g...@github.com/OSGeo/grass-addons.git
>
> Are you sure about this? This definitely doesn't work for me, if you use
https it needs to be:

git clone https://github.com/*YOUR-USERNAME*/*YOUR-REPOSITORY*




> replacing g...@github.com:your_GH_account with g...@github.com
> /your_GH_account
>
> Maybe the colon works if you have an ssh key set in your github account.
>
> Michael
> 
> C. Michael Barton
> Director, Center for Social Dynamics & Complexity
> Professor of Anthropology, School of Human Evolution & Social Change
> Head, Graduate Faculty in Complex Adaptive Systems Science
> Arizona State University
>
> voice:  480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
> fax: 480-965-7671 (SHESC),  480-727-0709 (CSDC)
> www: http://www.public.asu.edu/~cmbarton, https://complexity.asu.edu/csdc
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Mar 4, 2020, at 7:37 PM, Vaclav Petras  wrote:
>
> Thanks Anna for identifying this. Looks likely.
>
> Markus, Michael, I don't see the bad URL anywhere on Trac wiki, grasswiki,
> or in CONTRIBUTING.md file (as far as search works for URLs, it does at
> least for Trac).
>
> Michael, The CONTRIBUTING.md file has SSH URL for your fork and HTTPS for
> the OSGeo upstream repo, so your problem was not caused by that.
>
> Nevertheless, switching to HTTPS also for the fork is something we can do
> if more people support it.
>
> Vaclav
>
> On Wed, Mar 4, 2020 at 9:11 PM Markus Neteler  wrote:
>
>> Michael,
>>
>> Michael Barton  schrieb am Mi., 4. März 2020,
>> 19:11:
>>
>>> Thanks Luca,
>>>
>>> I also found someone here that pointed that out. I originally got
>>> instructions from the GRASS WIKI.
>>>
>>
>>
>> Which URL?
>>
>> Markus
>>
>> There is either an error or it is something that does not work for Macs.
>>> The examples use a colon to indicate the repository owner instead of a
>>> slash. I had fixed that for the original clone command but did not catch it
>>> for the one setting upstream.
>>>
>>> Also learned a new one that is exactly what I need in some
>>> circumstances:
>>>
>>> git reset --hard origin/master
>>>
>>> Michael
>>> 
>>> C. Michael Barton
>>> Director, Center for Social Dynamics & Complexity
>>> Professor of Anthropology, School of Human Evolution & Social Change
>>> Head, Graduate Faculty in Complex Adaptive Systems Science
>>> Arizona State University
>>>
>>> voice:  480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
>>> fax: 480-965-7671 (SHESC),  480-727-0709 (CSDC)
>>> www: http://www.public.asu.edu/~cmbarton
>>> 
>>> , https://complexity.asu.edu/csdc
>>> 
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Mar 4, 2020, at 3:30 PM, Luca Delucchi  wrote:
>>>
>>> Hi Michael,
>>>
>>> On Wed, 4 Mar 2020 at 19:49, Michael Barton 
>>> wrote:
>>>
>>>
>>> I want to do something that should be simple but it is not. I want to be
>>> able to update my fork of GRASS source code from master. The wiki
>>> instructions say I should be able to do this with:
>>>
>>> git fetch upstream
>>> git rebase upstream/master
>>>
>>> But when I do, I get:
>>>
>>> unable to access 
>>> 'https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com-3AOSGeo_grass.git_=DwIBaQ=l45AxH-kUV29SRQusp9vYR0n1GycN4_2jInuKy6zbqQ=lk-7X7CEOMDN8GaGVhiDsuO6gEp1wbG6nfT1XEEEtR0=ocylBhKg4eZ-QJLCBa53vt3dUwHB_ZET96-XkejX2FU=t9pyApmJY3B5H0nFh-Gm1IG1VGltt378-0JryEOEZG8=
>>> ': Port number ended with 'O
>>> 
>>> '
>>>
>>>
>>> it seems wrong the url, it should be
>>> 

Re: [GRASS-dev] silly question

[Anna Petrášová]

Perhaps caused by some mixing of cloning with HTTPS vs SSH?

git clone g...@github.com:petrasovaa/grass.git
git clone https://github.com/petrasovaa/grass.git

The instructions assume ssh.

On Wed, Mar 4, 2020 at 7:11 PM Michael Barton 
wrote:

> Thanks Luca,
>
> I also found someone here that pointed that out. I originally got
> instructions from the GRASS WIKI. There is either an error or it is
> something that does not work for Macs. The examples use a colon to indicate
> the repository owner instead of a slash. I had fixed that for the original
> clone command but did not catch it for the one setting upstream.
>
> Also learned a new one that is exactly what I need in some circumstances:
>
> git reset --hard origin/master
>
> Michael
> 
> C. Michael Barton
> Director, Center for Social Dynamics & Complexity
> Professor of Anthropology, School of Human Evolution & Social Change
> Head, Graduate Faculty in Complex Adaptive Systems Science
> Arizona State University
>
> voice:  480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
> fax: 480-965-7671 (SHESC),  480-727-0709 (CSDC)
> www: http://www.public.asu.edu/~cmbarton, https://complexity.asu.edu/csdc
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Mar 4, 2020, at 3:30 PM, Luca Delucchi  wrote:
>
> Hi Michael,
>
> On Wed, 4 Mar 2020 at 19:49, Michael Barton 
> wrote:
>
>
> I want to do something that should be simple but it is not. I want to be
> able to update my fork of GRASS source code from master. The wiki
> instructions say I should be able to do this with:
>
> git fetch upstream
> git rebase upstream/master
>
> But when I do, I get:
>
> unable to access 
> 'https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com-3AOSGeo_grass.git_=DwIBaQ=l45AxH-kUV29SRQusp9vYR0n1GycN4_2jInuKy6zbqQ=lk-7X7CEOMDN8GaGVhiDsuO6gEp1wbG6nfT1XEEEtR0=ocylBhKg4eZ-QJLCBa53vt3dUwHB_ZET96-XkejX2FU=t9pyApmJY3B5H0nFh-Gm1IG1VGltt378-0JryEOEZG8=
> ': Port number ended with 'O
> 
> '
>
>
> it seems wrong the url, it should be
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_OSGeo_grass.git=DwIBaQ=l45AxH-kUV29SRQusp9vYR0n1GycN4_2jInuKy6zbqQ=lk-7X7CEOMDN8GaGVhiDsuO6gEp1wbG6nfT1XEEEtR0=ocylBhKg4eZ-QJLCBa53vt3dUwHB_ZET96-XkejX2FU=2s0FIt9ZZMaEF8dGFczUzV71CeMzJZ3MBNeNaOmhcp4=
>
> Any suggestions? I don't want to have to keep forking and cloning
>
> Michael
>
>
>
> --
> ciao
> Luca
>
> www.lucadelu.org
>
>
> ___
> 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] missing logs for Windows addons

[Anna Petrášová]

On Sat, Feb 29, 2020 at 4:51 PM Martin Landa  wrote:

> Hi,
>
> pá 14. 2. 2020 v 20:15 odesílatel Anna Petrášová 
> napsal:
> > I found another issue, it's not a big deal, but addons can't be
> installed for grass7.8dev because the g.extension expects grass-7.8.3dev
> while the server uses grass-7.8.dev:
> >
> > ERROR: Cannot open URL:
> http://wingrass.fsv.cvut.cz/grass78/x86_64/addons/grass-7.8.3dev/r.futures.zip
>
> the correct URL is
>
>
> http://wingrass.fsv.cvut.cz/grass78/x86_64/addons/grass-7.8.dev/r.futures.zip


yes, but g.extension expects  grass-7.8.3dev because grass.version() gives
7.8.3dev not 7.8.dev. So I guess the directory layout should follow that.


>
> Ma
>
> --
> 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

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

[Anna Petrášová]

Thanks, confirmed!

On Sat, Feb 29, 2020 at 4:52 PM Martin Landa  wrote:

> Hi,
>
> út 28. 1. 2020 v 15:00 odesílatel Anna Petrášová 
> napsal:
> > I looked at 7.9, 7.8.2 and 7.8.dev, none of them have any recent changes
>
> please check a next build (1/3), should be fixed.
>
> Ma
>
> --
> 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