Gemeldete Probleme aus Prüfläufen der AdV Testsuite

Die zu den unten gemeldeten Prüfnummern vorhandenen Fehler in der NAS-GML Struktur von Bestandsdaten wurden VertiGIS bereits gemeldet und sind bereits analysiert und registriert. Wie bemühen uns um eine baldige Korrekturmöglichkeit.

Hinweise bzgl. der Aktualisierung dieses Knowledge Base Artikels:

Über die Option "Folgen" erhalten Sie aktiv eine Information wenn sich inhaltliche Änderungen, z.B. Hinzufügen von gemeldeten Testfällen bzw. Änderungen bei gemeldeten Testfällen ergeben sollten. In einem Kommentar (siehe unten) wird dann die erfolgte Änderung dann näher beschrieben.

DE.11001.G.a.001 Im Bereich der Flurstücksgrenze existiert eine Lücke bzw. Überschneidung in der Flächendeckung (DEV 181678)

-> Es existiert tatsächlich keine Lücke bzw. Überschneidung in der Flächendeckung, allerdings werden in den Flurstücksgrenzen der  beteiligten Flurstücken die jeweiligen Linienstücke uneinheitlich mit bzw. ohne CompositeCurve-Elementen in den NAS-Daten abgebildet. Entfernt man die CompositeCurve-Tag-Klammerung händisch aus der NAS-Datei, liefert die ADV-Testsuite für das Testkriterium DE.11001.G.a.001 keine Meldung mehr. Die Geometrie lässt sich im 3A Editor durch neue Generierung (z.B. Stützpunkt rein/raus) korrigieren. Siehe auch DE.40000.G.a.001

Hinweis: Die Ergebnisse des Testkriteriums DE.11000.G.a.001 können sich auch auf tatsächlich vorhandene, d.h. "echte" Lücken und Überlappungen beziehen.

Beispiel:

...

DE.11001.G.a.002 Die Festlegung der Flurstücksgrenze ist fehlerhaft (DEV 166079)

Für die Geometrietypen "LineStringSegment" dürfen nur zwei Positionen angegeben sein, für "Arc" müssen immer drei Positionen angegeben sein

-> Es wird die Einhaltung folgender Konsistenzbedingung für Flurstücke des AAA-Modells 6.0.1 überprüft: Jede Linie ist genau durch zwei Positionen bestimmt. Siehe auch DE.72001.G.a.002

fehlerhaft:

korrekt:

Die fehlerhafte Form des Ablegens der Geometrie kann nicht sicherstellen, dass das generelle Thema Flurstuecke_DLKM eingehalten wird. Allein aus diesem Grunde muss die Geometrie des Flurstücks je Grenzabschnitt zu den jeweils benachbarten Flurstücken aufgeteilt sein.

DE.31001.G.b.001 Im Bereich des Gebäudes ist die Identität der gemeinsam genutzten Geometrie auf Curve-Ebene nicht gegeben. Gemeinsame Linien benachbarter Objekte der Gebäude, Bauteile bzw. Besonderen Gebäudelinie müssen nicht nur identische Liniensegmente aufweisen, sondern auch auf Curve-Ebene identisch unterteilt sein. (DEV 163533)

 -> Gemeinsame Linien benachbarter Objekte... müssen auch auf Curve-Ebene identisch unterteilt sein. In den untersuchten Fällen waren die Stützpunkte gemeinsamer Linien von benachbarten Objekten innerhalb des Themas "Gebäude DLKM" nicht in identischen Curves abgelegt. Die Identität auf Curve Ebene gilt dabei nur bzgl. solcher Objekte, welche sich in einem obligatorischen Thema mit dem Gebäude-Thema befinden. Siehe auch DE.50001.G.b.002

Hinweise:

Hier werden z.Zt. (18.01.2022) von der AdV Testsuite fälschlicherweise auch Objekte gemeldet, die sich nicht beide innerhalb des obligatorischen Themas befinden.

Es kann sich auch um tatsächlich fehlende Stützpunkt in den Geometrien handeln.

DE.40000.G.a.001 Im Bereich der Grenzen der Tatsächlichen Nutzung existiert eine Lücke bzw. Überschneidung in der Flächendeckung (DEV 181685)

-> Es existiert tatsächlich keine Lücke bzw. Überschneidung in der Flächendeckung, allerdings werden die Grenzen der beteiligten Objekten der Tatsächlichen Nutzung uneinheitlich mit bzw. ohne CompositeCurve-Elementen in den NAS-Daten abgebildet. Entfernt man die CompositeCurve-Tag-Klammerung händisch aus der NAS-Datei, liefert die ADV-Testsuite für das Testkriterium DE.40000.G.a.001 keine Meldung mehr. Die Geometrie lässt sich im 3A Editor durch neue Generierung (Stützpunkt rein/raus) korrigieren. Siehe auch DE.11001.G.a.001

Hinweis: Die Ergebnisse des Testkriteriums DE.40000.G.a.001 können sich auch auf tatsächlich vorhandene, d.h. "echte" Lücken und Überlappungen beziehen.

Beispiel:

...

DE.50001.G.b.002 Im Bereich des Bauwerkes ist die Identität der gemeinsam genutzten Geometrie auf Curve-Ebene nicht gegeben. Gemeinsame Linien benachbarter Objekte der Bauwerke bzw. Einrichtungen müssen nicht nur identische Liniensegmente aufweisen, sondern auch auf Curve-Ebene identisch unterteilt sein. (DEV 163533)

 -> Gemeinsame Linien benachbarter Objekte... müssen auch auf Curve-Ebene identisch unterteilt sein. In den untersuchten Fällen waren die Stützpunkte gemeinsamer Linien von benachbarten Objekten innerhalb des Themas "Bauwerke DLKM" nicht in identischen Curves abgelegt. Die Identität auf Curve Ebene gilt nur bzgl. der Objekte, welche sich in einem obligatorischen Thema mit dem Bauwerke-Thema befinden (s.o.). Siehe auch DE.31001.G.b.001

Hinweise:

Hier werden z.Zt. (18.01.2022) von der AdV Testsuite fälschlicherweise auch Objekte gemeldet, die sich nicht beide innerhalb des obligatorischen Themas befinden

Es kann sich auch um tatsächlich fehlende Stützpunkt in den Geometrien handeln.

Beispiel: Die gemeinsam genutzte gelb markierte Linie der Bauwerke Carport und Zaun wird in der NAS auf Curve-Ebene unterschiedlich dargestellt:

DE.72001.G.a.002 Die Festlegung der Grenze eines Objektes Bodenschätzung ist fehlerhaft (DEV 181761)

Für die Geometrietypen "LineStringSegment" dürfen nur zwei Positionen angegeben sein, für "Arc" müssen immer drei Positionen angegeben sein

-> Es wird die Einhaltung folgender Konsistenzbedingung für die Bodenschätzung des AAA-Modells 6.0.1 überprüft: Jede Linie ist genau durch zwei Positionen bestimmt. Siehe auch DE.11001.G.a.002

fehlerhaft:

korrekt:

DE.00001.A.a.007 Unzulässige Art der Fachdatenanbindung (DEV 183577)

NRW nutzt zurzeit nur eine Fachdatenverbindung im Namensraum der AdV. Diese ist gemäß GeoInfoDok eine Fachdatenverbindung vom Fachobjekt zum Objekt AA_Antrag. Allerdings ist die nach NRW-Vorgabe verwendete Form der Art "urn:adv:fachdatenverbindung:AA_Antrag" nicht konform zu den Vorgaben der
GeoInfoDok.

Die AdV definiert in der GeoInfoDok 7 die zukünftig die zukünftig bundesweit im Namensraum urn:adv:fdv vorgegebenen Fachdatenverbindungen.

Beispiel einer unzulässigen Art der Fachdatenverbindung:

Die Korrekturen werden im Rahmen der Migration nach GID 7 stattfinden.

DE.02000.G.a.004 Unzulässige Verwendung von GM_CompositeCurve (DEV 161223)

Bei AA_Liniengeometrie wird GM_CompositeCurve nur verwendet, wenn die Anzahl der enthaltenen GM_Curve mindestens 2 ist. Für jedes Feature einer Objektart, bei der AA_Liniengeometrie erlaubt ist (substituierbar für adv:AU_KontinuierlichesLinienobjekt oder adv:AU_Objekt) prüfen, ob count(adv:position/gml:CompositeCurve/gml:curveMember/*)!=1

-> für linienartige AU_Objekte (unabhängige Geometrie, nimmt also an keinen topologischen Beziehungen teil, z.B. AX_UntergeordnetesGewaesser) gilt die Regel, dass gml:CompositeCurve nur verwendet werden darf, wenn sie größer gleich zwei gml:Curves enthält.

Beispiel: nur eine CompositeCurve in der Geometrie vorhanden:

DE.02000.G.a.008  Prüfung der Geometrien auf Konformität zu ISO 19107

Dazu wird jede Geometrie mit deegree und JTS validiert. Weiterhin wird geprüft dass in einer Surface enthaltene Polygon Patches verbunden sind, dass in einem CurveSegment zwei aufeinander folgende Punkte nicht dieselben Koordinaten haben, und dass die Geometrie die isSimple() Prüfung von JTS besteht.

Verwendung nicht-standardkonformer Geometrien Ostwert: ... , Nordwert: ...

-> ggf. Vollkreisdefinition (Circle) für ein punktförmiges Objekt (z.B. Baum) vorhanden
-> Verwendung von Multicurve statt Curve bei linienförmigen Objekt, normalerweise wird Multicurve nur bei disjunkten Linien oder Flächen definiert.

DE.00001.A.a.011 Fehlerhafte Kodierung von Maßeinheiten Ostwert: ... , Nordwert: ... (DEV 163523)

-> alle @uom genügen folgendem regulären Ausdruck: "urn:adv:uom:.*", korrektes Beispiel: <objekthoehe uom="urn:adv:uom:m">3</objekthoehe>
-> es wurde ein Hash-Zeichen (#) statt des Doppelpunktes bei der metrischen Angaben Angabe z.B. bei der relativen Höhe zu Grenzpunkten "urn:adv:uom:.#" aufgefunden.

Beispiel

falsch: <relativeHoehe uom=http://www.adv-online.de/uom/uom.xml#m>0.7</relativeHoehe>

korrekt: <objekthoehe uom="urn:adv:uom:m">3</objekthoehe>

DE21001.F.c.003 Es ist zu prüfen, ob der Zeitpunkt qualitaetsangaben.herkunft.processStep.dateTime (falls vorhanden) fachlich plausibel ist.

Folgende Bedingung müssen erfüllt sein:
a) Bestandsobjekt: qualitaetsangaben.herkunft.processStep.dateTime < Lebenszeitintervall beginnt < Zeitpunkt des Testlaufs
b) Fortführungsobjekt, neues Objekt: qualitaetsangaben.herkunft.processStep.dateTime < Zeitpunkt des Testlaufs
c) Fortführungsobjekt, geändertes Objekt: Lebenszeitintervall beginnt < qualitaetsangaben.herkunft.processStep.dateTime < Zeitpunkt des Testlaufs

-> Falls a) gemeldet wird, so ist die Erklärung für das Phämomen in einer geringfügigen Zeitdifferenz zwischen den "Uhren" im 3A Editor und im 3A Server zum Zeitpunkt der Fortführung zu erklären. Da die Zeitangabe in den Qualitätsangaben des Objektes im Gegensatz zu der Zeitangabe beim Lebenszeitinterlvall (LZI) des Objektes nicht durch den 3A Server gesetzt werden, sondern vom 3A Editor aus dem Ff-Auftrag übernommen werden, kann es bei einem zeitlich "vorlaufendem" 3A Server zu einem etwas früheren Lebenszeitintervall des Objektes selbst mit einer etwas späteren Angabe des Erfassungszeitpunktes bei den Qualitätsangaben gekommen sein.

DE.21007.F.a.001 Dem Buchungsblatt ist keine Buchungsstelle zugeordnet

Es existieren Buchungsblätter, auf denen keine Buchungsstellen mehr vorhanden sind. Die Ursache warum einzelne Buchungsblätter nicht korrekt gelöscht, d.h. historisiert wurden ist unklar.

Die Korrektur ist durch folgende Vorgehensweise möglich, siehe:

Buchungsblätter löschen, auf denen keine Buchungsstellen mehr vorhanden sind

Zur Einsicht in die bereits behobenen Probleme und ChangeRequests verweisen wir generell auf das

VertiGIS Product Changelog