Blog

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:

• WOML Core
• WOML SWO
• WOML Quantity
• WOML Textfct

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:Bezier curve segments in the geometries of WOML line and surface objects. Previously only gml:CubicSpline and gml:LineStringSegment were 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 WeatherForecast and MeteorologicalAnalysis may 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 sharedObjects property as members of ReferenceableObjectArrayAssociationType as defined in AbstractMeteorologicalObjectCollection. These objects can be referenced by using the local Xlink variation (href attribute 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 particular ValidTimePeriods, Elevations or KnownPlaces, 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, Storm and ConvectiveStorm.
• 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 introduced FlowDirectionMeasureType for 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.

I always knew I should have paid more attention to the theory on university computer graphics lessons. Now I have to learn some things the hard way, like the proper handling of Bézier curves. For you as the users of WOML, this unfortunately means iterative improvements in the WOML geometry models.

WOML Core uses Cubic Splines (or Cubic Bézier curves) to describe the smooth control paths for line and area objects. I have used GM_Curve class of ISO 19107 standard (Geographic Information) as the reference model for implementing these curve types in WOML. GM_Curve defines a continuous curve by using 1..n connected curve segments (GM_CurveSegment). In GML 3.1 the type implementing the ISO GM_Curve model is gml:CurveType. This definition is very flexible, as each curve segment may use different curve interpolation method.

For the current WOML version (2010/05/28) I have tried to restrict the curve expression complexity by allowing only Cubic Spline type segments in the control curves for line objects. For the WOML area objects the model is even more restricted: the outer and inner boundaries (or Rings) each have only one implicit curve segment. The aim has been to make the programming the software using WOML objects easier by only using the curve types really needed for WOML objects. However as it seems the simplification has gone a bit too far in the case of area objects. The single curve segment model means that the exterior and interior Cubic Spline boundaries have to be so called Natural Splines, which semm to be far less supported in existing computer graphics software packages then the basic Cubic Bézier curves. Our software developers recently ask for the possibility to define all the WOML control curves with Cubic Bézier curve segments each having only four points: the start and the end points and two points defining curve tangent vector directions at those points. For the WOML line objects this is no problem: it is perfectly OK to give only two control point positions for each segment, and the tangent vectors can be give by vectorAtStart and vectorAtEnd properties. But for the area types the geometry model would have to change a bit.

As I was reconsidering the geometries of the WOML line and area objects, more improvement ideas came into my mind (as painfully often happens). The current dual model on either using spline or line string curves for defining the control curve seemed somewhat ugly and not really flexible enough: Especially for some areas, it really should be possibly to define the boundary curves partly with sharp-egded curves and partly with smooth curves. Also the property name polygonControlCurve in woml:AbstractLineObjectType is a misnomer: As an open curve it's not a polygon, but a line string. Furthermore the possibility of defining the geometry of an area object only indirectly by using targetRegion property instead of giving the geometry inline now seemed like a design mistake: Each WOML Feature should have a clearly defined primary geometry property. For these reasons I decided to remodel the geometry properties and types for the next WOML version. The good news is that the new geometry model is simpler and harmonized between both line and (surface) area types.

The diagrams shown above describes the properties of the current and the new woml:AbstractLineObjectType}}s side by side. The old choice between the {{splineControlCurve and polygonControlCurve has been replaced by a single controlCurve property of type CombinedSegmentedCurvePropertyType. This property may contain an element of type CombinedSegmentedCurveType defining a curve by 1..n cubic spline or line string segments (combinedSegments-element):

In this way the control curves for all the WOML line objects may consist of arbitrary sequences of cubic spline or line string segments. These segments are also now defined by directly using the gml:CubicSpline and the gml:LineStringSegment elements. The redundant and optional interpolatedCurve property remains the same as before: software may use the existing lines string interpolation of the whole curve for rendering if the interpolation attributes indicate a good enough fit considering the target rendering resolution. The idea is to make it easier for the software implementations to re-project the curves in some typical conditions as they don't have to recalculate the spline curves for the target map projection.

The (surface) area objects now have very similar changes in defining their geometries:

The former double-choice of providing a geometry is replaced by providing controlSurface property of type CombinedSegmentedSurfacePropertyType and a separate interpolatedSurface and the targetRegion/targetRegionReference choice. The exterior and interior properties of the contained surface element are of type CombinedSegmentedRingType, which in turn used the same combinedSegments element as the CombinedSegmentedCurveType for line objects:

These changes will be published as part of the next WOML Core version which is scheduled for the beginning of August 2010. The major release of the WOML Core also means a simultaneous major release for the WOML SWO, WOML Quantity and WOML Textfct schemas.

Finally a couple of links for those who have been bee patient enough to read this post up to this point: The first one is a very interesting wikipedia article about the ship-building origins of the Spline curves before the computer graphics. The second is much more boring, but possibly useful: If you don't want to pay 238 Swiss frangs for the ISO/DIS 19107 standard document, you can download it for free from the OGC portal.

I finally managed to create a proper web site for the WOML, it's now available under the FMI's public wiki site at http://agora.fmi.fi/display/WOML/. Once again a conference publicity created the necessary momentum: I wanted to have a properly arranged information package to show at the EGOWS meeting in ECMWF last week, so I spent a couple of work days to export and publish all the WOML schema and documentation files and type down some (hopefully) descriptive text for each of the WOML packages.

The reception for my presentation about the SmartMet II WOML Editor seemed to be quite good, at least there was some discussion and comments about WOML amongst the participants. I think we will really get some good comments and suggestions for improvements when more people start playing with it. During the meeting we also had an opportunity to visit Oxford (thus the photo on the left). The city was quite turisty (not surprising), but inside the colleges' walls you could still get a quite, but intense feeling some serious figuring out going on.

The other thing in my task list for the EGOWS this time was the idea of describing meteorological feature and coverage data visualization using OGC Styled Layer Descriptor and Symbology Encoding standards. I must say that one hasn't really caught fire yet. The current versions of these standards are not expressive enough (no directed line symbology, tails, ends etc.), so the developers tend to ignore the standard. I'm still to hear anyone from the meteorological global community really trying to do anything operational with those standards. It seems to be quite difficult to build momentum for this work right now inside the met community, so perhaps the standardized visualization will have to wait awhile.

In this blog I will notify you about all releases and other WOML-related news, so stay tuned! There is an Atom syndication feed available for those who are interested in following this blog using a feed reader.

By the way: the WOML Java library jar files generated with Apache XMLBeans are not yet linked to the wiki, let me know if you'd like to have them available. They are really just a bunch of Java class files, and rather big, so I'd like to know that someone really uses them before I start offering the downloads. We actually build them using Maven2, so I might just offer the maven pom file for download..