European Commission logo
INSPIRE Community Forum

missing associations to OM_Observation in xsd

Hello everybody,

I plan to transform German Soil data in the INSPIRE Soil model. Unfortunately, I met the following problem when trying:

The Data Specification describes for several FeatureTypes that there are associations with the OM_Observation object (e.g. p.37: "Any soil profile can be characterized as a whole by a number of properties, of which the following are included in the model: its soil type according to the WRB soil classification scheme (WRBSoilName) and/or any other soil classification scheme (otherSoilName) with the limitation to one per dataset, and zero or more other parameters, which are expressed through soilProfileObservation associations with OM_Observation objects (see Figure 11).").

The UML diagram in Figure 11 also contains these associations (soilSiteObservation, soilProfileObservation, profileElementObservation, soilDerivedObjectObservation). Nevertheless, in the xsd (https://inspire.ec.europa.eu/schemas/so/4.0/Soil.xsd), I cannot find any of those associations even though I would them expect to appear in it. Am I missing something?

All the best and thank you for your help.

Johanna

  • Michael LUTZ

    Dear Kathi, Tomas,

    the idea of the draft schemas is to provide a resource for testing. If we get positive feedback on the changes made (both from reviewing the XSD and from using it in practice), we will migrate it into the official http://inspire.ec.europa.eu/schemas space.

    Since all additional properties, except soilDerivedObjectObservation, are optional, the change would be backwards-compatible and hence not break any existing implementations. That said, we should consider implementing the change proposed by Tomas originally, i.e. to change the multiplicity of the soilDerivedObjectObservation property from 1 to 0..*, i.e. to make it optional like the other corresponding properties, to ensure backwards-compatibility.

    So please review the draft schema, test it and provide us with feedback.

    Thanks, Michael

  • Tomas LINDBERG

    By Tomas LINDBERG

    Dear all,

    Can anyone see a valid reason for SoilDerivedObject  to have another cardinality than the other associations to OM_Observation? We will have to deliver a geometry for every observation (+ 50 in our case).

    We are in the process of implementing SOIL using soilDerivedObject right now and it would be useful to our work (data model, GML-files, View Services) to know if the change request will be accepted eventually, even if it takes some time to make schemas official. In short, it feels awkward  to deliver data according to the current schema when we think it is not correct, but would it be risky to adjust to the proposed the change to 0..*?

  • Tomas LINDBERG

    By Tomas LINDBERG

    Dear Michael,

    It seems like Johanna Ott tested the draft schema (see reply from 02.01.2019) and provided feedback with good results. I can also test the draft schema  during december, but it would be more rewarding to test it with the change of cardinality of soilDerivedObject  also implemented in the draft schema, and avoid another review/test period. And then finally get an official schema published with all issues solved at once early 2020.

    Is this realistic? 

    Otherwise we will probably publish our harmonized services with the current official schema, which would a pity.

  • Katharina SCHLEIDT

    By Katharina SCHLEIDT

    Taking a deeper look at the soil model, I'm starting to wonder if the cardinality of the soilDerivedObjectObservation association between SoilDerivedObject and the related Observation is correct with 1

    I still don't quite understand the details of the functionality of the SoilDerivedObject, but as this is always associated with either a SoilBody or SoilProfile with 0..*, it is still possible to associate multiple observations to a profile or body, with the only excess baggage being the INSPIRE ID and the polygon.

    Within the textual description, there is also mention of the use of SoilDerivedObject for soil mapping. In this context, it could be easier for users to access a set of polygons all pertaining to the same observed property (though formally, I would also be for opening up the cardinality of soilDerivedObjectObservation to 0..*, parallel to the observation association on Site, Profile and Element)

    Conclusion - while there is a bit of excess data encoding, to my understanding, it should be possible to put the data online correctly the way the current draft of the model stands

     

     

  • Michael LUTZ

    If I understand Tomas' request well, he would like to directly associate observations to a SoilDerivedObject, rather than having to create SoilProfile objects as intermediaries. If the source data does not contain data on soil profiles, you would have to create such objects as empty artefacts, so I guess this would not be very useful.

    In conclusion, I would propose to make the proposed change of multiplicity in the draft schema from 1 to 0..*, so that Tomas and Kathi (and others) can test it.

  • Tomas LINDBERG

    By Tomas LINDBERG

    Dear Michael,

    you understand me correctly:)

    How can we make this change in the draft schema happen? Can you put this through the formal change request process, or reopen the proposal that this forum did a few years ago?

  • Linton Donovan

    By Linton Donovan

    Hi all,

    I am also wondering when (or if) this draft-version of the Soil-schema will become official. As far as I can see there is no other way to attach observations to ObservedSoilProfile, ProfileElement and SoilSite. We do not need DerivedSoilProfile, but I guess the multiplicity for this should actually also be 0..*.
    What is the status on this draft? It becomes more and more urgent to speed up the entire harmonization.

    Linton

  • Katharina SCHLEIDT

    By Katharina SCHLEIDT

    Dear all,

    based on my experience with similar issues in INSPIRE Schemas, I'd advise all those impacted by this issue to get in touch with their national MIG representatives. I agree that it is highly unsatisfactory to have the only semi-correct schema versions listed as draft half a year before finalization is required by MS, but based on EC procedures, only the MS representatives can trigger action here.

    On a more pragmatic note, while I understand why the associations from the spatial objects within the SO dataspec to observations on these spatial objects have been created, they are not formally necessary, as the inverse association from the observation to the spatial object is available from the base O&M standard. Thus, you can still provide and query all the relevant data, the only difference is that instead of navigating from the spatial object to the observation, you must query the observations for those that pertain to the spatial object.

    Hope this helps!

    :)

    Kathi

Earth Science

Earth Science

Join this group to share your knowledge, learn and collaborate with INSPIRE Earth Science Cluster for Geology, Soils, Natural Risk Zones, Mineral resources, and Energy resources