Linienskalierung im Zusammenhang mit dem DWG Export I

Bis vor kurzem war ich der Meinung, dass der DWG Export (_maptoacad, "Bearbeitbar", "mit Vorlage") die Linienskalierung nicht korrekt exportiert und entsprechend das Problem an Autodesk gemeldet. Dort wurde es soweit bestätigt.

Durch Zufall haben wir aber herausgefunden, dass die Skalierung (AutoCAD Linientypfaktor) aber durchaus beim DWG Export beeinflussbar ist und korrekte Ergbnisse liefern kann.

Um das gewünschet Exportergebnis zu erzielen muss man aber in der Layer Datei einige Einträge vornehmen, für die es im Map Stil-Editor keine Einstellmöglichkeiten gibt.

Als Beispiel dient folgende AutoCAD Liniensignatur LTYP20:

*LTYP20,[LT20] LTYP20

A,.3,-0.10,.6,-0.085,.03,-0.085,.3

Die Liniensignatur wird im Stil-Editor eingeladen. Einstellungen dort sind auf "Meter" gesetzt.

In der Layer Datei sind nun folgende Angaben enthalten:

<Name>LTYP20</Name>

<Description>[LT20] LTYP20</Description>

<Graphics>

<Path>

<Geometry>M 0,0 L 3,0 M 4,0 L 10,0 M 10.85,0 L 11.15,0 M 12,0 L 15,0 </Geometry>

...

Die Signatur hat eine Länge von 15 Einheiten. Zum Aufbau des <Geometry> Tags siehe "Building Symbol Libraries with Autodesk MapGuide Enterprise" (2009).

Um in Map entsprechend ein Signaturabschnitt mit der Länge von 15m darzustellen gibt man bei Breite und Höhe "15" ein. Den "Wiederholungsfaktor" setzt man für diesen Linientyp ebenfalls auf "15" damit die Signatur sich ohne Lücke an die nächste anschliesst.

Im Layer sind nun folgende Werte abgespeichert:

<Repeat>15000</Repeat>

...

<Identifier>StyleEditorGenerated_ScaleX_0</Identifier>

<DefaultValue>1.0</DefaultValue>

...

<Override>

<ParameterIdentifier>StyleEditorGenerated_ScaleX_0</ParameterIdentifier>

<ParameterValue>1000</ParameterValue>

...

<SizeContext>MappingUnits</SizeContext>

Der <Repeat> Wert beträgt 15000, der Widerholungsfaktor im Stil-Editor 15. Soweit ich verstehe, sind die Angaben bei <Geometry> in Milimeter (siehe UnitsControl in UnitsControl in SymbolDefinition-1.1.0.xml). Entsprechend ist der Wert bei StyleEditorGenerated_ScaleX_0 zu verstehen.

Um die Darstellung der Linine auf einen Massstab von 1:250 auszurichten kann man in der Layer - Datei noch die Tags <ScaleX> und <ScaleY> hinzufügen:

...

 <ScaleX>250</ScaleX>

 <ScaleY>250</ScaleY>

</SymbolInstance>

Fügt man diese Einstellungen hinzu, ändert sich die Anzeige im Stil-Editor entsprechend. Für Breite/Höhe und Wiederholungsfaktor ist nun jeweils der Wert "3750" eingetragen. Aber die Darstellung in Map hat nicht den gwünschten Effekt. Die Linie erscheint nun als durchgezogen.

Ändert man die Werte bei <ScaleX><ScaleY> auf 0.250 ist die Darstellung in Map wie erwartet. Die Signatur ist 3.75m lang.

Beim DWG Export ist der Lininetypfaktor aber 0.003 und die Darstellung damit falsch.

Letztlich stimmt die Darstellung in Map und beim DWG-Export, wenn man folgende Werte verwendet:

<Repeat>15</Repeat>

...

<Override>

<SymbolName>LTYP20</SymbolName>

<ParameterIdentifier>StyleEditorGenerated_ScaleX_0</ParameterIdentifier>

<ParameterValue>1</ParameterValue>

</Override>

<Override>

<SymbolName>LTYP20</SymbolName>

<ParameterIdentifier>StyleEditorGenerated_ScaleY_0</ParameterIdentifier>

<ParameterValue>1</ParameterValue>

</Override>

ScaleX>250</ScaleX>

<ScaleY>250</ScaleY>

Wie man sieht, kann man eine bestimmte Darstellung in Map über unterschiedliche Einstellungen erzielen. Für den korrekten Export ist dagegen eine bestimmte Einstellung erforderlich.

Beim Export hat die Linien den Linientypfaktor 2.5. Der folgende Screenshot zeigt die FDO Linie (schwarz) mit der Polylinie aus dem Export (als XREF eingebunden):

Map 2013, SP1

Benutzer ohne Passwortabfrage einrichten

Beim Benutzer "Administrator" ist gemäss Vorgabe bei der Anmeldung kein Passwort erforderlich. Um andere Benutzer so einzurichten, dass keine Passworteingabe erforderlich ist, muss das Benutzerpasswort mit dem Benutzernamen identisch sein - allerdings in Grossbuchstaben. 

Beispiel:

Benutzername - Gast

Passwort - GAST

Visual Studio Express 2010 und Map/Topobase Forms

Für den Map Administrator 2012 hatte ich ein kleines Plugin für die übersichtlichere Anzeige von Benutzern, Gruppen und Projekten mit VSExpress C# 2010 geschrieben. Verwendet habe ich dabei unter anderem ein "TreeView" Steuerlement von Topobase.

 

Die Umstellung auf Map 2013 hat nicht funktioniert. Auch das Neu-Erstellen eines Projektes mit dem TreeView Steuerlement endete immer mit einer der folgenden Fehlermeldungen (je nachdem welche DLLs (*.IM.Genuine, IM.Map.ImageResources) man referenziert zusätzlich und ob man die DDLs aus dem Map\bin Ordner referenziert oder aus dem AIA\bin Ordner):

 

Could not load file or assembly 'Autodesk.Map.IM.ImageResources, Version=16.0.102.43, Culture=neutral, PublicKeyToken=null' or one of its dependencies. Das System kann die angegebene Datei nicht finden.

 

Could not load file or assembly 'Autodesk.Map.IM.ImageResources, Version=16.0.102.29, Culture=neutral, PublicKeyToken=null' or one of its dependencies. Das System kann die angegebene Datei nicht finden.

 

Could not load file or assembly 'Autodesk.Map.IM.Genuine, Version=16.0.36.2, Culture=neutral, PublicKeyToken=null' or one of its dependencies. Das System kann die angegebene Datei nicht finden.

 

Verwirrend ist, dass die Versionen bei einigen der verwendeten DLLs im Map und im AIA Bin Ordner unterschiedlich sind - obwohl SP1 bei beiden installiert ist. Andere Topobase/Map Steuerlemente lassen sich dagegen ohne weiteres verwenden. Nur beim TreeView gab es das Problem.

 

Bei Autodesk konnte das Problem letztlich nachvollzogen werden. Die Vermutung ist, dass es mit der VSExpress Version zu  tun haben könnte. Da es mit VSExpress 2012 nicht auftritt war die Empfehlung, die aktuelle Version zu installieren.

 

Also habe ich VSExpress 2012 installiert. Während die Installation noch durchlief (zumindest war aber schon .net 4.5 fertig installiert) habe ich mein Projekt in VSExpress 2010 nochmal geöffnet. Und plötzlich liess sich in dem Projekt - ohne weitere Einstellungen - das TreeView Control hinzufügen. Da ich in den letzten Tagen keine weiteren Installationen oder andere Änderungen am PC durchgeführt habe (zumindest kann ich micht nicht erinnern) - scheint die plötzliche Änderung mit der Installation von VSStudio Express 2012 oder dem .net Framework 4.5 im Zusammenhang zu stehen.

 

VSExpress 2012 ist zwar nun installiert - starten kann ich es trotzdem nicht. Es gibt kein Programmsymbol auf dem Desktop oder einen Eintrag unter "Programme". In der Systemsteuerung ist es unter "Software" aber aufgeführt und lässt sich deinstallieren/reparieren. Egal, es funktioniert ja nun auch mit VSExpress 2010.

DWG Export - Linientyp XYZ nicht in Vorlage gefunden

Beim DWG Export erscheint die Meldung, dass bestimmte Linientypen in der Vorlage nicht gefunden wurden, obwohl diese dort vorhanden sind:

 

Befehl: _-MapToACAD Exportmethode [Bearbeitbar/Visuell]: _Editable Dateityp speichern [AutoCAD-2013-DWG/AutoCAD-2013-DXF/AutoCAD-2010-Drawing/AutoCAD-2010-DXF/AutoCAD-2007-Drawing/AutoCAD-2007-DXF/AutoCAD-2004-Drawing/AutoCAD-2004-DXF/AutoCAD-2000-Drawing/AutoCAD-2000-DXF]: _Dwg2013 Dateispeicherort: "C:\Temp\DWG_Export\wt_fm_mlinie.dwg" Die Datei C:\Temp\DWG_Export\wt_fm_mlinie.dwg ist bereits vorhanden. Sie wird überschrieben.

XDaten erstellen [Ja/Nein]: _No Speicherort der Vorlage (DWT): "C:\Temp\DWG_Export\PZ_WFM.dwt"

Linientyp AC_LType_GA_PIPE_2LINES nicht in Vorlage gefunden. Stattdessen wird VonLayer verwendet.

Linientyp AC_LType_WA_PIPE_AXE nicht in Vorlage gefunden. Stattdessen wird VonLayer verwendet.

 

Ursache könnte sein, dass der Linientyp ursprünglich als XML-Datei in den Stil-Editor eingelesen wurde. Dann speichert Map automatisch unter dem Tag <ExtendedData>einen Verweis auf die XML Datei im Layer ab:

 

<ExtendedData1>

<FileName>S:\GIS\TOPOPAR\PZ_MAP2013\WA_CH_DE_Wasser\LTypeDefinitions\AC_LType_GA_PIPE_2LINES.xml</FileName>

</ExtendedData1>

 

Löscht man den Verweis auf den Dateinamen aus der Layerdatei, funktioniert der Export wie erwartet.

Map 2013, SP1.

 

Migration - extrem lange Durchlaufzeit

Bei der Testmigration der TB2 Strom Daten lief der OracleImport über das Wochenende, ohne dass sich in der Fortschrittsanzeige im AIA etwas geändert hätte:

Der Import wurde dann abgebrochen und mit dem Oracle Admin der Zustand der Datenbank untersucht. Dort gab es allerdings keine Auffälligkeiten. Auch beim zweiten Migrationsversuch wurde nach 24h abgebrochen, nachdem es keinen sichtbaren Fortschritt gab und die Migration an gleicher Stelle scheinbar "steckenblieb". Tatsächlich war die Session in Oracle aber noch aktiv und ein SQL Statement wurde - länger als 22h - ausgeführt. 

Die problematische SQL Abfrage, die so lange lief, liess sich identifizieren. Offen blieb, warum diese Abfrage so extrem lange läuft. Gemäss Autodesk Consulting lief die Testmigration dort mit den gleichen Daten innerhalb einer Stunde durch. Wie kommt dieser extreme Unterschied zu Stande?

Nach einiger Suche und Recherche haben wir dann den Oracle Parameter "optimizer_mode" von der Einstellung "first_row" auf "all_row" gesetzt. Die Migration ist dann beim erneuten Start über die problematischen Punkt hinaus - auch innerhalb akzeptabler Zeit. Diese Einstellung ist also für den Unterschied in der Ausführungszeit wohl die Hauptursache. Insgesamt lief die Strom Migration immer noch deutlich länger als bei ADSK Consulting.

Der Standard-Wert für "optimizer_mode" ist bei Oracle 11.2 "all_rows". Bei der von uns verwendeten Instanz war der Wert aber auf  "first_row" gesetzt. Diese Einstellung war im Zusammenhang mit TB2 bei uns erforderlich und wurde beim Anlegen der neuen Instanz (für Map) übernommen - mit den entsprechenden Konsequenzen.

Durch die Änderung der Einstellung hat sich auch das Problem bei der Abwasser-Fachschale gelöst. 

Views und Formulare

Diese Verhalten ist - soweit mir bekannt - nicht in der Hilfe dokumentiert . Soweit die FID und GEOM aus einer Tabelle stammen wird automatisch das Formular dieser Tabelle geöffnet, nicht das Formular des Views. Ein Eintrag in TB_GN_INFO_REDIRECT ist zur Umleitung dann nicht erforderlich.

TB2 Migrationswerkzeuge für Map 2013 - Fehler mit Datumsangaben

Die Migrationswerkzeuge für Map 2013 hatten anfänglich noch einige Fehler, die aber bei der Migration schnell aufgefallen sind und inzwischen von Autodesk behoben wurden. Ein Fehler blieb beim Flatport/TB2 Import bisher unbemerkt - die Datumsangaben werden falsch migriert. Die Werte für Tag und Monat sind vertauscht. Wenn der Tag grösser als 12 ist und als Monatsangabe falsch wäre wird kein Datum migriert. Das Problem wurde an Autodesk weitergegeben und heute auch schon behoben. Mit den Werkzeugen für Map 2012 sind diese Probleme nicht aufgetreten.

 

Beispiel:

mit 2012 migriert:

select tb2_fid, fid, date_inquiry from wa_damage where tb2_fid=2263

   TB2_FID        FID DATE_INQUIRY

---------- ---------- ------------

      2263     266734 21.07.06    

 

select tb2_fid, fid, date_inquiry from wa_damage where tb2_fid=529

   TB2_FID        FID DATE_INQUIRY

---------- ---------- ------------

       529     267218 10.12.95    

 

mit 2013 migriert

select tb2_fid, fid, date_inquiry from wa_damage where tb2_fid=2263

   TB2_FID        FID DATE_INQUIRY

 

---------- ---------- ------------

      2263     267429  

select tb2_fid, fid, date_inquiry from wa_damage where tb2_fid=529

   TB2_FID        FID DATE_INQUIRY

---------- ---------- ------------

       529     266734 12.10.95   

Wer die Werkezeuge unter 2013 schon einsetzt - besser die letzte verfügbare Version anfordern.

Langsame Abfrage in Oracle - was genau passiert da eigentlich?

Bei den testweise migrierten Abwasser Daten lassen sich die Haltungen nicht aktualisieren oder neue Haltungen erzeugen. Wird eine Haltung im Formular aktualisiert, "hängt" Map und muss über den TaskManager beendet werden.

Bei den anderen Featureklassen im Abwasser tritt dies nicht auf. Im Zusammenhang mit der Problematik stehen die Objektregeln zum Aktualisieren der Labels (RegenerateLabel_BD/BU/AD/AU/AI). Werden die Objektregeln ausgeschaltet, lassen sich die Datensätze ohne weiteres aktualisieren oder neue Haltungen erfassen.

Da der Autodesk Support mit unserem Datendump das Problem nicht nachvollziehen konnte, bleibt nichts anderes, als die Ursache selber weiter einzugrenzen. Allerdings habe ich kaum Kenntnisse, wie man in Oracle die Ausführung von SQL Abfragen analysiert. Hier meine in diesem Zusammenhang gesammelten Erkenntnisse:

Zunächst habe ich geschaut, ob eine Abfrage besonders lange dauert. Die dafür verwendete SQL Abfrage sieht so aus:

select

s.username,

s.sid,

s.serial#,

s.last_call_et/60 mins_running,

q.sql_text from v$session s

join v$sqltext_with_newlines q

on s.sql_address = q.address

where status='ACTIVE'

and type <>'BACKGROUND'

and last_call_et> 60

order by sid,serial#,q.piece

Als Ergebnis sollte man die SQL Abfragen erhalten, die länger als 60 sec. dauern. Zumindest war das meine Erwartung. Da mir vertiefte Kenntnisse in dem Bereich fehlen, habe ich im Internet nach entsprechenden SQL Statements gesucht – und anschliessend nicht weiter im Detail geschaut, wie das Ergebnis zu interpretieren ist. Denn anhand der Abfrage konnte ich sehen, dass folgende SQL Anweisung länger als 60 min läuft:

WITH CONNECTION AS ( SELECT * FROM WW_CONN C WHERE (C.FID_FROM IN (SELECT FID FROM WW_LINE WHERE FID_ATTR=:B1 ) AND C.F_CLASS_ID_FROM =22) OR (C.FID_TO IN (SELECT FID FROM WW_LINE WHERE FID_ATTR=:B1 ) AND C.F_CLASS_ID_TO =22) ) SELECT MIN(P.FID_ATTR) AS FID_FROM FROM CONNECTION C, WW_POINT P WHERE (P.FID = C.FID_FROM AND C.F_CLASS_ID_FROM = 32 AND C.FLOW = 1) OR (P.FID = C.FID_TO AND C.F_CLASS_ID_TO = 32 AND C.FLOW = 2)

Mit Map's SQLSpy liess sich auslesen, dass ":B1" der Feature-ID der Haltung entspricht, die aktualisiert werden soll.

Nimmt man die oben aufgeführte SQL Anweisung, ersetzt ":B1" mit einer Haltungs-Feature-ID und führt die Abfrage z.B. im SQLDeveloper aus, dann dauert die Ausführung weniger als 1 sec.

Wie entsteht nun der grosse Unterschied in der Ausführungszeit zwischen Map und SQLDeveloper? Zwei Erklärungsansätze vom Autodesk Support :

-         Drittapplikationen, die ev. die Objektregeln beeinflussen

-         Oracle Konfiguration

Drittapplikationen haben wir im Augenblick nicht im Einsatz. Die Oracle Konfiguration ist natürlich fast überall unterschiedlich – und damit eine potentielle Ursache. 

Als nächstes habe ich – dem Hinweis aus dem Oracle Forum folgend – die Ausführungspläne der beiden Statements angeschaut. Gibt es dort Unterschiede, die die unterschiedliche Laufzeit erklären?

Um den Ausführungsplan der Anweisungen zu erhalten benötigt man die SQL_ID. Diese kann man z.B. über folgende Anweisung erhalten:

SELECT sql_id, child_number

FROM v$sql

WHERE sql_text LIKE '%WITH CONNECTION%';

Den Ausführungsplan ruft man dann mit der ermittelten SQL_ID und der Child_Number auf, z.B.:

SELECT * FROM table(DBMS_XPLAN.DISPLAY_CURSOR(c7my737tshr9k,0));

Es hat sich jedoch gezeigt, dass die Ausführungspläne der SQL Anweisung aus Map und aus dem SQLDeveloper identisch sind.

Der entscheidende Hinweis kam wieder vom Oracle Forum: über die folgende Abfrage erhält man zur Ausführung einer SQL Anweisung weitere Informationen:

select sql_id

     , PLAN_HASH_VALUE

     , CHILD_NUMBER

     , EXECUTIONS

     , ELAPSED_TIME/1000000

     , USER_IO_WAIT_TIME

     , CONCURRENCY_WAIT_TIME

     , DISK_READS

     , BUFFER_GETS

     , ROWS_PROCESSED

  from v$sql

 where sql_id = c7my737tshr9k;

Bei dieser Abfrage sieht man, wie oft die SQL Anweisung ausgeführt wurde. Bei der Anweisung aus Map liegt die Zahl bei über 6000. Das Problem ist also nicht – wie ursprünglich gedacht – die unterschiedliche Ausführungszeit der fraglichen SQL Anweisung sondern der Umstand, dass die Anweisung bei aktivierten Objektregeln extrem häufig hintereinander ausgeführt wird. Die Ursache dafür ist im Augenblick noch unklar.

Die erste von mir verwendete SQL Abfrage zeigt Angaben bezogen auf die Session.

Dadurch entgeht die Information, dass die SQL Anweisung mehrfach ausgeführt wird – was zu dem falschen Rückschluss führte, das die SQL Anweisung extrem lange benötigt.

Aus dem Beispiel wurde mir deutlich, dass man nicht ohne weiteres SQL Abfragen aus dem Internet verwenden sollte, nur weil sie "zu passen" scheinen. Zudem sind "plausible" erscheinende Ergebnisse manchmal eben auch irreführend. Die andere Seite der Medaille ist natürlich, dass man ja irgendwann mal vor einem solchen Problem steht und sich damit beschäftigen muss.

Am Ende sei noch erwähnt, dass Map's SQLSpy schon in die richtige Richtung gezeigt hat. Lässt man den SQLSpy mitlaufen wenn die Haltung aktualisiert wird, dann erscheint die fragliche SQL Abfrage permanent neu in der Liste – hier wird also deutlich, dass die Abfrage immer wieder in Oracle ausgeführt wird. Ich hatte dem aber keine Bedeutung geschenkt – da ich zum SQLSpy keine Dokumentation gefunden habe, bleibt bei der Interpretation der Ergebnisse auch nur Raten übrig. Hier hatte ich dann nicht richtig geraten sondern gedacht, der SQLSpy erzeugt unsinnige Ergebnisse.

Jetzt gilt es "nur noch" herauszufinden, warum die Anweisung bei aktivierten Objektregeln bei uns so häufig ausgeführt wird.