GEO Kanal/INKA

Die folgenden häufig gestellten Fragen (FAQ) wenden sich an Leitstellenanwender, die mit GEO Kanal/INKA arbeiten. Die Fragen sind nach den verschiedenen Modulen gegliedert, mit denen ein Leitstellenanwender arbeitet.

ISYBAU-Import

Welche ISYBAU-Formate können importiert werden?

Der ISYBAU-Import unterstützt sowohl die alten Formate 01/96 und 06/01 als auch die neuen Formate nach XML-2006. Die folgenden Datenbereiche dieser Formate können importiert werden:

0196/0601
- Typ K (Stammdaten Haltungen und Schächte)
- Typ LK (Stammdaten Anschlussleitungen und Anschlusspunkte)
- Typ ST (Stammdaten Sonderbauwerke)
- Typ H (Zustandsdaten Haltungen)
- Typ LH (Zustandsdaten Anschlussleitungen)
- Typ S (Zustandsdaten Schächte)
- Typ Z (Zustandsdaten Sonderbauwerke)
- Typ EY (Ergebnisse hydraulischer Berechnungen zu Haltungen und Schächten)
(nur teilweiser Import: Es werden nur die Zustandsklassen und Auslastungskennwerte für Haltungen importiert)

XML-2006
- Stammdatenkollektive
- Zustandsdatenkollektive
- Hydraulikdatenkollektive

Warum meldet der Import, dass er schon von einem anderen Benutzer verwendet wird?

Der ISYBAU-Import kann nur von einem Anwender gleichzeitig verwendet werden. INKA sperrt daher die Importfunktionalität solange für andere Anwender, bis der Importvorgang des aktuellen Nutzers des Imports abgeschlossen worden ist. In diesem Fall ist daher abzuwarten, bis der andere Anwender seinen Import abgeschlossen hat.

Im Einzelfall kann es passieren, dass INKA einen laufenden Import meldet, obwohl kein anderer Anwender importiert. Dieses Verhalten tritt auf, wenn ein Anwender seinen Import nicht korrekt beendet hat, weil bspw. INKA oder der Rechner selber abgestürzt sind. In diesem Fall kann sich der genannte Anwender bei INKA an- und wieder abmelden, so dass die Sperre wieder aufgehoben wird.

Wenn der Anwender jedoch nicht erreichbar ist und sich daher nicht anmelden kann, kann sich stattdessen auch ein anderer Anwender mit dem INKA-Hauptnutzer (in der Regel INKA oder INKA_MASTER) an INKA anmelden und den Importdialog starten. Hier hat er die Möglichkeit die Sperrung aufzuheben und der Import kann dann durchgeführt werden, indem das Löschen des Eintrags mit „Ja“ bestätigt wird (siehe folgende Abbildung).

Warum meldet der Import, dass er schon verwendet wird, obwohl kein Nutzer importiert und in der Meldung auch kein Nutzer genannt wird (der Anwender ist als Anwender für den ISYBAU-Import eingetragen.)?

Dieses Verhalten kann direkt nach einer Migration der INKA-Datenbank auftreten, die nach einer Update-Installation einer neuen Version der FAA erforderlich ist.

Um den Import wieder freizuschalten, kann sich ein Anwender mit dem INKA-Hauptnutzer (in der Regel INKA oder INKA_MASTER) an INKA anmelden und den Importdialog starten. Hier hat er die Möglichkeit, die Sperrung aufzuheben und der Import kann dann wie gewohnt durchgeführt werden.

Warum dauert der ISYBAU-Import einer XML-2006-Datei so lange bzw. warum reagiert der ISYBAU-Import nicht mehr?

Manchmal erscheint der Meldungsdialog, der auf den Abschluss des Importvorgangs hinweist, hinter dem eigentlichen Importdialog. Dieser Meldungsdialog muss jedoch geschlossen werden, bevor der Importdialog wieder verwendet werden kann.

Um den Meldungsdialog wieder in den Vordergrund zu bringen ist ein beliebiges anderes Fenster zu minimieren. Dies kann auch eine andere Anwendung sein. Durch die notwendige Aktualisierung der Fensterdarstellung gelangt der Meldungsdialog nun in den Vordergrund und es kann wie gewohnt weitergearbeitet werden.

Warum dauert der ISYBAU-Import von Filmdaten in einer XML-2006-Datei so lange?

Der Import von umfangreichen Informationen zu Inspektionsfilmen aus einer ISYBAU-XML-2006-Datei kann derzeit zu unverhältnismäßig langen Bearbeitungszeiten führen. Je nach Umfang der Filmdaten kann dies zwischen wenigen Minuten bis zu mehreren Stunden dauern.

Das Problem wird in einer kommenden Version der FAA korrigiert werden. Bis dahin ist es ggf. erforderlich auf den Import von umfangreicheren Filmdaten zu verzichten. Hierzu sind die Filmdaten aus der ISYBAU-Datei vor dem Import in INKA zu entfernen (beispielweise mit einer Bearbeitungssoftware wie BaSYS). Die übrigen Inspektionsdaten können beibehalten werden.

Warum werden Filmdaten in XML-2006 immer abgewiesen, obwohl diese korrekt sind („XML-0005: Dem Inspektionsobjekt [Objektbezeichnung] des Auftrags [Auftragsbezeichnung] darf nicht mehr als ein Film zugeordnet werden.“)?

Hierbei handelt es sich um einen Fehler im INKA-Import, da die Prüfung der ISYBAU-Datei derzeit bei Filmdaten zu streng ist.

Das Problem wird in einer kommenden Version der FAA korrigiert werden. Bis dahin ist es ggf. erforderlich auf den Import von Filmdaten zu verzichten. Hierzu sind die Filmdaten aus der ISYBAU-Datei vor dem Import in INKA zu entfernen (beispielweise mit einer Bearbeitungssoftware wie BaSYS).

Ab der FAA 2.3.7 darf pro Objekt und Inspektionsrichtung ein Film importiert werden. Der Import der Filmdaten arbeitet jetzt gemäß der Vorgaben der Baufachlichen Richtlinien Abwasser. Sollte der Fehler dennoch auftauchen, überprüfen Sie Ihre installierte FAA Version.

Warum werden Inspektionsdaten nach DIN EN 13508-2 in einer XML-2006-ISYBAU-Datei abgewiesen, die das Kürzel „AEC“ enthalten?

Hierbei handelt es sich um einen Fehler im INKA-Import, da die Prüfung der ISYBAU-Datei derzeit das Kürzel „AEC“ nicht kennt.

Das Problem wird in einer kommenden Version der FAA korrigiert werden. Für bestehende FAA-Versionen existiert ein Patch, der die Prüfung korrigiert und den Import des Kürzels AEC ermöglicht (siehe FAA-Downloadbereich).

Ab Version 2.3.8 ist dieser Fehler behoben.

Wieso sind nach einem Import einer ISBYAU-XML-2006-Datei nicht alle Zustandsdaten der Austauschdatei in INKA vorhanden?

Wenn die Zustandsdaten in der ISYBAU-Austauschdatei auf mehrere Zustandsdatenkollektive verteilt sind, müssen diese in mehreren Importschritten nacheinander importiert werden.

Jedes Zustandsdatenkollektiv ist daher nach Import des vorigen im Importdialog auszuwählen und der Import erneut zu starten. Im folgenden Beispiel wurde das zweite Zustandsdatenkollektiv zum Import ausgewählt.

Wie ist beim alten ISYBAU-Import (0196/0601) die Fehlermeldung „ora-01400 ‚Einfügen von NULL in LADELIEG.lieg_nr nicht möglich’“ zu umgehen?

Dieser Fehler kann auftreten, wenn nicht alle Felder in den ID-Records einer ISYBAU-Austauschdatei im Format 01/96 bzw. 06/01 ausgefüllt wurden.

Um das Problem zu umgehen, sind die Felder "Liegenschaftsnummer" (ID-Record A, Spalten 18-27) und "Liegenschaftskennnummer" (ID-Record B, Spalten 13-22) auszufüllen und der Import erneut zu starten. Wenn die Werte für diese Felder nicht bekannt sind, können hier auch beliebige Werte eingetragen werden, da der Import diese Werte nicht importiert und lediglich zum Vergleich mit den in der INKA-Datenbank hinterlegten Werten heranzieht.

Wieso bricht der alte ISYBAU-Import (0196/0601) ab und meldet lediglich „Die Datenübernahme der Austauschdatei war nicht erfolgreich.“?

Wenn diese Fehlermeldung im ISYBAU-Import für XML-2006 erscheint, ist ein unvorhergesehener Fehler aufgetreten, für den keine konkrete Fehlermeldung vorliegt. Es wird empfohlen, in dieser Situation den Anwendersupport zu benachrichtigen, der das weitere Problem analysieren kann. Weitere Hinweise zum Problem finden sich auch in der Datei „faa_inka.log“, die sich im Verzeichnis der Anwendungsdaten des angemeldeten Benutzers befindet.

Um die Datei „faa_inka.log“ zu finden ist ein Windows-Datei-Explorer zu öffnen und in der Adresszeile der Pfad „%appdata%\lisa\faa\“ einzugeben (ohne die Anführungsstriche). Das Verzeichnis, in dem sich die Datei „faa_inka.log“ befindet, wird nun geöffnet und die Datei kann mit einem Texteditor geöffnet werden.

Die folgenden Meldungen können innerhalb der Datei auftreten und weisen auf bestimmte Probleme in den ISYBAU-Daten hin:

"ORA-01438: Wert größer als angegebene Stellenzahl für diese Spalte zulässt."

- Die Gefälleberechung für eine Leitung oder eine Haltung schlägt ggf. fehl, weil ein sehr großes Gefälle berechnet worden ist. Dies kann mit einer angegeben Sohlhöhe von „0“ zusammenhängen, die als Platzhalter verwendet worden ist, obwohl keine Sohlhöhe aufgenommen worden ist. Wenn die reale Sohlhöhe der Kante sehr viel höher liegt, wird ein zu großes Gefälle berechnet. In diesem Fall ist die Sohlhöhe „0“ in der Austauschdatei zu löschen (beispielweise mit einer Bearbeitungssoftware wie BaSYS/PIETS) und der Import neu zu starten.

- Die Berechnung der Schachttiefe schlägt ggf. fehl, weil die Sohlhöhe mit „0“ als Platzhalter angegeben worden ist, obwohl sie nicht aufgenommen wurde. Wenn die Deckelhöhe wesentlich höher liegt, wird eine zu große Schachttiefe berechnet. In diesem Fall ist die Sohlhöhe „0“ in der Austauschdatei zu löschen (beispielweise mit einer Bearbeitungssoftware wie BaSYS/PIETS) und der Import neu zu starten.

- Eine Dezimalzahl wurde mit mehr Stellen angegeben als die Baufachlichen Richtlinien Abwasser gestatten (siehe Baufachliche Richtlinien Abwasser, Kapitel A.7-2, Abschnitt Feldformate, Dezimal). Die fehlerhaft angegebenen Werte sind zu korrigieren (beispielweise mit einer Bearbeitungssoftware wie BaSYS/PIETS) und die Datei erneut zu importieren.

Warum kann ein Inspektionsauftrag im alten ISYBAU-Import (0196/0601) nicht ausgewählt werden?

Damit ein Auftrag im alten ISYBAU-Import ausgewählt werden kann, müssen für diesen Auftrag die Felder Auftragsart und Kodiersystem gefüllt sein. Wenn dies nicht der Fall ist, wird der Auftrag im Importdialog nicht angezeigt.

Um das Problem zu beheben, ist ein neuer Auftrag anzulegen und sicherzustellen, dass die beiden Felder korrekt belegt sind.

Der Massenimport weist fast alle Liegenschaften mit der Meldung „Die Austauschdatei entspricht nicht dem ISYBAU-Schema. Kein Import“ ab.

Überprüfen der Datei „INKA.log“. Wird dort die Fehlermeldung „Zu wenig Prozessspeicher für Versuch…“ ausgegeben, muss der Massenimport mit weniger ausgewählten Liegenschaften wiederholt werden. Die Datenmenge ist in diesem Fall zu groß für den Rechner. Ein schrittweißes Importieren sollte den Fehler beheben.

Sollte auch dies nicht funktionieren, müssen die Liegenschaften einzeln importiert werden und abgewiesene Liegenschaften auf mögliche Datenfehler hin überprüft werden.

Der Massenimport weist eine Liegenschaft mit der Fehlermeldung „Vorläufige Liegenschaft mit ID XXXXX konnte nicht in endgültige Liegenschaft umgewandelt werden.“ ab.

Überprüfen des Tablespace „INKA“ in der Datenbank. Ist eine hohe Speicherbelegung vorhanden, sollte der Speicher für den Tablespace erweitert werden und der Import erneut durchgeführt werden. Es kann aber auch hilfreich sein, die Datenbank neu zu starten.

Von Datenfehlern ist in der Regel nicht auszugehen, da alle Prüfungen zu diesem Zeitpunkt bereits abgeschlossen sind. Sollten sich die Daten dennoch nicht importieren lassen, wenden Sie sich an die Anwenderbetreuung zur weiteren Unterstützung.

Der Import einer aus INKA exportierten Liegenschaft mit Hydraulikdaten wird als nicht schemakonform abgewiesen.

Überprüfen Sie das Hydraulikdatenkollektiv auf das Vorhandensein doppelter Flächennummern. Der Fehler kann durch den Import von mehreren Hydraulikdatenkollektiven aufgetreten sein, wenn sich die Kollektive nicht überlagern.

Um den Fehler beheben, muss eine der beiden doppelten Flächen umbenannt werden und der Import erneut durchgeführt werden.

Der Import einer Liegenschaft wird mit der Fehlermeldung „Die Datei entspricht nicht dem XML-ISYBAU-Schema…“ abgebrochen.

In der Regel liegen Fehler in der ISYBAU-Datei vor. Sollte der Fehler nicht durch ein externes Prüftool zu finden sein, kann ggf. die Datei „faa_inka.log“, die sich im Verzeichnis der Anwendungsdaten des angemeldeten Benutzers befindet.

Liegt in der Datei „faa_inka.log“ folgende Fehlermeldung vor: „…kann nicht um 8 in INKA_TS erweitert werden“, ist die Kapazität des INKA Tablespaces ausgereizt, ohne dass eine automatische Erweiterung eingerichtet ist. Wenden Sie sich an Ihren Datenbankadministrator oder weisen Sie dem Tablespace eine größere Speicherfläche zu. Es ist ratsam, den Tablespace automatisch in 50 MB-Schritten erweitern zu lassen.

INKA

Warum wird in INKA keine Deckelhöhe für einen Schacht angezeigt, obwohl in den ISYBAU-Daten eine Deckelhöhe vorhanden war?

In INKA existiert derzeit ein Bug im Import, der dazu führt, dass die Deckelhöhe nicht korrekt im INKA-Dialog angezeigt werden kann, wenn in der ISYBAU-Austauschdatei bestimmte Felder für das Schachtobjekt nicht belegt sind.

Es ist daher sicherzustellen, dass die Angaben zur Form des Schachtaufbaus und des Unterteils des Schachtes in der Austauschdatei angegeben worden sind. Nach Ergänzen dieser Informationen in der ISYBAU-Datei ist der INKA-Import erneut durchzuführen.

Warum werden nicht alle vorhandenen Inspektionen zu einem Objekt angezeigt?

In jedem Inspektionsdatendialog ist in INKA in der Regel die Option „Aktuelle Inspektion je Objekt“ eingestellt, die lediglich die jeweils nach Datum neueste Inspektion anzeigt.

Um auch ältere Stände und damit alle gespeicherten Inspektionen anzeigen zu können, ist die Option „Alle Aufträge“ zu wählen. Nun können Inspektionsdaten direkt über die Auswahl des Auftrags ausgewählt werden.

Wieso lässt INKA es nicht immer zu, dass ein Schacht, Sonderbauwerk oder Anschlusspunkt gelöscht wird?

Alle Knotenobjekte (Schacht, Anschlusspunkt und Sonderbauwerk) sind in der Regel als Von- und/oder Bis-Knoten einer Kante (Haltung, Anschlussleitung, Rinne, Gerinne) eingetragen. Das Löschen eines Knotens ist daher erst möglich, wenn diese Verbindung gelöst worden ist.

Es ist dabei zu beachten, dass sämtliche Einträge gelöscht werden müssen und daher alle Objekte sowohl in den Stamm- als auch in den Zustandsdaten kontrolliert werden müssen. Um die betroffenen Einträge zu finden, können die betroffenen Haltungen und Leitungen in dem Stamm- und den Zustandsdaten über die Suchfunktion gefunden werden.

Warum werden die Sachdaten zu meinen Sanierungsmaßnahmen nach dem Import nicht angezeigt?

Sachdaten zu Sanierungen werden derzeit nur angezeigt, wenn das Abwasserobjekt in INKA eine Verknüpfung mit einem Geometriedatensatz in GEO Kanal besitzt. Das heißt, es müssen LISA-GUID für die Objekte vorhanden sein.

Die Sachdaten werden vollständig angezeigt, wenn man über die Objektverknüpfung in GEO Kanal dem entsprechenden Sachdatensatz eine LISA-GUID zuweist.

GEO Kanal

Welche BFR Verm-Versionen werden unterstützt?

Die aktuelle FAA-Version unterstützt ausschließlich die BFR Verm 2.5 und 2.5.1. Wenn die Unterstützung der BFR Verm 2.4 benötigt wird, steht die FAA 2.3.2 zur Verfügung (siehe Downloadbereich). Es ist allerdings zu beachten, dass die FAA 2.3.2 nicht parallel zur aktuellen FAA eingesetzt werden kann, da die INKA-Datenbank nicht kompatibel ist. Es wird daher empfohlen, alle Verfahren vor der Bearbeitung in GEO Kanal/INKA auf den aktuellen Stand der BFR Verm zu migrieren und die aktuelle FAA-Version einzusetzen.

Sollte dies nicht möglich sein und ein Mischzustand aus Verfahren nach BFR Verm 2.4 und BFR Verm 2.5 vorliegen, ist eine FAA-Umgebung aufzubauen, die aus einer Parallelinstallation der FAA-Versionen 2.3.2 und 2.3.4 besteht. Details zu dieser Parallelinstallation finden sich in den Benutzungshinweisen zu GEO Kanal/INKA 2.3.4, die dem Setup zur Version 2.3.4 beiliegen.

Die BFR Verm 2.5.1 wird ab der FAA 2.3.7 unterstützt. Eine Parallelinstallation zur Unterstützung der BFR Verm 2.4 ist nicht verfügbar. Mit der FAA 2.3.5 wurde die Unterstützung der BFR Verm 2.4 offiziell eingestellt.

Warum startet GEO Kanal nicht vollständig bzw. bleibt beim Start hängen?

Wenn GEO Kanal gestartet wird, wird auch der INKA-Sachdatenclient gestartet und der Dialog zur Liegenschaftsvoreinstellung angezeigt. Auf manchen Systemen erscheint dieser INKA-Dialog jedoch hinter dem ALK-GIAP-Fenster und es entsteht der Eindruck, dass GEO Kanal nicht mehr korrekt weitergeladen wird.

In diesem Fall ist in der Windows-Taskleiste die Anwendung INKA zu suchen und der Eintrag zweimal anzuklicken. Der INKA-Dialog gelangt nun in den Vordergrund und es kann mit der Auswahl der Liegenschaft fortgefahren werden.

Warum bleibt GEO Kanal beim Aufruf eines Sachdatendialogs hängen?

Bei der Objektsuche werden immer alle Objekte zur Liegenschaft geladen und dies kann bei größeren Liegenschaften einige Sekunden dauern. Auf manchen Systemen erscheint der INKA-Sachdatendialog jedoch auch hinter dem ALK-GIAP-Fenster und es entsteht der Eindruck, dass der Aufruf nicht erfolgreich war.

In diesem Fall ist in der Windows-Taskleiste die Anwendung INKA zu suchen und der Eintrag zweimal anzuklicken. Der INKA-Dialog gelangt nun in den Vordergrund und es kann mit der Auswahl der Liegenschaft fortgefahren werden.

Warum wird beim Aufruf der Objektsuche für Zustandsdaten über GeoKanal->Objektsuche->Zustandsdaten->Leitungen immer die Meldung "Inspektionsdaten können für Anschlusspunkte nicht angezeigt werden." angezeigt?

Hierbei handelt es sich um einen Fehler in GEO Kanal, der in einer kommenden Version behoben werden wird.

Zustandsdaten für Leitungen sind daher bis zur Korrektur durch direkte Auswahl der Zustandsdaten zu einem Grafikobjekt oder im Standalone-INKA-Client anzuzeigen, der bspw. über das Windows-Startmenü aufgerufen werden kann (Programme\LISA\FIS Abwasser\INKA starten).

Der Fehler ist ab der Version 2.3.8 behoben.

Was für ein Datenfehler liegt vor, wenn beim Datenabgleich von Haltungen der Fehler "8091: Unplausible Geometrieangaben in INKA. Bilden einer Fläche zum GEO-Kanal-Objekt nicht möglich." protokolliert wird?

Diese Meldung weist grundsätzlich nicht auf einen Fehler in den Daten hin. GEO Kanal weist lediglich auf fehlende Haltungsflächen hin, die für den Themenplan „Einzugsgebiete Regenwasserabfluss“ verwendet werden. Diese Meldung erscheint daher, wenn noch keine Haltungsflächen erfasst und importiert worden sind und daher auch nicht gebildet werden können.

In einer kommenden Version der FAA wird der Meldungstext die Situation genauer darstellen und die Kategorie der Meldung wird von „Fehler“ auf „Hinweis“ geändert werden.

Was bedeutet der Eintrag „Unplausible Geometrie“ im Protokoll von GEO Kanal für die Bildung von Schachtobjekten?

Die Meldung „Unplausible Geometrie“ bei Schächten bedeutet grundsätzlich, dass das Objekt nicht gebildet werden konnte, da die in INKA enthaltene Geometrie durch GEO Kanal nicht ausgewertet werden kann. Dies hat bei Schächten meist eine der beiden folgenden Ursachen.

Wenn eine Schachtkoordinate in INKA fehlt, da kein Punkt mit dem Punkattribut SMP in der importierten ISYBAU-Datei für den Schacht enthalten war, kann die Objektbildung des GEO Kanal kein Verfahrensobjekt bilden, da Schachtobjekte nach BFR Verm einen Schachtmittelpunkt benötigen. In diesem Fall kann die Deckelkoordinate durch GEO Kanal als Schachtmittelpunkt dupliziert werden, damit die Bildung des Schachtes trotzdem möglich ist. Diese Funktion kann in den Optionen des GEO Kanal aktiviert werden.



Eine weitere Situation, die zu der angegebenen Meldung führen kann, ist doppelt angegebene Geometrie, die insbesondere bei nach XML-2006 migrierten Altdaten auftreten kann (Typ K des ISYBAU-Formats 01/96). Die Ursache liegt in diesem Fall darin, dass zwar ein Schachtmittelpunkt vorliegt (Punkt mit Punktattribut SMP in ISYBAU), doch ein weiterer Höhenpunkt in der ISYBAU-Austauschdatei angegeben worden ist (Punkt mit Punktattribut HP in ISYBAU), der die Sohlhöhe des Schachtes enthält. Es darf jedoch nur einer der beiden Punkte in der Austauschdatei und damit auch bei der Objektbildung in GEO Kanal vorhanden sein.

Zur Korrektur ist daher in diesem Fall diese Dopplung in der ISYBAU-Datei aufzulösen (beispielweise mit einer Bearbeitungssoftware wie BaSYS) und die Datei ist dann erneut in INKA zu importieren. Auf Grundlage der bereinigten Daten kann dann die Objektbildung des Schachtes durchgeführt werden. Siehe zu dieser Problematik auch die Vorgaben aus Kapitel A-1.2.2.1 der Baufachlichen Richtlinien Abwasser.

Warum meldet die Datenprüfung des GEO-TOP unbekannte Benutzerattribute „Q_VOLL“ und „Q_MAX“ für Haltungen?

Die Attribute „Q_VOLL“ und „Q_MAX“ wurden in einer älteren Version der FAA verwendet und können daher nur bei Verfahren auftreten, die mit einer älteren Version bearbeitet worden sind (FAA 2.3.1 oder älter). Diese zusätzlichen Attribute sind unkritisch und ein manuelles Löschen dieser Attribute ist auch problemlos.

In einer kommenden FAA-Version wird im Datenabgleich eine Funktion ergänzt werden, die diese Attribute automatisch löschen kann.

Warum meldet die GEO-TOP-Datenprüfung bei der Objektart 6 850 3520 (Regenwassernutzungsanlage, punktförmig) die unzulässige Objektteilart 1 850 1107 (Deckel / Einstieg Regenwassernutzungsanlage)?

Diese fehlerhafte Datensituation kann durch den Datenabgleich von GEO Kanal entstehen, wenn eine Regenwassernutzungsanlage über einen ISYBAU-Import Deckelkoordinaten in INKA erhalten hat, aber keine Flächengeometrie für das Objekt vorliegt. In diesem Fall wird durch den Datenabgleich fälschlicherweise ein Objektteil „Deckel“ für die punktförmige Regenwassernutzungsanlage generiert. Diese Zuordnung ist nach BFR Verm jedoch nicht gestattet.

Der Datenabgleich wird daher in einer kommenden Version der FAA korrigiert werden und er löscht dann auch fehlerhaft gebildete Objektteile. Um die Daten kurzfristig zu korrigieren, ist das Objektteil mit den Mitteln des ALK-GIAP manuell zu löschen. Dies sollte am Ende der Bearbeitung des Verfahrens geschehen, da ein erneuter Datenabgleich des Objekts das Objektteil wieder bilden würde.

Warum können manche Objekte (insbesondere Anschlusspunkte vom Typ Gebäudeanschluss, Regenfallrohr und Straßeneinlauf) im Verfahren nicht gebildet werden?

Die BFR Verm gestattet für die verschiedenen Objektarten teilweise nicht alle Entwässerungssysteme. In den ISYBAU-Austauschformaten und damit auch in INKA können dagegen grundsätzlich für alle Objektarten auch alle Entwässerungssysteme angegeben werden. Wenn das in INKA angegebene Entwässerungssystem laut BFR Verm jedoch nicht gestattet ist, kann die Objektbildung von GEO Kanal das Objekt nicht im Verfahren bilden.

Ein Beispiel für unplausible Werte ist ein Straßeneinlauf, der bspw. in INKA das Entwässerungssystem „Schmutzwasser“ besitzen kann. Für Straßeneinläufe ist jedoch nach BFR Verm 2.5 kein Objektteil für diese Kombination vorgesehen.

Eine Korrektur erfordert daher eine fachliche Beurteilung und Anpassung der Daten. Es wird empfohlen, das Entwässerungssystem des Objektes in INKA auf einen Wert zu ändern, der nach BFR Verm erlaubt ist. Im Einzelfall kann es sich bei Anschlusspunkten auch anbieten, die Punktkennung im INKA-Stammdatendialog zu ändern. Nach der Datenänderung kann die Objektbildung wiederholt werden.

Wieso bricht die Objektbildung von allen Objekten der Liegenschaft mit der Meldung „Koordinaten außerhalb der Verfahrensgrenzen“ ab?

Wenn eine Koordinate der INKA-Datenbank zur Objektbildung ins Verfahren übernommen wird, muss diese innerhalb der für das Verfahren definierten Grenzen liegen. Ist dies nicht der Fall, kann das Objekt nicht im Verfahren abgelegt werden und die Meldung erscheint. Dieses Problem kann folgende Ursachen haben:

- Im INKA-Voreinstellungsdialog wurde die falsche Liegenschaft ausgewählt, die nicht zu den Verfahrensdaten passt. In diesem Fall ist lediglich die eingestellte Liegenschaft zu kontrollieren.

- In der INKA-Datenbank sind UTM-Koordinaten enthalten, die über ISYBAU importiert worden sind. Eine Bildung auf Grundlage von UTM-Koordinaten wird durch GEO Kanal derzeit noch nicht unterstützt.

Warum ist manchmal nach einem Datenabgleich in GEO Kanal die Textfreistellung der Folie 850 nicht mehr korrekt?

Der Datenabgleich von GEO Kanal gleicht die Verfahrensdaten mit den über ISYBAU importierten Sachdaten der INKA-Datenbank ab. Wenn die INKA-Sachdaten zusätzliche Informationen enthalten, die nach BFR Verm für ein Verfahrensobjekt erlaubt sind, gelangen diese Informationen ins Verfahren.

Wenn bspw. die Profilbreite bisher nicht im Verfahren enthalten war, aber in INKA angegeben worden ist, wird im Verfahren ein zusätzliches Objektteil gebildet. Die Bildung dieses Objektteils berücksichtigt jedoch die bereits freigestellten übrigen Objektteile nicht und bildet das neue Objektteil an einer Standardposition. Das Objektteil kann sich daher mit den bestehenden Objektteilen überschneiden und muss nach dem Datenabgleich freigestellt werden.

Unterstützt GEO Kanal UTM-Koordinaten?

UTM-Koordinaten werden durch GEO Kanal im gleichen Maße unterstützt, wie diese im ALK-GIAP und allgemein im LISA verwaltet werden. Die Funktionen des GEO Kanal sind daher weitestgehend auch mit UTM-Koordinaten lauffähig.

Allerdings kann keine Objektbildung von Verfahrensobjekten aus den INKA-Daten durchgeführt werden, wenn die INKA-Daten durch einen Import von ISYBAU-Daten im Format XML-2006 bereits UTM-Koordinaten enthalten. Die Funktionalität zur Bildung von Verfahrensobjekten auf Grundlage von UTM-Koordinaten wird in einer Folgeversion der FAA ergänzt werden.

Was tue ich, wenn mein Schacht sowohl Regen- als auch Schmutzwasser führt (Kombinationsschächte)?

In manchen Fällen werden Schächte für mehrere Entwässerungssysteme genutzt. Diese sogenannten Kombinationsschächte existieren derzeit weder in den Baufachlichen Richtlinien Abwasser noch in den BFR Vermessung. Die Schächte führen die Entwässerungssysteme separat, sind also keine Mischwasserschächte. Meistens ist neben einem Regenwassersystem ein tiefer liegendes Schmutzwassersystem angeschlossen.

Um die Situation korrekt darzustellen, werden zwei Schachtobjekte angelegt, die in unmittelbarer Nachbarschaft liegen und die gleiche Deckelkoordinate besitzen. Dadurch ist es möglich, die ankommenden Kantengeometrien richtig zuzuordnen und dennoch den identischen Einstieg des Schachts zu übernehmen.

Mit Einführung eines BFR-Objektes, das diese Datensituation abbilden kann, wird dieser Weg hinfällig.

Warum sind nach der Übernahme von Geo- und INKA-Daten aus den Austauschformaten die Objektverknüpfungen nicht mehr vorhanden?

Die Objektverknüpfung wird in der FAA über die LISA-GUID hergestellt. Es ist in den Austauschformaten zu prüfen, ob die einzelnen Objekte eine LISA-GUID besitzen. Sollte dies der Fall sein, aber nach der Übernahme in die Bestandsdokumentation keine Verknüpfungsinformation mehr vorhanden sein, ist ggf. der Import der ISYBAU-Daten zu wiederholen. Dabei ist darauf zu achten, dass der Haken zur Übernahme der LISA-GUID gesetzt ist.

ISYBAU-Export

Warum fehlt in einer exportierten ISYBAU-Datei im Format XML-2006 das Entwässerungssystem, die Kanalart bzw. die Entwässerungsart?

In ISYBAU nach XML-2006 kann das Entwässerungssystem nur gespeichert werden, wenn auch eine Kanalart angegeben wurde (und umgekehrt). Wenn die Kanalart nicht in den INKA-Daten vorhanden ist, gibt der ISYBAU-Export daher auch das Entwässerungssystem nicht aus, da beide Informationen in einem gemeinsamen Attribut „Entwässerungsart“ abgelegt werden.

Um das Problem zu beheben, ist für alle Objekte die fehlende Kanalart zu ergänzen. Dies kann direkt im Sachdatendialog erfolgen, doch ist diese Variante bei einer großen Objektzahl relativ aufwendig. Der Datenabgleich des GEO Kanal bietet daher die Möglichkeit, eine fehlende Kanalart automatisch zu setzen. Diese Funktion muss allerdings in den Optionen erst aktiviert werden. Danach ist ein Datenabgleich für alle Objekte durchzuführen, denen die Kanalart fehlt (oder vereinfacht für das ganze Verfahren). Fehlende Werte für Kanalart und Entwässerungssystem können auch mit Hilfe der Plausibilitätsprüfung ermittelt werden. Details zu beiden Funktionen finden sich im Handbuch zu GEO Kanal.

Objektnamenmigration

Warum meldet das Werkzeug zur Objektnamenmigration nach dem Einlesen eines Protokolls der IDB-Objektnamenmigration immer noch, dass die Liegenschaften zu migrieren sind?

Das FAA-Werkzeug zur Objektnamenmigration kann Protokolle, die mit der IDB-Objektnamenmigration erstellt worden sind, nicht korrekt auswerten und migriert daher die INKA-Datenbank nicht. Die Objektnamen der Liegenschaft in der INKA-Datenbank sind daher immer noch auf dem veralteten Stand.

Für dieses Problem existiert eine angepasste Version der Objektnamenmigration, die über die Anwenderbetreuung bezogen werden kann. Diese Version kann die IDB-Protokolle auswerten und ermöglicht die Migration der Objektnamen.

Wie kann ich erfahren, welche Objekte noch nicht migriert worden sind?

Die FAA-Objektnamenmigration stellt Liegenschaften mit noch nicht migrierten Objekten dar, doch wird keine Liste mit den konkret betroffenen Objekten, sondern lediglich die Anzahl dargestellt. Für die Bearbeitung der betroffenen Objekte kann es jedoch sinnvoll sein die konkreten Objekte zu kennen.

Eine Ermittlung der noch nicht migrierten Objekte ist daher mit einem Skript möglich, dass über den Anwendersupport bezogen werden kann.