the model driven approach of iso19100 iso tc211 and cen tc287 implemented by interlis n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
The model driven approach of ISO19100 (ISO/TC211 and CEN/TC287) implemented by INTERLIS PowerPoint Presentation
Download Presentation
The model driven approach of ISO19100 (ISO/TC211 and CEN/TC287) implemented by INTERLIS

Loading in 2 Seconds...

play fullscreen
1 / 35

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


  • 156 Views
  • Uploaded on

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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'The model driven approach of ISO19100 (ISO/TC211 and CEN/TC287) implemented by INTERLIS' - aloha


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
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

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

o verview
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

1 t he s wiss s ituation
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

2 sdi s and projects the differences
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

2 sdi s and projects the differences1
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

3 t he model driven approach mda 3 1 p rinciple
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

slide7

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

3 2 e xample data transfer and gis implementation by mda 2 3

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

3 2 e xample data transfer and gis implementation by mda 3 3
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

3 3 s ervices based on mda
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

3 4 m da as fundamental method of iso19100 standards series 1 3
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

3 4 m da as fundamental method of iso19100 standards series 2 3
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

3 4 m da as fundamental method of iso19100 standards series 3 3
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

3 5 i mportant differences
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

3 6 s emantic transformation 1 3
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

3 6 s emantic transformation 2 3

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

3 6 s emantic transformation 3 3
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

4 w hat is interlis 1 2
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

4 w hat is interlis 2 2
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

slide20

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

5 3 which language concepts support which data exchange mechanisms
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

5 4 s upport of multilingual federated organisations
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

5 5 e nabling model evolution schema versioning
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

5 6 e nabling further development and extension
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

5 6 s imple data handling for data suppliers users
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

5 7 s imple outsourcing of services around the data
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

slide27

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

5 11 a vailability for everyone at reasonable price
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

5 12 a vailability of specialists guarantee of education and training
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

5 13 a nyone else using these tools
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

5 14 an own question sample xml
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

why do we write schemas
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

example
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

what exists in current standards to constrain geo datatypes
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

slide35
Do you have enough ressources to hand craft all this validation code in every application?

ISO19100 implemented by INTERLIS