ENVISION

1. ENVISION developing a consensus on a ENVironmental Interoperable Spatial Information Open Network

2. Application example: Oil Spill Detection Future users& applications multiple providers ensure frequent coverage Oil Slick DB Oil Slick detection Cost Guard ESA: ERS/Envisat Data Sea Surface Movement Model Radarsat: Radarsat data Seaside resorts NASDA: JERS data Marine National Parks Sea Currents Wind Data Wave Data Airborne Radar

3. € Value-Adding Company: The Non-Business Case • Production Infrastructure Costs > sales • Shipment/Production times too slow to offer timely information I/FA Local Data Provider Satellite EO Data Provider develop & maintain custom interface develop & maintain custom interface I/FE Local Data Provider Interface C Interface D Satellite EO Data Provider Airborne EO Data Provider Satellite EO Data Provider

4. OpenGIS/Corba OpenGIS/WWW CIP IMS Required Data Provider Interfaces ?!? Data Provider Disaster Management Environment Oceanography Coastal Management Fishery Standard Interfaces Climatology Agriculture RAMSES Fire . . . Transport Geology Single Application Interfaces Application Sector Interfaces

5. The Value Adding Chain EO/GIS Data Provider EO/GIS VAC VAR Value Adding Companies Value-added Application Reseller Inventory Browse Inventory Inventory Algorithms Order Order Order Services On-line Archive User Services Interoperable Data and Service Bus Production Services Information Raw Data Semi-Finished Semi-Finished Raw Extraction / Raw Product Product Acquisition Product Product Product Assembly Retrieval Generation Generation Retrieval Archive

6. The Information Value Tower Application DataEnd Users High-Level Data End Users(User Application Centres) Low-Level Data End Users Interoperable Data & Services Bus

7. € € € € € € € The “Business” Scenario ApplicationEnd User Value-AddedApplicationReseller Value-Adding Companies Data Providers GIS/Map Data Satellite EO Data Airborne EO Data Local Data

8. The Protocol/Standards Jungle ccsds OAIS GILS ceos/cintex Z IMS esa/jrc CIP GELOS nasa GEO CORBA fgdc DCOM XML ISO/TC 211 OpenGIS SQL

9. Active Institutional Players at European ...

10. … and world-wide level

11. Infrastructures and Protocols

12. Conclusion on the ‘State-of-the-Art’ • heterogeneous interoperability ‘islands’ • frequently only Web-based access possible (no defined protocol) • frequently Z39.50 as underlying information technology (obsolete?) • many infrastructures only provide ‘directory’ function • ‘ordering’ and ‘on-line access’ usually not supported • where supported, no consideration of commercial security and European Data Policy requirements

13. Questions to be answered • Is a shared core between EO, GI and application domain possible ? • Who ‘drives’: EO, GI or applications ? • European or global ? • Commercial or ‘scientific’? • Single-Stop Shop or Service Federation ? • Light or Heavy Protocol ? • What standards and technologies shall we base on ? • What type of interfaces does a geospatial application require ? • What kind of services are required ?

14. Interfaces and Services required in an operational scenario of a geospatial application • No Web I/F, but stable and defined ‘protocol’, to be used as API • Data Sources are configured by human intervention: is Directory service required in an operational scenario ? • Inventory and On-line Data Access most important Services • Ordering of future Data Acquisitions important for Planning • Additional Services • ‘Push’ Services • ‘Data Sniffing’ • Data Mining • Support for GRID infrastructure TBC

15. Technology/Standards/Architecture • Easy-to-use modern mainstream technology: WWW, XML, Corba, (Z39.50 not ‘promotable’ to application builders) • ISO 19115 with OpenGIS WWW or CORBA profile as basis(most living initiatives have fed in, but application input is lacking) • ‘light’ standard based on WWW profile sufficient for application builders • heavy ‘academically complete’ solutions reserved to institutional data interchange • aim for a minimum common core based on a technology that allows simple domain-specific extensions (e.g. XML) TBC

16. ‘Commercial’ Issues • Big commercial providers are sensitive to have a direct interface to their customers • No ‘single-stop-shop’, but federated architecture allowing direct access of customers to data providers • Commercial accounting requirements (e.g. non-repudiation based on digital signature) may require change of user management from userid/password to private/public key approach • introduction of private/public key approach with professional certificate providers is an opportunity to allow the users to have a unique user identification for all providers. • Some doubt if URL synta is sufficent for requests TBC

17. European or Global ? • New global standards are not yet mature and fully suitable for Europe • ‘European standard’ approach eases consensus finding process(US agenda and speed might put the process at risk) • ‘European standard’ gives an advantage to the European Players within the European market • Satellite data are global • Some scientific problems require world-wide cooperation • ‘Global standard’ will ease export of application technology ‘Act European, Think Global’ or ‘Act Global, Think European’ ?

18. Final Thoughts • Application builders are waking up and demand that the consensus-finding process starts (May 2000, 1st IST concertation meeting on environment applications) • Avoid building completely separated or ‘closed’ infrastructures for EO, GI and application sectors • Application Community and Data Providers need to be better involved • Keep present that the EO value adding chain produces GI applications • High-Value GI applications require continuous information acquisition(in-situ, airborne or satellite-based) • GMES to be considered