Michael Germann (2003)
24. Juni 04 (15:02 Uhr)
Beitragsnummer: 186

Stellungnahme des INTERLIS-Kernteam zur GML INTERLIS Studie von Prof. Nebiker (FHBB)

Die Studie von Professor Nebiker und seinem Team positioniert GML 3.0 auf der gleichen Stufe wie INTERLIS 2 („die Absicht hinter GML und INTERLIS ist grundsätzlich vergleichbar“). GML wird als Modellierungssprache mit ähnlichen Eigenschaften wie INTERLIS präsentiert. Diese Darstellung ist nach unserer Meinung nicht richtig und widerspricht sowohl der Absicht der GML Erfinder ("GML is a non-proprietary geographic file format that can encode most types of geographic information."), als auch den aktuellen Absichten der ISO (GML als Transferformat für mit UML beschriebene Geodaten). Nach unserer Meinung muss man die Absichten hinter GML und INTERLIS korrekt wie folgt beschreiben:

- GML 3.0 ist ein flexibles, XML basiertes Transferformat.
- INTERLIS 2 ist eine Modellierungssprache für die möglichst präzise Beschreibung von beliebigen Daten. Das konkrete Transferformat wird in INTERLIS immer aus dem Datenmodell via Regeln hergeleitet. Es ist mit INTERLIS 2 z.B. ohne weiteres möglich mehrere Transferformate für das gleiche Datenmodell zu definieren (z.B. INTERLIS XTF und/oder GML).

Aus den oben beschriebenen unterschiedlichen Zielsetzung von GML und INTERLIS drängt sich eine Ablösung von INTERLIS durch GML nicht auf. Ein Umstieg auf GML würde u.a. folgende negative Konsequenzen haben:

- Mit GML könnten Geodaten weniger präzis beschrieben werden. Das ist aber das Hauptanliegen von INTERLIS. Insbesondere wurde INTERLIS 2 entwickelt um die Präzision der Beschreibung gegenüber INTERLIS 1 zu verbessern (Assoziationen, Constraints, Einheiten, etc.).
- Mit GML wäre man auf Gedeih und Verderb an die (GML)XML-Technologie gebunden. Eine Unterstützung von verschiedenen Transferformaten wäre damit praktisch ausgeschlossen. Es zeigt sich z.B. bereits heute, dass verschiedene Anwendungen auch verschiedene XML-Codierungen verlangen. INTERLIS XTF eignet sich z.B. für die langfristige Archivierung bzw. die inkrementelle Nachlieferung von Daten. GML scheint hingegen bei den Webservices an Bedeutung zu gewinnen.

Das in der Studie genannten Szenario 3 (rasche Umstellung auf GML) ist daher nach unserer Meinung nicht durchführbar. Es bleiben daher nur die Szenarien 1 (unabhängige Weiterentwicklung von INTERLIS) und 2 (zweigleisige Strategie). In Szenario 2 sehen wir die Position von GML aber nur im Bereich des Transfers als mögliche Variante zu XTF aber NICHT als eine alternative Modellierungssprache. Die Bezeichnung „zweigleisige Strategie“ ist daher für Szenario 2 nicht richtig, weil sie die Gleichbehandlung von INTERLIS und GML suggeriert. Besser wäre die Bezeichnung „INTERLIS mit GML Transfer“. Im Detail müsste man jedoch noch abklären, ob GML alle Anforderungen an einen INTERLIS 2 konformen Transfer erfüllt. Im Moment (GML 3.0) ist das jedoch mindestens im Bereich inkrementelle Nachlieferung, polymorphes Lesen oder für die Codierung gewisser Geometrietypen nicht der Fall.

INTERLIS 2 Kernteam, Mai 2004

KOGIS als Mitglied des Kernteams - gleichzeitig aber auch Auftraggeberin der besprochenen Studie - kann sich nicht mit allen Punkten der Stellungnahme einverstanden erklären.

Urs Gerber
3. Mai 04 (08:43 Uhr)
Beitragsnummer: 154

Im GIS Monitor, April 29, 2004 from GITC America bin ich auf folgenden Beitrag zu GML gestossen, welcher Erfahrungen von Safe Software (Anbieter von FME) beschreibt:
"Don Murray, the founder and president of Safe Software, explained his experiences with Geography Markup Language, GML, an XML encoding for geospatial data. In short, he argued there are two roles assigned to GML. One is to be an "expressive" tool for complexly modeled data. That is, it can capture and distribute all the complexity of the Ordnance Survey's MasterMap in a vendor-neutral way. From his account, it works great for that type of use. The second use is to deliver a solution to the request, "Hey Fred, can you get me some data about this area of town?" For this type of "quick sharing across GIS packages" GML has not fared so well. That was his conclusion based on experience from a recent GML Relay where data ideally was to be loaded into and edited in a software package then passed to the next participant to do the same. It didn't happen as was hoped, to put it gently.
Still, the Relay experience was valuable as were some of Safe Software's implementations for customers. Murray noted that he and his colleagues have learned that GML:
-is not a database
-is slow to use as is but great to load once into a database
-is built for expressiveness
-typically needs an external file to ensure effective understanding of that expressiveness
-that the external file sometimes needs to be "handcooked"
-is effective in a controlled environment
The challenge then is to explore how GML can better serve the quick data sharing needs of geospatial (and other) users. And, the answer seems to involve some type of profiling that will simplify the process. A profile basically means "rules about what types of things go into" GML. As Murray put it, one part of a profile might be "Thou shalt not have embedded objects" (object made up of other objects). Until one or more profiles are defined and agreed upon, most users will rely on the "old faithful" ways of quick data transfer, via shape files or MIF/MID. For GML to take hold, it needs to be at least as easy and effective as these methods. The example Murray used that sticks with me: imagine if when you tried to load a Web page you had to "spend a morning" deciphering its language. The Internet would never work. That's akin to the current state of GML for data exchange."

Für diejenigen, die GIS Monitor noch nicht kennen: [www.gismonitor.com/]

Stefan Keller
18. April 04 (16:37 Uhr)
Beitragsnummer: 141

Inkrementelle Nachlieferung, polymorphes Lesen, erweiterbare Kurventypen, Views, Signaturenmodell, Darstellungsbeschreibungssprache, mehrsprachige Tags und Schemas, Unterstützung auch künftiger XML Schemas, volle UML-Integration, zehn Mal kompakterer Spezifikationsumfang, drei bis fünf Jahre Vorsprung in der Werkzeug-Entwicklung und eine seit über zwölf Jahren ausgebildete Benutzerbasis sind meines Erachtens kaum Details...

Schade, dass die Studie alle diese Aspekte kaum erwähnt und in den Szenarien unberücksichtigt lässt.

Claude Eisenhut
10. April 04 (13:56 Uhr)
Beitragsnummer: 138

In der Studie fehlen wichtige Details, die bei INTERLIS und GML auf Stufe Transferformat unterschiedlich sind:
- polymorphes Lesen
- mehrsprachige Tags
- inkrementelle Nachlieferung
- Codierung von Punkt/Linieninformationen

Was ist damit gemeint? Wie wäre die Anwendung? Was wären die Vor-/Nachteile?

Eine detailiertere Untersuchung würde zeigen: das einzige, richtige Format gibt es nicht. Auch XML ist das nicht.
Die Trennung der Inhaltsbeschreibung von den Formatbeschreibungen ist darum wichtig.

Die Szenarien und Empfehlung in Kap. 7 kann nur richtig eingestuft werden, wenn der Leser der Studie diese Unterschiede auch kennt.

Claude Eisenhut
29. März 04 (09:39 Uhr)
Beitragsnummer: 130

In Abb.5 S.33 wird nur zwischen Daten und Modell unterschieden. Meiner Meinung
nach müsste man aber zwischen Daten, Format, exakter Inhaltsbeschreibung und
Visualisierung (der Daten, des Formats, der Inhaltbeschreibung)
unterscheiden.

So könnte man z.B. zeigen, dass UML für verschiedene Stufen nützlich ist,
und, wichtiger, man nicht einfach UML für die Modellierung vorgeben kann,
sondern dass man definieren muss, auf welcher Stufe modelliert werden soll.
Und man darum auch eine entsprechende UML-Konfiguration benötigt.

Man könnte aber auch sehen, dass es die vorgeschlagene Variante 4 gar nicht gibt! Wenn man UML
für die Visualisierung der Inhaltsbeschreibung verwendet, muss es ja das
selbe sein für INTERLIS und GML. Man will ja die selben Daten beschreiben
(=Inhaltsbeschreibung), nur in einem anderen Format!

Der Newsmoderator
19. März 04 (09:51 Uhr)
Beitragsnummer: 126

Im Rahmen des Spirgartentreffens am 17.3.04 (siehe auch Beitrag [121]) hat Herr S. Nebiker (FHBB) die Ergebnisse einer Vergleichsstudie INTERLIS 2 - GML 3 vorgestellt, die er zusammen mit A. Annen und S. Bleisch (FHBB) im Auftrag von KOGIS verfasst hatte. Herr Nebiker informierte in seiner Präsentation (siehe [www.interlis.ch/general/docs/spirgarten2004_interlis-gml.pdf] über Basisstandards, -konzepte und -technologien rund um UML und XML, verglich die zugrundeliegenden Konzepte von INTERLIS 2 und GML 3, präsentierte praktische Untersuchungsergebnisse zur Konvertierung und Interoperabilität von INTERLIS 2 und GML 3 (, die in einer eigens dazu angelegten Diplomarbeit von A. Annen erarbeitet wurden), stellte Stärken und Schwächen sowie Gemeinsamkeiten und Unterschiede einander gegenüber und stellte Chancen und Risiken von drei Szenarien zum weiteren Vorgehen zur Diskussion:

Szenario 1:
"INTERLIS only" als von GML unabhängige Weiterentwicklung von INTERLIS

Szenario 2:
"Kombination" als zweigleisige Strategie mit Konvertierungsschiene oder anders ausgedrückt: INTERLIS Modellierung mit GML Support

Szenario 3:
"GML only" als rasche Umstellung auf GML

Herr Nebiker empfahl Szenario 2 zur Weiterbearbeitung und stellte hierfür erste Umsetzungsvorschläge vor.

Die vollständige Studie finden Sie unter [www.kogis.ch/docs/Vergleichsstudie_ILI_GML_final.pdf].

Welche Fragen sind für Sie im Zusammenhang mit den Thema INTERLIS 2 und/oder GML 3 noch offen?