jsonix

Unmarshalling SOS GetCapabilities via JSONIX yields only abstract offering data


I am trying to use jsonix to unmarshall a GetCapabilities response from SOS_2_0. Below is the code I wrote to unmarshall the xml string. It seems to work fine however not all of the elements have been mapped correctly.

function jsonixParseSensors(xmlStr) {
      var module = SOS_2_0_Module_Factory();
      var context = new Jsonix.Context([XLink_1_0, GML_3_2_1, OWS_1_1_0, SWE_2_0, SWES_2_0, WSN_T_1, WS_Addr_1_0_Core, OM_2_0, ISO19139_GMD_20070417, ISO19139_GCO_20070417, ISO19139_GSS_20070417, ISO19139_GTS_20070417, ISO19139_GSR_20070417, Filter_2_0, SOS_2_0]);
      var unmarshaller = context.createUnmarshaller();
      var data = unmarshaller.unmarshalString(xmlStr);
      return data;
}

In the screenshot below it is apparent all of the 'offerings' in 'contents' are defaulted to the abstract type (SWES_2_0.AbstractContentsType.Offering) and have no information about the sensor/observation offering in them. It's odd because other elements such as 'filtercapabilities' contain all the info and attributes as well. I have tried this both with and without passing namespacing arguments to unmarshallString and it does not seem to make a difference. Is there something I am fundamentally misunderstanding?

enter image description here.

enter image description here

SOS GetCapabilities xml from Botts-Geo

SOS GetCapabilities xml from Sensiasoft


Solution

  • The problem was in the SWES_2_0 mapping. The abstractOffering property of the SWES_2_0.AbstractContentsType.Offering type was generated as "element" property:

      {
        ln: 'AbstractContentsType.Offering',
        tn: null,
        ps: [{
            n: 'abstractOffering',
            rq: true,
            en: 'AbstractOffering',
            ti: '.AbstractOfferingType'
          }]
      }
    

    This should have been an "element reference" property to allow the swes:AbstractOffering element to be replaced by other elements via substitution groups.

    This should be fixed now in ogc-schemas trunk, see the test.