...
How to make the standard extendable
Meating Meeting with EPA on how to make OpenMI and FRAMES work together, and also several reviewers, have revealed the necessity of making the standard extendable instead of "all inclusive". since the "all inclusive" is very difficult to predict.
The base idea is to make very general versions of interfaces, and provide specializations of these. These specializations can be released at a later stage than the standard, and without affecting the standard.
Strategy for releasing 2.0
...
- Point
- LineString - values defined on each LineString coordinate (node based values on a line)
- MultiLineString - values defined on each LineString (element based values on a line)
- 2D/3D mesh based - the IElementSet of today
- Element values (finite volume type values)
- Node values (finite element type values)
- Grid based, element/node/face values
- Structured grid, (x0, dx, xCount)^dimension + rotation from true north
- CurveLinear grid (coordinates for all grid points)
- Polygon/MultiPolygon
Some of these have directly an OGC feature counterpart, while others (the grid) has not. Some of these are covered by the current element set, and some are not, or only in a "generic" geometrical way, i.e. without topology information.
...
Releasing full standard, reflecting all suggested requests, including SDK and GUI.
Existing Current problems:
No model, neither test models nor real world model has really been used and tested using the 2.0 standard. Hence, there are many unknowns and in order to get around all possible issues, quite a lot of work is required.
Limited resources within OATC for testing and development, in order to get as well the standard as the SDK "correct".
...