DWG export - lineweight missing

When exporting to CAD drawing (maptoacad, editable, with template) some polylines got the default lineweight of "0" although the Map display model assigns certain lineweights to them. In Map these lines displayed correctly. For the polylines affected the lineweight was set using an expression:

<Override>
 <SymbolName>LTYP20</SymbolName>
 <ParameterIdentifier>LINEWEIGHT</ParameterIdentifier>
 <ParameterValue>0.35 * 500</ParameterValue>
</Override>

To get the lineweight exported correctly one has to put the expression in brackets:

<Override>
 <SymbolName>LTYP20</SymbolName>
 <ParameterIdentifier>LINEWEIGHT</ParameterIdentifier>
 <ParameterValue>(0.35 * 500)</ParameterValue>
</Override>

Map 2103, Sp2

DWG Export - Linienstärke fehlt

In der exportierten DWG (_maptoacad, Bearbeitbar, mit Vorlage) hatten einige Linien die Linienstärke "0", obwohl im Darstellungsmodell ein anderer Wert eingestellt ist. In Map wird die Linienstärke auch korrekt dargestellt. Bei den betroffenen Linien war im Map-Layer die Linienstärke über einen Ausdruck festgelegt:

<Override>
 <SymbolName>LTYP20</SymbolName>
 <ParameterIdentifier>LINEWEIGHT</ParameterIdentifier>
 <ParameterValue>0.35 * 500</ParameterValue>
</Override>

Für den DWG Export lag die Lösung darin, den Ausdruck in Klammern zu setzen:

<Override>
 <SymbolName>LTYP20</SymbolName>
 <ParameterIdentifier>LINEWEIGHT</ParameterIdentifier>
 <ParameterValue>(0.35 * 500)</ParameterValue>
</Override>

Map 2103, Sp2

DWG-Export - hatch pattern missing

We used some hatch patterns in our display model which we loaded via StyleEditor from external files (xml, pat). We also made sure that corresponding AutoCAD hatches with the same name were available when conducting DWG export - but theses were always missing in the drawing file.

It turned out that the following tag in the layer is responsible:

<ExtendedData1>
 <FileName>S:\GIS\...\Vorlagen\HTypWAV_Wald2.xml</FileName>
</ExtendedData1>

It automatically gets created when you load a hatch from an external file. After removing the tag DWG export worked as expected. Same happens by the way with lines styles.

Map 2103, SP2

DWG Export - eigene Schraffuren fehlen

Im Darstellungsmodell wurden einige Schraffuren aus externen Dateien verwendet. Für den DWGExport standen die entsprechenden Schraffuren als AutoCAD Schraffuren zur Verfügung - trotzdem wurde keine dieser Schraffur in der DWG erzeugt.

Ursache ist der folgende Verweis in der Layerdatei - dieser entsteht, wenn das Schraffurmuster aus einer externen Datei geladen wird:

<ExtendedData1>
 <FileName>S:\GIS\...\Vorlagen\HTypWAV_Wald2.xml</FileName>
</ExtendedData1>

Entfernt man den Eintrag funktioniert der Schraffurexport auch mit eigenen Schraffurmustern.
Ähnliches gilt auch für Linientypen.

Map 2013, SP2

Display models - TB2 / Map / DWG-Export - progress report

We have invested quite some time in creating proper display models. We need to provide data to internal and external customers. With TB2 you can just save a drawing - with Map it gets more complicated...

Here is one example - "Leitungskataster Wasser". All styles are laid down in engineering standards which apply to the whole of Switzerland (similar standards exist in other countries as well).

data representation in TB2, Map, and Map-DWG Export

The screenshot shows:
- current representation of data in TB2 (plain CAD drawing we would pass on to customers)
- representation in Map (based on our new display model - FDO based)
- DWG as result of DWG-Export in Map and some additional tweaking

In Tb2 some features are drawn as CAD - multilines - something Map-DWG Export does not support. We have written a small tool which converts the exported polylines into multilines and applies the correct multilinestyle and scale as well.

Map 2013, SP2

Darstellungsmodelle - TB2 / Map / DWG-Export - Zwischenstand

Viel Zeit haben wir bisher in die Erstellung der Darstellungsmodelle investiert. Hier ein Bericht zum Zwischenstand - Beispiel Leitungskatasterplan Wasser, 1:250:

LK Wasser - TB2, Map, Map-DWG-Export

Im Screenshot sind zu sehen:
- die aktuelle Darstellung aus TB2 (links)
- die Darstellung in Map (Mitte)
- das Ergebnis des DWG Exportes mit Map (rechts - plus Nachbearbeitung)

Zum DWG Export - um wieder eine Multiliniendarstellung zu erhalten wie in TB2 wird die per _maptoacad (Optionen "Bearbeitbar", "mit Vorlage") - erstellte DWG nachberarbeitet. Dazu haben wir ein kleines Werkzeug geschrieben, dass aus den relevanten P-Linien wieder M-Linien erstellt, den richtigen Stil zuweist und skaliert. Alle dafür notwendigen Informationen sind bereits im Darstellungsmodell enthalten.

Map 2013, SP2

thematic rules, expressions and null values

The issue I described earlier today involves a bit more than I  thought initially. Here are results for some further tests I did - all related to thematic rules and how <null> values in treated in Map expressions. All tests were done using just one thematic rule which was applied to column "CREATION_CODE_XY_1":

value                    count
<null>                    1222
2                            1
8                         5016   


Test 1 rule: "NOT CREATION_CODE_XY_1 IN (8)"

result in Map:
features with <null> value in column are displayed but cannot be snapped to
(features with CREATION_CODE_XY_1 = 2 are displayed as well but you can snap to them).

result in Oracle:
select count(*) from wdp_dp_punktelement where creation_code_xy_1 not in (8);

COUNT(*)
--------
       1

conclusion:
- results in Map and Oracle are different
- object snap doesn't work on  features with <null> values

If you add a second rule without any expression, set the symbol color to "none" and move the rule to the bottom then snapping does work (but additionally the "hidden" symbol from the second rule is snapped to as well).

    
Test 2 - rule: "CREATION_CODE_XY_1 <> 8"

result in Map:
features with <null> value are not displayed
(features with CREATION_CODE_XY_1 = 2 are displayed  and symbols can be snapped).

result in Oracle:
select count(*) from wdp_dp_punktelement where creation_code_xy_1 <> 8;

COUNT(*)
--------
       1

conclusion:
- results in Map and Oracle are the same
- expression from Test 1 is not that different from expression in Test 2 but the results in Map are quit  different


Test 3a - rule: CREATION_CODE_XY_1  NULL   OR   NOT  CREATION_CODE_XY_1  IN ( 8 )

results in Map:
features with  <null>  values are displayed and can be snapped

results in Oracle:
select count(*) from wdp_dp_punktelement where creation_code_xy_1 is null or creation_code_xy_1 not in (8);

COUNT(*)
--------
    1223

conclusion:
- results in Map and Oracle are the same
 
Test 3b - rule : NOT  CREATION_CODE_XY_1  IN ( 8 ) OR  CREATION_CODE_XY_1  NULL

results in Map:
features with <null> value are displayed, features can be snapped

results in Oracle:
select count(*) from wdp_dp_punktelement where creation_code_xy_1 not in (8) or creation_code_xy_1 is null;

COUNT(*)
--------
    1223

conclusion:
- results in Map and Oracle are the same

Test 4a - rule: CREATION_CODE_XY_1   NULL   OR   CREATION_CODE_XY_1   <> 8

results in Map:
features with <null> value are displayed, features can be snapped

results in Oracle:
select count(*) from wdp_dp_punktelement where creation_code_xy_1 is null or creation_code_xy_1 <> 8;

COUNT(*)
--------
    1223

conclusion:
- results in Map and Oracle are the same
 
Test 4b - rule: CREATION_CODE_XY_1  <>8  OR  CREATION_CODE_XY_1  NULL
 
results in Map:
features with <null> value are not displayed

results in Oracle:
select count(*) from wdp_dp_punktelement where creation_code_xy_1 <> 8 or creation_code_xy_1 is null;
COUNT(*)
--------
    1223

conclusion:
- results in Map and Oracle are different, order of expression changes result in Map but does not change it in Oracle (in Test 3b change of order didn't change result either in Map or Oracle)

summary:
- special attention is required when working with <null> values, the person who creates display models is not necessarily a database expert and doesn't know about <null> peculiarities
- always consider <null> values and use special operators such as "is null" "is not null"
- verify your rules with a test data set
- order of expressions might change result in Map
- Map and Oracle deliver different results where you would expect the same outcome

Finally another example in this context: the following rules were applied and the last rule was meant to deal with an "empty" column (but which actually contains <null> values):

ID_SYMBOLART  =  15  AND  ID_FARBE  =  1
….
to_char(ID_SYMBOLART)  = '' AND ID_FARBE  =  1

It was not possible to snap to the symbols on this layer.

The last rule needs to be rectified to:
NOT ID_SYMBOLART NULL AND ID_FARBE = 1

Map 2013, SP2