<table cellspacing="12" width="100%">
<tr><td colspan="2">
<table width="100%" bgcolor="#f0f0f8">
<tr><td align="center">
<h1>Topology-Geometry: an advanced tutorial</h1>

<table width="100%"><tr>
<td width="33%" align="left"><a
<td align="center"><a to
<td width="33%" align="right"><a

<h3>TopoLayers and TopoFeatures</h3>
In the previous tutorial we've examined a first couple of SQL functions intended to export a GeoTable out from an existing Topology: <b>TopoGeo_ToGeoTable()</b> and <b>TopoGeo_ToGeoTableGeneralize()</b>.<br>
Anyway SpatiaLite supports an more sophisticated (and complex) approach based on <b>TopoLayers</b> and <b>TopoFeatures</b> specifically intended to support a very flexible mechanism for exporting a full set of GeoTable(s) directly deriving from a Topology.
<h4>a conceptual reference framework</h4>
<ul>
<li>an ISO Topology is just intended to support a consistent set of <b>Nodes</b>, <b>Edges</b> and <b>Faces</b> primitives fully covering the plane.
Topology primitives correspond to pure geometries, and can never be directly  associated to a corresponding set of information attributes.
Both Node and Edge primitives directly correspond to a <u><i>real but Face primitives simply correspond to a <u><i>virtual thus necessarily requiring to be dynamically recontructed every time that they are referenced (and this could easily become a real bottleneck).</li>
<li>on the other hand a GeoTable (aka as in the common GIS parlance) is always based on many distinct features, and for each feature a Geometry and an associated set of information attributes are expected to be declared.</li>
<li>there is further difference to be taken in proper account: Topology primitives necessarily are elementary. Feature Geometries can usually represent some complex type: MULTIPOINT, MULTILINESTRING, MULTIPOLYGON and, may be, GEOMETRYCOLLECTION. So it should be absolutely clear that a Feature Geometry does not necessarily corresponds to a single Topology primitive ; a Feature Geometry could easily be derived from aggregating many different Topology primites.</li>
<li>that's not all: many different GeoTables could evenatually be derived from a single Topology; and the same Topology primitive could play a very different role in everyone of these GeoTables.<br>
Just a basically simple example: imagine a Topology corresponding to some cadastral map. We'll surely have many potential layers: buildings, agricultural land, populated places, administrative boundaries, roads, ponds, rivers, fences and so on.<br>
In such a context a fence could easily correspond to a Feature within the layer, could probably delimit two adjacent agricultural areas and could eventually be part of some administrative boundary.</li>
<li><b>TopoLayers</b> and <b>TopoFeatures</b> represent a complex mapping structure allowing to establish permanent explicit correspondences between Topology Primitives and GeoTable Features.
<ul>
<li>each <b>TopoLayer</b> directly corresponds to a single GeoTable to be exported from the Topology.</li>
<li>a <b>TopoFeature</b> corresponds to a single Feature, contains an individual set of information attributes and detailedly specifies which Topology primitives must be aggregated in order to compose the approriate Geometry.</li>

</ul>

<br><br>
<table width="100%"><tr>
<td width="33%" align="left"><a
<td align="center"><a to
<td width="33%" align="right"><a