Datenquellen in Iwan7

Iwan kann auf verschiedene Datenquellen zugreifen. Dabei wird intern grob in die Kategorien

Vector Layer
CAD Layer
Raster Layer
Grid Layer

unterschieden. Je nach Typ sind bestimmte Operationen möglich. Jeder Ebenentyp kann zumindest in der Karte dargestellt werden. Abfragen per GeoSQL sind auf alle Vector Layer und einige andere möglich.

Die Ebenen werden beim ersten Zugriff "geladen". D.H. es werden einige Metadaten aus der Quelle ermittelt. Der Datenzugriff erfolgt i.d.R. immer direkt auf den angebundenen Datenspeicher, d.h. es erfolgt kein Import. Ein Cacheing wird nur bei bestimmten Datentypen durchgeführt. Der Server überwacht dann Änderungen an der Datenquelle und aktualisiert den Cache automatisch.

Die Beschreibung der Datenquelle erfolgt per Json-Notation. Die Argumente sind dabei abhängig vom Quelltyp. Zur Identifikation der Ebenen wird ein sog. LayerName vergeben. Ebenen können zudem in Projekten organisiert werden.

Generelle Features

Die in Iwan angebundenen Datenquellen sind recht flexibel ausgelegt.

Grundsätzlich gilt:

Geometrietypen pro Quelle können gemischt vorkommen, d.h. es ist zulässig das bspw. eine Tabelle Punkt-, Flächen- und Liniengeometrien enthält. Für diese Mischung von Geometrien liegen keine Einschränkungen vor, weder bei der Darstellung noch bei Abfragen.
techn. Metadaten an Quellen sind optional, d.h., wir bestehen nicht auf Registrierungen der Quellen (im jeweiligen System). Z.B. ist bei Datenbanken alles als Datenquelle möglich, was per SELECT * FROM ... abfragbar ist.
Mehrere Geometriespalten werden problemlos verarbeitet, lediglich für die Kartendarstellung ist eine "Hauptgeometrie" zu definieren.
Gleichbehandlung der Quellen ist garantiert. Vor allem im Bereich der Abfragen steht mit GeoSQL ein universelles Mittel zur Verfügung. Der Grundsatz bei der Implementierung ist: "Mach was geht in der originären Quelle, den Rest dann halt selber".

JSON Definition

Jede Datenquellenbeschreibung erfolgt in Form eines Json Objektes. Der Objektname wird dabei intern zum Ebenennamen. Obligatorisch für alle Definitionen ist die Angabe type. Die weiteren Argumente sind abhängig vom Quelltyp.

Sofern die Ebene Darstellungen per CSS unterstützt, kann immer cssFile oder style definiert werden.

Bsp.: Legt eine Ebene mit dem internen Bezeichner "STR" an, die auf eine Shape-Datei verweist.

{
"STR": {
    "type": "Shapefile",
    "filename": "..\\strasse.shp",
    "cssfile": "D:\\CSS\\str.css",
    "loadErrorBehavior":"Strict"
   }
}

Welchem Projekt die Ebene zugewiesen wird, ist vom Aufrufer abhängig und nicht in der Ebenenbeschreibung enthalten.

Hinweis: Der integrierte JSON Parser unterstützt eine erweiterte Syntax. Es können Kommentare angegeben werden und Zeichenfolgen können Umbrüche enthalten. Kommentare sind // (Single-Line) oder als Block durch /* und */ begrenzt möglich.

Allgemeine Eigenschaften

onexist

Der Ebenenname ist pro Projekt eindeutig. Wenn eine Ebene bereits vorhanden ist, kann optional das Attribut "onexist" angegeben werden.

Dabei kann einer der Werte verwendet werden: ¹⁾

ThrowIfExistsWithSameName : (Standard), Fehler melden, wenn bereits vorhanden
UseExisting : alle Argumente ignorieren und ohne Fehler die Beschreibung der vorhandenen Ebene zurückgeben
UseExistingIfLoadedBefore : Neuladen, wenn der Zeitpunkt des letzten Ladevorganges dieser Ebene vor dem mittels IfLoadedBefore übergebenem Zeitpunkt liegt.
- IfLoadedBefore muss in diesem Zusammenhang angegeben werden, der Zeitwert ist in der in ISO8601 beschriebenen Form anzugeben (Bsp.: "2016-02-25T18:23:27.9690000Z")
ReplaceExisting : neue Ebene bereitstellen, vorhandene Ebene entladen und die Beschreibung der neuen Ebene zurückgeben (in dieser Reihenfolge)
ReplaceIfArgumentsChanged : Neuladen, wenn die Argumente sich von der der geladenen Ebene unterscheiden. Über die relevanten Argumente wird dabei ein Hash-Wert gebildet, der dann hier zum Vergleich verwendet wird.

^{1) diese Angaben sind von der Implementierung des Layermanagers abhängig, konkret beschreibt dies die Implementierung in Iwan7}

Ebenennamen dürfen ...

keines der Zeichen /, \, ", :, ., <, >, -, ;, =, [, ], `, ^ enthalten

eine Länge von 255 nicht überschreiten.

der Charcode muss zwischen 32 und 123 sein

Einige Ebenen werten zudem das Flag für die Fehlertoleranz aus. Dieses wird über das Attribut "loadErrorBehavior" gesteuert. Standardwert ist "Strict". Einige Fehler können über die Angabe von "Lax" ignoriert werden. Ein Hinweise auf die Auswertung ist bei der Dokumentation zum Ebenentyp angegeben.

alternativeRenderSources

Ab der Version 7.0.4.

Für Optimierungen von Zeichenoperationen steht alternativeRenderSources zur Verfügung.

Auch hier ist der Hinweis auf die Nutzungsmöglichkeit in der Dokumentation zum Ebenentyp angegeben.

dimension

Ab der Version 7.5.0.3.

Die Eigenschaft dimension kann verwendet um Dimensionen für Vektorebenen zu definieren.

bboxOverride

Ab der Version 7.5.0.10.

Die Eigenschaft bboxOverride kann verwendet werden, um die auto. ermittelte Ausdehnung der Ebene zu überschreiben.

bboxOverrideAsUndefined e

Ab der Version 7.6.0.22.

Dient nur als Short-Cut für bboxOverride {0,0,0,0}, darf nicht gemeinsam mit bboxOverride verwendet werden.

Diese Angabe wird beim Abruf der Ebenenbeschreibung mit ausgegeben und findet intern keine weitere Beachtung.

Dies entspricht dem Verhalten von theInitExtent aus Iwan6.

Die Angabe wird in Form eines Objektes mit folgender Struktur erwartet:

{
    minx:double|null|undefined,
    miny:double|null|undefined,
    maxx:double|null|undefined,
    maxy:double|null|undefined,
    epsgCode :uint|null|undefined
}

Wenn einer der Werte (xmin ...) mit <> 0 belegt ist, dann sollten alle Werte inkl. des epsgCode angegeben werden. Dies wird z.Z. mit Rücksicht auf cardo3 nicht erzwungen.

Bsp. für eine Angaben, die in Iwan6 "theInitExtent:none" entspricht:

"bboxOverride":{}

sourceLable

Ab der Version 7.6.9.

Dieses Attribut wird nicht direkt von Iwan7 ausgewertet, aber in den Ebenenbeschreibungen wieder mit ausgegeben.

Dies ermöglicht Drittanwendungen, wie z.B. unserem cardo4, weitere Anwendungsspezifische Informationen zu transportieren.

In cardo kann damit die Datenquelle im Datenbrowser assoziiert werden. dbfs://freigabeNameImDatenbrowser::pfad würde cardo mitteilen, dass die Dateien (...der Quelle) in diesem Pfad des Datenbrowsers zu finden sind-

Übersicht der aktuell verfügbaren Datenquellen

Alle unten aufgeführten Datenquellen sind bereits vollständig implementiert. Ist noch kein Link zur Beschreibung vorhanden, ist lediglich die Dokumentation noch nicht vollständig.