7.4.1. Basic functionality¶
7.4.1.1. WFS operations¶
The OGC WFS 2.0 interface defines eleven operations that can be invoked by a client. A WFS server is not required to offer all operations to conform to the standard but may support a subset only. For this purpose, the WFS standard defines conformance classes named Simple WFS, Basic WFS, Transactional WFS and Locking WFS that grow in the number of mandatory operations. The current version of the 3D City Database Web Feature Service implements the Simple WFS conformance class. Thus, it is fully OGC conformant but lacks operations from other conformance classes. It is planned to incrementally increase the functionality of the WFS in future releases.
The following table lists all WFS 2.0 operations and marks those supported by the 3D City Database WFS.
Operation
|
Description
|
Supported
|
GetCapabilities
|
The GetCapabilities operation generates a service
metadata document describing the WFS service
provided by a server.
|
X
|
DescribeFeatureType
|
The DescribeFeatureType operation returns a
schema description of the CityGML feature types
offered by the WFS instance.
|
X
|
ListStoredQueries
|
The ListStoredQueries operation lists the stored
queries available at the server.
|
X
|
DescribeStoredQuery
|
The DescribeStoredQueries operation provides
detailed metadata about each stored query expression
that the server offers.
|
X
|
GetFeature
|
The GetFeature operation returns a selection of
CityGML features from the 3D City Database using a
query expression.
|
X
|
GetPropertyValue
|
The GetPropertyValue operation allows the value of a
feature property or part of the value of a complex
feature property to be retrieved from the 3D City
Database for a set of features identified using a query
expression.
|
–
|
LockFeature
|
The LockFeature operation is used to expose a long-
term feature locking mechanism to ensure consistency
in data manipulation operations (e.g., update or delete).
|
–
|
GetFeatureWithLock
|
The GetFeatureWithLock operation is functionally
similar to the GetFeature operation except that in
response to a GetFeatureWithLock operation, the
WFS shall also lock the features in the result set.
|
–
|
CreateStoredQuery
|
A stored query may be created using the
CreateStoredQuery operation.
|
–
|
DropStoredQuery
|
The DropStoredQuery operation allows previously
created stored queries to be dropped from the system.
|
–
|
Transaction
|
The Transaction operation is used to describe data
transformation operations (i.e., insert, update, replace,
delete) to be applied to CityGML feature instances
under the control of the web feature service.
|
–
|
7.4.1.2. Service URL¶
The service URL or service endpoint is the location where the 3D City Database WFS can be accessed by a client application over a local network or the internet. This URL is typically composed as follows:
The actual URL depends on the servlet container and your network configuration. Please ask your network administrator for the protocol (typically http or https), the host name and the port of the server. The context path is typically added to the URL by the servlet container. Please refer to the documentation of your servlet container for more information. The last component wfs of the URL identifies the service and makes sure that requests are routed to the WFS service implementation.
Note
For Apache Tomcat, the name of the WFS WAR file will be used as
context path in the service URL. For example, if the WAR file is
named citydb-wfs.war, then the service URL will be
http[s]://[host][:port]/citydb-wfs/wfs. To pick a different context
path, simply rename the WAR file or change Tomcat’s default behavior.
7.4.1.3. Service bindings¶
A service binding refers to the communication protocol that shall be used for exchanging request and response messages between a WFS server and a client. The WFS 2.0 interface standard defines HTTP GET, HTTP POST and SOAP over HTTP POST as possible service bindings for WFS 2.0 implementations.
The 3D City Database WFS implements both the HTTP POST and the HTTP
GET conformance class. Therefore, a client can choose to send a request
either XML-encoded using the HTTP method POST (using text/xml as content
type) or KVP-encoded (key-value-pair) using the HTTP method GET. Note
that the XML content of POST messages sent to the server must be
well-formed and valid with respect to the
WFS 2.0 XML Schema
The following table summarizes the operations and the supported service binding as offered by the 3D City Database WFS.
Operation
|
Service Binding
|
GetCapabilities
|
XML over HTTP POST and KVP over HTTP GET
|
DescribeFeatureType
|
XML over HTTP POST and KVP over HTTP GET
|
ListStoredQueries
|
XML over HTTP POST and KVP over HTTP GET
|
DescribeStoredQuery
|
XML over HTTP POST and KVP over HTTP GET
|
GetFeature
|
XML over HTTP POST and KVP over HTTP GET
|
7.4.1.4. CityGML feature types¶
The 3D City Database WFS supports all CityGML top-level feature types,
and corresponding feature instances will be sent to the client upon
request. If you just want to advertise a subset of the CityGML feature
types, you can restrict the feature types in the config.xml settings
(cf. Section 7.3.2). In addition to the predefined CityGML feature
types, the WFS can also support feature types defined in a CityGML ADE.
This requires a corresponding ADE extension to be installed for the WFS
and to be registered with the 3DCityDB instance (cf. Section 7.2).
Note
Appearance properties of CityGML features such as textures or color information are currently not supported by the WFS implementation and thus will not be included in a response document.
The supported CityGML feature types together with their official XML namespaces (CityGML version 2.0 and 1.0) and recommended prefixes are listed in the table below.
Feature type
|
XML namespace
|
XML prefix
|
Building
|
bldg
|
|
Bridge
|
brid
|
|
Tunnel
|
tun
|
|
TransportationComplex
|
tran
|
|
Road
|
tran
|
|
Track
|
tran
|
|
Road
|
tran
|
|
Square
|
tren
|
|
Railway
|
tran
|
|
CityFurniture
|
frn
|
|
LandUse
|
luse
|
|
WaterBody
|
wtr
|
|
PlantCover
|
veg
|
|
SolitaryVegetationObject
|
veg
|
|
ReliefFeature
|
dem
|
|
GenericCityObject
|
gen
|
|
CityObjectGroup
|
grp
|
Simply declare the above namespaces in XML-encoded requests using the
notation xmlns:prefix=namspace_uri. For KVP-encoded requests,
the NAMESPACES parameter shall be used to declare any namespaces
and their prefixes used in the request based on the format
xmlns(prefix, escaped_uri).
Note
The 3DCityDB WFS can correctly deal with the default CityGML prefixes
in KVP-encoded requests. Thus, if you use one of the default prefixes
from above, you can skip the NAMESPACES parameter. The CityGML
version that will be associated with the prefix by the WFS depends
on the default CityGML version in your config.xml
(cf. Section 7.3.2).
7.4.1.5. Exception reports¶
If the WFS encounters an error while parsing or processing a request, an XML document indicating that error is generated and sent to the client as exception response. Please refer to the WFS 2.0 specification for the structure and syntax of the exception response.