Punktebenen aus Datenbanken

Kann verwendet werden, wenn Rechts/-Hochwert Spalten in einer Datenbank als Punktgeometrie abgebildet werden müssen.

Es wird eine Geometrie-Spalte GEOM angefügt, die sich aus den definierten X/Y Werten ergibt.

Abfragen mittels GeoSQL sind möglich.

Argumente

Typname: PointLayer

  • driverType (odbc): Treiber für den Zugriff, einer der Werte Odbc, PostgreSQL oder Oracle

  • connectionString: Je nach Treiber, die Verbindungszeichenfolge zur Datenquelle.

  • userName (null): Benutzername zur Datenbank, überschreibt die in connectionString evtl. vorhandene Angabe, kann verschlüsselt angegeben werden.

  • passWord (null): Kennwort zur Datenbank, überschreibt die in connectionString evtl. vorhandene Angabe, kann verschlüsselt angegeben werden.

  • source: Name einer Abfrage oder Tabelle. Es kann sich dabei um jedes Datenbankstatement handeln, vom dem ein SELECT * FROM ... möglich ist. Handelt es sich um eine Abfrage, wird immer automatisch ein Alias angefügt. Bsp. für gültige Quellen:

    • TABELLEA
    • SELECT * FROM TABELLEA
    • (SELECT a,b,* FROM TABELLEA)
  • geomXValueColumnName: Name der Spalte mit Rechtswert (bzw. je nach Projektion), muss numerisch sein.

  • geomYValueColumnName: Name der Spalte mit Hochwert (bzw. je nach Projektion), muss numerisch sein.

  • quickLoad (false): Wenn false, dann werden Count, Srid und BBox über diese Abfrage ermittelt

  • idColumnName ("_auto_"): optionaler Name einer Spalte die eindeutige Werte enthält, wenn angegeben, dann muss die Spalte auch in {source} mit enthalten sein.

  • epsgCode (-1): Epsg-Code der Daten, wenn nicht definiert, dann wird eine automatische Ermittlung aus der Bounding-Box versucht

  • style|cssFile: hier immer vom Typ Vektor CSS.

Ladevorgang

Beim Laden wird einmalig

 SELECT * FROM {source} WHERE 1 = 0

zur Bestimmung der Spalten ausgeführt.

Der Name der neuen Geometriespalte lautete Geom.

Ist eine Spalte mit diesem Namen in der Quelle bereits vorhanden, dann wird der Spaltennamen Geom0 generiert (bzw. Geom1 ...).

Wenn nicht quickLoad:true angegeben ist, dann wird die BBox und Datensatzanzahl durch folgende Abfrage ermittelt:

SELECT 
   MIN({x}) as minx, MAX({x}) as maxx, 
   MIN({y}) as miny, MAX({y}) as maxy,
   COUNT(*) as cnt 
FROM 
   {src}
WHERE
  {x} IS NOT NULL AND {y} IS NOT NULL

Beispiel

Treiber ODBC:

[{
"pt":{
  "type":"PointLayer",
  "driverType":"ODBC",
  "connectionString":"Driver={SQL Server Native Client 11.0}; Server=srv\\inst; Database=cardo_ref;uid=XX;pwd=XX",
  "source":"dbo.odbc",
  "idColumnName":"ID",
  "geomXValueColumnName":"X",
  "geomYValueColumnName":"Y",
  "epsgCode":25833
  }
}]

... oder mit dem Treiber PostgreSQL:

[{
"pt":{
  "type":"PointLayer",
  "driverType":"PostgreSQL",
  "connectionString": "host=srv dbname=db port=5432",
  "source":"geodaten.odbc",
  "idColumnName":"ID",
  "geomXValueColumnName":"X",
  "geomYValueColumnName":"Y",
  "epsgCode":25833
  }
}]

... oder mit dem Treiber ORACLE:

[{
"pt":{
  "type":"PointLayer",
  "driverType":"Oracle",
  "connectionString": "TNSName",
  "source":"geodaten.odbc",
  "idColumnName":"ID",
  "geomXValueColumnName":"X",
  "geomYValueColumnName":"Y",
  "epsgCode":25833
  }
}]

Hinweise zur Verwendung in der cardo Umgebung

Hinweis: Die folgenden Ausführungen gehören nicht direkt zu Iwan7. Der hier vorgestellte Vorgang ist in cardo implementiert.

Bei der Verwendung in cardo werden für einige Funktionen, bspw. Beschriftung erstellen, GeoSQL etc, die "alten" Iwan6 basierten Ebenen ad-Hoc in einen Iwan7 Layer gewandelt und dort bereitgestellt.

Dazu wird die Ebenenbeschreibung aus Iwan6 ermittelt und diese in die Syntax von iwan7 überführt.

Das Gegenstück des PointLayers in Iwan6 ist der Ebenentyp "ODBC Punkte" (die anderen Spielarten, Kreise, Polygon etc. auf dieser Basis wurden kaum genutzt, so dass außen vor bleiben).

Hier gibt es einige beachtenswerte Hinweise. Das "Hauptproblem" hierbei ist, dass Iwan6 als 32 Bit Prozess ausgeführt wird, Iwan7 immer als 64Bit Prozess. Die ODBC Treiber sind meist architekturspezifisch benannt, und ein 64Bit Prozess kann keine 32Bit Treiber laden.

Bei der Konvertierung aus Iwan6 in Iwan7 wird anhand der eingestellten Verbindungszeichenfolge der passende driverType und connectionString für den zu erstellenden PointLayer ermittelt, wie der obigen Beschreibung zu entnehmen ist, muss es nicht unbedingt ODBC sein.

Regeln für die Ableitung der Parameter driverType und connectionString

Folgende Regeln sind implementiert. Betrachtet wird dabei die Verbindungszeichenfolge (Eigenschaft "theServer"):

Daraus werden die Eigenschaft=Werte Paare am Semikolon (ohne Beachtung von Anführungszeichen) aufgesplittet.

Bei den Eigenschaftsnamen spielt die Groß/Kleinschreibung keine Rolle, ist eine Liste von Werte vorhanden, wird der letzte Wert übernommen (die Reihenfolge ist dabei relevant).

  • Die Eigenschaften uid, user, user id werden als Nutzername übernommen.

  • Die Eigenschaften pwd, password werden als Kennwort übernommen.

  • Ist die Eigenschaft driver vorhanden, dann prüfe ob in dieser ...

    • der Wert sql server enthalten ist, dann

      • wird als driverType ODBC gesetzt,
      • das Argument "driver" wird immer in den Wert SQL Server Native Client 11.0 geändert,

        D.H. es muss im Fall von SQL Server ein SQL Server Native Client 11.0 installiert sein.

      • die Verbindungszeichenfolge wird aus allen anderen Eingangsparametern wieder zusammengebaut.
    • ... der Wert postgresql enthalten ist, dann

      • wird als driverType PostgreSQL gesetzt,
      • die Argumente server ,database, port müssen vorhanden sein und werden als Verbindungszeichenfolge in der Form "host=x dbname=x port=x" übergeben.
    • ... der Wert oracle enthalten ist, dann

      • wird als driverType Oracle gesetzt,
      • eine der Eigenschaften server dbq wird als Verbindungszeichenfolge direkt übergeben (meist handelt es sich dabei um einen TSN-Namen).
  • Traf keine der Regeln zu, dann wird als driverType ODBC gesetzt und die Verbindungszeichenfolge unverändert übernommen.

    An diesem Punkt ist die Wahrscheinlichkeit eines erfolgreichen Zugriffs recht gering (siehe Hinweise zu den Architekturunterschieden).

    Was tun?

    I) Verwende statt DSN Lose Einträge

    Meist sind DSN Einträge auf dem Server eingerichtet, dort ist der Treiber fest hinterlegt, es wird schlichtweg nicht funktionieren.

    Wir empfehlen besser DSN-lose Verbindungszeichenfolge zu verwenden. In diesem Fall greift der oben beschriebene Mechanismus.

    Häufig verwendete Eigenschaften können auch als cardo Variable definiert werden.

    Bsp.:

    DSN=TestPostres wird dann zu: driver={PostgreSQL ANSI};Server=XX;Port=5432;Database=db1

    Die Eigenschaften hier nur Beispielhaft aufgeführt, diese müssen nat. an die jeweilige Installation angepasst werden.

    II) Erstelle den DSN Eintrag identisch als 64 Bit Version

    Erstellen Sie den Eintrag mit dem 64Bit ODBC Admin.

    III) Es ist DSN los, aber der Treiber passt nicht

    Prüfen Sie, ob der Datenbanktreiber als 64Bit Version auf dem Server installiert ist, dies ist unbedingte Voraussetzung.

    Wenn der Name des Treibers sich von dem 32Bit Namen unterscheidet, dann müssen wir die Übersetzungsliste anpassen.

    Bitte sprechen Sie in dem Fall unsere Support an.

    IV) Es existiert keine 64 Bit Version des Treibers

    Dann ist die Datenquelle nicht verwendbar, hier müssen Sie auf eine andere Datenbank/Format umziehen.


Zuletzt geändert: 13.03.2024 12:40:13 (erstmals erstellt 21.05.2019)