GRASS GIS at OSGeo Community Sprint 2019 - Revision history

⚠️Wenzeslaus: /* Vaclav (Vashek) Petras */

2019-05-17T04:13:03Z

Vaclav (Vashek) Petras

← Older revision		Revision as of 04:13, 17 May 2019
Line 62:		Line 62:
	*** Automatic identification of CRS (actually makes more sense/is more safer in batch processing/backend use than in desktop use)		*** 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 clear/straightforward CLI
	*** More ~~quite~~ --exec		*** More quiet --exec
	*** Perhaps --exec needs different defaults than interactive use (e.g. more quiet) or there should be an alternative subcommand or binary		*** Perhaps --exec needs different defaults than interactive use (e.g. more quiet) or there should be an alternative subcommand or binary

⚠️Wenzeslaus at 04:11, 17 May 2019

2019-05-17T04:11:33Z

← Older revision		Revision as of 04:11, 17 May 2019
Line 73:		Line 73:

	* [[GRASS GIS Community Sprint Berlin 2019]]		* [[GRASS GIS Community Sprint Berlin 2019]]

			[[Category: Workshops]]
			[[Category: Code Sprint]]
			[[Category: 2019]]

⚠️Wenzeslaus: /* Thursday */

2019-05-17T04:10:02Z

Thursday

← Older revision		Revision as of 04:10, 17 May 2019
Line 49:		Line 49:
	==== Vaclav (Vashek) Petras ====		==== 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.		* 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:		** Recipes for command line and integrating tasks are needed, for example:
	*** Passing parameters to a script (Bash, Python, using GRASS interface description, with --exec)		*** Passing parameters to a script (Bash, Python, using GRASS interface description, with --exec)
	*** Slicing messages		*** Slicing messages
	*** grass --tmp-location EPSG:3358 --exec g.region -pg \| grep ".*"		*** Handling module output and error states: grass --tmp-location EPSG:3358 --exec g.region -pg \| grep ".*"
	*** grass --tmp-location EPSG:3358 --exec bash -c "r.in.pdal input=~/points.las output=points; g.gui -f"		*** 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)		** Cutting down the steps in "external" CLI (--exec)
	*** Thumbs up for --exec and --tmp-location		*** Thumbs up for --exec and --tmp-location
Line 64:		Line 66:

	==== Anna Petrasova ====		==== 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 ===		=== See also ===

	* [[GRASS GIS Community Sprint Berlin 2019]]		* [[GRASS GIS Community Sprint Berlin 2019]]

⚠️Wenzeslaus: /* Vaclav (Vashek) Petras */

2019-05-17T03:51:33Z

Vaclav (Vashek) Petras

← Older revision		Revision as of 03:51, 17 May 2019
Line 35:		Line 35:
	* 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.		* 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}}.		** 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.		** 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}}		* Commented on issues: svn2git migration, GRASS GIS 8 planning, Unicode in Python code, {{trac\|3790}}, {{trac\|2970}}

⚠️Wenzeslaus: /* See also */

2019-05-16T19:41:58Z

⚠️Wenzeslaus: /* Wednesday */

2019-05-16T19:40:42Z

Wednesday

← Older revision		Revision as of 19:40, 16 May 2019
Line 43:		Line 43:
	* Fix tests for i.vi and g.extension ({{changeset\|74483}}, {{changeset\|74482}})		* Fix tests for i.vi and g.extension ({{changeset\|74483}}, {{changeset\|74482}})
	* Use UTF-8 in v.in.geonames (#3781, {{changeset\|74481}})		* Use UTF-8 in v.in.geonames (#3781, {{changeset\|74481}})

			=== Thursday ===

			==== Vaclav (Vashek) Petras ====

			* 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
			*** grass --tmp-location EPSG:3358 --exec g.region -pg \| grep ".*"
			*** 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 quite --exec
			*** Perhaps --exec needs different defaults than interactive use (e.g. more quiet) or there should be an alternative subcommand or binary

			==== Anna Petrasova ====

⚠️Wenzeslaus: /* Wednesday */

2019-05-16T02:15:37Z

Wednesday

← Older revision		Revision as of 02:15, 16 May 2019
Line 36:		Line 36:
	** Using callback filter is simpler with current v.in.pdal code. Implemented in {{changeset\|74484}}.		** Using callback filter is simpler with current v.in.pdal code. Implemented in {{changeset\|74484}}.
	** 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.		** 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, {{trac\|3790}}, {{trac\|2970}}		* 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}})

⚠️Wenzeslaus: /* Reports */

2019-05-15T21:22:39Z

Reports

← Older revision		Revision as of 21:22, 15 May 2019
Line 28:		Line 28:
	* Connected with ODM group and clarified the goals.		* Connected with ODM group and clarified the goals.
	* Update documentation for v.surf.rst for point clouds ({{changeset\|74479}})		* 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 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, {{trac\|3790}}, {{trac\|2970}}

⚠️Wenzeslaus: Reports and goals

2019-05-15T13:18:50Z

Reports and goals

@@ Line 8: / Line 8: @@
 [[File:GRASS_GIS_Code_Sprint_2018.png|320px]]
 </center>
 == Reports ==

⚠️Wenzeslaus at 20:05, 14 May 2019

2019-05-14T20:05:25Z

← Older revision		Revision as of 20:05, 14 May 2019
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].

← Older revision		Revision as of 19:41, 16 May 2019
Line 63:		Line 63:

	==== Anna Petrasova ====		==== Anna Petrasova ====

			=== See also ===

			* [[GRASS GIS Community Sprint Berlin 2019]]