2005-05-02ISO19100 implemented by INTERLIS1 The model driven approach of ISO19100 (ISO/TC211 and...

2005-05-02 ISO19100 implemented by INTERLIS 1

The model driven approach of ISO19100 (ISO/TC211 and

CEN/TC287) implemented by INTERLIS

Christine [email protected]

ETH Zürich, IGP. www.gis.ethz.ch Claude Eisenhut

[email protected] Eisenhut Informatik AG, Jegenstorf

Nicole [email protected]

ETH Zürich, IGP. www.gis.ethz.ch Hans Rudolf Gnägi

[email protected] Zürich, IGP. www.gis.ethz.ch

mailto:[email protected]







OVERVIEW

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


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


2. SDIS 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-aroundstions (data / services / (choose another bridge-transfer) element)

– necessity for exactly defined basic description language


2. SDIS 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


– 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. THE MODEL DRIVEN APPROACH - MDA3.1 PRINCIPLE


• 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 EXAMPLE: DATA TRANSFER AND GIS IMPLEMENTATION BY MDA (1/3)

• Phases 1 and 2 of MDA



• Phases 3 and 4 of MDA

SQL

GIS/DB specific description

GIS/DB internalstructure

logical schema(GIS configuration)

physical schema(implementation)

GIS DB

physical schema (transfer format description)

Transfer data file

XML-Schema

GMLILI-XML



– 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)


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


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.


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


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


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


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


UML &INTERLIS

Data model forpedestriannavigation

encodingrules

R

UML &INTERLIS

Originaldata model

(e.g. based onGDF)

data set(e.g.

TeleAtlas)

semanticmapping

S

inputoutput

ready for integration

Reduceddata set forpedestriannavigation

= 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




• 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)


4. WHAT IS INTERLIS? (1/2)

– A textual CSL, closely related

to the graphical CSL UML– Different transfer formats– Encoding rules (XML based)

<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 ...

<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 ...

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:

b

D

B

A

a

c d

C

1

Building:• Number, Street• Geometry

Building:• Number, Street• Geometry


4. WHAT 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


5. ANSWERS TO QUESTIONS OF ANNEX A

5.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!


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


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


5.5 ENABLING MODEL EVOLUTION (SCHEMA VERSIONING)

– Model-name + object-orientation with inheritance defined for topics, classes, relationships and attribute-types


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


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)


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)


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


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):

UML INTERLIS Editor FW, OS

INTERLIS Compiler FW, OS

INTERLIS Checker FW


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


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


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>


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.


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>

???


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 !


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

Date post:	12-Jan-2016
Category:	Documents
Upload:	abraham-ray
View:	215 times
Download:	0 times

2005-05-02ISO19100 implemented by INTERLIS1 The model driven approach of ISO19100 (ISO/TC211 and...

Documents