[NAS] Unnötig viele Zwischenpunkte im Geometriefeld

[Jäger, Frank (KRZ)]

Hallo,
in der Liste des ALK-Konverters "edbs2wkt" fand heute eine Diskussion statt, wie man "unnötige" Zwischenpunkte aus der Geometrie eines Objektes entfernen kann.

Link zum Archiv: http://sourceforge.net/mailarchive/forum.php?forum_name=edbs2wkt-user
Betreff: "Flurstücksgrenzen" (2010, Oktober)

Die "Redundanzfreiheit" der ALK teilt eine Linie auch dann auf, wenn auf einer anderen Folie ein Objekt endet oder abzweigt.
Dieser "Zwischenpunkt" liegt dann /in der Geraden/ und macht für das aktuelle Objekt oder die aktuelle Folie keinen Sinn. Trotzdem schreibt der Konverter das zur Zeit in das Geometriefeld, weil die "Geradheit" beim Konvertieren nicht untersucht wird.

Ziel des Fragestellers war es dort (ALK), nur die unnötigen Zwischenpunkte zu entfernen, die von Objekten anderer Folien stammen, aber die Zwischenpunkte zu behalten, die von Objekten der gleichen Folie stammen. Dazu wurde noch keine Lösung gefunden.
Die Geometrie eines einzelnen Objektes - ohne die genannte Randbedingung - kann die PostGIS-Function "simplify" jedoch auf die notwendigen Punkte reduzieren.

Die Reduktion der ALK-Flächen mit einer Toleranz von "1 mm" reduziert die Punkte im Umring einer Fläche im Schnitt um 10 bis 20%. Den meisten Erfolg hat man bei den großen Flur-Objekten der Folie 002, wo bis zu 40% eingespart wird.

Da ich im ALKIS ähnliche Strukturen wie in der ALK vermute, habe ich auch dort die Potentiale untersucht.
Der folgende SQL-Select analysiert exemplarisch an 3 ALKIS-Tabellen (PostNAS 0.5) welche Vereinfachung bei verschiedenen Toleranz-Parametern erfolgen würde.

Zu meinem Erstaunen reduziert bereits der Tolerenz-Parameter "1 Millimeter" die Anzahl der Punkte in einem Umring auf unter 50%!
Das ist wesendlich mehr als in der ALK. Ich hatte eigentlich weniger vermutet, weil z.B. Flurstücke und Nutzungsarten in ALKIS entkoppelt sind.

<SQL>
SELECT 
  count(gml_id) AS anzahl,
  round(avg(ST_npoints(wkb_geometry)),2)
     AS punktanzahl_orig,
  round(avg(ST_npoints(st_simplify(wkb_geometry, 0.001))),2)
     AS punktanzahl_simply_mm,
  round(avg(ST_npoints(st_simplify(wkb_geometry, 0.01))),2)
     AS punktanzahl_simply_cm,
  round(avg(ST_npoints(st_simplify(wkb_geometry, 0.05))),2)
     AS punktanzahl_simply_5cm
  FROM [tabelle]
;
</SQL>

Das liefert folgende Ergebnisse:

                             -- Anzahl Punkte im Umring --
  Tabelle               Anz. PostNAS  --Simplify-Toleranz--
                        Obj. Orig.     1 mm    1 cm    5 cm 
  -----------------   ------ ------  ------  ------  ------
Musterkarte RLP:
  ax_flurstueck         2369  20.45   10.24    9.06    8.80
  ax_wald                 89  20.70   11.53   11.15   11.08
  ax_wohnbauflaeche       76  28.37   12.59   11.53   10.91
Lokale Produktionsdaten:
  ax_flurstueck        23589  30.55   12.60   11.57   11.08
  ax_wald               1207  61.44   27.88   27.24   26.28
  ax_wohnbauflaeche     2357  44.41   18.60   16.55   15.54


Dies Ausmaß hat mich erstaunt. Bei der Umsetzung von ALK nach ALKIS muss wohl etwas sub-optimal gelaufen sein.

Je nach Verwendungzweck kann also die Komplexität der Geometrie und somit Speichervolumen, Datentransfervolumen (DB -> Renderer) und die Zeit für das Rendern erheblich optimiert werden.
Da ALKIS aufgrund der zerfledderten Tabellen (Nutzung) unser langsamster WMS ist, würde ein wenig Tuning durchaus als wohltuend empfunden.

Selbst wenn es sich z.B. um einen vermarkten Grenzpunkt in einer Flurstücksgrenze handelt, kann dieser m.E. für einen WMS ohne Qualitätsverlust aus dem Flurstücks-Umring entfernt werden.
Der Grenzstein darauf wird aus einer anderen (Punkt-) Tabelle generiert und Kringel samt Loch darin werden über die Flurstücksgrenze drüber gerendert. Somit wäre dieser Zwischenpunkt in der Flächengeometrie des Flurstücks entbehrlich, wenn es nur um das Rendern einer Karte geht.

Die Optimierung der Geometrie nach der Konvertierung kann z.B. über folgende SQL-Befehle erfolgen:

<SQL>
UPDATE ax_wald
SET    wkb_geometry = st_simplify(wkb_geometry, 0.002);

UPDATE ax_wohnbauflaeche
SET    wkb_geometry = st_simplify(wkb_geometry, 0.002);

UPDATE ax_flurstueck
SET    wkb_geometry = st_simplify(wkb_geometry, 0.002);
</SQL>

Usw.
(Tolerenz hier: 2 mm)

Spricht sonst etwas dagegen, die Geometrie zu vereinfachen?

Für welche anderen Anwendungen wäre es möglicherweise sinnvoll, solche Punkte zu behalten?

Sollte man das "simplify" (optional) gleich beim Konvertieren anwenden?
(Das wäre insbesondere beim NBA-Verfahren effektiver als nach jeder Konvertierung immer alle Geometriefelder zu bearbeiten.)
Dann wäre der Konverter zu erweitern.

Wer kann sich die Vermehrung von unnötigen Zwischenpunkten von ALK nach ALKIS erklären? 



Mit freundlichen Grüßen
Frank Jäger

Kommunales Rechenzentrum
Minden-Ravensberg/Lippe