Ansätze und Vorgehen zur Qualitätssicherung der 3D-Modelle der LandesvermessungsverwaltungenClemens Portele, interactive instruments GmbHmit Unterstützung durch Kai-Uwe Gierse, Geobasis NRWWorkshop 3D-Stadtmodelle, 08.11.2016
3D-Gebäudemodelle der Landesvermessung
Eckdaten
Umfang • knapp 53 Mio. oberirdische Gebäude
Inhalt • Geometrie: LoD1 - einfache Klötzchen mit Flachdach, ETRS89/UTM + DHHN92• Gebäudegrundriss in der Regel aus der amtlichen Liegenschaftskarte• Höhe des Gebäudes• Gebäudefunktion• Qualitätsangaben (Metadaten)• Amtlicher Gemeindeschlüssel• Objektidentifikator• Name (wenn geführt)
Organisation • Pflege der Daten durch jede Landesvermessungsverwaltung• „Zentrale Stelle Hauskoordinaten und Hausumringe“ (ZSHH) bei Geobasis NRW bündelt
die Datenlieferungen der Bundesländer• Abgabe durch ZSHH bei länderübergreifenden Lieferungen• Einheitliches Gebühren- und Lizenzmodell
Datenabgabe • Shape oder CityGML 1.0• In Kacheln mit einheitlicher Kachelseitenlänge, z.B. 1 km
Typische Anwendungsbereiche
§ Umsetzung der EU-Umgebungslärmrichtlinie§ Erstellung von Solarpotenzialkatastern§ Modell- und Netzplanungen im Mobilfunkbereich§ Präsentation von Bauvorhaben und ihren Auswirkungen auf die Umgebung§ Grundlagendaten zur Visualisierung von städtebaulichen Planungen§ Abbildung realistischer Szenarien im Bereich der Fahrzeugnavigation
Spezifikationen
§ Produktstandard, Datenformat-beschreibung und AdV-CityGML-Profile standardisieren länderübergreifende Datenabgabe
§ LoD1 und LoD2
LoD1-DE – Qualitätsaspekte
Motivation
3D-Gebäudemodell
(landesweit)
3D-Gebäudemodell
(bundesweit)
Datenprüfung &
-integration
Bundesland ZSHHDatenabgabe
§ Prüfung auf Datenkonformität zu Produktstandard, Datenformatbeschreibung, etc.
§ Prüfungen:§ Schemavalidierung à Datenlieferung valide gegen XML-Schema?§ Leerkacheln à Datenlieferung vollständig?§ stichprobenartige Inhaltsprüfung à Datenlieferung vorgabenkonform?
§ hoher Prüfaufwand, da manuell, zeitintensiv und fehleranfällig § Bedarf der ZSHH nach automatisierter Prüfung der LoD-Daten
Prüfplan
Umfang
§ Initiale Implementierung der Testkriterien zu § „Schemaprüfung“§ „Profilkonformität“
§ für § LoD 1§ LoD 2
§ Spätere Erweiterung um die Testkriterien der Kategorien § „Geometrie“§ „Semantik“§ „externe Referenzen“vorgesehen
Testkriterien zur Profilkonformität (1/2)
§ Attributive Prüfungen§ keine leeren Attribute§ Attribute vollständig? Besitzt jedes Gebäude/Bauteil korrekte Pflichtattribute§ Attribute richtig zum Gebäude/Bauteil zugeordnet§ korrekte Belegung
§ generische Attribute/Metadaten (nur Werte der Codeliste) § Attribut function (nur Werte der Codeliste)§ Attribut roofType (nur Werte der Codeliste)§ Attribut Gemeindeschlüssel
§ zulässige Belegung des Attributs Gebäudehöhe§ minimale, maximale Gebäudehöhe (Warnung)§ (keine) länderspezifischen Attribute§ core:informationSystem bei externen Referenzen
Testkriterien zur Profilkonformität (2/2)
§ Gebäudeteile§ gehört nur zu einem Gebäude§ Teil eines Gebäudes§ keine Unterteilung von Gebäudeteilen
§ ID und Name§ korrekte OID?§ ist der Dateiname korrekt?§ <gml:name> bei Citymodel vorhanden? Sind die Werte zulässig?
§ Bounding Box§ Envelope pro CityGML-Datei§ CRS nur in Envelope bei CityModel
§ Geometrie§ 3 Nachkommastellen für Koordinaten§ keine Kreisbögen im Datensatz § keine Referenzen auf Geometrie anderer Objekte
Wesentliche Anforderungen an die Prüfsoftware§ Test der Datenlieferung eines Landes oder eine Teilmenge der Kacheln
§ Datenlieferungen sind vollständig und nicht nur stichprobenhaft zu testen§ Von allen beteiligten Ländern nutzbar, plattformunabhängig
§ Prüfsoftware über versionsverwaltetes Repository online bereitgestellt§ Lokale Tests möglich (aufgrund der Datenmenge und des Datenschutzes)
§ Implementierung als Webanwendung§ Bedienung clientseitig über einen Browser (IE, Firefox und Chrome), nur JavaScript und CSS§ Prozessierung der Daten serverseitig, Verwendung von Java 8
§ Laufzeiten im Wesentlichen linear skalierend (durch Parallelisierung der Abläufe und/oder Verbesserung der Hardwareausstattung)§ Zeitbedarf für das Testen aller Länder <20 Tage, besser <10 Tage
§ Testberichte§ mit Aussage zu jedem durchgeführten Test und ggf. nicht anwendbaren Tests§ Fehlersituationen klar und verständlich beschrieben, mit Identifizierung der betroffenen
Gebäude und Datenelemente§ Statistiken
Datenfluss mit Prüfsoftware
3D-Gebäudemodell (landesweit)
3D-Gebäudemodell (bundesweit)
Korrekturen
Integration
Länderübergreifende Datenabgabe
Vermessungsverwaltung(Bundesland)
ZSHH
Prüfung
Prüfung
Umsetzung der Prüfsoftware auf Basis von ETF und BaseX
ETF: XtraServer und ESDIN – der Ausgangspunkt (2005-2009)
§ Tests für OGC-Dienste und GML-Daten§ ETF als dünne Schicht (Skripte, SoapUI-Erweiterungen)§ Lokale Testausführung in SoapUI§ Open-Source
soapUI
ETF(Test Framework)
ESDIN-Tests
(soapUI projects)
soapUI
XTF(Test Framework)
XtraServer-CI-Tests
(soapUI projects)
ETF: Weiterentwicklung in verschiedenen Projekten
§ Weiterentwicklung des Frameworks, modulare Architektur
§ Webanwendung§ Einfaches, übergreifendes GUI§ Ohne lokale Installation§ REST API§ Mehrsprachig (DE, NL, EN)
§ Hilfreiche Testberichte (HTML und XML)§ Unterstützung für BaseX für
performantes Testen großer XML-Dokumente
§ Geometrie (2D): Validierung, Prädikate in XQuery, Indizierung
soapUI(for web services)
BaseX(for XML
data)
ETF Core(Test Framework)
Tests(soapUI projects and/or Xquery)
ETF Web App(Web Application)
ETF: Einsatzbeispiele
ETF: INSPIRE Validator (in Entwicklung)
ETF: Einfache Verwendung durch Docker
Testrahmen
Testprojekt
Übersicht und Begriffe
Prüfsoftware
Testfall TestkriteriumTestfallTestfallTestkriteriumTest-kriterium
Testobjekt Testbericht
Demo der Prüfsoftware
§ Demo§ mit „Testdatensatz 3D-Gebäudemodell LoD1 Deutschland“ (AdV-Webseite)§ mit geändertem Testdatensatz mit einzelnen Fehlern
§ <gen:stringAttribute name="DatenquelleBodenhoehe"><gen:value>1500</gen:value></gen:stringAttribute>§ <bldg:function>51009_16108888</bldg:function>§ <gml:posList srsDimension="3">647770.0987 5649630.678 ...
§ Ablauf§ Übersicht über den Webclient§ Durchführung von Tests§ Lesen von Testberichten
Beispiel der Umsetzung eines Testkriteriums<Assertion id="Profil.Attribute.2210.1" severity="error"><name>Höhenangaben vollständig</name><shortDescription>Ist das Pflichtattribut zur Höhe vorhanden?</shortDescription><description>Besitzt jedes Gebäude die Höhe des Gebäudes aus der Differenz der Dachhöhe und der Bodenhöhe (bldg:measuredHeight)? Bei einem Gebäude mit Bauteilen muss die Information beim Bauteil angegeben sein, ansonsten beim Gebäude.</description><specReference>Prüfplan Gebäudemodelle Version 1.2, Prüfnummer 2210 Zeile 1 / 2270 Zeile 3</specReference><expression>let $featuresWithErrors := ($buildings[not(bldg:measuredHeight) and not(bldg:consistsOfBuildingPart/bldg:BuildingPart)] | $buildingparts[not(bldg:measuredHeight)])[position() le $limitErrors]
return (local:statistics-info($featuresWithErrors), let $text := 'Ohne Wert für die Höhe des Gebäudes aus der Differenz der Dachhöhe und der Bodenhöhe.'return local:object-messages($featuresWithErrors, $text))</expression>
</Assertion>
Laufzeiten mit verschiedenen Datensätzen – Übersicht
Testsystem A A A A B
Datensatz LoD1 NW, BN LoD1 HH LoD1 MV LoD2 NW 2014 LoD2 NW 2012
Gesamt [min] 1 8 49 414 480
Kacheln 158 879 6580 12466 31228
Gebäude [1000] 119 373 1130 3800 9275
Bauteile [1000] 0 106 0 1027 3646
Größe [GB] 0,61 5,6 17,1 106,4 157
XML-Nodes [10^6] 15 182 607 3011 3217
Laufzeiten mit verschiedenen Datensätzen – nach Testkriterien
0
500
1000
1500
2000
2500
3000
3500
4000
4500
5000
Geb
äude
sam
mel
nBa
utei
le s
amm
eln
Stat
istik
ers
telle
nTe
st B
asis
.Ver
gl.0
100
Test
Pro
fil.A
tt.21
00Te
st P
rofil
.Att.
2210
.1Te
st P
rofil
.Att.
2210
.2Te
st P
rofil
.Att.
2210
.3Te
st P
rofil
.Att.
2210
.4Te
st P
rofil
.Att.
2210
.5Te
st P
rofil
.Att.
2210
.6Te
st P
rofil
.Att.
2210
.7Te
st P
rofil
.Att.
2210
.8Te
st P
rofil
.Att.
2210
.9Te
st P
rofil
.Att.
2220
.1Te
st P
rofil
.Att.
2220
.2Te
st P
rofil
.Att.
2220
.3Te
st P
rofil
.Att.
2220
.4Te
st P
rofil
.Att.
2230
Test
Pro
fil.A
tt.22
40Te
st P
rofil
.Att.
2250
Test
Pro
fil.A
tt.22
60Te
st P
rofil
.Att.
2270
.1Te
st P
rofil
.Att.
2270
.2Te
st P
rofil
.Att.
2270
.3Te
st P
rofil
.Att.
2270
.4Te
st P
rofil
.Att.
2270
.5Te
st P
rofil
.Att.
2270
.6Te
st P
rofil
.Att.
2270
.7Te
st P
rofil
.Att.
2270
.8Te
st P
rofil
.Att.
2270
.9Te
st P
rofil
.Att.
2270
.10
Test
Pro
fil.A
tt.22
70.1
1Te
st P
rofil
.Att.
2270
.12
Test
Pro
fil.A
tt.22
70.1
3Te
st P
rofil
.Att.
2270
.14
Test
Pro
fil.B
aute
il.23
10.1
Test
Pro
fil.B
aute
il.23
10.2
Test
Pro
fil.B
aute
il.23
20Te
st P
rofil
.Bau
teil.
2330
Test
Pro
fil.N
ame.
2410
Test
Pro
fil.N
ame.
2420
Test
Pro
fil.N
ame.
2430
Test
Pro
fil.B
Box.
2510
Test
Pro
fil.B
Box.
2520
.1Te
st P
rofil
.BBo
x.25
20.2
Test
Pro
fil.G
eom
.261
0Te
st P
rofil
.Geo
m.2
620
Test
Pro
fil.G
eom
.263
0.1
Test
Pro
fil.G
eom
.263
0.2
Laufzeiten pro Testkriterium in Sekunden
Verwendung eines Git-Repositories für die Pflege der Testkriterien, Dokumentation, Verfolgung von Issues, usw.
Stand & Einsatz der Qualitätssicherungskomponente (QSK)§ QSK steht sowohl der ZSHH als auch allen Bundesländern zur
Verfügung§ Einsatz
§ Datenausgangskontrolle beim Bundesland§ Dateneingangskontrolle bei der ZSHH
§ Ziel: Qualitätssteigerung der LoD-Daten lokal und zentral !
3D-Gebäudemodell
(landesweit)
3D-Gebäudemodell
(bundesweit)
Datenprüfung &
-integration
Bundesland ZSHHDatenabgabe
ggf. Mängelmeldung & Korrekturlieferung
LoD1-DE – Qualitätsaspekte
Stand & Einsatz der Qualitätssicherungskomponente (QSK)
Stand: 11/2015 Stand: 11/2016
fehlerfrei *
fehlerhaft *
* gem. Prüftool
LoD1-DEbei der ZSHH
LoD1-DE – Qualitätsaspekte
Fazit Qualitätssicherungskomponente (QSK)
§ bundesweiter Einsatz der QSK
§ automatisierter Prüfprozess verringert Prüfaufwand
§ ausschließlich Annahme von fehlerfreien Daten durch die ZSHH
§ Qualitätssteigerung der Daten!
§ aktive Datenverbesserung anstatt Reaktion auf Kundenrückmeldungen
LoD1-DE – Qualitätsaspekte
Weiterentwicklung Qualitätssicherungskomponente (QSK)
§ bisher implementiert: Schema- & Profilprüfungen
§ laufend: Sammlung neuer Testkriterien bei ZSHH & AdV-PG 3D-Geobasisdaten
§ entsprechend Fortschreibung des Prüfplans und Implementierung in QSK
§ aktuell umfangreiche Arbeiten an Prüfplan im Bereich Geometrie- & Semantikprüfungen
§ geplante Erweiterung der QSK um diese Prüfungen in 2017/2018
LoD1-DE – Qualitätsaspekte