III.A.  Motivation

A significant portion of the global water supply can be attributed to groundwater resources. Effective management of such resources requires the collection, management and delivery of related data, but these are impeded by issues related to data availability, distribution, fragmentation, and heterogeneity: collected data are not all readily available and accessible, available data is distributed across many agencies in different sectors, often thematically fragmented, and similar types of data are diversely structured by the various data providers. This situation holds both within and between political entities, such as countries or states, impairing groundwater management across all jurisdictions. Groundwater data networks are an emerging solution to this problem as they couple data providers through a unified data delivery vehicle, thus reducing or eliminating distribution, fragmentation, and heterogeneity through the incorporation of standards for data access and data content. The relative maturity of OGC data access standards, such as the Web Feature Service (WFS) and Sensor Observation Service (SOS), combined with the rise of water data networks, have created a need for GroundWaterML2 (GWML2), a common groundwater data standard.

III.B.  Historical background

Several activities have influenced the development of GWML2.

• GWML1: a GML application schema for groundwater data developed at Natural Resources Canada and used to exchange groundwater data within Canada, between Canada and the USA, and in some other international efforts (Boisvert & Brodaric, 2012).

• GWIE1: an interoperability experiment within the OGC HDWG, in which groundwater data was shared across the USA-Canada border (Brodaric & Booth, 2011).

• GW2IE: a second interoperability experiment within the OGC HDWG, that designed and tested a precursor of GroundWaterML2 (GWML2, version 2.1): a conceptual, logical, and encoding specification for the representation of core groundwater data (OGC, 2016).

• INSPIRE Data Specification on Geology — hydrogeology package: a conceptual model and GML application schema for hydrogeology (INSPIRE, 2013), with regulatory force in the European Union and for which GWML2 is expected to be an encoding candidate.

• BDLISA: the French Water Information System information models for water wells and hydrogeological features (BDLISA, 2013).

The primary goal of this standard is to capture the semantics, schema, and encoding syntax of key groundwater data, to enable information systems to interoperate with such data.

2.1.  XML implementation

The XML implementation (encoding) of the conceptual and logical groundwater schemas is described using the XML Schema language and Schematron.

Requirements for one standardization target type are considered:

• data instances.

i.e., XML documents that encode groundwater data. As data producing applications should generate conformant data instances, the requirements and tests described in this standard effectively also apply to that target.

Conformance with this standard shall be checked using all the relevant tests specified in Annex A (normative) of this document. The framework, concepts, and methodology for testing, and the criteria to be achieved to claim conformance are specified in ISO 19105: Geographic information — Conformance and Testing. In order to conform to this OGC encoding standard, a standardization target shall implement the core conformance class, and choose to implement any one of the other conformance classes (i.e., extensions).

All requirements-classes and conformance-classes described in this document are owned by the standard(s) identified.

2.2.  Use of vocabularies

Controlled vocabularies, also known as code-lists, are used in data exchange to identify particular concepts or terms, and sometimes relationships between them. For example, an organization may define a controlled vocabulary for all observed phenomena, such as water quality parameters, that are to be exchanged between parties. Some of these definitions may be related by hierarchical relationships, such as specialization, or through other relationships such as equivalence.

GroundWaterML2.0 does not define a set of vocabularies for groundwater data exchange in this version. It is envisaged that specific communities will develop local vocabularies for data exchange within the community. Future work within the Hydrology Domain Working Group could address standardized controlled vocabularies for the groundwater domain. Such vocabularies require a governance structure that allows changes to be made as definitions evolve, possibly using the OGC definition namespace (http://www.opengis.net/def/gwml/2.2), which is governed by the OGC Naming Authority (OGC-NA). The OGC-NA is responsible for processing requests to change or add new definitions to this namespace. The procedures for the OGC-NA are outlined in OGC document 09-046 (OGC-NA – Procedures) and the structure of URIs is outlined in OGC 09-048 (OGC-NA – Name type specification – definitions). Any URIs for vocabulary items (e.g. identifiers for various property values, properties, roles or other fixed labels) in this specification are included as examples only, for illustration purposes, and will not resolve, because GWML2 vocabularies are not defined. However, some such URIs in various example encodings may resolve if data providers have defined and implemented vocabularies for particular services.

The following convention has been used throughout the document to identify attributes requiring controlled vocabularies:

• In the conceptual model, such attributes are typed with a name ending by Type (ex: PorosityType); and

• In the logical model this suffix becomes TypeTerm (ex: PorosityTypeTerm).

2.3.  Groundwater data

Groundwater data conforming to this standard are encoded in GML-conformant XML documents, for this version of GWML2. It is anticipated that future versions or extensions will develop additional encodings such as JSON or RDF. The standard MIME-type and sub-type for GML data should be used to indicate the encoding choice as specified in MIME Media Types for GML, namely: application/gml+xml.

Conformance with this standard shall be checked using all the relevant tests specified in Annex A (normative) of this document. The framework, concepts, and methodology for testing, and the criteria to be achieved to claim conformance are specified in the OGC Compliance Testing Policies and Procedures and the OGC Compliance Testing web site¹.

In order to conform to this OGC™ interface standard, a software implementation shall choose to implement:

1. Any one of the conformance levels specified in Annex A (normative).

All requirements-classes and conformance-classes described in this document are owned by the standard(s) identified.

6.1.  Requirements class

Each normative statement (requirement or recommendation) in this standard is a member of a requirements class. Each requirements class is described in a discrete clause or sub-clause, and summarized using the following template:

Table 2

All requirements in a class must be satisfied. Hence, the requirements class is the unit of re-use and dependency, and the value of a dependency requirement is another requirements class. All requirements in a dependency must also be satisfied by a conforming implementation. A requirements class may consist only of dependencies and introduce no new requirements.

6.2.  Requirement

All requirements are normative, and each is presented with the following template:

Table 3

where /req/[classM]/[reqN] identifies the requirement or recommendation. The use of this layout convention allows the normative provisions of this standard to be easily located by implementers.

6.3.  Conformance class

Conformance to this standard is possible at a number of levels, specified by conformance classes (Annex A). Each conformance class is summarized using the following template:

Table 4

All tests in a class must be passed. Each conformance class tests conformance to a set of requirements packaged in a requirements class.

W3C Schema (XSD) and ISO Schematron (SCH) files are considered as part of this standard, although available online only, due to concerns about document size. Many requirements are expressed in a single XSD or SCH file although tests are listed individually in the conformance annex (one test for XSD and one test for SCH).

Schematron files explicitly specify which requirements are being tested in the title of the schematron pattern.

<pattern id="origin_elevation">

<title>Test requirement: /req/well-xsd/origin-elevation</title>

<rule context="gwml2w:GW_Well">

<assert test="count(gwml2w:gwWellReferenceElevation/gwml2w:Elevation[gwml2w:elevationType/@xlink:href='http://www.opengis.net/req/well/origin_elevation']) = 1">A GW_Well needs at least one origin Elevation</assert>

</rule>

</pattern>

6.4.  Identifiers

Each requirements class, requirement and recommendation is identified by a URI. The identifier supports cross-referencing of class membership, dependencies, and links from each conformance test to the requirements tested. In this standard, identifiers are expressed as partial URIs or paths, which can be appended to a base URI that identifies the specification as a whole in order to construct a complete URI for identification in an external context.

The URI for each requirements class has the form:

http://www.opengis.net/spec/groundwaterml/2.2/req/[classM].

The URI for each requirement or recommendation has the form:

http://www.opengis.net/spec/groundwaterml/2.2/req/[classM]/[reqN].

The URI for each conformance class has the form:

http://www.opengis.net/spec/groundwaterml/2.2/conf/[classM].

The URI for each conformance test has the form:

http://www.opengis.net/spec/groundwaterml/2.2/conf/[classM]/[testN].

6.5.  External package abbreviations

Concepts from schemas defined in some other International Standards are designated with names that start with alpha codes as follow:

Table 5

6.6.  Abbreviated terms

In this document the following abbreviations and acronyms are used or introduced:

Table 6

6.7.  UML notation

The diagrams that appear in this standard, including the GWML2 Conceptual and Logical schemas, are presented using the Unified Modeling Language (UML), in compliance with ISO/IEC 19505-2.

Note: Within the GWML2 conceptual and logical diagrams, the following color scheme is used to identify packages in some cases. This is just for information purposes.

Amber: GWML2 defined within this standard

Green and Purple: from GeoSciML 4.0

Blue: from O&M

6.8.  Finding requirements and recommendations

This standard is identified as http://www.opengis.net/spec/groundwaterml/2.2. For clarity, each normative statement in this standard is in one and only one place, and defined within a requirements class table and identified with a URI, whose root is the standard URI. In this standard, all requirements are associated to tests in the abstract test suite in Annex A. using the URL of the requirement as the reference identifier. Recommendations are not tested but are assigned URLs and are identified using the ‘Recommendation’ label in the associated requirements table.

Requirements classes are separated into their own clauses, named, and specified according to inheritance (direct dependencies). The Conformance test classes in the test suite are similarly named to establish an explicit and mnemonic link between requirements classes and conformance test classes.

7.1.  Technical Basis

This standard builds on a number of standards for encoding XML data, including:

• OMXML (10-025r1)

• sweCommon (08-094r1)

• GML ISO 19136:2007 (07-036r1)

• ISO/TS 19139:2007 (Metadata)

• W3C XSD

This standard also builds on existing schema, primarily Observations & Measurements (OMXML) and GeoSciML 4.0 (16-008). It accomplishes this by (a) extending these schemas with groundwater specializations, (b) referring to a class in these schema in order to type a named property, or © using a class from the schemas as one of the two participants in a binary relationship.

7.2.  Overview of Observations & Measurements

ISO 19156:2011 — Observations and Measurements is a generic GML schema for observations. As shown in Figure 1, it defines an observation as “…​an act associated with a discrete time instant or period through which a number, term or other symbol is assigned to a phenomenon. It involves application of a specified procedure, such as a sensor, instrument, algorithm or process chain. The procedure may be applied in-situ, remotely, or ex-situ with respect to the sampling location. The result of an observation is an estimate of the value of a property of some feature.“

7.2.1.  Sampling features

Sampling features in O&M are defined as a “feature, such as a station, transect, section or specimen, which is involved in making observations concerning a domain feature.” Sampling features in the groundwater domain are features along which, or upon, observations are made. The most relevant are water wells and boreholes, which effectively host observations along staged intervals; a collection of these intervals and their observations constitutes a log.

Figure 1 — Observation in O&M (from ISO 19156:2011)

7.3.  Overview of GeoSciML 4.0

GeoSciML 4.0 is a GML schema for core geological entities including geological units, structures, and earth materials. It is particularly relevant to GWML2 because bodies of rock serve as containers for subsurface water bodies. Such rock bodies possess variable hydrogeologic properties according to their material composition and topological organization. Thus, geological units and earth materials are the key GeoSciML 4.0 entities required by GWML2.

GeoSciML 4.0 defines a geological unit as “a body of material in the Earth whose complete and precise extent is inferred to exist (NADM GeologicUnit, Stratigraphic unit in sense of NACSN or International Stratigraphic Code), or a classifier used to characterize parts of the Earth (e.g., lithologic map unit like ‘granitic rock’ or ‘alluvial deposit’, surficial units like ’till’ or ‘old alluvium’).“

GeoSciML 4.0 defines an earth material as “naturally occurring substance in the Earth” and intuitively refers to various types of rocks such as sandstone, granite, and gneiss.

8.1.  Hydrogeological Units

These are distinct volumes of earth material that serve as containers for subsurface fluids. The boundaries of a unit are typically discriminated from those of another unit using properties related to the potential or actual ability to contain or move water. The properties can be geological or hydraulic, and typically include influences from the surrounding hydrological environment. More specifically, the conceptual model delineates two types of hydrogeological units, with slightly different orientations: aquifer-related units have boundaries delimited by the hydrogeological properties of the rock body, while groundwater basins have boundaries delimited by distinct flow regimes. Aquifer-related units are subdivided into aquifer systems, which are collections of aquifers, confining beds, and other aquifer systems. Confining beds are units that impede water flow to surrounding units, and supersede notions such as aquitards, aquicludes, and aquifuges, which are not included herein, as it is difficult to differentiate these in practice.

Several significant properties are typically attributed to hydrogeological units, such as porosity, permeability, and conductivity, but these and others are modeled more accurately here as occurring necessarily concurrent with (dependent on) voids or fluid bodies. For example, porosity, in its various forms, requires both the presence of a unit (container) and its voids, as it is typically defined as the proportion of void volume to total unit volume (i.e., volume of solid material plus voids). Likewise, properties such as hydraulic conductivity and yield require the presence of units and fluid bodies, as they are concerned with the rate of movement of a fluid through a unit. Note that permeability and hydraulic conductivity are differentiated here: permeability refers to intrinsic permeability, which measures the ability of a unit to host fluid flow, independent of fluid properties and based solely on the connectivity and size of voids, whereas hydraulic conductivity additionally considers fluid properties.

Likewise, management areas are also relational entities in the sense that they are typically necessarily linked with a unit (or system) and possibly a fluid body. Management areas are earth bodies identified for groundwater management purposes and their boundaries can be delineated by social factors, such as policy or regulation, in addition to physical factors related to hydrogeology or hydrology.

8.2.  Fluid Bodies

These are distinct bodies of fluid (liquid or gas) that fill the voids in hydrogeological units. Fluid bodies are made of biologic (e.g., organisms), chemical (e.g., solutes), or material constituents (e.g., sediment). While it is expected that the major constituent of a fluid body will be water, the conceptual model allows for other types of major constituents such as petroleum. Minor constituents are not necessarily fluids, but can be gases, liquids, or solids (including organisms), and are included in the fluid body in various forms of mixture, such as solution, suspension, emulsion, and precipitates. Fluid bodies can also have other fluid bodies as parts, such as plumes or gas bubbles. Surfaces can be identified on a fluid body, such as a water table, piezometric or potentiometric surface, and some such surfaces can contain divides, which are lines projected to the fluid surface denoting divergence in the direction of flow systems within the fluid.

8.3.  Voids

Voids are the spaces inside a unit (e.g., aquifer) or its material (e.g., the sandstone material of an aquifer), and might contain fluid bodies. Voids are differentiated from porosity, in that porosity is a ratio of void volume to total volume of unit plus voids, while voids are the spaces themselves. It is important to conceptually differentiate voids from units and their containers, in order to represent, for example, the volume of fractures, caves, or pores in a particular unit or its portion.

8.4.  Flow

Groundwater flow denotes the process by which a fluid enters or exits a container (unit) or its voids, or flows within them. Flow between one container or void and another is named InterFlow, and flow within a container or void is named IntraFlow. Recharge is the flow into a groundwater container or void, and discharge is flow out of a groundwater container or void. The reciprocal source or destination entity can be any appropriate container or void such as a river, lake, pipe, reservoir, canyon, flood plain, ground surface, etc. A flow system is then a collection of flows ordered in a sequence from recharge to discharge, such that the flow segments of the system make up a connected flow path from source to destination. A water budget is a measure of the balance of recharge and discharge valid for a specific time and relative to a specific groundwater feature, such as a basin, aquifer, management area, or well.

Many of these concepts are depicted in Figure 2. Shown is a flow system (A+B) and two subsystems (A, B) that are its parts. Each subsystem is composed of interior flows, indicated by the solid lines with arrows, as well as input and output flows indicated as recharge and discharge, respectively. These flow systems are contained by three distinct hydrogeologic unit bodies, with the middle body oriented at an angle and having a K (hydraulic conductivity) value of 10^-5. Intraflow is exemplified by a flow line within the right hydrogeologic unit body, while Interflow is exemplified by the flow from right body (the source container) to middle body (the destination container). The boundary between the bodies serves as the interface through which the flow occurs. While not shown, the three hydrogeologic unit bodies contain a groundwater body (i.e., a fluid body) in their pores (i.e., voids), and it is this groundwater body that is flowing.

Figure 2 — Example flow system with two subsystems (after Freeze & Cherry, 1978, p. 204)

8.5.  Wells

Well-related entities include water wells, springs, and monitoring sites. Water wells are man-made constructions for monitoring, withdrawing, or injecting water from/into a hydrogeological unit, while springs are features where water discharges to the surface naturally. Both wells and springs possess important links to the hydrogeological environment, including their host units and materials, as well as the intersecting fluid body. Monitoring sites are locations where devices are placed to measure various properties of significance to hydrogeology, such as water level, flow rate, water temperature, or chemical composition, or to take samples. As such, monitoring sites are roles played by other features, for example, water wells or springs.

8.6.  Conceptual Model Specification

Figure 3 — GWML2 CM — Hydrogeological Unit

Figure 4 — GWML2 CM — Groundwater Properties

Figure 5 — GWML2 CM — Fluid Body

Figure 6 — GWML2 CM — Groundwater Flow

Figure 7 — GWML2 CM — Wells

8.7.  Requirements

Target logical models that are compliant with the conceptual model shall implement components of the conceptual model respecting their semantics, i.e., their definition and intent. In other words, the logical model must be highly semantically similar to components of the conceptual model and must not specify any requirements that would contradict or result in non-conformance to the conceptual model. Semantic similarity can be tested in multiple ways, including but not limited to: (i) direct comparison of UML components, (ii) comparison after mapping components to a common expressive knowledge representation language, such as first order logic or common logic, or (iii) comparison after mapping components to a reference ontology. The target can reuse and adapt existing logical models.

9.1.  Logical Model Specification

Figure 8 — GWML2 LM — Package Dependencies (Internal).

Figure 9 — GWML2 LM — Package Dependencies (External — indirect dependencies not shown).

Figure 10 — GWML2 LM — Hydrogeological Unit.

Figure 11 — GWML2 LM — Groundwater Properties.

Figure 12 — GWML2 LM — Fluid Body.

Figure 13 — GWML2 LM — GroundWaterML2-Constituent.

Figure 14 — GWML2 LM — Groundwater Flow.

Figure 15 — GWML2 LM — Well.

Figure 16 — GWML2 LM — WellConstruction.

Figure 17 — GWML2 LM — Aquifer Test.

10.1.  Abstract requirements classes: GWML2 core logical model

This core requirement class describes requirements that must be met by all target implementations that claim compliance with GWML2 (this standard). It also sets common requirements for all extensions of this standard. Since this requirement class is abstract, a conformant target implementation SHALL also implement at least one concrete requirements class from Clause 10.2 and greater.

The properties, constraints, cardinalities and associations documented in the UML will be honoured by all the target implementations.

10.2.  Requirement class: GWML2-Main

10.2.1.  Feature of interest for Association classes

OM_Observation is extensively used to represent property values wherever it is useful to include supporting metadata such as the methods used to obtain the values. As stated in ISO 19156:2011/10-004r3, the OM_Observation’s feature of interest should be the bearer of the observed property (10-004r3, Clause 7.2.2.7). All properties in GWML 2.2 that use OM_Observation in the model are carried by Features; the relationship between the observation and the bearer of properties is obvious, except for two cases: GW_UnitFluidProperty (Figure 18) and GW_UnitVoidProperty (Figure 19).

GW_FluidProperty is an association class linking a GW_HydroGeoUnit and a GW_FluidBody and carries properties that are inherently related to the association of a geological unit and the fluid occupying its voids. Not being a feature, this class cannot be the feature of interest of the properties it bears.

Figure 18 — Association class between a GW_HydrogeoUnit and GW_FluidBody.

Traditionally, those properties (gwHydraulicConductivity, gwStorativity, gwTransmissivity and gwYield) are assigned by convenience to the hydrogeological unit (GW_HydrogeoUnit), because the fluid is a body of groundwater (GW_FluidBody) that is rarely explicitly identified. Therefore, the feature of interest of all the values of GW_UnitFluidProperty SHALL be the GW_HydrogeoUnit instance at the gwFluidBodyUnit end of the GW_UnitFluidProperty association.

Requirement 7:
/req/main/observed-unit-fluid-property-foi
The feature of interest of OM_Observation values for GW_UnitFluidProperty properties (gwHydraulicConductivity, gwStorativity, gwTransmissivity and gwYield) SHALL be the GW_HydrogeoUnit instance at the gwFluidBodyUnit end of the GW_UnitFluidProperty association.

Similarly, GW_UnitVoidProperty is an association class linking a GW_HydroGeoUnit with a GW_HydrogeoVoid, and this association class also then cannot be the feature of interest for the properties it bears (Figure 19).

Figure 19 — Association class between a GW_HydrogeoUnit and GW_HydrogeoVoid.

As void properties are traditionally assigned to the hydrogeologic unit, the feature of interest of all property values of GW_UnitVoidProperty SHALL be the GW_HydrogeoUnit instance, which is located at the gwVoidUnit end of the GW_UnitVoidProperty association.

Requirement 8:
/req/main/observed-unit-void-property-foi
The feature of interest of OM_Observation values for GW_UnitVoidProperty properties (gwPermeability and gwPorosity) SHALL be the GW_HydrogeoUnit instance at the gwVoidUnit end of the GW_UnitVoidProperty association.

Requirement 9:
/req/main/managementArea
GW_Management’s gwAreaFeature SHALL NOT be a subtype of GW_HydrogeoUnit.

10.3.  Requirement class: GWML2-Constituent

Analytical results are modelled as OM_Observation having GW_Constituent as features of interest (see Figure 20). A typical analytical procedure involves a sampling feature (such as a SF_Specimen) and a series of OM_Observations reporting on some properties of the feature of interest.

Figure 20 — The pattern for analytical results.

By referring to the real world identifiable feature using the sampledFeature property, and using the observation’s featureOfInterest to refer to the constituent of the fluid body, this pattern permits a detailed description of the composition of various parts of the fluid body.

10.4.  Requirement class: GWML2-Flow

This requirements class does not contain any requirement. All the requirements are inherited from /req/core and /req/constituent.

10.5.  Requirement class: GWML2-Well

This clause describes groundwater abstraction and monitoring through artificial features (water wells, monitoring stations) and natural features (springs). Artificial features are modelled as O&M sampling features (by the ISO 19156:2011 definition) as they are used as support for observations.

10.5.3.  Geology Log

GW_GeologyLog is an OM_Observation, with a start and end measured (along the borehole path) depth, that shall capture downhole geological observations (including geophysical and geochemical). Because GW_GeologyLog is a specialisation of OM_Observation, it can be use anywhere a OM_Observation is expected (unless explicitly forbidden) and therefore be a valid value for relatedObservation (inherited from OM_Observation). To avoid confusing semantic, this specification limits the use of GW_GeologyLog togwml:gwWellGeology property only.

Requirement 24:
/req/well/well-geology
In a context of a GW_Well, instances of GW_GeologyLog SHALL only be used as values of GW_Well::gwWellGeology.

The geologic log is encoded as a GW_GeologyLogCoverage (Clause 9.1.10) or as a DataArray (Clause 10.9).

Figure 21 — Alternative Log encodings

Requirement 25:
/req/well/log
The value of om:result of GW_GeologyLog SHALL either be a GW_GeologyLogCoverage or swe:DataArray

10.6.  Requirement class: GWML2-WellConstruction

10.7.  Requirement class: Vertical Well (profile)

A vertical well is a special case where the shape of the well is a straight vertical line. The rationale to create a special profile is to inform the data consumer that calculation of relative position into absolute position is greatly simplified — or the well shape can be ignored since all the positional information can be inferred from the GW_Well::WellLocation, gwWellReferenceElevation and gw:WellTotalLength. This implies there is an alternative way to build “3D” query. Vertical wells are very common and several groundwater applications expect them to be vertical. GW_Well:shape shall have only 2 vertices.

The second vertex shall have the same x and y as the first vertex.

10.8.  Requirement Class: GeologyLog (profile)

This requirement class describes a recommended pattern to encode a GeologyLog.

In this profile, geological logs are modelled as GML discrete coverages (CV_DiscreteElementCoverage, 06-188r1) of elements of type LogValue. Each Log Value is composed of a pair of properties to locate the element along the Well path (fromDepth and toDepth) and a SWE DataRecord that contains an arbitrary set of fields to report properties of interest along the path (see Figure 22). This approach is verbose and exposes explicitly fromDepth and toDepth, making it more suitable to a WFS environment. which uses XPath to target filter properties. It also allows heterogenous coverages, since nothing prevents a different DataRecord in each element. This might or might not be considered a positive aspect. A community can enforce DataRecord to remain the same in the coverage by defining their own profile.

Figure 22 — SWE Data Record

SWE (08-094r1, Clause 7.3) describes the requirements to encode a DataRecord. A community that defines a common Geologic Log encoding should agree on a definition and scoped name for the DataRecord, as well as on definitions of the individual fields composing the record.

For example, a community that wants to use some GeoSciML 4.0 vocabulary to encode a geology log can agree on a field type (eg: SWE Category) and a definition (a URI) to flag that field in the DataRecord as having controlled content. Another community might chose to constrain the complete DataRecord by agreeing on the scoped name of the DataRecord itself.

10.9.  Requirement class: DataArray

This requirement class describes the recommended compact pattern to encode a GeologyLog.

Block log encoding is an alternative to GeologicLogCoverage encoding (see clause Clause 10.8). Clause Clause 10.8 provides an explicit discrete coverage encoding that is rather verbose because of the nature of the combination of CV_DiscreteCoverage and DataRecord. Each member of the discrete coverage defines a new DataRecord, and describes the record structure. As logs usually describe the same variables along their length, this structure is extremely redundant.

The SWE::DataArray (08-094r1, Clause 7.5) encoding is more compact because it describes fields only once in a header section. DataArray also provides alternative value encoding (xml, text block or binary) and external references to encoded data files. Because this encoding does not impose an explicit “from” and “to” field, it can also accommodates non-spatial logs (such as time series). Note that users seeking water related time series should consider WaterML Part 1 (10-126r4). Note that swe:Matrix is a subtype of swe:DataArray, making swe:Matrix a valid substitute.

For client applications ingesting a DataArray, this specification defines explicit identifiers for fromDepth and toDepth. A client can then locate the position properties by scanning the component definitions.

Compact encoding is composed of a series fields from which 2 might designated as fromDepth and toDepth, representing a section along the log.

DataArray::elementType provides a description of each field composing the array, The data type is defined using a SWE DataComponent used as data description (08-094r1, Clause 7.3.1). Each DataComponent has a definition property containing to a unique URI representing a specific property (eg: SWE::Quantity for a Temperature). It is recommended that a standard list of definition URI is defined by a community to uniquely identified properties of interest.

10.10.  Requirement class: Aquifer test (profile)

Aquifer hydraulic parameters are routinely evaluated by a series of tests that involves pumping or injecting water at known rates and by observing the changes in the water table. Other tests might involve injecting a tracer (radio element or dye) at some location and follow its progression at observation points. From these observations, various methods have been developed to compute aquifer properties. To adequately report an aquifer test, the data about initial conditions, test parameters, sampling features, measured and calculated observation must be packaged and put into context.

Figure 17, above, shows the elements required to encode an aquifer test. An AquiferTest assesses an Aquifer using a method (eg: Packer test) that is encoded as an OM_Process. The test is performed at a test site (the GW_AquiferTest defines a geometry corresponding to the test location) and consists of sampling features (usually the GW_Well) that are associated to the GW_AquiferTest through relatedSamplingFeature. Each sampling feature has a role in the test (observation or test features). Some sampling features are sites where test activities are performed (referred to as “test feature”), such as pumping water out of a bore. Other features are sites where more passive observations are made, such as measuring the impact of pumping made at the test sampling feature on the water table. From this activity, a series of observation are made, typically time series along the timespan of the test. Then from these observations, a method is used to infer some aquifer properties (such as transmissivity, storativity or yield). The findings are then documented in a report that can be attached to GW_AquiferTest using generic metadata properties.

A typical AquiferTest might be sketched as follows in Figure 23:

Figure 23 — A typical pumping test.

10.10.1.  Aquifer Test O&M mapping

Observation and Measurement (O&M 2.0 : OGC 10-004r3), along with its GWML extensions, contains all the elements needed to model an aquifer test. A complete aquifer test can be built around SF_SamplingFeature and OM_Observation, with the addition of GW_AquiferTest, a subtype of SF_SpatialSamplingFeature (Figure 24), to distinguish aquifer tests from other sampling features and to package observations and sampling features.

Figure 24 — GW_AquiferTest.

10.10.3.  SF_SamplingFeature properties

10.10.3.1.  sampledFeature

In the context of an aquifer test, it links to the real world feature being assessed by the aquifer test (generally a GW_AquiferUnit). O&M does not constrain SF_SamplingFeature to any particular feature type, but this standard requires that the sampledFeature shall be a subtype of a GW_HydrogeoUnit.

Requirement 36:
/req/aquifertest/sampledfeature
The sampledFeature of a GW_AquiferTest SHALL be an instance of (or a reference to) a subtype of GW_HydrogeoUnit.

10.10.3.2.  relatedSamplingFeature

In the context of an aquifer test, the related sampling feature property identifies all the sampling features participating in the aquifer test. The role of each feature is assigned by the SF_SamplingFeatureComplex:role property. The role of the sampling feature is scoped by the test. Therefore the same sampling feature can have different roles in different tests, but also within the same test (by having multiple SF_SamplingFeatureComplex referring to the same SF_SamplingFeature). Single bore tests are examples where the observation bore and the test bore are the same feature. This standard proposes a list of core roles to identify the observation features and test features.

The test feature is the “active” sampling feature where the test is performed (e.g., the well that is pumped or injected).

Requirement 37:
/req/aquifertest/testfeature
SF_SamplingFeatureComplex:role for the sampling feature where the test is performed SHALL have the value http://resource.gwml.org/def/role/testFeature

The observation feature is the “passive” feature where observations are made. It is the feature at which the effects of the test are measured.

Requirement 38:
/req/aquifertest/observationfeature
SF_SampleFeatureComplex:role for the sampling feature where the observations are made SHALL have the value http://resource.gwml.org/def/role/observationfeature

A single sampling feature can be the target of several SF_SamplingFeatureComplex. A data provider can add more than one SF_SamplingFeatureComplex to accommodate other roles (see Figure 25).

Figure 25 — Multiple roles for the same well using two SF_SamplingFeatureComplexes.

10.10.3.3.  parameter

Test parameters, such as pumping rates during the test are not considered as being an observation, but as test parameters. To document test parameters, there are two options:

• Using SF_SpatialSamplingFeature:hostedProcedure of type OM_Process that can encode all possible details of a test using SensorML (OGC 12-000), MD_Metadata (ISO-19115) or any other suitable model; or

• Use parameter of type SF_SamplingFeature:parameter:NamedValue using agreed value types for well-known test parameters.

Although the formal mechanism to report test parameters is through OM_Process, this standard recommends reporting community defined values in simple parameter key-value pairs (KVP) using sf:NamedValue.

Recommendation 7:
/req/aquifertest/testparameter
When present, SF_SamplingFeature:parameter:NamedValue SHALL be encoded using community defined values

10.10.3.4.  relatedObservation

All related observations, including the observations made at the test feature sites and observation derived from those observations should be available as related observations (sf:relatedObservation).

Recommendation 8:
/req/aquifertest/observation
All observations relevant to an aquifer test SHOULD be available as relatedObservation

From the raw observations measured during a test, new observations can be inferred or calculated. The raw observations (related from the observation Features) and the derived observations (the result of the test) SHALL be related to each other using om:ObservationContext. The role of the observation context defines which observation derives or supports the other one. ‘supportObservation’ and ‘derivedObservation’ roles can be considered complementary: if A is supportObservation of B, then B is the derivedObservation of A.

Requirement 39:
/req/aquifertest/observation-role
Raw observations from the observation sampling feature SHALL be link to the test result observations using the roles defined in Table 98

Table 98 — ObservationContext roles.

Role	URI	Direction
Support observation	http://www.opengis.net/def/role/supportObservation	Observation linking to other observation used to calculate, derive or infer a new values
Derived observation	http://www.opengis.net/def/role/derivedObservation	Observation linking to another observation that has calculated, inferred or derived values

10.10.3.5.  hostedProcedure

A hostedProcedure is used to document such things as methods to identify or localise the sampling feature, but its use is not constrained to anything specific. The hostedProcedure property, of type OM_Process, may be used to accommodate detailed aquifer test parameters if needed by the data provider.

The O&M standard does not prescribe any model to encode OM_Process, but suggests:

ISO 19115-2 provides MI_Instrument, LE_Processing and LE_Algorithm, which could all be modelled as specializations of OM_Process. OGC SensorML [16] provides a model which is suitable for many observation procedures

OGC 10-0043 / ISO 19156, clause 7.2.3, p. 14

For instance, a pump (used to pump water from the borehole) can be modelled as a SensorML sml:PhysicalSystem.

10.10.3.6.  shape

SF_SpatialSamplingFeature does not constrain the geometry type (Point, Curve, Polygon, etc), therefore any geometry can represent a test. In most situations, the geometry of the test is the test area, the zone of influence around the pumping test or even the volume of rock affected or in scope for the test.

This standard also does not constrain the geometry type. Communities that wish to constrain the geometry type should create a profile of this standard.

10.10.4.  OM_Observation

OM_Observations are used to represent values of properties observed or computed in the context of this test. There are at least two categories of observations generated through an aquifer test:

• Raw observations, normally taken at the observationFeatures; and

• Derived observations, calculated from the raw observations.

These two kinds of observations differ by their respective feature of interest. For the former (raw data) the feature of interest is the sampling feature from which observations are made (e.g., observation bore). In the latter case, the feature of interest is the GW_AquiferTest itself. Observations can be linked together using related observations (om:relatedObservation/om:ObservationContext), which provide a role (om:ObservationContext/om:role) for the targeted observation. Figure 26 shows an example of “raw” observations (Drawdown1 and Drawdown2) measured at two observation wells (obs1 and obs2). The same figure also shows a derived observation (transmissivity) having the aquifer test itself as its feature of interest. The derived observation provides a link back to the supporting observation used to compute the derived values.

Figure 26 — Relationships between observations and features of interest.

Observations made during the test and computed observations are modelled as OM_Observations.

10.10.4.1.  phenomenonTime, resultTime and validTime

As specified in Observation and Measurement; phenomenonTime reflects the time that the result applies to the property; the resultTime is the time at which the value has been obtained or became available and validTime is the time during which the value is usable. Depending on the type of observation (raw or computed), those time might be different (see Table 99).

Table 99 — Types of observations and times.

Type of Observation	phenomenonTime	resultTime	validTime
Raw	Duration of the test	End of the test	Period during which the condition are the same, so the same test would produce the same values
Derived	Duration of the test	When calculation are done (publication)	Depends on the parameters or test

10.10.4.2.  observedProperty

This property describes the phenomenon being observed (e.g., groundwater level). The observed property is normally a reference to a property inherent in the feature of interest (“`the real word feature is the subject of the observation and carries the observed property, clause=7.2.2.7). But because of subtle variations in the semantics of such properties (such as specific Yield versus maximum Yield versus sustainable Yield, etc.), the observedProperty meaning should be formally defined by a community. The value of observedProperty becomes a reference to that definition (expressed in SWE, SKOS or OWL for example).

ObservedProperty can also be a compound property (a collection of observedProperty). Again, because of the close tie to use cases, compound properties should be defined by a community.

Recommendation 9:
/req/aquifertest/observedProperty
The observedProperty SHOULD be a reference to a community managed vocabulary.

10.10.4.3.  result

The result property reports the product of the observation process. In many cases, the aquifer test will produce a time series, such as drawdown data over time. When the result is a time series, it shall be modelled as a TimeSeriesML 1.0 (OGC 15-082r3).

Requirement 40:
/req/aquifertest/timeseries
Observation producing time series SHALL be modelled as TimeSeriesML 1.0 (OGC 15-042r3)

Derived (or computed) observations will often produce compound values. It is possible to report each result component as distinct observations, but GWML2 shall use the more efficient alternative of wrapping compound results into swe:DataRecord.

Requirement 41:
/req/aquifertest/timeseries-datarecord
Derived or computed observations SHALL be encoded as swe:DataRecord

10.10.5.  Aquifer test overview

Figure 27 provides an example of the mapping of AquiferTest to O&M.

Figure 27 — Typical pump test instance: 1 sampling feature and 2 observation features.

11.1.  GWML2-XSD

Groundwater features and their properties will be encoded in XML using standard GML encoding rules (Annex E of OGC Geography Markup Language v3.2 (ISO 19136:2007).

In examples, HTTP URIs that are used as resolvable resources (e.g. for vocabularies) may be included as examples only, for illustration purposes, and may not resolve, because the vocabularies are not defined. However, some such URIs in various example encodings may resolve if data providers have defined and implemented vocabularies for particular services.

XML snippets will use the following prefixes:

Table 100

ISO-19136_2007 provides a mapping between UML classifiers and XSD entities. All XSD types and elements must be created following those mapping rules. This standard considers the XSD files (the schema files) to be normative (they contain the official interpretation of 19136 conversion of the UML classifiers into XML).

Other rules, that can’t be expressed in XSD, are provided as schematron rules. As the XSD files, schematron rules files are considered normative.

The date-time formats will conform to ISO standards. Although this is already a GML 3.2.1 encoding rule (clause 14.2.2.7), this format shall also be used in any string that is not normally checked for an occurrence of dates.

Note that this precludes the use of time-coordinate systems such as UNIX time. This is specified in order to be maximally consistent with WML2 requirements. The time zone will be included in the time element.

Greenwich Mean Time (GMT or Zulu)

<om:phenomenonTime>

<gml:TimeInstant gml:id="ab.ww.402557.wl.1.ti.1">

<gml:timePosition>1981-09-12T00:00:00Z</gml:timePosition>

</gml:TimeInstant>

</om:phenomenonTime>

Time Zone (example is Newfoundland time zone -3:30)

<om:phenomenonTime>

<gml:TimeInstant gml:id="nf.ww.34212.wl.1.ti.1">

<gml:timePosition>1981-09-12T00:00:00-03:30</gml:timePosition>

</gml:TimeInstant>

</om:phenomenonTime>

Some SWE Common types are restricted to avoid ambiguity.

(...)

<gwml2w:GW_Well gml:id="ca.ab.gov.wells.402557">

<gml:description>Water well from Alberta water well database</gml:description>

<gml:identifier codeSpace="http://www.ietf.org/rfc/rfc2616">http://ngwd-bdnes.cits.nrcan.gc.ca/Reference/uri-cgi/feature/gsc/waterwell/ca.ab.gov.wells.402557</gml:identifier>

<gml:name codeSpace="urn:cgi:featureType:CA.AB:WaterWell">402557</gml:name>

<gml:name codeSpace="urn:x-gin">ca.ab.waterWell.402557</gml:name>

(...)

(...)

<gwml2:gwAquiferSystemPart xlink:href="http://environment.data.gov.au/groundwater/feature/hydrogeologicalunit/hgu.nsw.5" xlink:title="Stuarts Point - Lower Quaternary Sands"/>

(...)

<gwml2wc:casingMaterial xlink:href="http://www.sandre.eaufrance.fr/?urn=urn:sandre:donnees:154::CdElement:5:::referentiel:3.1:xml" xlink:title="PVC"/>

11.2.  Requirement class: GWML2-Main XML encoding

All xml elements under namespace http://www.opengis.net/gwml-main/2.2 must validate against the schema located at http://schemas.opengis.net/gwml/2.2/gwml2-main.xsd.

OM_Observation values, used as property values in GW_UnitFluidProperty must identify the instance of GW_HydrogeoUnit at the gwFluidBodyUnit end of the association between this feature and the GW_FluidProperty.

<?xml version="1.0" encoding="UTF-8"?>

<gwml2:GW_Aquifer gml:id="aq.1">

<gsmlb:geologicUnitType xlink:href="http://www.opengis.net/def/gwml/2.2/geologicunitype/aquifer_unit" xlink:title="Aquifer" xsi:type="gwml2:AquiferPropertyType"/>

<!-- (...) -->

<gwml2:gwUnitFluidBody>

<gwml2:GW_UnitFluidProperty>

<gwml2:gwYield>

<om:OM_Observation gml:id="aq.1.fp.1">

<om:phenomenonTime>

<gml:TimeInstant gml:id="aq.1.fp.1.ti.1">

<gml:timePosition>2015/7/28T12:00:00Z</gml:timePosition>

</gml:TimeInstant>

</om:phenomenonTime>

<!-- (...) -->

<om:featureOfInterest xlink:href="#aq.1" xlink:title="aquifer 1"/>

<!-- (...) -->

</om:OM_Observation>

</gwml2:gwYield>

<gwml2:gwUnitFluidBody xlink:href="http://resource.org/id/fluid-body/fb1" xlink:title="fluid body f1"/>

<gwml2:gwFluidBodyUnit xlink:href="#aq.1" xlink:title="aquifer 1"/>

</gwml2:GW_UnitFluidProperty>

</gwml2:gwUnitFluidBody>

</gwml2:GW_Aquifer>

OM_Observation values, used as property values in GW_UnitVoidProperty must identify the instance of GW_HydrogeoUnit at the gwVoidUnit end of the association between this feature and the GW_VoidProperty.

<?xml version="1.0" encoding="UTF-8"?>

<gwml2:GW_AquiferSystem gml:id="as.1">

<!-- (...) -->

<gwml2:gwUnitVoid>

<gwml2:GW_UnitVoidProperty gml:id="v1">

<gwml2:gwPorosity>

<om:OM_Observation gml:id="aq.1.fp.1">

<om:phenomenonTime>

<gml:TimeInstant gml:id="aq.1.fp.1.ti.1">

<gml:timePosition>2015/7/28T12:00:00Z</gml:timePosition>

</gml:TimeInstant>

</om:phenomenonTime>

<!-- (...) -->

<om:featureOfInterest xlink:href="#as.1" xlink:title="Aquifer System 1"/>

<!-- (...) -->

</om:OM_Observation>

</gwml2:gwPorosity>

<gwml2:gwUnitVoid xlink:href="http://www.opengis.net/def/nil/OGC/0/unknown" xlink:title="Unknown"/>

<gwml2:gwUnitVoid xlink:href="#as.1" xlink:title="Aquifer System 1"/>

</gwml2:GW_UnitVoidProperty>

</gwml2:gwUnitVoid>

</gwml2:GW_AquiferSystem>

11.3.  Requirement class: GWML2-Constituent XML encoding

All xml elements under namespace http://www.opengis.net/gwml-constituent/2.2 must validate with the schema located at http://schemas.opengis.net/gwml/2.2/gwml2-constituent.xsd.

11.4.  Requirement class: GWML2-Flow XML encoding

All xml elements under namespace http://www.opengis.net/gwml-flow/2.2 must validate with the schema located at http://schemas.opengis.net/gwml/2.2/gwml2-flow.xsd.

11.5.  Requirement class: GWML2-Well XML encoding

All xml elements under namespace http://www.opengis.net/gwml-well/2.2 must validate with the schema located at http://schemas.opengis.net/gwml/2.2/gwml2-well.xsd.

Well shall provide an origin elevation as a reference for relative positions along the borehole path.

Elevation geometries must have a relevant vertical 1D srsName.

Examples of reference elevations (measured using different methods); note, one of them is designated as the origin (‘reference’) elevation for relative positions:

<gwml2w:gwWellReferenceElevation>

<gwml2w:Elevation>

<gwml2w:elevation srsDimension="1" srsName="http://www.opengis.net/def/crs/EPSG/0/5711" uomLabels="m AHD">139.06</gwml2w:elevation>

<gwml2w:elevationAccuracy xlink:href="http://www.opengis.net/def/nil/OGC/0/unknown" xlink:title="unknown"/>

<gwml2w:elevationType xlink:href="http://www.bom.gov.au/water/groundwater/ngis/elevation-type/natural-ground-surface" xlink:title="natural ground surface"/>

<gwml2w:elevationMeasurementMethod xlink:href="http://www.bom.gov.au/water/groundwater/ngis/elevation-method/dem" xlink:title="Digital Elevation Model"/>

</gwml2w:Elevation>

</gwml2w:gwWellReferenceElevation>

<gwml2w:gwWellReferenceElevation>

<gwml2w:Elevation>

<gwml2w:elevation srsDimension="1" srsName="http://www.opengis.net/def/crs/EPSG/0/5711" uomLabels="m AHD">139.06</gwml2w:elevation>

<gwml2w:elevationAccuracy xlink:href="http://www.opengis.net/def/nil/OGC/0/unknown" xlink:title="unknown"/>

<gwml2w:elevationType xlink:href="http://resource.gwml.org/def/elevationType/originElevation" xlink:title="reference elevation"/>

<gwml2w:elevationMeasurementMethod xlink:href="http://www.bom.gov.au/water/groundwater/ngis/elevation-method/dem" xlink:title="Digital Elevation Model"/>

</gwml2w:Elevation>

</gwml2w:gwWellReferenceElevation>

<om:OM_Observation gml:id="feduni.borehole.observation.51409.44574.32328">

<gml:identifier codeSpace="http://www.ietf.org/rfc/rfc2616">http://groundwater.victoria.com.au/feature/observation/feduni.borehole.observation.51409.44574.32328</gml:identifier>

<om:phenomenonTime>

<gml:TimeInstant gml:id="feduni.borehole.observation.time.51409.44574">

<gml:timePosition>1997-07-14+12:00:00</gml:timePosition>

</gml:TimeInstant>

</om:phenomenonTime>

<om:resultTime xlink:href="#feduni.borehole.observation.time.51409.44574"/>

<om:procedure xlink:title="PUM"/>

<om:parameter>

<om:NamedValue>

<om:name xlink:href="http://www.opengis.net/def/param-name/GWML/2.2/fromDistance " xlink:title="from"/>

<om:value xsi:type="swe:QuantityPropertyType">

<swe:Quantity>

<swe:uom xlink:href="http://qudt.org/vocab/unit#Meter" xlink:title="metre"/>

<swe:value>10.5</swe:value>

</swe:Quantity>

</om:value>

</om:NamedValue>

</om:parameter>

<om:parameter>

<om:NamedValue>

<om:name xlink:href="http://www.opengis.net/def/param-name/GWML/2.2/toDistance " xlink:title="to"/>

<om:value xsi:type="swe:QuantityPropertyType">

<swe:Quantity>

<swe:uom xlink:href="http://qudt.org/vocab/unit#Meter" xlink:title="metre"/>

<swe:value>10.6</swe:value>

</swe:Quantity>

</om:value>

</om:NamedValue>

</om:parameter>

<om:parameter>

<om:NamedValue>

<om:name xlink:href="http://www.opengis.net/def/param-name/GWML/2.2/referenceGeometry " xlink:title="geometry"/>

<om:value xsi:type="gml:GeometryPropertyType" xlink:href="#feduni.borehole.51409.shape.1"/>

</om:NamedValue>

</om:parameter>

<om:observedProperty xlink:href="http://environment.data.gov.au/def/property/pH_water" xlink:title="pH"/>

<om:featureOfInterest xlink:href="#feduni.borehole.51409"/>

(...)

</om:OM_Observation>

<sam:relatedSamplingFeature>

<sam:SamplingFeatureComplex>

<sam:role xlink:href="http://resource.gwml.org/def/role/waterSample" xlink:title="Water sample"/>

<sam:relatedSamplingFeature>

<spec:SF_Specimen gml:id="spc.1">

(...)

<sam:parameter>

<om:NamedValue>

<om:name xlink:href="http://www.opengis.net/def/param-name/GWML/2.2/fromDistance " xlink:title="from"/>

<om:value xsi:type="swe:QuantityPropertyType">

<swe:Quantity>

<swe:uom xlink:href="http://www.opengis.net/def/uom/UCUM/0/m" xlink:title="metre" code="m"/>

<swe:value>8.12</swe:value>

</swe:Quantity>

</om:value>

</om:NamedValue>

</sam:parameter>

<sam:parameter>

<om:NamedValue>

<om:name xlink:href="http://www.opengis.net/def/param-name/GWML/2.2/toDistance" xlink:title="to"/>

<om:value xsi:type="swe:QuantityPropertyType">

<swe:Quantity>

< swe:uom xlink:href="http://www.opengis.net/def/uom/UCUM/0/m" xlink:title="metre" code="m"/>

<swe:value>8.4</swe:value>

</swe:Quantity>

</om:value>

</om:NamedValue>

</sam:parameter>

<sam:parameter>

<om:NamedValue>

<om:name xlink:href="http://www.opengis.net/def/param-name/GWML/2.2/referenceGeometry " xlink:title="to"/>

<om:value xsi:type="gml:GeometryPropertyType" xlink:href="#well.path.1" />

</om:NamedValue>

</sam:parameter>

(...)

</spec:SF_Specimen>

</sam:relatedSamplingFeature>

</sam:SamplingFeatureComplex>

</sam:relatedSamplingFeature>

<gwml2w:gwSiteReferenceElevation>

<gwml2w:Elevation>

<gwml2w:elevation srsName="http://www.opengis.net/def/crs/EPSG/0/5711" uomLabels="m AHD" srsDimension="1">523.27</gwml2w:elevation>

<gwml2w:elevationAccuracy xlink:href="http://www.opengis.net/def/nil/OGC/0/unknown" xlink:title="unknown"/>

<gwml2w:elevationType xlink:title="Relative Level Natural Surface"/>

<gwml2w:elevationMeasurementMethod xlink:href="http://www.opengis.net/def/nil/OGC/0/unknown" nilReason="unknown" xlink:title="unknown"/>

</gwml2w:Elevation>

</gwml2w:gwSiteReferenceElevation>

11.6.  Geology Log (GW_GeologicLogCoverage)

This standard forbids the use of relatedObservation to link a GW_Well to a GW_GeologyLog, the property gwWellGeology must be used.

The geologic log is encoded as a GW_GeologyLogCoverage.

The fromDepth value must be less than or equal to the toDepth value.

<gwml2w:GW_GeologyLogCoverage gml:id="borehole.INDIANA.USGS.403836085374401.lithology.coverage">

<gwml2w:element>

<gwml2w:LogValue>

<gwml2w:fromDepth>

<swe:Quantity>

<swe:uom xlink:href="http://qudt.org/vocab/unit/FT" xlink:title="foot" code="ft"/>

<swe:value>0</swe:value>

</swe:Quantity>

</gwml2w:fromDepth>

<gwml2w:toDepth>

<swe:Quantity>

<swe:uom xlink:href="http://qudt.org/vocab/unit/FT" xlink:title="foot" code="ft"/>

<swe:value>9</swe:value>

</swe:Quantity>

</gwml2w:toDepth>

<gwml2w:value>

<swe:DataRecord definition="http://www.opengis.net/def/gwml/2.2/datarecord/earthMaterial">

<swe:field name="major_lithology">

<swe:Category definition="http://www.opengis.net/def/gwml/2.0/observedProperty/earthMaterial">

<swe:identifier>http://cida.usgs.gov/groundwater/def/lithology/CLAY</swe:identifier>

<swe:value>CLAY</swe:value>

</swe:Category>

</swe:field>

<swe:field name="lithology-description">

<swe:Category definition="http://www.opengis.net/def/gwml/2.0/observedProperty/earthMaterial">

<swe:value>BROWN</swe:value>

</swe:Category>

</swe:field>

</swe:DataRecord>

</gwml2w:value>

</gwml2w:LogValue>

</gwml2w:element>

</gwml2w:GW_GeologyLogCoverage>

11.7.  GeologicLog (DataArray)

Example of a DataArray Geologic Log encoding (XML encoding).

<om:result>

<swe:DataArray definition="http://www.opengis.net/def/gwml/2.0/coverage/geologyLog">

<swe:elementCount>

<swe:Count>

<swe:value>4</swe:value>

</swe:Count>

</swe:elementCount>

<swe:elementType name="LogValue">

<!-- row is the name of each row -->

<swe:DataRecord definition="http://www.opengis.net/def/gwml/2.0/datarecord/earthMaterial" id="le.1">

<swe:field name="from">

<!-- name of the column -->

<swe:Quantity definition="http://www.opengis.net/def/gwml/2.2/observedProperty/fromDepth">

<swe:uom xlink:href="http://qudt.org/vocab/unit/M" xlink:title="m"/>

</swe:Quantity>

</swe:field>

<swe:field name="to">

<swe:Quantity definition="http://www.opengis.net/def/gwml/2.2/observedProperty/toDepth">

<swe:uom xlink:href="http://qudt.org/vocab/unit/M" xlink:title="m"/>

</swe:Quantity>

</swe:field>

<swe:field name="lithology">

<swe:Category definition="http://www.opengis.net/def/gwml/2.0/observedProperty/earthMaterial">

<swe:codeSpace xlink:href="http://resource.geosciml.org/classifierscheme/cgi/201211/simplelithology" xlink:title="Simple lithology"/>

</swe:Category>

</swe:field>

</swe:DataRecord>

</swe:elementType>

<swe:encoding>

<swe:XMLEncoding/>

</swe:encoding>

<swe:values xmlns:d="http://www.opengis.net/def/gwml/2.0/coverage/geologyLog">

<d:LogValue>

<d:from>0.0</d:from>

<d:to>0.30</d:to>

<d:lithology>Soil</d:lithology>

</d:LogValue>

<d:LogValue>

<d:from>0.30</d:from>

<d:to>4.27</d:to>

<d:lithology>Clay</d:lithology>

</d:LogValue>

<d:LogValue>

<d:from>4.27</d:from>

<d:to>9.14</d:to>

<d:lithology>Till</d:lithology>

</d:LogValue>

<d:LogValue>

<d:from>9.14</d:from>

<d:to>11.58</d:to>

<d:lithology>Gravel</d:lithology>

</d:LogValue>

</swe:values>

</swe:DataArray>

</om:result>

Alternative encoding using Text block encoding (instead of <swe:XMLEncoding/> above).

<swe:encoding>

<swe:TextEncoding blockSeparator="&#10;" tokenSeparator="," />

</swe:encoding>

<swe:values xmlns:d="http://www.opengis.net/def/gwml/2.0/coverage/geologyLog">

0.0,0.30,Soil

0.30,4.27,Clay

4.27,9.14,Till

9.14,11.58,Gravel

</swe:values>

11.8.  Requirement class: GWML2-WellConstruction XML encoding