Das grundsätzliche Prinzip der Übernahme digitaler Datenbestände zeigt die folgende Abbildung:

Das Quellsystem konvertiert die Daten aus seinem internen Format in ein externes Schnittstellenformat. Dieser Datenbestand wird durch einen Konverter in das Schnittstellenformat des Zielsystems gewan- delt, das die Daten einliest und in sein internes Format wandelt. Bei der Konvertierung sind eine Reihe von Problemen anzugehen. Nicht immer können direkte Beziehungen zwischen den Datenelementen über einfache Umsetzungsregeln hergestellt werden. Vielmehr ist häufig eine Zusammenfassung oder Spezialisierung von Objekten erforderlich, wobei dann nicht immer eindeutige Lösungen möglich sind.

• Es kann beispielsweise sein, daß im Ausgangssystem Flurstücksflächen nur durch ein Folge von Linienstücken geführt werden; im Zielsystem hingegen soll die Fläche topologisch korrekt unter Zuordnung der Flurstücksnummer erscheinen.
• Ein anderes System unterscheidet nicht zwischen verschiedenen Punktarten. Für das Zielsystem ist dann eine Spezialisierung aus Linienzusammenhängen abzuleiten, so daß die Punkte verschiedenen Objektklassen zugewiesen werden können.
• Unterschiede existieren auch in der Art und Weise, wie Texte und Symbole referenziert werden (Bezugspunkt links unten, in der Mitte, …).
• Im Ausgangsdatenbestand sind unter Umständen Informationen gar nicht vorgesehen, die das Zielsystem benötigt. So enthalten beispielsweise EDBS-Aufträge keine Angaben über die Schriftart und Schriftgröße. Für eine korrekte Darstellung in einem Sekundärnachweis müssen diese Attribute gegebenfalls dem erzeugten Schnittstellenformat beigefügt werden.

Ablauf Datenkonvertierung

Für die Umsetzung digitaler Datenbestände werden in der Regel bestimmte Arbeitsschritte durchlaufen, die in der folgenden Abbildung dargestellt sind. Dabei wird davon ausgegangen, dass ein Konvertierungsprogramm bereits vorliegt.

Die Aufstellung der Abbildungsregeln für das Konvertierungsprogramm erfordert intensive Kenntnisse der fachlichen Hintergründe, der zugrundeliegenden Datenmodelle von Quell- und Zielsystem und der jeweiligen Schnittstellenformate. Die Aufgabenvielfalt kann durch eine Person zumeist nicht abgedeckt werden. Wie Textbox 15 (siehe unten) zeigt, kann die Zusammenarbeit verschiedener Fachleute nötig sein.

1. Im ersten Schritt muß eine detaillierte Analyse des umzusetzenden Datenbestandes (Objektklassen / Feature types, Attributumfang, Art und Umfang der Graphikinformation, Art und Umfang der Topologie) und des Datenmodells im Zielsystem vorgenommen werden. Die Analyse des Eingangsbestandes kann auf der Grundlage vorliegender Strukturdefinitionen des Ausgangssystems, der Formatbeschreibung oder durch die DV-gestützte Analyse des Datenbestandes erfolgen. Die Objektstruktur des Zielsystems kann der Schnittstellendefinition und dem Datenmodell der Zielanwendung entnommen werden.
2. Für die Datenumsetzung muß im nächsten Schritt für jedes Datenelement im Ausgangsbestand die Entsprechung im Zielsystem gefunden werden und als Abbildungsvorschrift festgelegt werden. Diese umfaßt Vorgaben für die Überführung der Datenelemente bzw. Objekte, der Attribute, der Geometrie und die Festlegung der im Konverter zu generierenden Zusatzinformation. Der Aufwand für diese Festlegungen und die notwendigen, iterativ durchzuführenden Testläufe ist entsprechend hoch.
3. Die Abbildungsvorschriften werden durch den Konverter ausgewertet und zunächst auf einen Testbestand angewendet.
4. Das Ergebnis der Umsetzung ist sorgfältig zu prüfen.
5. In der Regel wird eine Nachberarbeitung der Abbildungsregeln nötig sein, bevor die Umsetzung des gesamten Ausgangsdatenbestands erfolgen kann.

Any project dealing with the SDTS is best handled by a team approach because of the wide range of knowledge and abilities that is needed. At a minimum the team needs experts in the following areas: 1. Subject matter expert – conceptual level 2. Spatial data model expert – logical level 3. Spatial data model expert – format level 4. Software developers (analyst, designer, programmer) 5. Policy authority expert The subject matter expert must know how the real world is depicted in the spatial model, including the attribution method and feature extraction rules … [and] needs to be proficient in the spatial object definitions; SDTS entity, attribute, and value model; standard entity and attribute terms; and data quality categories. The logical level expert must know the digital representations of the spatial model … [and] needs to be proficient in the modules, fields, and subfields of the standard. The format level expert must know file formats, record layouts, data types, and other details of this nature. … need to be proficient with the standard’s format level and the ISO 8211 software and (or) standard and familiar with the logical level. By having a policy authority expert as a part of the team, the necessary decisions will be made in a more timely fashion and not hamper the progress of the project. The policy authority expert needs to be familiar the SDTS to present options to policymakers. There is a learning curve associated with the SDTS. Initially, team members should spend time studying the SDTS literature, reading articles, examining case studies, attending workshops, experimenting with software, and so on. Existing profiles and case studies provide excellent examples of the application of the standard.