1. Karel Charvat Help Service Remote Sensing Social Validation of INSPIRE Annex III Data Structures in EU Habitats (27th of June 16:00 room Fintry)

2. Content Lessons learn from user communities Why harmonize data? For whom are metadata important From INSPIRE to Habitats Architecture Reference laboratory as prove of concept Pilots testbeds

3. Lessons learn from user communities NATURAL RESOURCE MGMT WILD SALMON MONITORING LA PALMA MARINE RESERVE ECO- TOURISM NAT’L POLICY HIKING TRIP PLANNER CZECH NAT’L FOREST PROGRAMME SORIA NATURAL RESERVE SHEEP & GOAT HERD MANAGEMENT ECON ACTIVITY AT COASTAL BENTHIC HAB. ECONOMIC ACTIVITIES

4. Lessons learn from user communities Analysis of use cases Generalization How communities request could influence architecture design, data models and metadata requirements

5. Analysis of use cases

6. Analysis of use cases

7. Analysis of use cases

8. Analysis of use cases – data usage Regional data used regionally Global data used regionally Regional data used cross regionally Regional data used globally Global data used globally

9. Regional data used regionally There is not direct requirement for INSPIRE data models Local data models could be wider Local data models reflect regional needs and also regional decision processes If data are not shared outside of region (but in many cases it is necessary), in principle global standards are not needed Standards are needed in case of more data suppliers, to guarantee data consistence

10. Regional data used regionally

11. Global data used regionally Global data are in some content something like de facto standards In some cases it is necessary to be possible transform data into such models, which is required by regional decision processes The global model has to cover regional decision needs (GMES case for example) Question is, if this transformation will be done on fly or offline Language problem

12. Example FMI data used locally

13. Example FMI data used locally

14. Regional data used cross regionally There is already very visible problem of data harmonization, this problem is higher, in the case of cross boarder regions In many cases, like tourism we need deal not with one or more separate data theme, but with complex mixture of themes related to INSPIRE In some application cases model could be broader then INSPIRE definition Language problem

15. Tourist example

16. Regional data used globally Probably most relevant cases for INSPIRE data model The idea is to combine local data sets into one data set The regional data has to be transformed (in many cases simplified) into global model Relevant cases are tourism, transport, education, research, environment protection, risk management, strategic decision Language problem

17. Regional data used globally

18. Regional data used globally

19. Global data used globally Global data are standard or de facto standard. It is expected, that in the case of data of public sector, this data will be already in INSPIRE models It could happened, that this models has to be transformed on the base of needs of concrete application area. Transformation could be based also on Feature Encoding or SLD.

20. Global data used globally

21. Global data used globally

23. Just commonelementsandattributes

24. To enableanextensionofmodels

25. To interconnectHabitatsthemes

27. methodologyusedforINSPIRE data specification,

28. internationalstandards

29. analysesof data modelsforselectedthemesused in single countriesparticipating on Habitatsproject

30. resultsofprevioustasksofHabitatsprojectFeature Catalogues INSPIREtesting TRAGSATEC IMCS HSRS TU Graz

31. INSPIRE Data Specifications 2.0 Harmonization FMI data SeaRegions Testingofspecifications (based on Habitats data modelsand user requirements) Bio-geographicalregions Habitatsandbiotopes Species distribution

32. Source data Vegetation tiers (altitudinal vegetation zones) layer Part of PFD (Regional Plans of Forest Development) produced by FMI Spatial reference system - SJTSK (Czech national system) FMI original classification system

33. New Data Model Existing data model + referenceHabitatTypeId: CharacterString referenceHabitatTypeScheme: ReferenceHabitatTypeSchemeValue localSchemeURI: URI localNameValue: CharacterString geometry: polygon referenceHabitatTypeId: eunis_value referenceHabitatTypeScheme: eunis localSchemeURI: link_to_FMI_classification localNameValue: FMI_classification_value

34. Harmonization process Open SHP file and its scheme New data model Save final SHP file Reclassification FMI -> EUNIS

35. Taxonomy – reclassification (FMI -> Eunis) 0 Pine -> G3.42,"4","Middle European [Pinussylvestris] forests" 1 Oak -> G1.87,"4","Medio-European acidophilous [Quercus] forests" 2 Beech-oak -> G1.82,"4","Atlantic acidophilous [Fagus] - [Quercus] forests" 3 Oak-beech -> G1.82,"4","Atlantic acidophilous [Fagus] - [Quercus] forests" 4 Beech -> G1.6,"3","[Fagus] woodland" 5 Fir-beech -> G4.6,"3","Mixed [Abies] - [Picea] - [Fagus] woodland" 6 Spruce-beech -> G4.6,"3","Mixed [Abies] - [Picea] - [Fagus] woodland" 7 Beech-spruce -> G4.6,"3","Mixed [Abies] - [Picea] - [Fagus] woodland" 8 Spruce -> G3.1D,"4","Hercynian subalpine [Picea] forests" 9 Dwarp pine -> F2.45,"4","Hercynian [Pinusmugo] scrub"

36. Target data Source data (simplified)

37. Metadata profiles and cataloging Requirements on metadata information are growing with professionalism of users. Simply we can say, that for example tourist requirements will be done usually by theme of information and spatial or eventually time extend Requirements of specialist could lead to extension of current INSPIRE standards (done as part of Habitats work)

38. Simple metadata inside of viewer

39. Habitats multi search

40. INSPIRE versus Habitats architecture

41. What is missing from Habitats view INSPIRE architecture doesn’t reflect needs of regions about data collection and updating INSPIRE architecture doesn’t reflect needs of regions about metadata collection and updating In single Habitats pilot cases you don’t need necessary full architecture Components of Habitats architecture could be localized on more places.

42. Example Metadata Habitats metadata management has to be divided into single components, guarantee communication using CSW standards. So metadata management system could run on different server, than single clients Metadata management system is divided from metadata edition and also from discovery services.

43. Example Metadata Catalogue system is now composed from independent components: Metadata catalogue Metadata editor client Metadata import client Metadata harvesting client Metadata valuator client Light discovery services client Full discovery services client

44. Example Metadata Currently solved problem is about metadata management, if to use metadata harvesting or provide multi search to multiple catalogue Second option could be combined with some methods of metadata caching The problems are with different usage of standards in INSPIRE and ISO, for example some GEOSS catalogues are not compatible with INSPIRE based catalogues

45. View services Current most popular technologies are based on clients technologies. It give us some advantage, but also could bring problems with browsers and some operations like coordinate transformation or printing Server part of client is necessary

46. View services

47. View services

48. Additional services required Sensor Observation Services Data uploading Data composition forming Vectorisation of data Data download Support for mobile online and offline data collection Support for iframe or portlets to be possible integrate components with Web pages

49. Usage of iframe

50. Reference laboratory Habitats RL is designed and implemented as a virtual database. It integrates different technologies like GIS, multimedia, and virtual reality. Important part is integration of social networking tools supporting social assessment. These services are not implemented on the Habitats portal directly, but they are implemented as virtual services on different places in Europe.

51. Reference laboratory

52. Pilot implementation Not all pilots need to implement full architecture, subset of architecture is given by pilot needs Pilot implementation are based on common generic architecture principles, but they are free to use different components and platforms, this give possibilities for good testing of interoperability Pilot applications are validate by users, but also against RL

53. Thank you for your attention Karel Charvat Help Service Remote Sensing