We are getting quite close to the planned release date for the next WOML version 2010/11/15, and I must say things look pretty good: There are not too many issues left to resolve. During the last month or so I've managed to solve the problem of describing the changing wind speeds along the jet streams (by using the curve segment specific wind speed values), added several new Sensible Weather Objects (LowPressureCenter, HighPressureCenter, PolarLow, Cyclone, Anticyclone, Mesocyclone, Antimesocyclone, Mesolow, PolarCyclone, TropicalCyclone, Ridge, WarmAdvection and ColdAdvection), and a way to describe local wind speed and direction as WOML Quantity.
Majority of the new objects are really just "semantics containers" with little or no type-specific properties, but i think they are a good starting point for describing these phenomena. I've used the atmospheric phenomena descriptions of the NASA SWEET Ontology 2.1 ("phenAtmoXXX.owl") as a reference to many of the new WOML-SWO objects. It's really a good information source of phenomena definitions, especially if you happen to have some good ontology browser at hand.
Another issue that has been on my mind recently, is the necessity of keeping the non-mandatory (redundant) interpolated control curve information in WOML line objects and area objects. Currently the primary geometry of the line object is defined by "controlCurve" property, which may contain cubic spline segments as well as line string segments. In addition to this the geometry may also be expressed using as interpolated line string segments in property "interpolatedCurve" with the used interpolation frequence and unit-of-measure given as attributes. The similar duplicate geometry possibility exists for area objects' boundary rings.
The reasoning behind this dual nature of the geometry properties has been, that some applications might not need to understand the more complex (and processing-intensive) smooth curve definitions, if an interpolated version of the curve is already available as a simple-to-plot line string. But is this really worth the added complexity, data redundancy and keeping both geometry representations in sync? Most visualization applications probably interpret the "controlCurve" property anyway, when the interpolated curve is too coarse for the target resolution, or it does not exists at all. In fact, the transform-curve-to-line-string operation "asLineString" is defined in the set of curve operations of GM_Curve type of ISO/TC211 standard 19107:2001. It seems to me that this would clearly indicate that calculating line string interpolations from more general curve geometries should be implemented in software.
If you have any opinion on this latter issue, please comment on this post or send me email.