Re: [GRASS-dev] New features provided by Nix

[Vaclav Petras via grass-dev]

Thanks Ivan, it looks quite useful and I plan to use it when I update my
system in a month or so.

On Fri, 28 Jun 2024 at 03:41, Ivan Mincik via grass-dev <
grass-dev@lists.osgeo.org> wrote:

> Hi people !
>
> Recently, I had a pleasure to join GRASS Community Meeting in Prague and
> had a presentation about Nix [1] and potential benefits it can bring to
> a GRASS community. It was quite well received and now it is a real thing
> [2] (+ few more PRs).
>
>
> # What Nix can do for you ?
>
> 1. Create a full development environment by running single `nix develop`
> command
>
> 2. Run GRASS directly from a Git source code (from any branch, tag or
> checkout which contains nix files added in #3889)
>
> 3. A lot more
>
>
> # How to use it ?
>
> Please check out PR #3889 [1] description for the instructions. It is
> just about installing Nix and then you can start running some magic
> commands.
>
> I am still struggling how to integrate this information to a GRASS Wiki.
>
>
> # My Nix presentation
>
> Markdown version of my GRASS Community meeting presentation containing
> some more very interesting examples can be found here [3].
>
> Have a nice day !
>
>
> 1 - https://nix.dev/
> 2 - https://github.com/OSGeo/grass/pull/3889
> 3 -
>
> https://github.com/imincik/nix-presentations/blob/master/grass-community-meeting-2024/presentation.md
>
> --
> Ivan Minčík, ivan.min...@gmail.com
>
> GPG: https://imincik.github.io/0xDDDF983F.key
> Matrix:  @imincik:matrix.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] Fwd: [PROJ] PROJ was not updated in Zenodo

[Vaclav Petras via grass-dev]

Thanks Even. This is not clear to me. I see OSGeo/grass enabled. I can't
manage that because it says that it is managed by another user of my org.
Screenshot attached.

Vaclav

On Tue, 4 Jun 2024 at 10:29, Even Rouault via grass-dev <
grass-dev@lists.osgeo.org> wrote:

> Hi,
>
> see below. I also see in https://zenodo.org/account/settings/github/ that
> the OSGeo/GRASS repository is disabled. I suspect it needs to be turned on
> again, otherwise the next GRASS release will probably lack a Zenodo record
> Even
>
>  Message transféré 
> Sujet : Re: [PROJ] PROJ was not updated in Zenodo
> Date : Tue, 4 Jun 2024 16:25:42 +0200
> De : Even Rouault via PROJ  
> Répondre à : Even Rouault 
> 
> Pour : Peter Löwe  , Javier
> Jimenez Shaw  
> Copie à : proj  
>
> Hi,
>
> I've posted the following message through Zenodo support form at
> https://zenodo.org/support
>
> 
>
> Hi,
> The PROJ project has released a new GitHub release at
> https://github.com/OSGeo/PROJ/releases/tag/9.4.1 a couple days ago but no
> new corresponding Zenodo record has been created at
> https://zenodo.org/records/5884394  , despite the GitHub integration
> being set up.
> I see from my account in https://zenodo.org/account/settings/github/ that
> the repository seems to have been disabled, although it was enabled last
> time. It seems something regularly disable repositories... ? I've just
> re-enabled it (as well as other repositories such as OSGeo/gdal and
> mapserver/mapserver that were disabled). Could you trigger the creation of
> a new record for the 9.4.1 release ? And what's the reason for this
> apparent disabling of repositories?  This isn't the first time it happens
> Best regards,
> Even Rouault
>
> """
>
> I'm proposing to add a step in HOWTO-RELEASE so we check that before doing
> the release : https://github.com/OSGeo/PROJ/pull/4162 , pending Zenodo
> figures out why the repositories get regularly disabled...
>
> Even
>
>
> Le 04/06/2024 à 12:20, Peter Löwe via PROJ a écrit :
>
> Javier, all,
>
> whoever handled the latest release should contact the Zenodo helpdesk
> https://zenodo.org/support about the missing version DOI.
>
> BTW, the PROJ page at OSGeo (https://www.osgeo.org/projects/proj/) seems
> to be outdated (PROJ 9.0.0).
>
> Best,
> Peter
>
>  
>
>
> *Gesendet:* Montag, 03. Juni 2024 um 21:56 Uhr
> *Von:* "Javier Jimenez Shaw"  
> *An:* "proj"  , "Peter Löwe"
>  
> *Betreff:* PROJ was not updated in Zenodo
> Hi PROJ
>
> I "was" by accident in Zenodo today, and I think it was not updated with
> the last release of PROJ
> https://zenodo.org/records/10818825
> Is it still failing, Peter?
>
> Cheers
> Javier
>
> .___ ._ ..._ .. . ._.  .___ .. __ . _. . __..  ...  ._ .__
>
> ___
> PROJ mailing 
> listPROJ@lists.osgeo.orghttps://lists.osgeo.org/mailman/listinfo/proj
>
> -- http://www.spatialys.com
> My software is free, but my time generally not.
>
> ___
> 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.4.0

[Vaclav Petras via grass-dev]

On Fri, 26 Apr 2024 at 05:36, Markus Neteler via grass-dev <
grass-dev@lists.osgeo.org> wrote:

> The remainder for the 8.4.0 milestone are (currently) 104 open pull
> requests (PRs) which still need testing or review or to be postponed:
> https://github.com/OSGeo/grass/pulls?q=is%3Aopen+is%3Apr+milestone%3A8.4.0
>

This is now down to 27. Kudos to Anna, myself and others.

I created a Future milestone discussed earlier to help with the management.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GSoC 2024 - Add EODAG support to GRASS GIS

[Vaclav Petras via grass-dev]

Hi and welcome Hamed,

On Mon, 18 Mar 2024 at 20:10, Hamed A. Elgizery via grass-dev <
grass-dev@lists.osgeo.org> wrote:

>
> Can you please guide me with any materials — if available — regarding the
> datasets? And if there is an issue “test of skills” available that is
> related to EODAG, since there are no issues associated with this task here:
> https://grasswiki.osgeo.org/wiki/GRASS_GSoC_Ideas_2024#:~:text=i.landsat.download-,Test%20of%20skills%3A,-GUI%3A%20Add%20space
>

This was suggested in the past by Luca as a test of skills for this topic:

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

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

Re: [GRASS-dev] GRASS Teams on GitHub

[Vaclav Petras via grass-dev]

On Fri, 8 Mar 2024 at 09:10, Ondřej Pešek  wrote:

>
> @Vaclav: Do you have some more points against the master-children
> schema? It seems that the general agreement is *for* the restructuring
> into parent and children teams. So far the only point against was "I
> didn't find team nesting particularly useful and we already had a
> couple of top-level teams."


...and I didn't see it working for GDAL with people both in the parent team
and child teams and repos being assigned to both levels.

How do you suggest we do it? Empty parent team without repos? Would that
look good?


> Although I appreciate all the work you
> dedicate to the GitHub management, I don't think that this is a valid
> point against when compared to the positive ones (although it's
> understandable that nobody wants to drop something that they have just
> created).
>

Thanks. It is more that before it was a high priority for me to get access
rights in order (access rights to individuals both directly and through
teams, inactive people from 2000s and early 2010s grandfathered into GitHub
write access, ...). These parent-child teams are low priority compared to
that.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] r.copy doesn't respect computational region??

[Vaclav Petras via grass-dev]

On Sat, 2 Mar 2024 at 07:04, Paulo van Breugel via grass-dev <
grass-dev@lists.osgeo.org> wrote:

>
>
> On March 2, 2024 1:00:23 AM GMT+01:00, Michael Barton via grass-dev <
> grass-dev@lists.osgeo.org> wrote:
> >It's been awhile since I've done this but I thought I remembered that a
> new map created with r.copy is constrained by the computational region.
> That does not seem to the case, at least in 8.4 dev. Maybe it has been this
> way for awhile (long while?) and I didn't notice it.
>


g.copy is a general tool which creates a copy of the data. Perhaps you are
interested in r.clip which is a raster tool and is driven by the
computational region as expected. r.clip clips according to the current
computation region (preserves original raster alignment  by default).

https://grass.osgeo.org/grass-stable/manuals/addons/r.clip.html


>
> I think, but I'm not 100% sure, that has always been the case.


Here is g.copy documentation from v6.4 it does not mention anything about
region. It seems to go back to US Army CERL.

https://github.com/OSGeo/grass-legacy/blob/2734c86fd5cb976b4a94b04a2cdc75b4613f6a77/general/manage/cmd/g.copy.html#L6


> In any case, it seems to be the logical behavior, otherwise it wouldn't be
> a true copy?
>

Are the different expectations coming from differences between raster tools
and general tools? With r.copy (as opposed to g.copy), you could perhaps
argue for respecting the computational region, but I think the "true copy"
expectation would still be strong.

Vaclav


>
>
> >
> >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<
> 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] GRASS GIS: backport of CI speed updates to G83?

[Vaclav Petras via grass-dev]

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

>
> In fact the slowest CI run determines how much time I have to wait
> with each release step (i.e., editing VERSION file, wait 1:30hs, do
> some steps, wait 1:30hs, create tarball, wait 1:30hs, reset VERSION
> file, wait 1:30hs ... which is a pain).
>

Isn't the issue the release procedure itself? It has a bunch of steps which
need to be done manually.

I counted 3 pushes which is what triggers the CI.

1) release VERSION file push
2) tag push
3) development VERSION file push

The release needs step 2 to be completed. We were doing step 2 only after
CI for step 1 completed to make sure the CI runs on the branch at that time
before the tag is made in step 2. I guess the reason to wait after step 2
before doing step 3 is to make sure that the automated part of the release
procedure linked to step 2 actually went through. Is this correct?

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

Re: [GRASS-dev] GRASS Teams on GitHub

[Vaclav Petras via grass-dev]

Huidae and Ondrej,

I recently restructured the teams to reflect GitHub workflows and resulting
needs for access (the original team structure was just used from Subversion
access). Another reason was getting a better control over who can change
the code directly (this is connected to the required PR reviews).

We have 11 teams to cover our 4 repos and different levels of access (plus
2+1 legacy teams). Less would not allow us to give people specific
properly-limited rights when needed, i.e., on a "need-to-have" basis. We
have the minimum number of teams to drive write access on repo-to-repo
basis to our 4 repos and make use of the 4 different relevant roles (4
Write teams, one for each repo, 1 Admin and 1 Maintain team for all repos,
1 Triage team, 1 special-purpose Triage team (discussion-moderators), 1
legacy Write (addons-subversion-committers), 1 legacy Triage
(subversion-committers), 1 legacy Read (docker-homebrew-users)). More would
be needed for specific task or organization reasons such as the current
grass-discussion-moderators. Another reason to add more (possibly nested
teams) would be when we would use it for reviews and/or notifications like
"someone from the Windows team needs to review this PR", but it seems we
are heading towards code owners rather than teams there (I don't pretend to
know what are the differences or overlaps here).

If we say we want to cut down the number of teams, we can remove one or
more of the following: 1 or 2 Subversion teams (legacy, but both are in use
now), homebrew-docker team (complete legacy), grass-addons-write (could be
merged with grass-write depending on how much it will be used, it has one
person who is not in grass-write), grass-promo-write (can be merged with
grass-website-write depending on in which way the grass-promo repo will be
used).

For comparison, GDAL has 2 teams for 3 repositories plus a top-level GDAL
team containing the two teams. gdal-admins has 9 members and the
gdal-committers team has 22 members (our grass-subversion-committers legacy
team has 33). gdal-admins has Admin for 2 repos and Write for 1 repo.
gdal-committers Write for 2 repos. The top-level GDAL team has 5 direct
members and 1 repo. The 3 repos are gdal, gdal-data, and shapelib (plus
there is 1 auto-updated repo and 2 legacy repos not managed using access
roles for teams). The two notable differences in the project structure
influencing the number and diversity of repos are that the GDAL website is
generated from the gdal repo and that GDAL drivers are either included in
gdal repo, (inactive) legacy repo or in separate repos (GDAL has 1 Write
team, we 3 extra teams). Additionally, we already had a need for a separate
Triage team and a GitHub Discussion-managing Triage team (2 extra teams).
We are not yet making use of the Maintain team (1 extra team).

More answers inline.

On Thu, 22 Feb 2024 at 14:51, Huidae Cho via grass-dev <
grass-dev@lists.osgeo.org> wrote:

> Ondrej,
>
> I agree with you that there are too many teams for GRASS [1] and they
> should be consolidated (or not, but at least moved) as child teams.
>
> Do we still need these subversion teams?
> * grass-subversion-committers
>  GRASS
> GIS Subversion committers
> * grass-addons-subversion-committers
>  GRASS
> GIS Addons Subversion committers
>

These are people who had access in the Subversion times. We want these past
Subversion-time contributors to have Triage rights (whatever that means).
The grass-addons repo works differently, so the Subversion-time group has
Write access there, but that can be changed in the future easily as this
group from pre-GitHub times is separate from the active group in
grass-addons-write.


> How is this team different from the above
> grass-addons-subversion-committers?
> * grass-addons-write
>  Maintainers of
> tools in GRASS GIS Addons with write access to the repository
>

This is the active team where new people would be added. The Subversion
team may move from Write to Triage in the future.


> How are these three teams different?
> * grass-admin  GRASS GIS
> repo administration team
> * grass-maintain  GRASS
> GIS repo settings maintenance team
> * grass-write  Maintainers
> of GRASS GIS with write access to the main repository
>

They have what GitHub calls Admin, Maintain, and Write access rights to the
repo. Write is only for code. Maintain is for some of the settings. for
Admin for access and security. See more here:

https://docs.github.com/en/organizations/managing-user-access-to-your-organizations-repositories/managing-repository-roles/repository-roles-for-an-organization


> I think we need this team.
> * 

Re: [GRASS-dev] GRASS GIS: backport of CI speed updates to G83?

[Vaclav Petras via grass-dev]

On Tue, 20 Feb 2024 at 06:45, Nicklas Larsson via grass-dev <
grass-dev@lists.osgeo.org> wrote:

>
> On 20 Feb 2024, at 10:14, Markus Neteler via grass-dev <
> grass-dev@lists.osgeo.org> wrote:
>
>
> In fact the slowest CI run determines how much time I have to wait
> with each release step (i.e., editing VERSION file, wait 1:30hs, do
> some steps, wait 1:30hs, create tarball, wait 1:30hs, reset VERSION
> file, wait 1:30hs ... which is a pain).
>
>
> I agree this is a case where we have limited ourself too much, with all
> those
> required 1.5 hrs tests, approval, etc. (not even [skip ci] would work) .
> What you
> would need is a (ideally) direct commit access or at least  “Rebase and
> merge”
> option to merge (thus enable a number of commits to be merged at one time,
> as opposed to "Squash and merge”).
>
> We must find a solution to improve this situation for preparing releases, I
> wouldn’t mind temporary lifting necessary constraints.
>

The backports and releases are done using direct commits and pushes. That's
how the rules are set, no bypass or exception is necessary for that.

I guess the issue is not that we can't bypass the check but that we want
the checks to pass because we don't want to base the release on a commit
with failing CI.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GSoC Ideas

[Vaclav Petras via grass-dev]

Seeing the new startup screen idea description, the "Proposals for a new
GRASS GIS startup mechanism" wiki page on Trac wiki might be a good read:

https://trac.osgeo.org/grass/wiki/wxGUIDevelopment/New_Startup

On Thu, 15 Feb 2024 at 14:11, Anna Petrášová via grass-dev <
grass-dev@lists.osgeo.org> wrote:

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

Re: [GRASS-dev] Renaming location to project

[Vaclav Petras via grass-dev]

Dear dev list,

While the decision at the PSC meeting was to merge the first batch of
renames to have it in for 8.4 [1], the PRs [2] will need reviews to be
merged. Anyone can leave an approving review. One approving review from a
member of the grass-write team [3] will be needed to enable merging. For
your convenience, here are the links to the PRs:

https://github.com/OSGeo/grass/pull/2993
https://github.com/OSGeo/grass/pull/3131
https://github.com/OSGeo/grass/pull/3130
https://github.com/OSGeo/grass/pull/3133
https://github.com/OSGeo/grass/pull/3134

Best,
Vaclav

[1] https://trac.osgeo.org/grass/wiki/PSC/Minutes/PSC_Meeting_20240209
[2] https://github.com/orgs/OSGeo/projects/2
[3] https://github.com/orgs/OSGeo/teams/grass-write



On Thu, 21 Dec 2023 at 10:45, Vaclav Petras  wrote:

> Dear users and developers,
>
> We have a new development which will likely touch everyone, so I would
> like to make sure that everyone is informed and can prepare for or even
> help with the changes.
>
> After years of discussions, we are renaming the "location" concept in
> GRASS GIS to "project". While we confirmed we want to keep all the
> advantages of the current data hierarchy in GRASS GIS, the term "location"
> makes explaining and working with the hierarchy difficult. The new term
> "project" was chosen for the concept because it aligns with the place the
> concept has in GRASS GIS and how other software packages are using the
> term. The term "project" is also already used by many people who are
> explaining GRASS GIS data hierarchy in workshops, classes, and papers.
>
> Main transition will happen for 8.4 and is designed to be backward
> compatible until the 9.0 release.
>
> Many PRs are already in place:
>
> https://github.com/orgs/OSGeo/projects/2
>
> This text is a summary of a longer text in the related issue:
>
> https://github.com/OSGeo/grass/issues/3121#issuecomment-1866473182
>
> Best,
> Vaclav
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Renaming location to project

[Vaclav Petras via grass-dev]

Dear users and developers,

We have a new development which will likely touch everyone, so I would like
to make sure that everyone is informed and can prepare for or even help
with the changes.

After years of discussions, we are renaming the "location" concept in GRASS
GIS to "project". While we confirmed we want to keep all the advantages of
the current data hierarchy in GRASS GIS, the term "location" makes
explaining and working with the hierarchy difficult. The new term "project"
was chosen for the concept because it aligns with the place the concept has
in GRASS GIS and how other software packages are using the term. The term
"project" is also already used by many people who are explaining GRASS GIS
data hierarchy in workshops, classes, and papers.

Main transition will happen for 8.4 and is designed to be backward
compatible until the 9.0 release.

Many PRs are already in place:

https://github.com/orgs/OSGeo/projects/2

This text is a summary of a longer text in the related issue:

https://github.com/OSGeo/grass/issues/3121#issuecomment-1866473182

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

Re: [GRASS-dev] Daily build for Windows outdated

[Vaclav Petras via grass-dev]

On Mon, 9 Oct 2023 at 02:41, Martin Landa  wrote:

>
> right, the build process was broken. Fixed. Martin
>


Thank you! Looks good. Revision 632b22970e is the latest on main.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Daily build for Windows outdated

[Vaclav Petras via grass-dev]

Dear Martin and grass-dev,

The daily build for Windows seems outdated to me. The file at

https://wingrass.fsv.cvut.cz/grass84/

is from today, but the commit hash is df2c0bc922 which is this commit:

https://github.com/OSGeo/grass/commit/df2c0bc922

from June 7. This is the date in the logs.

Can you please look into this?

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

Re: [GRASS-dev] How to reformat markdown to pass pre-commit?

[Vaclav Petras]

On Wed, 13 Sept 2023 at 15:13, Markus Neteler  wrote:

> Hi,
>
> I have updated doc/infrastructure.md in my local Git copy and fail to
> commit it in a new PR due to pre-commit linting checks:
>
>
> markdownlint.Failed
> ...
>
> I tried to use `mdformat` on the file but the result isn't compatible
> with markdownlint.
>
> Is there any other tool to auto-format the file (even a 90% solution is
> fine)?
>

I used these two in the past with GRASS GIS:

npx markdownlint-cli --fix  doc/infrastructure.md
npx prettier --print-width 80 -w  doc/infrastructure.md

I don't remember exactly, but I guess at least one worked okay.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Send GRASS news to mailing list

[Vaclav Petras]

I just realized this would also be a good match for the grass-announce
mailing list. To cross-post or not to cross-post?


https://lists.osgeo.org/pipermail/grass-announce/

On Fri, 1 Sept 2023 at 10:40, Veronica Andreo  wrote:

> Hi Vashek,
>
> Yes, it's a good idea to spread the news also via mailing lists
>
> Vero
>
> El vie., 1 sep. 2023 10:28, Markus Neteler  escribió:
>
>> Hi Vaclav,
>>
>> Just a hint: the email limit can be lifted easily. Just post and I (or
>> any other list admin) can approve it.
>>
>> Markus
>>
>>
>> Vaclav Petras  schrieb am Fr., 1. Sep. 2023, 14:53:
>>
>>> Dear all,
>>>
>>> Having the very nice post about the meeting in Prague and others at the
>>> GRASS website, I was thinking we should send this to the grass-user mailing
>>> list too and maybe grass-dev.
>>>
>>> Given the mailing list emails have size limitations and may end up
>>> potentially ASCII, I'm suggesting sending an email with a link to the new
>>> item and the first paragraph of the news item to the grass-user mailing
>>> list. So, the one for Prague, would look like this:
>>>
>>> """"
>>> Report of the GRASS GIS Community Meeting in Prague
>>>
>>> The GRASS GIS Community Meeting was held in the Czech Republic from June
>>> 2 to 6 at the Faculty of Civil Engineering of the Czech Technical
>>> University in Prague. The meeting was a milestone event to celebrate the
>>> 40th birthday of GRASS GIS and brought together users, supporters,
>>> contributors, power users and developers to celebrate, collaborate and
>>> chart the future of GRASS GIS.
>>>
>>> Read more at:
>>>
>>>
>>> https://grass.osgeo.org/news/2023_08_13_grass_community_meeting_prague_june_2023_report/
>>> """
>>>
>>> What do you think?
>>>
>>> Vaclav
>>> ___
>>> 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] Send GRASS news to mailing list

[Vaclav Petras]

Dear all,

Having the very nice post about the meeting in Prague and others at the
GRASS website, I was thinking we should send this to the grass-user mailing
list too and maybe grass-dev.

Given the mailing list emails have size limitations and may end up
potentially ASCII, I'm suggesting sending an email with a link to the new
item and the first paragraph of the news item to the grass-user mailing
list. So, the one for Prague, would look like this:


Report of the GRASS GIS Community Meeting in Prague

The GRASS GIS Community Meeting was held in the Czech Republic from June 2
to 6 at the Faculty of Civil Engineering of the Czech Technical University
in Prague. The meeting was a milestone event to celebrate the 40th birthday
of GRASS GIS and brought together users, supporters, contributors, power
users and developers to celebrate, collaborate and chart the future of
GRASS GIS.

Read more at:

https://grass.osgeo.org/news/2023_08_13_grass_community_meeting_prague_june_2023_report/
"""

What do you think?

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

Re: [GRASS-dev] [GRASS-user] OSGeo code sprint at Big Data from Space 2023, November, in Vienna

[Vaclav Petras]

I'm planning to participate remotely, mostly async. If anyone plans to
participate one way or another, let me know, we can connect.

Best,
Vaclav


On Wed, 2 Aug 2023 at 15:06, Markus Neteler  wrote:

> The Annual Code Sprint comes to Vienna (Austria)!
> The OSGeo Community Sprint 2023 will be hosted by the Big Data from
> Space 2023 (BiDS) event.
>
> BiDS brings together key actors from industry, academia, EU entities
> and government to reveal user needs, exchange ideas and showcase
> latest technical solutions and applications touching all aspects of
> space and big data technologies, providing a unique opportunity to
> discuss and present the most recent innovations and challenges
> encountered in the context of big data from space. The 2023 edition of
> BiDS will focus not only technologies enabling insight and foresight
> inferable from big data from space. Together, we want to emphasize how
> breakthrough space data driven technologies impact on society’s grand
> challenges, such as climate change and the green transition.
> The event, organized by the European Space Agency (ESA) together with
> the European Union Satellite Center (SatCen) and the Joint Research
> Center (JRC), will take place at the Austria Center Vienna, and counts
> with the support of the partners FFG, Austria in Space and the Federal
> Ministry Republic of Austria.
>
> Date: November 6 to 9, 2023
> Time: 9:00am to 1:30pm each day
>
> Details at:
> https://wiki.osgeo.org/wiki/OSGeo_Community_Sprint_2023
>
> A great occasion to meet in person!
> ___
> 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] Version DOI missing for GRASS 8.3.0

[Vaclav Petras]

On Tue, 8 Aug 2023 at 12:26, Markus Neteler  wrote:

> Hi Peter,
>
> On Tue, Aug 8, 2023 at 5:04 PM Peter Löwe  wrote:
> >
> > Hi Markus,
> > the licence ID for GRASS GIS 7.8.8. on its landing page reads:
> > "Other (Open)"
>
> I have seen it, too. Unfortunately not the precise licence description.
>
> > This setting goes back to GRASS GIS 7.8.6.
> > Since this is (just) landing page metadata, this can be changed after
> the minting of the DOI and the file upload into Zenodo.
> >
> > The landing page for GRASS GIS 8.2.0 (https://zenodo.org/record/6612307)
> has different licence metadata: "GNU General Public License v2.0 or later",
> which points to https://opensource.org/license/gpl-2-0/
> >
> > Did GRASS GIS 8.2.0 get maybe manually checked into Zenodo ?
>
> I am not aware that anyone manually uploaded a GRASS GIS release to Zenodo.
>
> > Otherwise this could be a Zenodo-sided bug ("worked before")..?
>
> Probably they treated non-SPDX conformant license identifiers (here:
> "GPL-2.0-or-later") differently?
> Just guessing: In the past they changed it to "Other (Open)" and now
> it is (randomly) failing?
>

I think it was two different things. The 7.8 branch info for Zenodo is just
picked from GitHub metadata, while 8.2 and 8.3 are using the CFF file.
Between the latest 8.2 and 8.3.0, Zenodo also happened to change how a
non-conformat license entry is handled.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Where is the GRASS legend file?

[Vaclav Petras]

Hi Michael,

On Thu, 20 Jul 2023 at 18:14, Michael Barton  wrote:

> According to the d.legend.vect manual, I should have a legend file
> somewhere for all vectors. Here is what it says in notes:
>
> "Module d.legend.vect draws vector legend based on legend file defined in
> shell environment variable GRASS_LEGEND_FILE. This file is automatically
> created and updated whenever d.vect command is used. User can create custom
> legend file and then use export GRASS_LEGEND_FILE=path/to/file in shell.
> GRASS GUI and MONITORS create the legend file automatically. By default the
> legend file is stored in grassdata/location/mapset/.tmp/user directory (in
> case of d.mon deeper in /monitor_name directory)."
>

It seems the documentation is wrong. Perhaps documenting an earlier state.

GUI puts all these files in a subdirectory of /tmp/. `find /tmp/ -name
"legend.txt"` reveals that.

The monitors (d.mon) put that indeed in the mapset .tmp directory, but it
is a longer path than the documentation suggests, for wx0, I have:

~/grassdata/nc_spm_08_grass7/mapset_name/.tmp/node_name/MONITORS/wx0/leg


> As a test, I made a vector areas file out of the landclass96_28 raster in
> the North Carolina demo dataset. I set the vector color table to match the
> original raster. That works fine. Now I'd like to make a legend out of
> this. But I can't find the file that is supposed to be generated
> automatically to use or examine.
>

If you just want to use it with d.legend.vect, there is actually nothing to
do. d.legend.vect will pick it up automatically just like in the example in
the documentation. On the other hand, if you want to modify it by hand, use
input and output parameters of d.legend.vect.

The whole GRASS_LEGEND_FILE part is hidden from the user and you use it
(only?) if you are using the other environment variables for rendering.
Perhaps this needs to be emphasized in the documentation. (?)


> It is not in  grassdata/location/mapset/.tmp/user directory
> /Users/cmbarton/Dropbox\
> \(ASU\)/GRASS_dropbox/grassdata_dropbox/nc_spm_08_grass7/spatialtech2023/.tmp
> This directory contains no files and only one empty folder ("OKED3863").
>
> The environmental variable GRASS_LEGEND_FILE appears to be empty
>

The variable is set internally for the commands which do the rendering, so
you cannot get to it otherwise. If you set up things yourself in the shell
or in Python, then you would also set up the variable.


> So can anyone help me find this missing file?
>

I hope this clarifies that. Please suggest edits to the documentation.

BTW, grass.jupyter.Map is used in the same way, i.e., no direct handling of
GRASS_LEGEND_FILE, just d.legend.vect (d_legend_vect). If you are
interested, the implementation is easier to digest than the wxGUI code:

https://github.com/OSGeo/grass/blob/main/python/grass/jupyter/map.py#L90

Best,
Vaclav


>
> 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] Contribution for GRASS Community Sprint

[Vaclav Petras]

Hi Brendan,

On Sat, 18 Mar 2023 at 23:43, Brendan  wrote:

> I would like to join the community sprint this year. Probably remotely,
> but possibly in person.
>

Great! We are planning for a good remote participation option. We still
need to plan the details... (I guess this is the first call for
volunteer(s) for planning the virtual/hybrid piece!)


> I was thinking about fixing the input parameters for GRASS algorithms in
> QGIS's processing toolbox.
> Many have wrong required parameters, defaults, and so forth. Lots of easy
> things to fix.
>

Oh, yes. This is right along the lines of what we are considering as one of
the topics. In fact, we would like to make it easier to update in the
future with some automation to decrease the maintenance burden. No firm
plans for that yet, but any help scripting this or testing this would be
great.


> If there will be any talks or discussions, I'd really like to hear about
> the current and future state of lidar in GRASS.
>

The main topic for the sprint in relation to this is probably CMake to get
PDAL support on Windows.

Best,
Vaclav


> Best, Brendan
> ___
> 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] CI test timeout

[Vaclav Petras]

Hi Stefan,

On Sun, 12 Mar 2023 at 08:45, Stefan Blumentrath 
wrote:

>
> After adding another case to the t.rast.algebra test, the tesuite
> occasionally fails due to test time-out. See:
>
> https://github.com/OSGeo/grass/actions/runs/4394593270/jobs/7699431483#step:11:236
> The t.rast.algebra test has quite a number of test cases...
>

Any temporal test can fail with timeout. Not only this one. I think this
one is most commonly failing because it has the most tests, not because it
is more wrong then the others.


>
> My question is, what is the appropriate solution here:
> 1) split up the test, so that tests savely finish within 300 seconds
> threshold? The drawback is that the creation of testdata in those tests
> often takes ~ 20 to 50 seconds,  which is an overhead in each testfile o
>

I think the split would just increase the time for good cases and while the
number of processes which may hang will remain the same.

I think I have some comments about it here:

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


> 2) increase the time-out limit a bit, so the test does not fail...
>

I think the tests hang, not simply take a little longer. Before the time
limit, they would take (the full) 6 hours. So, increasing the test time
limit would make it fail later, but that's all.

The actual problem is unknown, but I don't know if anyone tried like
100-500 tests in a row locally to see what happens. The test results are
available for download even when the tests fail (to help track down this
problem).

Vaclav


> 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] Version Numbering RFC Final Phase

[Vaclav Petras]

Dear all,

Please see the current draft of RFC: Version Numbering which is in PR 2357.
It is now almost ready and you can leave comments on GitHub or here. Most
important thing it brings is a continuous minor versioning line, i.e., the
next planned release - as you may have noticed - is 8.3, not 8.4 because we
will not be skipping odd numbers anymore.

https://github.com/OSGeo/grass/pull/2357

Best,
Vashek
___
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

[Vaclav Petras]

On Tue, 21 Feb 2023 at 13:19, Veronica Andreo  wrote:

>
> El vie, 17 feb 2023 a las 15:25, Markus Neteler ()
> escribió:
>
>>
>> Version scheme update: please note that we abandon the odd/even scheme
>> and go for semantic versioning, i.e. 8.3.x comes after the 8.2.x
>> series. See also the related RFC: Version Numbering
>> (https://github.com/OSGeo/grass/pull/2357).
>>
>
> Just wondering.. Should we adopt an RFC that has not yet been merged nor
> approved via motion? There's a list of tasks in the PR that still seems
> incomplete and I see that Vashek moved the milestone of the RFC to 8.4...
> I'm not trying to delay the release -either it is called 8.3 or 8.4, it is
> overdue- but IMO we need to agree on the RFC, no? Shall I prepare a motion
> and we approve a version 1 of the Version Numbering RFC?
>

Ideally, yes, but practically we can follow it already. We agreed at the
PSC meeting that we want to follow it, although we did not vote on actually
approving it because it was not finished. We also don't have any formal
procedure for numbering except tradition. There were also no negative
comments for the PR in the PR itself. Hence, the RFC in the PR is the
closest thing to an official guidance we have.

We are using the yet-unmerged Python version RFC in a similar way.

The version numbering PR did not make it through my triage when I was
cleaning PRs and issues before the release because it did not pass my rule
"ready or important to have in the 8.3 code".

I still agree that it is a potentially big change for those who actually
followed the version numbering, but I hope if there is some criticism of
that, we would know already.

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

Re: [GRASS-dev] RFC: variations of statistics in r.neighbors (and the stats lib)

[Vaclav Petras]

Hi Francesco,

On Wed, 1 Feb 2023 at 07:09, Francesco Paolo Lovergine 
wrote:

>
>
> ...or change quantile and quartile into a list of 1..2 comma separated
> values.
>
> Much better, isn't it?
>

Maybe, but explicit named arguments are nice, too.

Do you plan to open a PR? A more experimental code could also go to the
grass-addons repo.

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

[GRASS-dev] Reminder: Community sprint planning meeting

[Vaclav Petras]

If you want to join the sprint planning meeting in an hour or so, you need
to email me to get the link.

If you already got the link from me or as a PSC member, you can ignore this
email.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Community sprint planning meeting

[Vaclav Petras]

Given the feedback I have already received, let me emphasize that the
community sprint is really for all contributors, not only code
contributors! If you are interested in translations, documentation, event
organizing, or other things, the sprint is a good time to do that.

On Fri, 10 Feb 2023 at 14:03, Vaclav Petras  wrote:

> Dear all,
>
> I'm happy to announce we are planning a community sprint for the 40th
> birthday of GRASS GIS!
>
> If you are interested, we will meet on Friday, February 17 at 15:00 UTC
> [1]. Send me an email and I will send you a Zoom link.
>
> Best,
> Vashek
>
> [1]
> https://www.timeanddate.com/worldclock/meetingdetails.html?year=2023=2=17=15=0=0=179=51=48=25=197=37=248=176
>
>
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Community sprint planning meeting

[Vaclav Petras]

Dear all,

I'm happy to announce we are planning a community sprint for the 40th
birthday of GRASS GIS!

If you are interested, we will meet on Friday, February 17 at 15:00 UTC
[1]. Send me an email and I will send you a Zoom link.

Best,
Vashek

[1]
https://www.timeanddate.com/worldclock/meetingdetails.html?year=2023=2=17=15=0=0=179=51=48=25=197=37=248=176
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Proposal for using ClangFormat, replacing GNU indent, for C/C++ code formatting

[Vaclav Petras]

On Mon, 5 Dec 2022 at 08:07, Nicklas Larsson via grass-dev <
grass-dev@lists.osgeo.org> wrote:

>
> 1. We adapt the formatting policy using ClangFormat.
>

+1

I would prefer if formatting changes from GNU indent which can be done
separately are done separately. For Python & Black, I did that together but
1) in multiple PRs and 2) we lacked any formatting, so it was a little
different. Things like ReflowComments seem like a good second round.
(Sorry, I'm a little confused about your intention with unused
.clang-format and what will be in there.)


> 2. We implement "BreakBeforeBraces" rules according the "Stroustrup" style.
>

Given the lack of unified standard in C and C++, I'm for making choices
which bring the formatting closer to Python and Black which Stroustrup
seems to do.

Related to that, the in-line comments in the PR are modified to have one
space after the code while Black, i.e., our Python code, has two.


> 3. If there are no objections raised within a two weeks period, say until
> December 18, either to points 1 and/or 2 or even to this proposed deadline,
> the PR [1] will be merged and work can start on source code formatting.
>

My approach with Black was to do config+formatting+CI at once which has the
disadvantage of adding the commit with config+CI into
.git-blame-ignore-revs, but a comment in that file warns about that and it
is exactly what will happen when we change the formatting later on with
active CI (the formatting will have to go in together with config and CI
changes).


> 4. Any changes decided upon ought to be added to
> https://trac.osgeo.org/grass/wiki/Submitting/C
>

Yes. FYI, although details are unclear, the long-term plan for these
documents is to move them to code (based on a discussion at a PSC meeting).

Best,
Vaclav


>
>
> Cheers,
> Nicklas
>
>
>
>
>
> [1] https://github.com/OSGeo/grass/pull/2272
> [2] https://www.gnu.org/software/indent/
> [3] https://clang.llvm.org/docs/ClangFormat.html
> [4] https://github.com/OSGeo/grass/blob/main/utils/grass_indent.sh
> [5] https://clang.llvm.org/docs/ClangFormatStyleOptions.html
> [6] https://github.com/OSGeo/grass/pull/2272/files
>
> ___
> 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] GitHub backport label proposal

[Vaclav Petras]

On Tue, 22 Nov 2022 at 14:54, Nicklas Larsson via grass-dev <
grass-dev@lists.osgeo.org> wrote:

> ...In case that is the way the community choose to go then the label will
> have to be “backport releasebranch_8_2”, which is very long…
>

We could revisit the names of branches. The word branch seems unnecessary,
esp. when the readability is questionable anyway due to the two separate
words without any separator.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] GNU indent is confused by dglib macro code

[Vaclav Petras]

Dear all,

GNU indent is confused by code in dglib/misc-template.c and I can't really
blame it. I'm confused, too. It is hard to track the structure there.

indent says (also reported in #1630):

indent: ./lib/vector/dglib/misc-template.c:574: Error:Stmt nesting error.
indent: ./lib/vector/dglib/misc-template.c:655: Error:Unmatched 'else'
indent: ./lib/vector/dglib/misc-template.c:684: Error:Stmt nesting error.

All three seem to be connected to the two uses of DGL_FOREACH_EDGE which
are also the only two uses of this macro. There is also plenty of
ifdef-else-endif which might be confusing indent.

Any opinions on how to proceed here? I would like to see the code
simplified in the sense that it is easily readable by both humans and
machines, but it is not clear to me how to achieve it here.

The misc-template.c is included into "v1" and "v2" file to produce
different code through the ifdefs for DGlib graph versions 1 and 2.

Best,
Vaclav

[#1630] https://github.com/OSGeo/grass/issues/1630#issuecomment-1295442400
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GRASS GIS twitter account - was: Re: Fwd: [mapserver-users] new official twitter account

[Vaclav Petras]

Hi Jorge and all,

Are there any other accounts which need the same steps? E.g., YouTube?

Thanks,
Vaclav

On Tue, 8 Nov 2022 at 04:38, Markus Neteler  wrote:

> Hi Jorge,
>
> On Mon, Nov 7, 2022 at 7:59 PM Jorge Cornejo  wrote:
> >
> > Is there anyone from GRASS that can officially take over this twitter
> account?
>
> Yes, done. Vero and I have taken over.
>
> > I'm in the process of decommissioning my server and many websites and
> their associated email addresses will not be working anymore.  I plan to
> shut it all down by the end of this year (2022).
> >
> > If you guys could forward this to the appropriate individual will be
> greatly appreciated.
>
> Thanks for all your support!
>
>
> Markus
>
> >
> > Jorge Cornejo
> > Phone: 8186136404
> > Email: xch...@gmail.com
> > Website: http://www.jorgecornejo.com
> > Website: http://hackerspacela.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] Various grass-promo repo updates

[Vaclav Petras]

On Thu, 27 Oct 2022 at 12:35, Markus Neteler  wrote:

> On Thu, Oct 27, 2022 at 5:32 AM Vaclav Petras 
> wrote:
> >
> > I'm adding some new material to the grass-promo repository [1]. I can
> also share some of the designs through Sticker Mule, too, so ask me if you
> want some.
>

That's cool stuff, thanks!
>
> (and I have already seen it in the wild, it looks really good :-) )
>

Thanks.

It's worth emphasizing that sharing the designs through Sticker Mule is
easy and the designs skip proofing phase as long it is exactly the same
physical thing and you want to use Sticker Mule.

The repo is good when you want to modify the designs, use them on something
else, or use a different provider.


> I have now added the 'grass-admin' group (at time you, Martin Landa,
> me) to the repo.
>

Thank you. Here is what I did:

* master renamed to main
* squash and merge is the only option
* has readme
* has social preview image (a quickly created file, updated in grass, added
to grass-addons, website)
* only up to 2 branches and tags can be updated in one push (also for
grass, grass-addons, website)

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

[GRASS-dev] Various grass-promo repo updates

[Vaclav Petras]

Dear all,

I'm adding some new material to the grass-promo repository [1]. I can also
share some of the designs through Sticker Mule, too, so ask me if you want
some.

I took the opportunity and added a trivial readme file which may clarify
when to add things to it (that is any time). While with free online repo
hosting services, the repo is not necessary for sharing, it is still a good
place for potentially reusable artwork and other resources.

Finally, I have merge/write access, but can I get admin access to rename
master to main and enable "squash and merge" only?

Best,
Vaclav

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

Re: [GRASS-dev] PSDriver

[Vaclav Petras]

On Thu, 13 Oct 2022 at 15:43, Markus Neteler  wrote:

> On Thu, Oct 13, 2022 at 8:35 AM Brad ReDacted 
> wrote:
> >
> > Can someone tell me what spec the (enhanced) postscript driver
> > (lib/psdriver) adheres to? I am having difficulty looking up one of the
> > parameters (box erase, in particular - erase.c).
>
> Good question, the driver did not receive much attention in the last 15
> years:
>

I think it would be fair to just select whatever reasonable modern spec and
make it adhere to that, i.e., modernize. (Or just focus on Cairo, that's
another option.)


> and this ticket:
>
> Cairo and PS drivers display only one raster or vector for SVG and PS
> https://trac.osgeo.org/grass/ticket/3033
>

That's definitely a major issue. Perhaps easier to solve for the PS driver.

Not really related to the PS driver, but related to reading images: A
doable feature seems to be adding raster image rendering to the Cairo
driver. It can read an existing image as a background to draw on, but we
are missing functions to draw raster images as overlays (something which
would be accessed using e.g. d.image or used for symbols).

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

Re: [GRASS-dev] hacktober, docs

[Vaclav Petras]

On Fri, 7 Oct 2022 at 16:59, Daniel Torres  wrote:

>
> I'd say it would be good to create some issues for non coding enthusiasts
>

Here is one. It is the "will stay open forever" type.

https://github.com/OSGeo/grass/issues/2594
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] hacktober, docs

[Vaclav Petras]

On Fri, 7 Oct 2022 at 09:18, Daniel Torres  wrote:

>
> I see that all issues tagged with 'Hacktober' are coding related, do you
> guys have any idea of non coding stuff that could work? like first-issue
> but non coding? mmm I don't know, documentation, missing examples, and so
> on?
>

Images for documentation are often missing, e.g.:

https://grass.osgeo.org/grass82/manuals/raster_graphical.html

(Often it is enough to use the existing example to generate the image.)
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] hacktober, docs

[Vaclav Petras]

On Thu, 6 Oct 2022 at 13:46, Daniel Torres  wrote:

> Hi guys,
> are we doing anything for hacktober? I see some 2021 issues in the grass
> repo tagged as hacktober,
>

...and the grass and grass-addons repos are tagged and I'm ready to do some
reviews. I just didn't have any capacity to do the promotion myself and I
don't know how many people here follow Hacktoberfest (you can, after all,
do the proper Octoberfest), but yes, we are active although there was no
announcement.


> but wondering if it would make sense to make some announcement on the site
> (maybe a dialog when landing in the home, or somewhere in the home )
>

Yes.


> and if there are  non coding (docs and so on) or first issues we could add
> for this (for the grass website or the grass repo).
>

I did not check the new rules in relation to the website, but non-coding
PRs in grass and grass-addons will count for sure and with the label, we
are set.


> Also, asking again about the docs improvements. Vaclav mentioned some time
> ago he would like to see some work on that side, and on JavaScript checks
> in Super-Liner .
>

The checks are more straightforward, so a better fit for Hacktoberfest.
Also, having HTML/CSS/JS checks in place is a good basis for changing the
documentation because we can merge with greater confidence.


> As said before, I'm mostly on frontend stuff and happy to help with that
> (although I'd need some guidance as I'm not familiar with the code and so
> on...) or if you think I'd be helpful in other things, let me know.
>

If you see something which hurts your eyes or feels really clunky, that
might be a place to start (that might be code, CLI, or documentation on
mobile). Someone will likely be able to point you to the right code. ...or
suggest trying something else first :-)

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

Re: [GRASS-dev] Should we become stricter with failures in addon CI?

[Vaclav Petras]

Hi Stefan,

On Wed, 5 Oct 2022 at 07:18, Stefan Blumentrath 
wrote:
>
> Test success rate is at ~70 % and if I add a new failing test, that is
not considered a test failure, so I have to go in and check if the added
test actually succeeded.

The tooling improved since the rule was set up, so I would say, yes, it
should mirror the setup in the core where not-yet-fixed tests are excluded
in config.

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

Re: [GRASS-dev] pre-commit hooks

[Vaclav Petras]

Hi Stefan,

On Wed, 5 Oct 2022 at 07:31, Stefan Blumentrath 
wrote:
>
> ... come up with a suggestion for how to implement (including opt-out /
opt-in possibilities)...

I thought pre-commit hooks are always opt-in. In any case, that's probably
the first thing which would inform other decisions.

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

Re: [GRASS-dev] C code indented

[Vaclav Petras]

On Sat, 17 Sept 2022 at 04:57, Wolf Bergenheim 
wrote:

> On Tue, 13 Sept 2022 at 09:33, Vaclav Petras  wrote:
>
>>
>> Formatting needs to be enforced in the CI. This can be done with
>> something like re-indent followed by git diff.
>>
>>
> Maybe something like this could be used?
> https://github.com/marketplace/actions/clang-format-check  Note that it
> doesn't actually format the code, but would complain like the current black
> formatter for python 樂
>
> or perhaps https://github.com/material-foundation/clang-format-ci seems
> to do the same, and leaves inline comments
>

Yes, please. We need to transition to clang-format and one of these
clang-format wrappers for CI will be needed. You can open an experimental
PR if you want. See also #2272.

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

Re: [GRASS-dev] C code indented

[Vaclav Petras]

I have resolved all indentation-related conflicts in the open PRs. The
procedure worked well on all PRs except one which had changes in
directories which were not indented yet.

The remaining issues are:

There are directories where indent reports an error, esp. due to
ambiguities in the current code formatting. These are not indented yet.
These would be best resolved by separate PRs, possibly separating the
ambiguity fixes from the overall formatting changes (esp. given that we
want to ignore purely formatting changes in git blame).

Formatting needs to be enforced in the CI. This can be done with something
like re-indent followed by git diff.

Best,
Vaclav

On Sat, 27 Aug 2022 at 14:06, Vaclav Petras  wrote:

> Dear all,
>
> Most of the C and C++ code was indented using our
> ./utils/grass_indent_ALL.sh script at the FOSS4G 2022 sprint. This will
> help to indent code for PRs and with the transition to clang-format.
>
> Directories with files which indent reports issues for were not updated,
> because more changes are needed in the code.
>
> This may create conflicts in some existing PR which modify C code. If you
> have a conflict related to this (old PR may have other conflicts too), you
> can follow this procedure:
>
> Indent your code:
>
> ./utils/grass_indent.sh db/drivers/mysql/create_table.c
>
> Commit the change:
>
> git commit -m "Indent PR code" db/drivers/mysql/create_table.c
>
> Update upstream/main branch:
>
> git fetch upstream
>
> Merge into your branch upstream/main:
>
> git merge --strategy=recursive --strategy-option=ours upstream/main
>
> Let me know if you have any questions,
> Vaclav
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] C code indented

[Vaclav Petras]

Dear all,

Most of the C and C++ code was indented using our
./utils/grass_indent_ALL.sh script at the FOSS4G 2022 sprint. This will
help to indent code for PRs and with the transition to clang-format.

Directories with files which indent reports issues for were not updated,
because more changes are needed in the code.

This may create conflicts in some existing PR which modify C code. If you
have a conflict related to this (old PR may have other conflicts too), you
can follow this procedure:

Indent your code:

./utils/grass_indent.sh db/drivers/mysql/create_table.c

Commit the change:

git commit -m "Indent PR code" db/drivers/mysql/create_table.c

Update upstream/main branch:

git fetch upstream

Merge into your branch upstream/main:

git merge --strategy=recursive --strategy-option=ours upstream/main

Let me know if you have any questions,
Vaclav
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] mkhtml fails on Windows with UnicodeDecodeError

[Vaclav Petras]

On Wed, Aug 24, 2022, 4:51 AM Martin Landa  wrote:

> Hi Vaclav,
>
> st 24. 8. 2022 v 10:41 odesílatel Vaclav Petras 
> napsal:
>
>> The lib/gis/parser_html.c puts iso-8859-1 into the HTML files (I just
>> checked that now), so that's what an HTML reader should be using. That's of
>> course not what we want at this point. It just should be UTF-8 everywhere.
>>
>> 
>>
>
> +1 for switching to UTF-8
>
> The HTML files may already use UTF-8 (?), but the parser may emit HTML in
>> system-dependent encoding. However, the source code it is using should be
>> UTF-8 or more likely it is simply ASCII, so perhaps not much to worry about.
>>
>
> I am not sure why the parser should emit HTML in system-dependent
> encoding. Why simply not use UTF-8 as suggested in PR [1]?
>

It should emit UTF-8, I don't know what it does now.


> Back to the original problem, how can we solve the problem with
> compilation on Windows 2016 without changing the code base of grass78
> significantly? BTW, I was able to compile grass78 on the same machine a few
> weeks ago and I don't see any related changes in v.random.html... (?)
>

The PR looks okay on the surface. Maybe you can just remove the problematic
character in 7.8.


> Martin
>
> --
> 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] mkhtml fails on Windows with UnicodeDecodeError

[Vaclav Petras]

Hi Martin,

On Wed, 24 Aug 2022 at 04:25, Martin Landa  wrote:

>
> the question is also why we are using default OS encoding to decode HTML
> pages [1]. Couldn't we simply use UTF-8 regardless of OS system locale?
>

This seems to be some general confusion around that, or more likely just
some legacy code.

The lib/gis/parser_html.c puts iso-8859-1 into the HTML files (I just
checked that now), so that's what an HTML reader should be using. That's of
course not what we want at this point. It just should be UTF-8 everywhere.



The HTML files may already use UTF-8 (?), but the parser may emit HTML in
system-dependent encoding. However, the source code it is using should be
UTF-8 or more likely it is simply ASCII, so perhaps not much to worry about.

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

Re: [GRASS-dev] hi

[Vaclav Petras]

 Now, I see I misunderstood here. The Discussion is about the communication
channels, not about the website. I guess my comments are still generally
valid, but irrelevant here. Sorry for the noise.

On Mon, 1 Aug 2022 at 14:58, Vaclav Petras  wrote:

> ...but I should add: Let's see what works.
>
> On Mon, 1 Aug 2022 at 14:56, Vaclav Petras  wrote:
>
>> There is no difference in discussing things in the PR or issue versus in
>> a Discussion in terms of notifications, no? If it is about development, it
>> should be part of this mailing list or the PRs/issues in the relevant repo.
>> I don't see what Discussion would add here. ...that's of course different
>> from considering the more "chatty" channels.
>>
>> On Mon, 1 Aug 2022 at 14:17, Daniel Torres  wrote:
>>
>>> Venga, muchas gracias Veronica.
>>>
>>> Nice, thanks, I'll open a discussion. I mean, I'm just joining and
>>> possibly there are some downsides of doing so and most probaly it has
>>> already been discussed, but I think it would be useful to ease the
>>> communication.
>>>
>>> On Mon, Aug 1, 2022 at 12:58 PM Veronica Andreo 
>>> wrote:
>>>
>>>> Hola Daniel,
>>>>
>>>> None of those at time, but you could open a new discussion in github
>>>> (though that is in the main grass repo...)
>>>>
>>>> Vero
>>>>
>>>> El lun., 1 ago. 2022 19:51, Daniel Torres 
>>>> escribió:
>>>>
>>>>> thanks Veronica, then I'll  try with the ones suggested in Hugo website
>>>>>
>>>>> (is there another communication method you guys use, like Slack,
>>>>> discord or something like kind of more direct or  quick questions and
>>>>> stuff? )
>>>>>
>>>>> On Mon, Aug 1, 2022 at 11:43 AM Veronica Andreo 
>>>>> wrote:
>>>>>
>>>>>> Hello Daniel,
>>>>>>
>>>>>> IIRC, I suggested using something similar to what wowchemy (former
>>>>>> hugo academic) has, but the path chosen was different. Paulo, also made a
>>>>>> suggestion, but I didn't have the time to try, honestly. I think it's all
>>>>>> in the PRs and probably this issue too:
>>>>>> https://github.com/OSGeo/grass-website/issues/19
>>>>>>
>>>>>> Vero
>>>>>>
>>>>>> El lun, 1 ago 2022 a las 15:55, Daniel Torres ()
>>>>>> escribió:
>>>>>>
>>>>>>> Thanks guys,
>>>>>>> I'm ok with starting on the website.
>>>>>>>
>>>>>>> About the search, in Hugo website they suggest a couple of methods
>>>>>>> https://gohugo.io/tools/search/ , have those been tried?
>>>>>>>
>>>>>>> On Sun, Jul 31, 2022 at 3:29 AM Veronica Andreo <
>>>>>>> veroand...@gmail.com> wrote:
>>>>>>>
>>>>>>>> Hi Daniel,
>>>>>>>>
>>>>>>>> Welcome! Besides what Vashek pointed out, if you feel comfortable
>>>>>>>> starting with something for the website, we are missing a search engine
>>>>>>>> there. There were a couple of attempts in the past but none of them 
>>>>>>>> worked
>>>>>>>> fully as expected. Have a look at the PRs here:
>>>>>>>> https://github.com/OSGeo/grass-website/pulls
>>>>>>>>
>>>>>>>> Best,
>>>>>>>> Vero
>>>>>>>>
>>>>>>>> El sáb, 30 jul 2022 a las 23:46, Vaclav Petras (<
>>>>>>>> wenzesl...@gmail.com>) escribió:
>>>>>>>>
>>>>>>>>> Hi Daniel,
>>>>>>>>>
>>>>>>>>> Welcome. That sounds great. For Python, check this presentation
>>>>>>>>> I'm preparing for FOSS4G where are I describe how to do good PRs 
>>>>>>>>> which fix
>>>>>>>>> coding standards and the load of tools which can be applied:
>>>>>>>>>
>>>>>>>>> https://wenzeslaus.github.io/code-quality-measures-foss4g-2022/#/45
>>>>>>>>>
>>>>>>>>> JavaScript at this point means starting with your own idea 

Re: [GRASS-dev] hi

[Vaclav Petras]

...but I should add: Let's see what works.

On Mon, 1 Aug 2022 at 14:56, Vaclav Petras  wrote:

> There is no difference in discussing things in the PR or issue versus in a
> Discussion in terms of notifications, no? If it is about development, it
> should be part of this mailing list or the PRs/issues in the relevant repo.
> I don't see what Discussion would add here. ...that's of course different
> from considering the more "chatty" channels.
>
> On Mon, 1 Aug 2022 at 14:17, Daniel Torres  wrote:
>
>> Venga, muchas gracias Veronica.
>>
>> Nice, thanks, I'll open a discussion. I mean, I'm just joining and
>> possibly there are some downsides of doing so and most probaly it has
>> already been discussed, but I think it would be useful to ease the
>> communication.
>>
>> On Mon, Aug 1, 2022 at 12:58 PM Veronica Andreo 
>> wrote:
>>
>>> Hola Daniel,
>>>
>>> None of those at time, but you could open a new discussion in github
>>> (though that is in the main grass repo...)
>>>
>>> Vero
>>>
>>> El lun., 1 ago. 2022 19:51, Daniel Torres 
>>> escribió:
>>>
>>>> thanks Veronica, then I'll  try with the ones suggested in Hugo website
>>>>
>>>> (is there another communication method you guys use, like Slack,
>>>> discord or something like kind of more direct or  quick questions and
>>>> stuff? )
>>>>
>>>> On Mon, Aug 1, 2022 at 11:43 AM Veronica Andreo 
>>>> wrote:
>>>>
>>>>> Hello Daniel,
>>>>>
>>>>> IIRC, I suggested using something similar to what wowchemy (former
>>>>> hugo academic) has, but the path chosen was different. Paulo, also made a
>>>>> suggestion, but I didn't have the time to try, honestly. I think it's all
>>>>> in the PRs and probably this issue too:
>>>>> https://github.com/OSGeo/grass-website/issues/19
>>>>>
>>>>> Vero
>>>>>
>>>>> El lun, 1 ago 2022 a las 15:55, Daniel Torres ()
>>>>> escribió:
>>>>>
>>>>>> Thanks guys,
>>>>>> I'm ok with starting on the website.
>>>>>>
>>>>>> About the search, in Hugo website they suggest a couple of methods
>>>>>> https://gohugo.io/tools/search/ , have those been tried?
>>>>>>
>>>>>> On Sun, Jul 31, 2022 at 3:29 AM Veronica Andreo 
>>>>>> wrote:
>>>>>>
>>>>>>> Hi Daniel,
>>>>>>>
>>>>>>> Welcome! Besides what Vashek pointed out, if you feel comfortable
>>>>>>> starting with something for the website, we are missing a search engine
>>>>>>> there. There were a couple of attempts in the past but none of them 
>>>>>>> worked
>>>>>>> fully as expected. Have a look at the PRs here:
>>>>>>> https://github.com/OSGeo/grass-website/pulls
>>>>>>>
>>>>>>> Best,
>>>>>>> Vero
>>>>>>>
>>>>>>> El sáb, 30 jul 2022 a las 23:46, Vaclav Petras (<
>>>>>>> wenzesl...@gmail.com>) escribió:
>>>>>>>
>>>>>>>> Hi Daniel,
>>>>>>>>
>>>>>>>> Welcome. That sounds great. For Python, check this presentation I'm
>>>>>>>> preparing for FOSS4G where are I describe how to do good PRs which fix
>>>>>>>> coding standards and the load of tools which can be applied:
>>>>>>>>
>>>>>>>> https://wenzeslaus.github.io/code-quality-measures-foss4g-2022/#/45
>>>>>>>>
>>>>>>>> JavaScript at this point means starting with your own idea which
>>>>>>>> may or may not be what you are looking for. Website is certainly one 
>>>>>>>> option.
>>>>>>>>
>>>>>>>> I would really like to see changes in the documentation (aka HTML
>>>>>>>> manual pages):
>>>>>>>>
>>>>>>>> https://grass.osgeo.org/grass83/manuals/
>>>>>>>>
>>>>>>>> ...but that's certainly "bring your own idea." It likely involves
>>>>>>>> some HTML and CSS design, but perhaps there is something more 
>>>>>>>> functional
>&g

Re: [GRASS-dev] hi

[Vaclav Petras]

There is no difference in discussing things in the PR or issue versus in a
Discussion in terms of notifications, no? If it is about development, it
should be part of this mailing list or the PRs/issues in the relevant repo.
I don't see what Discussion would add here. ...that's of course different
from considering the more "chatty" channels.

On Mon, 1 Aug 2022 at 14:17, Daniel Torres  wrote:

> Venga, muchas gracias Veronica.
>
> Nice, thanks, I'll open a discussion. I mean, I'm just joining and
> possibly there are some downsides of doing so and most probaly it has
> already been discussed, but I think it would be useful to ease the
> communication.
>
> On Mon, Aug 1, 2022 at 12:58 PM Veronica Andreo 
> wrote:
>
>> Hola Daniel,
>>
>> None of those at time, but you could open a new discussion in github
>> (though that is in the main grass repo...)
>>
>> Vero
>>
>> El lun., 1 ago. 2022 19:51, Daniel Torres  escribió:
>>
>>> thanks Veronica, then I'll  try with the ones suggested in Hugo website
>>>
>>> (is there another communication method you guys use, like Slack, discord
>>> or something like kind of more direct or  quick questions and stuff? )
>>>
>>> On Mon, Aug 1, 2022 at 11:43 AM Veronica Andreo 
>>> wrote:
>>>
>>>> Hello Daniel,
>>>>
>>>> IIRC, I suggested using something similar to what wowchemy (former hugo
>>>> academic) has, but the path chosen was different. Paulo, also made a
>>>> suggestion, but I didn't have the time to try, honestly. I think it's all
>>>> in the PRs and probably this issue too:
>>>> https://github.com/OSGeo/grass-website/issues/19
>>>>
>>>> Vero
>>>>
>>>> El lun, 1 ago 2022 a las 15:55, Daniel Torres ()
>>>> escribió:
>>>>
>>>>> Thanks guys,
>>>>> I'm ok with starting on the website.
>>>>>
>>>>> About the search, in Hugo website they suggest a couple of methods
>>>>> https://gohugo.io/tools/search/ , have those been tried?
>>>>>
>>>>> On Sun, Jul 31, 2022 at 3:29 AM Veronica Andreo 
>>>>> wrote:
>>>>>
>>>>>> Hi Daniel,
>>>>>>
>>>>>> Welcome! Besides what Vashek pointed out, if you feel comfortable
>>>>>> starting with something for the website, we are missing a search engine
>>>>>> there. There were a couple of attempts in the past but none of them 
>>>>>> worked
>>>>>> fully as expected. Have a look at the PRs here:
>>>>>> https://github.com/OSGeo/grass-website/pulls
>>>>>>
>>>>>> Best,
>>>>>> Vero
>>>>>>
>>>>>> El sáb, 30 jul 2022 a las 23:46, Vaclav Petras ()
>>>>>> escribió:
>>>>>>
>>>>>>> Hi Daniel,
>>>>>>>
>>>>>>> Welcome. That sounds great. For Python, check this presentation I'm
>>>>>>> preparing for FOSS4G where are I describe how to do good PRs which fix
>>>>>>> coding standards and the load of tools which can be applied:
>>>>>>>
>>>>>>> https://wenzeslaus.github.io/code-quality-measures-foss4g-2022/#/45
>>>>>>>
>>>>>>> JavaScript at this point means starting with your own idea which may
>>>>>>> or may not be what you are looking for. Website is certainly one option.
>>>>>>>
>>>>>>> I would really like to see changes in the documentation (aka HTML
>>>>>>> manual pages):
>>>>>>>
>>>>>>> https://grass.osgeo.org/grass83/manuals/
>>>>>>>
>>>>>>> ...but that's certainly "bring your own idea." It likely involves
>>>>>>> some HTML and CSS design, but perhaps there is something more functional
>>>>>>> that can be done. An alternative to this is migrating to Sphinx first, 
>>>>>>> but
>>>>>>> that's just a thought from the past.
>>>>>>>
>>>>>>> Now when I think about it, the full JavaScript checks in Super-Liner
>>>>>>> are not enabled, so that's perhaps a small JavaScript task to tackle 
>>>>>>> before
>>>>>>> starting a bigger project (that's up to you!).
>>>>>>>
>>>>>>> Let me know if there is any other info which would be helpful.
>>>>>>>
>>>>>>> Best,
>>>>>>> Vaclav
>>>>>>>
>>>>>>>
>>>>>>> On Sat, 30 Jul 2022 at 14:18, Daniel Torres 
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hi guys, I'm Daniel , I work as Front end dev. I would like to
>>>>>>>> contribute to the project, as I find it really nice. I have experience 
>>>>>>>> with
>>>>>>>> JS and front end stuff, but also with Python.
>>>>>>>>
>>>>>>>> Happy to contribute, but don't really know where to start. (Maybe
>>>>>>>> something on the website side?)
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>>   Daniel
>>>>>>>> ___
>>>>>>>> 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] hi

[Vaclav Petras]

Hi Daniel,

Welcome. That sounds great. For Python, check this presentation I'm
preparing for FOSS4G where are I describe how to do good PRs which fix
coding standards and the load of tools which can be applied:

https://wenzeslaus.github.io/code-quality-measures-foss4g-2022/#/45

JavaScript at this point means starting with your own idea which may or may
not be what you are looking for. Website is certainly one option.

I would really like to see changes in the documentation (aka HTML manual
pages):

https://grass.osgeo.org/grass83/manuals/

...but that's certainly "bring your own idea." It likely involves some HTML
and CSS design, but perhaps there is something more functional that can be
done. An alternative to this is migrating to Sphinx first, but that's just
a thought from the past.

Now when I think about it, the full JavaScript checks in Super-Liner are
not enabled, so that's perhaps a small JavaScript task to tackle before
starting a bigger project (that's up to you!).

Let me know if there is any other info which would be helpful.

Best,
Vaclav


On Sat, 30 Jul 2022 at 14:18, Daniel Torres  wrote:

> Hi guys, I'm Daniel , I work as Front end dev. I would like to contribute
> to the project, as I find it really nice. I have experience with JS and
> front end stuff, but also with Python.
>
> Happy to contribute, but don't really know where to start. (Maybe
> something on the website side?)
>
> Cheers,
>   Daniel
> ___
> 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 birthday toast tomorrow, July 29th!

[Vaclav Petras]

To celebrate GRASS birthday, discuss latest developments, and more, join us
in one hour using Zoom at:

https://ncsu.zoom.us/j/92129342971?pwd=Um1DSlhtYWwrL3Vwa0tlc3hzNHBQdz09

Topic: GRASS GIS Birthday 2022
Time: 15:00 UTC
Meeting ID: 921 2934 2971
Passcode: 454117


On Thu, 28 Jul 2022 at 03:33, Veronica Andreo  wrote:

> Hello everyone!!
>
> Tomorrow, the calendar marks 39 years of GRASS development! 邏 Let's
> celebrate with some beverage and make a toast in an online meeting at 15
> UTC (See local times here:
> https://www.timeanddate.com/worldclock/meetingdetails.html?year=2022=7=29=15=0=0=48=25=207=197
> )
>
> Vashek will provide a link before the scheduled time! Keep an eye on the
> mailing list!
>
> See you tomorrow!
> Vero
>
> --
> Dra. Verónica Andreo
> Investigadora Asistente 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] password security

[Vaclav Petras]

On Mon, 25 Jul 2022 at 23:38, Brad ReDacted 
wrote:

>
> Is there any objection to adding yet another dependency?
>

To keep this moving, I think there are no objections to adding security if
the new dependency is optional. Optional dependencies and maintainable code
is generally a good start to get something accepted.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] password security

[Vaclav Petras]

On Mon, 25 Jul 2022 at 23:38, Brad ReDacted 
wrote:

>
> I hate adding dependencies, but security is best left to security
> experts and I strongly advocate against duplicating security related code.
>

If this security feature is really needed, then the best practices seem to
indicate a specialized library is needed, for example the Open Source
Security Foundation (OpenSSF) Best Practices state:

"If the software produced by the project is an application or library, and
its primary purpose is not to implement cryptography, then it SHOULD only
call on software specifically designed to implement cryptographic
functions; it SHOULD NOT re-implement its own." ("The term SHOULD indicates
a criterion that is normally required, but there may exist valid reasons in
particular circumstances to ignore it. However, the full implications must
be understood and carefully weighed before choosing a different course.")

FLOSS Best Practices Criteria (Passing Badge)
https://bestpractices.coreinfrastructure.org/en/criteria/0

Criteria Discussion
https://bestpractices.coreinfrastructure.org/en/criteria_discussion
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] GRASS GIS 8.2.0 Released

[Vaclav Petras]

I'm pleased to announce that GRASS GIS 8.2.0 was released!

The 8.2.0 release of GRASS GIS is now available with results from the GSoC
2021 and many other additions. A new grass.jupyter package is now included
for interacting with Jupyter notebooks. Single window graphical user
interface is available in GUI settings. r.series and three other modules
are newly parallelized. Additionally, the release includes a series of
scripting, packaging, and reproducibility improvements.

For all 220+ changes, see our detailed announcement with the full
contributors and list of features and bugs fixed at GitHub / Releases /
8.2.0 . Special thanks
to GSoC students, their mentors, and first-time contributors!

Packages and installers are now available for Windows, macOS, Debian,
Fedora, and Gentoo with more coming soon.

See more at grass.osgeo.org / News
.
___
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.2.0

[Vaclav Petras]

I can do whatever. Let's chat off list about the details.

On Mon, Jun 6, 2022, 7:46 AM Markus Neteler  wrote:

> Hi Vero
>
> Just edit straight in GitHub.
> This should work. Once done, ping me and I trigger the Hugo script on the
> server.
>
> Markus
>
>
>
> Veronica Andreo  schrieb am Mo., 6. Juni 2022,
> 13:39:
>
>> I merged Caitlin news yesterday, but I forgot to change the date in the
>> YAML heading of the file, which was planned for thursday, the day I weekly
>> post on twitter... So, the news is merged but does not appear in the
>> website yet and does not make sense to post about it... difficult day
>> yesterday, sorry
>>
>> Vashek, if you want to merge the release news then go ahead, I tweet
>> about that and on thursday, we do Caitlin post when it appears online.
>>
>> Vero
>>
>> El dom, 5 jun 2022 a las 1:06, Vaclav Petras ()
>> escribió:
>>
>>>
>>>
>>> On Sat, Jun 4, 2022, 5:07 PM Veronica Andreo 
>>> wrote:
>>>
>>>>
>>>> I had planned to merge Caitlin's news tomorrow and tweet about that on
>>>> Monday, so then we can post the release,
>>>>
>>>
>>> That works for me!
>>>
>>>> ___
>> 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.2.0

[Vaclav Petras]

On Sat, Jun 4, 2022, 5:07 PM Veronica Andreo  wrote:

>
> I had planned to merge Caitlin's news tomorrow and tweet about that on
> Monday, so then we can post the release,
>

That works for me!

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

[Vaclav Petras]

On Sat, 4 Jun 2022 at 16:20, Martin Landa  wrote:

>
> standalone installer available for testing at
>
>
> https://grass.osgeo.org/grass82/binary/mswindows/native/WinGRASS-8.2.0-1-Setup.exe
>

Thank you, Martin!
___
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.2.0

[Vaclav Petras]

Dear all,

8.2.0RC2 was released:

https://github.com/OSGeo/grass/releases/tag/8.2.0RC2

Please test it and package it as you see fit.

The final release will be approximately in a week in accordance with RFC 4:
Release Procedure (Draft).

https://trac.osgeo.org/grass/wiki/RFC/4_ReleaseProcedure

There are 2-3 open PRs, one bug fix and some release procedure things,
which will go in before the final release.

https://github.com/OSGeo/grass/milestone/8

Best,
Vaclav


On Sun, 1 May 2022 at 15:01, Vaclav Petras  wrote:

> Dear all,
>
> New planned dates for 8.2.0 [1]:
>
> May 13: 8.2.0RC2
> May 20: 8.2.0 (final)
>
> This is in accordance with RFC 4: Release Procedure (Draft) [2].
>
> One way to test it is using the mybinder Binder [3].
>
> Best,
> Vaclav
>
> [1] https://github.com/OSGeo/grass/milestone/8
> [2] https://trac.osgeo.org/grass/wiki/RFC/4_ReleaseProcedure
> [3]
> https://mybinder.org/v2/gh/OSGeo/grass/8.2.0RC1?urlpath=lab%2Ftree%2Fdoc%2Fnotebooks
>
> On Fri, 29 Apr 2022 at 09:34, Vaclav Petras  wrote:
>
>> Dear all,
>>
>> 8.2.0RC1 was released.
>>
>> https://github.com/OSGeo/grass/releases/tag/8.2.0RC1
>>
>> Please test and package it as you see fit.
>>
>> Best,
>> Vaclav
>>
>
___
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.2.0

[Vaclav Petras]

On Fri, 6 May 2022 at 18:04, Martin Landa  wrote:

>
> Windows standalone installer
>

Thank you, Martin!
___
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.2.0

[Vaclav Petras]

Dear all,

New planned dates for 8.2.0 [1]:

May 13: 8.2.0RC2
May 20: 8.2.0 (final)

This is in accordance with RFC 4: Release Procedure (Draft) [2].

One way to test it is using the mybinder Binder [3].

Best,
Vaclav

[1] https://github.com/OSGeo/grass/milestone/8
[2] https://trac.osgeo.org/grass/wiki/RFC/4_ReleaseProcedure
[3]
https://mybinder.org/v2/gh/OSGeo/grass/8.2.0RC1?urlpath=lab%2Ftree%2Fdoc%2Fnotebooks

On Fri, 29 Apr 2022 at 09:34, Vaclav Petras  wrote:

> Dear all,
>
> 8.2.0RC1 was released.
>
> https://github.com/OSGeo/grass/releases/tag/8.2.0RC1
>
> Please test and package it as you see fit.
>
> Best,
> Vaclav
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] [release planning] GRASS GIS 8.2.0

[Vaclav Petras]

Dear all,

8.2.0RC1 was released.

https://github.com/OSGeo/grass/releases/tag/8.2.0RC1

Please test and package it as you see fit.

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

Re: [GRASS-dev] lib/rast3d/error.c

[Vaclav Petras]

Hi Brad,

On Tue, 26 Apr 2022 at 12:37, Brad ReDacted 
wrote:

> Hello,
>
> Is there any particular reason lib/rast3d/error.c exists? All I see is
> duplicated functionality to lib/gis/error.c with different function
> names.
>

I think the general idea there is that the rast3d library uses a different
function than the modules. A function which only prints, does not call
fatal (does not call exit or long jump), and can be customized
independently. In other words, Rast3d_error is not the same as
G_fatal_error.


> Are there any objections to deleting lib/rast3d/error.c and using the
> equivalent functions of lib/gis/error.c?
>

Generally, no objections from me. I don't think rast3d lib needs different
functions than the rest of the code. On the other hand, the idea of
different functions for the library and the modules seems worth preserving
or pursuing further, but in the context of the whole library, not just
rast3d.

Best,
Vaclav


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

Re: [GRASS-dev] Planning 8.2.0

[Vaclav Petras]

Dear all,

I have created the release branch for 8.2 series [1] and we are close to
releasing version 8.2.0 [2]. RC1 will follow shortly.

As a reminder, 8.2.0 will contain most of the GSoC 2021 work done by Linda,
Caitlin, and Aaron (opt-in single window, grass.jupyter, several parallel
modules).

Creation of the release branch also means that the main branch is now ready
for larger changes.

Best,
Vaclav

[1] https://github.com/OSGeo/grass/tree/releasebranch_8_2
[2] https://github.com/OSGeo/grass/milestone/8


On Wed, 23 Mar 2022 at 11:52, Vaclav Petras  wrote:

> Here is the current state for 8.0.2 and 8.2.0 milestones:
>
> 8.0.2 due: March 31
> 8.2.0 due: April 05
>
> 8.0.2 PRs: 7
> 8.0.2 issues: 11
> 8.2.0 PRs: 19
> 8.2.0 issues: 0
>
> Most of the 11 issues for 8.0.2 are Windows-related. 5 PRs are GSoC 2021
> related.
>
> Please, resolve your PRs or move them to 8.4.0.
>
> Let me know if you are interested in having a call about the upcoming
> releases.
>
> Best,
> Vaclav
>
> 8.0.2 https://github.com/OSGeo/grass/milestone/15
> 8.2.0 https://github.com/OSGeo/grass/milestone/8
>
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Reasons for GDAL dynamic library load in code?

[Vaclav Petras]

Merged into the main branch as adde62ef.

https://github.com/OSGeo/grass/commit/adde62ef22bad90c337580afff925be4e646abe2

On Tue, 12 Apr 2022 at 10:09, Vaclav Petras  wrote:

> Given that the original motivation is unknown and that we would not do the
> same now, i.e., we would treat GDAL as any other library, it seems we can
> go ahead.
>
> The only reason I can think of is GRASS driver for GDAL which introduces a
> cyclic dependency, but if anything is needed, it is perhaps solved in GDAL.
>
> On Thu, 7 Apr 2022 at 11:10, Vaclav Petras  wrote:
>
>> Hi devs,
>>
>> We are about to remove dynamic loading of GDAL from the raster library
>> code in #2290. GDAL will then be loaded as any other library by the system.
>>
>> https://github.com/OSGeo/grass/pull/2290
>>
>> Currently, the libraries are loaded with dlopen and LoadLibrary and
>> GDAL_DYNAMIC is set to enable that code. This was introduced in 2008 by
>> Glynn in r33559.
>>
>>
>> https://github.com/OSGeo/grass/commit/265039761908433c58b07b9b47fcb16f5126e88c
>> https://trac.osgeo.org/grass/changeset/33559
>>
>> To be sure removing it completely is a good step, I wanted to check the
>> original motivation. Any ideas? The commit message doesn't mention the
>> motivation and I'm not getting anything from Internet searches.
>>
>> Let me know what you think.
>>
>> Best,
>> Vaclav
>>
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] About fixing test

[Vaclav Petras]

Unfortunately, v.out.lidar is not built in the CI, so not a good candidate
here, try r.contour, r.in.gdal, v.what, g.search.modules, anything in
gunittest. pygrass or temporal might be more difficult, but still not that
special.

On Mon, 18 Apr 2022 at 13:02, Adithya Ambapurkar  wrote:

> I have selected decimation_test.py and tried to run it in jupyterlab. But
> it shows v.out.lidar no such file or directory. So I changed the path using
> os.chdir but it shows permission denied for v.out.lidar. How to fix this
> error and file
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] About pull request

[Vaclav Petras]

Great. I have left a new round of reviews.

#2311 looks hopeful and #2310 is not necessary, so no further changes are
needed in either at this point. Focus on fixing some tests.



On Mon, 18 Apr 2022 at 09:20, Adithya Ambapurkar  wrote:

> I have created pull requests for test_module_assertions.py and for
> updating gunittest.cfg file. Check the pr if any mistake is there. Thank
> you sir for your support and guidance. With your help I could create the
> first pull request for osgeo. Should I test other files also in
> gunittest.cfg for gsoc 2022.
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] About fixing exisiting test

[Vaclav Petras]

On Sun, 17 Apr 2022 at 07:30, Adithya Ambapurkar  wrote:

> ...used %%python...
>

As I mentioned earlier, I don't recommend this approach, but yes, you can
(and have to) use this in the notebook. However, that's for the notebook
only. Unrelated to the actual test code.


> It ran all tests successfully but in output it says raster map not found.
>

This may or may not be a problem. If the tests pass, chances are it is the
correct and expected output. For example, if the test checks the behavior
when a non-existent raster map is used, the message is expected and inside
the test, it likely expects failure rather than success with, e.g., the
assertModuleFail function you have seen.


> ...How to convert it to pytest code as both are different and is there any
> documentation which compares gunittest and pytest. Pytest docs and
> gunittest docs are separate. Example for assertModule and assertModuleFail
> what is its equivalent in pytest.
>

This is all for the actual summer project including the documentation.

All pytest is experimental now and does not have any documentation.
However, general pytest documentation applies:

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

Re: [GRASS-dev] About fixing exisiting test

[Vaclav Petras]

If the test run okay and doesn't fail, go ahead and create a PR to enable
it.

Don't try to convert any tests to pytest. That's a topic for the summer.
You should write a new possibly simple test using pytest.

On Sun, Apr 17, 2022, 7:30 AM Adithya Ambapurkar  wrote:

> I have selected test_module_assertions.py and used %%python as mentioned
> earlier in jupyterlab notebook along with grass gis code. It ran all tests
> successfully but in output it says raster map not found. How to get the
> raster map and should i convert this code from gunitttest to pytest. How to
> convert it to pytest code as both are different and is there any
> documentation which compares gunittest and pytest. Pytest docs and
> gunittest docs are separate. Example for assertModule and assertModuleFail
> what is its equivalent in pytest. What should I do next?
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] About fixing existing tests

[Vaclav Petras]

On Fri, 15 Apr 2022 at 03:49, Adithya Ambapurkar  wrote:

> I have selected test_gunittest_doctests.py file
>

Perhaps try something else. This one may have additional challenges because
it is doctest. Although it actually runs for me in Binder without errors.


> and tried to run on jupyterlab on binder. I included the necessary grass
> code and when i run it gives some error
>

There is more than one way to do it, but given what you tried, the best way
to do it for you is to in a notebook:

```
# Import Python standard library we need.
import os
import sys
import subprocess

# Ask GRASS GIS where its Python packages are.
sys.path.append(
subprocess.check_output(["grass", "--config", "python_path"],
text=True).strip()
)

# Run the tests.
# (The path is where the source code (with tests) is. In Binder, the source
code is in the user's home directory.)
os.chdir(os.path.expanduser("~"))
!python -m grass.gunittest.main --location nc_basic_spm_grass7
--location-type nc
```

The above works for me in a notebook in Binder and it should work locally
as well.

Alternatively, in Binder, you can also use the Terminal (File > New
Launcher > Terminal) and use `grass` command with --exec instead of the
above Python notebook code. That's what I usually use locally in the
terminal on Ubuntu. An example of the that is here:

https://github.com/OSGeo/grass/blob/main/.github/workflows/test_thorough.sh

The doc for running tests in general is here:

https://grass.osgeo.org/grass80/manuals/libpython/gunittest_running_tests.html


> Without the grass code if i run nothing happens
>

Not sure what you mean, but I get an error with your notebook. Anyway, I
suggest *not* to run it this way, although you could make it work by adding
%%python (cell magic) at the top of the cell. Then it works, runs tests,
and they pass. I didn't investigate that further. I didn't think of this as
an experimental method before, but probably not a good way of running tests
in general.


> I also tried to run locally and installed grass, pytest, ipython packages
> using pip but it gives grass.gunittest module not found error
>

Running pytest should not give you "grass.gunittest not found" because
grass.gunittest is not used when running pytest. (Note that you need the
latest code from the main branch to run pytest otherwise pytest will fail
with lots of errors.)

Anyway, the important step likely missing is that you need to add GRASS
Python packages on path.

I run pytest on Ubuntu with the following:

PYTHONPATH=`grass --config python_path`:$PYTHONPATH
LD_LIBRARY_PATH=/path/to/compiled/grass/dist.x86_64-pc-linux-gnu/lib pytest
/test/file/to/run/name.py -vv

Or, in multiple steps:

export PYTHONPATH=`grass --config python_path`:$PYTHONPATH
export LD_LIBRARY_PATH=/path/to/compiled/grass/dist.x86_64-pc-linux-gnu/lib
pytest /test/file/to/run/name.py -vv

You can see another example in the pytest.yml workflow for GitHub Actions:

https://github.com/OSGeo/grass/blob/main/.github/workflows/pytest.yml
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Reasons for GDAL dynamic library load in code?

[Vaclav Petras]

Given that the original motivation is unknown and that we would not do the
same now, i.e., we would treat GDAL as any other library, it seems we can
go ahead.

The only reason I can think of is GRASS driver for GDAL which introduces a
cyclic dependency, but if anything is needed, it is perhaps solved in GDAL.

On Thu, 7 Apr 2022 at 11:10, Vaclav Petras  wrote:

> Hi devs,
>
> We are about to remove dynamic loading of GDAL from the raster library
> code in #2290. GDAL will then be loaded as any other library by the system.
>
> https://github.com/OSGeo/grass/pull/2290
>
> Currently, the libraries are loaded with dlopen and LoadLibrary and
> GDAL_DYNAMIC is set to enable that code. This was introduced in 2008 by
> Glynn in r33559.
>
>
> https://github.com/OSGeo/grass/commit/265039761908433c58b07b9b47fcb16f5126e88c
> https://trac.osgeo.org/grass/changeset/33559
>
> To be sure removing it completely is a good step, I wanted to check the
> original motivation. Any ideas? The commit message doesn't mention the
> motivation and I'm not getting anything from Internet searches.
>
> Let me know what you think.
>
> Best,
> Vaclav
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Reasons for GDAL dynamic library load in code?

[Vaclav Petras]

Hi devs,

We are about to remove dynamic loading of GDAL from the raster library code
in #2290. GDAL will then be loaded as any other library by the system.

https://github.com/OSGeo/grass/pull/2290

Currently, the libraries are loaded with dlopen and LoadLibrary and
GDAL_DYNAMIC is set to enable that code. This was introduced in 2008 by
Glynn in r33559.

https://github.com/OSGeo/grass/commit/265039761908433c58b07b9b47fcb16f5126e88c
https://trac.osgeo.org/grass/changeset/33559

To be sure removing it completely is a good step, I wanted to check the
original motivation. Any ideas? The commit message doesn't mention the
motivation and I'm not getting anything from Internet searches.

Let me know what you think.

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

Re: [GRASS-dev] About gsoc project

[Vaclav Petras]

Hi Adithya,

Welcome to the grass-dev mailing list. I'll answer inline:

On Wed, 6 Apr 2022 at 11:03, adinayyu  wrote:
> ...my statement of proposal for the osgeo grass gis project.

Good topic. The pytest is important!

> How and what should i contribute to the project or osgeo before
submitting my proposal.

The "test of skills" specified on the wiki still applies. You will need to
be familiar with both the new (pytest) and the old (grass.gunittest)
system. So, start with fixing a couple failing tests. There is a list of
failing tests in the .gunittest.cfg file in the root directory of the repo.

https://github.com/OSGeo/grass/blob/main/.gunittest.cfg

You should also write some new tests. This can now be done with both
grass.gunittest and pytest. You will get familiar with the grass.gunittest
tests while fixing the existing tests. There are a couple of experimental
tests which use pytest. Here are some simple examples:

https://github.com/OSGeo/grass/blob/main/python/grass/script/tests/utils_test.py
https://github.com/OSGeo/grass/blob/main/python/grass/script/tests/grass_script_setup_test.py

How much do you need to write? More is better because you will get familiar
with more aspects of the testing, but start small. One PR with one fixed
test file from .gunittest.cfg.

> Give feedback and suggestions if there is any mistake in the proposal.

Good for starters. You will need to extend it beyond what is on the wiki to
increase chances of your application. Doing the above tasks will help you
in that.

> Apart from mailing lists, are there any other platforms to interact with
the community.

When you submit a PR, people will react with comments and reviews. That's
the most direct way of getting feedback for your code. For general
questions about development, the grass-dev mailing list is the best. We
have also grass-user focused on running the software itself and GitHub
Discussions.

First of all, you should familiarize yourself with GRASS GIS and create a
development environment for GRASS GIS on your computer - that is compile
the code and make sure you can modify it and compile again - if you are
using Windows, the best way is to set up a Ubuntu virtual machine and do
the development there.

You can skip ahead a little bit and use GRASS GIS online through JupyterLab
on Binder. Not a good way for doing development, but a great way of getting
familiar with the software through Python (most relevant for your GSoC
topic) and even the build environment because there is actually all the
code and you have access to the command line from there.

8.0.1 release:
https://mybinder.org/v2/gh/OSGeo/grass/8.0.1?urlpath=lab%2Ftree%2Fdoc%2Fnotebooks%2Fbasic_example.ipynb
development version:
https://mybinder.org/v2/gh/OSGeo/grass/main?urlpath=lab%2Ftree%2Fdoc%2Fnotebooks%2Fgrass_jupyter.ipynb

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

Re: [GRASS-dev] Planning 8.2.0

[Vaclav Petras]

Here is the current state for 8.0.2 and 8.2.0 milestones:

8.0.2 due: March 31
8.2.0 due: April 05

8.0.2 PRs: 7
8.0.2 issues: 11
8.2.0 PRs: 19
8.2.0 issues: 0

Most of the 11 issues for 8.0.2 are Windows-related. 5 PRs are GSoC 2021
related.

Please, resolve your PRs or move them to 8.4.0.

Let me know if you are interested in having a call about the upcoming
releases.

Best,
Vaclav

8.0.2 https://github.com/OSGeo/grass/milestone/15
8.2.0 https://github.com/OSGeo/grass/milestone/8

On Sun, 27 Feb 2022 at 15:33, Vaclav Petras  wrote:

> TLDR: 8.2.0 with GSoC 2021 work (single window, Jupyter, parallel modules)
> is scheduled for April 5.
>
> Action items: For PRs, merge now or move the milestone to 8.4.0. For
> issues, create a new PR now or move to 8.4.0.
>
>
> Dear all,
>
> We are entering a preparation phase for 8.2 release. (As you may or may
> not know, we are currently skipping odd minor numbers because they are used
> to make the development version, so there is no 8.1 release.)
>
> On a couple occasions, we discussed that the 8.2 release contains the GSoC
> 2021 work, i.e., the release will contain Linda's single window, Caitlin's
> grass.jupyter, and Aaron's parallelized modules.
>
> Unfortunately, I can't find this in PSC minutes or elsewhere perhaps
> because the main discussion happened in the Birthday call. We also lack a
> formalized roadmap, release schedule [1], and release procedure [2] is a
> draft. However, the current state and plan are well represented in the
> GitHub milestone [3].
>
> Because 8.2 is a "GSoC 2021" release, the plan is to release it on April
> 5th before GSoC 2022 starts. Now, it's time to finish and merge any PRs
> which are almost done. For PRs which are not ready to be merged, move them
> to the 8.4.0 milestone. Similarly, for issues, resolve them now or move
> them to 8.4.0.
>
> Importantly, there is no need for 8.2.0 to contain anything else except
> what is already on main plus the GSoC 2021 work because the plan is that
> 8.2 is whatever 8.0 is plus an experimental version of single window,
> grass.jupyter, and most of the newly parallelized modules.
>
> Best,
> Vaclav
>
> [1] https://trac.osgeo.org/grass/wiki/RFC/4_ReleaseProcedure
> [2] https://trac.osgeo.org/grass/wiki/Release/Schedule
> [3] https://github.com/OSGeo/grass/milestone/8
>
___
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?

[Vaclav Petras]

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

> ...There were attempts to do this [2, 3], but numerous problem
> arose...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.
>

Additionally, the C++ support in GNU Indent is limited:

While an attempt was made to get indent working for C++, it will not do a
good job on any C++ source except the very simplest.
https://www.gnu.org/software/indent/manual/indent/Bugs.html

I think the note in the docs was there even before C++11.


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

I don't think the style is set in stone. This is perhaps for a next phase,
but unless a strong standard emerges for C/C++, we may consider switching
to something which is close to Black given our mixed code base. Function
signatures and calls would be the big change there. However, the closing
parenthesis on a separate line typical to Black is available only in the
upcoming ClangFormat 14.

On the other hand, yielding to some 3rd party standard seems like a good
idea especially for all the C++ syntax.


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

+1. Being tool-independent is not possible here and ClangFormat seems to do
the job.


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

You can run a specific version locally using Docker thanks to a related
GitHub Action:

https://github.com/DoozyX/clang-format-lint-action#run-locally

Harder to integrate in your editor, but at least something. (Yes, your
favorite editor may already have support for ClangFormat.)
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Question regarding GRASS_NOTIFY

[Vaclav Petras]

On Fri, 4 Mar 2022 at 10:09, Nicklas Larsson via grass-dev <
grass-dev@lists.osgeo.org> wrote:

> Couldn’t the desired outcome
> of using GRASS_NOTIFY be implemented in another way?
>

The purpose was interactive use from the command line I suppose, so for
these cases users can set a convenient alias for sending the signal or a
prefix command to use with the display commands (to call the command and
then send the signal) like `ni d.rast elevation` where `ni` is the
command/alias. Adding something similar to a script has even a smaller
overhead, although it too requires you making sure it happens every time
instead of the one-time GRASS_NOTIFY settings. (I'm assuming here that
signal handling in the imgview programs is not removed.)
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Planning 8.2.0

[Vaclav Petras]

TLDR: 8.2.0 with GSoC 2021 work (single window, Jupyter, parallel modules)
is scheduled for April 5.

Action items: For PRs, merge now or move the milestone to 8.4.0. For
issues, create a new PR now or move to 8.4.0.


Dear all,

We are entering a preparation phase for 8.2 release. (As you may or may not
know, we are currently skipping odd minor numbers because they are used to
make the development version, so there is no 8.1 release.)

On a couple occasions, we discussed that the 8.2 release contains the GSoC
2021 work, i.e., the release will contain Linda's single window, Caitlin's
grass.jupyter, and Aaron's parallelized modules.

Unfortunately, I can't find this in PSC minutes or elsewhere perhaps
because the main discussion happened in the Birthday call. We also lack a
formalized roadmap, release schedule [1], and release procedure [2] is a
draft. However, the current state and plan are well represented in the
GitHub milestone [3].

Because 8.2 is a "GSoC 2021" release, the plan is to release it on April
5th before GSoC 2022 starts. Now, it's time to finish and merge any PRs
which are almost done. For PRs which are not ready to be merged, move them
to the 8.4.0 milestone. Similarly, for issues, resolve them now or move
them to 8.4.0.

Importantly, there is no need for 8.2.0 to contain anything else except
what is already on main plus the GSoC 2021 work because the plan is that
8.2 is whatever 8.0 is plus an experimental version of single window,
grass.jupyter, and most of the newly parallelized modules.

Best,
Vaclav

[1] https://trac.osgeo.org/grass/wiki/RFC/4_ReleaseProcedure
[2] https://trac.osgeo.org/grass/wiki/Release/Schedule
[3] https://github.com/OSGeo/grass/milestone/8
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GRASS 8.0 support in GDAL and QGIS

[Vaclav Petras]

On Fri, 25 Feb 2022 at 09:07, Sebastiaan Couwenberg 
wrote:

>
> If we want to stop using --prefix=/usr/lib and have FHS complianance
> while also having the shared libraries in the default library search
> path several changes in GRASS will be required.
>
> The resulting structure should result in something like:
>
>   /etc/grassconfiguration files
>   /usr/bin  executables
>   /usr/lib  shared libraries
>   /usr/lib/python3/dist-packages/grass  python package
>   /usr/libexec/grassexecutable helpers
>   /usr/share/grass  architecture independent files
>   /usr/share/manmanual pages
>

Makes sense. Any good examples of how to do this with Autotools, esp. given
that macOS and Windows still need a single directory?


> This assumes that the grass shared libraries should not be considered
> private which does seem to be the case with their use by libgdal-grass
> being the exception.
>

We keep a stable API anyway for custom user executables such as addons, so
not private in that sense. Libraries can also be accessed from Python
through an API which wraps ctypes calls.

I'm not sure what is the current situation in QGIS, but at least
historically, that would be another exception, so perhaps not an exception
at all, but a rule.

The executables like g.region are somewhat internal, so that's perhaps the
/usr/libexec/grass group.

Alternatively the GRASS executables need to have RPATH set, e.g. with:
>
>   -Wl,-rpath,/usr/lib/grass80/lib
>

I'm not sure what are the risks involved here. I have seen -rpath-link used
in the code, so that's not good enough.


> To remove the need for changing the library search path. This is the
> road of least resistance.
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GRASS 8.0 support in GDAL and QGIS

[Vaclav Petras]

On Fri, 25 Feb 2022 at 01:25, Sebastiaan Couwenberg 
wrote:

> On 2/24/22 15:23, Vaclav Petras wrote:
> > On Thu, 24 Feb 2022 at 03:33, Sebastiaan Couwenberg wrote:
> >> Should we perhaps take this opportunity to move the grass libraries to
> >> default library search paths as raised on the debian-gis list?
> >>
> >>https://lists.debian.org/debian-gis/2021/12/msg00023.html
> >
> > I vote yes. I think the reasons to do this are no longer valid. Doing it
> > the standard way seems to me to be the best way forward. Any
> > suggestions/PRs?
>
> Not using --prefix=/usr/lib will violate FHS, so not an option for the
> Debian package.
>

Using --prefix now results in every file from GRASS being installed into
--prefix, so I assume the current --prefix behavior is wrong from Debian
perspective, yes? Any suggestions on correct behavior?
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GRASS 8.0 support in GDAL and QGIS

[Vaclav Petras]

Hi Bas,

On Thu, 24 Feb 2022 at 03:33, Sebastiaan Couwenberg 
wrote:

>
> Should we perhaps take this opportunity to move the grass libraries to
> default library search paths as raised on the debian-gis list?
>
>   https://lists.debian.org/debian-gis/2021/12/msg00023.html
>

I vote yes. I think the reasons to do this are no longer valid. Doing it
the standard way seems to me to be the best way forward. Any
suggestions/PRs?

Similarly, the Python package or packages are not on a standard path either.

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

[Vaclav Petras]

On Wed, 23 Feb 2022 at 16:47, Helmut Kudrnovsky  wrote:

> >However, there are still a number of 8.0.1-labeled PRs open:
> >
> https://github.com/OSGeo/grass/issues?q=is%3Aissue+milestone%3A8.0.1+is%3Aopen
>
> [Bug] winGRASS is missing PROJ utilits (proj, cs2cs) bug Windows
> [Bug] Broken "List available extensions" on Windows bug Windows
> [Bug] Error when launching GRASS GIS 8.0.0-RC1-1 on Windows bug Windows
>
> IMHO nothing to block 8.0.1 ...
>

All three moved to 8.0.2.
___
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.0.1

[Vaclav Petras]

On Wed, 23 Feb 2022 at 12:37, Markus Neteler  wrote:

> On Sun, Feb 20, 2022 at 2:06 PM Markus Neteler  wrote:
> >
> > Hi devs,
> >
> > (8.0.1 milestone: https://github.com/OSGeo/grass/milestone/9)
> >
> > I still see backport candidate(s) in
> > -
> https://github.com/OSGeo/grass/issues?q=is%3Aopen+is%3Aissue+label%3Abackport_needed+milestone%3A8.0.1
>
> Empty now.
>
> However, there are still a number of 8.0.1-labeled PRs open:
>
> https://github.com/OSGeo/grass/issues?q=is%3Aissue+milestone%3A8.0.1+is%3Aopen
>
> How to deal with that? May all be bumped to 8.0.2?
>

I moved anything inactive for more than two weeks to 8.0.2 (both issues and
PRs). I don't think we need to have any discussion to do that.

I also moved to 8.0.2 any PRs with a missing review. 1 PR by MarkusM didn't
have the backport label and looked like material for a future minor release
(moved to 8.2). No PRs remain.

3 issues related to Windows remain (generally, unresolved issues without
blocker label should be moved before release, but perhaps some of these are
solved since there is activity today?).

https://github.com/OSGeo/grass/pulls?q=is%3Aopen+is%3Apr+milestone%3A8.0.1+sort%3Aupdated-desc
https://github.com/OSGeo/grass/issues?q=is%3Aopen+is%3Aissue+milestone%3A8.0.1+sort%3Aupdated-desc



> 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] GRASS + WSL

[Vaclav Petras]

On Wed, 23 Feb 2022 at 04:56, Brad ReDacted 
wrote:

>
> I'm going to cc: the list because I'm not sure how to address this.
>

Thanks. That's actually the right thing to do. :-) See also:

https://grasswiki.osgeo.org/wiki/Mailing_list_etiquette#Responding_to_other_posts
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS-PSC] difficult to get GRASS source code package

[Vaclav Petras]

On Mon, 14 Feb 2022 at 14:22, Veronica Andreo  wrote:

>
> Currently, there's a link to releases  in the first entry of
> https://grass.osgeo.org/download/ that points to
> https://github.com/OSGeo/grass/releases. I agree that esp for 8.0.0 the
> link to the tarball means a lot of browsing down.
>

Or instead of the releases page to that tags page I linked above. The links
(both .tar.gz and .zip) are more readily available there. The target
audience is technical anyway, so perhaps this is a preferred view at this
point in the workflow.

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

Re: [GRASS-dev] [GRASS-PSC] difficult to get GRASS source code package

[Vaclav Petras]

Hi Michael,

This looks more like a grass-dev topic, than grass-psc. I'm adding
grass-dev, please remove grass-psc when (if) you reply.

I'll let others comment on the tarball and website and comment on the Git
and GitHub part. +1 for Nickals' answer.

Git is definitely a valid way of getting source code for a build and
perhaps a preferred one since there is all the extra metadata for files.
Maybe we should work on clarifying whether that's really the preferred way.

When using Git locally, you need to be careful if you are using your fork
or the upstream, OSGeo repo. If you do a new clone from GitHub, it should
be pretty clear what you used.

Clone by default gets the default branch which is main, so you need to
switch to another branch (`git switch` in modern Git, `git checkout` in old
Git):

git switch releasebranch_8_0
git switch --detach 8.0.0

git checkout releasebranch_8_0
git checkout 8.0.0

When we one does repetitive clones (e.g., in CI), you can do a shallow
clone with --branch (which works for tags too) to get just one given state
of the repo:

git clone --depth 1 --branch releasebranch_8_0
git clone --depth 1 --branch 8.0.0

When using GitHub, the link Download ZIP which is under the green Clone
button respects the current branch which you set using the combo-box at the
right side or using the "8 branches" link. You can get, e.g.,

https://github.com/OSGeo/grass/archive/refs/heads/releasebranch_8_0.zip

On top of what Nicklas said about the release, you can also use the "124
tags" link which takes you to an overview page with links for all tags
(==releases in our case).

https://github.com/OSGeo/grass/tags

Best,
Vaclav

On Mon, 14 Feb 2022 at 11:16, Michael Barton  wrote:

> I stand corrected. I am not sure that I have the current 8.0 stable
> release. Cloning gives me the main repository, not 8.0.0 stable. I can
> check out a branch but need to make sure that I've got the stable release
> 8.0.0. The reason is that I'm trying to package this in sync with other
> platforms. It looks like the 8.0.0 branch was updated recently. So it is
> not the fixed stable release of 17 days ago.
>
> 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 Feb 14, 2022, at 9:08 AM, Michael Barton 
> wrote:
>
> This sounds a bit weird, but with some recent changes to the GRASS
> website, it has become more difficult to find and download a current stable
> release.
>
> I went to find a tar/zip package of GRASS 8.0.0 source code to build and
> could not find one from the web site. The links all lead only to the GitHub
> repository. This is fine for people who want dev versions. But I would
> think that some people just want the package. I eventually cloned one from
> GitHub, but even there, it is not transparent how to get the stable release
> vs. an updated version. Even on GitHub, the clone/download button seemed to
> be missing.
>
> While I could get the software, it seems like we should put back in a link
> to the source code packages somewhere.
>
> 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-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] help with completing GRASS 8 new features wiki

[Vaclav Petras]

How to edit and fine-tune release descriptions?

I have noticed that the lines for the two v.db.select PRs related to JSON
and CSV were confusing because the JSON mentioned a flag which was later
replaced, so I edited the description of the RC2 release on GitHub. Is that
the right approach?

Thanks,
Vaclav
___
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.0.0

[Vaclav Petras]

On Tue, Jan 11, 2022 at 12:52 PM Veronica Andreo 
wrote:
>
> El dom, 9 ene 2022 a las 16:36, Markus Neteler ()
escribió:
>>
>> Can we now publish "final" or do we still need a RC2?
>
> With no blockers, I'd be in favor of publishing final already :)
> Is there any "policy" regarding the number of RC's before final?

Traditionally, I think we did 2 RCs, but since we are releasing from a
("stable") branch rather than the main (development) branch, one could
argue we don't need any RCs at all. Perhaps 8.0.0 and all x.0.0 would be an
exception requiring one RC since the branch is new(ly created from the main
branch). We have a RFC with two RCs [1], but I think since then we
considered reducing that (I can't find the wiki page with the notes).

[1] https://trac.osgeo.org/grass/wiki/RFC/4_ReleaseProcedure

On Tue, Jan 11, 2022 at 1:39 PM Newcomb, Doug via grass-dev <
grass-dev@lists.osgeo.org> wrote:
>
> There may be some work to be done on the Windows standalone installer yet.

At the New Year's call, we discussed a little bit that with a release, we
may focus on the source code readiness for a release, but more or less
ignore the distribution of the software. In other words, we would leave out
the complexities of distributing the software from the event of tagging the
source code with a release tag. On the other hand, the Windows installer
code lives in the main source code, so as a result any changes may trigger
a new patch release if we ignore the standalone installer when tagging. In
any case, small issues in the installer are not blockers of the release.

In an ideal world, the Windows installer is built automatically based on
the event of tagging the release and the same happens for each commit on
the branch for testing purposes. This can be achieved with the installer
code in the main repo or in the separate repo in case a separate repo would
clear up some issues with releasing.

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

Re: [GRASS-dev] PR workflow fails due to ubuntu-20.04

[Vaclav Petras]

On Fri, Dec 10, 2021 at 7:39 AM Martin Landa  wrote:

>
> most of the workflows in my latest PR are queued because of [1]. Any
> idea what could be wrong? `ubuntu-20.04` is defined in [2].
>

The first link leads me to "Python Flake8 Code Quality" (flake8), but since
you are mentioning ubuntu-20.04, that job (although ubuntu-18.04 too) fails
with timeout after 6 hours (GitHub job max time). There are some issues
with tests that sometimes they get stuck. I was not able to determine the
reason from the results. It always seems to be a different test.

If someone wants to investigate more or add some time checks to gunittest
to mitigate this right there that would be great. I can provide reviews or
some other help. Adding a time limit (timeout-minutes [1]) to the job would
at least resolve the issue of unnecessary job running.

As for the many jobs for PRs being queued, that's now pretty much standard
in times which seem to be Western hemisphere working hours. I think the 20
concurrent jobs limit [2] applies to the whole OSGeo org.

Let me know if this addresses your question or not. Nothing wrong with your
code. The jobs are finished or running at the time of writing this email.

Best,
Vashek

[1]
https://docs.github.com/en/actions/learn-github-actions/workflow-syntax-for-github-actions#jobsjob_idtimeout-minutes
[2]
https://docs.github.com/en/actions/learn-github-actions/usage-limits-billing-and-administration



>
> Thanks, Martin
>
> [1] https://github.com/OSGeo/grass/runs/4483450424?check_suite_focus=true
> [2]
> https://github.com/landam/grass/blob/tgis_bands2semantic_labels/.github/workflows/ubuntu.yml
>
> --
> 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] help with completing GRASS 8 new features wiki

[Vaclav Petras]

On Wed, Dec 1, 2021 at 4:01 PM Markus Neteler  wrote:

> On Wed, Dec 1, 2021 at 9:25 PM Markus Neteler  wrote:
> ...
>
> > Drawback: how to filter out the "old" stuff (we seek the delta between
> > 7.8.6 and releasebranch_8_0) - any idea?
>
> Just found out that tags can be compared (sorry for slow), e.g.:
>
> https://github.com/OSGeo/grass/compare/7.8.5...7.8.6
>


But for 7.8.6...8.0.0 will not filter out the backported commits, no?

Here is an idea, we stop backporting and then the simple queries will start
working or, a more conservative suggestion, we consider the bugs fixed in
8.0 and 7.8 worth reporting for both. It is fixed for 8.0, so it should be
reported there. It also happens to be backported to the 7.8 branch, but
that does not change anything about a need to report it for 8.0 since
that's really the main focus after the 7.8.0 release. I'm just not sure how
this should work in the state when we branch out for release, but there is
no release yet (the current 8.0 vs 8.2 state).
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] help with completing GRASS 8 new features wiki

[Vaclav Petras]

On Sun, Nov 28, 2021 at 1:06 PM Markus Neteler  wrote:

> On Wed, Nov 24, 2021 at 2:10 PM Veronica Andreo 
> wrote:
>
> For populating this page I usually use "git log":
>
> # GRASS GIS 7.0.0 release on 2015-03-20
> git log --oneline --after="2015-03-20" | cut -d' ' -f2- | sed 's+^+ *
> G80:+g' | sed 's+(#+(PR:+g' | sort -u
>

You could also use GitHub CLI to get merged PRs with milestone 8.0.0:

gh pr list --search "milestone:8.0.0" --state merged --limit 100

This gives 93 PRs. Unfortunately, we also have PRs with no milestone which
is 919 items:

gh pr list --search "no:milestone" --state merged --limit 100
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Branch for 8.0 release created

[Vaclav Petras]

Dear all,

As decided at the PSC meeting on Friday, I have created a new branch for
the 8.0 release. This means that:

1) We are close to 8.0 RC 1.

2) Version 8 specific bug fixes need to be backported from main to
releasebranch_8_0.

3) If we plan another bug fix release of 7.8, bug fixes relevant to both
8.0 and 7.8 need to be backported also to 7.8 at least until the release of
8.0.

4) Docker images are now built for the 8.0 branch too (I changed the
workflow settings). (Open issues/PRs if this doesn't work.)

4) Larger changes such as single window and raster parallelization GSoC
projects can now be merged into the main branch.

In the following days, I will create a new branch for addons called grass8.
However, the transition there will be a longer process and I will need some
support in updating all the related workflows.

Best,
Vaclav

https://github.com/OSGeo/grass/tree/releasebranch_8_0
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Ad hoc hybrid sprint now

[Vaclav Petras]

We are having an ad hoc hybrid sprint now. You can connect remotely with
Zoom right now using this link:

https://ncsu.zoom.us/j/97331377857?pwd=Nzh1cW1yaGFXNkxUYVZFQ2Y3bzA5QT09

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

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

[Vaclav Petras]

That's fine Wolf. I really meant that in case you have some Perl
experience. There are certainly many different issues (see good first issue
label), but similar to the Perl issue is what you get when running
`shellcheck */*.sh`.

https://github.com/OSGeo/grass/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22



On Sat, Oct 2, 2021 at 7:02 AM Wolf Bergenheim 
wrote:

> Ugh. I give up. Perl and I just agreed to go our separate ways :P
>
> --Wolf
>
> *-- *
> * ^.___*
>
> *( ,__// / Wolf Bergenheim*
>
>
>
> On Sat, 2 Oct 2021 at 12:01, Wolf Bergenheim 
> wrote:
>
>> Hey Vaclav,
>>
>> Sure, perl is by no means an area I know much about, but looks quite
>> simple :)
>>
>> *-- *
>> * ^.___*
>>
>> *( ,__// / Wolf Bergenheim*
>>
>>
>>
>> On Sat, 2 Oct 2021 at 10:23, Vaclav Petras  wrote:
>>
>>>
>>>
>>>
>>> On Fri, Oct 1, 2021 at 10:31 AM Wolf Bergenheim <
>>> wolf+gr...@bergenheim.net> wrote:
>>>
>>>> Mainly I'm looking for opportunities to contribute after 10 years away
>>>> :P
>>>>
>>>
>>> Hi Wolf,
>>>
>>> If you are looking for suggestions, there are some Perl linting issues
>>> in grass-addons repo I just stumbled across.
>>>
>>> https://github.com/OSGeo/grass-addons/issues/619
>>> https://github.com/OSGeo/grass-addons/issues/620
>>>
>>> Besides Python and C, some Bash linting fixes might be needed too, but
>>> I've never looked into those except for disabling the check.
>>>
>>> Best,
>>> Vaclav
>>>
>>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

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

[Vaclav Petras]

On Fri, Oct 1, 2021 at 10:31 AM Wolf Bergenheim 
wrote:

> Mainly I'm looking for opportunities to contribute after 10 years away :P
>

Hi Wolf,

If you are looking for suggestions, there are some Perl linting issues in
grass-addons repo I just stumbled across.

https://github.com/OSGeo/grass-addons/issues/619
https://github.com/OSGeo/grass-addons/issues/620

Besides Python and C, some Bash linting fixes might be needed too, but I've
never looked into those except for disabling the check.

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

[GRASS-dev] Community sprint at FOSS4G 2021

[Vaclav Petras]

Dear all,

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

It is organized by the FOSS4G 2021 conference, but you don't need to be
registered to the conference to participate. Links for meetings will be
posted on the following wiki page or here.

https://wiki.osgeo.org/wiki/FOSS4G_2021/Community_sprint

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

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

Re: [GRASS-dev] GRASS releases: Let's meet to discuss/coordinate them!

[Vaclav Petras]

Starting in 1 hour. Here is the link to the call.

https://ncsu.zoom.us/j/96809444905?pwd=VlY5ajZneDhWaUlVZUtFKzFvdWpEdz09

On Fri, Sep 10, 2021 at 9:37 AM Veronica Andreo 
wrote:

> Dear all,
>
> Next Tuesday, September 14th at 21:00 CEST [1] we'll (videocall) meet to
> discuss/coordinate upcoming GRASS GIS releases. You are all welcome to join
> and contribute :)
>
> The link for the meeting will be shared in this thread soon before the
> meeting.
>
> Looking forward to seeing you
>
> Have a great weekend!
> Vero
>
> [1]
> https://www.timeanddate.com/worldclock/meetingdetails.html?year=2021=9=14=19=0=0=485=207=48=25=197
> ___
> 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] nc_spm_08_grass8?

[Vaclav Petras]

On Fri, Sep 10, 2021 at 3:02 AM Maris Nartiss  wrote:

> 2021-09-10 5:56 GMT+03:00, Vaclav Petras :

...
> = Not a big difference from existing implementation
>

Just to be clear, all these would be in addition to the proper handling of
band references and applied only when you don't want to deal with band
references directly.

...
>
> > Option 4) i.gensigset et al. labels the bands 1,2,3,... on the fly only
> in
> > the signature file and i.smap et al. uses the same numbering scheme when
> > the rasters don't have band references. Band references are handled only
> > when needed even on the module level in addition to the user level.
>
> Didn't understood how this differs from option #2.
>

The difference would be that the band references are never added to the
rasters in #4, only added to the signature file and re-created in the same
way for classification. In #2 they are actually added to rasters by
i.group. However, here is another option which I think is better than my
previous ones:

Option 5) Add a library function to read band reference which has a
fallback (band reference getter with a default). A reasonable fallback
seems to be the name of the raster map. This function can be then used on
all places in the signature/classification context instead of
Rast_read_bandref. i.gensigset et al. writes raster names as band
references to the signature file, i.smap et al. reads these names and
matches them with result from this new function unless the user didn't set
or renamed the raster map in the meantime. No additional step needed to the
v7 workflow if you don't need to use band references. The signatures are
associated with the raster map name rather than the order (as it is in v7).
Signatures from one mapset can then be used in another mapset as long as
the names of the rasters are the same (let's say each scene imported under
the same name into its own mapset for parallel processing). Something like
this function:

/** Return band reference or fallback to raster name if it is not set. */
char *Rast_read_bandref_with_fallback(const char *name, const char *mapset)
{
   char *ret = Rast_read_bandref(name, mapset);
   if (ret)
   return ret;
   else
   return G_store(name);
}
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Renaming master branch to main branch

[Vaclav Petras]

On Fri, Sep 10, 2021 at 4:36 PM Markus Metz 
wrote:

>
> ...all the previously timed-out tests for the affected PRs are passed...
>

As for the timed-out tests - those which are running actual test suites and
time out after 6 hours - that's actually still an issue. It just usually
does not happen. It is not clear to me what the cause is. You can see it
stuck at different tests, usually (always?) temporal, but that's also
because there are just a lot of temporal ones. I enabled the test result
(artifact) download even for that case, but I didn't see anything useful
there either. However, the fact that the artifact preparation step works
suggests that the GitHub VM itself is not stuck and it is really something
with our code or tests.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Renaming master branch to main branch

[Vaclav Petras]

On Fri, Sep 10, 2021 at 2:30 PM Markus Metz 
wrote:

>
> The commit history of the PR has not been messed up, only the relevant
> commits are shown.
>

Right, right, Git or GitHub recognizes that thoise 41 are already on main.

The reason for the rebase was that some tests were failing, apparently
> because of a combination of renaming master to main and changes to GHA, and
> a PR can only be squashed and merged if all tests are passed.
>

Ah, that makes sense. You need to update in one way or another in this case.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Renaming master branch to main branch

[Vaclav Petras]

On Fri, Sep 10, 2021 at 1:16 PM Markus Metz 
wrote:

> ...
> $ git checkout raster_tempdir
> $ git rebase main
>
> Successfully rebased and updated refs/heads/raster_tempdir.
>
> $ git status
> On branch raster_tempdir
> Your branch and 'metzm/raster_tempdir' have diverged,
> and have 48 and 7 different commits each, respectively.
>   (use "git pull" to merge the remote branch into yours)
>
> $ git push metzm raster_tempdir
> ! [rejected]raster_tempdir -> raster_tempdir (non-fast-forward)
> error: failed to push some refs to 'github.com:metzm/grass.git'
> hint: Updates were rejected because the tip of your current branch is
> behind
> hint: its remote counterpart. Integrate the remote changes (e.g.
> hint: 'git pull ...') before pushing again.
> hint: See the 'Note about fast-forwards' in 'git push --help' for details.
>

This is how it is supposed to behave when you do `git rebase`. Rebasing
re-applies the changes you made in raster_tempdir one by one on top of your
local main. This creates different commits in the sense that the commit
hashes are different. This causes the "have diverged" part. 48 on the local
raster_tmpdir is your 7 commits plus 41 commits which happened in the main
branch since you created raster_tempdir. 7 commits on metzm/raster_tempdir
is the original commits you made which have the original, different hash,
so Git considers them to be different.

Force push with `git push -f metzm raster_tempdir` is appropriate here. You
will replace whatever is in the remote branch by your newly updated
(rebased) local branch content.

We are currently merging all PRs using the "Squash and merge" feature, this
reduces the commit which will go to the main branch to only the actual
changes taking care of the merge commits. So, you can use git merge or git
rebase on your branches.

I still prefer rebase most of the time because it is easier to review
commits in the PR (since there are no merge commits). Some people also use
rebase to reduce the commits on a branch to one, but I think that's usually
not helpful for review. However, merge does not require the strange force
pushing and it works better in case of conflicts because you are simply
merging the latest state, not each commit on your branch which is the case
with rebase.

As far as I can tell, the master-main rename should not have any influence
on this. And yes, the message from `git push` is not applicable here.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] nc_spm_08_grass8?

[Vaclav Petras]

On Thu, Sep 9, 2021 at 3:23 PM Maris Nartiss  wrote:

> 2021-09-09 19:19 GMT+03:00, Vaclav Petras :
> >
> > In the documentation, we moved from (5 calls):
> >
> > ```
> > g.region raster=lsat7_2002_10
> > i.group group=lsat7_2002 subgroup=res_30m input=...
> > v.to.rast input=training output=training use=cat label_column=label
> > i.gensigset trainingmap=training group=lsat7_2002 subgroup=...
> > i.smap group=lsat7_2002 subgroup=res_30m signaturefile=...
> > ```
> >
> > to (16 calls):
> >
> > ```
> > g.mapset mapset=PERMANENT
> > r.support map=lsat7_2002_10 bandref=TM7_1
> > r.support map=lsat7_2002_20 bandref=TM7_2
> > r.support map=lsat7_2002_30 bandref=TM7_3
> > r.support map=lsat7_2002_40 bandref=TM7_4
> > r.support map=lsat7_2002_50 bandref=TM7_5
> > r.support map=lsat7_2002_61 bandref=TM7_61
> > r.support map=lsat7_2002_62 bandref=TM7_62
> > r.support map=lsat7_2002_70 bandref=TM7_7
> > r.support map=lsat7_2002_80 bandref=TM7_8
> > g.mapset mapset=user1
> > g.region raster=lsat7_2002_10
> > i.group group=lsat7_2002 subgroup=res_30m input=...
> > v.to.rast input=training output=training use=cat label_column=label
> > i.gensigset trainingmap=training group=lsat7_2002 subgroup=...
> > i.smap group=lsat7_2002 subgroup=res_30m signaturefile=...
> > ```
> >
> > This seems to be making GRASS more difficult to use instead of making it
> > easier to use or at least keeping the status quo.
>
> And we gained ability to use signatures from one scene to classify
> different scenes.
>

Why not to have both? Classify thousands of scenes while providing a simple
way of doing things?

If all import tools assigned band references, having them ready in the
dataset for landsat could be perhaps justified. That's the answer I was
hoping for, but that's not the case. Still, the question would be what if
you can't use such a tool.

As for getting closer to the original behavior where 5 commands were enough
to classify, i.group could add the band references since one needs to deal
with both groups and bands anyway or the signature handling could assign
them on the fly. I'm probably missing some important details you know
about, but here are some options I can think of:

Option 1) i.group has a new option bandref. It assigns band references to
the rasters. User needs to provide as many band references as inputs. Still
quite long, but i.group call is long already and it is at least technically
one step.

Option 2) i.group has a new flag to auto-assign band references 1,2,3,...
(2a). Or perhaps an option taking a prefix/basename (2b). Simple to set.
Minimal change from the current workflows. Almost feels like band
references are optional.

Option 3) i.group auto-assigns automatically when band references are not
present. No dealing with band references unless one needs to.

Option 4) i.gensigset et al. labels the bands 1,2,3,... on the fly only in
the signature file and i.smap et al. uses the same numbering scheme when
the rasters don't have band references. Band references are handled only
when needed even on the module level in addition to the user level.

With all options users still may take advantage of the flexible signature
file system if being careful about order. (Keeping the order right is
likely not an issue while scripting, so having a list of auto-assigned
numbers is just fine.) All options hide details of the actual reference
handling at least a little bit providing more space for changes later on.
The options 3 and 4 make dealing with band references completely optional.
Option 4 avoids mixing groups and band references and while option 3 hides
that part.

Other options would be modules such as r.number.bands/i.auto.bands (kind of
like options 2 and 3 but standalone) and i.band.identify (some heuristic to
determine band names from raster names perhaps taking an example or a
sensor).
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] nc_spm_08_grass8?

[Vaclav Petras]

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

In the documentation, we moved from (5 calls):

```
g.region raster=lsat7_2002_10
i.group group=lsat7_2002 subgroup=res_30m input=...
v.to.rast input=training output=training use=cat label_column=label
i.gensigset trainingmap=training group=lsat7_2002 subgroup=...
i.smap group=lsat7_2002 subgroup=res_30m signaturefile=...
```

to (16 calls):

```
g.mapset mapset=PERMANENT
r.support map=lsat7_2002_10 bandref=TM7_1
r.support map=lsat7_2002_20 bandref=TM7_2
r.support map=lsat7_2002_30 bandref=TM7_3
r.support map=lsat7_2002_40 bandref=TM7_4
r.support map=lsat7_2002_50 bandref=TM7_5
r.support map=lsat7_2002_61 bandref=TM7_61
r.support map=lsat7_2002_62 bandref=TM7_62
r.support map=lsat7_2002_70 bandref=TM7_7
r.support map=lsat7_2002_80 bandref=TM7_8
g.mapset mapset=user1
g.region raster=lsat7_2002_10
i.group group=lsat7_2002 subgroup=res_30m input=...
v.to.rast input=training output=training use=cat label_column=label
i.gensigset trainingmap=training group=lsat7_2002 subgroup=...
i.smap group=lsat7_2002 subgroup=res_30m signaturefile=...
```

This seems to be making GRASS more difficult to use instead of making it
easier to use or at least keeping the status quo.

Changing the sample dataset sounds like hiding the issue rather than
solving it. Having an ultra convenient sample dataset doesn't make the
software easier to use.

Additionally, given that the band references seem highly experimental, I
don't think they should be required for any workflow at least from the user
point of view.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev