norbit / alkisimport Goto Github PK

Beim Import der thüringischen Daten (ALKIS_KB58_nas.zip) lief das Postprocessing auf einen Fehler. Angeblich war eine Flurstücksnummer doppelt vorhanden.

psql:postprocessing.d/4_nas2alb/1_flurst.sql:59: FEHLER:  doppelter Schlüsselwert verletzt Unique-Constraint »flurst_pkey«
DETAIL:  Schlüssel »(flsnr)=(161101-000-04490/141)« existiert bereits.

Die Funktion alkis_flsnr() erzeugt aus den Werten "161101000044900141__" und "161101000044902141__" die selbe Flurstücksnummer.
Das eine endet auf "0141__", die andere aber auf "2141__".

An den Daten (Auszug) der beiden Flächen kann man sehen, das diese aber verschieden sind:

SELECT
a.flurstueckskennzeichen,
     alkis_flsnr(a) AS flsnr,
     alkis_flsnrk(a) AS flsnrk,
     to_char(alkis_toint(a.land),'fm00') || to_char(alkis_toint(a.gemarkungsnummer),'fm0000') AS gemashl,
     to_char(coalesce(a.flurnummer,0),'fm000') AS flr,
     to_char(date_part('year', a.zeitpunktderentstehung), 'fm0000') || '/     -  ' AS entst,
     amtlicheflaeche::int AS flsfl
   FROM ax_flurstueck a
   WHERE a.endet IS NULL
     AND alkis_flsnr(a)='161101-000-04490/141';

flurstueckskennzeichen	flsnr                   flsnrk          gemashl         flr     entst         flsfl
"161101000044900141__"	"161101-000-04490/141"	"04490/141"	"161101"	"000"	"2004/ - "	2548
"161101000044902141__"	"161101-000-04490/141"	"04490/141"	"161101"	"000"	"2009/ - "	14646

Hi I am very grateful for this tool!
Anyway I am trying to run it with the test data from Baden Württemberg and it fails at the stage where it calls ogr2ogr on the xml file:
ERROR 1: Failed to process SRS definition: './131467.wkt2'

When I removed the single quotes around the file path in the declaration of the CRS var here https://github.com/norBIT/alkisimport/blob/master/alkis-import.sh#L680 , it works.
I am on Ubntu Linux, with GDAL 3.0.4,

hoffentlich werde ich nicht lästig ;-)

wenn möglich bitte die Spaltennamen kürzen.

Hintergrund:
ich speichere mir in QGIS verschiedene Layer zu offlineverwendung als Shape-Dateien ab.
Leider unterstützt das Shape-Format nur kurze Spaltennamen. Beim Export wird z.B. aus sn_randlinie => sn_randlin.
Es müssen also immer die Stile in den Layereigenschaften auf die neuen Spaltennamen angepasst werden damit die Darstellung passt.

Vielleicht lassen sich ja kürzere Spaltennamen finden.

Gruß
Christian Maurer

Ein User ohne Privilege CREATE auf der Datenbank wollte alkisimport über QGIS ausführen. Das schlug fehl, obwohl Schema alkis bereits existiert:

2023-02-28 08:39:09.384915	> psql:alkis-functions.sql:39: ERROR:  permission denied for database ****|
2023-02-28 08:39:09.388727	> CONTEXT:  SQL statement "CREATE SCHEMA alkis"|
2023-02-28 08:39:09.405053	> PL/pgSQL function pg_temp_15.alkis_set_schema(text) line 6 at EXECUTE|
2023-02-28 08:39:09.414839	> psql:alkis-functions.sql:39: STATEMENT:  SELECT pg_temp.alkis_set_schema('alkis');|

Nachdem ich dem User Privilege CREATE auf der Datenbank gegeben hatte funktionierte der Import.

Die Fehlerursache ist, dass alkis_set_schema(text) ein vorhandenes Schema mittels Exception behandelt, anstatt pg_namespace zu prüfen:

Der Import sollte bei einem vorhandenem Schema nicht daran scheitern, dass Privilege CREATE fehlt.

Zum Vergleich: alkis-import.sh und alkisImport.py prüfen dagegen zuerst pg_namespace:

Owner der Schemas alkis und postgis ist Rolle gis_owner, deren Mitglied der User ist. gis_owner hat Default Privileges auf den beiden Schemas. Der User hat somit alle Berechtigungen, um über alkisimport in Schemas alkis und postgis Datenbankobjekte erstellen zu lassen. Datenbankowner ist postgres.

=# \dn alkis|postgis
   List of schemas
  Name   |   Owner
---------+-----------
 alkis   | gis_owner
 postgis | gis_owner
(2 rows)

Der Fehler in alkis.alkis_importlog im Detail:

2023-02-28 08:39:07.895021	Import-Version: e393be3
2023-02-28 08:39:08.569379	Datenbank-Version: PostgreSQL 12.14, compiled by Visual C++ build 1914, 64-bit
2023-02-28 08:39:08.596882	PostGIS-Version: 3.3 USE_GEOS=1 USE_PROJ=1 USE_STATS=1
2023-02-28 08:39:08.640651	BEFEHL: 'C:\OSGeo4W\bin\ogr2ogr.exe' '--version'
2023-02-28 08:39:08.929065	> GDAL 3.5.3, released 2022/10/21|
2023-02-28 08:39:08.932006	
2023-02-28 08:39:08.940242	EXITCODE: 0
2023-02-28 08:39:08.948722	BEFEHL: 'C:\OSGeo4W\bin\psql.exe' '--version'
2023-02-28 08:39:09.039179	> psql (PostgreSQL) 14.3|
2023-02-28 08:39:09.05084	
2023-02-28 08:39:09.052486	EXITCODE: 0
2023-02-28 08:39:09.145827	Gesamtgröße des Imports: 116MiB
2023-02-28 08:39:09.165183	BEFEHL: 'C:\OSGeo4W\bin\psql.exe' '-v' 'alkis_epsg=25832' '-v' 'alkis_schema=alkis' '-v' 'postgis_schema=postgis' '-v' 'parent_schema=alkis' '-v' 'alkis_fnbruch=true' '-v' 'alkis_pgverdraengen=false' '-v' 'alkis_avoiddupes=false' '-v' 'alkis_hist=false' '-v' 'ON_ERROR_STOP=1' '-v' 'ECHO=errors' '--quiet' '--no-psqlrc' '-f' 'alkis-clean.sql' 'host=**** port=5432 dbname=**** user=**** password=*removed*'
2023-02-28 08:39:09.384915	> psql:alkis-functions.sql:39: ERROR:  permission denied for database ****|
2023-02-28 08:39:09.388727	> CONTEXT:  SQL statement "CREATE SCHEMA alkis"|
2023-02-28 08:39:09.405053	> PL/pgSQL function pg_temp_15.alkis_set_schema(text) line 6 at EXECUTE|
2023-02-28 08:39:09.414839	> psql:alkis-functions.sql:39: STATEMENT:  SELECT pg_temp.alkis_set_schema('alkis');|
2023-02-28 08:39:09.427772	
2023-02-28 08:39:09.430118	Fehler bei Prozeß: 3
2023-02-28 08:39:09.432238	EXITCODE: 3
2023-02-28 08:39:09.433989	Datenbankleerung schlug fehl.

2023-02-28 08:39:45.644951	Import-Version: e393be3
2023-02-28 08:39:45.65327	Datenbank-Version: PostgreSQL 12.14, compiled by Visual C++ build 1914, 64-bit
2023-02-28 08:39:45.673573	PostGIS-Version: 3.3 USE_GEOS=1 USE_PROJ=1 USE_STATS=1
2023-02-28 08:39:45.68551	BEFEHL: 'C:\OSGeo4W\bin\ogr2ogr.exe' '--version'
2023-02-28 08:39:45.817313	> GDAL 3.5.3, released 2022/10/21|
2023-02-28 08:39:45.832485	
2023-02-28 08:39:45.834489	EXITCODE: 0
2023-02-28 08:39:45.838148	BEFEHL: 'C:\OSGeo4W\bin\psql.exe' '--version'
2023-02-28 08:39:45.931515	> psql (PostgreSQL) 14.3|
2023-02-28 08:39:45.942698	
2023-02-28 08:39:45.946863	EXITCODE: 0
2023-02-28 08:39:46.0443	Gesamtgröße des Imports: 116MiB
2023-02-28 08:39:46.062396	BEFEHL: 'C:\OSGeo4W\bin\psql.exe' '-v' 'alkis_epsg=25832' '-v' 'alkis_schema=alkis' '-v' 'postgis_schema=postgis' '-v' 'parent_schema=alkis' '-v' 'alkis_fnbruch=true' '-v' 'alkis_pgverdraengen=false' '-v' 'alkis_avoiddupes=false' '-v' 'alkis_hist=false' '-v' 'ON_ERROR_STOP=1' '-v' 'ECHO=errors' '--quiet' '--no-psqlrc' '-f' 'alkis-init.sql' 'host=**** port=5432 dbname=**** user=**** password=*removed*'
2023-02-28 08:39:46.237087	> psql:alkis-functions.sql:39: ERROR:  permission denied for database ****|
2023-02-28 08:39:46.241561	> CONTEXT:  SQL statement "CREATE SCHEMA alkis"|
2023-02-28 08:39:46.248274	> PL/pgSQL function pg_temp_14.alkis_set_schema(text) line 6 at EXECUTE|
2023-02-28 08:39:46.254618	> psql:alkis-functions.sql:39: STATEMENT:  SELECT pg_temp.alkis_set_schema('alkis');|
2023-02-28 08:39:46.262762	
2023-02-28 08:39:46.264227	Fehler bei Prozeß: 3
2023-02-28 08:39:46.270101	EXITCODE: 3
2023-02-28 08:39:46.272122	Anlegen des Datenbestands schlug fehl.

Beim Import von ALKIS-NAS-Daten ohne Eigentümerdaten fehlt die gesamte Flurstücksinformation incl. Flurstücksgrenzen.
Getestet mit 3.0-10 und 3.0-11, Windows 10 64bit, OSGeo4W - Installation.

Hallo Jürgen,

hier gleich noch ein weiteres Problemchen: Der Datensatz (persönliche Daten wurden verändert) in ax_anschrift sieht so aus:
ort_post = "CH-8037 Zürich ( Schweiz )"
postleitzahlpostzustellung = NULL
strasse = "Musterstraße 29"
hausnummer = NULL
bestimmungsland = "CH"

daraus wird in der Tabelle eigner:
name1 = "Mustermann"
name2 = "* 19XX-XX-XX"
name3 = "Musterstraße 29"
name4 = NULL
name5 = "CH"
name6 bis name8 = NULL

Problem liegt vermutlich in Z. 416 von nas2alb.sql

Grüße

Bernhard
liegt es vielleicht daran, dass postleitzahlpostzustellung NULL ist und damit name4 NULL wird?

Das Truncate zum leeren der Tabellen in der alkis-ableitungsregeln.sql sperrt diese Tabelle mit dem Modus "AccessExclusivLock".

In der Postgres Doku wird empfohlen DELETE zu benutzen, wenn weiterhin in einer Transaktion auf die Datensätze zugegriffen werden soll.
Anschließend sollte ein VACUUM ausgeführt werden um nicht genutzten Speicher wieder freizugeben.
http://www.postgresql.org/docs/9.1/static/sql-truncate.html

Hallo,

nach einem erfolgreich durchgeführten ALKIS-Import stellen sich die Flurstücksbezeichnungen (Zähler, Nenner) relativ verschoben zum Bruchstrich dar (s. Screenshot). Ich nutze die QGIS-Erweiterung "norGIS ALKIS-Einbindung" V 2.0.43, der Import wurde mit "norGIS ALKIS-Import" V 3.0-29 durchgeführt.

Woran kann die verschobene Darstellung von Zähler und Nenner liegen?

Danke und Gruß
Daniel Grohmann

Während des Imports erhalte ich folgende Fehlermeldung:

Erzeuge Flurstücksnummern in Schrägstrichdarstellung...
 SQL DONE[2]: postprocessing.d/1_ableitungsregeln/11001.sql 2022-07-19 07:58:23 in 3s
 psql:postprocessing.d/1_ableitungsregeln/11001.sql:70: FATAL:  failed to load summary "/usr/lib/postgresql13/lib64/bitcode/postgis-3.index.bc": Invalid summary version 7, 1, 2, 3 or 4 expected
 Server beendete die Verbindung unerwartet
        Das heißt wahrscheinlich, dass der Server abnormal beendete
        bevor oder während die Anweisung bearbeitet wurde.
 psql:postprocessing.d/1_ableitungsregeln/11001.sql:70: Fatal: Verbindung zum Server wurde verloren
 parallel: This job failed:
 sql postprocessing.d/1_ableitungsregeln/11001.sql
 parallel: Starting no more jobs. Waiting for 0 jobs to finish.
 FEHLER BEIM POSTPROCESSING
 END 2022-07-19 07:58:23

Ich verwende Postgres auf OpenSuse Leap 15.3
Gibt es eine Möglichkeit den Import trotzdem durchzuführen?

ist das nicht fehlerhaft?:

"pgverdraengen "*)
	PGVERDRAENGEN=${src#pgverdraenen }
	case "$FNBRUCH" in
	an|on|true|an)
		PGVERDRAENGEN=true
		;;
	aus|off|false)
		PGVERDRAENGEN=false
		;;
	*)
		echo "$P: Ungültiger Wert $PGVERDRAENGEN (true or false erwartet)"
		exit 1
		;;
	esac
	;;

??? -->

"pgverdraengen "*)
	PGVERDRAENGEN=${src#pgverdraengen }
	case "$PGVERDRAENGEN" in
	an|on|true|an)
		PGVERDRAENGEN=true
		;;
	aus|off|false)
		PGVERDRAENGEN=false
		;;
	*)
		echo "$P: Ungültiger Wert $PGVERDRAENGEN (true or false erwartet)"
		exit 1
		;;
	esac
	;;

Nach dem Import von aktuellen ALKIS Daten aus NRW (Kreis Lippe) werden keine Gebäudenummern mehr dargestellt bzw. abgeleitet.
Die View v_haeuser ist leer da in den ap_pto's keine Art='HNR' vorhanden ist.

Ich versuche Alkis-Import unter Windows zu starten. Zur Installation habe ich osgeo4win- Installer verwendet. Es existiert ein Verzeichnis c:\OSGeo4W\apps\alkis-import.
Nach Start über das Icon ist weder ein Fenster noch eine Fehlermeldung zu sehen.

Moin! Bei der estmaligen Benutzung von alkis-import 3.0-5 kommt es bei mir zu einem Fehler und Importabbruch im Verlauf der Schemamigration, siehe log:

19567	"2018-11-22 08:14:20.617646"	"> psql:alkis-update.sql:26: HINWEIS:  ALKIS-Schema-Version: 14|"
19568	"2018-11-22 08:14:20.617646"	"CONTEXT:  PL/pgSQL-Funktion alkis_update_schema() Zeile 34 bei RAISE
19569	"2018-11-22 08:14:20.617646"	"> psql:alkis-update.sql:26: HINWEIS:  Migriere auf Schema-Version 15|"
19570	"2018-11-22 08:14:20.633246"	"CONTEXT:  PL/pgSQL-Funktion alkis_update_schema() Zeile 559 bei RAISE
19571	"2018-11-22 08:14:20.633246"	
19572	"2018-11-22 08:14:52.020446"	"> psql:alkis-update.sql:26: FEHLER:  Spalte »artderflurstuecksgrenze« enthält NULL-Werte|"
19573	"2018-11-22 08:14:52.067246"	"> CONTEXT:  SQL-Anweisung »ALTER TABLE ax_besondereflurstuecksgrenze ALTER artderflurstuecksgrenze SET NOT NULL«|"
19574	"2018-11-22 08:14:52.067246"	"> PL/pgSQL-Funktion alkis_update_schema() Zeile 1237 bei SQL-Anweisung|"
19575	"2018-11-22 08:14:52.082846"	
19576	"2018-11-22 08:14:52.082846"	"Fehler bei Prozeß: 3"
19577	"2018-11-22 08:14:52.082846"	"EXITCODE: 3"
19578	"2018-11-22 08:14:52.082846"	"Schemaprüfung schlug fehl."

Ist NULL grundsätzlich verboten in artderflurstuecksgrenze, so dass ich das Problem mit dem Author der Daten klären muss?
Gibt es einen Weg den Fehler (zunächst) zu umgehen? z.B. Anpasssen der Funktion alkis_update_schema?

Bei den Flustücksnummern wird für die horizontale Ausrichtung der Bruchstrich fix auf "zentrisch" gesetzt. Allerdings werden so nicht die rechts- oder linksbündigen Ausrichtungen berücksichtigt.
Im Fall der Bruchstriche ließ sich dies durch Verschiebung deren End- und Anfangspunkte erreichen. Für die Darstellung der Zähler und Nenner reicht es nicht, dass man einfach die Ausrichtung durchreicht und vom MapServer entsprechend die Labels positionieren lässt. Dann werden rechts- oder linksbündige Flurstücksnummern nicht konform zum ALKIS-SK dargestellt, da die jeweils kleine Zahl nicht mittig auf dem Bruchstrich steht. Hierzu musste also der Punkt in die Mitte des Brcuhstriches verschoben werden, sodass der MapServer immer nur zentrisch darstellen muss.
Anbei die erweiterte SQL.
11001.sql.zip

Ist es möglich den Import unter Windows zu automatisieren, also die UI von alkisImport.py zu umgehen?

Ich habe es bereits mit alkis-import.sh über Cygwin probiert, was auch weitestgehend läuft, wenn ich postgresql-client und gdal installiere.

Letztendlich gibt es aber ein Problem mit parallel, das ich über Package moreutils installiert habe. Der Fehler ist:

SQL DONE[0]: postprocessing.d/0_ableitungsregeln.sql 2022-04-22 22:02:58 in 1s
parallel: unknown option -- -
parallel [OPTIONS] command -- arguments
        for each argument, run command with argument, in parallel
parallel [OPTIONS] -- commands
        run specified commands in parallel
FEHLER BEIM POSTPROCESSING
END 2022-04-22 22:02:59

Meine Kenntnisse in Sachen Cygwin und Windows halten sich aber in Grenzen.

Mein Ziel ist es den Import unter Linux als auch Windows (andere Teammitglieder nutzen Windows) zu automatisieren. Vielleicht lässt sich alkisImport.py dahingehend anpassen, um den Import analog zu alkis-import.sh über eine Datei zu konfigurieren. Beim Überfliegen des Python-Scripts ist mir keine derartige Funktion aufgefallen, die eventuell nur undokumentiert ist.

Hallo,

gerne würde ich von https://www.opengeodata.nrw.de/produkte/geobasis/lika/alkis_sek/bda_oe/ heruntergeladene ALKIS-Daten mit dem Linux-Skript in eine frische Postgis-Datenbank importieren. Unter Debian 10 habe ich eine Datenbank mit Namen "alkis" angelegt und in pgadmin3 den Befehl "CREATE EXTENSION postgis" auf die Datenbank ausgeführt.

Eine Steuerdatei habe ich entsprechend http://www.norbit.de/68/ angelegt (die letzte Zeile jeweils für alle xml-Dateien):
PG:host=xpostgis dbname=alkis user=postgres password=******
create log debug
/xdata/xpostgis/alkis-nas/bda_oe_...EPSG25832_NAS/fachinformationen..._bda.xml.gz -skipfailures

Beim Import über das Skript mit der Steuerdatei kommt direkt ein Fehler:
henning@xpostgis:~$ /xdata/xpostgis/alkisimport-master/alkis-import.sh /xdata/xpostgis/alkis-nas/nas-import.lst
START 2019-08-06 17:21:57
GDAL 2.4.0, released 2018/12/14
SQL RUN: preprocessing.d/0_alkis-signaturen.sql 2019-08-06 17:21:57
?column?

Lade Signaturen...
(1 Zeile)

psql:preprocessing.d/0_alkis-signaturen.sql:25: FEHLER: Relation »alkis_flaechen« existiert nicht
ZEILE 1: DELETE FROM alkis_flaechen;
^
psql:preprocessing.d/0_alkis-signaturen.sql:25: ANWEISUNG: DELETE FROM alkis_flaechen;
SQL DONE[3]: preprocessing.d/0_alkis-signaturen.sql 2019-08-06 17:21:57 in 0,nichts
FEHLER BEIM PREPROCESSING
END 2019-08-06 17:21:57
henning@xpostgis:~$

Über das Windows-GUI kommt dieser Fehler nicht und ich könnte in die Datenbank importieren. Ich vermute, dass über das Windows-GUI vorher noch ein Schema angelegt wird und das löschen aus den dann bereits angelegten Tabellen somit klappt. Wenn ich das Skript richtig lese (Zeile 672 ff.) sollte das Schema eigentlich durch das "create" in der Steuerdatei angelegt werden.

Hat jemand eine Idee, wo sich Bug oder Bedienfehler versteckt?

Vieelen Dank & beste Grüße
Henning

Mit avoiddupes true werden Trigger erstellt, um Duplikate abzufangen: https://github.com/norBIT/alkisimport/blob/7919227c179d42181fb78998b5c1c03e41958471/preprocessing.d/1_ignore-duplicates.sql.

Problem dabei ist, dass die Trigger bei einem nachträglichen Import noch aktiv sind, weil avoiddupes false nie behandelt wird.

Steuerdatei für initialen Import:

create

avoiddupes true
jobs 1

0.xml
1.xml

Steuerdatei für zusätzlichen Import. Duplikate in 2.xml werden trotzdem ignoriert.

avoiddupes false

2.xml

Ich finde die Trigger sollten durch create bzw. update erstellt werden und lediglich mit ALTER TABLE ... { ENABLE | DISABLE } TRIGGER ... aktiviert oder deaktiviert werden, je nach Einstellung von avoiddupes.

Hi!
I am testing this wonderful thing with qgis, and copied the last edition.
After running it with a NAS file and a Database with postgis (as I did it with the old version) there is always the message that alkis_elemente cannot be found.
I looked up the database and found, that no table alkis_... was created. In a older Database everything was there. Did I something wrong or is there a bug inside the new version?
I'm not familiar with python. Sorry.
Greats Johannes

Beim Import der ALKIS Daten von Sachsen - konkret von Chemnitz - wird er Import abgebrochen. Details siehe log. liegt es an den Daten? Oder am ALKIS-Import?

https://www.geodaten.sachsen.de/downloadbereich-alkis-4176.html
(dort ALKIS Download mit Punktinformationen (gemeindeweise) auswählen und dann Stadt Chemnitz)
alkis-import-fehler.log

Folgende Indices führen zu einer exklusiven Sperrung bei der Aktualisierung:

po_points_temp0
po_points_temp1

Wieso werden dies Indices nach der Benutzung wieder gelöscht? Macht ein Löschen nach der Transaktion mehr sinn?

Ich habe festgestellt, dass bei großen Datensätzen die Import-Dauer unverhältnismäßig zunimmt.

Einzelimporte - immer Vollabgaben - laufen auf performanter Hardware insgesamt sehr zügig durch. Werden 15 Ämter auf einmal importiert, skaliert auch der reine DB-Import (ogr2ogr) optimal mit der Datenmenge im Vergleich zur Datenmenge bspw. eines Amtes.
Das Aufbereiten der Daten (nachgelagerte SQL-Skripte) dauert allerdings unverhältnismäßig länger. Bis zu bestimmten Datenmengen skaliert das "Postprocessing" noch gut, ab einer bestimmten Menge läuft es zeitlich sehr aus dem Ruder.

EDIT 20.02. (Aktualisierung der u.g. Zahlen)
Amt / Datenmenge der Vollabgabe / Dauer des kompletten Imports:
Mülheim a.d Ruhr (3,5 GB): 14 min.
Wesel (29 GB): 204 min.
Mülheim a.d Ruhr, Duisburg, Oberhausen, Bottrop (zus. 33 GB): 482min.
Mülheim a.d Ruhr, Wesel, Duisburg, Oberhausen, Bottrop (zus. 62 GB): 1.097 min.
alle 15 Ämter im Ruhrgebiet (175 GB): 9.500 min (ca. 6,5 Tage)

Die Hausnummern (Konsolenausgabe: "Gebäudehausnummern...") scheinen einen "problematischen" Part darzustellen, denn dort "steht" der Prozess (15 Ämter, s.o.) seit etwa 49h. Vor eineinhalb Jahren ist ein vergleichbarer Import aller Ämter gelaufen; dort hat der Part, der wohl auch die Gebäudehausnummern enthält (alkis-ableitungsregeln.sql?) insgesamt nur 26h auf schwächerer Hardware benötigt (Import-Version: 287fce5). Kann die Änderung 7f82ac2
vielleicht bei großen Datenmengen negative Auswirkungen haben? Diese ist nach dem letzte großen Import in den aktuell verwendeten Code eingeflossen und bezieht sich auf Hausnr....

Das löschen des Index in der alkis-ableitungsregeln.sql führt ebenfalls zum exklusiven Sperren der Tabelle in der Transaktion.

Auszug von der Webseite http://www.norbit.de/68 :

... wird ogr2ogr mit der Option -skipfailures ausgeführt. Dies sollte nur nötig sein, wenn man Datenbestände mit doppelten Datensätzen importiert (etwa Datensätzen für verschiedenen Gemeinden bei denen sich die Katalogeinträge überschneiden)

Eigene Erfahrung:

"-skipfailures" verlangsamt seit GDAL2 die Importe erheblich (der ogr2ogr-Prozess dauert etwa dreimal länger, als ohne "-skipfailures").
Aufgrund des auf der Webseite beschriebenen Umstandes ist jedoch beim Import mehrer Gemeinden (bspw. OpenData-Daten NRW; mehrere Gemindedatensätze) der Parameter "-skipfailures" zumindest bei den Katalogobjekten notwendig, bei den anderen Objektarten aber mögicherweise nicht. Das wäre zu klären...
Wenn bei anderen Objektarten keine doppelten Datensätze vorkommen, wäre eine differenzierte Behandlung der Import-Dateien dementsprechend sinnvoll - zumindest dann wenn möglich. Bei den ALKIS-OpenData-Datensätzen aus NRW liegen die Katalogobjekte in "katalogobjekte_bda.xml".

-->Beispiel zur Erweiterung des Shell-Scripts. Fallunterscheidung ob die Objektdatei im Dateinamen "katalogobjekte" enthält, oder nicht (ist sicherlich nicht optimal...):

opt_sf=
if [[ "$src" =~ "katalogobjekte" ]]; then
	opt_sf="-skipfailures"
else
	opt_sf=
fi

...

echo RUNNING: ogr2ogr -f $DRIVER $opt $opt_sf -update -append "$DST" $CRS "$dst"
t0=$(bdate +%s)
if [ -z "$T0" ]; then T0=$t0; fi
if [ -n "$GDB" ]; then
	gdb --args ogr2ogr -f $DRIVER $opt $opt_sf -update -append "$DST" $CRS "$dst" </dev/tty >/dev/tty 2>&1
else
	ogr2ogr -f $DRIVER $opt $opt_sf -update -append "$DST" $CRS "$dst"
fi
t1=$(bdate +%s)

Präsentationsobjekte (ap_pto) für Gebäude mit der Art = "FreierText" werden nicht für die Beschriftung der Karte berücksichtigt.
Dieses sind z.B. Namen von Kirchen oder anderen Gebäuden. Die Schrift erscheint immer in der Mitte des Gebäudes.

alkis-compat.sql erstellt Funktionen als Ersatz für eventuell fehlende Funktionen. Teilweise handelt es sich um Shims für Postgres (array_length und unnest) sowie für PostGIS (ST_*). Bei den Funktionen ohne Präfix ST_ bin ich mir nicht sicher wofür die existieren. Hatte PostGIS mal eine API ohne den Präfix? Die werden von alkisimport aber auch nicht verwendet.

Ist jetzt die Frage, welche Postgres- und PostGIS-Versionen alkisimport überhaupt unterstützt (keine Aussage dazu in der README oder auf https://www.norbit.de/68/). Aber Funktionen array_length und unnest existieren seit Postgres 8.4 (https://www.postgresql.org/docs/8.4/release-8-4.html#AEN97667). Postgres 8.3 ist seit 10 Jahren EOL.

Zumindest sollten die Funktionen nur erstellt werden wenn nötig, anstatt Schema public und das PostGIS-Schema mit unnötigen Objekten zuzumüllen. Beispielsweise wird Funktion cleanGeometry erstellt, um damit st_makevalid zu implementieren. cleanGeometry ist aber unnötig, wenn st_makevalid bereits existiert (seit PostGIS 2.0.0, https://postgis.net/docs/release_notes.html#idm46696).

Übersicht der verwendeten Funktionen aus alkis-compat.sql:

git grep -Eiho '\<('"$(grep -Eio 'create\s+function\s+\w+' -- alkis-compat.sql | awk '{print $3}' | sort | uniq | paste -sd '|')"')\s*\(' -- ':!alkis-compat.sql' | sort | uniq -c

  3 alkis_offsetcurve(
  9 array_length(
  7 st_area(
  1 st_asbinary(
 30 st_astext(
 21 st_azimuth(
  7 st_buffer(
161 st_centroid(
 17 st_collect(
 16 st_distance(
 34 st_dump(
 24 st_endpoint(
  9 st_equals(
  2 st_force2d(
  9 st_geometryn(
188 st_geomfromtext(
  4 st_intersection(
  8 st_intersects(
  5 st_isvalid(
  1 st_isValid(
 38 st_length(
 61 st_lineinterpolatepoint(
  5 st_linemerge(
 21 st_makeline(
  1 st_makevalid(
245 st_multi(
  3 st_numpoints(
  1 st_offsetcurve(
  5 st_point(
  9 st_pointn(
  2 st_pointonsurface(
  9 st_reverse(
  5 st_rotate(
  3 st_setsrid(
  3 st_srid(
 25 st_startpoint(
 34 st_translate(
 11 st_x(
  1 st_xmax(
  1 st_xmin(
 11 st_y(
  1 st_ymax(
  1 st_ymin(
 44 unnest(

trying to import xml files as per example nas.lst
nas.lst:

PG:dbname=alkis user=alkis password=alkis
epsg 25832
create
log
1.xml
2.xml
3.xml
...
(but amended correct DB credentials)
and running
alkis-import.sh nas.lst
returns:
alkis-import.sh: line 522: sql: command not found
I suspect the functional scope of sql() might be too small?!

Where to from here?

Cheers,
Stefan

psql:alkis-ableitungsregeln.sql:399: FEHLER: Einfügen oder Aktualisieren in Tabelle »alkis_linien« verletzt Fremdschlüssel-Constraint »alkis_linien_katalog_fkey«
DETAIL: Schlüssel (katalog)=(1) ist nicht in Tabelle »alkis_signaturkataloge« vorhanden.

Hallo,

das Land Thüringen stellt zum 01.01.2024 bei der Datenlieferung von NAS-Daten auf eine neue Version des AAA-Datenmodells von GeoInfoDok 6.0 auf GeoInfoDok 7.1 um. Wir importieren unsere NAS-Daten, die wir halbjährlich vom Land bekommen, per alkisimport in unsere PostGIS-Datenbank.

Mir ist zu diesem Punkt noch nicht ganz klar, ob und welche Auswirkung diese Umstellung haben wird. Wird die neuere Version GeoInfoDok 7.1 vom alkispimport unterstützt und können die Daten entsprechend fehlerfrei importiert werden? In der FOSSGIS-Liste kam die Rückmeldung (https://lists.fossgis.de/pipermail/fossgis-talk-liste/2023-May/012525.html), dass es in Hessen, wo bereits auf die neue Version umgestellt worden ist, wohl zu einer Fehlermeldung beim Import kam (welche ist leider nicht mehr bekannt).
Gibt es auch von anderer Seite aus bereits die Anforderung, dass der Import auch mit GeoInfoDok 7.1 funktioniert und müsste man die Anwendung entsprechend anpassen/erweitern?

Vielen Dank für eine Rückmeldungen hierzu!

Mir ist aufgefallen, dass alkis_farben mit UNIQUE(c, y, m, k) definiert ist, obwohl die vier Spalten nullable sind. Ich denke mal, dass die CMYK- und auch RGB-Werte generell nicht nullable sein sollten (unabhängig vom Unique Constraint).

Die Query, mit der ich meine Datenbanken nach solchen Fällen durchsucht habe:

select
  k.conrelid::regclass,
  k.conname,
  array_agg(a.attname order by a.attnum) as attnames
from
  pg_constraint k
  cross join
    unnest(k.conkey) keyattnum
  join
    pg_attribute a
      on a.attrelid = k.conrelid
      and a.attnum = keyattnum
      and not a.attnotnull
where
  k.contype = 'u'
group by
  1, 2

Tests mit dem branch gid7 erfolgten.

Bei postprocessing wird die Tabelle po_lines befüllt.

Hierbei tauchen in 2 Skripten Fehler auf

• 61001.sql ax_boeschungkliff
• 62040.sql ax_strukturlinie3d

https://github.com/norBIT/alkisimport/blob/gid7/postprocessing.d/1_ableitungsregeln/61001.sql#L249

Fehler: geometry has 2 dimension but geometry has not
Ändern in st_multi(st_force2d(st_collect(b1)))

https://github.com/norBIT/alkisimport/blob/gid7/postprocessing.d/1_ableitungsregeln/62040.sql#L15
Andern in st_multi(st_force2d(wkb_geometry)) AS line
Daten aus Tabelle ax_strukturlinie3d

Ich möchte einen bestehenden Datenbestand überschreiben, deswegen habe ich "Datenbestand neu anlegen" ausgewählt. Ich erhalte dieses Protokoll:
2022-04-06T11:52:54 Import-Version: 37654c2
2022-04-06T11:52:54 Datenbank-Version: PostgreSQL 12.10 on x86_64-suse-linux-gnu, compiled by gcc (SUSE Linux) 7.5.0, 64-bit
2022-04-06T11:52:54 PostGIS-Version: 3.1 USE_GEOS=1 USE_PROJ=1 USE_STATS=1
2022-04-06T11:52:55 > GDAL 3.4.2, released 2022/03/08|
2022-04-06T11:52:55 > psql (PostgreSQL) 13.0|
2022-04-06T11:52:55 Gesamtgröße des Imports: 30GiB
2022-04-06T11:52:55 > Aktuelles Schema public.|
2022-04-06T11:52:55 > psql:alkis-schema.sql:14: FEHLER: Relation »aa_advstandardmodell« existiert bereits|
2022-04-06T11:52:55 > psql:alkis-schema.sql:14: STATEMENT: CREATE TABLE aa_advstandardmodell (|
2022-04-06T11:52:55 > wert character varying,|
2022-04-06T11:52:55 > beschreibung character varying,|
2022-04-06T11:52:55 > dokumentation character varying,|
2022-04-06T11:52:55 > PRIMARY KEY (wert)|
2022-04-06T11:52:55 > );|
2022-04-06T11:52:55 Fehler bei Prozeß: 3
2022-04-06T11:52:55 Anlegen des Datenbestands schlug fehl.

Bisher funktionierte dieses Verfahren gut. Ich verwende die Version 3.0-44.

Ist es mit diesem Plugin auch möglich DLM Karten zu importieren und darstellen?

Beim Einsammeln mehrerer Ämter/Bestandsdatenauszüge gibt es immer wieder Probleme, die Daten aller Ämter in einer DB im Public-Schema zusammenzubringen, ein defekter Datensatz zerschießt u.U. die DB/bzw. den Import.
Da es ja seit kurzem möglich scheint - ich habe es mangels gepatchtem GDAL noch nicht getestet - Importe in ein anderes als das Public-Schema laufen zu lassen, wäre es dann nicht denkbar, für jede räumliche Zuständigkeit (Katasteramt) ein Schema in der DB anzulegen und mittels eines übergeordneten "Eltern-Schemas" und Vererbung den Zugriff für die Anwendung (QGIS/Mapserver) via Eltern-Schema global auf die Summe der Kind-Schemata zu ermöglichen?

Vorteile:

• jeder Datensatz eines Amtes bleibt autark
• mittels mehrerer paralleler Importinstanzen schnellere Importe (v.a. Postprocessing)
• schnellere Abfragen und Verwaltung der DB aufgrund kleinerer Tabellen
• größere Robustheit der Anwendung bei Importen/Updates, im schlimmsten Fall geht nur der Datensatz eines Amtsbezirks kaputt

wie in #49 vorgeschlagen, habe ich die aktuelle Version des Alkis - Importers für einen Erstimport verwendet.

In der Logdatei sind einige Fehler aufgetreten, z.B.

(1) psql:alkis-compat.sql:195: FEHLER: Funktion »st_makevalid« existiert bereits mit den selben Argumenttypen

(2) psql:alkis-compat.sql:378: FEHLER: Funktion st_force_2d(geometry) existiert nicht
ZEILE 2: SELECT st_force_2d($1);
^
TIP: Keine Funktion stimmt mit dem angegebenen Namen und den Argumenttypen überein. Sie müssen möglicherweise ausdrückliche Typumwandlungen hinzufügen.

Es geht mehr um Fehlermeldungen vom Typ (2). Hat dies negativen Einfluss auf die Importe?

Es gab in einem Forum ein ähnliches Problem:

https://lists.fossgis.de/pipermail/fossgis-talk-liste/2020-January/010411.html

Wir haben die Postgis Version 3.2. Beim Recherchieren ergab sich, wie in dem Forumsbeitrag auch, dass z.B.
Funktionen seit Postgis Version 2.1 ohne Unterstrich geschrieben werden.

hallo,

wäre es möglich dem Layer Flurstücksgrenzen ein paar zusätzliche Spalten hinzuzufügen und mit ein paar Werten aus ax_flurstueck zu befüllen?
Interresant wären vorallem gemarkungsnummer, zaehler, nenner und amtliche Flaeche.

Dies würde es sehr vereinfachen in QGIS weitere Auswertungen auf dem Layer laufen zu lassen.

Im Moment habe ich mir die ax_flurstueck extra aus der Datenbank geladen und anhand der gml_id in QGIS mit dem Flurstücksgrenzen-layer verknüpft, geht auch, aber wenns nicht zu viel aufwand ist wärs vielleicht auch für andere eine schöne Erweiterung.

Könnte man auch auf andere Layer ausweiten, z.B. Gebäude -> Lagebezeichnung

Gruß
Christian Maurer

Fehler bei der Verarbeitung von GID7 Daten:

psql:postprocessing.d/1_ableitungsregeln/61001.sql:281: FEHLER: Geometry has Z dimension but column does not
KONTEXT: SQL-Anweisung »INSERT INTO po_lines(
gml_id, thema, layer, line, signaturnummer, modell
) VALUES (
r0.gml_id, 'Topographie', 'ax_boeschungkliff', st_multi(st_collect(b1)), '2531', r0.modell
)«
PL/pgSQL-Funktion pg_temp_27.alkis_boeschung() Zeile 236 bei SQL-Anweisung
psql:postprocessing.d/1_ableitungsregeln/61001.sql:281: ANWEISUNG: SELECT pg_temp.alkis_boeschung();

Die bei GDAL2 dringend notwendigen zusätzlich Optionen (GDAL2_OPTS=" -nlt CONVERT_TO_LINEAR -ds_transaction") werden bei Ausführung des Shell-scripts nicht gesetzt, obwohl GDAL 2.1.3 installiert ist...

Der Prozess wir folgendermaßen (nas.lst) gestartet:
PG:dbname=XXX
epsg 25832
update
log
options --config PG_USE_COPY YES

--> Workaround manuelles setzen in den options:
options --config PG_USE_COPY YES -ds_transaction -nlt CONVERT_TO_LINEAR

ein kleines Testskript (zusammenkopiert aus alkis_import.sh)

#!/bin/bash
opt=
GDAL_VERSION=$(unset CPL_DEBUG; ogr2ogr --version)
echo $GDAL_VERSION

case "$GDAL_VERSION" in
"GDAL 2."*)
GDAL2_OPTS=" -nlt CONVERT_TO_LINEAR -ds_transaction"
opt="$opt$GDAL2_OPTS"
;;
*)
GDAL2_OPTS=""
;;
esac

echo $opt

gibt folgende Meldung aus:

GDAL 2.1.3, released 2017/20/01
-nlt CONVERT_TO_LINEAR -ds_transaction

d.h., die Erkennung der GDAL-Version an sich verläuft korrekt.

Hallo ,

beim Import mit der Import-Version 5f8e097 kommt es beim Abarbeiten von 3_eignerart.sql zu dieser Fehlermeldung:
psql:postprocessing.d/4_nas2alb/3_eignerart.sql:97: FEHLER: Spalte »land« existiert nicht|
und der Import wird abgebrochen.
Ich lese die Daten in ein frisches Schema ein.
Vielleicht kann jemand den Fehler reproduzieren und eine Lösung finden.

Vielen Dank für dieses tolle Werkzeug des Alkis-Import und für sicherlich eine schnelle Lösung des Problems.

Im Postprocessing fehlt in der SQL 4_postnas-keytables.sql die Erstellung der View v_bschaetz_entsteh_klima.
Anbei das erweiterte SQL zur Erstellung der View.
4_postnas-keytables.sql.zip

Ich möchte mehrere ALKIS Imports in eine DB importieren, die unabhängig voneinander funktionieren/existieren können sollen; Hintergrund ist Verwendung des QWC2 QGIS web client; der nur eine DB Connection erlaubt.

Wie muss ich die Parameter (ALKIS-Schema, PostGIS-Schema, Elter-Schema) setzten und muss ich ggf. das postGIS schema von public in ein anderes verschieben (wie hier beschrieben: https://www.postgis.net/2017/11/07/tip-move-postgis-schema/)?

Was ist die Bedeutung von Elter-Schema? Welche Objekte (Tabellen, Funktionen, etc.) landen jeweils in diesen drei parametrisierten Schemas?

Muss ich für jeden Import zwei gesonderte Schemas anlegen(für ALKIS-Schema & PostGIS Schema)?

Ich möchte vermeiden, dass ALKIS Objekte in public landen (zuletzt ist sogar passiert, das die Tabellen ax_xxxx, etc. in public gelandet sind, obwohl ein anderes alkis-schema angegeben war...)
Gibt es ein cleanup script, dass sämtliche ALKIS Objekte entfernt (nicht nur Daten löscht)?

Diese Woche wurde auf unserer Alkis Datenbank ein Analize Vacuum durchgeführt, das mit einer Fehlermeldung abgebrochen ist:

vacuumdb: Vacuum der Datenbank »aaaogr« fehlgeschlagen: FEHLER: Funktion alkis_toint(character varying) existiert nicht
ZEILE 1: SELECT to_char(alkis_toint(f.land),'fm00') || to_char(alkis_...
^
TIP: Keine Funktion stimmt mit dem angegebenen Namen und den Argumenttypen überein. Sie müssen möglicherweise ausdrückliche Typumwandlungen hinzufügen.
ANFRAGE: SELECT to_char(alkis_toint(f.land),'fm00') || to_char(alkis_toint(f.gemarkungsnummer),'fm0000') ||
'-' || to_char(coalesce(f.flurnummer,0),'fm000') ||
'-' || alkis_flsnrk(f)
KONTEXT: PL/pgSQL-Funktion public.alkis_flsnr(public.ax_flurstueck) Zeile 3 bei RETURN

"Eine Recherche hat ergeben, dass das Problem aber tatsächlich im Datenmodell begründet liegt.
Laut https://stackoverflow.com/questions/65237130/getting-function-does-not-exist-error-in-vacuumdb (in der Antwort) wird die Funktion VACUUM,
die das Berechnen der Statistiken übernimmt mit einem geleerten Suchpfad ausgeführt. D.h. dass auch Funktionen im Schema public nicht mehr im
Suchpfad von VACUUM enthalten sind und daher nicht gefunden werden können. In der Fehlermeldung sieht man, dass die Funktion alkis_toint ohne Schemaangabe
in der Modelldefinition steht. Daher kann sie VACUUM nicht finden, obwohl sie vorhanden ist.
Leider kann VACUUM auch kein neuer Suchpfad ("search_path") mitgegeben werden, so dass das nicht clientseitig gelöst werden kann.
Hier ist tatsächlich eine Änderung des Datenmodells notwendig, so dass die Funktion mit expliziter Schemaangabe aufgerufen wird."

Angeführt werden muss noch, dass wir eine ältere Version des Alkis Importers verwenden.
Können Sie etwas zu dem Fehler sagen?

Beim Versuch eine aktuelle Version der ALKIS-Daten in die Bestehende Datenbank einzuspielen, bricht der Import mit folgender Fehlermeldung ab:

psql:postprocessing.d/4_nas2alb/3_eignerart.sql:42: ERROR: duplicate key value violates unique constraint "eignerart_pkey"|
DETAIL: Key (flsnr, bestdnr, bvnr)=([...]) already exists.|

Muss ich bei einem Update etwas spezielles beachten?

Es wäre klasse, wenn der "Über"-Dialog die Versionsnummer anzeigen könnte. Dann hat der Nutzer einen einfachen Weg herauszufinden, welche Version er hat. ;)

Hallo, habe bereits einige Bundesländer erfolgreich per Shellscript importiert (Sachsen, Brandenburg, Hamburg) jedoch verhält sich beim Bundesland Thüringen die Sache merkwürdig.

Wenn ich die NAS ALKIS Daten von https://www.geoportal-th.de/de-de/Downloadbereiche/Download-Offene-Geodaten-Th%C3%BCringen/Download-ALKIS-flurweise herunterlade (Katasterbereiche) und importiere landen nur wenige Tausend Flurstücke in der Datenbank anstatt mehrere Millionen.

Dementsprechend ist Thüringen in QGIS nur zum Bruchteil abgebildet (ich glaube zwischen 5000 - 10000 Flurstücke ingesamt).

Ist das Problem bekannt? Gibt es besondere Einstellungen um das Problem zu beheben?

Vielen Dank vorab.

In dem Fall, dass auf einem Flurstück ein fitkives Grundbuchblatt (5000) mit einer Buchungsstelle der Buchungsart 2201 (Aufgeteiltes Erbbaurecht WEG) gebucht ist, werden keine Eigentümer in der Auskunft angezeigt.
Hier muss eine weitere Buchungsstelle über die Relation "an" gesucht werden um die Informationen für die Erbbauberechtigten zu finden.

Nach der Auswahl einer Datei stürzt ALKIS-Import 3.0-8 mit einem "Python funktioniert nicht mehr"- Fehler ab.
Umgebung: Windows 10, OSGeo4W - Installation

Die Ereignisanzeige liefert das:

Name der fehlerhaften Anwendung: pythonw.exe, Version: 3.7.150.1013, Zeitstempel: 0x5b331a31
Name des fehlerhaften Moduls: ucrtbase.dll, Version: 10.0.17134.319, Zeitstempel: 0x40b70dec
Ausnahmecode: 0xc0000409
Fehleroffset: 0x000000000006e57e
ID des fehlerhaften Prozesses: 0x23f8
Startzeit der fehlerhaften Anwendung: 0x01d4ae755adc866d
Pfad der fehlerhaften Anwendung: C:\OSGEO4~1\apps\Python37\pythonw.exe
Pfad des fehlerhaften Moduls: C:\WINDOWS\System32\ucrtbase.dll
Berichtskennung: def7c143-f824-4066-93ba-425daa8b9ae3
Vollständiger Name des fehlerhaften Pakets: 
Anwendungs-ID, die relativ zum fehlerhaften Paket ist: 

going the UI import way, I feed the alkis import with alkis shape XML files. However, instead of a successful import, I get a

2017-02-20T17:26:51 Import-Version: ba7af92
2017-02-20T17:26:51 Datenbank-Version: PostgreSQL 9.5.5 on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu 5.4.0-6ubuntu1~16.04.2) 5.4.0 20160609, 64-bit
2017-02-20T17:26:51 PostGIS-Version: 2.3 USE_GEOS=1 USE_PROJ=1 USE_STATS=1
2017-02-20T17:26:51 > GDAL 1.11.3, released 2015/09/16|
2017-02-20T17:26:51 > psql (PostgreSQL) 9.5.5|
2017-02-20T17:26:51 Gesamtgröße des Imports: 22kiB
2017-02-20T17:26:51 Kompatibilitätsfunktionen importiert.
2017-02-20T17:26:52 > PL/pgSQL function alkis_drop() line 17 at EXECUTE|
2017-02-20T17:26:52 > PL/pgSQL function alkis_drop() line 17 at EXECUTE|
2017-02-20T17:26:58 Datenbestand angelegt.
2017-02-20T17:26:58 > Präsentationstabellen werden erzeugt.|
2017-02-20T17:26:58 Präsentationstabellen angelegt.
2017-02-20T17:27:00 > Erzeuge Sicht für Klassifizierungen...|
2017-02-20T17:27:00 > Erzeuge Sicht für tatsächliche Nutzungen...|
2017-02-20T17:27:00 > Erzeuge Sicht für ausführende Stellen...|
2017-02-20T17:27:00 postcreate.d/nas2alb.sql ausgeführt.
2017-02-20T17:27:04 Signaturen importiert.
2017-02-20T17:27:04 > FAILURE:|
2017-02-20T17:27:04 > Unable to open datasource `/home/stefan/[...]shp.xml' with the following drivers.|
2017-02-20T17:27:04 > -> ESRI Shapefile|
2017-02-20T17:27:04 > -> MapInfo File|
2017-02-20T17:27:04 > -> UK .NTF|
2017-02-20T17:27:04 > -> SDTS|
2017-02-20T17:27:04 > -> TIGER|
2017-02-20T17:27:04 > -> S57|
2017-02-20T17:27:04 > -> DGN|
2017-02-20T17:27:04 > -> VRT|
2017-02-20T17:27:04 > -> REC|
2017-02-20T17:27:04 > -> Memory|
2017-02-20T17:27:04 > -> BNA|
2017-02-20T17:27:04 > -> CSV|
2017-02-20T17:27:04 > -> NAS|
2017-02-20T17:27:04 > -> GPX|
2017-02-20T17:27:04 > -> LIBKML|
2017-02-20T17:27:04 > -> KML|
2017-02-20T17:27:04 > -> GeoJSON|
2017-02-20T17:27:04 > -> Interlis 1|
2017-02-20T17:27:04 > -> Interlis 2|
2017-02-20T17:27:04 > -> GMT|
2017-02-20T17:27:04 > -> GPKG|
2017-02-20T17:27:04 > -> SQLite|
2017-02-20T17:27:04 > -> DODS|
2017-02-20T17:27:04 > -> ODBC|
2017-02-20T17:27:04 > -> WAsP|
2017-02-20T17:27:04 > -> PGeo|
2017-02-20T17:27:04 > -> MSSQLSpatial|
2017-02-20T17:27:04 > -> OGDI|
2017-02-20T17:27:04 > -> PostgreSQL|
2017-02-20T17:27:04 > -> MySQL|
2017-02-20T17:27:04 > -> PCIDSK|
2017-02-20T17:27:04 > -> OpenFileGDB|
2017-02-20T17:27:04 > -> XPlane|
2017-02-20T17:27:04 > -> AVCBin|
2017-02-20T17:27:04 > -> AVCE00|
2017-02-20T17:27:04 > -> DXF|
2017-02-20T17:27:04 > -> Geoconcept|
2017-02-20T17:27:04 > -> GeoRSS|
2017-02-20T17:27:04 > -> GPSTrackMaker|
2017-02-20T17:27:04 > -> VFK|
2017-02-20T17:27:04 > -> PGDump|
2017-02-20T17:27:04 > -> OSM|
2017-02-20T17:27:04 > -> GPSBabel|
2017-02-20T17:27:04 > -> SUA|
2017-02-20T17:27:04 > -> OpenAir|
2017-02-20T17:27:04 > -> PDS|
2017-02-20T17:27:04 > -> WFS|
2017-02-20T17:27:04 > -> HTF|
2017-02-20T17:27:04 > -> AeronavFAA|
2017-02-20T17:27:04 > -> Geomedia|
2017-02-20T17:27:04 > -> EDIGEO|
2017-02-20T17:27:04 > -> GFT|
2017-02-20T17:27:04 > -> GME|
2017-02-20T17:27:04 > -> SVG|
2017-02-20T17:27:04 > -> CouchDB|
2017-02-20T17:27:04 > -> Idrisi|
2017-02-20T17:27:04 > -> ARCGEN|
2017-02-20T17:27:04 > -> SEGUKOOA|
2017-02-20T17:27:04 > -> XLS|
2017-02-20T17:27:04 > -> ODS|
2017-02-20T17:27:04 > -> XLSX|
2017-02-20T17:27:04 > -> ElasticSearch|
2017-02-20T17:27:04 > -> PDF|
2017-02-20T17:27:04 > -> Walk|
2017-02-20T17:27:04 > -> CartoDB|
2017-02-20T17:27:04 > -> SXF|
2017-02-20T17:27:04 Fehler bei Prozeß: 1
2017-02-20T17:27:04 /home/stefan/[...].shp.xml mit 22kiB in 258ms importiert (87kiB/s)
2017-02-20T17:27:04 Import nach 12s abgebrochen.

Any idea what to change in order to get the data into the DB?
Cheers,
Stefan

SET search_path = :"alkis_schema", public;
müsste
SET search_path = :alkis_schema, public;
heißen oder?

Bei einigen Böschungen bekomme ich bei der Erzeugung folgende Fehlermeldung:
NOTICE: 0 elements input array
CONTEXT: SQL statement "INSERT INTO po_lines(
gml_id, thema, layer, line, signaturnummer, modell
) VALUES (
r.gml_id, 'Topographie', 'ax_boeschungkliff', st_multi(st_collect(b1)), '2531', r.modell
)"
PL/pgSQL function "alkis_boeschung" line 121 at SQL statement

Der Wert für die Variable b1 ist in diesen Fällen NULL.

Als ich versucht habe, das Log eines erfolglosen Imports (Server hatte nach zwei Stunden Pause (laut alkisimport Log) die Verbindung geschlossen), ist alkisimport abgestürzt.

Traceback (most recent call last):
  File "alkisImport.py", line 427, in saveLog
    f = QFile(save)
TypeError: arguments did not match any overloaded call:
  QFile(): too many arguments
  QFile(str): argument 1 has unexpected type 'tuple'
  QFile(QObject): argument 1 has unexpected type 'tuple'
  QFile(str, QObject): argument 1 has unexpected type 'tuple'
Aborted (core dumped)

2774bd4 (Mon Nov 19 15:49:06 2018 +0100)

Python 3.7.1