Initial sketch of using TSML TVP as part the aerodrome forecast content model

[ilkkarinne]

I drafted a first sketch of the IWXXM aerodrome weather forecast schema and example leveraging TimeseriesTVP and TimeseriesMetadata schema fragments of TSML 1.2. Minor changes were required for these TSML schemas to eliminate direct links with the O&M 2.0 schemas.

See my fork at https://github.com/spatineo/iwxxm-sx/blob/63bf7eb04c87755fe28cfcd088b2df61eb79fc6b/IWXXM/examples/AerodromeWeatherForecast-Example.xml

I did not create a pull request yet, as we probably want to create a separate branch in this repo for the aerodrome forecast development, so that it does not conflict with the main branch releases.

[blchoy]

Thanks Ilkka. I have created a new branch amf for the development of aerodrome MET forecast for you to work on.

[blchoy]

The first thing I would like to bring up is the spatial + temporal bounding box in iwxxm:MeteorologicalFeatureCollection and the geometry + phenomenonTime in iwxxm:MeteorologicalFeature.

Making reference to existing TAF, which is supposed to provide forecasts of weather phenomena for the area at the aerodrome (the area within a radius of approximately 8 km of the Aerodrome Reference Point (ARP)) within its valid period (see Para. 3.4.1 of ICAO Doc. 8896), we may want to define iwxxm:MeteorologicalFeatureCollection in the following way:

<iwxxm:MeteorologicalForecastCollection>
    ...
    <iwxxm:boundingPeriod />    <-- Valid period of the Aerodrome MET Forecast
    <iwxxm:boundingVolume />    <-- A disc with its centre an the ARP and radius of 8 km
    ...
</iwxxm:MeteorologicalForecastCollection>

For individual weather phenomenon, if it is also being used to represent condition of the whole aerodrome centred at the ARP for the whole valid period, we can just copy/refer to the bounding volume and period in the collection. In case the weather phenomenon is forecast for a specific location (e.g. Touch Down Zone (TDZ), then we may want to mention this in the WxObject:

<iwxxm:MeteorologicalForecast>
    ...
    <iwxxm:phenomenonTime/>    <-- Could be the same as iwxxm:boundingPeriod or otherwise.  Since this is implemented as gml:AbstractTimeObject, it can be any time object offered by GML
    ...
    <iwxxm:phenomenonGeometry/>    <-- Could be the same same as iwxxm:boundingVolume or otherwise.
    ...
</iwxxm:MeteorologicalForecast>

In this way individual WxObject can be extracted and used without loosing its spatial and temporal context, and when viewed together as a collection, it will be able to give a comprehensive picture (or story) the collection intends to give (c.f. a TAF message).

I know the above representations do not include a reference to the aerodrome itself. This is why we need to look at the use case to see if we need to (i) squeeze aerodrome descriptions into existing tags, or (ii) revise iwxxm:MeteorologicalFeature and iwxxm:MeteorologicalFeatureCollection to include aerodrome descriptions.

[ilkkarinne]

I know the above representations do not include a reference to the aerodrome itself. This is why we need to look at the use case to see if we need to (i) squeeze aerodrome descriptions into existing tags, or (ii) revise iwxxm:MeteorologicalFeature and iwxxm:MeteorologicalFeatureCollection to include aerodrome descriptions.

I think we do need to explicitly refer to particular known aerodromes, at least by id, because the names/IDs are likely to be very often used as filters for the forecast/observation information. And yes, my first idea also was that the aerodrome identification would be a separate element either in MeteorologicalFeature or MeteorologicalFeatureCollection levels, but then I thought that as the iwxxm:phenomenonGeometry element is not restricted to GML geometries, it could also function as way to provide a more generic location information (Aerodrome and its surroundings). I agree that the name "phenomenonGeometry" would suggest using a geometry and not a feature (with a geometry property).

I did not dare suggest changes in for iwxxm:MeteorologicalFeature, since the current extension mechanisms for iwxxm:phenomenonGeometry and iwxxm:phenomenonProperty seemed sufficient.

[blchoy]

I did not dare suggest changes in for iwxxm:MeteorologicalFeature, since the current extension mechanisms for iwxxm:phenomenonGeometry and iwxxm:phenomenonProperty seemed sufficient.

Thank you and I share you views. So I will add on my list of re-usable items for both iwxxm:phenomenonGeometry and iwxxm:phenomenonProperty.

[ilkkarinne]

In the discussion with TSML people at OGC two aspects favouring TVP over the domain-range encoding have come up:

1. The domain-range encoding does not allow for point-specific metadata (such as uncertainty, quality or interpolation). The same metadata elements on DR apply to the whole (piece of the) timeseries.
2. Time axis values on the DR model does not allow using timestamps for describing points in time, as the ISO 8601 notation does not strictly speaking define a temporal coordinate reference system. The Unix time (number of seconds since 1970-01-01:00:00:00Z) can be used, has an existing OGC CRS definition and would probably be OK for developers, but is less readable for humans then ISO 8601 timestamps. In TVP the timestamps can be used without a problem, as the model is not based on the ISO / OGC Coverage model, which demands the coverage domain axes are defined using well-defined coordinate reference systems.

[ilkkarinne]

I've now managed to introduce record-type values into the time-value-pair encoding of the provisional TSML IWXXM profile. This is done by using a new RecordTVP element featuring a list of values instead of a single Measure of the MeasureTVP element (see example). Values are of type xs:anySimpleType to non-numeric (category/URI) values are also supported.

The structure and the quantities included in the records are described using a new element iwxxm:pointRecord (see example)

In addition to the list of values the point metadata can now also be presented for each record field separately, see example