GRASS GIS at OSGeo Community Sprint 2019

OSGeo Community Sprint 2019, University of Minnesota - Twin Cities, May 14-17, 2019.

Check sprint's sponsors here.

Goals

Find the best way for GRASS GIS to use PDAL.
Get new prototype started in terms of code design and/or putting the basic pieces together to test specific usages of API and have a prototype which would conform with the PDAL API best practices. Options are PDAL C++ API (original pre- and modern post-1.0 release), using PDAL C API, and command line pipeline API.
Identify and ideally implement any features in GRASS GIS API which would make it easier for OpenDroneMap to run GRASS GIS algorithms.
Write and/or review a draft of Git/GitHub usage best practices for GRASS GIS learning from the projects which migrated from Subversion/Trac in recent years.
Finishing porting GRASS to Python 3 so that we can release long-awaited Python3-compatible version.
Connect GRASS more tightly, namely to build on top the current integration and add a stronger analytical component to WebODM.

Started discussion about the right PDAL API for GRASS GIS.
- PDAL C API is not part of the core and the maintenance plan for future is unclear.
Connected with ODM group and clarified the goals.
Update documentation for v.surf.rst for point clouds (trac r74479)

Discussed with PDAL developers and decided the best approach is to use standard C++ API with streaming and either proper PDAL stages or callback filter.
- Using callback filter is simpler with current v.in.pdal code. Implemented in trac r74484.
- The stages are executed in streaming mode which significantly reduces memory requirements (from all input in memory to fixed amount).
- The C/C++ version of r.in.pdal should use stages, possibly one or more filters and a writer. However, the implementation should keep as much code as possible as (pure) C for reuse in similar modules following what is in r.in.lidar and others.
Commented on issues: svn2git migration, GRASS GIS 8 planning, Unicode in Python code, trac #3790, trac #2970

Worked on r.in.pdal (PDAL-based version of r.in.lidar)
- Most of functionality now available, but whole output raster needs to fit into memory and general refactoring is needed.
Discussed how GRASS GIS is used in WebODM now and what should be improved.
- Recipes for command line and integrating tasks are needed, for example:
  - Passing parameters to a script (Bash, Python, using GRASS interface description, with --exec)
  - Slicing messages
  - Handling module output and error states: grass --tmp-location EPSG:3358 --exec g.region -pg | grep ".*"
  - Debugging tricks: grass --tmp-location EPSG:3358 --exec bash -c "r.in.pdal input=~/points.las output=points; g.gui -f"
- Cutting down the steps in "external" CLI (--exec)
  - Thumbs up for --exec and --tmp-location
  - Automatic import/linking
  - Automatic identification of CRS (actually makes more sense/is more safer in batch processing/backend use than in desktop use)
- More clear/straightforward CLI
  - More quiet --exec
  - Perhaps --exec needs different defaults than interactive use (e.g. more quiet) or there should be an alternative subcommand or binary

Fixed several issues in the library and fixed several related tests.
Discussed integration of GRASS GIS and WebODM with other developers (WebODM plugin).