[PostNAS Suite] Postprocessing nach Differenzdatenimport

[Oliver Schmidt]

Moin Jürgen,
meine Antworten bzw. Fragen zu deiner Mail habe ich inline gepackt.

> 
> Message: 2
> Date: Thu, 28 Nov 2019 19:08:00 +0100
> From: Jürgen E. Fischer <jef at norbit.de>
> To: "PostNAS-Suite - ALKIS, ATKIS, ABK - NAS-Importschnittstelle via
> 	ogr2ogr" <nas at lists.osgeo.org>
> Subject: Re: [PostNAS Suite] Postprocessing nach Differenzdatenimport
> Message-ID: <20191128180800.dtu2b5jm23haq7wx at norbit.de>
> Content-Type: text/plain; charset=utf-8
> 
> Moin Oliver,
> 
> On Thu, 28. Nov 2019 at 16:54:57 +0100, Oliver Schmidt wrote:
> > wir nutzen jetzt seit ein paar Monaten den norbit ALKIS-Import lediglich mit
> > Vollabgaben und dem Postprocessing. Das funktioniert zwar gut, aber die
> > Laufzeit liegt bei rund 7 Tagen für den landesweiten Import und das
> > Postprocessing für das RP-ALKIS.
> 
> Über alkis-import.sh oder das Python-Frontend?   Mit alkis-import.sh kann man
> sowohl die Importe als auch das Postprocessing parallel laufen lassen…

Wir nutzen das alkis-import.sh, das bei uns schon parallel läuft. Zumindest wird solange parallelisiert, wie es genügend Skripte gibt. Am längsten laufen die SQLs für Flurstücke, Gebiete, tN und Gebäude. Was dann auch nochmal wahnsinnig lange dauert, ist das refilter.py Skript. Der Import für ganz RP läuft rund 8 Stunden, was schon OK ist. Aber das Postprocessing dauert dann nochmal eine Woche... 

> 
> 
> > Wenn wir auf die differenziellen NBAs gehen würden, würde das Postprocessing
> > ja wieder alles rechnen müssen, was bei täglichen Updates ja keinen Sinn
> > machen würde. Gibt es eine Möglichkeit, dass das Postprocessing nur die
> > Sachen aktualisiert, die auch von den NBA-Updates betroffen sind?
>  
> > Wenn es eine Möglichkeit gäbe, das gesamte Postprocessing deutlich schneller
> > laufen zu lassen, wäre das natürlich auch eine Alternative...
> 
> Die einzelnen Skripte parallel laufen zu lassen bringt schon etwas.

Macht das nicht dein Importskript sowieso schon? Der Flaschenhals scheinen eher die einzelnen Skripte 11001.sql, 72004.sql, 31001.sql, 12002.sql, 11002.sql, 12001.sql, gebiete.sql und eben refilter.py zu sein. Wenn mann diese noch schlau aufteilen könnte, dann würde man damit auch wieder parallel arbeiten können. Ob damit aber Rechenzeiten erreicht werden, die eine tagesaktuelle Darstellung der Lika ermöglichen, sehe ich derzeit nicht...

> 
> Das Postprocessing berücksichtigt derzeit nur die aktuellen Objekte und führt
> auch nicht mit aus welchen einzelnen Datensätzen zum abgeleiteten Objekt
> gejoined wurden (nur das Hauptobjekt z.B. gml_id des ax_flurstueck, aber nicht
> die der Flurstücksnummerposition aus ap_pto und auch nicht deren
> Entstehungdaten).
> 
> Wenn Objekte untergehen, weiß man also nicht welche abgeleiteten Objekte davon
> betroffen sind.  Zudem dürften die Regeln nur noch dann Objekte ableiten, wenn
> daran neue Objekte beteiligt sind (es können ja auch alte und neue gejoined
> werden).
> 
> Da wäre also noch einiges zutun.  Bisher habe ich dazu nur Vorüberlegungen.
> 
> 
> Jürgen
> 
> -- 
> Jürgen E. Fischer           norBIT GmbH             Tel. +49-4931-918175-31
> Dipl.-Inf. (FH)             Rheinstraße 13          Fax. +49-4931-918175-50
> Software Engineer           D-26506 Norden            https://www.norbit.de
> 
> 
> ------------------------------
> 
> Subject: Fusszeile der Nachrichtensammlung
> 
> _______________________________________________
> NAS mailing list
> NAS at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/nas

Viele Grüße,
Oliver