"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"

Boreholes, Sampling & Observations

Back to GeoSciMLModel
Discuss this page at BoreHolesAndObservationDiscussion
Also see GeoSciML2Discussion, ObservationsAndSampling

Scope Notes

GeoSciML ver2.0 Model (Release Version)

Modifications made to Boreholes prior to release in December 2008.

  • Relationship between Boreholes and Observations, version 2.0, August 2008:

-- BruceSimons - 2010-02-01

GeoSciML ver2.0 Model (Release Candidate)

  • Relationship between Boreholes and Observations, version 2.0, October 2007:

Supporting specifications

The Observations and Measurements, and Sampling Features specifications are summarized at ObservationsAndSampling.

These are relevant to the borehole encoding issue since:
  • Borehole or ObservationWell may be defined as a specialization of SamplingCurve, which carries an arbitrary set of relatedObservation associations whose results may be logs
  • note also that Section, Map, Flitch etc may be defined as specializations of SamplingSurface
  • the results of observations on these features can be expressed either using the gml:Coverage (domain-range) or the cv:CV_DiscreteCoverage encoding. The latter is perhaps more flexible and more familiar.
Else for interval-logs you can just treat these as a set of MappedFeature instances with their samplingFrame being this SamplingCurve (see GeologicFeature).

Note that these aspects of the models provide data structures but do not address the issue of standardising the next level in - i.e. controlled vocabularies, etc, that are required for the values of the fields within the data structures.

-- SimonCox - 11 Jun 2007


GeoScience Victoria (GSV) example:


This is based on TestBed 3 examples (https://www.seegrid.csiro.au/subversion/GeoSciML/instances/TB3.1_UC3D_BRGM_Boreholes_O&M.xml) with some additional changes commented on below.

-- BruceSimons - 2010-02-04

See https://www.seegrid.csiro.au/subversion/GeoSciML/instances/Borehole1_samplingCurveWithObservations.xml for an example of a borehole with three logs, encoded using sa:SamplingCurve.

Compare this with https://www.seegrid.csiro.au/subversion/GeoSciML/instances/borehole1_mappedFeatureCollection.xml which shows (a sketch of) the lithology log encoded as a collection of gsml:MappedFeature elements - note that in this case the elements have to be classified as lithostratigraphic units, since a mapped feature cannot be a pure lithology (material).

-- SimonCox - 06 Jun 2007

Boreholes BRGM examples available in the instances directory: All the BRGM examples use the same coordinate projection system EPSG:7412 which corresponds to the French Lambert projection (EPSG:27582) taking into account the elevation expressed in meters. As the median curve of the borehole is a 3D curve, the envelope, when it is defined, must be a 3D envelope.
  • BRGMVerticalBorehole.xml: this is a simple example without any observation and measurement. As the borehole is vertical, we only need the begin point and the end point to encode the geometry of the 3D median curve of the borehole. When the borehole length is encoded, it must be equal to the difference of elevations between the begin point and the end point.
  • BRGMStraightBorehole.xml: this is a simple example without any observation and measurement. As the borehole is straight, we only need the begin point and the end point to encode the geometry of the 3D median curve of the borehole. When the borehole length is encoded, it must be equal to the distance from the begin point to the end point.
  • BRGMDeviatedBorehole.xml: this is an example of a deviated borehole. In this example, the borehole is described by geology and grades which are encoded as coverages of intervals using basic gml types. The median curve of the borehole is encoded as a line string composed of all points used in the 3 coverages. The points must be sorted according to the increasing depth (curvilinear distance along the borehole). In this example, the coordinates have been calculated by the BRGM GDM (Geological Data Management) application. With another calculation algorithm, we can obtain some slight differences on the coordinate values. The values of direction and inclination used in this calculation have been encoded as 2 coverages of points. Encoding the coverages according to the increasing depth may improve the performance of parsers parsing borehole data. As the direction values have been measured at the same depths as the inclination values, these points are not redefined in the inclination coverage : it's the reason why links to the points of the direction coverage were used in the inclination coverage. In this example, the collar location has been defined although it is optional. As the collar of the borehole is also the first point of the borehole, the first point of the borehole has been defined as a point property in the line string defining the geometry of the borehole in order to reuse this point by a link in the collar location.
  • BRGMDeviatedBoreholeCGI.xml: it is the same example as BRGMDeviatedBorehole with all observations and all measurements encoded with the CGI classes from GeoSciML.
  • BRGMDeviatedBoreholeSwe.xml: it is the same example as DeviatedBorehole with all the direction and inclination values encoded as one swe (SensorWebML) array and all the geology and grade values encoded as another swe array.
  • BRGMBoreholeExample1: it is an example of a BRGM borehole from the national database of boreholes. It is a vertical borehole with lithology, lithostratigraphy and age information encoded as gml codes.
  • BRGMBoreholeExample1GeologicalUnits: it is the same borehole as BRGMBoreholeExample1 with lithology, lithostratigraphy and age information encoded as GeoSciML lithologic units and lithostratigraphic units. These units are encoded in each interval.
  • BRGMBoreholeExample1GeologicalUnits_Links: it is the same example as BRGMBoreholeExample1GeologicalUnits but geologic units are encoded in separate members. The controlled concepts are also encoded in seperate members. It's the reason why this example is encoded as a collection of GeoSciML members, one for the borehole, others for the geologic units and the last ones for the dictionaries.
  • BRGMBoreholeExample1MappedFeatureCollection_Links: it is the same borehole as BRGMBoreholeExample1_Links with the borehole encoded as a collection of mapped features, one for the 3D curve of the borehole and one per interval and observation.
  • BRGMBoreholeExample2: it is a simple example of a well with gamma ray and sound information encoded as coverages of points. This example uses the indexData element describing general data about the borehole (operator, driller, date of drilling, drilling method, start point, nominal diameter and inclination type).
-- ChristianBellier - 30 July 2007 -- ChristianBellier - 05 December 2007

BoreHoles And Observation Discussion

Some comments:
  • We can define rules to encode boreholes. For instance, we can define rules to encode the gml:ids.
  • We must check that properties like grade, direction, inclination (list to define) are defined in a general dictionary.
  • Encoding the coverages according to the increasing depth may improve the performance of parsers parsing borehole data.
My point of view about the comparison between methods:
  • Using CGI classes for encoding values is not very different from using gml basic classes.
  • With swe classes for encoding values, we get a small file with few lines by comparison with the other methods. A drawback of this method is that the geometry of the points or intervals associated with observations and measurements is not linked to the geometry of the line string of the borehole. That may be a problem for a parser to parse the geometry of points and intervals.
  • A drawback of the mapped feature collection method is that we cannot have numerical values associated with intervals.
  • It is possible to describe the geology by geological units with the mapped feature collection and the coverage method (not with the swe method).
  • The swe method is an easy way to link a borehole database to a WFS of boreholes but this method has some drawbacks.
Some questions to debate:
  • In the case of a straight borehole, there is no element to encode the direction and the inclination of the borehole. We can assume that the borehole is deviated on only one interval and process this problem the same way as a deviated borehole?
  • In case of a deviated borehole, a good way to define the geometry would be an element for the begin point and a projection system working with curvilinear distance, direction and inclination. In this case, the 3D line string would be optional and the applications consuming this data could compute the coordinates of the line string points if they need the coordinates. In such a case, must the interoperability work on the 3D line string or on the begin point with the set of curvilinear distance, direction and inclination tuples?
  • In case of deviated boreholes and straight boreholes, as we work with angles, we must specify the convention defining the angles.
  • In case of coverages, it’s not possible to encode more than one observation or measurement. In such a case, we must encode several coverages with the same geometry. Is it possible to have coverages with more than one value element in order to not duplicate the geometry? (With more than one observation or measurement in a coverage, it would be easier to link a borehole database to a WFS of boreholes)
  • In case of intervals, the schema does not check that the first pos value (from depth) is less than the second pos value (to depth). It may be done by a parser.
  • In a coverage, we can mix points and intervals. It may be a problem for parsers and for applications.
  • In a coverage, we can mix code values and measurement values. I think that a coverage must always refer the same type of data. This problem may be solved by a parser.
  • In a coverage of numerical values, we can use different units. For instance, we can use meter and g/t in the same coverage: this case is a non sense. But in the same coverage, we can use meter and kilometre in the same coverage. The parser must check the homogeneity of the units and may deliver the values according to a chosen unit (meter or kilometre).
  • There is something missing in the schema. We cannot encode well trajectories.
  • Is the envelope of boreholes 2D or 3D? I guess that the answer is 3D. All the BRGM examples were encoded with a 3D envelope.
  • Must we define a subset of types used in the coverages? I think yes to implement parsers.
  • Must we support the two methods? (coverage and feature collection) If yes, that means that we will have to implement two parsers completely different.
  • In boreholes, do we always know the sampled feature (intention), the feature of interest, …?
-- ChristianBellier - 30 July 2007 -- ChristianBellier - 05 December 2007

Best practice

A borehole is a feature whose median axis is a curve. Related observations and measurements are made on points or intervals, at depths measured from the collar along the borehole curve. Observations may concern, for example, lithology, stratigraphy (category results), porosity, geophysical logs data, and ore-grades (numerical results). In case of holes with non-constant diameter, the variation of the diameter may also be described as a log.

The shape of the boreholes (median axis of the borehole) is a 3D curve, which in the simplest cases may be vertical and straight, but is commonly deviated, and often not straight. The axis-shape may be described by means of another log known as the “survey” (3-D direction as a function of depth) which may be converted (“de-surveyed”) to obtain the shape in an x-y-z reference frame.

A borehole is associated with one or more associated domain features which it samples: for instance, the geological unit (a geological feature from GeoSciML) intersected by the borehole. A borehole may also be associated with related sampling features. This allows a set of boreholes to be grouped as a campaign, or specimens to be associated with boreholes, boreholes with mines, etc.

While boreholes may carry various kinds of observation, in a geological mapping context, lithology logs are a key information type. There are two ways to describe these:
  1. A borehole is a special sampling curve feature, and the lithology log is reported as the result of a related observation – i.e. borehole-centric, in which the association points from the sampling frame to the observed units. This point of view is natural when comparing multiple logs of different properties.
  2. The lithology log is a collection of mapped features (i.e. occurrences of geologic units) whose sampling frame is a sampling curve describing the borehole – i.e. classification-centric, in which the association points from the observed lithology to its sampling frame. This point of view is natural when comparing a borehole log with other representations of the same property, perhaps sampled in a different frame (e.g. map or section).

When to use which approach?

  1. The first approach (borehole feature) is important during observation/data-collection and for re-examination through the lens of an observational campaign.
  2. The second approach (collection of mapped features) is important after interpretation, and is used later on during compilation.
With the second approach, it is highly convoluted to also include measurements of continuously varying properties, such as ore-grades, porosity, etc. Hence, the first approach is recommended when it is required to compare geologic features (e.g. units) and ore-grade within a hole. However, the second approach is more convenient to compare a geological interpretation from a borehole with a 2-D or 3-D model described as a set of mapped features (i.e. a geologic map).

Rather than combining these into one service it is recommended to keep them as two separate views of the data:

SimonCox wrote (4/2/2010):

"... its a standard pattern to build complex things from simple components. The Observation standard is so simple and pared back on the assumption that people will add value with services on top of it that aggregate stuff. A service that takes a set of logs of the same borehole and combines them into a complex multi-component dataset is fine. But don't do it too soon (and in particular don't push it into the information model too soon) else you lose the ability to do other kinds of combos. There could be another model on top of the primitive one to do this. "

Encoding borehole logs

When the borehole feature approach is used, the log is embedded as the result of an observation. The Observation/observedProperty may be lithology or lithostratigraphy or geologic feature identity or age or any grade or gamma ray or porosity or …. The Observation/procedure should identify the geologist and/or logging technology. The type of a generic Observation/result is "Any", which in this case is a "Discrete Point Coverage" or "Discrete Curve Coverage" or "Segmented Curve Coverage". The value for each point or interval is the "value" in the corresponding GeometryValuePair.

Comment (-- BruceSimons - 2010-02-01)

In TestBed 3 these were done as a series of cv:CV_DiscreteCoverage/cv:elements in the om:Observation/om:result with cv:value an xlink:href eg:

                        <!-- As the geometry of this interval has been previsouly defined, we refer to it -->
                     <!-- Age value according to the stratigraphic chart dictionnary -->

An alternative is to have each result describe the gsml:material result for each interval, which allows a full description of gsmlRockMaterial rather than a simple href to a lithology value.

               <cv:domainExtent xlink:href="#bh.352865.Shape"/>
               <cv:rangeType xlink:href="urn:ogc:def:nil:OGC:unknown"/>
                              <gml:LineString srsName="#bh.352865.shape" srsDimension="1">
                                 <!-- An identifier is not defined for the geometry of the interval as the interval geometry is not repeated for any other observations on this interval (none in GSV data - each set of observations has its own set of intervals) -->
                        <gsml:RockMaterial gml:id="bh.352865.lithology.1.1">
                           <gml:description>SURFACE CLAY</gml:description>
                                 <gsml:value codeSpace="urn:cgi:classifier:CGI:ConsolidationDegree:2008:unconsolidated">Unconsolidated</gsml:value>
                           <gsml:lithology xlink:href="urn:cgi:classifier:CGI:SimpleLithology:2008:clay"/>
                           <!-- A lithology mapping to CGI will be required as GSV's GEDIS Boreholes doesn't use the GUS standards -->

Is having a single Observed Property result (gsml:material) which is a complex data type (gsml:CompoundMaterial) counter to the intention of O&M?

-- BruceSimons - 2010-02-02


In the XML encoding, (Discrete Coverage version - see OGC 06-122r1 and XML Schema) the element geometry is normally implemented as follows:
  • If the observations are made on intervals, then each cv:geometry/cv:CV_DomainObject/cv:spatialElement in the log should contain a gml:LineString
  • If the observations are made at points, then each cv:geometry/cv:CV_DomainObject/cv:spatialElement in the log should contain a gml:Point
  • All positions should be expressed as an offset within the borehole, i.e. as a 1-D coordinate in the coordinate reference system defined by the borehole shape, whose origin is at the borehole collar
If the same sampling intervals or points are to be re-used for more than one log, then it is helpful to assign a value for the @gml:id attribute on each geometry element.

Comment: (-- BruceSimons - 2010-02-01)

As GSV data has a separate From-To depth recorded for every observation down a borehole it is more practical (for GSV) to deliver each of these as separate LineStrings associated with each Observation/GeologicUnit rather than deliver once and href.

Property value

The element value is also an "Any". The type should be indicated using the standard xsi:type attribute. The following forms are recommended::
  • If the assigned value is a reference to an identifiable resource, then use a link provided by gml:ReferenceType, for example:
    • A reference to a ControlledConcept should use the concept identifier assigned in the CGI Identifier Scheme - e.g.
<cv:value xsi:type="gml:ReferenceType" xlink:href="urn:cgi:classifier:CGI:lithology:sandstone"/>

    • A reference to a GeologicFeature (unit, structure, etc) should use the identifier assigned by the agency that described the feature - e.g.
<cv:value xsi:type="gml:ReferenceType" xlink:href="urn:cgi:feature:USGS:4fd7c961"/>
<cv:value xsi:type="gml:ReferenceType" xlink:href="urn:uuid:71d12820-821e-11dc-8314-0800200c9a66"/>

  • If the assigned value is a literal from an identifiable vocabulary, then use gml:CodeType, e.g.
<cv:value xsi:type="gml:CodeType" codeSpace="urn:cgi:classifierScheme:BRGM:lithology">grés</cv:value>
<cv:value xsi:type="gml:CodeType" codeSpace="http://www.somacon.com/p142.php">antiquewhite4</cv:value>

  • If the assigned value is an arbitrary literal, then use xs:string, e.g.
<cv:value xsi:type="xs:string">very very old and crumbly</cv:value>

  • If the assigned value is a scaled number, then use gml:MeasureType, e.g.
<cv:value xsi:type="gml:MeasureType" uom="kg/m3">2560.</cv:value>

  • If the assigned value is a presence/absence indicator, then use xs:boolean, e.g.
<cv:value xsi:type="xs:boolean">false</cv:value>

  • If the assigned value is a qualified term or scaled number or range, then use the appropriate gsml:CGI_Value type, e.g.
<cv:value xsi:type="gsml:CGI_TermValuePropertyType">
    <gsml:CGI_TermValue> ... </gsml:CGI_TermValue>

  • If the assigned value is a structured description, then use a suitable type and sub-elements
Note that in the last two cases, since the value is expressed using namespace-qualified sub-elements, there is no requirement to include the xsi:type attribute in order to indicate the type of the content. However, it is recommended to include it to assist client applications, and for consistency.

Multiple properties

If multiple properties are observed on the same intervals or locations, there are thyree possible approaches:
  1. use a single log, in which the "value" part of the geometry-value pair holds a "tuple" composed of the various components. This is a good approach if many boreholes have exactly the same set of properties logged, so the tuple definition is part of a standard "data product specification" that can be published somewhere.
  2. use a separate log per property, but in the "geometry" part of the geometry-value pair, use a xlink:href to a geometry element that has already been used elsewhere (e.g. on the first log of the suite). This is a good approach where each property is usually analysed separately, and the correlations with other logs are of secondary interest.
  3. use a separate log per geometry and repeat the "geometry" part of the geometry-value pair (-- BruceSimons - 2010-02-01)

Encoding a geology log as a collection of mapped features

If the mapped feature approach is used, a borehole is encoded as a series of GeoSciML MappedFeature instances, each with a link to the GeologicFeature (unit, structure, etc) that is its specification. The 3D sampling curve corresponding to the shape of the borehole samplingFrame must be available, and the shape of each MappedFeature must be contained within this.

With this approach, the log is implied by a collection of mapped features from GeoSciML.

Some other best practices

  • For a set of intervals in the same hole, ensure they are all oriented in the same direction (e.g. the "from" depth value must be less than or equal to the "to" depth).
  • intervals of a borehole should be sorted according to increasing depth.
  • If observations of the same property are made on mixed intervals and points, encode the points as intervals.
  • The points of a borehole must be sorted to increasing depth.
  • The borehole length, when it is defined, must be greater than or equal to the maximum depth of intervals and points of the borehole.
  • Use the same scale (uom, codeSpace) for all values of the same property.
Main.SimonCox doesn't understand the following group - can ChristianBellier please clarify.
  • To encode undefined numeric values, use the GML rule.
  • When the values of a measurement are encoded in a coverage with only the value of this measurement, there are 2 options to process undefined values:
    • Do not encode intervals or points with undefined values
    • Encode them
      The choice depends on the way the application that will consume this data, works.

When a measurement has undefined values and when the measurement is encoded as a coverage with only one value, there are two options to process the undefined values:
  • Ignore them. That means that only defined values will be encoded. In such a case, there is no constraint on the encoding of the measured values.
  • Encode them. In such a case, use the CGI_NumericValue type to be able to encode undefined values. With the CGI_NumericValue type, it is possible to qualify the undefined values as nil:inapplicable or nil:missing or nil:numsfeld or nil:unknown or nil:withheld.
The second option is the most common approach. With the second option, applications can count the number of defined values while it's not possible with the first option.

gml:Envelope vs gml:LineString

For sa:shape and gsml:shape we have used GM_Object, which allows the use of gml:LineString. For gsml:coredInterval we have used GM_Envelope which allows gml:Envelope. gml:LineString allows gml:id as well as srsName, whereas gml:Envelope doesn't allow gml:id. This precludes referring to the same geometries described in the Observations (see "Multiple Properties" discussion above).

More importantly it requires gml:lowerCorner and gml:upperCorner, rather than the two gml:pos values gml:LineString uses. This is inconsistent and wrong, the gsml:coredInterval should be treated the same as the Observation interval.

-- BruceSimons - 2010-02-01

sa:shape - gml:pos or gml:posList

The gml:LineString element on sa:shape can be either gml:pos or gml:posList. In previous testbed examples we have used gml:pos. I suggest 'best practise' be to use gml:posList. In this way more than just the start and end co-ordinates of the shape of the borehole can be delivered if desired.

-- BruceSimons - 2010-03-09 https://www.seegrid.csiro.au/subversion/GeoSciML/instances/

Linear Referencing (Borehole)

In principle these should be specified by a single coordinate giving the offset from a datum (e.g. the collar) in a 1-D coordinate system coinciding with the borehole axis.

However, many deployments are using GIS databases which only allow for 2-D coordinates.

The suggested workaround is to use 2-D coordinates, in a Lateral Offset Linear Coordinate Reference System. The second coordinate, corresponding to the lateral offset from the linear element, can be set to 0.0 so that the position coincides with the 'linear' element (actually a curve of course).

Linear referencing is part of the v3.3 upgrade to GML currently making its way through the OGC approval process. The work on this aspect was done by Paul Scarponcini of Bentley Systems - who have an interest in infrastructure, roads, communications, cables, etc and positions relative to these, as well as David Burggraf of Galdos - who have been working with the DIGGS community who are interested in boreholes. Examples instances can be found in the GML v3.3 draft which is available on the OGC portal here:


Pay particular attention to Section 9.5.10 where examples of the CRS definition and direct positions using this are given.

GML 3.3 is about to go to RFC and we would expect it to be approved by OGC later in the year.

Guidance provided by SimonCox 27 Jun 2011

For those without access to the OGC portal, an example of using a 3D CRS from section 9.3.20 of the above document follows:

This combination of a linear element and a Linear Referencing Method, identifiable by a gml:id, can be used as an SRS. For example:

<gml:Point gml:id="p1" srsName="#LSRS123">

defines a Point geometry as a distance along (15.5) the linear element encapsulated in LSRS123, measured in accordance with the Linear Referencing Method which is also encapsulated in LSRS123:

<gmllr:LinearSRS gml:id="LSRS123">
         <gml:LineString srsName="…" srsDimension="3" gml:id="LS_BH18">
         <gml:posList>407829 268621 23.93 407415 268600 8.43</gml:posList>
         <gmllr:LinearReferencingMethod gml:id="LRM001">
                    <!--chainage = measurement in metres -->
                    <!--absolute = measure from start of linear element -->
            <gmllr:units uom="m"/>

The example of using the Lateral Offset Linear CRS (from section 9.5.10 of the above document):

   <gml:Point gml:id="p2" srsName="#LSRS234">
      <gml:pos>25 30 5</gml:pos>

defines a Point geometry as a distance along (25), an offset lateral distance (30) and an offset vertical distance (5) from the linear element encapsulated in LSRS234, measured in accordance with the Linear Referencing Method which is also encapsulated in LSRS234:

<gmllro:LateralOffsetLinearSRS gml:id="LSRS234">
         <gmllr:LinearElement gml:id="LE005">
               <gml:LineString gml:id="LS001">
                  <gml:posList>407829 268621 23.93 
                   407415 268600 8.43</gml:posList>
               <gmllr:LinearReferencingMethod gml:id="LM001">
            <gmllr:measure uom="mile">100</gmllr:measure>
            <gmllr:startValue lrm="LRM001">0</gmllr:startValue>
         <gmllro:LRMWithOffset gml:id="LRM002">
            <!--chainage = measurement in metres -->
            <!--absolute = measure from start of linear element -->
            <!--positiveLateralOffsetDirection defaults to 
            "right" -->
            <!--positiveVerticalOffsetDirection defaults to "up" -->

-- Ollie Raymond - 29 Jun 2011

What part of the linear reference examples can the 2D GIS systems not deliver?

-- Ollie Raymond - 29 Jun 2011

The 2D GIS can’t deliver

<gml:posList>407829 268621 23.93 407415 268600 8.43</gml:posList>   <!-- The shape of the borehole -->
(it’s 3D)


(it’s 1D)

My recipe solves the second problem, but not the first.

Simon Cox - 29 Jun 2011

So when you deliver an offset linearly referenced point down a borehole from a 2D GIS dataset,

<gml:Point gml:id="p1" srsName="#MyBoreholeSRS ">
    <gml:pos>15.5 0</gml:pos>

do you have a separate database from which to source the “MyBoreholeSRS” information (which requires a 3D shape)?

<gmllro:LateralOffsetLinearSRS gml:id="MyBoreholeSRS">
        <gmllr:LinearElement gml:id="LE005">
                <gml:LineString gml:id="LS001" srsName="EPSG:999999" srsDimension="3">     <!-- The shape of the borehole provides the SRS of the point location -->
                    <gml:posList>407324 268786 223.93 407324 268786 123.93</gml:posList>
                <gmllr:LinearReferencingMethod gml:id="LM001">
            <gmllr:measure uom="metre">100.0</gmllr:measure>
            <gmllr:startValue lrm="LRM001">0.0</gmllr:startValue>
        <gmllro:LRMWithOffset gml:id="LRM002">

-- Ollie Raymond - 29 Jun 2011

Effectively that is the requirement, triggered if your basic system does not support non-2D.

Simon Cox - 29 Jun 2011

Topic attachments
I Attachment Action Size Date Who Comment
BoreHoleAndObservation_06_2007.gifgif BoreHoleAndObservation_06_2007.gif manage 23.4 K 23 Jul 2007 - 18:53 MarcusSen Older version
BoreholeAndObservation.pngpng BoreholeAndObservation.png manage 23.4 K 23 Jul 2007 - 19:06 MarcusSen Relationship between Boreholes and Observations, July 2007
GeoSciML_BoreHoleObservation_10_2007.gifgif GeoSciML_BoreHoleObservation_10_2007.gif manage 129.7 K 17 Oct 2007 - 07:23 BruceSimons Relationship between Boreholes and Observations, version 2.0, October 2007
Summary_diagram_Boreholes_and_observations.pngpng Summary_diagram_Boreholes_and_observations.png manage 145.8 K 01 Feb 2010 - 12:30 BruceSimons GeoSciML v2.0 Release version of Boreholes and O&M
Topic revision: r42 - 30 Jun 2011, OliverRaymond

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