Re: [NAS] Unnötig viele Zwischenpunkte im Geometriefeld
Ralf Suhr
Ralf.Suhr at itc-halle.de
Mon Okt 11 09:10:06 EDT 2010
Hallo Herr Jäger,
die von Ihnen vorgeschlagene Geometriereduzierung kann man noch erhöhen, wenn
man Flächen mittels ST_Union() zusammenfasst. Zumindest für die Tabellen der
Flächennutzung macht das Sinn, weil der Geometrieindex der Datenbank klein
bleibt.
Wenn Sie alle Geometrieobjekte beim Import in die Datenbank vereinfachen
wollen, so würde ich vorschlagen einen Trigger zu nutzen, der die Aktionen
ausführt. Somit wäre gewährleistet, das der Konverter je nach Bedarf noch die
unveränderten Geometrien schreibt oder noch weiter vereinfacht, wenn man den
WMS nur in grober Auflösung bereitstellen will.
Also etwa so:
CREATE OR REPLACE FUNCTION axsimlify()
RETURNS TRIGGER AS
$$
BEGIN
NEW.wkb_geometry := ST_Simplify(NEW.wkb_geometry, 0.002);
RETURN NEW;
END;
$$
LANGUAGE 'plpgsql';
CREATE TRIGGER axsimplify
BEFORE INSERT ON ax_wohnbauflaeche
FOR EACH ROW EXECUTE PROCEDURE axsimlify();
MfG
Ralf Suhr
Am Montag 11 Oktober 2010 14:37:08 schrieb 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
> _______________________________________________
> NAS mailing list
> NAS at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/nas
>