GRASS GIS at OSGeo Community Sprint 2019
Jump to navigation
Jump to search
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.
Reports
Tuesday
Vaclav (Vashek) Petras
- 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)
Wednesday
Vaclav (Vashek) Petras
- 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
Anna Petrasova
- Cleanup decoding/encoding in Python scripting library (trac r74480)
- Fix tests for i.vi and g.extension (trac r74483, trac r74482)
- Use UTF-8 in v.in.geonames (#3781, trac r74481)
Thursday
Vaclav (Vashek) Petras
- 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
- Recipes for command line and integrating tasks are needed, for example:
Anna Petrasova
- Fixed several issues in the library and fixed several related tests.
- Discussed integration of GRASS GIS and WebODM with other developers (WebODM plugin).