Die zu den unten gemeldeten Prüfnummern vorhandenen Fehler in der NAS-GML Struktur von Bestandsdaten wurden VertiGIS bereits gemeldet und sind analysiert und registriert. Wir bemühen uns um eine baldige Korrekturmöglichkeit.
Sofern DataUpdater bereitgestellt werden, sollten diese am Ende der Produktion unter GID 6, aber vor Migration der Daten nach GID 7 eingesetzt werden. Ein früherer Einsatz ist möglich, ersetzt jedoch nicht eine Wiederholung vor der Migration.
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 näher beschrieben.
Übersicht über die gemeldeten Prüffälle:
|
Prüffall |
Korrekturmöglichkeit GID 6.0.1 |
Korrektur GID 7 |
|
Typ 1: Vom Bearbeiter zu beheben Typ 2: DataUpdater 3A-DataUpdater-AdvtSegmentDasher verfügbar |
Korrekturfunktion |
|
|
DataUpdater 3A-DataUpdater-AdvtSegmentDasher verfügbar |
Korrekturfunktion |
|
|
Softwarekorrektur geplant |
Korrekturfunktion geplant |
|
|
Typ 1: Vom Bearbeiter zu beheben Typ 2: DataUpdater geplant |
Korrekturfunktion geplant |
|
|
Softwarekorrektur geplant |
Korrekturfunktion geplant |
|
|
DataUpdater 3A-DataUpdater-AdvtSegmentDasher verfügbar |
Korrekturfunktion |
|
|
DataUpdater 3A-DataUpdater-FDVTransformer verfügbar |
- |
|
|
in Abstimmung |
- |
|
|
DataUpdater 3A-DataUpdater-AdvtCompositeCurveRemover verfügbar |
Korrekturfunktion |
|
|
in Abstimmung |
- |
|
|
in Abstimmung |
- |
|
|
in Abstimmung |
- |
|
|
in Abstimmung |
- |
|
|
in Abstimmung |
- |
|
|
individuelle Lösung |
- |
DE.11001.G.a.001 Im Bereich der Flurstücksgrenze existiert eine Lücke bzw. Überschneidung in der Flächendeckung (DEV 181678)
-> Unter dieser Nummer werden 2 Arten von Problemen gemeldet:
- Typ 1: Echte Lücken oder Überschneidungen
- Typ 2: CompositeCurve-Elemente im Umring eines Flurstücks
Bei Problemen vom Typ 2 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
Beispiel:
...
Weiteres Vorgehen zur Korrektur:
Probleme vom Typ 1 sollten durch die Topologie/Vertex-Prüfung gefunden werden und sind vom Bearbeiter zu beheben.
Probleme vom Typ2:
Für GID 6.0.1:
VertiGIS hat zur Lösung des Problems den DataUpdater 3A-DataUpdater-AdvtSegmentDasher für 3A Server Versionen 6.7.2.2 und 6.6.3.4 erstellt. Der DataUpdater muss ggfs. mehrfach aufgerufen werden.
Für GID 7:
Der 3A Server wird um eine Korrekturfunktion ergänzt, die verhindert, dass künftig neue Fehler dieser Art entstehen.
DE.11001.G.a.002 Die Festlegung der Flurstücksgrenze ist fehlerhaft (DEV 166079, DEV 185760)
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.
Weiteres Vorgehen zur Korrektur:
Für GID 6.0.1:
VertiGIS hat zur Lösung des Problems den DataUpdater 3A-DataUpdater-AdvtSegmentDasher für 3A Server Versionen 6.7.2.2 und 6.6.3.4 erstellt. Der DataUpdater muss ggfs. mehrfach aufgerufen werden.
Für GID 7:
Der 3A Server wird um eine Korrekturfunktion ergänzt, die verhindert, dass künftig neue Fehler dieser Art entstehen.
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ützpunkte in den Geometrien handeln.
Beispiel: eine gemeinsam genutzte Gebäudeseite geht über drei Stützpunkte (gelb markiert):
Beim AX_Gebaeude DENW… werden die Koordinaten der Gebäudelinie gespeichert im Format:
Beim Nachbargebäude AX_Gebaeude DENW… werden die Koordinaten der Gebäudelinie gespeichert im Format:
Der Fehler liegt darin, dass für den Bereich des gemeinsamen Linienverlaufes über die drei gelb markierten Stützpunkte in beiden Gebäuden (s.u.) eine identische Curve Unterteilung vorliegen muss. Dies ist nicht der Fall, Beispiel für eine zulässige gemeinsame Curve:
<gml:Curve gml:id="...">
<gml:segments>
<gml:LineStringSegment>
<gml:posList>372728.627 5757390.922 372729.431 5757386.908 372729.462 5757386.923</gml:posList>
</gml:LineStringSegment>
</gml:segments>
</gml:Curve>
</gml:curveMember>
Weiteres Vorgehen zur Korrektur:
Für Korrektur der Daten für GID 6.0.1:
VertiGIS wird dieses Problem mittels Softwarekorrektur lösen.
Für GID 7 wird der 3A Server um eine Korrekturfunktion ergänzt, die verhindert, dass künftig neue Fehler dieser Art entstehen.
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)
-> Unter dieser Nummer werden 2 Arten von Problemen gemeldet:
- Typ 1: Echte Lücken oder Überschneidungen
- Typ 2: CompositeCurve-Elemente im Umring einer Tatsächlichen Nutzung
Bei Problemen vom Typ 2 existiert tatsächlich keine Lücke bzw. Überschneidung in der Flächendeckung, allerdings werden die Grenzen der beteiligten Objekte 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
Beispiel:
...
Weiteres Vorgehen zur Korrektur:
Probleme vom Typ 1 sollten durch die Topologie/Vertex-Prüfung gefunden werden und sind vom Bearbeiter zu beheben.
Probleme vom Typ2:
Für GID 6.0.1:
VertiGIS hat zur Lösung des Problems den DataUpdater 3A-DataUpdater-AdvtTNSurfaceCleaner für 3A Server Versionen 6.7.2.2 und 6.6.3.4 erstellt. Der DataUpdater muss ggfs. mehrfach aufgerufen werden.
Für GID 7:
Der 3A Server wird um eine Korrekturfunktion ergänzt, die verhindert, dass künftig neue Fehler dieser Art entstehen.
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ützpunkte 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:
Weiteres Vorgehen zur Korrektur:
Für GID 6.0.1:
VertiGIS wird dieses Problem mittels Softwarekorrektur lösen.
Für GID 7 wird der 3A Server um eine Korrekturfunktion ergänzt, die verhindert, dass künftig neue Fehler dieser Art entstehen.
DE.72001.G.a.002 Die Festlegung der Grenze eines Objektes Bodenschätzung ist fehlerhaft (DEV 181761, DEV 185760)
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:
Weiteres Vorgehen zur Korrektur:
Für GID 6.0.1:
VertiGIS hat zur Lösung des Problems den DataUpdater 3A-DataUpdater-AdvtSegmentDasher für 3A Server Versionen 6.7.2.2 und 6.6.3.4 erstellt. Der DataUpdater muss ggfs. mehrfach aufgerufen werden.
Für GID 7:
Der 3A Server wird um eine Korrekturfunktion ergänzt, die verhindert, dass künftig neue Fehler dieser Art entstehen.
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:
Weiteres Vorgehen zur Korrektur:
Für GID 6.0.1:
VertiGIS hat zur Lösung des Problems den DataUpdater 3A-DataUpdater-FDVTransformer für 3A Server Versionen 6.7.2.2 und 6.6.3.4 erstellt. Der DataUpdater muss ggfs. mehrfach aufgerufen werden.
Hinweis: Korrekte Parameterdatei notwendig!
Für GID 7:
Die Fachdatenverbindungen werden im Rahmen der Migration berücksichtigt und sind dann im 3A Server 7 korrekt.
DE.00001.R.a.003 AX_HistorischesFlurstueckOhneRaumbezug: Objekt ...nicht vorhanden (DEV 197559)
Ein durch eine Relation referenziertes Objekt muss im Testgegenstand vorhanden sein. Objekte AX_HistorischesFlurstueckOhneRaumbezug haben eine Relation istGebucht auf AX_Buchungsstellen, welche jedoch nicht mehr existieren.
Die Relationen sind zu löschen.
Weiteres Vorgehen zur Korrektur:
In Abstimmung.
DE.02000.G.a.004 Unzulässige Verwendung von GM_CompositeCurve (DEV 161223, DEV 186464)
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:
Weiteres Vorgehen zur Korrektur:
Für GID 6.0.1:
VertiGIS hat zur Lösung des Problems den DataUpdater 3A-DataUpdater-AdvtCompositeCurveRemover für 3A Server Versionen 6.7.2.2 und 6.6.3.4 erstellt. Der DataUpdater muss ggfs. mehrfach aufgerufen werden.
Für GID 7:
Der 3A Server wird um eine Korrekturfunktion ergänzt, die verhindert, dass künftig neue Fehler dieser Art entstehen.
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.
Weiteres Vorgehen zur Korrektur:
In Abstimmung.
DE.02000.G.a.009 Prüfung ob jede Koordinate drei Nachkommastellen besitzt und "." als Trennzeichen für die Nachkommastellen genutzt wird (DEV 152938)
-> Es wurde ein Fortführungsauftrag aus dem 3A- Editor zu Testzwecken in die ADV Testsuite eingelesen. In der Datei wird der Tag anzahlDerNachkomastellen mit 3 angegeben. Dabei wird ein Koordinatenwert zu Punkten, welche in jeweils einer Koordinate an der dritten Nachkommastelle eine 0 aufweisen, nur mit zwei Nachkommastellen ausgewiesen.
Beispiel:
Weiteres Vorgehen zur Korrektur:
In Abstimmung.
DE.00001.A.a.011 Fehlerhafte Kodierung von Maßeinheiten Ostwert: ... , Nordwert: ... (DEV 163523)
-> Es handelt sich um die Angabe des Hash-Zeichens statt des Doppelpunktes bei der Angabe einer relativen Höhe zu Grenzpunkten. Alle @uom genügen folgendem regulären Ausdruck: "urn:adv:uom:.*", korrektes Beispiel: <objekthoehe uom="urn:adv:uom:m">3</objekthoehe>
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>
Weiteres Vorgehen zur Korrektur:
In Abstimmung.
DE.00001.F.a.002 Verstoß gegen KosIT-Vorgabe Lateinische Zeichen Unicode (DEV 182931)
-> Die AdV-Testsuite prüft im Testkriterium DE.00001.F.a.002 gegen die Liste der „Lateinischen Zeichen in Unicode“ Version 1.1.1 vom 27.01.2012 (Quelle: http://xoev.de/latinchars/1_1/latinchars.pdf)
Das Zeichen U+2212 -> Minuszeichen ist nicht Bestandteil dieser Liste und wird daher als fehlerhaft gemeldet. Die Minuszeichen sind vermutlich durch händisches Editieren entstanden.
Beispiel:
Beschreibung einer Erbengemeinschaft in der NAS:
Zu 3.1.1, 3.2, 3.4, 3.5 - in Erbengemeinschaft nach ... - Zu 3.1.1, 3.2, 3.4, 3.5, 3.6 − in Erbengemeinschaft −
Das erste Zeichen ist ein - Bindestrich-Minuszeichen (U+002D) und ist zugelassen. Die beiden Letzten sind jeweils „normale“ mathematische Minus Zeichen (U+2212) und sind nicht zugelassen.
Weiteres Vorgehen zur Korrektur:
In Abstimmung.
DE.21001.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.
Weiteres Vorgehen zur Korrektur:
In Abstimmung.
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
Kommentare
2 Kommentare
28.04.2022:
Die Prüffälle:
DE.00001.A.a.007 Unzulässige Art der Fachdatenanbindung
DE.21007.F.a.001 Dem Buchungsblatt ist keine Buchungsstelle zugeordnet
wurden zum Artikel hinzugefügt.
Hinweise zur Korrekturmöglichkeit wurden hinzugefügt.
Die Prüffälle:
DE.02000.G.a.009 Prüfung ob jede Koordinate drei Nachkommastellen besitzt und "." als Trennzeichen für die Nachkommastellen genutzt wird
DE.00001.F.a.002: Verstoß gegen KosIT-Vorgabe Lateinische Zeichen Unicode, Minuszeichen
wurden zurm Artikel hinzugefügt.
Bitte melden Sie sich an, um einen Kommentar zu hinterlassen.