New WOML release 2012-11-15 has been released. The main focus for this release was better support for severe weather warnings, including custom warning areas, and a new feature collection type for publishing the weather warnings and the data for the predicted hazardous meteorological phenomena together as a package.
The new warning-related feature types are part of the WOML Textfct package at least for now, but described in a separate XML Schema file.
Detailed release notes:
The was no release made for the WOML SWO module this time, as there were no changes required. The WOML Quantity was still released even the only changes were the dependency to the 2012-11-15 version of the WOML Core, because it was likely that elements from both WOML Textfct and WOML Quantity namespaces would be used together in same documents. Thus it makes sense that those elements depend on the same version of WOML Core.
List of all the issues resolved in these releases:
This year's last version of WOML modules, "2011/11/15", was released today. When announcing the previous WOML version in August I wrote that I hoped that we'd seen the last major turn in the rocky road to the final WOML curve geometry definitions. Should have known that I was wrong again. Starting from the WOML 2011/11/15 only the GML geometry types are supported, including the verbose and cumbersome gml:Bezier. Personally I don't like it, but it seems that it makes living a lot easier with many software libraries and applications, when only GML geometry types are used. This way applications can separate the geometry properties from other properties by simply checking whether they contain one of the GML geometry elements (like gml:Curve).
I won't make any promises, but right now it looks like the WOML schemas might be somewhat stabilizing, which is good news. We are in progress of taking WOML-based forecasts into operational use at FMI, gradually replacing older XML-based weather products. Hopefully some of the WOML content will also be publicly available some time in future.
If you're using WOML, be it a simple hack or an operational system, please let us know, it would be nice to get some feedback on what we're doing.
Detailed release notes:
List of all the issues resolved in these releases:
Please let us know if you have any issues with the new versions of the schemas, or would like additions or changes made in the following versions.
A new version WOML modules "2011/06/15" was released today. The biggest change in this release is what hopefully is the last major turn in the multi stage development of curve handling of WOML features. The curve handling was changed in versions 2009/06/13, 2011/03/15 and unfortunately also in this latest release.
As of this version the only supported way to use spline curves is through the new woml:CubicBSplineType which tries to model the cubic B-spline curve as it's typically interpreted in computer science: a combination of cubic Bezier curves each having four control points. There is a CubicSplineType, BSplineType and BezierType in GML 3.2, but all these are problematic to too complex for WOML purposes:
- The gml:CubicSplineType defines a polynomial spline, but it's not composed of cubic Bezier curves.
- The gml:BSplineType can be a polynomial or rational curve as specified by ISO 19107:2003. The model unnecessarily complicated and allows for too much freedom for the users when considering the application developers: WOML should only support the basic cubic B-splines for which there is a built-in support in many graphics libraries (see for example the CubicCurve2D of the Java standard library).
- The gml:BezierType extends the gml:BSplineType by restricting it's properties. While this is technically possible, restriction of complex types is asking for trouble IMHO. For the application developers the end result is that while certain properties exist in handler objects generated from the XML Schema files, their is forbidden by the schema. When we really only need the four positions of the control points for each bezier segment, the complexity of gml:BezierType is very uncomfortable.
Detailed release notes:
List of all the issues resolved in these releases:
Please let us know if you have any issues with the new versions of the schemas, or would like additions or changes made in the following versions.
A "bug fix" for the latest WOML Core was released today. The only issue fixed in this update is WOML-44. There was on error in defining ReferenceableObjectArrayAssociationType used as type of sharedObjects property in WOML collection types. The intention of this element is to contain any number of identifiable GML objects referenced by more than one element inside the WOML collection. When the same objects (like locations, parameter definitions, valid times etc.) are needed several times within one collection, they can be included only once in the sharedObjects and referenced using xlink:href attributes from other elements.
The ReferenceableObjectArrayAssociationType was defined in the following way:
<complexType name="ReferenceableObjectArrayAssociationType">
<sequence>
<element name="member" type="gml:AbstractGMLType" minOccurs="0" maxOccurs="unbounded" />
</sequence>
</complexType>
This did not work as intended however, because the "member" element could only be substituted with elements having that particular element as their substitutionGroup attribute (there were no such elements defined in WOML schemas). The correct formulation for this schema type is :
<complexType name="ReferenceableObjectArrayAssociationType">
<sequence>
<element ref="gml:AbstractGML" minOccurs="0" maxOccurs="unbounded" />
</sequence>
</complexType>
Now we can use any element having gml:AbstractGML element as their substitutionGroup as the content of elements of this type.
This change was rolled out as a minor update of WOML Core version 2011/03/15, identified by schema "version" attribute value 1.1. This means that the old schema version 1.0 was overwritten with the updated version in the schema file directory. The schema documentation for all the WOML modules was also updated to reflect the change.
Sorry for any inconvenience.
Yesterday we managed make the release versions "2011/03/15" of all four WOML modules (Core, SWO, Quantity and Textfct). This version contains some major changes in the schemas, including upgrade to GML 3.2, abandoning the interpolated versions of the curve geometries and introduction of data "time series" feature types. It was decided that it would be a good thing to combine these changes, which we know means some changes in the application code, with the move from GML 3.1 to GML 3.2. GML 3.2 schema is pretty different from the 3.1 version, contains a lot more types and elements, and uses them from several other namespaces, like the ISO/TC211 metadata and data quality (http://www.isotc211.org/2005/gmd). For this reason application developers should reserve some time to add support for this new WOML version.
For the ones interested in the history of WOML, the predecessor of WOML, FMI Meteorological Objects schema, was already upgraded to used GML 3.2 once with it's version 2009/09/07 released in September 2009. Due to the (assumed) incompatibility of GML 3.2. with WFS 1.1, this change was reverted in the next release. Now finally after 2.5 years we are bold enough to go for it again 
Some highlights of the changes:
- WOML 2011/03/15 is based on GML 3.2.1. The previous versions were based on GML 3.1.1. OGC Web Feature Service (WFS) 1.1.1 only mandates that if the requested return format is GML 3.1, the response features must be a GML 3.1 FeatureCollection. If the requested return format is something else (like GML 3.2), the return encoding does not have to use GML 3.1. Thus the spec does not force the use of the older GML version with WFS 1.1.
- The optional interpolated versions of the primary geometries of line and surface objects are now removed entirely, because of the added complexity with little real benefit to the using applications. See a previous blog post for more discussion on this issue.
- It is now possible to use
gml:Beziercurve segments in the geometries of WOML line and surface objects. Previously onlygml:CubicSplineandgml:LineStringSegmentwere supported. Note: Please tell us what you think of this change? Should we continue to support both Cubic Spline and Bezier curve segments in future versions? Which curve segment types would you prefer? - WOML collection types (like
WeatherForecastandMeteorologicalAnalysismay now only contain other WOML features. In previous versions the collection extended the the (now deprecated)gml:AbstractFeatureCollection. The reason behind this change is to simplify the job of the applications parsing WOML data: They now better what to expect to find inside the WOML collections. The downside is the decreased flexibility if WOML collections: You can no longer mix features from other schemas with the WOML features inside a WOML collection. - Updated and improved documentation in the WOML Wiki:
- All the UML diagrams have been updated to match the changes in the new version.
- UML class diagram has been added to Textfct page.
- A Usage examples page has been added to WOML Wiki. Ask for more XML examples to be included if you require them.
List of all the issues resolved in these releases:
Please note that if you use Apache XMLBeans for generating XML-to-Java mappings for WOML, the amount of generated classes (an the file size of their jar) has increased considerably: For example the size of the jar file containing the generated class files for WOML Core was about 3.9 MB in version 2010/11/15, and it's about 10.4 MB in this version. This is caused directly by the increased amount of the types and elements in the GML 3.2 and referred XML schemas compared to GML 3.1. It also takes considerable CPU resources to generate, build and especially javadoc this many classes (4905 generated class files currently from WOML Core), so you should probably consider using tools that can skip generating Java classes not needed for your WOML usage. If you find good alternatives to XMLBeans, feel free to add a comment or send me email.
We also have some very interesting discussions going on about international co-operation in WOML development and possibilities of introduction of WOML into the OGC Interoperability Experiments and standardization process. More details on this to be revealed in later posts.
As always, please give any feedback and keep sending improvement requests, currently there aren't many in the queue, so your's might get implemented sooner than you think!
Hi,
WOML site was unavailable for a couple of hours due to technical problems on Friday 25th March 2011. The generated XML Schema documentation and the schema files were available, but the site itself (inlcuding this blog) was down. Sorry about the possible inconvenience.
Just a short heads up considering next week (28.2-3.3.2011): I'll be participating in the OGC Technical Committee meetings in Bonn, Germany. If you are attending too, and would like to have a word about WOML, please come and grab my sleeve. I'll be on the conference premises (the Langer Eugen UN campus) from monday to thursday.
I'm also having a presentation on about challenges and proposed solutions in using the Observations & Measurements 2.0 joint OGC & ISO standard (currently in draft international standard phase in the ISO process) in modeling prediction data sets, like the ones created by numerical weather models. wednesday in the second MetOcean Domain Working Group session starting at 3 p.m. in room 1916. Be sure to double-check the meeting agenda as there are always schedulings and additions to it even during the meetings.
Hope to see you there!
Phew! Last week I finally managed to release the latest version "2010/11/15" of the WOML modules Core, SWO, Quantity and Text forecast. The issues pending longest consisted of documentation (who would have guessed?). All-in-all 23 issues were resolved in this release:
Some highlights:
- It is now possible to share any GML objects (with an id) among the members of a forecast or analysis by adding them to
sharedObjectsproperty as members ofReferenceableObjectArrayAssociationTypeas defined inAbstractMeteorologicalObjectCollection. These objects can be referenced by using the local Xlink variation (hrefattribute with "#" + the gml:id of the object) by any number of objects wishing to link to these shared objects. By adding often recurring elements, like particularValidTimePeriods,ElevationsorKnownPlaces, as shared objects, the verboseness of the XML representation of the forecast is reduced. This notation also makes the shared nature of these objects explicit: If you change the value of a shared object, it should also affect all the objects that refer to it. In the previous WOML versions it was only possible to share connection points shared by Line Objects. - New Sensible Weather Object types for pressure related objects:
LowPressureCenter,HighPressureCenter,PolarLow,Cyclone,Anticyclone,Mesocyclone,Antimesocyclone,Mesolow,PolarCyclone,TropicalCyclone,Ridge,StormandConvectiveStorm. - Implemented possibility to describe changing maximum wind speeds along a
JetStream(was:Jet): each curve segment may now have it's own maximum wind speed defined. - It's now possible to use categorized measurement values like "sunny" or "cloudy" as values of
GeophysicalParameterValue. Previously it was only possible to use single numerical values or numerical ranges. Also introducedFlowDirectionMeasureTypefor describing values for flow measures with both direction and a numerical value (like wind speed). - New Point or Surface objects for time series of measured or predicted values.
The documentation of SWO page in WOML wiki is much more elaborate now, including UML class diagrams for all major WOML Feature types and related object types defined in WOML and GML schemas. I will try to do the same effort with the WOML Quantity by the next release.
Have fun!
P.S. If you are using or are considering to use WOML in projects, or have any comments or suggestions, please do not hesitate to contact me or add a comment to this post. We'd really like to hear from you.
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.
The Confluence Wiki platform used is not the best possible blogging tool. For example the feeds are implemented in a pretty clumsy way: the URLs are very long and complicated, and the definition of "latest posts" is a bit odd: you have to give the time frame and the maximum post count in the feed URL. If you just try to ask say 15 latest posts, you only get maximum of 15 post that have been modified within some default time frame (a month?). This give some very annoying and unexpected results as entries seem to disappear from the feed.
I have tried to make this less of an issue now for you by explicitly giving a very long time frame if the sidebar feed URL (modified within last 1000 days). If you already follow WOML Blog using a feed reader, please update to using the following URLs:
- Atom: https://agora.fmi.fi/createrssfeed.action?types=blogpost&sort=created&showContent=true&showDiff=true&spaces=WOML&labelString%3D&rssType=atom&maxResults=15&&timeSpan=1000&publicFeed=true&title=WOML+Blog+feed
- RSS 2.0: https://agora.fmi.fi/createrssfeed.action?types=blogpost&sort=created&showContent=true&showDiff=true&spaces=WOML&labelString%3D&rssType=rss2&maxResults=15&&timeSpan=1000&publicFeed=true&title=WOML+Blog+feed
- RSS 1.0: https://agora.fmi.fi/createrssfeed.action?types=blogpost&sort=created&showContent=true&showDiff=true&spaces=WOML&labelString%3D&rssType=rss1&maxResults=15&&timeSpan=1000&publicFeed=true&title=WOML+Blog+feed
I finally managed to create the "2010/09/13" release of WOML Core, WOML SWO, WOML Quantity and WOML Textfct schemas. The biggest changes in the Core was redesign of the geometry properties for line and area objects (see my blog post from July 2010 for more details). Unfortunately these changes are not backwards compatible, but it's probably worth the effort to upgrade to the latest version of the schemas, because the geometries are much better defined now. For SWO and Textfct, the only changes were upgrading to use the new Core. In Quantity there was also some harmonization between point and area objects.
For detailed release notes see the release pages of the WOML modules: WOML-Core 2010-09-13, WOML-SWO 2010-09-13, WOML-Quantity 2010-09-13 and WOML-Textfct 2010-09-13. The issues resolved for this release are available in WOML Jira
The next WOML release is planned already for mid-November 2010 featuring the following new capabilities:
- Reusable geometries, time instances and geophysical parameter definitions. Many objects are typically repeated several times inside a WOML forecast or analysis. Valid times and parameter names (like temperature) are good examples. It will be possibly to include these shared objects in a special section inside a WOML object collection and just to refer to them from elsewhere using their gml:ids.
- Some new Sensible Weather Object types, such as pressure centers, advection and wind direction indicators. Jet objects will also be extended for defining different maximum wind values along the jet line.
A lot of work to be done within the next month, I hope I've got enough time to do it all.
Feel free to comment any issue or ask any questions about this release or WOML in general. It's obvious that the schemas are still far from complete at this point. Any suggestions for improvements and additions are also warmly welcome.
In case you haven't heard of this already, this is just a short informational notice about the third Workshop on the use of GIS/OGC Standards in Meteorology that will be held at UK MetOffice in Exeter, UK, 15-17 November 2010. The workshop is open to all interested parties regardless of being national meteorological services, research institutes, commercial companies etc. Registration is mandatory however, by 2nd October and it's preferable to prepare a presentation to further the use and understanding of OGC Standards in meteorology domain.
I'm certainly planning to be there, and I'd b pleased to discuss any WOML issues there formally or informally.
Another step in making the WOML development more organized and transparent has been taken: All the improvement requests, schema changes and other issues are now reported in the WOML Jira. The WOML project has read-only access rights for all users including anonymous ones, but reporting of the issues as well as any other kind of editing requires user registration.
I've also added some Confluence-Jira integration widgets to the WOML Wiki: The issues that have been reported and scheduled for some future WOML release are now listed at the bottom of the WOML Wiki pages for core, SWO, Quantity and Textfct.
If you wish to register for WOML Jira, please contact me by email (ilkka.rinne at fmi.fi) and I'll pass the request on our Jira administrators.
I'm sorry to inform you that the next WOML simultaneous release with the re-written curve handling among other things will be delayed by a month. The changes are practically done, but I'm heading for the last part of my summer vacation after next week, and I haven't got the time to prepare the release before that.
The new anticipated release will be on week 37 (13.-17.9.) just in time before the OGC TC meeting in Toulouse.
Sorry for any inconvenience.
Chatting with a senior colleague at FMI yesterday, the issue of usefulness of abstractions for weather condition or meteorological phenomena, like WOML Weather Objects, was raised once again. What is the point of forecasters spending their valuable working time drawing the charts with weather symbols, rain or cloud areas copied from the visualizations of the numerical weather model results when they should create added value to the forecasting process by guiding the automated systems to create products of better quality and accuracy for the current weather situation? It a very good point, we definitely should focus on creating weather objects that are highly usable in the creating automated weather products.
We have very good numerical models - why create manual forecasts?
Today the modern numerical weather models combined with high-resolution, near real-time weather radar data and satellite imaginary provide a lot of very good quality weather data in numerical gridded form. This gridded data is very convenient for making automated weather products, because the high-resolution weather data can be interpolated for almost any location and for any requested instance of time. Graphical and textual weather forecasts currently created by meteorologists on the other hand consist mostly of local "picks" of the foreseen weather conditions, local interpreted in both spatial and temporal senses. Forecaster may for example include the daily minimum and maximum temperatures and the general weather type for 10 biggest cities in a country in a forecast product. It is up to the human reader of the forecast to do the "interpolation" of the local weather conditions in time and place.
One might ask whether the human aspect is needed anymore in creating weather forecasts? If the computers do the forecasts so well and so fast why spend a lot of time manual forecasting? Unfortunately the weather models alone are not always accurate enough to create reliable forecasts. There is also a lot of conflicting weather information available and uncertainty involved: one model says the rain will start at 12:00 and the other that it's pouring heavily already at 11:30. Or that the temperature in certain area will stay above +2 degrees Celsius the next night, but what about the parts of the road going through a valley in that area? Will there be still be icing on the road? In many situations the forecasters are able to improve the numerical forecasts by using several sources of information and their personal experience in both the weather and the typical behavior of the different weather models in different meteorological situations. At the same time it is important not to waste forecasters time in creating forecast features by hand when they could as well be automatically produced by the computer-aided forecasting software.
Consolidated view: gridded forecast data and forecasters' adjustments
So, both the numerical, gridded data and the human interpretation of the predicted weather are needed to make good forecast products, but how to best use them together? One thing the meteorological offices around the world very much try to avoid is sending contradicting weather information out to the public. It does not seem very professional if the issues weather products for the same time do not say the same thing.
There are many ways to make the products based on gridded data and the ones created manually more similar. Perhaps the most simple one is carefully selecting the best model result for the current weather situation. One could also change the underlying gridded data from some close-enough model to fit the manually created forecast, or you could stick to the numerical model's forecast and hope your doubts were unfounded. Adjusting the results of the pre-calculated weather model run is not so easy however. The physical model behind the weather model is a very complex one, and changing one parameter in one place and time should reflected be adjusting some other parameters too, to keep the model consistent and usable. The more radical changes you make the more difficult it becomes to keep the model result consistent.
In principle one would have to re-run the model a little bit different way to create the adjusted result from the same source data (weather observations). Running the model on-demand is typically not feasible, but having several variations of the same model run pre-calculated helps in choosing the best fit and evaluating the uncertainty of the forecasting situation at hand. Sometimes simple adjustments can be applied quite consistently however, like accelerating or slowing down the model's time, or speed of events happening. One could locally adjust a weather model's time so that a weather front with heavy rain that was observed reaching city A at 12:00 would reach the city B one hour sooner than the model predicts. This "time forgery" often works better than trying to actually adjust the model results' parameter data, because most of the valuable weather information, like the detailed structure of the rainy areas can be kept intact.
Weather Objects as annotations to the numerical data presentation
To enable smooth drill-down of weather information the forecast products should provide good linking between the abstract weather forecast objects and the underlying grid data. The object notation should provide a good overview of the weather conditions. When an interesting object or area is found, more detailed information based on gridded weather data could be provided in the forecast product context. When seen like this the weather objects become a kind of annotations of the underlying numerical weather data, enabling the forecasters to highlight certain features and the most important weather conditions. This vision seems like a helpful to me when developing WOML: Create meaningful annotation-like objects and always provide a good links to the underlying, possibly slightly adjusted, numerical data. I don't yet know how exactly these ideas will by reflected in the future WOML versions, but at least I feel a bit more confident now in using the WOML together with other kinds of meteorological data.