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.
lastModColumnName (null): Name einer Spalte, die das Änderungsdatum der Datenzeile als DateTime enthält. Diese Information wird in der Beschreibung der Datenquelle ausgegeben (mit dem Wert, der zum Zeitpunkt des Ladens der Ebene vorhanden war).
Beachte: Wenn angegeben, dann wird diese Information auch bei
quickLoad:true
ermittelt, d.h. es erfolgt dann immer ein Abfrage der Artselect count(*), max(modCol) from ...
.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: 20.09.2024 07:22:06 (erstmals erstellt 21.05.2019)