Beanstandung ohne eigene Fehlermeldung
Ziel
Die aufnehmende Stelle weist Ihre Abgabe zurück, Ihre eigene Validierung meldet aber nichts — Sie können also nichts korrigieren. Diese Seite gibt den kurzen Selbsthilfe-Ablauf, den Sie durchgehen sollten, bevor Sie mit der Fehlersuche im Projekt beginnen. Fokus Baden-Württemberg.
Der Grund ist erfahrungsgemäß fast immer derselbe: Der beanstandete Export stammt aus einem älteren Programmstand, und der zugrunde liegende Fehler ist längst behoben. Zwischen dem Export, der Abgabe, der Prüfung beim Amt und der Rückmeldung vergehen oft Wochen — in dieser Zeit sind mehrere Programmversionen erschienen.
Der Ablauf in vier Schritten
1. Feststellen, womit der beanstandete Export erzeugt wurde
Jede XML-Datei, die VermCad schreibt — auch die Fortführungs- und die Bestandsdatendatei — trägt gleich hinter der XML-Deklaration einen Kommentar mit Programmname, 32/64 Bit, Programmversion und Landesversion. Öffnen Sie die beanstandete Datei in einem Texteditor und sehen Sie sich die ersten beiden Zeilen an; der Kommentar hat die Form
<!--VermCad (64 Bit) | <Versionsnummer> | Baden-Württemberg-->
Notieren Sie außerdem das Dateidatum. Ihren eigenen, aktuell installierten Stand finden Sie in der Titelleiste des Hauptfensters (dort stehen Bit-Version, Programmversion, Landesversion und Benutzer) sowie im Menü Hilfe → Informationen über VermCad... — dort mit Versionsnummer und Versionsdatum.
2. Aktualisieren
VermCad prüft bei jedem Start, ob auf dem Update-Server eine neuere Version bereitliegt. Ist das der Fall, endet die Titelleiste mit => Neue VermCad-Version verfügbar! — dieser Hinweis erscheint bei jedem Benutzer.
Das Update selbst ist dem Hauptnutzer vorbehalten: Nur bei ihm wird die neue Version tatsächlich angeboten oder geladen, und nur bei ihm ist im Vorgaben-Dialog der Reiter Update überhaupt sichtbar, in dem eingestellt wird, wie das Programm reagiert (Nie / Nachfragen / Automatisch); siehe Vorgaben: Update. Wenn Sie den Reiter nicht finden, arbeiten Sie nicht als Hauptnutzer — dann ist das Update dort anzustoßen. Was sich seit Ihrem Stand geändert hat, zeigt Hilfe → Release Notes anzeigen.
3. Frisch validieren und neu exportieren
Projekt mit der aktuellen Version öffnen, Validieren und danach vFE exportieren. Die neue Datei zur Prüfung geben. In den ausgewerteten Supportfällen war die Sache damit fast immer erledigt — eine Nachbearbeitung des Projekts war nicht nötig, weil die Korrekturen im Export selbst lagen.
4. Erst danach tiefer suchen
Tritt der Fehler mit der aktuellen Version erneut auf, lohnt sich die Suche im Projekt:
- Aufbau und Reihenfolge der Ausgabedatei prüfen — ALKIS-Arbeitsabläufe-Aufbau der Erhebungsdaten.
- Objektart, Geometrieart und Pflichtattribute der neu erfassten Objekte prüfen — ALKIS-Arbeitsabläufe-Objektart, Geometrieart und Pflichtattribute.
- Nennt das Fehlerprotokoll ein Objekt, das in der Exportliste des Fortführungsdialogs gar nicht auftaucht, in die erzeugte XML-Datei sehen: dasselbe Objekt kann dort mehrfach enthalten sein. Wann das korrekt ist und wann nicht, steht unter Ein Objekt taucht doppelt in der Datei auf.
- Bleibt es unklar: den aktuellen Projektstand an den Support geben (Support-Kontakt), zusammen mit dem Wortlaut des Fehlerprotokolls und der beanstandeten Datei.
Wenn VermCad beim Export selbst warnt
Nach dem Schreiben der Datei prüft VermCad sie gegen das XML-Schema. Schlägt das fehl, erscheint das Fenster Validierungsfehler:
- Datei "…" wurde exportiert, aber es wurden Fehler bei der Validierung festgestellt.
- Bitte wenden Sie sich vor der Abgabe an den VermCad-Support (Fehlermeldung siehe Status-Balken - rote Fehlerzeile)
Wird zusätzlich eine Bestandsdatendatei geschrieben, beginnt die Meldung entsprechend mit Dateien "…" und "…" wurden exportiert, ….
Diese Meldung nicht übergehen. Sie besagt, dass die Datei nicht schemakonform ist — die aufnehmende Stelle wird sie mit hoher Wahrscheinlichkeit nicht einlesen können. Den vollständigen Wortlaut finden Sie in der roten Fehlerzeile bzw. im Fenster Fehler und Hinweise (F6); geben Sie ihn an den Support weiter, damit die interne Validierung ergänzt werden kann. Erscheint eine solche Meldung schon vor dem Export in der Validierung (Ein Export wäre nicht valide gegen das XML Schema: …), gilt dasselbe.
Typische Fehlerbilder
| Symptom | Ursache | Abhilfe |
|---|---|---|
| Die Simulation beim Amt meldet Fehler, die eigene Validierung nicht. | Der Fehler steckt nicht in den Daten, sondern in der Art, wie sie geschrieben wurden — z. B. eine fehlende Koordinate an einem Präsentationsobjekt, ein falsch berechneter Bogenmittelpunkt beim Alt-Neu-Vergleich oder ein fehlendes Element an einem Linienobjekt. Alle diese Fälle waren Programmfehler und sind behoben. | Programmstand prüfen, aktualisieren, neu exportieren. |
| PunktortTA mit den gleichen UTM-Koordinaten existiert noch — der Löschsatz eines Punktorts wird von der Prüfroutine des Amtes nicht erkannt. | Formale Abweichungen in der NAS-Struktur (Namensraum-Deklarationen, Zeitstempel). Programmseitig korrigiert. | Aktuelle Version, neuer Export. Tritt die Meldung erneut auf: Support. |
| Die Zahlen im Fortführungsnachweis weichen von denen in den Erhebungsdaten ab (z. B. grafisch ermittelte statt berechneter Flächen). | Ausgabe- bzw. Übernahmefehler eines älteren Stands. | Programmstand prüfen; Ausdruck und Export nach dem Update gemeinsam neu erzeugen — ein alter Ausdruck neben einem neuen Export führt in die Irre. |
| Die Abgabe wird mit nummerierten Fehlern zurückgewiesen (z. B. 4501, 7311, 7516/7518). | Die Nummern stammen aus dem Verfahren der aufnehmenden Stelle und sagen für sich genommen nichts über die Ursache. Dahinter standen mehrfach bereits behobene Programmfehler. | Zuerst Schritt 1 bis 3; bleibt der Fehler, den Wortlaut zusammen mit dem Projektstand an den Support geben. |
| Das Fehlerprotokoll nennt ein Objekt, das in der Exportliste nicht vorkommt. | Das Objekt steht mehrfach in der Datei. | In die XML-Datei sehen; siehe ALKIS-Arbeitsabläufe-Aufbau der Erhebungsdaten. |
Was Sie nicht tun sollten
- Die Abgabedatei von Hand nachbearbeiten. Das ist allenfalls ein Notbehelf für einen einzelnen Termin und behebt die Ursache nicht. Beim nächsten Export ist der Eingriff wieder verloren, und ein von Hand geänderter Datensatz lässt sich später nicht mehr nachvollziehen.
- Die Abgabedatei als Beleg für den Datenstand nehmen. Maßgeblich ist der Projektstand; der Support arbeitet grundsätzlich am Projekt und nicht an der Ausgabedatei.
- Updates aufschieben, solange ein Auftrag läuft. Genau in dieser Zeit entsteht der Abstand zwischen dem Stand, mit dem exportiert wurde, und dem Stand, gegen den das Amt prüft.
Siehe auch
- ALKIS-Arbeitsabläufe-Aufbau der Erhebungsdaten — wie die Ausgabedatei aufgebaut ist
- ALKIS-Arbeitsabläufe-Objektart, Geometrieart und Pflichtattribute
- ALKIS-Arbeitsabläufe-Fortführungsfälle und Validierungsmeldungen
- Vorgaben: Update
- Fehler und Hinweise-Das Fenster Fehler und Hinweise · CAD-Arbeitsabläufe-Fehlersuche und Wiederherstellen
- Support-Kontakt