Vector topology cleaning - Revision history

Neteler: /* See also */ +Fixing centroids outside area

2020-04-05T13:02:50Z

See also: +Fixing centroids outside area

← Older revision		Revision as of 13:02, 5 April 2020
Line 83:		Line 83:

	'''A:''' Yes, these are typically holes in polygons (islands).		'''A:''' Yes, these are typically holes in polygons (islands).

			== Fixing centroids outside area ==

			Q: {{cmd\|v.clean}} reports: "WARNING: Number of centroids outside area: x"

			A: ... todo (v.build with error map to get category of offending centroid; then v.edit to delete it)

	== See also ==		== See also ==

Neteler: remove hardcoded version specific urls, use latest version

2018-12-03T16:25:14Z

remove hardcoded version specific urls, use latest version

← Older revision		Revision as of 16:25, 3 December 2018
Line 25:		Line 25:
	== Cleaning large network datasets ==		== Cleaning large network datasets ==

	'''Q:''' How can I speed up topologial cleaning (~~{{cmd\|~~v.clean}}) in GRASS 6 for large network datasets (for example OpenStreetMap data)?		'''Q:''' How can I speed up topologial cleaning (v.clean) in GRASS 6 for large network datasets (for example OpenStreetMap data)?

	'''A:''' The improved {{cmd\|v.clean~~\|version=70~~}} version in GRASS 7 is way faster. Here some hints though:		'''A:''' The improved {{cmd\|v.clean}} version in GRASS 7 is way faster. Here some hints though:

	''GRASS 6:'' When '''breaking lines''' it is recommended to		''GRASS 6:'' When '''breaking lines''' it is recommended to
Line 34:		Line 34:
	* use {{cmd\|v.build.polylines}} to merge lines again.		* use {{cmd\|v.build.polylines}} to merge lines again.

	''GRASS 7:'' Here this has become much easier. Use {{cmd\|v.clean~~\|version=70~~}} with the -c flag and 'tool=break' and 'type=line'. The 'rmdupl' tool is then ''automatically'' added, and the splitting and merging is done internally.		''GRASS 7:'' Here this has become much easier. Use {{cmd\|v.clean}} with the -c flag and 'tool=break' and 'type=line'. The 'rmdupl' tool is then ''automatically'' added, and the splitting and merging is done internally.

	== Cleaning zero length lines ==		== Cleaning zero length lines ==

Neteler: Snapping threshold strategy added (by Markus Metz, https://lists.osgeo.org/pipermail/grass-user/2017-October/077165.html)

2017-10-22T20:00:12Z

Snapping threshold strategy added (by Markus Metz, https://lists.osgeo.org/pipermail/grass-user/2017-October/077165.html)

← Older revision		Revision as of 20:00, 22 October 2017
Line 3:		Line 3:
	'''Q:''' What would be the 'recommended' way of dealing with the 'errors' found in vector data which were created with zero topological restrictions (and saved as .shp?)		'''Q:''' What would be the 'recommended' way of dealing with the 'errors' found in vector data which were created with zero topological restrictions (and saved as .shp?)

	'''A:''' For import, try to find a snapping threshold for {{cmd\|v.in.ogr}} that produces an error-free output (during import the module suggests a threshold). Ideally the output would not only be error-free, but the number of centroids would match the number of input polygons (both are reported by ''v.in.ogr''). The ''min_area'' option of ''v.in.ogr'' could also help. The bulk of the cleaning should be done by		'''A:''' For import, try to find a '''snapping threshold''' for {{cmd\|v.in.ogr}} that produces an error-free output (during import the module suggests a threshold). Ideally the output would not only be error-free, but the number of centroids would match the number of input polygons (both are reported by ''v.in.ogr''). The ''min_area'' option of ''v.in.ogr'' could also help. The bulk of the cleaning should be done by
	''v.in.ogr''. After that, removing small areas with <tt>v.clean ... tool=rmarea</tt>, threshold in square meters, could help.		''v.in.ogr''. After that, removing small areas with <tt>v.clean ... tool=rmarea</tt>, threshold in square meters, could help.

Line 9:		Line 9:

	Note: there might not be a standard procedure that works for all data sources.		Note: there might not be a standard procedure that works for all data sources.

			=== A strategy to find a viable '''snapping threshold'''===

			A hint for snapping: {{cmd\|v.in.ogr}} suggest for vector data with topological errors a range of <nowiki>[1e-08, 1]</nowiki> for suitable snapping values. The exponent thus ranges from -8 to 0. Testing all possible values in this range obviously takes a lot of time.

			''Strategy:'' You could set low = -8 , high = 0, and set mid to (low + high) / 2 = -4 and test {{cmd\|v.in.ogr}} with snap=1e$mid.

			* If you still get errors, increase: set low to mid, get new mid with (low + high) / 2
			* else, decrease: set high to mid, get new mid with (low + high) / 2

			Continue this until you found the threshold were these warnings just disappeared.

			Note: Snapping is slow and uses quite a bit of memory because it needs a spatial search tree.

	== Cleaning large network datasets ==		== Cleaning large network datasets ==

Neteler: /* Hints */ snap threshold is given in map units

2017-10-10T20:31:59Z

Hints: snap threshold is given in map units

← Older revision		Revision as of 20:31, 10 October 2017
Line 52:		Line 52:
	=== Hints ===		=== Hints ===

	* In recent GRASS GIS versions, '''snapping thresholds''' for unclean polygons are '''suggested''' to the user when using {{cmd\|v.in.ogr}}		* In recent GRASS GIS 7 versions, '''snapping thresholds''' for unclean polygons are '''suggested''' to the user when using {{cmd\|v.in.ogr}}.
			** Note that the '''snap threshold''' is given '''in map units''', e.g. meters. To select a reasonable value consider the distance of vertices in the map, i.e. the level of detail in order to avoid that either the entire geometry is getting "ruined" by an aggressive snapping nor that nothing happens if the snap threshold is magnitudes lower than the map unit (e.g. trying to fix cadastral maps at pico-meter level will not change much).
	* If the input polygons are '''supposed to not overlap''' each other, the number of centroids should be identical to the number of input polygons. If not the case, more topological cleaning is needed.		* If the input polygons are '''supposed to not overlap''' each other, the number of centroids should be identical to the number of input polygons. If not the case, more topological cleaning is needed.
	* If the '''input polygons have logical errors''', for example when the same landuse polygon is present more than once, this can not be cleaned automatically with {{cmd\|v.in.ogr}} or {{cmd\|v.clean}}. You can investigate overlapping areas in the imported vector with '{{cmd\|d.vect}} yourmap type=area layer=2' (only overlapping areas have a category in layer 2 after import). Additionally you may show the centroids of layer=2 to easier find tiny overlapping areas with '{{cmd\|d.vect}} yourmap type=centroid layer=2'		* If the '''input polygons have logical errors''', for example when the same landuse polygon is present more than once, this can not be cleaned automatically with {{cmd\|v.in.ogr}} or {{cmd\|v.clean}}. You can investigate overlapping areas in the imported vector with '{{cmd\|d.vect}} yourmap type=area layer=2' (only overlapping areas have a category in layer 2 after import). Additionally you may show the centroids of layer=2 to easier find tiny overlapping areas with '{{cmd\|d.vect}} yourmap type=centroid layer=2'

Neteler: +centroid hint

2015-05-26T14:11:46Z

+centroid hint

← Older revision		Revision as of 14:11, 26 May 2015
Line 52:		Line 52:
	=== Hints ===		=== Hints ===

	* In recent GRASS GIS versions, '''snapping thresholds''' for unclean polygons are '''suggested''' to the user when using v.in.ogr		* In recent GRASS GIS versions, '''snapping thresholds''' for unclean polygons are '''suggested''' to the user when using {{cmd\|v.in.ogr}}
	* If the input polygons are '''supposed to not overlap''' each other, the number of centroids should be identical to the number of input polygons. If not the case, more topological cleaning is needed.		* If the input polygons are '''supposed to not overlap''' each other, the number of centroids should be identical to the number of input polygons. If not the case, more topological cleaning is needed.
	* If the '''input polygons have logical errors''', for example when the same landuse polygon is present more than once, this can not be cleaned automatically with v.in.ogr or v.clean. You can investigate overlapping areas in the imported vector with 'd.vect type=area layer=2' (only overlapping areas have a category in layer 2 after import).		* If the '''input polygons have logical errors''', for example when the same landuse polygon is present more than once, this can not be cleaned automatically with {{cmd\|v.in.ogr}} or {{cmd\|v.clean}}. You can investigate overlapping areas in the imported vector with '{{cmd\|d.vect}} yourmap type=area layer=2' (only overlapping areas have a category in layer 2 after import). Additionally you may show the centroids of layer=2 to easier find tiny overlapping areas with '{{cmd\|d.vect}} yourmap type=centroid layer=2'

	'''Q:''' How about self-intersecting lines and boundaries?		'''Q:''' How about self-intersecting lines and boundaries?

Neteler: + Cleaning zero length lines

2015-02-18T17:12:20Z

+ Cleaning zero length lines

← Older revision		Revision as of 17:12, 18 February 2015
Line 22:		Line 22:

	''GRASS 7:'' Here this has become much easier. Use {{cmd\|v.clean\|version=70}} with the -c flag and 'tool=break' and 'type=line'. The 'rmdupl' tool is then ''automatically'' added, and the splitting and merging is done internally.		''GRASS 7:'' Here this has become much easier. Use {{cmd\|v.clean\|version=70}} with the -c flag and 'tool=break' and 'type=line'. The 'rmdupl' tool is then ''automatically'' added, and the splitting and merging is done internally.

			== Cleaning zero length lines ==

			In order to remove all lines with zero length, run
			v.clean type=line tool=rmline

	== Cleaning patched polygons ==		== Cleaning patched polygons ==

Neteler: Comments added from http://lists.osgeo.org/pipermail/grass-user/2015-January/071625.html

2015-01-14T11:28:22Z

Comments added from http://lists.osgeo.org/pipermail/grass-user/2015-January/071625.html

← Older revision		Revision as of 11:28, 14 January 2015
Line 1:		Line 1:
			== Introduction ==

			'''Q:''' What would be the 'recommended' way of dealing with the 'errors' found in vector data which were created with zero topological restrictions (and saved as .shp?)

			'''A:''' For import, try to find a snapping threshold for {{cmd\|v.in.ogr}} that produces an error-free output (during import the module suggests a threshold). Ideally the output would not only be error-free, but the number of centroids would match the number of input polygons (both are reported by ''v.in.ogr''). The ''min_area'' option of ''v.in.ogr'' could also help. The bulk of the cleaning should be done by
			''v.in.ogr''. After that, removing small areas with <tt>v.clean ... tool=rmarea</tt>, threshold in square meters, could help.

			Example: For data which are mainly based on Landsat data, a threshold of 10 square meters could remove artefacts and preserve valid areas (Landsat pixel size is about 90 square meters). The threshold needs to be empirically determined.

			Note: there might not be a standard procedure that works for all data sources.

	== Cleaning large network datasets ==		== Cleaning large network datasets ==

Neteler: /* See also */

2014-07-31T17:48:58Z

Neteler: + link to Intro to vector data model

2014-07-18T08:39:41Z

+ link to Intro to vector data model

← Older revision		Revision as of 08:39, 18 July 2014
Line 56:		Line 56:
	== See also ==		== See also ==

			* Intro to [[Vector Database Management\|vector data model]] (with drawing)
	* [[Vector topology]]		* [[Vector topology]]
	* [http://grass.osgeo.org/programming7/vlibTopology.html#vlibTopoExamples Topology examples] (GRASS Programmer's Manual)		* [http://grass.osgeo.org/programming7/vlibTopology.html#vlibTopoExamples Topology examples] (GRASS Programmer's Manual)

Neteler: /* Cleaning patched polygons */

2013-05-11T20:55:37Z

Cleaning patched polygons

← Older revision		Revision as of 20:55, 11 May 2013
Line 16:		Line 16:
	'''Q:''' How can I patch to fitting area maps with have been digitized separately and correct the topology? I observe that the shared polygon boundaries do not perfectly match... I need to clean topology.		'''Q:''' How can I patch to fitting area maps with have been digitized separately and correct the topology? I observe that the shared polygon boundaries do not perfectly match... I need to clean topology.

	[[Image:Polygon map topology problems.png\|center\|thumb\|500px\|Polygon vector map with topology problems]]		[[Image:Polygon map topology problems.png\|center\|thumb\|500px\|Polygon vector map with topology problems (click to see)]]

	'''A:''' You can use {{cmd\|v.clean}} for this.		'''A:''' You can use {{cmd\|v.clean}} for this.

← Older revision		Revision as of 17:48, 31 July 2014
Line 58:		Line 58:
	* Intro to [[Vector Database Management\|vector data model]] (with drawing)		* Intro to [[Vector Database Management\|vector data model]] (with drawing)
	* [[Vector topology]]		* [[Vector topology]]
			* [[Vector Overlapping Areas]]
	* [http://grass.osgeo.org/programming7/vlibTopology.html#vlibTopoExamples Topology examples] (GRASS Programmer's Manual)		* [http://grass.osgeo.org/programming7/vlibTopology.html#vlibTopoExamples Topology examples] (GRASS Programmer's Manual)