MINDeSEA WP3 GeoPackage Data Delivery about project-support-wp8 HOT 14 CLOSED

In the MineralOccurrence table, is the intention to use EarthResourceML-Lite attribute names and codelists? If so column names aren't correct.

Instead of type we should have mineralOccurrenceType

I think too that as well as the label like occurrence from code list https://inspire.ec.europa.eu/codelist/MineralOccurrenceTypeValue you should also have the URI form. Like mineralOccurrenceType_uri and value https://inspire.ec.europa.eu/codelist/MineralOccurrenceTypeValue/occurrence

from project-support-wp8.

Hi nmtoken,

Thanks for the feedback. It has encouraged to review the INSPIRE model again meaning I have added a new table MiningFeature to capture inspireId identifiers.

1. The intention is not to use EarthResourceML-Lite with the MineralOccurence table.
2. I am simply using the following INSPIRE featureType tables: MineralOccurrence, Mine, MiningActivity, MiningFeature and MineralDepositModel
3. EarthResource featureType in Mineral Resource has voidable attributes meaning we dont have to include them and as we dont have relevant data from MINDeSEA it is therefore not included.
4. type is not called mineralOccurrenceType according to the UML in the INSPIRE data specification.
5. All URI associated with vocabularies are captured in the vocabularies table which are linked as Relationships in the GeoPackage.

I plan to submit an updated version with the MiningFeature table included in due course.

Kind regards,

Trevor

from project-support-wp8.

@mh-geus-dk @CipoCar

Does this suggested data structure look like it can be harvested into the INSPIRE minerals database to create the harmonized data outputs required.

@talcorn1976

Do you have an updated version you can share yet

from project-support-wp8.

Hi James,

I can send you a GeoPackage created in ArcGIS with the list of tables and 1 geometry feature table. We have been working on creating the relationships and constraints in the GeoPackage using SQLite but there yet.

I am happy to send the version of the GeoPackage without the relationships if this works?

In terms of fitting INSPIRE data specification the design of the tables and attributes follows the INSPIRE Data Specification on Mineral resources if that is what the INSPIRE minerals database is.

Kind regards,

Trevor

from project-support-wp8.

Hi Trevor,

So, the INSPIRE minerals database is intended as a reference to the the database that exists as part of EGDI infrastructure to hold the minerals data that is/was harvested from the complex feature ERML WFS services, set up to provide INSPIRE minerals data during the the Minerals4EU and EURARE projects from individual organizations, and which in turn is used as the basis of services to provide pan-European minerals data to the EGDI portal (harmonized WMS, simple and complex feature WFS) using ERML/ERML-Lite.

It is our understanding that minerals data like your own will be ingested into this database, or a database with the same structure of this database to allow similar services to be configured for the EGDI portal and wider consumption. The open question is mainly to the EGDI system administrators, to test your data as fit for purpose.

James

from project-support-wp8.

Hi James,

I am attaching the GeoPackage and a QGIS Project for MINDeSEA WP3 for share and review.

I would like to create the Relationships within the GeoPackage itself but cant using ArcGIS where I created the GeoPackage. As an alternative I have created the Relationships in the Project Properties of the QGIS Project. A colleague is looking into SQLite Relationship queries for me but is on leave until the end of July.

Alternatives for working with GeoPackage format welcome as I am new to the standard.

SeafloorMassiveSulphideDeposits.zip

from project-support-wp8.

@mh-geus-dk Please can you check whether you can upload the file in the SeafloorMassiveSulphideDeposits.zip file attached to the above comment

from project-support-wp8.

I have now been looking at the GeoPackage and see all the information’s. It is however not clear to me how MINDeSEA want their data shown on the portal. The data bearing tables could have been stored in one table containing all of the fields. I’m not sure on the intension of this split of data. Also it is not clear what the purpose of the table “vocabularies” is. The table contains a series of code list and it is not clear how you want to use them. The URI sometimes refer to a viewable page where the user can read about code, in other cases some XML or JSON. If these data are included in the Minerals4EU database there is no need to deliver the data once more. The layers can be defined based on those data.
I think it would be a good idea if WP6 and WP8 together makes a HowTo describing how to set up data in the GeoPackages in a way that show how the project want their data displayed – the colour of the data points and which field to use for the thematisation and so on. This is needed in order to have user-friendly upload data and registration of layers.

from project-support-wp8.

Hi Martin,

I am organizing a meeting this week and will get back to you on the recommended requirements you suggest.

Kind regards,

Trevor

from project-support-wp8.

@talcorn1976 @mh-geus-dk Have you discussed further whether the data fits in the Minerals4EU database structure and can use the standard route for that data or whether there are different requirements for this data and, if so, how Trevor wants it to be shown in the EGDI Portal?

from project-support-wp8.

Assumption for portrayal would be to use INSPIRE recommended styles

from project-support-wp8.

@talcorn1976 @mh-geus-dk Any update on this issue, can it be closed?

from project-support-wp8.

Nothing new from me. /Martin

from project-support-wp8.

Closing after confirmation by email.

from project-support-wp8.