Bas-Adresse – geänderte Adressnummer GIS seit 3.2

Hallo Daniela,
ich glaube nicht, dass durch ein Software-Update Adress-Objekte gelöscht und neu gesetzt werden. Ich gehe eher davon aus, dass ein Mitarbeiter (versehentlich) den alten Briefkasten gelöscht und dann einen neuen gesetzt hat. Leider kann meines Wissens bei Materialstämmen in G/Tech - und so werden die Adressverknüpfungen gehandhabt - softwaretechnisch nicht abgefangen werden, dass der Materialstamm (MID) gelöscht wird, auch wenn noch andere Objekte mit diesen verknüpft sind. Beim Löschen kommt auch keine Warnungsmeldung. Vielleicht sollte man das aber (noch) mal über einen Arbeitskreis anstoßen.

Prinzipiell sollte man deshalb nie Adressobjekte löschen, auch dann wenn das Gebäude dazu ggf. abgerissen ist. Zumindest muss vorher geprüft werden, ob noch Objekte zugeordnet sind - s.u. Es können ja immer noch stillgelegte Objekte zugeordnet sein. Es reicht meines Erachtens in so einem Fall, wenn die Grafikkomponente (Briefkasten) gelöscht wird, die Adresse selbst aber im System verbleibt.

Um auszuschließen, dass es sich bei Euch nicht doch um ein Problem des Updates handelt, würde ich im Objektexplorer - Verwaltungskomponente mal nachsehen, von wem und wann die aktuell im System vorhandene Adresse (Adressnummer GIS 270914) erfasst wurde. Eventuell findest Du ja die gelöschte Adresse ja noch in Eurem Testsystem oder man kann in der Tabelle MODIFICATIONLOG noch raus finden, wer die verschwundene Adresse gelöscht hat.

Im Anhang stelle ich Dir zwei SQL-Skripte zur Verfügung, die ich für mich zur QS / Korrektur gemacht habe (Dateiendung von .txt nach .sql ändern):


Prüfen_MID_ADRESSE_ZUGEORDNET.sql: Das Skript nutze ich ! bevor ! ich eine Adresse wirklich lösche, um zu prüfen, ob noch Objekte zugewiesen sind. Man gibt die Adress-MID un derhält eine Liste aller G!NIUS-Tabellen, in denen diese MID verwendet wird + ein SQL-Statement, mit dem man dann die entsprechenden Datensätze ermitteln kann. Das geht natürlich auch über die entsprechende Spalte in der GIN-Shell oder im SQL-Developer / Toad. Auch die Suche in G!NIUS (Extras - Suchen - Objekt oder Komponente) ist möglich.


Suche_vagabundierende_STREET_ID_ADRESS_MID.sql: Das Skript sucht alle MID's/STREET_ID's, die in den Fachtabellen vorhanden sind, aber zu denen es keine Adresse / Straße mehr gibt. Ich gebe zusätzlich das Migrationsattribut 5 aus, weil bei den aus GRIPS migrierten Objekten hier noch der Straßen / Gebäudeschlüssel gespeichert ist. wie oben kann man mit dem zusätzlich ausgegebenen SQL-Skript die entsprechenden Datensätze ermitteln.

Falls Du Fragen zur Anwendung hast, ruf mich einfach an.

Grüße Gerhard

Hallo Exkollege Gerhard

Danke für Deine Unterstützung.

Das Problem wurde bereits von unserer Hotline vor einigen Tagen analysiert und gelöst.
Ursache waren veraltete Straßenschlüssel in den Daten.

Grüße
Roland

Hallo Exkollege Roland,
dann ist ja jetzt in Grünstadt alles ok. Allerdings bleibt das Problem, dass Bas-Adress-Objekte gelöscht werden können, obwohl die MID noch bei Netzobjekten eingetragen ist. Im Zuge der Beantwortung von Danielas Frage hatte ich auch bei uns im System noch mal nachgesehen, ob es nicht aufgelöste Adress-MID's gibt. Das war vereinzelt (ca. 10 Objekte) der Fall, obwohl ich vor rund einem Jahr die Bereinigung schon einmal durchgeführt hatte und damals den Kolleginnen und Kollegen deutlich gesagt hatte, dass Briefkästen nicht gelöscht werden sollen. Es wäre schön, wenn man das Problem "Löschen verwendeter Adressen und Straßenschlüssel" softwareseitig lösen könnte.

Darüber hinaus haben wir das Problem mit geänderten Straßenschlüsseln auch (oder anders?). Durch die Zusammenlegung von Verbandsgemeinden in RLP ändern sich in letzter Zeit großräumig die amtlichen Straßenschlüssel. Da der Straßenschlüssel / Gebäudeschlüssel in der ALKIS-Schnittstelle, das Kriterium für die Erzeugung neuer Adress-Objekte ist, werden dann beim ALKIS-Import für ganze Straßenzüge / Gemeinden doppelte Briefkästen erzeugt - sofern man nicht bereits vorher in G!NIUS die Straßenschlüssel bei den Adressen manuell (per SQL) aktualisiert hat. Leider bekommt man von ALKIS-Seite keine Information, welcher Straßenschlüssel wie geändert wurde und auch die GIN-ALKIS-Schnittstelle liefert keine Hinweise. Bei der Adresszuordnung der Netz-Objekte hat man dann das Problem, dass die Benutzer mehr oder weniger zufällig, die Adresse mit dem alten oder dem neuen Straßenschlüssel zugeordnen. Ggf. werden die Erfasser auch einen der beiden Briefkasten löschen - solange er es darf - und so die oben erwähnte Situation herbeiführen.

Im Umfeld der ALKIS-Schnittstelle wären in meinen Augen deshalb von Intergraph-Seite zwei Tools sinnvoll (
Hinweis: Diese Anforderung hatte ich auch bereits an den Arbeitskreis ALKIS weitergeleitet und der "Topic" steht auch schon zum Voten bereit.):
1. Ermittlung bisher nicht vorhandener Straßenschlüssel / abweichende Straßennamen in einer ALKIS-Datenlieferung bevor die Daten importiert werden (ggf. in der Zwischendatenbank). Zusätzlich wäre es auch sinnvoll, die Straßenschlüssel / Straßennamen aus Bas-Adresse aufzulisten, die in einer neuen ALKIS-Lieferung nicht (mehr) vorhanden sind.
2. Ein Hilfstool für den Kunden-Administrator, mit dem
a. der Aufbau einer Konvertierungstabelle "alter Straßenschlüssel" - "neuer Straßenschlüssel" unterstützt wird. Zumindest das lvermgeo hier in Rheinland-Pfalz kann (oder will?) so eine Liste nicht liefern.
b. die Änderung der Straßenschlüssel bei den Adress-Objekten und den Netzobjekten vor dem ALKIS-Import durchgeführt werden kann.

Grüße Gerhard

Für das eigentliche Problem haben wir leider auch keine Lösung, aber für 2a) Aufbau einer Konvertierungstabelle "alter Straßenschlüssel" - "neuer Straßenschlüssel" kann evtl. dieser Service der Deutschen Post genutzt werden:
www.deutschepost.de/de/d/deutsche-post-d...d_postleitdaten.html
speziell:
www.deutschepost.de/content/dam/dpag/ima...mtb_strassen_neu.pdf

Grüße
JUMüller

Hallo Gerhard,

vielen Dank für Deinen Input.

Verbesserungen in diesem Umfeld wird es in G!NIUS 3.3.0.0 geben, bzw. sind bereits in G!NIUS 3.2.2.0 und G!NIUS-ALKIS Import 4.1.0.0 enthalten.

Fehler bitte über unser Supportportal sgisupport.intergraph.com melden.
Bitte habt Verständnis, dass wir diesen Kanal hier zwar sporadisch beobachten, es aber kein Ersatz oder ein Parallelkanal zu unseren eingespielten Supportprozessen sein kann.
Ich hatte mich primär bei diesem Thema eingeschaltet, damit nach außen nicht der falsche Eindruck entsteht, dass sich unser Support nicht um unseren Kunden gekümmert hat.

Wünsche bitte vorab im GINUG Arbeitskreis ALKIS diskutieren und „rundschleifen“.
Wir sind froh, dass die GINUG gegründet wurde, und wir über diesen Kanal einen praxisnahen kundenübergreifenden Input erhalten.
Ein spezielles GINUG Forum für ALKIS gibt es hier .

Grüße
Roland