Dear Lucie,

The first part is correct, the observedEvent represents an extraction of landslide layer (normally manage as Geomorphologic layer within Geology Data model) in a specific time windows. The HazardArea is something that you can derive in semi-automatic way (eENVplus project has provided an example between Italy and Slovenia http://showcase.eenvplus.eu/client/ep09.htm) or you can produce in your local machine an expose it as HazardArea layer (It is the case of LIFE-IMAGINE project http://www.life-imagine.eu/ - client: http://lifeimagine.graphitech-projects.com/; where we use the Hydrography district susceptibility map). In the same project we have also produced the Risk scenario map as RiskZone layer.

If a Geological Survey hasn’t produced an hazard map, this action is not mandatory. The potential add value of INSPIRE is to use the system to create one from the source data, following a specific predictive model.

Cheers,

Carlo

Thank you, Carlo.

Just to make it clear - if the hazardArea is not provided, neither riskZone can be calculated and provided, am I right?

Lucie.

Dear Lucie,

yes, you are right! But what I have also expressed is the potential use of INSPIRE NZ model to produce within a specific Hazard method in a semi-automatic way the HazardArea and then the RiskZone if you have Exposed and Vulnerability values.

Carlo

Just for information

A group of people from  TNO from the Netherlands, The Norwegian Petroleum Directorate,  BGS, The Department of Energy and Climate Change (also UK)  and  Common Data Access, CDA (also UK),  The Danish Energy Agency and the Geological Survey of Denmark and Greenland  is currently working on the common problems and challenges related to the data management of hydrocarbon exploration and production.

One of the things we are working with is an extension to the borehole purpose list.  We have not agreed on the terms and the definitions yet but the preliminary list with terms that we want to add look like this:

• Injection
• storage observation
• hydrocarbon storage
• scientific research
• salt production
• storage
• hydrocarbon development
• wildcat
• CO2 injection
• CO2 disposal
• shallow gas
• pilot

Dear Tim, and All,

The geophysical part of the recent UML model and the Guidance has not been updated since version 3.0. My comment only refers to the xsd schema. For geophysics extension version 3.0  xsd schema has not been generated by JRC. This is a serious obstacle in testing, but we can survive with pure O&M until it will be done.

Kind regards,

Laszlo Sores

Dear Laszlo,

We had a good Geology sub-cluster meeting at the INSPIRE conference on the Friday  with 5 Geological surveys represented reviewing the long overdue proposed changes to the Geology TG and today I have put up the final V6 here (https://themes.jrc.ec.europa.eu/file/view/158925/final-v6-version-of-inspire-geology-tg-to-go-to-mig-t-at-end-october-2017-for-approval  and deleted the previous v4 version).

This version includes all the 2008 to 2012 Geochronologic Era older and younger boundary changes that got overlooked when the decision to evolve to use (and specify as a legal requirement in the IR) ICS 2012 values as the first TG version was being written. Kristine and Chris owe me a lot of beer for actually getting round to doing this laborious job (but they have already given that to me I believe in my last visits to Hannover and Vienna!) and I hope that I have gotten it right - it is certainly 99.9% better than has been published - but it will need to be copied across to the INSPIRE registry when the 2 new URI codes and 1 typographic URI correction requests are made live in the registry (Carlo and Chris are both on the registry management board so I am sure they will ensure this is done appropriately). However with the tracked changes in this document it is easy to see the corrected year values.

It is Carlo's MIG-T role now to propose these (non-IR changing) changes to the MIG-T on 30th October but apparently we do have until the 15th to make any final changes to this v6 document. So I did just want to check with you Laszlo that you did not want to adjust the wording regarding the geophysics schema as you said on this cluster "it must be noted that the extension schema for geophysics is outdated and should be ignored" and in practice this is probably the only chance to refine from experience the actual wording of the Geology TG up to the 2020 implementation deadline. If the schema is not useable and nobody is going to fix it perhaps delete reference to it and there emphasise recommendation to use O and M (which is actually referred to earlier in the document for geophysics?).

Kind regards,

Tim, currently Geology sub-cluster facilitator

Dear Tim,

Do you think it is impossible to make JRC to finally create the proper xsd schema for the current version of geophysics extension? At the moment there is nothing to be added to the document, because both the wording and the published UML models are correct.

Best regards,

Laszlo

A new paper about the usefulness and application of the Data Specification to the domain has been published, via Open Access:

Robert Tomas, Matthew Harrison, José I. Barredo, Florian Thomas, Miguel Llorente Isidro, Manuela Pfeiffer, Otakar Čerba. Towards a cross-domain interoperable framework for natural hazards and disaster risk reduction information. Natural Hazards. 2015 DOI 10.1007/s11069-015-1786-7

We have the same problem with our deposits of sand and gravel. The sizes of the occurrences and amount of produced material are all reported in cubic meters. Up till now I have used a density of 1.7 tons/cubic meters for all sand and gravel deposits. It is not based on any elaborate deduction or statistics but on product lists from sand and gravel producers. 1.7 should be the density of natural sand and gravel and is quite high compared to other sand and gravel products that have a density down to 1.4.  When I think about it, I should have chosen a lower density because it would be safer to underestimate the size of the deposit rather than to overestimate the size.

Hi!

We discuss this issue at GTK yesterday and we have the same situation and plan to do this same kind of calculation from cubic metres to tons/density like 1.7tons!

The suggestion seems reasonable, a change of the data specification would be helpful.

Following the discussion above this proposed change to the data specification has been added to the MIG-T corrigenda for approval or otherwise in December 2015,

https://ies-svn.jrc.ec.europa.eu/issues/2209

If you have any comments to add before this is put forward please add them here before the 20^th of October.

Dear all,

The change of the ‘association soilDerivedObjectObservation between SoilDerivedObject and OM_Observation from 1 to 0..*’ within the Soil UML diagram (figure 11 in the Soil Data Specifications) was discussed at the recent thematic cluster facilitators meeting in Rome and will be put forward for approval to the MIG-T shortly.

(Please note the original request was to change the association from 1 to 0..*, however following further discussion it was agreed that the request should to change 1 to 1..* to ensure that if you provide a (or several) SoilDerivedObject(s), then a value is attached to it.)

So it is proposed that we put forward the following change to the MIG-T,

To change the association soilDerivedObjectObservation between SoilDerivedObject and OM_Observation from 1 to 1..*

This change would allow multiple observations on a soilDerivedObject

We don’t believe this change would have an impact on current implementations of the data model as current implementations will still be valid. However, we are looking for feedback from the community to confirm this prior to submission of this change to the MIG-T.

Please can you post your comments here as to whether this change would or would not affect your implementation of the soil data specification?

Thank you.