"Seegrid will be due for a migration to confluence on the 1st of August. Any update on or after the 1st of August will NOT be migrated"

Issues and requests

Results of meeting at BGS/Keyworth 28 May 2003

  1. generalise "event" model so that it can be re-used for other events in the lifetime of a feature, as well as the database record Now Event and RecordEvent in XmmlCVS:XMML/base.xsd -- SimonCox - 24 Jul 2003
  2. generalise Project to accomodate purposes other than mineral exploration (must include "instigator", and a "purpose") See discussion below -- SimonCox - 24 Jul 2003
  3. generalise Tenement to accomodate authorisation regimes (licensing) other than mineral exploration

-- SimonCox - 29 May 2003

Project

The Association of Geotechnical and Geoenvironmental Specialists (AGS) data exchange format (for site investigation reports), always require project infomation.

Information that may be specified is

  • Project identifier (1..1) (PROJ_ID)
  • Project title (0..1) (PROJ_NAME)
  • Site location (0..1) (PROJ_LOC)
  • Client name (0..1) (PROJ_CLNT)
  • Contractors name (0..1) (PROJ_CONT)
  • Project engineer (0..1) (PROJ_ENG)
  • General project comments (0..1) (PROJ_MEMO)
  • Date of production of data (0..1) (PROJ_DATE)
  • Monitoring Contractor identifier (0..1) (PROJ_CID)
  • AGS (format) edition number (0..1) (PROJ_AGS)
  • Associated file reference (0..1) (FILE_FSET)

I have created a test dump from the BGS database as below. Does this look correct?

In my version of commonFeatures.xsd I have xmml:Event with elements what / when / who ~ I have assumed these should be xmml:what / xmml:when / xmml:who. Similarly purpose should be xmml:purpose?

-- JamesPassmore - 23 Jul 2003

There is already a skeleton "xmml:Project" feature defined in the XmmlCVS:XMML/commonFeatures.xsd schema. Since this is in the Feature substitution group, a Project can be the content of a "relatedFeature" property which is available on all xmml Feature types.

There are also property elements "parentProject", "projectDetails" and "relatedProject". In the examples these are currently only used in the ReportingMetaData appearing in the statutory reporting templates (e.g. XmmlCVS:Examples/geochem/surfaceGeochem_sg2_1.xml ).

I suggest that the xmml:Project be fleshed out and used when appropriate.

-- SimonCox - 24 Jul 2003

I'm confused, I have attempted to use the xmml:Project feature in my AGS Project/Hole data dump. I put client into xmml:Project/gml:metaDataProperty/gml:GenericMetaData/ags:PROJ_CLNT so by rights it is attached to the project isn't it?

I agree that it should really be a property of project such as: xmml:Project/xmml:Client or xmml:Project/xmml:Sponsor

I think a question arises as to when we should use the xmml:Project/gml:metaDataProperty/gml:GenericMetaData/..., when we should append properties to xmml:Project/..., or when we should just substitute our own project for xmml:Project

-- JamesPassmore - 31 Jul 2003

Borehole

WellLogML from POSC is also interesting, though mostly targetted at data recorded by automated continuous logging tools, rather than core logs.

-- SimonCox - 8 May 2003

Should also ensure that we look at Log Ascii Standard (LAS) from Canadian Well Logging Society.

-- SimonCox - 09 Mar 2004

I believe the Log Ascii Standard (LAS) is supplied by most borehole logging contractors to their clients (in Australia at least). Tools to import to and export from LAS format would be very useful.

-- StephenGarner - 12 May 2004

--+++ Ongoing work from BGS

  1. Clarify schema by converting some optional elements (e.g. xmml:length) to mandatory, but add Null choice?
  2. BGS drillcode vocabulary?

An example of data taken from the BGS "Single Onshore Borehole Index" database converted to xmml:Borehole features is at XmmlCVS:Examples/boreholes/bgs_sobi_1.xml . This database is a national index of all boreholes over a certain depth in the country and so the quantity and quality of the data is variable. The structure is simple but it still provides a good test of some aspects of the borehole.xsd Schema. Doing this conversion is partially a GML/XMML learning exercise for us.

An example of borehole data also including some related geological logging from our "Borehole Geology" database converted to an xmml:Borehole feature with logs is at XmmlCVS:Examples/boreholes/bgs_bh_geol_1.xml .

Some issues that ocurred to me while creating these instances are:
  • Where to put location method and precision quality information?
  • Not clear what the correct place for the START_POINT_TYPE information is.
  • For drilling method using BGS dictionary rather than XMML Schema LUT can just add other:w(2,) values or should I override LUT Schema with a local one including definitions? Choice between codeSpace codes, and Schema LUTs has been made differently at different parts of XMML Schema; should there be a general pattern to allow all methods in all cases?
  • Does INSTIGATOR need a hard-typed property like the drilling operator or is a comment good enough?
  • In log range lists, the token lists should cope with descriptive log values with (single) spaces in the values that are separated by tabs or newlines but I'm not absolutely confident in how error-prone whitespace processing may be.
  • URI attributes add a lot of bulk and are generally repetitive.
  • I've included the BASE_BED classifier as an interval log at the moment but probably should be a point log.

-- MarcusSen - 28 Apr 2004

AGS HOLE

The Association of Geotechnical and Geoenvironmental Specialists (AGS) data exchange format (for site investigation reports), always requires a data file to include HOLE information. HOLE is an acronym for 'Hole Or Location Equivalent'. A 'HOLE' may be borehole, but may also be an inspection pit, observation pit, trial pit/trench, linear logging traverse, or logged exposure. Should we try to fit this data into xmml:BoreHole? or is it catered for elsewhere in xmml?

-- JamesPassmore - 24 Jul 2003

Re-reading this, it appears that the AGS HOLE feature is akin to an "Observation station".

In the observation model, any Feature (such as a station, a sample, a mountain, even a borehole) may be the "subject" or "target".

Alternatively, xmml:Borehole is a specialised feature which packages the borehole description with the observations made about it. It would be straightforward to design other similar features for pits, trenches and traverses, etc.

The case behind one approach or another is basically demand. Boreholes are a sufficiently commonly encountered feature that it is worthwhile creating an object which packages the information in this way. xmml:Observation is a more generic idea - it binds any feature to observation(s) made on it.

Note that, as currently formulated in XMML, the result of an observation may be a scalar, a geometry, time, tuple, numeric tuple, or an exception. The assumption is that (each component) of the result applies uniformly to the subject, "piecewise constant" if you like. In principle it would be possible for the "result" to also be an array, list or table, representing a property that varies across the subject, as long as we provide a rule for how to associate each component with sub-elements of the target or subject. But this latter case (properties which vary across the target object) is handled explicitly by the coverage model.

-- SimonCox - 25 Aug 2003

BRGM requirements

I've written a XMML boreholes parser working on vertical boreholes. It works on your example files and on my own files. I have not written yet the code to analyze deviated boreholes. In order to use XMML boreholes with GDM components, my XMML parser checks :
  • The srsname is the same one everywhere.
  • When the length is defined, the unit of the length must be the same one everywhere.
  • There must be the same number of category lists in each borehole.
The category lists must appear in the same order and with the same property value and the same codespace value.
  • There must be the same number of measure lists in each borehole.
The measure lists must appear in the same order and with the same property value and the same uom value.
  • When the length of the borehole is defined, it is compared to the envelope of the borehole and to the to depth of the last run.
  • The envelope of the borehole is compared to the to depth of the last
run.

With my XMML parser, it will be easy to write an interface with the GDM components.

To go on my job, I want to create a XMML boreholes server on our public boreholes database in order to connect the GDM components to XMML boreholes. Our public boreholes are stored in an Oracle database. Our boreholes database looks like a collection of boreholes and a collection of runs for each borehole. All elements (codes, measures) of a run are stored in only one record also containing the from and the to depths. I think it will be the same in many boreholes databases. As XMML uses the coverage model (domain and range) to design boreholes, geometry is separated from category lists and measure lists in the XML document. It is not so easy to map on the fly our Entity/Relation model and XMML borehole model (as a WFS does when it sends GML to the client). A solution could be to duplicate the Oracle boreholes in a new Oracle table containing the XMML boreholes, but of course it is not a good solution.

Is a WFS server able to deliver such XMML data (because you use the coverage model)?

Using this coverage model how can we query the runs through the WFS? (ex: get all boreholes in Orleans city crossing the limestone layer).

-- ChristianBellier - 23 Feb 2004

I guess the problem arises if you can only retrieve data "by row" from your tables. The XMML model uses the "coverage" model to represent logs, which is essentially equivalent to a "by column" representation where the properties are given sequentially rather than interleaved. This leads to coding efficiencies in XML, which is a serialised form and thus cannot represent "tables" naturally See the discussion of InformationViews.

-- SimonCox - 09 Mar 2004

I have some more questions about 1D coverages used in XMML boreholes: - I'm working on a program that will be able to connect OGC points servers. If I use the DescribeFeatureType Web service, I get a XML schema describing all the elements of one feature. My program will parse this result in order to propose the selection of one element in a dialog box. In this case, elements come from an Oracle table. - The second step in this program will be to connect XMML boreholes servers. My program will propose a dialog box in order to select one code element coming from our Oracle boreholes database used as a XMML boreholes server. It's the reason why my program assumes that the category lists are the same and in the same order in every feature member (ie every borehole). In this case, what will the result of DescribeFeatureType Web service be ? How can I get the name of all category lists and all measure lists of XMML boreholes accessed by a XMML boreholes server ? From a general point of view, what do you think about the constraint "the category lists must be the same and in the same order in every feature member" and the same one for measure lists ?

-- ChristianBellier - 05 Mar 2004

This is the dilemma of soft-typing (in the instance) vs. hard-typing (in the schema). You get maximum flexibility and minimum design overhead by using soft-typing, but it does put a greater burden on the processing software, which must retrieve an instance before it can fully describe what's there. OTOH hard typing moves all the structure into the schema, but typically at a cost of having to have a different schema for each borehole, since there will be different observations made in every borehole. However, if your application is highly standardised, then we could define a hard-typed schema for BRGM, by specialising (restricting) the XMML borehole schema.

-- SimonCox - 09 Mar 2004
Topic attachments
I Attachment Action Size Date Who Comment
ags_proj_hole_data_dump.xmlxml ags_proj_hole_data_dump.xml manage 20.9 K 24 Jul 2003 - 00:07 JamesPassmore AGS Project/Hole data dump
Topic revision: r5 - 15 Oct 2010, UnknownUser
 

Current license: All material on this collaboration platform is licensed under a Creative Commons Attribution 3.0 Australia Licence (CC BY 3.0).