1 / 21

Referent: Matthias Heide

Wenn Geodaten und Fachanwendungen nicht zusammenpassen: Datenaufbereitung und Objektbildung mit CITRA (CISS). Referent: Matthias Heide. Anforderungen der Anwender - ( Wozu Softwareschnittstellen?). 1. Entwicklung von offenen Systemen mit Basisfunktionen

aine
Télécharger la présentation

Referent: Matthias Heide

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Wenn Geodaten und Fachanwendungen nicht zusammenpassen: Datenaufbereitung und Objektbildung mit CITRA (CISS) • Referent: Matthias Heide

  2. Anforderungen der Anwender -(Wozu Softwareschnittstellen?) • 1. Entwicklung von offenen Systemen mit Basisfunktionen  spezielle Funktionen sind wünschenswert  Fachschale, Modul, ... als branschenspezifische Lösung • 2. Zusammenarbeit von verschiedenen Fachbereichen  Selektion von Daten, relevante Fachinformationen aus unterschiedlichen Gebieten  Verbindung zwischen den Datenmodellen • 3. „...Eine reine Konvertierung von GIS Formaten sind allein kein Qualitätsmerkmal von Schnittstellensoftware...“

  3. Ziel-System Quell-System Geodaten-server Worin bestehen die Lösungen? Integration Austausch Verschiedene Datenbestände Ein Datenbestand - Analyse - Aufbereitung - Modellierung Anzahl der Benutzer ? Performance ? Redundanz? Sicherheit ?

  4. Komplexität Migration Datenübernahme Einfache Konvertierung Daten-Austausch (auf unterschiedlichem Niveau) • Fachschalen erfordern mind. eine Konvertierung • Qualitätsanspruch steigt mit der Komplexität  Kosten Analyse und damit Kostenabschätzung

  5. Einfache Datenkonvertierung • insbesondere bei einer einmaligen Übernahme der Daten • 1 : 1 Umsetzung • meist nur Graphik • aufwendige Auseinandersetzung mit den Datenmodellen in Q- und Z-System entfällt • Ziel: Kosten sollen gering gehalten werden (kleinere Projekte)

  6. Datenübernahme • etwas mehr als eine reine Graphik-Umsetzung • gewisse Modellierung erfolgt bereits • einfache Objektbildung • geringere Komplexität als Migration • Definitionen beschreiben den Aufwand unzureichend  verläßliche Kostenabschätzung Testdatenbestand zur Analyse Plot dieses Testdatenbestandes Datenmodellbeschreibung des Ausgangssystems ggf. Beschreibung des Zieldatenmodells

  7. Datenmigration • komplexe Modellierung bei sehr großen Datenmengen • Erzeugung neuer Objekte • möglichst keine Daten sollen beim Systemwechsel verloren gehen • Ziele: • Qualitätssteigerung:Erstellung von Regeln zur Datenaufwertung und somit Nutzensteigerung, Vermeidung von Nachbearbeitung • Entdeckung und automatisierte Bereinigung von Fehlern in der Datenquelle (unter Vergleich von Q- und Z-System) • betroffen sind mittlere und große Versorgungs-unternehmen und Behörden

  8. Datenintegration • Datenintegration & Geodatenserver • Ziel: • Beschaffung, Speicherung und Fortführung komplexer heterogener Datenbestände • Verzicht auf ein einheitliches GIS (Datenmodell) • Beschreibung der Daten durch Kataloge • Daten mit verschiedenem räumlichen Bezug sowie Inhalten und Qualität sollen den Nutzer erreichen • Modellierung während der Abgabe an den Benutzer nicht nur nach inhaltlichen Aspekten

  9. Datenintegration • Vorteil: Redundanzfreiheit • Nachteil: Schnelligkeit insbesondere in Netzwerken Performance-Schwierigkeiten • Anwendung im Intra- und Internet • vom GIS unabhängige Speicherung der Daten durch entsprechende Geodatenbankverwaltungssoftware bereits im Angebot

  10. Datenanalyse • Analyse hinsichtlich der Graphik, Attributierung und Objektstruktur • Datenstruktur in Q- und Z-System • Hindernisse bei der Abbildung im Z-System • Datenaufbereitung

  11. Quelle Ziel Attribut 1 Attribut n Attribut 1 Attribut n Datenaufbereitung • Graphik (Symbole, Beschriftung) • Modifikationen der Sachdaten Kontrolle der Datenkonsistenz

  12. Bach Modellierung • Sachdaten (Umbenennung von Feldern...) • Geometrie (Umwandlung von Primitiven...) • Flächenbearbeitung • Herstellen von Beziehungen • Objekte modifizieren (trennen, verschmelzen...) Beispiel:

  13. Datenaufbereitung und Objektbildung mit CITRA (Fa. CISS) • CITRA = eigenes Datenformat + Software • Datenformat ist neutral (ASCII Format kann gelesen und analysiert werden) • Objektorientiert • „Drehscheibe zwischen den Systemen“ • Standardisierung und Automatisierung von wiederkehrenden Problemen • „Lesen“ und „Schreiben“ durch Konfigurationstabellen

  14. Der CITRA-Kreis

  15. Objektdefinition Neutraler Objektname (11 Zeichen) Geometrieteil beginnt mit PICTURE beliebig viele unterschiedliche grafische Primitive Koordinaten keine Angabe des Styling Attributteil Attributsegmentname (11 Zeichen) bei gleicher Sachdatenstruktur ein und derselbe Attributsegmentname ATTSEG=CITRA_ATT_1 Nr Feldname <Datentyp>:Feldinhalt 12 Straße C(24):Barbarossastraße

  16. Beispiel-Objekt Beginn Attributteil FACDEF ATTSEG = CITRA_ATT_1 12 STRAßE C(42) : Barbarossastraße PICTURE FTEXT = CITRA_FTEXT FLDID = 12 2518872.838 5686469.762 LINE = CITRA__LINE 2518864.95 5686472.05 2518866.74 5686472.83 2518865.65 5686475.32 2518864.95 5686472.05 TEXT = CITRA__TEXT 2518872.838 5686472.762 `CISS TDI GmbH` ENDFAC Geometrie-teil Ende

  17. Beispielobjekt - und so siehts dann aus CISS TDI GmbH Barbarossastraße

  18. Konfigurationstabellen • Logik und Steuerung • Ein-/ Ausblenden der zu konvertierenden Daten • eventuelle Belegung mit Defaultwerten • Angabe zu Farbe, Font, Symbolgröße und Ausrichtung • keine automatische Konfigurationserweiterung • „Was nicht in der Konfigurationstabelle vorkommt, bleibt unverändert und wird gemeldet“ • Protokollierung von nicht erfaßten Objekten • Kapselung durch Module (standardisierte Algorithmen) • Prüfung der Belegung von Attributfeldern • Suche nach und Beseitigung von Redundanz • Bildung oder Veränderung von Objektbeziehungen (Schriftplazierung)

  19. Probleme • unterschiedliche Datenstrukturen: • ein Quell-Objekt verfügt über unterschiedliche Attribute 50 kV • Datenfehler Fehler bei der Erfassung  deshalb: Analyse des Gesamtbestandes auf Grundlage einer Objektabbildungsvorschrift

  20. Wie funktioniert die Zusammenarbeit mit Firmen zu dessen Produkten Sie Schnittstellen entwickeln? • „distanziert bis gut“ • Vertraulichkeit und Neutralität • Loyalität • interne Informationen werden ausgetauscht bevor die Software auf dem Markt erscheint • Garantie bestimmter Information durch Exklusiv-Verträge

  21. Perspektiven • Zahl der Geodatennutzer wird zunehmen • Normierungs- und Koordinierungbestrebungen vs. Vergrößerung der Individualität durch Komponenten-technologie • Widerspruch: • „...individuelle Modellierung kann nicht durch eine Definition der Datengrundlage gelöst werden...“ • Verbesserung: • strikte Trennung der Datenbestände (Geodaten) von Visualisierungs- und Bearbeitungswerkzeugen • Nutzung eines leistungsfähigen Datenservers (Verwaltung unabhängig vom GIS durch standardisierte Datenbank)

More Related