Geometry Handler

Geometry Handler (Port:7203)

Der Geometry Handler verwaltet den Import und Export aller Geometrien in und aus einer Postgres-Datenbank. Die Export API ist in Anlehnung an die OGC API Specification gestaltet und bietet Abfragemöglichkeiten auf verschiedenen Ebenen. Importiert werden WKT-Geometrien, welche aus verschiedenen Dateien gelesen bzw. erstellt werden (XML/LandXML, TXT/CSV). Während des Imports werden Informationen, wie die UUID, die räumliche und geometrische Dimension und der Pfad zur Quelldatei gesammelt und an den File Input Handler gesendet. Dieser erstellt daraus in der GraphDB-Datenbank eine Instanz der Geometrie, welche weiter semantisch angereichert und verlinkt werden kann. Jede Instanz erhält einen eindeutigen Link, über den sich die Geometrie in der Postgres-Datenbank zweifelsfrei über die REST-Schnittstelle abfragen lässt.

Außerdem kann der Geometry Handler zum Updaten von TINs genutzt werden. Dafür werden die Veränderungen (hinzugefügte, entfernte Punkte, Bruchkanten) als JSON an die API gesendet. Damit wird das originale TIN aus Postgres abgefragt. Es werden die Punkte verändert und ein neues TIN berechnet. Dafür wird die JTS Topology Suite verwendet. Das neue TIN wird in Postgres gespeichert und in Postgres werden die zugehörigen Daten, sowie die Verknüpfung zur älteren Version gespeichert. Hierfür wird eine Versionsnummer hochgezählt.

Funktionsweise

Import:

[GET] /geometry/import/bucket/{bucket}/graphDbRepo/{graphDbRepo}

• Angabe eines MinIO Bucket als Quellordner und einer Postgres Datenbank als Zieldatenbank, sowie eines GraphDB Repository

• bei Start des Containers Prüfung, ob Datenbank bereits über ein entsprechendes Schema und Tabellen verfügt, wenn nicht wird Schemadatei zur Erstellung dieser ausgeführt

• Tabellen im Schema:

  • point_2d
  • point_3d
  • line_2d
  • line_3d
  • polygon_2d
  • polygon_3d
  • solid
  • dtm_tin
  • dtm_breaklines
  • dtm_specialpoints
  • dtm_embarkment

• Bucket wird nach Dateien mit den Endungen .xml, .txt, .csv durchsucht

• ist die XML-Datei eine LandXML-Datei, werden darin TIN's gesucht und deren Points und Faces werden in ein WKT-TIN umgewandelt

• TIN wird in die Datenbank importiert

• existieren Bruchkanten, werden diese als WKT-LINESTRING in die Tabelle dtm_breaklines importiert

• besondere Punkte werden als WKT-POINT Z in die Tabelle dtm_specialpointsimportiert

• TXT- und CSV-Dateien werden nach WKT-Strings durchsucht und diese werden je nach Geometrietyp in die jeweilige Tabelle importiert

• für jede importierte Geometrie werden Metadaten an den File Input Handler gesendet, der diese in Triple umwandelt und in das als Ziel angegebene Repository importiert

[GET] /geometry/import/bucket/{bucket}/graphDbRepo/{graphDbRepo}/file/{filename}

• zusätzlich zum Vorherigen Angabe eines Dateinamens, sodass nur eine spezielle Datei importiert wird

Export:

[GET] /geometry/export/

• Landing Page, auf der u.a. Verlinkungen auf die Unterseiten verweisen (noch nicht implementiert)

[GET] /geometry/export/conformance

• gibt Konformitätsklassen aus Standards und Spezifikationen an (noch nicht implementiert, eventuell nicht benötigt)

[GET] /geometry/export/collections

• gibt die Namen aller Geometrie-Tabellen zurück

[GET] /geometry/export/collections/{collectionId}

• gibt Informatione über eine Tabelle zurück

[GET] /geometry/export/collections/{collectionId}/items

• gibt die ID's aller Elemente einer Tabelle zurück

[GET] /geometry/export/collections/{collectionId}/items/{featureId}

• gibt die Geometrie des Elementes mit der angegeben ID im Koordinatenreferenzsystem ETRS89 / UTM Zone 32N zurück

[GET] /geometry/export/collections/{collectionId}/items/{featureId}/epsg/{epsg}

• gibt die Geometrie des Elementes mit der angegeben ID im gewünschten Koordinatenreferenzsystem zurück

Alle Abfragen werden als SQL-Befehl an die Datenbank gesendet.

Query Information

[GET] /geometry/geometry/query/exteriorring/tinid/{id}

• gibt den Umring des eingegebenen TIN als Polygon zurück

Edit Geometry

[POST] /geometry/edit/updateTIN/repo/{repo}

• Berechnung eines neuen TIN nachdem das Ausgangs-TIN verändert wurde
• Hinzufügen und Entfernen von Punkten, Einfügen von Bruchkanten
• Eingabe erfolgt als JSON:

[
  {
    "ObjectInfo": {
      "CollectionId": "string",
      "FeatureId": "string",
      "SRID": int
    },
    "MetaInfos": {
      "GroundChange": double,
      "User": "string"
    },
    "Breaklines": [
      [
        [
          x,
          y,
          z
        ], ...
      ],... 
    ],
    "AddedPoints": [
      [
        x,
        y,
        z
      ], ...
    ],
    "RemovedPoints": [
      [
        x,
        y,
        z
      ], ...
    ]
  }, ...
]

• Berechnung des TIN erfolgt als konforme Delaunay Triangulation mit der Bibliothek JTS
• neues TIN wird in Postgres gespeichert
• Massenänderungen zwischen den TINs werden berechnet
• TIN Metadaten werden in GraphDB importiert
• außerdem wird Versionsnummer hochgezählt und Knoten für den Prozess TINUpdate angelegt
• Knoten enthält Angaben zu Input, Output und Original TIN des Update Prozesses, sowie Aushub, Aufschüttung und Massenänderung gesamt

Calculate with Geometry

[POST] /geometry/calc/massDifference/firstTIN/{firstTinId}/secondTIN/{secondTinId}

• Eingabe zweier TINs, die den gleichen Bereich abbilden, in dem Änderungen vorgenommen worden
• optional: Verwendung einer Bruchkante oder Eingabe eines geschlossenen und im Bereich der TINs liegenden WKT LineStrings als Begrenzung für die Berechnung
• augegeben werden die gesamte Massenänderung, sowie die Aufschlüsselung in Aushub und Aufschüttung

[POST] /geometry/calc/gradient

• Eingabe eines TIN, eines darauf liegenden Punktes und eines Radius zum Puffern um den Punkt
• alle Dreiecke des TIN werden gesucht, die vom Pufferpolygon überlappt werden
• für jedes Dreieck wird die Neigung bestimmt
• aus Liste mit allen Neigungen im Pufferbereich werden
  • Anzahl der betroffenen Flächen
  • minimale Neigung
  • maximale Neigung
  • durchschnittliche Neigung
  • Median der Neigung
    bestimmt