Für die Ausführungen bezüglich der Darstellungsmodelle (z.B. Blöcke oder Linien) gilt für den DWG-Export:
- Export als "Bearbeitbar"
- Export mit Vorlage
Die Vorlage muss entsprechend Blöcke, Linien und Layer (speziell für Blockfarbe) enthalten.
Ich hatte das nicht ausdrücklich erwähnt. Getestet soweit mit Map 2013 SP2 und tw. mit Map 2014.
About things that happened to me at work.
Wednesday, 11 December 2013
Zeilenumbruch bei Labels - \n oder \P?
Es gilt:
- Label ist als MText definiert : Zeilenumbruch muss mit \P erfolgen
- Label ist als Text definiert : Zeilenumbruch muss mit \n erfolgen
Map 2013, SP2
- Label ist als MText definiert : Zeilenumbruch muss mit \P erfolgen
- Label ist als Text definiert : Zeilenumbruch muss mit \n erfolgen
 |
| Label als "MText" - Zeilenumbruch "\n" funktioniert nicht. |
 |
| Label als "Text - Zeilenumbruch über "\n" |
Tuesday, 26 November 2013
Untergeordnete Objekte löschen
Bei einem der eigenen Datenmodelle haben wir ein Objekt mit mehreren untergeordneten Objekten. Die Zuordnung ist entsprechend als Relation in Map gespeichert. Als Relationstyp ist "Objekt löschen, wenn das übergeordnete Objekt gelöscht wird" definiert:
Beim Löschen des übergeordneten Objektes wurden nur einige Unterobjekte gelöscht, aber nicht alle wie erwartet. Neben der Relation und dem passenden Relationstyp bedarf es noch der Aktivierung der Client-Objektregel "Delete (Collect FIDs)". Zur Regel heisst es im Flyout-Text: "Kaskadierendes Löschen der untergeordneten Objekte zusammen mit TB_REALTIONS".
Ich bin mir nicht sicher, ob die Objektregel automatisch aktiviert werden sollte wenn man den oben genannten Relationstyp auswählt oder nicht. Falls es einer manuellen Einstellung bedarf sollte es in der Hilfe erwähnt sein. Nach dem Aktivieren der Regel wurden alle untergeordneten Objekte beim Löschen des Hauptobjektes ebenfalls gelöscht. Vielen Dank an den Autodesk Support für den Hinweis.
Map 2013, SP2
 |
| Relation mit Relationstyp |
 |
| Client-Objektregel "Delete" muss aktiv sein |
Map 2013, SP2
Thursday, 21 November 2013
TB2 Darstellungsmodell nach Map umstellen – Beispiel 2 – Linie
In Fortführung des Beitrages von letzten Monat (Blöcke). Mir fehlt etwas die Zeit für eine ausführlichere Beschreibung, bei Fragen antworte ich gerne.
In Kurzform wie man Liniensignaturen aus TB2 nach Map
übernimmt und diese auch wieder über den DWG Export als Zeichnung sauber abgeben
kann:
Hinweise:
(1) Die Angaben bei der AutoCAD Linientypdefinition
sind ohne Einheiten. Die Angaben der Linientypdefinition im Map-Layer (zumindest bei
<Geometry>, <Repeat>) sind immer in "Millimeter".
(2) Die Linie im Beispiel stammt aus einem TB2 DM für den Plotmassstab
1:1000.
Vorgehensweise:
1. TB2 Prototypzeichnung öffnen und Liniendefinitionen als
LIN Datei exportieren (falls man die LIN Dateien nicht mehr hat) – Empfohlen mit
frei verfügbaren Werkzeug von CadStudio, Export mit dem Befehl "Linout1"
(ohne SHX Symbol-Export), nicht mit LINOUT (mit SHX Export), Link Download.
2. Bildaufbau mit Map
3. Stil-Editor für Linienfeatureklasse öffnen
3. Karteneinheiten auf Meter setzen
4. Lin Datei importieren und der Linie die gewünschte
Liniensignatur zuweisen
5. Darstellungsmodell/Layer speichern
6. Layer im Text-Editor öffnen
Liniendefinition – für AutoCAD
*LTYPWZS2,[WLT2] LTYPWZS2
A, 0.5, -0.2
Liniendefinition in der Layer-Datei in Map nach dem Import
<Geometry>M 0,0 L 5,0 </Geometry>
...
<Repeat>5.6</Repeat>
Signaturdefinition im Map-Layer wie Signaturdefinition für
AutoCAD Linie aber mit Faktor 10 multipliziert. In AutoCAD ist der Abstand
zwischen zwei Linien "0.2" Einheiten, im Map Layer dagegen "0.6"
Einheiten, da bei <Repeat> der Wert "5.6" eingetragen ist.
8. Der Abstand zwischen den Linienstückchen ist in Map also
falsch und muss korrigiert werden. Abstand bei AutoCAD – "0.2", den
Wert mit Faktor 10 multiplizieren ergibt: "2"
Repeat Faktor = Länge der Geometrie (<Geometry>) +
gewünschter Abstand
Repeat Faktor
= 5 + 2 = 7
<Repeat>7</Repeat>
9. Bei <ParameterOverrides> die Werte bei
<ParameterIdentifier>StyleEditorGenerated_ScaleX_0</ParameterIdentifier>
<ParameterIdentifier>StyleEditorGenerated_ScaleY_0</ParameterIdentifier>
auf
"1" setzen.
Jetzt ist die Liniensignatur in Map mit der von AutoCAD
identisch. Was noch fehlt ist die korrekte Skalierung. Im Beispiel ist der
Skalierfaktor für die Linien in AutoCAD "1" (1:1000 Plotmassstab der Zeichnung in TB2)
 |
| Linieneigenschaften in TB2 DM |
10. Skalierung anpassen
Nach </ParameterOverrides> folgende Ergänzungen
vornehmen:
<ScaleX>1000</ScaleX>
<ScaleY>1000</ScaleY>
Jetzt ist die Linie in Map gleich skaliert wie die Linie in
AutoCAD. Das funktioniert nun auch für den DWG Export. Die exportierte Linie behält ihre Skalierung (zumindest in Map 2013, SP2).
Restarbeiten: Linienstärke ist im TB2 Darstellungsmodell mit
"ElementSize" = "2" angegeben. In Map errechnet sich dann
die Linienstärke so:
Wert ElementSize in TB2 DM * gewünschter Plotmassstab
Bei ParameterOverrides gibt man dann bei LINEWEIGHT an:
<ParameterIdentifier>LINEWEIGHT</ParameterIdentifier>
<ParameterValue>2
* 1000</ParameterValue>
Im Abschnitt <Path> noch abgeben, dass die Linienenden
nicht abgerundet werden sollen:
<LineCap>None</LineCap>
 |
| Links - Map, rechts - TB2 |
Hier die modifizierten Teile des Layers:
<Path>
<Geometry>M 0,0
L 5,0 </Geometry>
<ScaleX>%StyleEditorGenerated_ScaleX_0%</ScaleX>
<ScaleY>%StyleEditorGenerated_ScaleY_0%</ScaleY>
<LineColor>%LINECOLOR%</LineColor>
<LineWeight>%LINEWEIGHT%</LineWeight>
<LineWeightScalable>false</LineWeightScalable> <LineCap>None</LineCap>
</Path>
</Graphics>
<LineUsage>
<Repeat>7</Repeat>
</LineUsage>
....
<ParameterOverrides>
<Override>
<SymbolName>LTYPWZS2</SymbolName>
<ParameterIdentifier>LINECOLOR</ParameterIdentifier>
<ParameterValue>ff000000</ParameterValue>
</Override>
<Override>
<SymbolName>LTYPWZS2</SymbolName>
<ParameterIdentifier>LINEWEIGHT</ParameterIdentifier>
<ParameterValue>2
* 1000</ParameterValue>
</Override>
<Override>
<SymbolName>LTYPWZS2</SymbolName> <ParameterIdentifier>StyleEditorGenerated_ScaleX_0</ParameterIdentifier>
<ParameterValue>1</ParameterValue>
</Override>
<Override>
<SymbolName>LTYPWZS2</SymbolName>
<ParameterIdentifier>StyleEditorGenerated_ScaleY_0</ParameterIdentifier>
<ParameterValue>1</ParameterValue>
</Override>
</ParameterOverrides>
<ScaleX>1000</ScaleX>
<ScaleY>1000</ScaleY>
....
Wednesday, 20 November 2013
TB_LABEL_DEF.ID
In der Map-Hilfe ist zu TB_LABEL_DEF.ID folgendes hinterlegt:
"Speichert die ID der Labeldefinition. Die benutzerdefinierte Labeldefinition beginnt mit der ID 10.000. IDs, die kleiner als 10.000 sind, werden für Autodesk-Anwendungen verwendet."
Probleme könnten nun im Zusammenhang mit CountryKits entstehen. Im "Workbook" für das CK Abwasser (CH, 2013) findet man Verweise auf Labels mit einer bestimmten ID, z.B. ID=10025.
Legt man als Benutzer eigene Labeldefinitionen an, scheint es besser zu sein, IDs nicht im zehntausender Bereich zu verwenden, da dort auch Label-Definition der CountyrKits definiert sind. Ein CK Update könnte ein neue Label-Definition einführen und - so mein Verständnis - dazu führen, dass eine eigene Label-Definition überschrieben wird.
Nachträglich kann man die ID manuell in der Tabelle ändern. Besser ist es, bei der Erstellung der Labeldefinitionen geeignete IDs zu verwenden. Die Vergabe der IDs bei den Label-Definitionen werden über die Sequenz TB_LABELDEF_S gesteuert.
Es gibt zwei Varianten wie man die Sequenz ändern kann:
a) Sequenz löschen und neu erstellen
Vorteil - einfache Vorgehensweise
Nachteil - Berechtigungen anderer Oracle Benutzer (speziell Gastdokumente) gehen beim Löschen der Sequenz verloren und müssen nachträglich wieder neu eingerichtet werden
Zur Kontrolle - wer hat Berechtigung auf der Sequenze?
select * from all_tab_privs where table_name='TB_LABELDEF_S';
Falls jemand Berechtigung hat (sollten nur bestehende Gastdokumente sein) müssen diese Berechtigungne nachträglich manuell wieder gesetzt werden.
drop sequence TB_Labeldef_s;
create sequence TB_Labeldef_s__x
increment by 1
start with 20000 -- neuer Startwert
minvalue 20000
maxvalue 9999999999999999999999999999
nocycle;
b) bestehende Sequenz ändern
Vorteil - bestehende Berechtigungen gehen nicht verloren
Nachteil - umständlichere Vorgehensweise
Die Vorgehensweise ist im Internet mehrfach beschrieben (z.B. https://forums.oracle.com/thread/1999691).
Aufpassen muss man, wenn Labeldefinitionen direkt in die Tabelle eingetragen werden. Dann wird die Sequenz nicht zwangsläufig verwendet und bereits vergebene IDs in der Tabelle sind in der Sequenz noch verfügbar. Legt man eine neuen Labeldefinition an und die bereitgestellt ID aus der Sequenz ist bereits in der Tabelle vergeben, erhält man eine Fehlermeldung beim Einfügen:
Offenbar gibt es hier eine Abweichung von der Map-Dokumentation und dem Verhalten von Map und der Vergabe der IDs in Countrykits. Die IDs ab 10000 stehen eben gerade nicht für benutzerdefinierte Labeldefinitionen zur Verfügung.
Map 2013, SP2
"Speichert die ID der Labeldefinition. Die benutzerdefinierte Labeldefinition beginnt mit der ID 10.000. IDs, die kleiner als 10.000 sind, werden für Autodesk-Anwendungen verwendet."
Probleme könnten nun im Zusammenhang mit CountryKits entstehen. Im "Workbook" für das CK Abwasser (CH, 2013) findet man Verweise auf Labels mit einer bestimmten ID, z.B. ID=10025.
 |
| Anlegen einer eigenen Label-Definition - ID im Beispiel ist im gleichen Bereich wie IDs des CountryKit. |
Legt man als Benutzer eigene Labeldefinitionen an, scheint es besser zu sein, IDs nicht im zehntausender Bereich zu verwenden, da dort auch Label-Definition der CountyrKits definiert sind. Ein CK Update könnte ein neue Label-Definition einführen und - so mein Verständnis - dazu führen, dass eine eigene Label-Definition überschrieben wird.
Nachträglich kann man die ID manuell in der Tabelle ändern. Besser ist es, bei der Erstellung der Labeldefinitionen geeignete IDs zu verwenden. Die Vergabe der IDs bei den Label-Definitionen werden über die Sequenz TB_LABELDEF_S gesteuert.
Es gibt zwei Varianten wie man die Sequenz ändern kann:
a) Sequenz löschen und neu erstellen
Vorteil - einfache Vorgehensweise
Nachteil - Berechtigungen anderer Oracle Benutzer (speziell Gastdokumente) gehen beim Löschen der Sequenz verloren und müssen nachträglich wieder neu eingerichtet werden
Zur Kontrolle - wer hat Berechtigung auf der Sequenze?
select * from all_tab_privs where table_name='TB_LABELDEF_S';
Falls jemand Berechtigung hat (sollten nur bestehende Gastdokumente sein) müssen diese Berechtigungne nachträglich manuell wieder gesetzt werden.
drop sequence TB_Labeldef_s;
create sequence TB_Labeldef_s__x
increment by 1
start with 20000 -- neuer Startwert
minvalue 20000
maxvalue 9999999999999999999999999999
nocycle;
b) bestehende Sequenz ändern
Vorteil - bestehende Berechtigungen gehen nicht verloren
Nachteil - umständlichere Vorgehensweise
Die Vorgehensweise ist im Internet mehrfach beschrieben (z.B. https://forums.oracle.com/thread/1999691).
 |
| Nach dem Ändern der Sequenz beginnt die ID Vergabe nun bei 20000 |
 |
| Labeldefinitions-ID bereits vorhanden - Fehlermeldung im Administrator beim Versuch, die Labeldefinition abzuspeichern. |
Offenbar gibt es hier eine Abweichung von der Map-Dokumentation und dem Verhalten von Map und der Vergabe der IDs in Countrykits. Die IDs ab 10000 stehen eben gerade nicht für benutzerdefinierte Labeldefinitionen zur Verfügung.
Map 2013, SP2
Tuesday, 19 November 2013
Datenimport - Geometrieprüfung - Fehler beheben
Bei der Ausführung der 1-Klick-Wartung erfolgt auch eine Geometrieprüfung. Beheben lassen sich die Fehelr aus dem Administrator heraus allerdings nicht.
Speziell folgende Meldung erschien bei mir nach dem Import von SHP Dateien über "In Fachschale konvertieren" (_mapconverttomodel):
Ungültige Geometrie AL_KBS_Unfall 1800 13367 [Element <1>] [Ring <1>]
Beim Bildaufbau fiel das Problem nicht auf. Erst bei der Ausführung der 1-Klick Wartung wurden die fehlerhaften Geometrien gemeldet.
Nach dem Einlesen von Fremddaten mit Map sollte man daher deren Validität in Oracle prüfen und die Oracle Funktionen zur automatischen Bereinigung nutzen. Nicht alle Probleme mit SpatialData lassen sich jedoch in Oracle lösen. Speziell der Oracle Spatial Fehler 13367 lässt sich jedoch über die Oracle Funktion MDSYS.SDO_UTIL.RECTIFY_GEOMETRY auch beheben.
Erleichtert wird die Fehlersuche und deren Behebung in SQLDeveloper übrigens mit dem Plugin "Georaptor". Die Funktionen gehen über die im SQLDeveloper vorhandenen Funktionen für Spatial-Data hinaus und sind in der Bedienung auch einfacher.
Speziell folgende Meldung erschien bei mir nach dem Import von SHP Dateien über "In Fachschale konvertieren" (_mapconverttomodel):
Ungültige Geometrie AL_KBS_Unfall 1800 13367 [Element <1>] [Ring <1>]
Beim Bildaufbau fiel das Problem nicht auf. Erst bei der Ausführung der 1-Klick Wartung wurden die fehlerhaften Geometrien gemeldet.
Nach dem Einlesen von Fremddaten mit Map sollte man daher deren Validität in Oracle prüfen und die Oracle Funktionen zur automatischen Bereinigung nutzen. Nicht alle Probleme mit SpatialData lassen sich jedoch in Oracle lösen. Speziell der Oracle Spatial Fehler 13367 lässt sich jedoch über die Oracle Funktion MDSYS.SDO_UTIL.RECTIFY_GEOMETRY auch beheben.
Erleichtert wird die Fehlersuche und deren Behebung in SQLDeveloper übrigens mit dem Plugin "Georaptor". Die Funktionen gehen über die im SQLDeveloper vorhandenen Funktionen für Spatial-Data hinaus und sind in der Bedienung auch einfacher.
Monday, 18 November 2013
In Fachschale konvertieren - "FEHLER: Int64Value ist Null"
Beim Konvertieren einer SHP Datei über die Funktion "In Fachschale konvertieren" erscheint die folgende Fehlermeldung:
FEHLER: Int64Value ist Null.
Leider hilft die Meldung hier nicht unmittelbar weiter, um die Ursache zu identifizieren.
Nach einigen Tests konnte das Problem eingegrenzt werden - in der SHP Datei gibt es ein Feld "ID" mit dem Datentyp "String". In Oracle ist der Datentyp in der Tabelle aber als "Number" konfiguriert. Beim Import kann der Datentyp dann nicht konvertiert werden. Die Fehlermeldung "Int64Value ist Null" zeigt zwar in die richtige Richtung - aber wirklich hilfreich ist sie nicht. Ändert man in Oracle den Datentyp auf Varchar2 dann läuft der Import ohne weiteres durch.
Erhält man diese oder ähnliche Meldungen beim Import sollte man zunächst die Datentypen im Ausgangsdatensatz und in der Zieltabelle miteinander vergleichen.
Map 2103, Sp2
Meldungen beim Import:
Befehl: _mapconverttomodel ==============================================
Datenprotokoll-Meldungen hinzufügen
______________________________________________
Importieren von Objekt aus 'kbs_abl_aktuell.shp' starten
Koordinatensystem der Quelle: CH1903/GSB.LV03-M
Koordinatensystem von Ziel: Swiss National System
FEHLER: Int64Value ist Null.
Datenquelle: kbs_abl_aktuell.shp
Importieren von Objekt aus 'kbs_abl_aktuell.shp' beendet.
______________________________________________
Zusammenfassung
Import wurde abgebrochen. Alle eingefügten Objekte wurden verworfen.
==============================================
FEHLER: Int64Value ist Null.
Leider hilft die Meldung hier nicht unmittelbar weiter, um die Ursache zu identifizieren.
Nach einigen Tests konnte das Problem eingegrenzt werden - in der SHP Datei gibt es ein Feld "ID" mit dem Datentyp "String". In Oracle ist der Datentyp in der Tabelle aber als "Number" konfiguriert. Beim Import kann der Datentyp dann nicht konvertiert werden. Die Fehlermeldung "Int64Value ist Null" zeigt zwar in die richtige Richtung - aber wirklich hilfreich ist sie nicht. Ändert man in Oracle den Datentyp auf Varchar2 dann läuft der Import ohne weiteres durch.
Erhält man diese oder ähnliche Meldungen beim Import sollte man zunächst die Datentypen im Ausgangsdatensatz und in der Zieltabelle miteinander vergleichen.
Map 2103, Sp2
Meldungen beim Import:
Befehl: _mapconverttomodel ==============================================
Datenprotokoll-Meldungen hinzufügen
______________________________________________
Importieren von Objekt aus 'kbs_abl_aktuell.shp' starten
Koordinatensystem der Quelle: CH1903/GSB.LV03-M
Koordinatensystem von Ziel: Swiss National System
FEHLER: Int64Value ist Null.
Datenquelle: kbs_abl_aktuell.shp
Importieren von Objekt aus 'kbs_abl_aktuell.shp' beendet.
______________________________________________
Zusammenfassung
Import wurde abgebrochen. Alle eingefügten Objekte wurden verworfen.
==============================================
Wednesday, 13 November 2013
SQL-Protokoll im Administrator
Vor ein paar Tagen ist mir in der Hilfe zufällig die Beschreibung einer Funktion ins Auge gefallen für die ich heute einen konkreten Anwendungsfall hatte.
Das man Featureklassen in der Fachschale per Script (bzw. per API) "registrieren" kann ist mir im Zusammenhang mit der bei uns laufenden Migration bewusst geworden als ich in die Migrationsscripte von Autodesk Consulting reingeschaut hatte.
Jetzt wollte ich eine ähnliche Vorgehensweise aber für Domaintabellen. Eine Möglichkeit ist, in die Server API Hilfe zu schauen und nach dem passenden Aufruf zu suchen. Variante 2 ist die Nutuzung der Funktion "SQL Protokoll" im Administrator.
Die Funktion findet man im Kontextmenü des Datenmodellexplorers. Mit der Funktion kann man dem Administrator bei der Arbeit - zumindest teilweise - über die Schulter schauen. Damit liess sich schnell herausfinden, dass man Domaintabellen mit dem Aufruf "MAPSYS.Domain.CreateDomainTable" erzeugt.
Map 2013, SP2
Das man Featureklassen in der Fachschale per Script (bzw. per API) "registrieren" kann ist mir im Zusammenhang mit der bei uns laufenden Migration bewusst geworden als ich in die Migrationsscripte von Autodesk Consulting reingeschaut hatte.
Jetzt wollte ich eine ähnliche Vorgehensweise aber für Domaintabellen. Eine Möglichkeit ist, in die Server API Hilfe zu schauen und nach dem passenden Aufruf zu suchen. Variante 2 ist die Nutuzung der Funktion "SQL Protokoll" im Administrator.
 |
| SQL Protokoll im Administrator |
Map 2013, SP2
Tuesday, 12 November 2013
TB_SQL und Performance
Die Frage, die sich bei Verwendung von TB_SQL auch stellt ist die nach den Auswirkungen auf die Performance, speziell im Web.
Mit AIMS 2013 steht ein einfaches Werkzeug zum Messen der benötigten Zeit für die Erstellung der Karte zur Verfügung (siehe für eine Beschreibung hier und hier).
Am Beispiel einer einfachen Berechnung (siehe hier) habe ich die zwei Varianten "View" und "TB_SQL" miteinander verglichen:
Die Tabelle gibt die Werte aus dem AIMS Performance Bericht wieder. Jeweils 10 Abfragen mit unterschiedlichen Kartenausschnitten bei einem Massstab von 1:10000. Die Karte enthält jeweils nur den Layer basierent auf dem View bzw. auf der Tabelle mit TB_SQL in der Layerdefinition. Darstellung und Massstabsbereiche sind gleich definiert.
Ergebnis: Die Unterschiede sind - schaut auf den Mittelwert für die Gesamtdauer - hier minimal. Für komplexere Abfragen muss man die Performance nochmal anschauen. Es wäre interessant zu erfahren, welche Erfahrungen andere Anwender bisher gesammelt haben.
Mit AIMS 2013 steht ein einfaches Werkzeug zum Messen der benötigten Zeit für die Erstellung der Karte zur Verfügung (siehe für eine Beschreibung hier und hier).
Am Beispiel einer einfachen Berechnung (siehe hier) habe ich die zwei Varianten "View" und "TB_SQL" miteinander verglichen:
| Tabelle (TB_SQL) | View | |||||||
| Layers | Images | Others | Gesamt | Layers | Images | Others | Gesamt | |
| 1 | 20.84 | 81.35 | 4.56 | 106.75 | 16.95 | 81.64 | 4.54 | 103.13 |
| 2 | 15.35 | 81.31 | 4.55 | 101.21 | 17.3 | 82.82 | 4.41 | 104.53 |
| 3 | 14.53 | 82.07 | 4.45 | 101.05 | 18.76 | 81.66 | 4.35 | 104.77 |
| 4 | 19.74 | 80.59 | 4.32 | 104.65 | 14.58 | 81.26 | 4.19 | 100.03 |
| 5 | 11.21 | 80.61 | 4.56 | 96.38 | 13.12 | 80.97 | 4.82 | 98.91 |
| 6 | 14.75 | 81.05 | 4.15 | 99.95 | 17.86 | 81.84 | 4.6 | 104.3 |
| 7 | 22.27 | 81.88 | 4.81 | 108.96 | 17.64 | 81.9 | 4.38 | 103.92 |
| 8 | 17.5 | 81.09 | 4.23 | 102.82 | 16.9 | 82.4 | 4.49 | 103.79 |
| 9 | 23.56 | 80.39 | 4.48 | 108.43 | 16.83 | 81.53 | 4.61 | 102.97 |
| 10 | 10.46 | 80.98 | 4.34 | 95.78 | 13.6 | 82.7 | 4.39 | 100.69 |
| Mittelwert | 17.021 | 81.132 | 4.445 | 102.598 | 16.354 | 81.872 | 4.478 | 102.704 |
Die Tabelle gibt die Werte aus dem AIMS Performance Bericht wieder. Jeweils 10 Abfragen mit unterschiedlichen Kartenausschnitten bei einem Massstab von 1:10000. Die Karte enthält jeweils nur den Layer basierent auf dem View bzw. auf der Tabelle mit TB_SQL in der Layerdefinition. Darstellung und Massstabsbereiche sind gleich definiert.
Ergebnis: Die Unterschiede sind - schaut auf den Mittelwert für die Gesamtdauer - hier minimal. Für komplexere Abfragen muss man die Performance nochmal anschauen. Es wäre interessant zu erfahren, welche Erfahrungen andere Anwender bisher gesammelt haben.
Verwendung von TB_SQL
Im Beitrag gestern hatte ich erwähnt, dass es bei der Auswertung von Datumsangaben innerhalb von "Ausdrücken" ein Problem gibt.
Mit Map ist man recht flexible und hat so den Vorteil, dass man oft auf unterschiedlichen Wegen zum gleichen Ergebnis gelangen kann. Um das Problem bei der Datumsauswertung zu umgehen hatte ich einen View angelegt, der die erforderlichen Berechnungen vornimmt. Ein Vorteil ist hier, dass ich mehrere Layer haben - im Augenblick 6 - die diesen View nutzen. Muss ich die Datumsberechnung ändern, dann lässt sich das einfacher in einem View vornehmen als in 6 unterschiedlichen Layern.
Der Datumsauswertung im View sieht ungefähr so aus:
...
t2t_fid,
CASE
WHEN erfassungsdatum BETWEEN to_date('31.08.2007','DD.MM.YYYY') AND to_date('31.08.2008','DD.MM.YYYY')
THEN 2007
...
ELSE NULL
END ER_DATUM_JAHR
Für die thematische Darstellung wird nun die neue Spalte "ER_DATUM_JAHR" ausgewertet, die die Jahresangabe enthält.
Man kann die Problematik aber auch ohne View lösen - allein mit Konfiguration im Layer. Dazu erstellt man eine Berechnung und verwendet dann die Funktion "TB_SQL". Über TB_SQL können die Daten aus der Tabelle während der Abfrage modifiziert werden. Die Datumsauswertung erfolgt dabei mit der gleichen Syntax wie die Auswertung im View. Die einzelnen Schritte:
1. Funktion "Berechnung erstellen" im Kontextmenü des Layers auswählen
2. Namen für die neue Spalte vergeben
2. in das Eingabefeld: TB_SQL('') eingeben
3. Die gewünschte SQL Abfrage zwischen die Hochkomma setzen, z.B.:
TB_SQL(' select CASE
WHEN erfassungsdatum BETWEEN to_date(''31.08.2007'',''DD.MM.YYYY'') AND to_date(''31.08.2008'',''DD.MM.YYYY'')
THEN ''2007''
WHEN erfassungsdatum BETWEEN to_date(''31.08.2008'',''DD.MM.YYYY'') AND to_date(''31.08.2009'',''DD.MM.YYYY'')
THEN ''2008''
WHEN erfassungsdatum BETWEEN to_date(''31.08.2009'',''DD.MM.YYYY'') AND to_date(''31.08.2010'',''DD.MM.YYYY'')
THEN ''2009''
WHEN erfassungsdatum BETWEEN to_date(''31.08.2010'',''DD.MM.YYYY'') AND to_date(''31.08.2011'',''DD.MM.YYYY'')
THEN ''2010''
WHEN erfassungsdatum BETWEEN to_date(''31.08.2011'',''DD.MM.YYYY'') AND to_date(''31.08.2012'',''DD.MM.YYYY'')
THEN ''2011''
WHEN erfassungsdatum BETWEEN to_date(''31.08.2012'',''DD.MM.YYYY'') AND to_date(''31.08.2013'',''DD.MM.YYYY'')
THEN ''2012''
WHEN erfassungsdatum BETWEEN to_date(''31.08.2013'',''DD.MM.YYYY'') AND to_date(''31.08.2014'',''DD.MM.YYYY'')
THEN ''2013''
WHEN erfassungsdatum BETWEEN to_date(''31.08.2014'',''DD.MM.YYYY'') AND to_date(''31.08.2015'',''DD.MM.YYYY'')
THEN ''2014''
WHEN erfassungsdatum BETWEEN to_date(''31.08.2015'',''DD.MM.YYYY'') AND to_date(''31.08.2016'',''DD.MM.YYYY'')
THEN ''2015''
WHEN erfassungsdatum BETWEEN to_date(''31.08.2016'',''DD.MM.YYYY'') AND to_date(''31.08.2017'',''DD.MM.YYYY'')
THEN ''2016''
ELSE NULL
END ER_DATUM_JAHR from WPO_V_EB_STANDORT where fid = g.fid' )
Hinweise:
- das Ergebnis der Abfrage darf nur eine Spalte zurückliefern (im Beispiel wird nur das Erfassungsdatum ausgewertet)
- das Ergebnis der Abfrage darf nur eine Zeile zurückliefern (im Beispiel über WHERE Bedingung gewährleistet: where fid = g.fid)
- das Ergebnis der Abfrage muss vom Datentyp "Text" sein (im Beispiel ist das Ergebnis (Jahreszahl) innerhalb von Hochkomma gesetzt und damit als Text definiert).
- das Hochkomma muss zweimal gesetzt werden falls es im SQL Ausdruck erforderlich ist (Maskierung: to_date(''31.08.2016'',''DD.MM.YYYY'') anstelle to_date('31.08.2007','DD.MM.YYYY') im View).
Um den Bezug zu der Datentabelle zu erstellen verwendet man immer den Alias "g". Im Beispiel wird keine weitere Tabelle abgefragt sondern nur eine Spalte der Tabelle ausgewertet. Man kann aber ohne weiteres auf andere Tabellen - z.B. Domaintabellen – zugreifen und so z.B. eine ID mit dem zugehörigen Wert ersetzen.
Die Berechnung sollte man vor dem Anwenden in die Zwischenablage kopieren. Enthält die Berechnung ein Fehler lässt sich anschliessend der Dialog zum Erstellen der Berechnung nicht mehr öffnen und man muss von vorne beginnen. Bei einem Fehler erhält man den Oracle Fehlercode und den gesamtem SQL Ausdruck zurück, den Map bei der Abfrage der Datenquelle verwendet, z.B.:
Speichern der Objekte im Cache fehlgeschlagen.
FDO-Befehl konnte nicht ausgeführt werden.
ORA-00913: Zu viele Werte 'SELECT g.GEOM.SDO_POINT.X, g.GEOM.SDO....
Die Map Hilfe enthält noch weitere Hinweise und Beispiele.
Zu beachten ist: verwendet man TB_SQL im Layer dann ist man später auf den Topobase FDO Datenprovider festgelegt. Man kann dann nicht mehr zum FDO Oracle Provider wechseln (z.B. für die Web-Auskunft). TB_SQL ist keine allgemeine FDO Funktion sondern spezifisch für den Topobase – Provider.
Im nächsten Beitrag werde ich kurz zu Performance-Auswirkungen schreiben.
Mit Map ist man recht flexible und hat so den Vorteil, dass man oft auf unterschiedlichen Wegen zum gleichen Ergebnis gelangen kann. Um das Problem bei der Datumsauswertung zu umgehen hatte ich einen View angelegt, der die erforderlichen Berechnungen vornimmt. Ein Vorteil ist hier, dass ich mehrere Layer haben - im Augenblick 6 - die diesen View nutzen. Muss ich die Datumsberechnung ändern, dann lässt sich das einfacher in einem View vornehmen als in 6 unterschiedlichen Layern.
Der Datumsauswertung im View sieht ungefähr so aus:
...
t2t_fid,
CASE
WHEN erfassungsdatum BETWEEN to_date('31.08.2007','DD.MM.YYYY') AND to_date('31.08.2008','DD.MM.YYYY')
THEN 2007
...
ELSE NULL
END ER_DATUM_JAHR
Für die thematische Darstellung wird nun die neue Spalte "ER_DATUM_JAHR" ausgewertet, die die Jahresangabe enthält.
Man kann die Problematik aber auch ohne View lösen - allein mit Konfiguration im Layer. Dazu erstellt man eine Berechnung und verwendet dann die Funktion "TB_SQL". Über TB_SQL können die Daten aus der Tabelle während der Abfrage modifiziert werden. Die Datumsauswertung erfolgt dabei mit der gleichen Syntax wie die Auswertung im View. Die einzelnen Schritte:
1. Funktion "Berechnung erstellen" im Kontextmenü des Layers auswählen
2. Namen für die neue Spalte vergeben
2. in das Eingabefeld: TB_SQL('') eingeben
3. Die gewünschte SQL Abfrage zwischen die Hochkomma setzen, z.B.:
TB_SQL(' select CASE
WHEN erfassungsdatum BETWEEN to_date(''31.08.2007'',''DD.MM.YYYY'') AND to_date(''31.08.2008'',''DD.MM.YYYY'')
THEN ''2007''
WHEN erfassungsdatum BETWEEN to_date(''31.08.2008'',''DD.MM.YYYY'') AND to_date(''31.08.2009'',''DD.MM.YYYY'')
THEN ''2008''
WHEN erfassungsdatum BETWEEN to_date(''31.08.2009'',''DD.MM.YYYY'') AND to_date(''31.08.2010'',''DD.MM.YYYY'')
THEN ''2009''
WHEN erfassungsdatum BETWEEN to_date(''31.08.2010'',''DD.MM.YYYY'') AND to_date(''31.08.2011'',''DD.MM.YYYY'')
THEN ''2010''
WHEN erfassungsdatum BETWEEN to_date(''31.08.2011'',''DD.MM.YYYY'') AND to_date(''31.08.2012'',''DD.MM.YYYY'')
THEN ''2011''
WHEN erfassungsdatum BETWEEN to_date(''31.08.2012'',''DD.MM.YYYY'') AND to_date(''31.08.2013'',''DD.MM.YYYY'')
THEN ''2012''
WHEN erfassungsdatum BETWEEN to_date(''31.08.2013'',''DD.MM.YYYY'') AND to_date(''31.08.2014'',''DD.MM.YYYY'')
THEN ''2013''
WHEN erfassungsdatum BETWEEN to_date(''31.08.2014'',''DD.MM.YYYY'') AND to_date(''31.08.2015'',''DD.MM.YYYY'')
THEN ''2014''
WHEN erfassungsdatum BETWEEN to_date(''31.08.2015'',''DD.MM.YYYY'') AND to_date(''31.08.2016'',''DD.MM.YYYY'')
THEN ''2015''
WHEN erfassungsdatum BETWEEN to_date(''31.08.2016'',''DD.MM.YYYY'') AND to_date(''31.08.2017'',''DD.MM.YYYY'')
THEN ''2016''
ELSE NULL
END ER_DATUM_JAHR from WPO_V_EB_STANDORT where fid = g.fid' )
Hinweise:
- das Ergebnis der Abfrage darf nur eine Spalte zurückliefern (im Beispiel wird nur das Erfassungsdatum ausgewertet)
- das Ergebnis der Abfrage darf nur eine Zeile zurückliefern (im Beispiel über WHERE Bedingung gewährleistet: where fid = g.fid)
- das Ergebnis der Abfrage muss vom Datentyp "Text" sein (im Beispiel ist das Ergebnis (Jahreszahl) innerhalb von Hochkomma gesetzt und damit als Text definiert).
- das Hochkomma muss zweimal gesetzt werden falls es im SQL Ausdruck erforderlich ist (Maskierung: to_date(''31.08.2016'',''DD.MM.YYYY'') anstelle to_date('31.08.2007','DD.MM.YYYY') im View).
Um den Bezug zu der Datentabelle zu erstellen verwendet man immer den Alias "g". Im Beispiel wird keine weitere Tabelle abgefragt sondern nur eine Spalte der Tabelle ausgewertet. Man kann aber ohne weiteres auf andere Tabellen - z.B. Domaintabellen – zugreifen und so z.B. eine ID mit dem zugehörigen Wert ersetzen.
Die Berechnung sollte man vor dem Anwenden in die Zwischenablage kopieren. Enthält die Berechnung ein Fehler lässt sich anschliessend der Dialog zum Erstellen der Berechnung nicht mehr öffnen und man muss von vorne beginnen. Bei einem Fehler erhält man den Oracle Fehlercode und den gesamtem SQL Ausdruck zurück, den Map bei der Abfrage der Datenquelle verwendet, z.B.:
Speichern der Objekte im Cache fehlgeschlagen.
FDO-Befehl konnte nicht ausgeführt werden.
ORA-00913: Zu viele Werte 'SELECT g.GEOM.SDO_POINT.X, g.GEOM.SDO....
Die Map Hilfe enthält noch weitere Hinweise und Beispiele.
Zu beachten ist: verwendet man TB_SQL im Layer dann ist man später auf den Topobase FDO Datenprovider festgelegt. Man kann dann nicht mehr zum FDO Oracle Provider wechseln (z.B. für die Web-Auskunft). TB_SQL ist keine allgemeine FDO Funktion sondern spezifisch für den Topobase – Provider.
Im nächsten Beitrag werde ich kurz zu Performance-Auswirkungen schreiben.
Monday, 11 November 2013
Darstellungsverwaltung - Problem bei Auswertung von Datumsangaben
Bei der Auswertung von Datumsangaben für die Darstellungsverwaltung scheint es ein Problem zu geben. Je nach Zoomstufe wird eine unterschiedliche Anzahl von Objekten in Map (und AIMS) angezeigt.
Das Problem scheint im Zusammenhng mit dem Datum bzw. der Auswertung des Datums zu stehen. Folgenden Ausdruck hatte ich verwendet:
ERFASSUNGSDATUM >= todate('31.08.2007', 'DD.MM.YYYY') and ERFASSUNGSDATUM <= todate('31.08.2008', 'DD.MM.YYYY')
"Erfassungsdatum" ist ein Datumsfeld in der Oracle-Tabelle. Die Auswertung des Datums wurde in den View verlegt. Autodesk ist über das Problem informiert.
Map 2013, SP2
 |
| Anzeige Objekte im Massstab rund 1:30000... |
 |
| Anzeige Objekte im Massstab rund 1:20000 - wesentlich mehr Objekte sind nun sichtbar. |
 |
| Ausdruck mit Datumsauswertung |
Das Problem scheint im Zusammenhng mit dem Datum bzw. der Auswertung des Datums zu stehen. Folgenden Ausdruck hatte ich verwendet:
ERFASSUNGSDATUM >= todate('31.08.2007', 'DD.MM.YYYY') and ERFASSUNGSDATUM <= todate('31.08.2008', 'DD.MM.YYYY')
"Erfassungsdatum" ist ein Datumsfeld in der Oracle-Tabelle. Die Auswertung des Datums wurde in den View verlegt. Autodesk ist über das Problem informiert.
Map 2013, SP2
Thursday, 7 November 2013
Checkbox - Wert '-1'
Bei den Feldern mit Checkbox im Formular wurde in TB2 der Wert '-1' für "Ja" vergeben (zumindest hier bei uns). In Map wird '-1' auch standardmässig mit 'J' bzw. mit 'Y' angezeigt - nur funktioniert der Filter im Formular dann nicht, wenn man nach 'J' bzw. 'Y' filtert. Die Werte in der Datenbank sollten also besser von -1 auf 1 aktualisiert werden.
Map 2013, SP2
Map 2013, SP2
Hilfreiche Tastenkombinationen für den Admin
Ich schreib ja den Blog auch, damit ich die Sachen für mich dokumentiert habe und schnell wieder finde. Jetzt stelle ich fest, dass ich die Formular-Shortcuts hier noch garnicht "dokumentiert" habe.
Bei einem geöffneten Forumular in Map:
(1) mit der Maus in die Zeile mit der Anzeige "Datensatz X von Y" klicken
(2) eine der folgenden Tastenkombinationen verwenden:
<STRG>+<R> öffnet Formular für TB_RELATIONS
<STRG>+<D> öffnet Formular für TB_GN_DIALOG
<STRG>+<C> öffnet Formular für TB_GN_CONTROL
<STRG>+<U> öffnet Formular für TB_GN_DIALOG_USER
<STRG>+<F> öffnet Formulardesigner
<STRG>+<N> zeigt die Datenbanknamen der Attribute sowie den Datentyp für die im aktuellen Formular vorhandenen Attribute (Tastenkombination gedrückt halten)
Voraussetzungen - Aktueller Map benutzer muss die Admin Bertechtigung in Map haben.
Map 2013, SP2
Bei einem geöffneten Forumular in Map:
(1) mit der Maus in die Zeile mit der Anzeige "Datensatz X von Y" klicken
 |
| mit Maus in die Zeile mit der Anzahl der Datensätze klicken |
<STRG>+<R> öffnet Formular für TB_RELATIONS
<STRG>+<D> öffnet Formular für TB_GN_DIALOG
<STRG>+<C> öffnet Formular für TB_GN_CONTROL
<STRG>+<U> öffnet Formular für TB_GN_DIALOG_USER
<STRG>+<F> öffnet Formulardesigner
<STRG>+<N> zeigt die Datenbanknamen der Attribute sowie den Datentyp für die im aktuellen Formular vorhandenen Attribute (Tastenkombination gedrückt halten)
Voraussetzungen - Aktueller Map benutzer muss die Admin Bertechtigung in Map haben.
Map 2013, SP2
Tuesday, 5 November 2013
In Fachschale konvertieren II
Für ein weiteres Projekt habe ich die Funktion "In Fachschale konvertieren" (siehe älteren Blog-Beitrag) verwendet und musste noch ein anderes Problem feststellen.
Mit einer Mapping-Datei will ich drei ESRI SHP Dateien jeweils in eine zugehörige Map-Tabelle übertragen. Die drei SHP Dateien werden zusammen geliefert und gehören inhaltlich auch zusammen.
Nach dem Erstellen der Mapping Datei hat der Import soweit funktioniert. Leider musste ich heute feststellen, dass beim erneuten Einladen der Mapping-Datei nur noch eine der SHP Datei auf die zugehörige Tabelle gemappt ist. Bei den anderen beiden SHP Dateien ist das Mapping "verloren" gegangen. Die Mapping Datei selbst ist vollständig - aber offenbar gibt es einen Bug in Map, der dazu führt, dass nur ein Eintrag aus der Mapping Datei ausgewertet wird.
Auf Rückfrage beim Autodesk Support wurde mir mitgeteilt, dass das Problem allerdings mit Map 2014 behoben sei.
Map 2013 SP 2.1
Mit einer Mapping-Datei will ich drei ESRI SHP Dateien jeweils in eine zugehörige Map-Tabelle übertragen. Die drei SHP Dateien werden zusammen geliefert und gehören inhaltlich auch zusammen.
Nach dem Erstellen der Mapping Datei hat der Import soweit funktioniert. Leider musste ich heute feststellen, dass beim erneuten Einladen der Mapping-Datei nur noch eine der SHP Datei auf die zugehörige Tabelle gemappt ist. Bei den anderen beiden SHP Dateien ist das Mapping "verloren" gegangen. Die Mapping Datei selbst ist vollständig - aber offenbar gibt es einen Bug in Map, der dazu führt, dass nur ein Eintrag aus der Mapping Datei ausgewertet wird.
Auf Rückfrage beim Autodesk Support wurde mir mitgeteilt, dass das Problem allerdings mit Map 2014 behoben sei.
Map 2013 SP 2.1
Tuesday, 29 October 2013
OracleImport - ORA-01400
Die TB2 Fachschale wurde mit Flatport migriert und konfiguriert. Anschliessend wird die Flatport-Migration in ein weiteres Schema erneut durchgeführt, um den OracleImport (Mapping) zu konfigurieren. Später werden die TB2 Daten in die vorbereitete Map-Fachschale via Flatport und OracleImport migirert.
Bisher hat das Einrichten des OracleImportes und der Import selbst immer funktioniert - bis gestern bei einer Tabelle während des Importes folgende Fehlermeldung ausgegeben wurde:
Fehler:ORA-01400: Einfügen von NULL in ("WT_TB"."WTB_KB_BAUWERK_TBL"."FID") nicht möglich
Die Meldung ist soweit nachvollziehbar - aber warum tritt das Problem plötzlich auf und warum bei einer Tabellen aber nicht bei den anderen Tabellen im Schema?
Die Erkläung ist einfach, leider habe ich doch einige Zeit und letztlich den Hinweis vom Kollegen benötigt - der zugehörige Trigger "WTB_KB_BAUWERK_TBL_FID" war deaktiviert. Warum dies passiert ist kann ich nicht sagen - manuell deaktiviert habe ich ihn nicht. Nach dem Aktivieren lief die Migration ohne weitere Meldungen durch.
Map 2013, SP2
Bisher hat das Einrichten des OracleImportes und der Import selbst immer funktioniert - bis gestern bei einer Tabelle während des Importes folgende Fehlermeldung ausgegeben wurde:
Fehler:ORA-01400: Einfügen von NULL in ("WT_TB"."WTB_KB_BAUWERK_TBL"."FID") nicht möglich
Die Meldung ist soweit nachvollziehbar - aber warum tritt das Problem plötzlich auf und warum bei einer Tabellen aber nicht bei den anderen Tabellen im Schema?
Die Erkläung ist einfach, leider habe ich doch einige Zeit und letztlich den Hinweis vom Kollegen benötigt - der zugehörige Trigger "WTB_KB_BAUWERK_TBL_FID" war deaktiviert. Warum dies passiert ist kann ich nicht sagen - manuell deaktiviert habe ich ihn nicht. Nach dem Aktivieren lief die Migration ohne weitere Meldungen durch.
Map 2013, SP2
Monday, 28 October 2013
Ungültiger View aus TB_Dictionary entfernt / Views per Script registrieren
Wenn man die in der 1-Klick-Wartung gefundenen Probleme beheben lässt und die Option "Fachschalen-Wörterbuch" aktiviert hat sollte man sich darauf einstellen, dass ein ungültiger View aus TB_DICTIONARY entfernt wird. In der Map Hilfe heisst es:
Wörterbuch - Korrigiert oder entfernt ungültige Einträge in TB_DICTIONARY.
Das war mir nicht bewusst. In diesem Zusammenhang noch der Hinweis - anstelle die Views (etwas umständlich) über den Map-Administrator manuell einzubinden kann man das auch per Script. Hier ein Beispiel für die Ausführung im SQL Developer:
--in der Fachschale ausführen, hier: wt_fm
declare n_ret number;
begin
n_ret:=MAPSYS.FeatureClass.CreateFeatureClass('FM_V_DSP_SW_TRASSEKNOTEN','FM_V_DSP_SW_TRASSEKNOTEN','Darstellung','P', '', 2, 0.00050, '352257', 'anyinteract', 1000000, 1000000, 10000, -10, -10, -10, 1, 1);
n_ret:=MAPSYS.FeatureClass.CreateFeatureClass('FM_V_DSP_SW_TRASSEKANTE','FM_V_DSP_SW_TRASSEKANTE','Darstellung','L', '', 2, 0.00050, '352257', 'anyinteract', 1000000, 1000000, 10000, -10, -10, -10, 1, 1);
end;
--separat ausführen:
commit;
Die einzelnen Parameter für CreateFeatureClass sind beschrieben in "Autodesk Topobase ServerSide API Help", Stand 2011. Eine neuere Dokumentation habe ich nicht gefunden. Hier der Auszug aus der CHM Datei (Topobase_ServerSide_API.chm).
FeatureClassFactory.createFeatureClass Methodcreate a feature class with all necessary attributes.
Java
public static AbstractFeatureClass createFeatureClass(
String featureClassName,
String caption,
String topicName,
String featureClassType,
int parent_f_class_id,
int dimensions,
double tolerance,
String srid,
String spatialMask,
double max_x,
double max_y,
double max_z,
double min_x,
double min_y,
double min_z,
int readOnly,
int objectExists
) throws SQLException, TopobaseException;
Parameters
Parameters Description
featureClassName - name of the new feature class
caption - caption of the new feature class
topicName - in which topic does the feature class is in
featureClassType - type of the new feature class [varchar2(1)] -> P - Point, L - Line, O - Polygon, A - Label, C - Collection, T - Attribute, R - Raster, E - Centroid, S - CompoundSurface, I - CompoundLineString, D - AutoCad Collection ,W - WMSMap, M - Dimension
parent_f_class_id - parent feature class of the new feature class
dimensions - spatial dimension of the new feature class
tolerance - spatial tolerance of the new feature class
srid - spatial reference ID of the new feature class
spatialMask - spatial query mask of the new feature class
max_x - max x value of the new feature class
max_y - max y value of the new feature class
max_z - max z value of the new feature class
min_x - min x value of the new feature class
min_y - min y value of the new feature class
min_z - min z value of the new feature class
readOnly - Feature class is read only
objectExists - Table/View already exists (register feature class only)
Returns
instance of an abstract feature class object
Remarks
See Also
FeatureClassFactory Class
FeatureClassFactory Members
topobase.feature Package
geändert am 13.11. - die GRANTS sollten nicht erforderlich sein, da die Ausführungsberechtigung bereits der Rolle 'public' zugewiesen wurde. Daher GRANT/REVOKE Verweis im Beispielscript entfernt.
Wörterbuch - Korrigiert oder entfernt ungültige Einträge in TB_DICTIONARY.
Das war mir nicht bewusst. In diesem Zusammenhang noch der Hinweis - anstelle die Views (etwas umständlich) über den Map-Administrator manuell einzubinden kann man das auch per Script. Hier ein Beispiel für die Ausführung im SQL Developer:
--in der Fachschale ausführen, hier: wt_fm
declare n_ret number;
begin
n_ret:=MAPSYS.FeatureClass.CreateFeatureClass('FM_V_DSP_SW_TRASSEKNOTEN','FM_V_DSP_SW_TRASSEKNOTEN','Darstellung','P', '', 2, 0.00050, '352257', 'anyinteract', 1000000, 1000000, 10000, -10, -10, -10, 1, 1);
n_ret:=MAPSYS.FeatureClass.CreateFeatureClass('FM_V_DSP_SW_TRASSEKANTE','FM_V_DSP_SW_TRASSEKANTE','Darstellung','L', '', 2, 0.00050, '352257', 'anyinteract', 1000000, 1000000, 10000, -10, -10, -10, 1, 1);
end;
--separat ausführen:
commit;
Die einzelnen Parameter für CreateFeatureClass sind beschrieben in "Autodesk Topobase ServerSide API Help", Stand 2011. Eine neuere Dokumentation habe ich nicht gefunden. Hier der Auszug aus der CHM Datei (Topobase_ServerSide_API.chm).
FeatureClassFactory.createFeatureClass Methodcreate a feature class with all necessary attributes.
Java
public static AbstractFeatureClass createFeatureClass(
String featureClassName,
String caption,
String topicName,
String featureClassType,
int parent_f_class_id,
int dimensions,
double tolerance,
String srid,
String spatialMask,
double max_x,
double max_y,
double max_z,
double min_x,
double min_y,
double min_z,
int readOnly,
int objectExists
) throws SQLException, TopobaseException;
Parameters
Parameters Description
featureClassName - name of the new feature class
caption - caption of the new feature class
topicName - in which topic does the feature class is in
featureClassType - type of the new feature class [varchar2(1)] -> P - Point, L - Line, O - Polygon, A - Label, C - Collection, T - Attribute, R - Raster, E - Centroid, S - CompoundSurface, I - CompoundLineString, D - AutoCad Collection ,W - WMSMap, M - Dimension
parent_f_class_id - parent feature class of the new feature class
dimensions - spatial dimension of the new feature class
tolerance - spatial tolerance of the new feature class
srid - spatial reference ID of the new feature class
spatialMask - spatial query mask of the new feature class
max_x - max x value of the new feature class
max_y - max y value of the new feature class
max_z - max z value of the new feature class
min_x - min x value of the new feature class
min_y - min y value of the new feature class
min_z - min z value of the new feature class
readOnly - Feature class is read only
objectExists - Table/View already exists (register feature class only)
Returns
instance of an abstract feature class object
Remarks
See Also
FeatureClassFactory Class
FeatureClassFactory Members
topobase.feature Package
geändert am 13.11. - die GRANTS sollten nicht erforderlich sein, da die Ausführungsberechtigung bereits der Rolle 'public' zugewiesen wurde. Daher GRANT/REVOKE Verweis im Beispielscript entfernt.
Thursday, 24 October 2013
Blog 'Beyond the Box'
Bei Autodesk gibt es noch einen Blog, der sich auch mit Map/AIMS/Topobase beschäftigt - "Beyond the Box". Der Blog vielleicht nicht so bekannt - hat aber gerade einen interessanten Artikel zum Thema AIMS Performance.
Wednesday, 16 October 2013
Publizieren nach AIMS - Tooltip
In Map kann man für einen Layer "QuickInfos" erstellen (Kontextmenü zum Layer > Quickinfos einrichten). Leider werden diese beim Publizieren nach AIMS nicht zu "Tooltips".
In AIMS muss man dann die Tooltipps nachträglich konfigurieren. Muss man später das Darstellungsmodell nochmal publizieren gehen die eingerichteten Tooltipps verloren.
Jetzt kann man bei der Erstellung der Darstellungsmodelle schon den Tooltip für AIMS mitkonfigurieren. In Map hat man davon leider nichts aber beim (erneuten) Publizieren nach AIMS sind die Tooltips dann schon vorhanden.
Dazu muss man in der Layer Datei unterhalb <VectorLayerDefinition> den Tooltip definieren. Dieser entspricht einem normalen Map/AIMS "Ausdruck" innerhalb des XML Tags <ToolTip></ToolTip>, z.B.
<ToolTip>Concat ( 'DP-Objekt Nr.: ', OBJEKT, Concat ( '\n', BEZEICHNUNG, CONCAT( '\n', SCHUTZMASSNAHME ) ))</ToolTip>
Lädt man das Darstellungsmodell in Map wird der <ToolTip> ignoriert. Speichert man das Darstellungsmodell bleibt der <ToolTip> erhalten (zumindest hat das bisher bei mir mit "Speichern" "Speichern unter" funktioniert).
Man hat zwar bei der Erstellung des Darstellunsgmodells einen etwas höheren Aufwand - erspart sich später aber das manuelle Einrichten der Tooltipps in AIMS.
Map 2013, SP2
In AIMS muss man dann die Tooltipps nachträglich konfigurieren. Muss man später das Darstellungsmodell nochmal publizieren gehen die eingerichteten Tooltipps verloren.
Jetzt kann man bei der Erstellung der Darstellungsmodelle schon den Tooltip für AIMS mitkonfigurieren. In Map hat man davon leider nichts aber beim (erneuten) Publizieren nach AIMS sind die Tooltips dann schon vorhanden.
Dazu muss man in der Layer Datei unterhalb <VectorLayerDefinition> den Tooltip definieren. Dieser entspricht einem normalen Map/AIMS "Ausdruck" innerhalb des XML Tags <ToolTip></ToolTip>, z.B.
<ToolTip>Concat ( 'DP-Objekt Nr.: ', OBJEKT, Concat ( '\n', BEZEICHNUNG, CONCAT( '\n', SCHUTZMASSNAHME ) ))</ToolTip>
 | |||||
| <ToolTip> Beispiel im Map-Layer |
 |
| Tooltip konfiguriert in AIMS/Studio |
Man hat zwar bei der Erstellung des Darstellunsgmodells einen etwas höheren Aufwand - erspart sich später aber das manuelle Einrichten der Tooltipps in AIMS.
Map 2013, SP2
Subscribe to:
Posts (Atom)