developer/psc meeting 2009-04-07
This was a meeting of the developers with the psc and each other.
Participants: AndreasPoth, JensFitzke, RutgerBezema, MarkusSchneider, AndreiIonita, AndreasSchmitz
Protocol by: AndreasSchmitz
Contents
1. WPVS
The WPVS is near completion. Recently, memory problems/leaks were found and fixed, and the rendering engine is running stable. VRML can be imported and displayed in a satisfactory manner. CityGML support is still missing, but work in progress (the feature model can already parse the schema and parse instance documents).
2. d3 core
Work on the core is being taken up by MarkusSchneider again, in particular work on the feature model. Analyzing schemas works quite good already. Unsupported parts (ie, non-GML parts) can be mapped to custom classes which have to parse the parts in question. It is planned and generally agreed that it would be desirable that these properties may be generically represented using an XML tree and/or a string, so supplying custom beans and parse methods is usually not necessary.
AndreiIonita is beginning to work on GML export, version 3.1.1. His previous work on the CRS database backend has already been enabled and is currently used by default.
3. Rendering 2D
New requirements are appearing elsewhere in this wiki that concern the rendering of line signatures. Especially in the planning community it is an often voiced requirement that such line signatures bend nicely around corners, which is not easy to implement and specify in a general way. deegree 2 performs unsatisfactory here at the moment, where such signature parts are usually specified as images, which are then painted either at the beginning of the next line segment, or in a somewhat undefined manner somewhere around the corner in question. Such images would have to be warped in some way, so they can be fit around the corner. XPlanGML is an example of a standard mandating the proper use of such line signatures.
4. Module structure
Currently, we have four means of modularizing deegree 3. We have:
- svn modules
- jars
- subsystems
- packages
where the svn modules correspond to the jars being built. The subsystems and packages are modularizations that have manifested itself during the past year's development process. The discrepancies between all these means should be removed as discussed in this meeting.
Generally, we have to views upon modules, the user's view and the developer's view. These do not necessarily match/overlap. There was some discussion what should constitute the base modules and what not (where to draw the line between modules), and the consensus was to use the subsystems defined in the paper by MarkusSchneider. The end result of this will be that subsystems == packages == developer's view. The svn module structure will be broken up, so that the source code remains in a central location. An automated build process will then be used to break up this structure again.
The users will usually be confused by too many packages/jars, so it was generally agreed that there will be a few jars, which are built from the subsystems. So each jar will contain one or more subsystems. Example: the commons.jar includes the subsystems commons and crs (note that the commons jar and the commons subsystem are obviously different things here!). Users that want to delve into the code can then easily find the code belonging to the jars by using a documentation page where is written which jar contains which subsystems. An automated build process will make it easy to swap one subsystem to another jar. While subsystem boundaries can change over time, the jars will not, as a consistent release process is important for the user community.
Apart from that, another, high level modularization was agreed upon. The core API consists of the subsystems (without services), whereas there are a number of high level systems that only make use of the API but are not strictly part of it.
- iGeoDesktop/other clients: once ported to deegree 3, the core does not have anything to do with it (as deegree 2 does not have anything to do with it now)
- services: in case the feature/raster systems are working as expected, it should be possible to implement the services without dependencies from the core to the services as well
- processes: geoprocessing tasks could be implemented independently as well
- tests: high level tests could be implemented that test bigger workflows such as loading features from a DB, transforming the feature collection to some srs, exporting and validating the GML, rendering the transformed collection etc.
- tools: command line/GUI tools are another example of code that simply uses the subsystems to perform its tasks
So in the end, all of these high level systems could be implemented in a different code base than the core, enabling a further modularization.
5. Tests
Besides the already mentioned high level tests, tests should also be written on subsystem level. Other independent tests include service testing over HTTP.
6. Other
To keep the psc informed, mails informing of new protocols should be CCed to psc at deegree.org