deegree web services aim to comply to the OGC standards, thus providing the best choice for interoperable spatial data infrasturctures with free and open source software.
The deegree WMS supports the OGC standards 1.1.0, 1.1.1 and 1.3.0. It is official OGC reference implementation for versions 1.1.1 and 1.3.0.
The following list of features is not complete, but highlights some of the more interesting parts of the deegree WMS:
deegree WMS supports HTTP GET and HTTP POST requests, at least if they are described by the WMS specification
- deegree WMS is very flexible when it comes to layer content:
- Several data sources can be combined in a single layer.
- Different kinds of data sources can be combined for one layer.
- Each data source can be used with its own filter. (e.g. filter encoding for WFS)
- If two or more data sources using different coordinate reference systems (CRS) shall be combined within one layer, deegree supports the necessary coordinate transformation. Even for WCS raster data.
The deegree WMS can be configured to respond in almost any possible CRS. A full list of currently supported CRS can be found in the SVN. And if your CRS is not yet included, it will most probably be no problem to add support for it.
- Data sources for deegree WMS can be:
- All common OGC web services such as WMS, WFS, WCS, either as local or remote services
- Postgres/PostGIS or Oracle Spatial. Any arbitrary SQL statement can be used to create the WMS layer content.
- deegree WMS supports and uses style definitions (SLD 1.0)
SLD GetMap requests are supported for named layers as well as user layers.
- It is even possible to use charts (pie, bar, line) as point symbolizers via SLD
- deegree WMS supports feature info requests
- Not only for vector data, but also for raster data
- As the feature info response is parsed through xslt, the result can be any possible text/xml format.
- What's more, the response may be completely different for each and every feature type.
- deegree WMS supports unrestricted layer nesting.
- deegree WMS is very stable even for large scales:
- A deegree WMS serving a raster data source of 3TB can handle 150000 requests per day (~12 h)
The deegree WFS focuses on the Web Feature Service Implementation Specification 1.1.0. This standard is supported and tested well. Support for version 1.0.0 is also available, but requires the processing of requests and responses by (generic) XSLT scripts. Here's a list of the supported request types:
GetCapabilities: supported (XML+KVP)
DescribeFeatureType: supported (XML+KVP)
GetFeature: supported (XML+KVP). Parameters traverseXLinkDepth and traverseXLinkExpiry are not evaluated. Requesting features by id is only available when the feature id prefices are unique.
GetFeatureWithLock: supported (XML+KVP), same restrictions as GetFeature
GetGmlObject: Currently not supported. Partial implementation should be possible, see discussion here: http://sourceforge.net/mailarchive/message.php?msg_id=48FD9B02.5020003%40lat-lon.de
Transaction: supported (XML), KVP is not available, supported idGen modes (Insert): GenerateNew and UseExisting. ReplaceDuplicate is not available.
LockFeature: supported (XML+KVP)
Some remarkable features of the deegree WFS implementation:
Complex features: The deegree WFS supports complex features, i.e. features which have feature-valued properties. Nesting depth is arbitrary and cyclic structures are possible as well.
Configurable ID generation: For the generation of new feature ids on inserts, different strategies are available (UUID, DB_SEQ, DB_MAX, PARENT). Also, the lookup of already existing features (or sub-features) is possible (requires the definition of the feature equals-relation by setting the relevant properties to be "identity parts"). Already existing features are not inserted again. Existing subfeatures are identified and referenced in the new features.
Coordinate transformation: Coordinate transformation of input and output geometries and bounding boxes is possible and delegated to the backend if it supports it (see below).
Non-linear geometries: Some support for non-linear geometries is available. gml:Arc and gml:Circle elements in a Transaction are automatically linearized.
Compatibility: For DescribeFeatureType and GetFeature requests, a quirks mode is used when feature type names with unbound/missing namespace prefices are used. This is important to improve interoperability with the 1.0.0 standard and broken 1.1.0 clients.
Schema-based configuration: Feature type configuration is based on annotated GML application schemas. Note: Although many common constructs are understood, not every schema can be used right away. However, it is generally possible to transform a GML schema into a form that the WFS can process and use XSLT to transform between the "internal" format and the output format.
Flexible output formats: For each feature type and output format, an XSLT script can be registered to transform feature collection responses. Also, a schema document can be registered that is returned as the DescribeFeatureType response. This way, unsupported schema structures and XML types (e.g. gml:CodeType) can be used, although the deegree WFS does not support them natively. However, it's currently not possible to transform a response with different feature types using different XSLT scripts. Incoming transactions can be transformed using XSLT as well.
Available functionality depends on the used backend. Full functionality is offered by the PostGIS and Oracle datastore implementation.
POSTGIS (PostGISDatastore): Supports all deegree WFS features. Native CRS transformation of input and output geometries and bounding boxes.
ORACLE (OracleDatastore): Supports all deegree WFS features. Native CRS transformation of input and output geometries and bounding boxes.
MYSQL (MySQLDatastore): Transactions are not tested. Spatial predicates (except bbox) are currently not implemented by !MySQL, so they won't produce the expected results.
SHAPE (ShapeDatastore): No transactions, sorting is not available. The BBOX operation is the only spatial predicate supported "natively", all other spatial predicates are evaluated in-memory. No complex features.
GENERICSQL (GenericSQLDatastore): No transactions, inserting has to be performed using the GenericSQLShapeImporter. The BBOX operation is the only spatial predicate supported "natively", all other spatial predicates are evaluated in-memory. No complex features.
SDE (SDEDatastore): Not tested. Please update.
WFS (CascadingWFSDatastore): Proxy datastore to remote WFS. Does not support transactions.
CACHED (CachedWFSDatastore): Caching proxy for other datastores. Keeps all available feature instances from the datastore in memory. Does not support transactions.
The deegree WCS supports the OGC standard 1.0.0. and is official OGC reference implementation for version 1.0.0. The following list of features is not complete, but highlights some of the more interesting parts of the deegree WMS:
deegree WCS supports HTTP GET and HTTP POST requests, at least if they are described by the WCS specification
- deegree WCS supports different kinds of datasources:
- images (tif, png,.jpeg, gif, bmp ) georeferenced by worldfiles
- GeoTIFF (16BIT and 32BIT as image or as data container e.g. for DEM)
- ECW files
- Image files can be spatialy indexed by shapefiles or a geodatabase. deegree offeres tools for creating indexes.
- Transformation of CRS is supported.
- A raster/image can be transformed into each CRS supported by deegree on the fly.
- deegree WCS is very stable even for large scales:
- A deegree WCS serving a raster data source of 3TB can handle 150000 requests per day (~12 h)
More information can be found at WebCoverageService
4. Catalogue Service-Web
The deegree CSW supports the OGC Standards in the versions 2.0.0 and 2.0.2.
The following list gives an overview about the features of the deegree CSW:
- Datasources for the deegree CSW can be:
- The following requests are supported by the deegree CSW:
GetCapabilities (HTTP GET and HTTP POST)
DescribeRecord (HTTP GET and HTTP POST)
GetRecordById (HTTP GET and HTTP POST)
GetRecords (HTTP GET and HTTP POST)
- Transaction - Insert, Update, Delete (HTTP POST)
- Harvesting (HTTP GET and HTTP POST)
- The harvesting operation of the deegree CSW supports
- harvesting of single metadata records and
- harvesting of other Catalogue Services as whole (this behavior is not described in the CSW Specification)
The deegree WebMapPrintService is a deegree specific service that is not defined by the OGC. It is a bit like a mixture between a WMS and WPS that can be used to create large high quality prints.
- WMPS supports different print formats
- prints can be created as HTML, PDF and PNG
- PDF prints can contain more than one page
- WMPS supports different print sizes
- WMPS supports DIN A5 till DIN A0 print size
- WMPS will be configured more or less like a deegree WMS
- same types of datasources are supported
- same styling is supported
- it is easy to create a WMPS configuration from an already existing WMS configuration
- WMPS uses print templates defined using Jasper and iReport
- templates can include every construct (e.g. database access, chart plots) allowed by Jasper
- creating a template using iReport is very easy
- more than one template can be used within one WMPS instance
- User defined content can be passed with print request
- each template may contains several areas that will contain text (e.g. print title or description) passed with a print request
- WMPS supports long time running jobs
- WMPS can be requests asynchronouly to support creating prints from a large amount of data
- requests are stored within a database and will be available even if WMPS is stopped by an adminstrator or the machine fails
- Data sources for deegree WPVS can be:
- Remote/Local-WMS, Remote/Local-WFS, LocalWCS
- Database support Postgres/PostGIS or Oracle Spatial (over WFS).
- Asynchronous loading of data.
- Elevationmodels can be vector data or raster data
- Datasets can be raster/image data and/or vector data (buildings)
Scene representation is done with java3d >1.5
- Requests (only HTTP GET):
- Get3DFeatureInfo is supported
GetView is supported, Pitch,Yaw and Roll can be arbitrary values between 0 and (2)PI
- NOT supported
- SLD Styles
- Caching of datasets
Uses the deegree CRS package as a backend for all transformations/projections (see ApiSubsystems#CRS)
- Version of implementation 0.4.0
- Following requests are supported:
- Transform (GET/POST)
- NOT supported
- Response of a Transformation can use direct declaration or a deegree inline data element.
- Multiparts are supported
- Currently following 'Objects' can be transformed:
- GML (3.1.1) Geometries (most WKT encoded as well)
- Simple data containing a list of ordinate tuples.
- Transformations can be selected by their id
- Concatenating transformations are partially supported.
The deegree2 Web Processing Service (WPS) is an implementation of OGC's Web Processing Service Deprecated Request for Comments Version 0.4.0 (OGC Document # 05-007r4). deegree's WPS is able to process Feature Collections based on arbitrary processes. OGC's WPS (Schut & Whiteside 2005) specification describes WPS as follows: “WPS defines a standardized interface that facilitates the publishing of geospatial processes, and the discovery of and binding to those processes by clients. "Processes" include any algorithm, calculation or model that operates on spatially referenced data. "Publishing" means making available machine-readable binding information as well as human-readable metadata that allows service discovery and use." Therefore the following WPS requests are supported:
GetCapabilities (HTTP GET & HTTP POST)
DescribeProcess (HTTP GET & HTTP POST)
- Execute (HTTP POST)
Although WPS is not restricted to serve processes based on spatial and/or temporal data it is meant to be a specification for processing mainly spatial and/or temporal data. The WPS Server acts as a container for an unlimited number of processes. The relation of a WPS Server to a WPS process comprises the same relation as the WMS Server to a WMS Layer.