Re: [GRASS-dev] [release] 7.6.1

[Markus Neteler]

Hi Martin, all,

On Sun, Mar 3, 2019 at 7:37 PM Martin Landa  wrote:
>
> Hi Markus, all,
>
> there are no known blockers [0], I would vote for 7.6.1RC1 in next few days.
>
> Martin
>
> [0] 
> https://trac.osgeo.org/grass/query?status=new&status=assigned&status=reopened&priority=blocker&priority=critical&milestone=7.6.1&group=type&order=priority
> [1] https://trac.osgeo.org/grass/milestone/7.6.1

Sounds good to me:

Here the included changes (starting from r73974):
- https://trac.osgeo.org/grass/log/grass/branches/releasebranch_7_6
- 
https://trac.osgeo.org/grass/changeset?reponame=&new=74146%40grass%2Fbranches%2Freleasebranch_7_6&old=73959%40grass%2Fbranches%2Freleasebranch_7_6

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

Re: [GRASS-dev] [GRASS GIS] #3487: vector digitizer unstable

[GRASS GIS]

#3487: vector digitizer unstable
+---
  Reporter:  cmbarton   |  Owner:  grass-dev@…
  Type:  defect | Status:  new
  Priority:  critical   |  Milestone:  7.6.1
 Component:  wxGUI  |Version:  7.2.2
Resolution: |   Keywords:  digitizer, ctypes
   CPU:  OSX/Intel  |   Platform:  MacOSX
+---

Comment (by neteler):

 Replying to [comment:15 cmbarton]:
 > Unfortunately, I can't test this until we figure out why configure is
 looking for cpp and bombing when it doesn't find it now.

 I'd suggest to move this to the 7.8 milestone, with focus on Python-3.

-- 
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] [release] 7.6.1

[Martin Landa]

Hi Markus, all,

there are no known blockers [0], I would vote for 7.6.1RC1 in next few days.

Martin

[0] 
https://trac.osgeo.org/grass/query?status=new&status=assigned&status=reopened&priority=blocker&priority=critical&milestone=7.6.1&group=type&order=priority
[1] https://trac.osgeo.org/grass/milestone/7.6.1

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

Re: [GRASS-dev] [release planning] GRASS GIS 7.8.0 with Python3 support

[Martin Landa]

Hi,

ne 3. 3. 2019 v 19:27 odesílatel Markus Neteler  napsal:
> > - Creation of release branch: 11 Feb 2019
> Please try it out for further testing of GRASS GIS with Python-3!

my +1 for creating 7.8 releasebranch. It's a first step which can be
done ASAP. Ma

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

Re: [GRASS-dev] [release planning] GRASS GIS 7.8.0 with Python3 support

[Markus Neteler]

On Mon, Feb 4, 2019 at 5:31 PM Markus Neteler  wrote:
>
> Hi devs,
>
> currently sitting next to Martin, we updated our roadmap (also keeping
> the QGIS releases in mind [1] and the next OSGeoLive release):
>
> Time schedule:
> https://trac.osgeo.org/grass/milestone/7.8.0
>
> - Proposal of release: 4 Feb 2019 (OSGeo birthday, btw!)
> - Creation of release branch: 11 Feb 2019
> - RC1: 11 Mar 2019
> - RC2: 24 Mar 2019
> - RC3: if needed
> - Final release: 1 Apr 2019 (tentatively)

Here an update, trying to keep above release plan:

We (esp Carmen, Anika and me) are using trunk in a big project in
mundialis in which we have completely migrated to Python-3 only.
It is all running in the cloud, hence no wxGUI involved. We certainly
only use a fraction of all the commands but for sure important ones
along with several image processing related addons.
Summary: it works :-)

In order to ease wider testing, Carmen created a Python-3-only docker
image with PDAL included as a goodie (we use it as part of our
multi-layered docker images):

https://github.com/mundialis/grass-py3-pdal

I just added usage instructions there. You can install it in parallel
and use it for testing.
Please try it out for further testing of GRASS GIS with Python-3!

> [1] 
> https://www.qgis.org/en/site/getinvolved/development/roadmap.html#release-schedule

Cheers
Markus

-- 
Markus Neteler, PhD
https://www.mundialis.de - free data with free software
https://grass.osgeo.org
https://courses.neteler.org/blog
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] [GRASS GIS] #3766: Update "Introduction to Raster classes" document

[GRASS GIS]

#3766: Update "Introduction to Raster classes" document
--+-
 Reporter:  Nikos Alexandris  |  Owner:  grass-dev@…
 Type:  defect| Status:  new
 Priority:  normal|  Milestone:
Component:  Docs  |Version:  unspecified
 Keywords:|CPU:  Unspecified
 Platform:  All   |
--+-
 In the
 [https://grass.osgeo.org/grass77/manuals/libpython/pygrass_raster.html
 Introduction to Raster classes], please the remove the incorrect short
 sentence
  Both classes write sequentially.
 from
  The read access is row wise for RasterRow and RasterRowIO and
 additionally cached in the RowIO class. Both classes write sequentially.

 Only
 [https://grass.osgeo.org/grass77/manuals/libpython/pygrass_raster.html
 #rasterrow-label RasterRow] (that is only one class) that writes
 sequentially.

-- 
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] Naming of modules in GRASS GIS 8

[Nikos Alexandris]

In the spirit of contributing ideas for "GRASS 8 planning" [0],
I'd like to add a section "Naming of modules" and propose essentially
the (re-)naming of grass modules, along with options (and/or parameters) by
fully spelling out of what they mean/do.

[0] https://trac.osgeo.org/grass/wiki/Grass8Planning

In my humble view, the development team should support and
encourage this practice extensively, including when scripting and naming
functions too.


While a lot has been updated during the last years, there are still
shortcuts instead of fully spelled out names. Some examples of module
names:

- `d.rast` instead of `d.raster`,
- `r.resamp.*` instead of `r.resampling.*`
- `r.stats` instead of `r.statistics.*`
- `r.vect.stats` instead of `r.vector.statistics`
- `r.surf.*` instead of `r.surface.*`
- `v.rast.*` instead of `v.raster.*`

Some harmonisation has to be applied in names of options and eventually
their description too. For example:

- `r.support` has "map   Name of raster map"
- `r.random` has "input   Name of input raster map"
- `r.buildvrt` has "input   Name of input raster files`
- `r.carve` has "Name of input raster elevation map`
- `r.category` has "map   Name of raster map"
- `r.category.trim` has "input   input map"

- `g.region` has a set of `res` named options (`res`, `res3`, `nsres`,
 `swres`, `tbres`) where all this could be fully spelled out
 `resolution`


Perhaps a set of naming guidelines can be created available for all to consult.
For example, in the following link, from the QGIS project,

https://issues.qgis.org/projects/qgis/wiki/Adding_New_Tools_to_the_GRASS_Toolbox#Specific-rules-for-module-descriptions

it is mentioned:

 ''Avoid unnecessary "map", "layer" and "file", e.g. "Export raster"
 instead of "Export raster map layer''

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