AW: [NAS] Buchauskunft

[Peter Korduan]

Hallo,

ich finde die Idee mit dem Preprozessing zwischen dem Konverter und der Anzeige gar nicht so schlecht. Es gibt eine ganze Reihe weitere Prozesse, die nach jeder Fortführung abzuarbeiten wären und nicht nur innerhalb der Katasterdaten, sondern für Daten, die mit den Katasterdaten in Beziehung stehen.

Ich würde das nicht als schlechten Stil bezeichnen. Redundanz ist, wenn sie gerechtfertigt ist (hier aus Performancegründen), sogar gut. Und andererseits kann man durch das Preprozessing auch Redundanz in anderen Datenbeständen reduzieren. Wozu z.B. Landkreis-, Gemeinde-, Gemarkungs- und Flurgrenzen fortführen, wenn sie doch aus den Flurstücksgrenzen abgeleitet werden können. Natürlich geht das nur über Vorberechnung. Hier noch zusätzliche mit verschiedenen Generalisierungsstufen.

Und Inkonsistents sollte auch nicht das Problem sein, denn:
1.) Die Fortführung über NBA führt ja auch regelmäßig zu nur zeitweisen Auszügen. Das ist zwar nur fehlende Aktualität und nicht zwangsweise Inkonsistens, könnte aber dazu führen, wenn man andere Daten mit Bezug zu Kataster auch in sein System asynchron einließt.
2.) Wenn das Preprozessing automatisiert abläuft und die referenzielle Integrität absichert, sollte auch keine Inkonsistenz auftreten.
  
Außerdem möchten wir für kvwmap auch eine Historie für alle Daten in unserer Datenbank führen. Auch dafür ist ein Preprozessor nach dem Einlesen der NBA sinnvoll einsetzbar.

Ich meine also, dass es nicht die Aufgaben des Konverters sein kann die Datenbankstruktur in die eine oder andere Weise zu verändern. Das ursprüngliche Datenmodell sollte schon so dicht wie möglich an dem vom AAA Modell sein. Was man daraus macht ist dann den Anwendungen überlassen. Da wir im Fall Katasterämter die gleiche Anwendung haben macht es Sinn die Nachbearbeitungsfunktionen dafür zusammen zu entwickeln und zu nutzen.

Mit freundlichen Grüßen
Peter Korduan


________________________________________
Von: nas-bounces at lists.osgeo.org [nas-bounces at lists.osgeo.org] im Auftrag von Jäger, Frank (KRZ) [F.Jaeger at KRZ.DE]
Gesendet: Montag, 14. Juni 2010 18:48
An: Entwicklung einer NAS Schnittstelle
Betreff: RE: [NAS] Buchauskunft

> -----Original Message-----
> From: Thomas Baschetti [mailto:th.baschetti at googlemail.com]
> Sent: Monday, June 14, 2010 6:17 PM
> To: Jäger, Frank (KRZ)
> Subject: Re: [NAS] Buchauskunft
>
...
> Wie ist das eigentlich mit dem postnas im Moment, läuft das
> deiner meinung nach gut?
> Fortführungsfähig? Was müssen wir - technisch - da noch rein bekommen?
>

Hallo,
PostNAS läuft hier für 3 Gemeinden bereits "in Produktion". Es wird monatlich über NBA fortgeführt.
Neulich mussten wir mal mit einer Erstabgabe neu starten, weil sich Fehler eingeschlichen hatten.
   Der Fehler lag aber *nicht* im Konverter  ;-)

Die Konvertierung von NAS dauert allerdings deutlich länger als vergleichbare Gebiete in EDBS (edbs2wkt).

Als nächsten Schritt möchte ich in der Buchauskunft den "Flurstücksnachweis" vollständiger machen.
Dazu sollten dann z.B. die Abschnitte der tatsächlichen Nutzung angezeigt werden.

In ALKIS ist die Nutzungsart nun unabhängig von den Flurstücken. Wenn man wissen möchte, wie viel von einem Flurstück auf welche Nutzungsart entfällt, dann muss man das geometrisch verschneiden, richtig?

Wenn man *eine* Tabelle "tatsächlich Nutzung" hätte, dann könnte man die mit der aktuellen Flurstücksgeometrie verschneiden und bekäme i.d.R. eine, manchmal auch mehrere Teilflächen geliefert.
Die Flächengröße der Verschneidung und die entschlüsselt Nutzungsart könnte man anzeigen.

Nun haben wir aber leider 28 verschiedene Tabellen, nämlich für jede Nutzungart(gruppe) eine.
Man muss also nacheinander 28 Verschneidungen durchführen, die durchsnittlich 0,05 Treffer bringen. Aber es könnte ja sein, dass man doch mal ein "Hafenbecken" erwischt.

Wie kommen wir da raus?
Eine dicke UNION-Abfrage ist wohl auch nicht die Lösung.

Ich spiele schon mit dem Gedanken, die "jedes Flurstück mit jeder Nutzungsart"-Verschneidung als Preprozessing zwischen Konverter und Auswertung laufen zu lassen und eine Hilfstabelle zu füllen, die mir sagt, wo es überhaupt Überlappungen gibt. Aber das ist natürlich ganz schlechter Stil, redundant und inkonsistent.

Hier erscheint mir eine Zusammenfassung der Nutzungsarten-Tabellen sinnvoller. Könnte der Konverter das machen, oder richtet sich die Datenbank-Struktur strikt nach der XML-Struktur, so dass man dazu Sonderfälle und Ausnahmen programmieren müsste.


Mit freundlichen Grüßen
Frank Jäger_______________________________________________
NAS mailing list
NAS at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/nas