1 / 35

The model driven approach of ISO19100 (ISO/TC211 and CEN/TC287) implemented by INTERLIS

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

aloha
Download Presentation

The model driven approach of ISO19100 (ISO/TC211 and CEN/TC287) implemented by INTERLIS

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 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 ISO19100 implemented by INTERLIS

  2. OVERVIEW • The Swiss situation • SDIs and projects: the differences • The model driven approach - MDA • What is INTERLIS • Answers to the questions of annex A ISO19100 implemented by INTERLIS

  3. 1. THE SWISS SITUATION • 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 ISO19100 implemented by INTERLIS

  4. 2. SDISANDPROJECTS: 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-aroundstions (data / services / (choose another bridge-transfer) element) • necessity for exactly defined basic description language ISO19100 implemented by INTERLIS

  5. 2. SDISANDPROJECTS: 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 ISO19100 implemented by INTERLIS

  6. 3. THE MODEL DRIVEN APPROACH - MDA3.1 PRINCIPLE • 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 ISO19100 implemented by INTERLIS

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

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

  9. 3.2 EXAMPLE: 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) ISO19100 implemented by INTERLIS

  10. 3.3 SERVICES 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 ISO19100 implemented by INTERLIS

  11. 3.4 MDA 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. ISO19100 implemented by INTERLIS

  12. 3.4 MDA 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 ISO19100 implemented by INTERLIS

  13. 3.4 MDA AS FUNDAMENTAL METHOD OF ISO19100 STANDARDS SERIES 3/3) • ISO/TC211 experience: • GI-standardisation is only possible at the system-independent conceptual level ISO19100 implemented by INTERLIS

  14. 3.5 IMPORTANT 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 ISO19100 implemented by INTERLIS

  15. 3.6 SEMANTIC 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 ISO19100 implemented by INTERLIS

  16. UML & INTERLIS UML &INTERLIS =scope of formal approach to ontologies = scope of application and/or information community encodingrules R = scope of format specifica tion for given application Originaldata model (e.g. based onGDF) Data model forpedestriannavigation = scope of content provider semanticmappingS = defines data set (e.g. TeleAtlas) = relationship Reduceddata set forpedestriannavigation output ready for integration = data flow input 3.6 SEMANTIC TRANSFORMATION (2/3) ISO19100 implemented by INTERLIS

  17. 3.6 SEMANTIC 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) ISO19100 implemented by INTERLIS

  18. 4. WHAT IS INTERLIS? (1/2) • A textual CSL, closely related to the graphical CSL UML • Different transfer formats • Encoding rules (XML based) • Building: • Number, Street • Geometry Data description (model): Data transfer format: DATA MODEL = DOMAIN Point2D = COORD 111.11 222.22; TOPIC T = CLASS C = Attr1: TEXT*12; Attr2: Point2D; ... <Grunddatensatz_Fixpunkte_LFP> <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 ... ISO19100 implemented by INTERLIS

  19. 4. WHAT ISINTERLIS? (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 ISO19100 implemented by INTERLIS

  20. 5. ANSWERS TO QUESTIONS OF ANNEX A5.1 HOW TO PROTECT LONG-TERM INVERSTMENTS IN DATA5.2 HOW 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! ISO19100 implemented by INTERLIS

  21. 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 ISO19100 implemented by INTERLIS

  22. 5.4 SUPPORT 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 ISO19100 implemented by INTERLIS

  23. 5.5 ENABLING MODEL EVOLUTION (SCHEMA VERSIONING) • Model-name + object-orientation with inheritance defined for topics, classes, relationships and attribute-types ISO19100 implemented by INTERLIS

  24. 5.6 ENABLING 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 ISO19100 implemented by INTERLIS

  25. 5.6 SIMPLE 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) ISO19100 implemented by INTERLIS

  26. 5.7 SIMPLE 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) ISO19100 implemented by INTERLIS

  27. 5.8 ENABLING QUALITY CONTROL OF DATA AND DATA-MODELS5.9 ENABLING THE CUSTOJMER TO CHECK THAT HE GETS WHAT HE ORDERED5.10 ENABLING 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 ISO19100 implemented by INTERLIS

  28. 5.11 AVAILABILITY 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): ISO19100 implemented by INTERLIS

  29. 5.12 AVAILABILITY 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 ISO19100 implemented by INTERLIS

  30. 5.13 ANYONE 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 ISO19100 implemented by INTERLIS

  31. 5.14 An own question Sample XML <ER_RoadNode> <id> <ER_ObjectId> <permanentId>10</permanentId> </ER_ObjectId> </id> <level>ER_Intersection</level> <location> <gml:Point> <gml:pos>624568.110 255553.990</gml:pos> </gml:Point> </location> </ER_RoadNode> ISO19100 implemented by INTERLIS

  32. 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. ISO19100 implemented by INTERLIS

  33. Example INTERLIS: Point = COORD 480000.000 .. 850000.000 [m] {CHLV03[1]}, 70000.000 .. 310000.000 [m] {CHLV03[2]}, ROTATION 2 -> 1; GML: <xsd:complexType name="Point"> <xsd:complexContent> <xsd:restriction base="gml:PointPropertyType"/> </xsd:complexContent> </xsd:complexType> ??? ISO19100 implemented by INTERLIS

  34. 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 ! ISO19100 implemented by INTERLIS

  35. Do you have enough ressources to hand craft all this validation code in every application? ISO19100 implemented by INTERLIS

More Related