Download to read offline
Uploaded bySimon Cox
Information Viewpoints and Geoscience Service Architectures
This document discusses three key viewpoints for earth science information: features, fields/coverages, and observations. It describes how these viewpoints can be mapped to OGC services and service chains. Features represent identifiable objects, fields/coverages represent the variation of a property across a domain, and observations provide estimates of feature property values. The viewpoints can be accessed through services like WFS, WCS, and SOS, and composed in different ways depending on the data and application needs.
More Related Content
Similar to Information Viewpoints and Geoscience Service Architectures
![Polymer [ बहुलक ] Chemistry Notes PDF - Irfanullah Mehar - JJ Sir Chemistry.pdf](https://cdn.slidesharecdn.com/ss_thumbnails/polymerchemistrynotespdf-irfanullahmehar-jjsirchemistry-260210172118-3f9b37f7-thumbnail.jpg?width=640&height=640&fit=bounds)
Information Viewpoints and Geoscience Service Architectures
- 1. Information Viewpoints andGeoscience Service Architectures Simon Cox Research Scientist 13 December 2007
- 2. Outline • Key viewpointsfor earth science information • Feature, field, observation • The value-adding cycle • Mapping the viewpoints to OGC services and chains
- 3. Fields vs. objects classicgeology: “feature” classic earth-observations: “field” or “coverage”
- 4. Conceptual object model:features • Digital object corresponding with identifiable, typed, object in the real world • mountain, road, specimen, event, tract, catchment, wetland, farm, bore, reach, property, license-area, station • Feature-type characterised by specific set of properties • Specimen • ID (name) • description • mass • processing details • sampling location • sampling time • related observation • material • …
- 5.
- 6. Spatial function orfield – “coverage” (x1,y1) (x2,y2) • Variation of a property in domain of interest • Property may be multi-component • Domain is often sampled on a grid • Domain extent is scoped by shape/lifetime of feature of interest • Range-type is scoped by type of feature-of-interest
- 7. Different cross-sections throughsame dataset Specimen Au (ppm) Cu-a (%) Cu-b (%) As (ppm) Sb (ppm) ABC-123 1.23 3.45 4.23 0.5 0.34 • A Row summarizes the properties of one feature • A Column = variation of a single property across a domain (i.e. set of locations)
- 8. Assignment of propertyvalues • For each field in the table the value is either i. asserted • E.g. name, owner, price, boundary (cadastral feature types) i. observed/estimated • E.g. colour, mass, shape (natural feature types) • i.e. error is of interest
- 9. Generic pattern forobservation metadata An Observation is an action whose result is an estimate of the value of some Property of the Feature-of-interest, obtained using a specified Procedure Feature-of-interest concept reconciles remote and in-situ observations
- 10. Three viewpoints: Feature,Coverage, Observation Specimen Au (ppm) Cu-a (%) Cu-b (%) As (ppm) Sb (ppm) ABC-123 1.23 3.45 4.23 0.5 0.34 • A Row gives properties of one feature • A Column = variation of a single property across a domain (i.e. set of locations) • A Cell reflects the result of a single observation
- 11. Value-adding chain • Observation/result •estimate of value of a property for a single specimen/station/location • data-capture, with metadata concerning procedure, operator, etc • Coverage • compilation of values of a single property across the domain of interest • data prepared for analysis/pattern detection • Feature • object having geometry & values of several different properties • 1. classified object, snapshot for transport • geological map elements • 2. object created by human activity, artefact of investigation • borehole, mine, specimen
- 12. OGC Service stack •Different information-types accessed using different interfaces • Maps – WMS • Features – WFS • Coverages – WCS • Observations – SOS • Each interface is composed of a “set of operations”
- 13. SOS getObservation getResult describeSensor getFeatureOfInterest Accessing data usingthe “Observation” viewpoint WFS/ Obs getFeature, type=Observation WCS getCoverage getCoverage (result) Sensor Register getRecordById WFS getFeature e.g. SOS::getResult == “convenience” interface for WCS
- 14. WFS/ SFS The “Sampling FeatureService” viewpoint WFSgetFeature WCS getCoverage getCoverage (property value) SOS getObservation Common data source getFeature (sampling Feature) getFeature (relatedObs/result value) getFeature (relatedObservation) getCoverage (result) Sensor Register getRecordById (procedure) getFeature (featureOfInterest) getObservation (relatedObs) getResult (property value)
- 15. WFS The “Domain Feature”viewpoint WCS getCoverage (property value) getFeature SOS getResult (property value) The “Observations are the most primitive” viewpoint #1 – observations are property-value-providers for features ??
- 16. WCS Accessing data usingthe “just the data” viewpoint WFS getFeature/geometry (domain exent) getCoverage SOS getResult (lots of ‘em) (range values) The “Observations are the most primitive” viewpoint #2 – observations are range-value-providers for coverages
- 17. Key points • Earthscientists use multiple viewpoints onto their data • These can be reconciled through a robust data model • Service interfaces to the different viewpoints can be composed in various ways, based on a simple set of OGC components
- 18. Contact Us Phone: 1300363 400 or +61 3 9545 2176 Email: enquiries@csiro.au Web: www.csiro.au Thank you Exploration & Mining Simon Cox Research Scientist Phone: 08 6436 8639 Email: Simon.Cox@csiro.au Web: www.seegrid.csiro.au
- 19. RockSample-A : Specimen DensityItA : Observation Density: Phenomenon Densitometry : ObservationProcedure 2610 kg/T : Measure 2006-11-23 : TM_Instant Leederv ille, WA : Location RockSample-B : Specimen DensityItB : Observation 2580 kg/T : Measure 2005-12-23 : TM_Instant West Leederville, WA :Location +time+result +procedure+observedProperty +featureOfInterest +samplingLocation +density +samplingLocation +time +procedure+observedProperty +featureOfInterest +result +density ProbeItA : Observation Material : Phenomenon Microprobe : Observ ationProcedure MineralDistribution :CV_Coverage 2006-11-24/2006-11-26 : TM_Period RockSample-A : Specimen Leederv ille, WA : Location +observedProperty +procedure +result +time +material +featureOfInterest +samplingLocation RockSample-A : Specimen 2610 kg/T : Measure Leederville, WA : Location +density +samplingLocation RockSample-A : Specimen DensityItA : Observ ation Density : Phenomenon Densitometry : ObservationProcedure 2610 kg/T : Measure 2006-11-23 : TM_Instant Leederville, WA : Location +featureOfInterest +observedProperty +procedure +result +density +time +samplingLocation RockSample-A : Specimen 2610 kg/T : Measure Leederville, WA : Location RockSample-B : Specimen 2580 kg/T : Measure West Leederville, WA :Location +density +samplingLocation +density +samplingLocation ProbeItA : Observation Material : Phenomenon Microprobe : Observ ationProcedure MineralDistribution :CV_Coverage 2006-11-24/2006-11-26 : TM_Period RockSample-A : Specimen DensityItA : Observation Density : Phenomenon Densitometry : ObservationProcedure 2610 kg/T : Measure 2006-11-23 : TM_Instant Leederv ille, WA : Location +procedure+observedProperty +result +time +featureOfInterest +material +featureOfInterest +observedProperty +procedure +result +density +time +samplingLocation MineralDistribution :CV_Cov erage RockSample-A : Specimen 2610 kg/T : Measure Leederville, WA : Location +material +density +samplingLocation Observations, features and coverages Feature summary Property-value evidence Multiple observations one feature, different properties: feature summary evidence A property-value may be a coverage Same property on multiple samples is a another kind of coverage Multiple observations different features, one property: coverage evidence
- 20. WFS Operation WFS-Client WFS GetCapabilities() Capabilities() DescribeFeatureType(FeatureType) XMLSchema() GetFeature(FeatureType, FilterExpression) Feature Collection () GetGmlObject(ObjectID) Object() Transaction(...) TransactionResponse() Name: Package: Version: Author: WFS-S1 OWS 1.0 Simon Cox
- 21. Multiple interfaces tosame information? • SOS::GetObservation == WFS::GetFeature(type=Observation) • SOS::GetResult == WCS::GetCoverage • SOS::DescribeSensor == WFS::GetFeature(type=Sensor) or CSW::GetRecordById • “Profile” generic operations • fix one or more parameters
- 22. Service profiles • WFSis “soft-typed” • Any feature-type • Query scoped by response model • Strong-typed service = profile of generic service-type • Limit response model • SOS = WFS(feature-type=Observation) • GeoSciML-service = WFS(feature-type=gsml:*) • Spectral Data Service = WCS(domain=wavelength) • Limit query model • Queriable properties = subset of response model • Conformance-levels? • Level 0 – spatial queries only • Level 1 – only these props • Level 2 – complete WFS
Editor's Notes
- #2 AB: When dealing with earth science data, different use-cases may require different views of the underlying information. At a basic level, data generation and initial assimilation generally involves dealing with event-based types and different granularity than data organized for processing, often on a grid, while further downstream the desired result of most scientific exercises is an interpretation view characterized by high semantic content and small size. The stages often map reasonably well onto the basic meta-models of Observation, Coverage and Feature provided by the OGC/ISO 19100 framework, and the matching service interfaces (SOS, WCS, WFS). However, on closer inspection of common use-cases, the vision of the Observation viewpoint as most primitive and the Feature viewpoint as most evolved does not consistently stand up. Furthermore, common discovery and access routes may involve traversing associations between instances using different viewpoints. These considerations lead to information (and thus service) composition arrangements with a variety of data flows. For example, an observation service may obtain its result data from a coverage service, while another coverage may be composed from multiple atomic observations; observations are often discovered through their association with a sampling-feature such as a cruise or borehole, or with a sensor platform such as a specific satellite whose description is available from a strongly governed register. The relationship of service instances to data stores (or other sources) is also not one-to-one, as multiple views of the same data are frequently involved. Useful service profiles may thus imply specific service architectures, and requirement to transform between viewpoints becomes almost ubiquitous. Adherence to a sound underlying meta-model for both data and services is a key enabler.
- #4 In the geosciences, we are very familiar with two key viewpoints: Geophysicists and “earth scientists” tend to work with physical properties, fields Geologists focus more on entities, objects, features
- #5 The “feature model” is defined formally in ISO 19101 & ISO 19109. Feature-types have semantically meaningful names – not “point line or polygon”. In this example the “specimen” feature type is characterized by the properties “mass, processing details, sampling location, material” etc For a given feature, the values of the properties are mainly constant (perhaps not material, in this case) -------------- Identifiable object and its set of properties each property has a constant value for the feature properties may be associations - value of property may be another object e.g. geometry Spatial properties are conceptually equivalent to other properties multiple geometry properties may be allowed (why?) GML is primarily concerned with representing Features. The hierarchical XML structure accommodates this quite naturally.
- #6 Features are often portrayed on maps. The symbolization typically uses 2 or 3 or 4 properties, e.g. Geometry (position/shape) Type (glyph, symbol) Some other property(s) (symbol colour, size) ---------- Many people experienced with digital spatial data management systems make the conversion to "points, lines and polygons" automatically. Note, however, that this is a geometry-centric abstraction, which may not be strongly related to the conceptual significance of the data. Since most features have a geometry, it may be convenient to sort and manage features with properties of the same geometry-type together - e.g. this allows indexing to be optimised. However, the geometry-centric approach is best thought of as an implementation viewpoint.
- #7 On the other hand, the “physical” view of the world often emphasizes the variation-of-a-property within the domain of interest. Domain may be spatial or temporal (time-series) In fact, coherence with the feature-model implies that the coverage domain is actually scoped to a feature, whose type carries the property --------------------- variation of a property within a spatio-temporal domain images, fields tenuous relationship with ESRI coverage ... typically used as evidence for features various implementations: function, functional map grid, time-series classified map position-value pairs
- #8 The feature and coverage viewpoints can also be reconciled by thinking about the “traditional” tabular presentation of data: e.g. a table of specimens with values for a suite of analytes Row describes a single specimen Column describes the variation across all the specimens (i.e. a coverage whose domain is the set-of-specimens, or perhaps is the tract which is sampled by the suite of specimens)
- #9 Property values may be assigned in two ways: By assertion – there is no error in the value, it is assigned by a rule By observation – the value is an “estimate” obtained by application of some procedure Corollary: the error in the estimate is likely to be of interest (quality control)
- #10 The organization of observation-metadata follows a common pattern. For example, consider the statement “The 7th banana weighed 270gm on the kitchen scales this morning” – a scalar measurement This can be expressed using the following object model. (click) The generalized version of this is the following sentence: (click) “An Observation is an action whose result is an estimate of the value of some Property of the Feature-of-interest, obtained using a specified Procedure” It generality is illustrated by the fact that the same pattern also matches examples like: (click) “Specimen H69 was determined on 1999-01-14 by Amy Bachrach to be of the species Eucalyptus Caesia” – a category observation (click) “IR image ASgh67c of Camp Iota was obtained by Aster in 2003” – an image or field aquisition (click) “The simulation run on 2004-09-09 indicated a pressure reduction of 4 MPa in geologic unit Q at 600 Ma” – a simulation i.e. this model is able to manage “observation metadata” across many (all?) disciplines. - AGU Fall 2006 presentation.
- #11 Going back to our tabular viewpoint: the result of a single observation populates a single field
- #12 Considering these viewpoints within the “data processing” chain – (click) Observations are primarily concerned with data acquisition (click) Coverages are often the result of compiling a set of observation results on “atomic” features (pixels, specimens, etc), so they are ready for signal processing, or pattern or anomaly detection (click) Natural- (or “domain-”) features are detected macro-objects, with a set of properties that summarizes their state Or sampling-features are the basis for observations …
- #13 Open Geospatial Consortium interface definitions provide access to these viewpoints. The standard interfaces are WMS for maps, WFS for features, WCS for coverages (fields) and SOS for observations. However, thinking about the fact that the information viewpoints are merely cross-sections through the information soup, The “standard” interfaces can be understood as “facades” or “brokers” to services providing components of the view:
- #14 For example (click) SOS presents the getObservation, getResult, describeSensor and getFeatureOfInterest operations. (click) SOS::getObservation is actually a specialized WFS::getFeature request – with feature type=Observation SOS:getResult will often retrieve information that is also presented by a coverage service SOS:describeSensor should typically be passed through as a request to a sensor registry SOS:getFeatureOfInterest is another WFS:getFeature request – this time probably to a different WFS datasource. (click) of course the WFS/Observations service would also chain to the coverage service to get the result element (the SOS component is a service and a WFS/WCS/Registry client) (click) A general expectation of the ultimate data sources is indicated by the “disks” (click) and an observation service may be caching data from a live feed.
- #15 But, another decomposition of the problem could be oriented around the “sampling feature” viewpoint. This organizes observations according to the mission or sampling regime. (click) Sampling Feature Service is a (hypothetical) specialized WFS. (click) requests for the sampling-feature itself would be passed through to a more primitive WFS requests for the relatedObservation are passed through to an SOS Requests for the observation/result is passed through to a WCS (The WFS component is a service and a WFS/WCS/SOS client) (click, click) Various other calls between the components are required to populate the data instances
- #16 It is often thought that “observations are the most primitive viewpoint” - Their results are used to populate feature-properties
- #17 In this scenario observation/results are used to compile discrete coverages.
- #18 Complexity can be obtained by chaining services SOA hides chains – the client only sees the immediate interface
- #20 Under certain conditions of homogeneity, the information in an observation collection may be captured in a compound observation types, as described in sub-clause 6.5. All member observations must have the same responsible party If the member observations have the same feature of interest the same event time different observed properties this may be represented as a ComplexObservation (sub-clause 6.5.2) whose observed property compounds the individual properties. Examples: a multi-band spectral radiance; a compound observable like “weather”; a tensor property like earthquake moment. If the member observations have the same feature of interest the same observed property different event times this may be represented as a TimeSeriesObservation (sub-clause 6.5.3) whose event time is the period encompassing all the member times. Examples: air-temperature at a weather station; water quality observations at a water monitoring station. If the member observations have the same observed property the same event time features of interest that comprise elements of a larger feature this may be represented as a DiscreteCoverageObservation (sub-clause 6.5.3) whose feature of interest is the larger feature and within which the result elements’ geometry describe its spatio-temporal decomposition. Example: the feature of interest is an array of stations, which may be on a grid; or an array of pixels, which comprise a scene