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:

Relation mit Relationstyp

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".

Client-Objektregel "Delete" muss aktiv sein

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

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>

Hier die Gegenüberstellung - TB2 und Map (1:1000)

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>

....

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.

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

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:

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

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.

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.
==============================================

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. 

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

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:

	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.

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.

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

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

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

mit Maus in die Zeile mit der Anzahl der Datensätze 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

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