GRASS GIS at OSGeo Community Sprint 2019: Difference between revisions

From GRASS-Wiki
Jump to navigation Jump to search
mNo edit summary
 
(9 intermediate revisions by the same user not shown)
Line 1: Line 1:
{{toc|right}}
{{toc|right}}


[https://wiki.osgeo.org/wiki/OSGeo_Community_Sprint_2019 '''OSGeo Community Sprint 2019'''], University of Minnesota - Twin Cities, May 14-17, 2019.
[https://wiki.osgeo.org/wiki/OSGeo_Community_Sprint_2019 ''OSGeo Community Sprint 2019''], University of Minnesota - Twin Cities, May 14-17, 2019.


Check sprint's sponsors [https://wiki.osgeo.org/wiki/OSGeo_Community_Sprint_2019#Sponsors here].
Check sprint's sponsors [https://wiki.osgeo.org/wiki/OSGeo_Community_Sprint_2019#Sponsors here].
Line 8: Line 8:
[[File:GRASS_GIS_Code_Sprint_2018.png|320px]]  
[[File:GRASS_GIS_Code_Sprint_2018.png|320px]]  
</center>
</center>
== 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 ==
== 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 ({{changeset|74479}})
=== 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 {{changeset|74484}}.
** 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 ({{changeset|74480}})
* Fix tests for i.vi and g.extension ({{changeset|74483}}, {{changeset|74482}})
* Use UTF-8 in v.in.geonames (#3781, {{changeset|74481}})
=== 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
==== 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).
=== See also ===
* [[GRASS GIS Community Sprint Berlin 2019]]
[[Category: Workshops]]
[[Category: Code Sprint]]
[[Category: 2019]]

Latest revision as of 04:13, 17 May 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.

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

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

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

See also