Issues to resolve

Integrating other data sources

posted 29 Mar 2012, 19:05 by David Pairman

There are a number of more specialised maps available that could/should be integrated with the LCDB. An example is the detailed mapping of wetlands in Taranaki. This really presents two issues; firstly what criteria should be use to accept the data set or even individual polygons from it. Assuming the data set provider is happy for integration and the dates are compatible, there still may be differences in class definition and methodology that need considering. Generally these data sets will be more detailed, but only covering limited area. Are we happy for some (limited) classes in some (limited) areas to be mapped to a higher quality?  Should we be accepting all polygons from such a data set or cutting them off at some minimum polygon size? If the latter, would you use the same threshold as the LCDB generally given the mapping is presumably better - see the Undersized polygons - remove issue?

The second issue is how to technically do the integration, given that there may already be a polygon there representing the feature at a lower resolution. We don't want to create slivers, but we also do want a reasonably automated methodology. No doubt we can come up with a set of rules, but it will inevitably be making assumptions.

Wetland polygons in Taranaki over the LCDB. Click on image to expand.

Coastal saline vegetation

posted 29 Mar 2012, 16:08 by David Pairman   [ updated 1 Jul 2012, 21:29 ]

Currently 'mangrove' and 'herbaceous saline vegetation' polygons are mapped but these generally fall outside any coastline definition e.g. Topo50 defined as mean high water spring. If we clipped to a coastline then valuable information on coastal saline vegetation would be lost. How do we solve this situation in an elegant way? See also the separate Topo50 coastline issue. Would a "land/sea" attribute be sufficient to tag polygons beyond the whichever coastline is used?

Parengarenga Harbour. Click on image to expand.


Resolved

At the April 2012 Technical Advisory Group meeting it was resolved to allow three classes; "Estuarine Open Water", "Herbaceous Saline Vegetation", and "Mangrove" to exist outside of the Topo50 coastline. An "onshore" attribute is used to indicate when a polygon is inside or outside the Topo50 coastal boundary. As part of the process of burning in the Topo50 coastline, slivers of other classes that may have been previously mapped outside the coastline were merged with one of the above classes provided the sliver was completely trapped (surrounded) by these classes (otherwise it was removed altogether to become part of the world polygon). Slivers were merged with the offshore-class that had the longest common boundary where there was a choice. Note, the process was recursive so that all "onshore-only" classes were removed or relabeled when not onshore, even if they didn't initially have a boundary with one of the three classes named above. See also the Topo50 coastline issue.

Bare surface classes

posted 28 Nov 2011, 17:54 by David Pairman   [ updated 1 Jul 2012, 21:49 by David Pairman ]

Some bare surfaces do not fit into the current group of bare surface classes - how do we fix this?  


The ‘bare surfaces’ group of classes doesn’t fill the thematic space available – for example there is no bare rock category available below the alpine environment unless it’s a landslide or along a lake or river. We’re considering the merit of merging ‘Alpine Gravel and Rock’ with ‘River and Lakeshore Gravel and Rock’ into a new generic ‘Gravel and Rock’ class. What do you think?



Collaborating agencies: Please leave your views as comments below, along with your name/organisation.


Resolved

At the April 2012 Technical Advisory Group meeting it was resolved to;
  1. Rename the "Coastal Sand and Gravel" class to simply "Sand and Gravel" (remains class 10).
  2. Combine "River and Lakeshore Gravel and Rock" and "Alpine Gravel and Rock" classes to form a new class called "Gravel and Rock" (class 16). 

A full table of the LCDB v3.0 classes, showing their relationship to LCDB-2 classes can be found in the LCDB2-3CorrelationTable document (View  Download).


Remove redundant boundaries?

posted 28 Nov 2011, 17:46 by David Pairman   [ updated 1 Jul 2012, 22:06 by David Pairman ]

Should boundaries between identical classes be removed?  


Our compilation to date has maintained an absolute respect for earlier mapping by not removing any existing boundaries, but inserting new boundaries along new or corrected land cover edges. As we do this, segments of former polygons have their attributes corrected so they often become described identically to their former neighbours. The old boundaries between neighbouring polygons therefore ceases to delineate any real difference between one side and the other so we’re contemplating a pre-release dissolve of these now-spurious boundaries to ‘clean up’ the database. What do you think?

Collaborating agencies: Please leave your views as comments below, along with your name/organisation.
Click on image to to expand.

Near Bay of Islands. The top two numbers represent original LCDB-1 and -2 classifications and the bottom three represent the current LCDB-1, -2 and -3 classifications. The cyan polygons above are now the same exotic class (54) at all there dates - should we remove the boundary? Our compilation has not removed any boundaries, yet… 


Resolved

At the April 2012 Technical Advisory Group meeting it was resolved to dissolve out redundant boundaries in the main LCDB V3.0 database. 

However, it was realised that doing so could make it more difficult to change due to correction of past errors rather than actual land-cover change - in particular if these boundaries are dissolved we couldn't tag a part of a polygon ad being corrected or the authority for the correction. To address this it was agreed that a layer of corrected errors should be produced whenever a new version of the LCDB is released. Where a part of a polygon is partitioned off as a previous error now corrected, only that part is put in the “corrected“ layer, not the parent polygon (which has also obviously been modified).

Topo50 coastline

posted 28 Nov 2011, 17:39 by David Pairman   [ updated 1 Jul 2012, 21:28 by David Pairman ]

Should we replace the LCDB current coastline with the TOPO50 coastline? 


The coastline of LCDB seems unique to LCDB. It differs from Topo50 which most would consider to be New Zealand’s authoritative coastline and (before our smoothing) it contained segments of stepped linework from early raster classification. We are contemplating delimiting the LCDB with a Topo50 coastline (through an as-yet undetermined process). What do you think?

Collaborating agencies: Please leave your views as comments below, along with your name/organisation. 

Example from Whangaroa Harbour (click image to expand)


Resolved 

At the April 2012 Technical Advisory Group meeting it was resolved to adopt the Topo50 coastline for LCDB to make it easier and more consistent to use with other data sets. In general previously mapped areas outside the Topo50 coast were truncated at the coastline. Where the Topo50 coastline fell outside the previously mapped boundary, the old "coastline" boundary was removed. Polygon boundaries (dangles) and other intersection points that previously touched the old "coastline" boundary were then extended to meet the new Topo50 boundary. In general their direction was maintained so long as they intersected within 200 metres, otherwise a direct line was taken to join the Topo50 coastline at its nearest point. 

Three classes; "Estuarine Open Water", "Herbaceous Saline Vegetation", and "Mangrove" to exist outside of the Topo50 coastline. An "onshore" attribute is used to indicate when a polygon is inside or outside the Topo50 coastal boundary. See the Coastal saline vegetation issue for more discussion on the offshore treatment. 

Undersized polygons - remove?

posted 28 Nov 2011, 17:20 by David Pairman   [ updated 1 Jul 2012, 21:58 by David Pairman ]

There are many polygons smaller than the LCDB  minimum map unit size of 1 hectare. Should we remove these, and if so, at what threshold?  


The LCDB claims a minimum map unit size of 1 ha. We’ve removed some of the really small polygons (< 0.05 ha) but among the 400,000 polygons in the database there still remain 67,000 polygons (17%) smaller than a hectare, 16,000 polygons (4%) smaller than half a hectare and 1,200 smaller than 0.2 hectares. From our observation, the smaller they are the less likely these polygons are to resolve any real difference in land cover so we’re contemplating a further elimination step before release in July. What do you think?

Collaborating agencies: Please leave your views as comments below, along with your name/organisation.

These cyan coloured polygons, near Dargaville, are <0.5 ha! (click on image to expand)


Resolved

At the April 2012 Technical Advisory Group meeting it was resolved to automatically eliminate polygons smaller than 1000 square metres (0.1 hectares). While the minimum mapping unit is nominally 1 hectare, it was recognized that some smaller features have been deliberately mapped and we didn't want to loose these.

1-6 of 6