1. 2005-05-02ISO19100 implemented by INTERLIS1 The model driven approach of ISO19100 (ISO/TC211 and CEN/TC287) implemented by INTERLIS Christine Giger giger@geod.baug.ethz.ch ETH Zürich, IGP. www.gis.ethz.ch Claude Eisenhut ce@eisenhutinformatik.ch Eisenhut Informatik AG, Jegenstorf Nicole Stahel nstahel@geo.unizh.ch ETH Zürich, IGP. www.gis.ethz.ch Hans Rudolf Gnägi gnaegi@geod.baug.ethz.ch ETH Zürich, IGP. www.gis.ethz.ch

2. 2005-10-13ISO19100 implemented by INTERLIS2 O VERVIEW 1.The Swiss situation 2.SDIs and projects: the differences 3.The model driven approach - MDA 4.What is INTERLIS 5.Answers to the questions of annex A

3. 2005-10-13ISO19100 implemented by INTERLIS3 1. T HE S WISS S ITUATION Switzerland is living federalism –consisting of 26 independent states (cantons) Swiss experiences in managing federated data structures –Switzerland organised infrastructure long before XML, GML and Web-Services existed –for more than 300 partners and –for GIS from more than 2 different providers –which still works in more and more application areas, even in non-geographic ones, –and integrates new technologies without problems

4. 2005-10-13ISO19100 implemented by INTERLIS4 2. SDI S AND PROJECTS: THE DIFFERENCES Infrastructure ≠ Project –no “boss” - directed by a “boss” –different partners- collaborators –+/- working - have to work together –has to grow bottom up- directed form top can not be ordered broken down to elements –ex: growing road network- ex: construction of a bridge –necessity for exact and - “boss” can define situation- understandable specifica- dependent walk-arounds tions (data / services / (choose another bridge- transfer) element) –necessity for exactly defined basic description language

5. 2005-10-13ISO19100 implemented by INTERLIS5 2. SDI S AND PROJECTS: THE DIFFERENCES Other aspects of Infrastructures –Data need to be correctly interpretable without questions (who should answer?) –Infrastructures are not exclusively geo-oriented –Geo-community has to take into account non-geo- applications as users of geo-data products

6. 2005-10-13ISO19100 implemented by INTERLIS6 –Describe data structures (as you specify programs) on the system-independent conceptual level –Automatically derive basic service features like: - transfer formats - protocols - logical and physical implementation 3. T HE MODEL DRIVEN APPROACH - MDA 3.1 P RINCIPLE

7. 2005-10-13ISO19100 implemented by INTERLIS7 UML-classdiagramm Data description language (DDL, CSL ) INTERLIS, EXPRESS Real world Description in natural language Reality selection = Real world objects ­ ­ Conceptual decription technique (basis: conceptual formalism) Conceptual (application) schema 3.2 E XAMPLE: DATA TRANSFER AND GIS IMPLEMENTATION BY MDA (1/3) Phases 1 and 2 of MDA

8. 2005-10-13ISO19100 implemented by INTERLIS8 3.2 E XAMPLE: DATA TRANSFER AND GIS IMPLEMENTATION BY MDA (2/3) Phases 3 and 4 of MDA SQL GIS/DB specific description GIS/DB internal structure logical schema (GIS configuration) physical schema (implementation) GIS DB physical schema (transfer format description) Transfer data file XML-Schema GML ILI-XML

9. 2005-10-13ISO19100 implemented by INTERLIS9 3.2 E XAMPLE: DATA TRANSFER AND GIS IMPLEMENTATION BY MDA (3/3) –Exact model description + corresponding data –Different transfer formats can be automatically derived from an exact conceptual model –Strict separation of model (-description) and format (-description)

10. 2005-10-13ISO19100 implemented by INTERLIS10 3.3 S ERVICES BASED ON MDA –Transfer: For most commercial GIS exist I/O processors or they can be implemented by the semantic transformation based on the proprietary internal transfer formats –Incremental change only update –Documented data save –Geo-data checker –Portal tools to provide Geo-data in the Internet (GeoShop) –Easier implementation of semantic translation –Generalized data models

11. 2005-10-13ISO19100 implemented by INTERLIS11 3.4 M DA AS FUNDAMENTAL METHOD OF ISO19100 STANDARDS SERIES (1/3) UML as CSL (ISO19103) + easy to understand + widespread + general add-ons are needed  ISO19103 defines basic language elements but not sufficiently. Example: What is the meaning of references from application schemas to model elements in the harmonised model? + GML work brings clarification of some problems. Example: Meaning of packages.

12. 2005-10-13ISO19100 implemented by INTERLIS12 3.4 M DA AS FUNDAMENTAL METHOD OF ISO19100 STANDARDS SERIES (2/3) Rules for application schema development (ISO19109) +MDA methodology is documented -contains superfluous and rather disturbing information. Example: General Feature Model GFM, to be replaced by the general OO resp. UML definition of “object” amendment procedure

13. 2005-10-13ISO19100 implemented by INTERLIS13 3.4 M DA AS FUNDAMENTAL METHOD OF ISO19100 STANDARDS SERIES 3/3) ISO/TC211 experience: –GI-standardisation is only possible at the system- independent conceptual level

14. 2005-10-13ISO19100 implemented by INTERLIS14 3.5 I MPORTANT DIFFERENCES data description (ontology, conceptual schema)  format description (physical schema of transfer file)  data (content of transfer file or data base) –conceptual modelling has to be exact and format- independent –a data-model (or schema) is not another and better description of the data format –but is the exact description of the data content

15. 2005-10-13ISO19100 implemented by INTERLIS15 3.6 S EMANTIC TRANSFORMATION (1/3) Problem –Exchange data between systems with different data structures Solution principle –Map data models on conceptual level –Let perform the corresponding transformation of data by an appropriate MDA-Tool

16. 2005-10-13ISO19100 implemented by INTERLIS16 UML & INTERLIS Data model for pedestrian navigation encoding rules R UML & INTERLIS Original data model (e.g. based on GDF) data set (e.g. TeleAtlas) semantic mapping S input output ready for integration Reduced data set for pedestrian navigation = scope of formal approach to ontologies = scope of application and/or information community = scope of format specifica tion for given application = scope of content provider = defines = relationship = data flow 3.6 S EMANTIC TRANSFORMATION (2/3)

17. 2005-10-13ISO19100 implemented by INTERLIS17 3.6 S EMANTIC TRANSFORMATION (3/3) Solution steps using UML-INTERLIS-Tools –Provide the conceptual schemas of the start data structure (original data model) of the final data structure (pedestrian navigation) –Define the semantic mapping from the original to the final model by providing the necessary parameters for the INTERLIS conversion system (ICS) –ICS automatically calculates the final data (reduced data set for pedestrian navigation in the standard format corresponding to the final model) from the original data in the standard format (e.g. TeleAtlas)

18. 2005-10-13ISO19100 implemented by INTERLIS18 4. W HAT IS INTERLIS? (1/2) –A textual CSL, closely related to the graphical CSL UML –Different transfer formats –Encoding rules (XML based) <Grunddatensatz_Fixpunkte_LFP_OBJE TID="T101" Art="LFP1" LageZuv="ja“ HoeheGen="0.0" Nummer="1091111.2“ Geometrie="675899.226/245270.946“ LageGen="0.0“ NumPos="675895.761/245263.124“ HoeheZuv="ja“ /> <Grunddatensatz_Fixpunkte_LFP_OBJE... <Grunddatensatz_Fixpunkte_LFP_OBJE TID="T101" Art="LFP1" LageZuv="ja“ HoeheGen="0.0" Nummer="1091111.2“ Geometrie="675899.226/245270.946“ LageGen="0.0“ NumPos="675895.761/245263.124“ HoeheZuv="ja“ /> <Grunddatensatz_Fixpunkte_LFP_OBJE... DATA MODEL = DOMAIN Point2D = COORD 111.11 222.22; TOPIC T = CLASS C = Attr1: TEXT*12; Attr2: Point2D;... DATA MODEL = DOMAIN Point2D = COORD 111.11 222.22; TOPIC T = CLASS C = Attr1: TEXT*12; Attr2: Point2D;... Data description (model): Data transfer format: Building: Number, Street Geometry Building: Number, Street Geometry

19. 2005-10-13ISO19100 implemented by INTERLIS19 4. W HAT IS INTERLIS ? (2/2) Advantages of a textual CSL (like INTERLIS) –Allows exact definition of data types –On the well defined textual description language different services can easily be realized –Especially the automatic derivation of the transfer format corresponding to the data model –This makes individual implementations of transfer formats for every new application data model superfluous –Which provides a significant save of time and money

20. 2005-10-13ISO19100 implemented by INTERLIS20 5. A NSWERS TO QUESTIONS OF ANNEX A 5.1 H OW TO PROTECT LONG-TERM INVERSTMENTS IN DATA 5.2 H OW TO EXCHANGE DATA AND DATA MODELS BY APPLYING THE MDA DATA EXCHANGE METHOD (SEE 3.2) –For (geo-)data-storage and –exchange do use the combination of the exact model description with the data in the corresponding automatically derivable standard transfer format!

21. 2005-10-13ISO19100 implemented by INTERLIS21 5.3 WHICH LANGUAGE-CONCEPTS SUPPORT WHICH DATA EXCHANGE MECHANISMS By the UML-INTERLIS solution different transfer formats are supported and can automatically be derived (for each application) from the conceptual application schema –INTERLIS1 proprietary transfer format (ITF) –INTERLIS-XML supporting incremental updates and polymorphic read –GML Tool (freeware, open-source): –INTERLIS Compiler

22. 2005-10-13ISO19100 implemented by INTERLIS22 5.4 S UPPORT OF MULTILINGUAL, FEDERATED ORGANISATIONS Federated organisations –Object-orientation with inheritance allows specialization of general data models –If modification of existing data models is not possible, semantic transformation (see 3.6) allows mapping of different data models and automatic reformatting of corresponding data –Tools (commercial): INTERLIS Conversion System, INTERLIS Studio Multilingual organisations –Data structure (model) comparison independent of the language, in which the names of the conceptual schema are given –Tools (freeware, open-source): INTERLIS Compiler

23. 2005-10-13ISO19100 implemented by INTERLIS23 5.5 E NABLING MODEL EVOLUTION (SCHEMA VERSIONING) –Model-name + object-orientation with inheritance defined for topics, classes, relationships and attribute- types

24. 2005-10-13ISO19100 implemented by INTERLIS24 5.6 E NABLING FURTHER DEVELOPMENT AND EXTENSION –Specialization and generalization possible by object- orientation with inheritance –Polymorphic read allows acceptance of new specialised data by processes based on the old general data model

25. 2005-10-13ISO19100 implemented by INTERLIS25 5.6 S IMPLE DATA HANDLING FOR DATA-SUPPLIERS/-USERS –Data suppliers and users have only to deal with data models and to agree on these –Extraction/introduction of geo-data out of/into GIS by tools (see 3.3) –Different transfer formats available (see 5.3) –Tools for semantic transformation (see 3.6) –Existing portal-tool (GeoShop) with Web Service Interface (see 3.3)

26. 2005-10-13ISO19100 implemented by INTERLIS26 5.7 S IMPLE OUTSOURCING OF SERVICES AROUND THE DATA –Exact data model + automatic format calculation from data model allows development and application of system-independent services (see 3.3)

27. 2005-10-13ISO19100 implemented by INTERLIS27 5.8 E NABLING QUALITY CONTROL OF DATA AND DATA-MODELS 5.9 E NABLING THE CUSTOJMER TO CHECK THAT HE GETS WHAT HE ORDERED 5.10 E NABLING THE SUPPLIER TO PROVE THAT HE DELIVERS WHAT HAS BEEN ORDERD Quality control of models: –With the compiler Quality control of data: –Checker allows to compare the data in standard format with the corresponding conceptual schema (data model) –Test if thematic attribute values (numbers, texts, enumerations) are elements of the corresponding value domain –Test of geometric consistency of points, lines and surfaces

28. 2005-10-13ISO19100 implemented by INTERLIS28 5.11 A VAILABILITY FOR EVERYONE (AT REASONABLE PRICE) Free ware and open source –Strategy of KOGIS (Swiss coordination group for GI and GIS on the federal level): to provide all the necessary tools as freeware and open source –Actually freeware (FW) and open source (OS): UML INTERLIS EditorFW, OS INTERLIS CompilerFW, OS INTERLIS CheckerFW

29. 2005-10-13ISO19100 implemented by INTERLIS29 5.12 A VAILABILITY OF SPECIALISTS, GUARANTEE OF EDUCATION AND TRAINING Specialists –CH: 20 years of experience with MDA Education/training –Basic courses of two times two days –Short introduction of semantic transformation: 2.5 days

30. 2005-10-13ISO19100 implemented by INTERLIS30 5.13 A NYONE ELSE USING THESE TOOLS Switzerland –Official surveying (since 1993) –Utilities, water, waste water, gas, distant heating, electricity, telecommunication –Metadata + server geocat Europe –Eurogeographics: Metadataserver geocat –Germany BKG: Metadataserver geocat –Belgium, Wallonian region: official surveying, cartography, water, roads –Austria: Renewal of exchange standards

31. 2005-10-13ISO19100 implemented by INTERLIS31 5.14 An own question Sample XML 10 ER_Intersection 624568.110 255553.990

32. 2005-10-13ISO19100 implemented by INTERLIS32 Why do we write schemas? From an e-mail of Paul W. Daisey (recvd. 30-Nov-2004) Yes, the parser implementations of XML/Schema validation, to be specific! It is especially ironic for me, because I am still enchanted with the idea of using parser validation to substitute for writing application- specific data validation code. But with the effort required to work around parser validation differences between Xerces, XSD, MSXML, Oracle's parserve2.jar, Oracle's XDB parser, etc., the apparent savings in effort are proving to be a mirage.

33. 2005-10-13ISO19100 implemented by INTERLIS33 Example INTERLIS: Point = COORD 480000.000.. 850000.000 [m] {CHLV03[1]}, 70000.000.. 310000.000 [m] {CHLV03[2]}, ROTATION 2 -> 1; GML: ???

34. 2005-10-13ISO19100 implemented by INTERLIS34 What exists in current standards to constrain geo- datatypes? Current standards (UML, 19103, 19107, 19136, XML-Schema) do not have/specify any geo specific datatype facets !

35. 2005-10-13ISO19100 implemented by INTERLIS35 Do you have enough ressources to hand craft all this validation code in every application?