deegree3 developer meeting (2008/09/10)
Protocol by: MarkusSchneider
Participants: RutgerBezema, ChristianKiehle, AndreasPoth, MarkusSchneider, OliverTonnhofer
Contents
1. Regular developer meetings
It was decided that future deegree3 developer meetings should be held at regular intervals:
every Tuesday at 10:00 AM
The developer meetings will provide a means for
- Monitoring current deegree3 activities
- Coordinating deegree3-related tasks
- Discussing technical/organizational issues
2. Documentation of deeegree3 development status
The deegreeWiki will be used to document the development of deegree3. An initial page structure has been created at deegree3/development.
3. Development process
The deegree3 development process focuses on subsystems, i.e. functional units with specific responsibilities for various aspects of geoprocessing. We want to achieve the following goals with this approach:
- Designing a well-usable API that meets all approved requirements.
- API stability: after a subsystem has reached a stable state, client code can rely on interface stability of the subsystem API.
- Delegating development responsibilities: every subsystem should have a primary maintainer.
- Defining pieces of work that need to be done.
- Reduce frustration of developers: every developer that depends on a subsystem has a fair chance to bring in his/her requirements/ideas.
Each subsystem has it's own wiki page that documents requirements, status and design issues.
4. Build Process
The build process will use Ivy for resolving the dependencies between the deegree3 SVN modules.
5. Upcoming / ongoing tasks
5.1. WPS / Processing
The WPS protoype has to be delivered at the end of September. The following important issues have to be resolved quickly:
Achieve an acceptable stability grade of the deegree3 processing API. External developers will start to develop WPS processes based on this API and incompatible changes have to be avoided.
Provide support for SOAP requests in the deegree3/OGCFrontController.
5.2. Feature and object model
Markus reported that the feature and object model of deegree3 is progressing. It is expected that the following functionality will be available at the end of week 38:
- Parsing of GML application schemas into feature types
- Parsing and exporting of GML documents (bypassing geometry elements at the moment)
To take the functionality to the next level, parsers for GML geometries will be needed next.
5.3. WCS / RasterAPI
Oliver is working on the deegree3 WCS. It was noted that the WCS service interface is of minor relevance, as WCS clients are rather uncommon. The raster functionality is usually accessed through the WMS interface or internally in deegree. Only the WCS 1.0.0 standard will be implemented for now.
It was noted that the crucial process of index-building (RasterTreeBuilder) needs a good documentation and maybe a GUI.
5.4. Configuration issues
The discussion about avoiding redundancies in service configuration documents was postponed. However, the following aspects have been noted:
- The PSC has to be involved when configuration changes are planned.
- A (web-based) GUI for the configuration / administration of deegree3 services is very desirable, but will not be followed with a high priority at the moment.