Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Loading in …3
×
1 of 22

Information Viewpoints and Geoscience Service Architectures

1

Share

Download to read offline

Matching information meta-models and service interfaces
Presented at AGU, 2007-12-13

Related Books

Free with a 30 day trial from Scribd

See all

Information Viewpoints and Geoscience Service Architectures

  1. 1. Information Viewpoints and Geoscience Service Architectures Simon Cox Research Scientist 13 December 2007
  2. 2. Outline • Key viewpoints for earth science information • Feature, field, observation • The value-adding cycle • Mapping the viewpoints to OGC services and chains
  3. 3. Fields vs. objects classic geology: “feature” classic earth-observations: “field” or “coverage”
  4. 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. 5. Mapped features
  6. 6. Spatial function or field – “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. 7. Different cross-sections through same 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. 8. Assignment of property values • 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. 9. Generic pattern for observation 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. 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. 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. 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. 13. SOS getObservation getResult describeSensor getFeatureOfInterest Accessing data using the “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. 14. WFS/ SFS The “Sampling Feature Service” 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. 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. 16. WCS Accessing data using the “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. 17. Key points • Earth scientists 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. 18. Contact Us Phone: 1300 363 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. 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. 20. WFS Operation WFS-Client WFS GetCapabilities() Capabilities() DescribeFeatureType(FeatureType) XML Schema() GetFeature(FeatureType, FilterExpression) Feature Collection () GetGmlObject(ObjectID) Object() Transaction(...) TransactionResponse() Name: Package: Version: Author: WFS-S1 OWS 1.0 Simon Cox
  21. 21. Multiple interfaces to same 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. 22. Service profiles • WFS is “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

  • 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.
  • 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
  • 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.
  • 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.
  • 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
  • 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)
  • 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)
  • 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.
  • Going back to our tabular viewpoint: the result of a single observation populates a single field
  • 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 …
  • 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:
  • 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.
  • 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
  • It is often thought that “observations are the most primitive viewpoint”
    - Their results are used to populate feature-properties
  • In this scenario observation/results are used to compile discrete coverages.
  • Complexity can be obtained by chaining services
    SOA hides chains – the client only sees the immediate interface
  • 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
  • ×