search

wmo-im / iwxxm

XML schema and Schematron for aviation weather data exchange
https://old.wmo.int/wiswiki/tiki-index.php%3Fpage=TT-AvXML
50 stars 22 forks source link

use of aixm:ElevatedPoint #108

Closed marqh closed 5 years ago

marqh commented 6 years ago

in IWXXM 2.x, the position is defined by

...
<gml:Point ... srsname="http://somecrs.notaurl">
  <gml:pos>  ...  </gml:pos>
</gml:Point>
...

within a <sams:SF_SpatialSamplingFeature> <sams:shape> (e.g. https://github.com/wmo-im/iwxxm/blob/master/2.1.1/examples/metar-A3-1.xml#L61)

In IWXXM 3.0RC1 the position element is altered to use aixm:ElevatedPoint

...
<aixm:ARP>
  <aixm:ElevatedPoint srsname="http://somecrs.notaurl">
    <gml:pos>  ...  </gml:pos>
  </aixm:ElevatedPoint>
</aixm:ARP>
...

(e.g. https://github.com/wmo-im/iwxxm/blob/master/3.0.0RC1/examples/metar-A3-1.xml#L36)

Questions:

  1. Why does IWXXM3 adopt aixm:ARP and aixm:ElevatedPoint when it was not used in IWXXM 2.x?
  2. Would it be possible to continue to use gml:Point instead of aixm:ElevatedPoint or aixm:ARP and aixm:ElevatedPoint to assist software and provide limited compatibility between IWXXM2.x and IWXXM3
blchoy commented 6 years ago

  1. Let's look at this the other way round. The use of O&M and hence sams:SF_SpatialSamplingFeature requires us to specify the aerodrome (or more accurately the ARP) with the use of sams:shape. The removal of O&M in IWXXM 3 allows us to describe the location of the ARP in a more logical way which is within aixm:AirportHeliport.

  2. I am afraid not if you look at the Class diagram of AirportHeliport (role ARP in upper left):

image

marqh commented 6 years ago

thank you @blchoy for this update

please may I ask:

How does this class diagram describe the use of a gml:pos element within an aixm:ElevatedPoint?

How does this class diagram describe the srsName and srsDimension attributes used on an aixm:ElevatedPosition?

many thanks mark

braeckel commented 6 years ago

The short answer is that we removed the O&M model and sams:shape was no longer available, so we tried to find an appropriate way to carry METAR/SPECI location information. As has been discussed since the very first version of IWXXM, there are two types of locations of interest with surface observations: an aerodrome reference point (the aixm:ARP - the point of highest elevation within an aerodrome) and the location at which the observation was made (where the equipment is located). Observing equipment is intended to be sited in such a way as to be representative of the entire aerodrome, this is discussed in ICAO Annex 3. An observationLocation element was added during the initial O&M removal/changes to represent observing locations, but after Choy and I had time to discuss further it clearly required more thought to represent properly since multiple sensors are often used at different locations within an aerodrome to create a METAR/SPECI report. So in https://github.com/wmo-im/iwxxm/commit/8a09fa5ee35a94b32f01e5277e1560f0d0126023#diff-38f8e7fecf61668df1712a9b12d83c60 the observedLocation element was removed, and the ARP is the only point that can be represented on METAR/SPECI at present.

In terms of compatibility aixm:ElevatedPoint is an extension of aixm:Point which extends gml:Point, and the main difference would be the element name and how elevations are expressed (see below). The IWXXM 3 approach clarifies the semantics of the location and matches the requirements set forth in ICAO Annex 3, but as you say does introduce compatibility issues. We should discuss this compatibility aspect further as a group.

There isn't much difference in terms of IWXXM-related content between gml:Point and aixm:ElevatedLocation, but the way they carry the information does differ. gml:Point can represent an N-dimensional point (realistically 2-D or 3-D), whereas ElevatedPoint represents either a 2-D or a 2.5-D location depending on whether the elevation is reported. ElevatedPoint only allows for elevations to be expressed relative to mean sea level (MSL) whereas the 3-D EPSG codes that one would use (such as EPSG:4979) with gml:Point report elevations relative to the geoid. And of course ElevatedPoint can include other information such as verticalAccuracy as seen here.

blchoy commented 6 years ago

May be Mark could elaborate at the telecon the problem they are facing? For us the new implementation is a more accurate representation of reports mentioned in Annex 3. Except for information harvesting we are not too sure what other issues the change could bring about.

blchoy commented 5 years ago

This was implemented in IWXXM 3.0.0RC3.