Tuesday, 28 May 2013

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

Monday, 27 May 2013

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

Wednesday, 22 May 2013

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.


Saturday, 18 May 2013

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.
 

Wednesday, 15 May 2013

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. 

Tuesday, 14 May 2013

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.