WishList for deegree3
This is a list of wishes for functionalities in deegree3. Basically most functions of deegree2 should be supported. Furthermore the following requirements occur:
Contents
1. common
- full proxy support including user authentication
tolerant mode (GFI & ArcGIS, version (e.g. 1.0) with WFS, ... )
- improved logging
heavy load proof (e.g. OpenLayers fires several GetMap request at the same time)
- make sure library dependencies are clear.
- try to use recent external libs. With deegree2 we deliver an outdated xerces of version 2.5 (2003) which is required by batik but is therefore used for the whole deegree.
- It should be clear how geometries (especially polygons) are modeled in deegree3 with respect of the orientation of outer and inner rings. Currently deegree2 relies on jts and so does postgis which define the outer boundary to be clockwise and the inner rings to be CCW. Therefore validation in Openjump and Postgis succeeds but does not in Oracle. Oracle and GML seem to include ISO19107 which defines it to be CCW for outer rings and CW for inner rings.
OpenGIS Implementation Specification for Geographic information 1.2.0 - Simple feature access - Part 2: SQL option 06-104r3 "Polygon rotation is not defined by this specification; actual polygon rotation may be in a clockwise or counter-clockwise direction.",
ISO19107 Slide 21Implicit right hand rule and therefore CCW/CW, but seems to be explicitly set also (please verify).
OpenGIS Geography Markup Language (GML 3.2.1) Encoding Standard 07-036 Page 280 "GM_Surface is represented by the Surface object element in GML. The orientation is not an explicit property of a Surface and is implicitly fixed to "+" " so it seems to be possible to also set the orientation explicitly.(please verify.)
- Please verify further specs.
- XML-output should always be pretty printed.
- It should be possible to change service configurations while a service is running
2. mapService (AKA WMS)
The wishes have been transferred to the mapService requirements table.
3. WFS
- simple configuration method to support GML3 and GML2 for one feature type-
- Support for WFS 1.0.0, 1.1.0 and 1.2.0
Support for GetGmlObject and traverseXlinkDepth
Support for GetDomain like defined for CSW
- Support for stored queries like defined for CSW ebRIM profile
- configurable tolerance for handling erroneous requests and data
- better support for complex XML schema; configuration should be possible without using XSLT-scripts
centralisation of configuration for a feature type -> all setting for a feature type shall be made within one resource
- support for restrictions on simple datatype like enumeration or regular expressions
- support for function to be used on returned properties
- definition of common queryable properties like defined for CSW
4. WCS
- Support for point datasources and dynamic interpolation; this may means support for WFS/WPS as datasources
- Support for Ranges (time, extent, frequency etc.)
- Better performance on large datasources
- Better support for different/native color model of source images
- Better support for none-image raster data
5. catalogueService (AKA CSW)
The wishes have been transferred to the catalogueService requirements table.
6. SOS
- support for addition specifications from Sensor Web Enablement context; especially Sensor Notification Service and Sensor Alert Service should be implemented.
integration of support for determining desired temporal resolution in GetObservation requests (and extra-/interpolation method)
7. Registries
- there should be registries for styles, iGeoDesktop-modules, WFS application schemas etc.
8. Metadata editor
9. Client Web
Wishes can be added to the web client requirements list.
10. Client Desktop
- Support of code lists to be used with editor functions (e.g. X-Planung)
11. Rendering
The wishes have been transferred to the Rendering subsystem requirements table.