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