5 Model Generalization
97
3. Get one specific feature, identified with a feature id. Here there is again a choice:
either the filter encoding can be used (see above) or the KVP ’featureid=...’ in a
HTTP GET ‘GetFeature’ request, as in the URL string:
http://www.someserver.org/servlet/wfs?REQUEST=GetFeature
&VERSION=1.0.0&TYPENAME=gdmc:parcel&featureid=parcel.93
5.4.3 Geography Markup Language
The output of a WFS service is a GML data stream. GML is one of the other important interoperability initiatives of OGC. Its current version is 3.1.1 [12]. GML is
a domain-specific XML vocabulary meant for the exchange of geo-data. Until version 3, GML only contained the basic geometry types (point, polygon, line string).
Version 3 introduced more complex geometry types and also topology. Apart from
its grammar and syntax, GML also has a meta-model (or conceptual model). At first
(GML 1 and GML 2) this was the Simple Features Specification of OGC itself. From
GML 3 the conceptual model is based on ISO 19107. The core of GML consists of a
large number of geometry and topology data types (primitives, aggregates, and complexes) to encode the spatial properties of geographical objects. Apart from the core
data types, the GML specification also contains rules how to derive other, domainspecific spatial and non-spatial data types (using XML Schema).
5.4.4 Interoperability and Getcapabilities
The basic goal of the Web service specifications of OGC is that it must be possible
for service software and client software of different vendors to communicate without
having ‘inside knowledge’ of that other component. This is achieved first of all by
writing down in an interface specification (or protocol) how to access that type of
Web service, which requests are possible, what are the parameters, which of these
parameters are optional. What is also specified is what the response of the Web service to the requests should be (in the case of a WFS GetFeature request always GML
must be offered by the service, other formats are optional).
The second method to enhance interoperability is by letting an OGC Web service
be ‘self-describing’: for that purpose, all OGC Web services have a GetCapabilities
request. The GetCapabilities response of the service contains meta-information about
• the requests that are possible on that particular Web service and the URLs of
those requests;
• the responses that are supported (the output that can be expected);
97
3. Get one specific feature, identified with a feature id. Here there is again a choice:
either the filter encoding can be used (see above) or the KVP ’featureid=...’ in a
HTTP GET ‘GetFeature’ request, as in the URL string:
http://www.someserver.org/servlet/wfs?REQUEST=GetFeature
&VERSION=1.0.0&TYPENAME=gdmc:parcel&featureid=parcel.93
5.4.3 Geography Markup Language
The output of a WFS service is a GML data stream. GML is one of the other important interoperability initiatives of OGC. Its current version is 3.1.1 [12]. GML is
a domain-specific XML vocabulary meant for the exchange of geo-data. Until version 3, GML only contained the basic geometry types (point, polygon, line string).
Version 3 introduced more complex geometry types and also topology. Apart from
its grammar and syntax, GML also has a meta-model (or conceptual model). At first
(GML 1 and GML 2) this was the Simple Features Specification of OGC itself. From
GML 3 the conceptual model is based on ISO 19107. The core of GML consists of a
large number of geometry and topology data types (primitives, aggregates, and complexes) to encode the spatial properties of geographical objects. Apart from the core
data types, the GML specification also contains rules how to derive other, domainspecific spatial and non-spatial data types (using XML Schema).
5.4.4 Interoperability and Getcapabilities
The basic goal of the Web service specifications of OGC is that it must be possible
for service software and client software of different vendors to communicate without
having ‘inside knowledge’ of that other component. This is achieved first of all by
writing down in an interface specification (or protocol) how to access that type of
Web service, which requests are possible, what are the parameters, which of these
parameters are optional. What is also specified is what the response of the Web service to the requests should be (in the case of a WFS GetFeature request always GML
must be offered by the service, other formats are optional).
The second method to enhance interoperability is by letting an OGC Web service
be ‘self-describing’: for that purpose, all OGC Web services have a GetCapabilities
request. The GetCapabilities response of the service contains meta-information about
• the requests that are possible on that particular Web service and the URLs of
those requests;
• the responses that are supported (the output that can be expected);