Many hyperlinks are disabled.
Use anonymous login
to enable hyperlinks.
Overview
Artifact ID: |
2e0f70ffeae7af9d751abf770eda8ae42e7ccf93
|
Page Name: | topo-advanced |
Date: |
2015-11-13 19:36:06 |
Original User: |
sandro
|
---|
Parent: |
7e5bbea3b6e15afe10cba45d20bbc1d9faeba645
(diff)
|
Next |
afbde461465df51e8a609c1ee64117b609f009bd |
---|
Content
Topology-Geometry: an advanced tutorial
|
TopoLayers and TopoFeatures
In the previous tutorial we've examined a first couple of SQL functions intended to export a GeoTable out from an existing Topology: TopoGeo_ToGeoTable() and TopoGeo_ToGeoTableGeneralize().
Anyway SpatiaLite supports an more sophisticated (and complex) approach based on TopoLayers and TopoFeatures specifically intended to support a very flexible mechanism for exporting a full set of GeoTable(s) directly deriving from a Topology.
a conceptual reference framework
- an ISO Topology is just intended to support a consistent set of Nodes, Edges and Faces 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 real geometry, but Face primitives simply correspond to a virtual geometry thus necessarily requiring to be dynamically recontructed every time that they are referenced (and this could easily become a real bottleneck).
- on the other hand a GeoTable (aka layer, 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.
- 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.
- 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.
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.
In such a context a fence could easily correspond to a Feature within the "fences" layer, could probably delimit two adjacent agricultural areas and could eventually be part of some administrative boundary.
- TopoLayers and TopoFeatures represent a complex and flexible structure intended to establish permanent explicit correspondences between Topology Primitives and GeoTable Features.
- each TopoLayer is uniquely identified by its name and directly corresponds to a single GeoTable to be exported from the Topology
An arbitrary number of TopoLayers can be created on the same Topology, and each one of them will act as a separate container.
- each TopoFeature is uniquely identified by its fid (feature-id) and corresponds to a single Feature containing an individual set of information attributes.
The Geometry for each TopoFeature is always indirectly defined by specifying a list of Topology primitives individually referenced by their IDs.
Such a geometry obviously is a virtual one, and will be actually materialized (by aggregating all referenced Topology primitives) only when exporting the destination GeoTable.
- The TopoLayers / TopoFeatures structure is practically implemented as a set of several closely related DB-tables )we'll examine later their respective layouts in full detail):
- <topo-prefix>_topolayers: this first table simply is a catalog of all TopoLayers supporting the same Topology.
Each TopoLayer is identified by its name and by its ID; both identifiers are granted to be unique.
- <topo-prefix>_topofeatures: this second table is intended to permanently store all cross-references existing between Topology primitives and TopoFeatures.
- <topo-prefix>_topofeatures_<topolayer-id>: for each single TopoLayer a separate table is required. The actual correspondence is established via the TopoLayer-ID suffix.
All these tables are intended to permanently store the information attributes for each TopoFeature in the same TopoLayer.
Different TopoLayers will obviosuly support a different set of information attributes thus requiring an individual table layout.
Anyway all these tables are always expected to declare a Primary Key of the INTEGER type named fid and intended to be an unique identifier for each TopoFeature.
- Several SQL functions are specifically intended to support processing operations based on TopoLayers and TopoFeatues; we'll examine later all them in full detail.
a quick practical exercise
Prerequisites:
- download the sample DB-file from here
It contains Census data (2011) kindly released by ISTAT under CC-BY license terms.
The original datasets have been slightly rearranged in a more convenient form.
All geometries are in the SRID 32632 (WGS 84 / UTM zone 32N):
- comuni: Tuscany Municipalities / Local Councils
- province: Tuscany Provinces / Counties
- regioni: Tuscany Region itself
- unioni_com: Unions / Confederations between Municipalities
- prov_istat2011: an alternative Provinces dataset.
This dataset is not exactly identical to province because it has a different origin (ISTAT - National Statistic Authority): both information attributes and geometries are slightly different.
- uncompress the downloaded db-file (tuscany-admin.sqlite).
- now you can finally start a SpatiaLite session using your preferred SpatiaLite front end tool:
- Attention: you must not directly connect to tuscany-admin.sqlite; you are expected instead to connect a new (empty) DB-file named tuscany-topo.sqlite
|