Creating the ArcGIS Workspace UML Model

Once the application schema has been pre-processed (as described here), it can be converted to an ArcGIS workspace model using the ShapeChange ArcGISWorkspace target. The following sections describe how the various application schema elements are converted into a model that complies with the ArcGIS workspace metamodel (which is used by the ArcGIS extension of Enterprise Architect).

Conversion of Model Elements

Package

Application schema packages are converted as described in the following table.

Application Schema Stereotype ArcGIS Model Element
<<Application Schema>>, <<applicationSchema>>, <<schema>> Package (with stereotype <<ArcGIS>>)
<<bundle>>, <<leaf>>, or no stereotype Package with no stereotype, except for the package that contains all feature classes – that package has the stereotype <<FeatureDataset>>.The package hierarchy is maintained, even though classes are split into separate package hierarchies according to their category (features, object classes / tables, and domains). The package hierarchy is not reflected in the geodatabase; it is only maintained for better readability of the ArcGIS UML model.

Class

Application schema classes are converted as described in the following table.

Application Schema Stereotype ArcGIS Model Element
<<featureType>> with no geometry property, and <<type>>  Class (with stereotype <<ObjectClass>>)
 <<featureType>> with one geometry property with value type GM_Point  Class (with stereotype <<Point>>)
  <<featureType>> with one geometry property with value type GM_MultiPoint  Class (with stereotype <<Multipoint)
  <<featureType>> with one geometry property with value type GM_Curve or GM_MultiCurve  Class (with stereotype <<Polyline>>)
  <<featureType>> with one geometry property with value type GM_Surface or GM_MultiSurface  Class (with stereotype <<Polygon>>)
  <<featureType>> with one geometry property with other value type  Not supported / will be ignored; schema must be pre-processed.
  <<featureType>> with multiple geometry properties  For the first geometry property, see above; all other geometry properties are ignored.
 <<dataType>> or <<union>> in the same application schema  Not supported / will be ignored; schema must be pre-processed.
 <<enumeration>> and <<codeList>>  Class (with stereotype <<CodedValueDomain>>)

NOTE: The default field type is esriFieldTypeString. This can be adjusted per enumeration / code list by setting the tagged value “fieldType” on that class to the desired field type (e.g. esriFieldTypeSmallInteger).

Property

Attribute

<<property>> elements within the application schema that are modelled as attributes are converted as described in the following table.

Application Schema Stereotype ArcGIS Model Element
<<property>>, maximum multiplicity > 1, except if value type is <<type>> or <<featureType>> Not supported / will be ignored; schema must be pre-processed.
<<property>>, value is of geometry type (name starts with „GM_“) Geometry properties are ignored; the stereotype of a feature class implies the geometry property and its type.
<<property>>, value type is <<enumeration>> or <<codeList>> Attribute (<<Field>>), value type is the coded value domain class.
<<property>>, value type is other type specified outside of the application schema Attribute (<<Field>>), type mapping as defined in the following table

NOTE: if the application schema contains a numeric range constraint for the property ShapeChange will create an according <<RangeDomain>> and set the type accordingly.

<<enum>> Attribute (<<DomainCodedValue>>)

Per default the initial value defined by the <<enum>> is used as initial value. Via the rule rule-arcgis-prop-initialValueByAlias this behavior can be changed to set the initial value using the alias of the <<enum>>.

<<property>>, value type is a non-abstract <<type>> or <<featureType>> in the application schema Association (<<RelationshipClass>>) to the corresponding class and <<field>> as described for one to many relationship here.

NOTE: relationship classes can only be linked to non-abstract classes, i.e. for such properties on abstract classes, the relationship class has to be defined on the non-abstract feature or object classes in all subtype branches of the abstract class.

 

Attributes with stereotype <<Field>> in the ArcGIS workspace model have a specific list of tagged values. The tagged values length, precision and scale are determined as follows:

FieldType TaggedValue name
 length  precision scale
 string  Following a length constraint defined for the attribute, or using a default value (currently 255; can be changed via a configuration parameter).  0  0
 integer  0  9  0
 double  0  10  6
 date  0  0  0
 coded or range domain  0  0  0

However, these characteristics can also be set on a case-by-case basis; see the documentation of the following conversion rules for further details:

Association

An association in the application schema is converted to an association with stereotype <<RelationshipClass>> as follows:

Mapping of ISO 19103 Types

The basic data types used in the application schema are mapped to ArcGIS basic data types as follows:

ISO 19103 Type Esri Type
CharacterString esriFieldTypeString
Integer esriFieldTypeInteger
Real esriFieldTypeDouble
Date, DateTime esriFieldTypeDate

Note: other types from ISO 19103, such as Measure and CI_Citation, can be mapped to the basic types listed in this table during pre-processing (see type flattening).

Mapping of Geometry Types

Feature classes in an ArcGIS workspace have a level of support for ISO 19107 geometry types similar to that of GML 2.1. The following table shows how ISO 19107 geometry types are realized:

ISO 19107 Type Realization in ArcGIS Workspace
GM_Point <<Point>> feature class
GM_MultiPoint <<Multipoint>> feature class
GM_Curve <<Polyline>> feature class
GM_MultiCurve
GM_Surface <<Polygon>> feature class
GM_MultiSurface
all other (e.g. GM_Solid, GM_MultiSolid) NA

Mapping of 1:n / n:1 Relationship

A 1:n /n:1 relationship is converted as follows:

  • An association with stereotype <<RelationshipClass>> is created between the source and target of the relationship:
    • Source: class that represents the “one” end of the relationship
    • Source role: name of the property with max cardinality 1
    • Source role multiplicity: 1
    • Target: class that represents the “many” end of the relationship
    • Target role: name of the non-abstract feature or object class (first character in lower case)
    • Target role multiplicity: 0..*
    • Tagged value OriginPrimaryKey: OBJECTID property of the non-abstract feature or object class that represents the source
    • Tagged value OriginForeignKey: “<source_role_name>ID” attribute in the target class (see next list item)
  • Attribute (<<Field>>) in target class with name “<source_role_name>ID” and type esriFieldTypeInteger (Precision: 9)

Mapping of n:m Relationship

An n:m relationship is converted as follows:

  • An association class is created with the following fields (and stored in a dedicated package within the ArcGIS workspace, named ‘Association Classes’):
    • “RID”: esriFieldTypeOID
    • name of source property (from application schema, if the property is named there, otherwise the name of the source class) + “ID”: esriFieldTypeInteger (Precision: 9)
    • name of target property (from application schema, if the property is named there, otherwise the name of the target class) + “ID”: esriFieldTypeInteger (Precision: 9)
  • An association with stereotype <<RelationshipClass>> is created between the source and target of the relationship:
    • Source role: name of the target property (from the application schema), or the name of the target class (from the application schema) if a name is not provided for the target property
    • Source role multiplicity: 0..*
    • Target role: name of the source property (from the application schema), or the name of the source class (from the application schema) if a name is not provided for the source property
    • Target role multiplicity: 0..*
    • Tagged value OIDFieldName: “RID”
    • Tagged value OriginPrimaryKey: OBJECTID attribute of the source class
    • Tagged value OriginForeignKey: attribute with name of target property (from application schema, if the property is named there, otherwise the name of the target class) + “ID” in the association class
    • Tagged value DestinationPrimaryKey: OBJECTID attribute of the target class
    • Tagged value DestinationForeignKey: attribute with name of source property (from application schema, if the property is named there, otherwise the name of the source class) + “ID” in the association class
    • NOTE: the tagged values are set both on the association and the association class.

Reflexive Relationships

A reflexive relationship is a relationship from a class that points back to itself. In most cases the relationship is represented by an association. In rare cases it can also be an attribute with value type being the class itself.

Conversion of reflexive relationships is currently not supported, because they are not supported in the ArcGIS workspace schema. Whenever such a relationship is encountered in the application schema, ShapeChange logs a warning and ignores the relationship.

RangeDomain from OCL

ArcGIS supports range domains for numeric values (classes with stereotype <<RangeDomain>>) which allow to set minimum and maximum values.

The conversion process identifies numeric range constraints defined for properties of feature and object types in the application schema. It does so by applying the following regular expressions:

  • .value\s*(?=>)(.*?)\s*([\+-]?[\.|\d]+)
    • this pattern detects the occurrence of a boundary comparison with the value of a property; both the comparison operator (> or >=) as well as the comparison value are detected
  • .value\s*(?=<)(.*?)\s*([\+-]?[\.|\d]+)
    • this pattern detects the occurrence of a boundary comparison with the value of a property; in this case the pattern detects an upper boundary comparison; both the comparison operator (< or <=) as well as the comparison value are detected
  • (?:self\.|\s)?(\w+)\.[\w\.]*?value(?:[,\s])
    • this pattern detects the name of the property to which the numeric range constraint applies

A numeric range constraint can define the lower boundary and/or the upper boundary for a property value. The following examples demonstrate valid numeric range constraints:

  • /* Property marineHabitatDepth – lower value > 0, upper value > 0 */ inv: let v=self.marineHabitatDepth.valueOrReason.value, vs=v.singleValue, vi=v.intervalValue, vil=vi.lowerValue, viu=vi.upperValue in v->notEmpty() implies ((vs->notEmpty() implies(vs.value > 0)) and (vi->notEmpty() implies ((vil->notEmpty() implies(vil.value > 0)) and (viu->notEmpty() implies(viu.value > 0)))))
  • /* Property vegetationTrafficImpact – lower value >= 0 and <= 100, upper value >= 0 and <= 100 */ inv: let v=self.vegetationTrafficImpact.valueOrReason.value, vs=v.singleValue, vi=v.intervalValue, vil=vi.lowerValue, viu=vi.upperValue in v->notEmpty() implies ((vs->notEmpty() implies(vs.value >= 0 and vs.value <= 100)) and (vi->notEmpty() implies ((vil->notEmpty() implies(vil.value >= 0 and vil.value <= 100)) and (viu->notEmpty() implies(viu.value >= 0 and viu.value <= 100)))))

Whenever a property in the application schema has a numeric range constraint and maps to a numeric type (esriFieldTypeInteger or esriFieldTypeDouble), a <<RangeDomain>> is created and set as the type of the <<field>> that represents the property.

Range limits in ArcGIS are inclusive. For cases in which the lower and/or upper boundary comparison operator is not inclusive, a delta will be added/subtracted to adjust the range limit in ArcGIS. The delta can be configured, for example to 0.01. If the numeric range constraint only defines one boundary of the range, a default value will be set for the other boundary (currently +/-1000000000).

NOTE: in order for ShapeChange to process and not dismiss OCL constraints while loading the input model, ensure that the configuration parameter ‘checkingConstraints’ for the “input” element is not set to ‘disabled’ (the default value is ‘enabled’).

NOTE: In most cases it is easier to use tagged values to specify the range domain. For further details, see rule-arcgis-cls-rangeDomainFromTaggedValues.

Length from OCL

Within the application schema, OCL constraints can be used to ensure that the length of a textual property value does not exceed a specific limit. If such an OCL constraint follows a specific pattern, ShapeChange can recognize it and use the information to populate the ‘length’ tagged value of the <<field>> that will represent the property in the ArcGIS model.

ShapeChange identifies a length constraint for a property by finding the following regular expression in the OCL (that is defined for the class that contains that property): (?:self\.|\s)?(\w+)\.[\w\.]*?size\(\)\D*(\d+)

The following example demonstrates a valid length constraint: inv: self.propWithSpecialLength->notEmpty() implies (self.propWithSpecialLength.size() <= 99)

NOTE: in order for ShapeChange to process and not dismiss OCL constraints while loading the input model, ensure that the configuration parameter ‘checkingConstraints’ for the “input” element is not set to ‘disabled’ (the default value is ‘enabled’).

NOTE: In most cases, it is easier to use tagged values to specify the length. For further details, see rule-arcgis-prop-lengthFromTaggedValue.

Additional Aspects

Names and Aliases

In the ArcGIS UML a model element supports the properties:

  • Name: A name of the model element
  • Alias: An alias, which will usually be shown in user interfaces

The default maximum length of a name is 30 characters. This limit can be changed via the configuration parameter maxNameLength. Another solution is to use the flattener to switch long names with short codes (e.g. contained in the conceptual model as alias of a model element).

ShapeChange will clip names that exceed the maximum name length.

Documentation

The conversion process handles documentation of application schema elements as follows:

  • If a code list or enumeration has documentation, it will be set in the ‘description’ tagged value of the resulting CodedValueDomain in the ArcGIS UML model.
  • For all other application schema types and their fields: if the model element has documentation, it will be set in the notes field of the resulting element (feature class, object class, field)  in the ArcGIS UML model.

Note, however, that most of the textual documentation of ArcGIS UML model elements will be ignored when the model is exported to an ArcGIS workspace XML document. Notes for feature and object classes as well as fields won’t be exported. CodedValueDomains support documentation via the “description” tagged value. If the application schema does not provide documentation for code lists or enumerations, then the “description” tagged value in the ArcGIS UML model will show <no description available> (because an empty description will lead to an error when validating the ArcGIS UML model in EA).

NOTE: The configuration parameter documentationTemplate is used to specify which descriptive information of a model element will be part of the documentation.

Setting the Spatial Reference System

ShapeChange currently does not set the spatial reference system used by the ArcGIS workspace. The SRS is set in the template .eap and can be changed there (before deriving the ArcGIS workspace model) or after processing by ShapeChange is complete. The SRS can be set using the ArcGIS extension. Simply right-click on the <<SpatialReference>> class (which can be found in the ArcGIS workspace model under ‘Model/ArcGIS Workspace/Spatial Reference’), then select Extensions > ArcGIS > Set Coordinate System; in the dialog that opens, choose the SRS you want.

Indexes

The ArcGIS workspace target currently does not create any specific indexes. When the ArcGIS workspace model is exported to an ArcGIS workspace document via Enterprise Architect, indexes for geometries and internal object ids are automatically created. Additional indexes can be specified as needed via the ArcGIS environment.

Required vs. Optional

While it is possible to specify for fields in a geodatabase feature/object class whether the field is required or not, it is usually advisable to make it nullable, even if the model would be stricter. An example is that during data capturing the information may not be available, but one wants to create the feature already. By default, non-system fields (that represent the properties of application schema types and feature types) are therefore all generated with IsNullable = true. The default behavior can be modified via rule-arcgis-prop-isNullable.

Composition

Composition – which is either explicitly set for an association end, or is implicit for attributes – is currently not modelled in the ArcGIS workspace model generated by this target.