Systems for data processing, anaylsis and representation

Allam, Mosaad; Plunkett, Gordon

Bibliographic data

Monograph

Persistent identifier:: 1067490280

Title:: Systems for data processing, anaylsis and representation

Sub title:: ISPRS Commission II Symposium : June 6 - 10, Ottawa, Canada

Scope:: 1 Online-Ressource (XX, 530 Seiten)

Year of publication:: 1994

Place of publication:: Ottawa

Publisher of the original:: The Surveys, Mapping and Remote Sensing, Natural Resources Canada

Identifier (digital):: 1067490280

Illustration:: Illustrationen

Signature of the source:: ZS 312(30,2)

Language:: English

Additional Notes:: Erscheinungsdatum des Originals ist aus dem Copyrightjahr ermittelt.

Usage licence:: Attribution 4.0 International (CC BY 4.0)

Editor:: Allam, Mosaad; Plunkett, Gordon

Corporations:: Symposium Systems for Data Processing, Analysis and Representation, 1994, Ottawa; International Society for Photogrammetry and Remote Sensing; International Society for Photogrammetry and Remote Sensing, Commission Instrumentation for Data Reduction and Analysis; Kanada, Surveys, Mapping and Remote Sensing Sector

Adapter:: Symposium Systems for Data Processing, Analysis and Representation, 1994, Ottawa; International Society for Photogrammetry and Remote Sensing; International Society for Photogrammetry and Remote Sensing, Commission Instrumentation for Data Reduction and Analysis; Kanada, Surveys, Mapping and Remote Sensing Sector

Founder of work:: Symposium Systems for Data Processing, Analysis and Representation, 1994, Ottawa; International Society for Photogrammetry and Remote Sensing; International Society for Photogrammetry and Remote Sensing, Commission Instrumentation for Data Reduction and Analysis; Kanada, Surveys, Mapping and Remote Sensing Sector

Other corporate:: Symposium Systems for Data Processing, Analysis and Representation, 1994, Ottawa; International Society for Photogrammetry and Remote Sensing; International Society for Photogrammetry and Remote Sensing, Commission Instrumentation for Data Reduction and Analysis; Kanada, Surveys, Mapping and Remote Sensing Sector

Publisher of the digital copy:: Technische Informationsbibliothek Hannover

Place of publication of the digital copy:: Hannover

Year of publication of the original:: 2019

Document type:: Monograph

Collection:: Earth sciences

Chapter

Title:: [Monday, June 6, 1994]

Document type:: Monograph

Structure type:: Chapter

Chapter

Title:: [Session B-1 WG II/3 - Technologies for Large Volumes of Spatial Data - Part A]

Document type:: Monograph

Structure type:: Chapter

Chapter

Title:: DEFINING THE ARCHITECTURAL DEVELOPMENT OF EOSDIS TO FACILITATE EXTENSION TO A WIDER DATA INFORMATION SYSTEM Mark Elkington, Richard Meyer and Gail McConaughy

Document type:: Monograph

Structure type:: Chapter

3.1 Intersite Architecture The intersite architecture is necessary to connect the services offered by providers to needs expressed by users in terms of requests to the system. Three classes of software component are envisaged for this layer: Advertising Service: The services offered by providers on the network need to be advertised to users. The advertising service is used by other components in the intersite architecture to perform their function. Request Broker Service: This service performs the matching between a user request and the services offered. In the many cases the user (e.g., a process) may have specified the service to be connected to, in others the broker will have to parse a ‘request description’ and use the advertising service to establish which services could satisfy the request. The request broking activity might involve user interaction. Distributed Information Manager : Where multiple sites are needed to resolve a request then an Inter-site Search Service is required to manage the process. The service will break up the query if necessary and generate a plan containing sub-requests which will be processed at individual sites. The sub-requests will generally be characterized by queries and operations, where an operation is usually some manipulation of results to provide output in the form or context requested by the user. The optimization of the division of a user request into a request plan is a difficult problem and in the short-term might involve the user in the planning process. An example of the use of the Distributed Information Manager to handle a coincident, content-based search is shown in Figure 2. In this case, the request is divided into three sub-requests: a query is made on the TOMS binned product to extract an ozone mask of the ozone hole for the required date, the mask is transferred to the second service provider which extracts cloud and sea-ice free fragments of the binned phytoplankton concentration product derived from Sea-WiFS data, which are then mosaiced on a separate compute server to form a single multi-date concentration map. Clearly this is not a trivial problem, and represents the vision of what should be possible in the future rather than what can immediately be developed. Issues such as optimization of the query plan, incompatibility of vocabularies, etc., all need to be addressed before such a vision is achievable. However there are clear evolutionary steps on the way to the vision, each of which give the user more support for resolving science questions. The purpose of the intersite architecture is to enable this evolution without a need to leave the architecture framework. What is the distribution of Phytoplankton Concentration underneath the ozone hole in the ice-free ocean for dates nearest October 15, 1995 Request phytoplankton concentration map masked for sea-ice and cloud (values tagged with date) Fig 2. The main issues related to the development of these three intersite components are related to vocabulary management and mapping, service and client incompatibility management and support for multi-protocol access to a dataset. These issues are considered further in NASA, 1994a. The interoperability layer assumes that each of its services can be distributed. There will probably be more than one example of a request broker or distributed information manager. They can differ in the scope of their capabilities or TOMS (Dobson threshold,dates) patial intersect with Ozone Hole TOMS [Level 3 binned product] Ozone Hole Mask SeaWiFsS (chlorophyll, dates, SeaWiFS [Level 3 binned product] mask)) Cloud-free and Sea- Ice free fragments combine cloud-free and ice- free values into distribution Example - Use of Inter-Site Request Agent to Resolve Coincident Search to which services and providers they give access; that is, intersite services can themselves be heterogeneous. For example, a distributed information manager might provide relatively basic inter-site request capability across a wide range of services, or more sophisticated capabilities over a smaller subset. 34 3.2. Pro Arc Each prov managemer community, a service wi site, but it access data data passed The main provider ser this section e autono e adverti * Support * Support service * Support e the role Provider sit and manag political anc of how the part of the : the site offe externally. provider arc Sites adveri are not adve The adverti: within the i the service essentially e a provider s can refer to Data Pi

Access restriction

Copyright

fullscreen: Systems for data processing, anaylsis and representation

Monograph

Chapter

Chapter

Chapter

Table of contents

Cite and reuse

Monograph

Chapter

Image

Image fragment

Citation links

Citation recommendation