Weil wir einige Performanceprobleme mit der Fachschale AW hatten habe ich u.a. mit SQL Spy mal beobachtet, welche Abfragen ablaufen. Dabei ist mir eine Abfrage aufgefallen, deren Syntax ich nicht kannte:
WITH CONNECTION AS ...
Zufällig habe ich einen passenden Blog-Beitrag zu diesem Thema gefunden:
http://sql-plsql-de.blogspot.ch/2013/09/plsql-code-in-einer-sql-abfrage-ja.html
http://sql-plsql-de.blogspot.co.uk/2008/12/subuqery-oder-inline-view-die-sql-with.html
About things that happened to me at work.
Monday, 9 September 2013
Map-Benutzername DB-seitig (Oracle) ermitteln
Um den aktuellen Map-Benutzernamen oder -ID über einen Trigger zu loggen, z.B. um die Bearbeitung eines Datensatzes zuordnen zu können, lässt sich folgende SQL Abfrage verwenden:
user_name := job3.gettbuser();
bzw.:
SELECT USER_MGMT.GETVALUE('LOGIN_ID')into user_id FROM dual;
Der Aufruf von Job3 funktioniert unabhängig davon, ob das Dokument job-aktiv ist oder nicht.
Map 2013, SP2.
user_name := job3.gettbuser();
bzw.:
SELECT USER_MGMT.GETVALUE('LOGIN_ID')into user_id FROM dual;
Der Aufruf von Job3 funktioniert unabhängig davon, ob das Dokument job-aktiv ist oder nicht.
Map 2013, SP2.
Thursday, 29 August 2013
Abwasser - Globales Akutalisieren oder Blättern im Formular langsam?
Wir mussten feststellen, dass das Blättern vom einem Datensatz zum nächsten in der Haltungsmaske bis zu 5 sec dauert. Auch ein Globales Update bei den Schächten für rund 140 Datensätze dauerte mehr als 30 Minuten. Wir arbeiten bei der Fachschale nicht mit Jobs - bei Job-aktiven Dokumenten soll der Effekt noch schlimmer sein.
Schuld ist offenbar eine im CK WW (CH?) 2013 überarbeitete Funktion namens "GetPoint". Das Problem ist bei Autodesk inzwischen bekannt. Wir haben eine korrigierte Version der Funktion erhalten, die das Problem löst.
Ob dies auch mit der Ursache war für die schon vorher aufgefundenen Performanceprobleme in der AW Fachschale wird sich zeigen.
Map 2013, SP2.
Schuld ist offenbar eine im CK WW (CH?) 2013 überarbeitete Funktion namens "GetPoint". Das Problem ist bei Autodesk inzwischen bekannt. Wir haben eine korrigierte Version der Funktion erhalten, die das Problem löst.
Ob dies auch mit der Ursache war für die schon vorher aufgefundenen Performanceprobleme in der AW Fachschale wird sich zeigen.
Map 2013, SP2.
Thursday, 15 August 2013
Linienende immer zeichnen - Problem beim DWG-Export
Linienenden werden bei Map nicht zwangsläufig mit einer Strichsignantur beendet - im Gegensatz zu AutoCAD Linien. Ein - recht umständlicher - "Trick" um das von AutoCAD gewohnte Verhalten auch in Map nachzubilden ist im Geospatialnavigator-Blog beschrieben.
Leider gibt es dann beim DWG Export den unangenehmen Effekt, dass das als Linienende gedachte "Endstück" zusätzlich als separate Linie vollständig exportiert wird.
Es ist nicht verständlich, warum die Map Darstellung nicht ohne weiteres vorsieht, dass ein Linienende immer mit einer sichtbaren Signatur enden kann. Das man umständlich einen solchen "Trick" anwenden muss, der dann weitere Nachteile nach sich zieht ist dann mehr als unbefriedigend.
DWG-Export mit Vorlage - Linientyp nicht in Vorlage gefunden.
Beim DWG-Export mit Vorlage kannn es zu folgender Meldung kommen:
Linientyp XYZ nicht in Vorlage gefunden. Stattdessen wird VonLayer verwendet.
obwohl der fragliche Linientyp in der DWT Vorlage enthalten ist.
Ursache ist, dass im Darstellungsmodell eine Referenz auf die importierte Liniendefinition enthalten ist. Dieser Verweis sieht in der Regel so aus:
<ExtendedData1>
<FileName>S:\GIS\MAPKonfig\
</ExtendedData1>
Importiert man einen Linienstil - wie im Beispiel aus einer XML Datei - wird der Pfad auf die importierte Datei mit in der Layerdefinition gespeichert. Dann kann aber das Problem beim Export entstehen - unabhängig davon, ob der Pfad zu der Datei noch gültig ist oder nicht.
Löscht man den Pfad bzw. den gesamten Eintrag aus der Layerdatei sollte der DWG Export ohne weiteres funtkionieren.
Thursday, 25 July 2013
Map 2014 - Absturz beim Bildaufbau
Testweise ist Map 2014 (ohne HF1) installiert. Da es ein Problem bei den FDO Providern gab habe ich auch die "providers.xml" gemäss dem KB Eintrag aktualisiert (http://usa.autodesk.com/getdoc/id=TS21699992).
Anschliessend kam es beim Bildaufbau immer zum Absturz.
Schaut man in die zum "Crash Report" gehörende "dumpuserinfo.xml" ist dort unter anderem folgendes vermerkt:
<MethodToBlame>Autodesk.Map.IM.Display.GraphicsGeneration.FeatureSourceManager.FillFdoProvidersDictionary()</MethodToBlame>
In der Applicationlog.xml fanden sich auch einige ähnliche Einträge:
System.ArgumentException: An item with the same key has already been added.
at System.Collections.Generic.Dictionary`2.Insert(TKey key, TValue value, Boolean add)
at Autodesk.Map.IM.Display.GraphicsGeneration.FeatureSourceManager.FillFdoProvidersDictionary()
Schaut man sich die "providers.xml" aus dem KB Eintrag an, sieht man, dass es dort für SHP und SDF zwei Einträge gibt die sich im Namen aber nicht in der Version unterscheiden:
<Name>OSGeo.SHP.3.8</Name>
<Name>OSGeo.SHP.3.7</Name>
beide aber:
<Version>3.8.0.0</Version>
Mit einer "providers.xml" ohne diese doppelten Einträge funtkioniert auch wieder der Bildaufbau.
Anschliessend kam es beim Bildaufbau immer zum Absturz.
Schaut man in die zum "Crash Report" gehörende "dumpuserinfo.xml" ist dort unter anderem folgendes vermerkt:
<MethodToBlame>Autodesk.Map.IM.Display.GraphicsGeneration.FeatureSourceManager.FillFdoProvidersDictionary()</MethodToBlame>
In der Applicationlog.xml fanden sich auch einige ähnliche Einträge:
System.ArgumentException: An item with the same key has already been added.
at System.Collections.Generic.Dictionary`2.Insert(TKey key, TValue value, Boolean add)
at Autodesk.Map.IM.Display.GraphicsGeneration.FeatureSourceManager.FillFdoProvidersDictionary()
Schaut man sich die "providers.xml" aus dem KB Eintrag an, sieht man, dass es dort für SHP und SDF zwei Einträge gibt die sich im Namen aber nicht in der Version unterscheiden:
<Name>OSGeo.SHP.3.8</Name>
<Name>OSGeo.SHP.3.7</Name>
beide aber:
<Version>3.8.0.0</Version>
Mit einer "providers.xml" ohne diese doppelten Einträge funtkioniert auch wieder der Bildaufbau.
Thursday, 11 July 2013
Textgrösse bei Labels
Die in den Map-Layern festgelegte Texthöhe führt zu anderen
Textgrössen als bei AutoCAD Texten. Im Beispiel wird "Arial" verwendet
und die Grösse "1" zugewiesen. Der Unterschied in der tatsächlichen
Textgrösse zwischen dem Map-Layer und dem AutoCAD Text
beträgt im Beispiel rund 1/3. Die Zahl "6"(siehe Screenshot) ist im AutoCAD
M-Text genau 1 Meter hoch, der Map Text dagegen nur rund 0.71 Meter.
Abbildung: Map Text in grün, AutoCAD MText in schwarz
Diese deutliche Differenz ergibt sich aus der unterschiedlichen
Betrachtungsweise von "Texthöhe" die AutoCAD und
Map-Darstellungsverwaltung haben. Wie genau die jeweilige
Betrachtungsweise ist weiss ich nicht - bei AutoCAD wird wohl auf die
"cap height",
also auf die Grossbuchstaben abgestellt, bei Map werden
dagegen auch noch weitere Parameter wie Ascender, Descender etc.
berücksichtigt (siehe zu den typographischen Feinheiten z.B.: Wikipedia).
Jedenfalls braucht man oft eine Textdarstellung in einer bestimmten Grösse. Um mit Map den Text tatsächlich in der gewünschten Grösse darzustellen muss der im Stil-Editor eingegebene Wert angepasst werden. Dafür ist - abhängig von der verwendeten Font-Familie - ein entsprechender Anpassungsfaktor erforderlich.
Vom Autodesk Support kam die Angabe des Faktors für einige ausgewählte Fonts:
Cadastra - 1.37
Arial - 1.3969
Courier New - 1.7504
Die Faktoren gelten bei der Verwendung von "Karteneinheiten". Um also einen Arial Text mit einer Schriftgrösse von 1 Meter in der Zeichnung zu erzeugen ist der Faktor 1.39 anzuwenden:
Abbildung: Map Text in grün, AutoCAD MText in schwarz
Leider konnte die eigentliche Formel zum Errechnen des Faktors nicht zur Verfügung gestellt werden. Ich habe nach etwas Recherche aber auch keine Formel finden bzw. selber herleiten können. Aber man kann sich scheinbar mit einer einfachen aber nicht genauen Faustformel behelfen:
Faktor = 1 / gemessene Höhe
Dazu setzt man die Textgrösse im Stil-Editor auf "1 m" und misst über den Befehl ABSTAND die tatsächliche Textgrösse in der Zeichnung.
Beispiel - Font "Old English Text MT"
Textgrösse: 1 m, tatsächliche Texthöhe (gemessen an Zahl "5") : 0.676 - Faktor = 1.479
Ob das für alle Fonts gleichermassen taugt kann ich im Augenblick auch noch nicht sagen. Ich bin immer noch auf der Suche nach der genauen Umrechnungsformel....
Jedenfalls braucht man oft eine Textdarstellung in einer bestimmten Grösse. Um mit Map den Text tatsächlich in der gewünschten Grösse darzustellen muss der im Stil-Editor eingegebene Wert angepasst werden. Dafür ist - abhängig von der verwendeten Font-Familie - ein entsprechender Anpassungsfaktor erforderlich.
Vom Autodesk Support kam die Angabe des Faktors für einige ausgewählte Fonts:
Cadastra - 1.37
Arial - 1.3969
Courier New - 1.7504
Die Faktoren gelten bei der Verwendung von "Karteneinheiten". Um also einen Arial Text mit einer Schriftgrösse von 1 Meter in der Zeichnung zu erzeugen ist der Faktor 1.39 anzuwenden:
Leider konnte die eigentliche Formel zum Errechnen des Faktors nicht zur Verfügung gestellt werden. Ich habe nach etwas Recherche aber auch keine Formel finden bzw. selber herleiten können. Aber man kann sich scheinbar mit einer einfachen aber nicht genauen Faustformel behelfen:
Faktor = 1 / gemessene Höhe
Dazu setzt man die Textgrösse im Stil-Editor auf "1 m" und misst über den Befehl ABSTAND die tatsächliche Textgrösse in der Zeichnung.
Beispiel - Font "Old English Text MT"
Textgrösse: 1 m, tatsächliche Texthöhe (gemessen an Zahl "5") : 0.676 - Faktor = 1.479
Ob das für alle Fonts gleichermassen taugt kann ich im Augenblick auch noch nicht sagen. Ich bin immer noch auf der Suche nach der genauen Umrechnungsformel....
Subscribe to:
Posts (Atom)