Title: GML, NEN3610 and TOP10NL
1GML, NEN3610 and TOP10NL
4th GML Relay (Emmen)
Wilko Quak
2Overview
- NEN3610 and its history
- TOP10NL a model on top of NEN3610
- Transforming the model to GML
- Questions
3History of NEN3610
- Originated by Ravi (Network Organization for
Geo-Information) - First base model in 1992
- Exchange format NEN1878
4New NEN3610 (work started in 2003)
- Prerequisites
- Based on International Standards (ISO, OGC)
- Backwards compatible with old NEN3610
- Should be a base for the exchange of all geo-data
in the Netherlands (Top-Down approach) - Extensible
5NEN3610 specifications
- Nationwide unique identifiers
- Temporal model useful for change only updates
- Fully described in UML
- GML Application Schema is automatically derived
from the UML model. - The model is not complete by itself it is a
starting point for sectors that should make a
Sector Model - One base class GeoObject and about a dozen
subclasses.
6NEN3610 base class GeoObject
- Unique nationwide Identifier
- Temporal attributes can be used for incremental
updates - Almost all attributes are optional
7NEN3610 subclasses
- Road
- Water
- Railroad
- Terrain area with specific landuse
- Building
- Construction bridges, telephone poles etc.
- Dyke very important in the Netherlands
- Cables underground
- RegistrationalArea province, municipality
boundary - GeographicArea areas with vague boundaries
(like the Lake District or the Alps)
8NEN3610 the UML Model
9NEN3610 temporal model
- Four temporal attributes for version management
and incremental updates. - objectBeginTime and objectEndTime indicate the
lifetime of an object. - If an attribute changes a new version is shipped
with a new versionBeginTime. - An object is deleted by shipping it with a non
null objectEndTime. - Two temporal attributes for when the object
changed in the real world beginTime and endTime
10Advantages of a nationwide base model
- Shared definitions
- One shared temporal model for all data in the
Netherlands - - To keep everybody happy almost all attributes
are optional and definitions very vague - A published base model is a good starting
point for sector models (even if they do not
agree with the model)
11Overview
- NEN3610 and its history
- TOP10NL a sector model in NEN3610
- Transforming the model to GML
- Conclusions
12Base model and sector models
International standard
OGC
ISO 191XX
NEN3610
National standard
Exchange
Sector specific
Organisation specific
13Making a sector model
- Sectors that use NEN3610 should choose the most
applicable class in NEN3610 and extend it. - If no applicable class is found GeoObject can be
extended - How to extend
- Extending by subclass
- Extending by pattern
14Extension by Subclass
- Create subclass
- add attributes
- restrict attributes
- An extension should not
- contradict with its base class.
- Any instance of the subclass
- must be a valid instance of the
- superclass.
15Multiple Inheritance
- If the original hierarchy has more than one level
subclassing might result in a multiple
inheritance hierarchy.
Keep base hierarchy as flat as possible!
16Extension by Pattern
- Copy class and attributes of all superclasses
- add new attributes
- delete unused attributes (when they were
optional) - Results in a new stand-alone UML model
17TOP10NL The first sector-model
- TOP10NL is a national 1 10 000 topographic
dataset of the Netherlands provided by the Dutch
Kadaster - Relatively easy because TOP10NL had a lot of
influence on the NEN3610 model - Extension by subclass
- Multiple Inheritance avoided by making
TOP10Object an attribute of every subclass.
18TOP10NL the complete model
19Lessons learnt from modeling NEN3610 and TOP10NL
- If you want to understand your own data try to
make a model that fits. - Keep your model as simple as possible
- Make a 1-level hierarchy at most
- Give definitions of all classes and attributes
(preferably also in English) -
20Overview
- NEN3610 and its history
- TOP10NL a model in the NEN3610 family
- Transforming the models to GML
- Questions
21Automatic Translation of UML model
UML
UML
Application
Guidelines
Schema
model
(XMI)
Encoding Rules
ShapeChange
ShapeChange
(Java, Servlet)
(Java program)
Configuration
Configuration
(XML)
(XML)
GML
GML
Application
Application
Schema
Schema
(XML Schema)
(XML Schema)
http//www.interactive-instruments.de/ugas/
22Consequences of Automatic Translation
- Because the GML Schema depends for 100 on the
UML - model every choice you make in UML is directly
reflected - in GML
- You only have to worry about the UML model
- Extension by pattern gives different schemas than
extension by subclass - Every typo is a bug
23Extension by Subclass Consequences for XML Schema
- The resulting GML lives in two nameSpaces
(nen3610 and top10nl) - The sector model includes the definition of the
base model and only describes the changes. - Every extension results in a substitutionGroup in
the application schema. - Automatic translation of restrictions from UML is
tricky. Manual post-processing of the schema is
sometimes needed. - Some restrictions cannot be expressed in
XML-Schema
24NEN3610 GML application schema
- The NEN3610 UML Model has been automatically
converted to a GML application schema
(NEN3610.XSD) This software was modified to
partly overcome the problems with restrictions in
subclasses - TOP10NL can include the NEN3610.XSD from their
own schema.
25Extension by pattern Consequences for XML Schema
- Simple document structure
- It is not clear from the schema that the sector
model is an extension of the base model
26GML design choices in TOP10NL (whats your
opinion?)
- Extension by subclass resulting in many
substitutionGroups. - langnl attribute to encode language of
geographic names. (this should be part of GML). - Use of objectBeginTime and objectEndTime enables
incremental updates - Choice of UTF8 as character encoding
Reli?34f Ge?34lectrificeerd
27Questions?