Namespace is http://xmlns.geosciml.org/geosciml-portrayal/1.0
GeoSciML-Portrayal was developed to provide a simple feature schema to deliver map unit, contact, and shear displacement structure (fault and ductile shear zone) descriptions in web map services that include text information for consumption by human users, identifiers for standard age and lithology classifiers that enable simple filtering and interoperable portrayal using SLD, a URI that provides a binding to a full GeoSciML feature element if available, and a symbol identifier field to enable a single user-defined symbolization scheme in each map service (that could be further modified by application of other SLD files using the same symbol field). Most WMS implementations make deployment of WFS service using the same schema as a WMS service a simple thing, and binding the simple feature WMS and WFS allows clients to acquire basic text geologic feature descriptions that can be used in web-mapping applications to construct custom legends. Binding with full GeoSciML features allows the portrayal scheme to be used in a map browsing and query interface to identify and select features for further processing that can be acquired as highly, structured, information-rich complex GML features.
The GeoSciML Portrayal schema standardizes the interaction (request/response formats) with layer-based map services. It is best thought of as a view of GeoSciML data that denormalizes the data and concatenates complex property values into single, human-readable, labels and returns single, representative, values from controlled vocabularies for properties multi-valued properties that can be used when generating thematic maps, or portrayals, of the data.
It is separate to, but harmonized with, GeoSciML and conforms to the level 0 of the Simple Features Profile for GML (OGC 06-049). This profile requires that each feature include a gml:id attribute. According to the GML specification, this identifier must be an alphanumeric string that has an alphabet letter as its first character. The simple features profile also supports only a limited subset of possible GML geometry types that may be used to describe feature geographic location and shape. For the purposes of GeoSciML simple features, these include gml:Point, gml:LineString, gml:Curve, gml:Polygon, gml:Surface, gml:MultiPoint, gml:MultiCurve, gml:MultiSurface and multi-geometry types consisting of collections of these base types.
GSML portrayal features area analogous to GeoSciML mapped features, with additional text attributes for human consumption, a flatted-relation view of the age, and assignment to a single lithology. The portray scheme consists of 'free-text' fields and identifier fields. In robust services the free-text fields will contain well-structured summaries of complex GeoSciML data in a format suitable for reading by the intended users. Identifier fields should contain identifiers for concepts in a controlled vocabulary (for example CGI Simple Lithology) that specify representative thematic properties. Inclusion of these standardized identifiers enables interoperability across services. Ideally these should be URIs that can be dereferenced to obtain machine-processable representations of the identified concepts. In addition, each feature includes an identifier for a specification that can be dereferenced to obtain a GeoSciML encoded description of the feature. This property is equivalent to the specification association from MappedFeature
in the full GeoSciML model.
- 17 Nov 2011
Model and XSD Location
Accompanying discussion is at GeoSciMLPortrayalViewModelDiscussion
- Modelled using HollowWorld for consistency with GeoSciML modelling practices.
- However, because this is a presentation model the order of attributes has been based on the order in which they should appear to a user - labels first, then URI values.
- As a result the modelling approach has not used inheritance as this would over-ride that ordering, presenting shared attributes first.
- The gsmltv:identifer, gsmltv:name and gsmtv:description attributes have been defined, instead of using their GML equivalents, as a concession to the inability of a number of target WMS applications to handle multiple namespaces in a configuration.
Example Web Feature Services
- 18 Aug 2011
Version 2.0 proposals
- 20 Sep 2012
The following is a record of email discussions in November 2012 regarding adding BoreholeView to GeoSciML-Portrayal:
Geoscience Australia would like to try and formalize a Borehole simple feature WFS and WMS standard, similar to GeologicUnitView, ContactView, and ShearDisplacementStructureView in GeoSciML-Portrayal v2.
I have attached a proposed structure, based on the existing xxxView classes and work done in the AuScope
project and at ESRI earlier this year.
Ollie Raymond - 5 Nov 2012
Having uom as a field is a real pain for users. Every filter or SLD must take this into account because it implies there can be mixed uom.
This is annoying:
(boreholeLength > 10 AND boreholeLength_uom = 'm')
(boreholeLength > 32.42 AND boreholeLength_uom = 'ft.')
It gets even worse when you need to combine with other uom because it becomes a n x m problem.
I know, provider will stick to a single unit. But if it does, why this field ? just document what uom is used somewhere else (like how you documented inclinationType) and keep them consistent (positionalAccuracy must be in meter if depth and elevation are in meter)
my two cents...
Eric Boisvert – 6 Nov 2012
Personally, I tend to agree with you. I did this to reflect the gdb model we came up with in Redlands, but I am ambivalent about their inclusion. I’d be happy to drop the UOM fields if others agree. It forces a provider to provide only one type of unit, but that is probably not a bad thing.
Ollie Raymond - 7 Nov 2012
IMHO uom is already logically part of the data model (part of Measure) - and the use of a separate attribute in the XML, or assumption of a constant value, is an encoding concern – noting that encodings may be lossy with respect to the model, so it’s ok to lose per-value UoM
So, should probably lose it from the model anyway. In the water space we’ve been working through issues around data products needing to restrict content of such encoding artefacts. Looks like we’ll need feature type catalogs with quite explicit information around how model elements are mapped to particular encodings
Rob Atkinson - 7 Nov 2012
The need for the UOM properties depends on what use case the Simple Feature view of a borehole meets. This is not clear from Ollie’s email.
I interpret the need for it as a simple response to a WMS query. I don’t think the model would be expected to meet the WFS filters we typically envisage for complex WFS (e.g. “Show all Boreholes where boreholeLength > X metres”).
As such, having the UOM properties is informative for use in say a GIS, but not designed for filtering.
Whether we use Eric’s solution or leave them in the model, what and how the properties are intended to be used will need to be documented:
1. Eric’s solution is to document the UOMs somewhere and indicate these must be followed to conform with the CGI profile; or
2. Document that UOM properties are designed for informative purposes and the simple WFS is unlikely to support complex across service queries.
Having two models, a simplified and complete model, is always going to cause tension between the simple model being ‘over-extended’ and the complex model being ‘over-simplified’. Documenting the intention of each model may help to avoid this.
Bruce Simons - 7 Nov 2012
You raise good points Bruce. A WMS/SF-WFS portrayal model is primarily for basic SLD portrayal schemes and human-readable information, not serious querying. That’s what the complex WFS is for.
1. I note that we have positionalAccuracy (characterString) without uom in our other portrayal view classes. Is it envisaged that this field was ever meant to be anything more than informative? There is no control over what a data provider puts in that field (eg, “250”, “250 metres”, “between 100 and 500 metres”). So it would seem that we envisaged these positionalAccuracy attributes to be informative, not seriously queried.
2. Testing a CGI profile of “always use metres for borehole length and positional accuracy” would be difficult (impossible?) in the absence of uom fields - where would a service profile tester like Schematron look for this information to test? GetCaps
? Where would a client look in a metadata document for “borehole length uom” information?
3. Rob, uom is part of the gml:Measure or swe:Quantity elements in the real WFS world, but our basic portrayal models are trying to use just basic strings, numbers, and uri’s for attribute types. So any multi-part elements like Measure or Quantity need to either be broken down into their component bits of “value” (eg, 25.4) + “uom” (eg, metres), or be concatenated into a text string (eg, “25.4 metres”).
4. The question we need to answer for Borehole portrayal is on which fields in the model would we want to use a SLD filter, and thus require some content control (ie, similar to representativeLithology and representativeAge for GeologicUnits
). Potential fields might be:
Ollie Raymond - 7 Nov 2012
Good point indeed Bruce.
Eric Boisvert - 7 Nov 2012
I’d avoid content control on any field.
The simple feature view is so data providers have an easy entry to deliver whatever happens to be in their database (“25.4”, “25.4m”, “25.4 metres”, ...). The URI to the fully described data (WFS) is the important field we should be aiming to get populated (i.e. to set-up fully described data services that can be filtered).
My ¼ of 8.
Bruce Simons - 7 Nov 2012
For the simple feature models we’ve been developing for the Geothermal system, the issue of UOM has been an ongoing debate. The dust is starting to settle around the view that since the point of the data delivery content model is to make client consumption of the data as simple as we can, measured quantities should use prescribed units, and we put the UOM in the field name to make this clear, thus depth_ft, maxTemperature_F. If there is a perceived need to allow multiple systems, then there should be another field e.g a depth_ft field and a depth_m field. The data provider takes care of units conversion.
If you want to take the borehole data and plots 2.5-D ‘sticks’ using say ArcScene
, you have to have one column that uses the same units all the way through. If there is a value field and a uom field, the client has to process the data from the service response to check that all units are consistent before doing anything
So I’d vote for boreholeLength_m
elevation_m, with the convention that the elevation reported is the elevation from which depth is measured (GL, KB, DF…)
postionalAccuracy in the other portrayal models is free text. The logic is that it’s not something someone will want to query or filter on, and it could be reported in lots of different ways and still be useful for evaluating the data in detail.
Just for entertainment value, I’ve attached the excel workbook for the content model we’re using for the geothermal data system. The primary use case for the ‘well header’ service is as an index to data linked to the well, with links in a text blob called ‘relatedResource’. We included some engineering stuff (casing, hole diameter) that doesn’t get populated very often and I’d probably leave out in future versions (with a separate service for borehole engineering data). There is a formation at TD, and true vertical depth. Based on comments we’ve been getting, adding a bottom hole X,Y location is looking like a good compromise to deal with deviated holes. Also have some silly extra location fields using the publich land survey system that is always used by drillers, and an optional UTM coordinate field. We have to consider what the practice is to deal with wells that have multiple wellbores….
Steve Richard - 7 Nov 2012
Thanks Steve, very informative.
Taking into account all the comments I have received, I have attached a v0.2 version of BoreholeView.
1. I have amended the attribute descriptions a bit, including some mention of relations of wells and wellbores (see https://www.ppdm.org/wiki/index.php/What_is_a_Well
2. “boreholeLength_m” and “elevation_m”. (No “uom” attributes.)
3. I have added a “parentBoreholeID” attribute to provide a link between parent wells and sidetracks.
4. I have added, tentatively, a “status” attribute. (“Status” is not currently in the GeoSciML Borehole model, but I would like it to be in the version 4, so I have added it here. “Status” is used in borehole databases I have seen, and is in the PPDM model for wells.)
5. I have added an “any:lax” element to the end of the attribute list, similar to what we did for the view classes in GeoSciML-Portrayal v2.0, to allow for additional user-defined elements where they want to deliver more than the standard BoreholeView attributes.
|| Data Type
|| Unique identifier for the borehole
|| Name of the borehole
|| A text description of the borehole
|| The purpose for which the borehole was drilled. eg, mineral exploration, hydrocarbon exploration, hydrocarbon production, groundwater monitoring, geothermal, site investigation
|| The present status of the borehole (eg, abandoned, completed, proposed, suspended)
|| Indicates the drilling method(s) used for this borehole. eg, rotary air blast, auger, diamond core, air core
|| Organisation responsible for commissioning the borehole (as opposed to drilling the borehole)
|| The organisation responsible for drilling the borehole (as opposed to commissioning the borehole)
|| Date of the start of drilling (formatted as a gml:timePosition date. eg, 2012-03-17)
|| Date of the end of drilling (formatted as a gml:timePosition date. eg, 2012-03-28)
|| Indicates the position relative to ground surface where the borehole commenced. eg, open pit floor or wall, underground, natural ground surface
|| Indicates the type inclination of the borehole. eg, vertical, inclined up, inclined down, horizontal
|| Organisation that is custodian of the material recovered from the borehole
|| The "length" of a borehole, in metres, as determined by the data provider (ie, "length" may have different sources, like driller's measurement, logger's measurement, survey measurement)
|| Compromise approach to supply elevation, in metres, for borehole (ie, wellbore) origin location. This is to allow for legacy data without elevation information, and software that cannot process 3-D GM_Point. The SRS will be a one dimensional "vertical" SRS (e.g. EPSG code in the range 5600-5799).
|| Spatial reference system of the elevation value. Mandatory if elevation is populated
|| An estimate of the accuracy of the positioning of the borehole collar location
|| Description of the lineage of source data for this borehole
|| URI link to a full GeoSciML Borehole record if available
|| Unique identifier for a parent borehole (eg, a parent well of a sidetrack wellbore)
|| URI link to a metadata record for this borehole
|| Identifier for a symbol from standard (locally or community defined) symbolization scheme for portrayal.
|| 2D location of the borehole (ie, wellbore) origin
|| An allowance for users to add any other informative attributes where appropriate
- BoreholeView proposal:
Ollie Raymond – 8 Nov 2012
As we have not yet officially published GeoSciML-Portrayal v2.0 publically at www.geosciml.org, would it be OK if we included the BoreholeView class in the official GeoSciML-Portrayal v2.0 release? This would greatly help some interoperability projects in Australia at least, in that they would not have to wait for GeoSciML v4 to be published to be able to use an official CGI simple features schema for boreholes.
Ollie Raymond - 14 February 2013