GEOSS Banner

2.2.1 Sharing features

A geographic feature is an abstraction of a real world phenomenon that is associated with a location relative to the Earth. A digital representation of the real world can be thought of as a set of features. A feature is a container for a set of values that characterizes that particular feature. Feature values are formalized in sets of properties where each property can be thought of as a {name, type, value} triplet.

Real world features are classified into feature types which can be characterized by a set of common properties. The number of properties a feature may have, together with their names and types, are determined by the feature type definition. Geographic features with geometry are those who have at least one geometric type property and one geometric value. Sharing data model problem Sharing feature collection problem Editing a feature collection problem


<<Prev T.O.C. Next>> Sharing data model problem

Fortunately, many features of the real world can be classified into a single feature type and thus share the same set of property names and types. The process of choosing and defining feature types that build a feature collection are called data model definition.

Currently, almost each GIS software vendor has its own data encoding. In many GIS softwares, the definition of the data model starts by distributing the different feature types into different layers. Each layer can only contain a particular feature type with a particular kind of geometry (e.g. point, line or polygon) and defines a table of attributes that a feature can have. One of the most common formats that use this approach is the shape file, which can only contain a feature type with its associated geometric property in a binary file (.shp); the non geometric attributes will be contained in a table file (.dbf) as well as in a data indexing file (.shx). In this approach, the way features are going to be visualized (symbolized) is not included in the data model and it is left at the user discretion.

In this case, the data model is described by the number of layers, the use of points, lines, polygons etc, and by the data table field type's definition.

On the other hand, many CAD software vendors use another approach. Even though the feature types are also classified into layers, now the properties are represented by symbolization properties like colors, line width, line style, etc. Commonly, all feature types are stored in a single file (such as .dxf or .dgn).

In this case, the data model is described in a separated document where layering and symbolization are related to feature attribute types.

Other models are also possible, such as the geodatabase model where features are associated to records from tables from a database. Each feature type can be recorded in a different table and each property is stored with a date field. Spatial data can be both stored in a specific kind of data fields (geospatial fields) or as a list of coordinate sequences in separate tables (in numerical fields).

In this heterogeneous situation, there is a need for a unified feature type definition and encoding. There is also the need for a data service that could inform and communicate the feature type’s definition. The WFS services define the DescribeFeature operation as a way to request feature types, and these can be shared using GML application schemas. Sharing feature collection problem

A feature collection is a sequence of different types of features. In the scenarios previously described, feature collections can be expressed in different data formats by different software vendors. Fortunately, features can be stored in files which in turn can be redistributed by web accessible folders or by ftp. For example, the Circum-Arctic Map of Permafrost and Ground-Ice Conditions ( can be accessed by ftp via in shapefiles.

Nevertheless, this approach does not offer the user the possibility to control the data format used, and it is completely up to the producers who offer their own favorite format and in some cases other popular formats. This usually leads to the coexistence of several different incompatible data formats. Furthermore, some geospatial information can generate large files which can be difficult to transmit. Therefore, to be able to extract only a subset of elements from the original file would be an asset.

In this heterogeneous situation, it is detected that a common way to request a subset of a feature data from some feature types is needed. Therefore, the WFS services define the GetFeature operation as a way to request subsets of feature collections, being the features shared in GML encoded files. Editing a feature collection problem

Feature collections aren’t static. Sometimes, the representation of a feature is not accurate enough, and later, a better representation becomes available; or sometimes the real world changes and their feature representations have to be updated accordingly. In our previous example, where data was held in web accessible folders or by an ftp file, the simplest approach would be to update the dataset and replace the whole file with the updated version. This is only possible when the changes are made in a centralized way, where there is only one person responsible for the management of the dataset to be updated. In other cases, different independent actors maintain a single dataset from different places. In the worse scenario, each actor could use a different format and a different set of tools to do it.

When a decentralized and heterogeneous situation occurs, the need for a common way to sent updates of some features, while keeping the majority of them intact is of great importance. The WFS services define the Transaction operation in order to create, update or delete some features in a feature collection; it also uses GML encoded files to communicate which features are being affected by the operation.


<<Prev T.O.C. Next>>


Files (0)

You must login to post a comment.