Attributes

The main part of a semantic feature type is the definition of its semantic attributes. Every feature attribute metadata definition contains all available pieces of information. All feature attributes must be defined inside the featureAttributeArray collection.

Example: Defining feature type with attributes. There are four feature attributes defined for the Pipeline feature type.

<ber:featureTypeArray>
  ...
  <ber:featureType
     id="ft_5012000"
     name="Pipeline" parentId="ft_5010000" abstract="true">
    <ber:description>Water pipelineAbstract parent of water pipelines</ber:description>
    <ber:featureAttributeArray> <!-- Array of Feature Attributes -->
      <ber:attribute id="at_5010004" name="Note" dbName="NOTE"
           nillable="true">
        <ber:description>Notes for the record</ber:description>
        <ber:dataType>  <!--Data Type Definition -->
          <ber:string maxLength="80"/> <!-- The string value -->
        </ber:dataType>
      </ber:attribute>
      <ber:attribute id="at_5012002" name="Length [m]" dbName="LENGTH">
        <ber:description>The length of a pipeline</ber:description>
        <ber:dataType>
          <ber:decimal precision="10" scale="2"/> <!-- Decimal number -->
        </ber:dataType>
      </ber:attribute>
      <ber:attribute id="at_5012001" name="Diameter" dbName="C_W_DIAMETER"
             nillable="false">
        <ber:dataType> <!-- Reference to a code list -->
          <ber:codeListRef refId="cl_105" displayColumn="ca_10502"/>
        </ber:dataType>
      </ber:attribute>
      <ber:attribute id="at_5012003" name="Material" dbName="C_W_MATERIAL"
             nillable="false">
        <ber:dataType> <!-- Reference to a code list -->
          <ber:codeListRef refId="cl_102" displayColumn="ca_10202"/>
        </ber:dataType>
      </ber:attribute>
    </ber:featureAttributeArray>
  </ber:featureType>
  ...
</ber:featureTypeArray>

Feature Attribute

Example: In the following example we define a text feature attribute called Note.

<ber:attribute id="at_5010004" name="Note" dbName="NOTE"
               nillable="true">
  <ber:description>Notes for the record</ber:description>
  <ber:dataType>  <!-- The Data Type Definition -->
   <ber:string maxLength="80"/> <!-- The string value -->
  </ber:dataType>
</ber:attribute>

The description of main XML elements and attributes for a feature attribute is undermentioned.

Attributes

id – Unique feature attribute identifier. It is unique in the whole project among all metadata elements, not only attributes.
name – Name of a feature attribute.
dbName – Database column name of a feature attribute.
nillable – Specifies whether this attribute must be filled for every feature instance (nillable=false) or if it can be left empty (nillable=true).
outputFormat - Number format string. It contains the colon with format specifier and optional precision specifier (e.g.: f2, :N3 or :F0). Possible values of format specifier are F or f, N or n, D or n. There is no difference if the format specifier is written in lowercase or uppercase. Detailed description of the formats is available on following page:

https://docs.microsoft.com/dotnet/standard/base-types/standard-numeric-format-strings

Format	Used for	Precision specifier	Group separator	Example input	Example output
D or d	Whole numbers	Minimum number of digits	Not used	1234 :D6	001234
N or n	General numbers	Number of decimal digits	Used	1234.56 :N1	1,234.6
F or f	General numbers	Number of decimal digits	Not used	1234.56 :F1	1234.6

Inner Elements

description – Contains a detailed description of the feature attribute.
dataType – Data type of the feature attribute (mandatory).
defaultValue– Parameter value can be accompanied with parameter next; it is also possible to use currentDate.
forbiddenOperations – The possible forbidden operations for feature attributes are [select | filter | update]. The forbidden operations have higher priority than access rights and they are evaluated before them. The virtual and derived attributes have operation update forbidden from their principle. This property is inherited to child feature types, but can be redefined

Feature Attribute Data Type

Every feature attribute must have its data type definition. The data type determines the type of all values for the feature attribute. A list of possible data types is listed below.

String data type

This data type defines text attributes.

Attributes

minLength – Minimum number of units of length. Accepted values are 0 to 32767
maxLength – Maximum number of units of length. Accepted values are 1 to 32767, default value is 100. Please note: Length bigger than 4000 is supported since Oracle 12. MAX_STRING_SIZE = EXTENDED has to be set for the database as described here: https://docs.oracle.com/database/121/REFRN/GUID-D424D23B-0933-425F-BC69-9C0E6724693C.htm#REFRN10321
pattern – Defines constraint on the value of a datatype. The value of pattern must be a regular expression.
contentType – Defines the content type which specific application can interpret. For other applications it behaves as standard string attribute

Example: Using string data types.

<ber:attribute id="at_1" name="Note" dbName="NOTE"
               nillable="true">
  <ber:description>Notes for the record</ber:description>
  <ber:dataType>
    <ber:string maxLength="80"/>
  </ber:dataType>
</ber:attribute>
<ber:attribute id="at_2" name="e-mail" dbName="EMAIL">
  <ber:description>e-mail address</ber:description>
  <ber:dataType>
    <ber:string pattern="^[\w-]+(?:\.[\w-]+)*@(?:[\w-]+\.)+[a-zA-Z]{2,7}$" maxLength="100"/>
  </ber:dataType>
</ber:attribute>
<ber:attribute id="at_3" name="JSON content" dbName="JSON">
  <ber:description>Application JSON content</ber:description>
  <ber:dataType>
    <ber:string maxLength="10000" contentType="application/json"/>
  </ber:dataType>
</ber:attribute>

Decimal data type

The decimal data type defines numeric attributes. It is possible to define both decimal and integer numeric values.

Attributes

precision – Specifies the total number of digits, it is mandatory, possible values range from 1 to 28.
scale – Specifies the number of digits to the right of the decimal point. Accepted values are 0 to 127. If not set or set to 0, the value can only be an integer.
minInclusive – Defines lower bound of the decimal value. The decimal value must be numerically greater than or equal to value of this constraint.
maxInclusive – Defines upper bound of the decimal value. The decimal value must be numerically less than or equal to value of this constraint.
minExclusive – Defines lower bound of the decimal value. The decimal value must be numerically greater than value of this constraint.
maxExclusive – Defines upper bound of the decimal value. The decimal value must be numerically less than value of this constraint.
pattern – Defines constraint on the value of a datatype. The value of pattern must be a regular expression.
subtype – Possible values number (default) or duration.
durationUnit – Defines units of duration. Possible values: s for seconds (default), m for minutes, h for hours, ms for milliseconds. Makes sense only in combination with subtype duration.

Example: Using decimal data type.

<ber:attribute id="at_5012002" name="Length [m]" dbName="LENGTH">
  <ber:description>The length of a pipeline</ber:description>
   <ber:dataType>
    <ber:decimal precision="10" scale="2"/>
  </ber:dataType>
</ber:attribute>

warning

From version 7.1.4, LIDS checks the maximum precision of decimal data type. The maximum value can be 28. .NET is not able to work with numbers with bigger precision. Model that includes NUMBER(38) is not valid and cannot be uploaded. What to do:

Remove SEMOBJ_ID, OBJECT_ID feature attributes. These attributes were added with previous migration. LIDS 7 and newer versions do not require them.
For other feature attributes change data type to decimal precision="28" or string. To change data type is quite easy in model.xml but it can be complicated in the database.

warning

LIDS AS does not automatically convert changed data types. You must do it in the database.

Date data type

This data type defines full date attributes. The year, month, day, hour, minute, second and millisecond information is specified and stored for a date value.

Attributes

pattern –The value of pattern must be a regular expression.
minValue – Defines lower bound of the date value. It can be specified in format "yyyy-mm-dd hh:mm:ss" or "yyyy-mm-dd".
maxValue – Defines upper bound of the date value. It can be specified in format "yyyy-mm-dd hh:mm:ss" or "yyyy-mm-dd".

Example: Using date data type.

<ber:attribute id="at_5012103" name="Installation date"
               dbName="INSTALL_DATE">
  <ber:description>The date of installation</ber:description>
    <ber:dataType>
      <ber:date/>
   </ber:dataType>
</ber:attribute>

Short date data type

This data type defines date only (without time) attributes. The year, month and day information is specified for a short date value.

Attributes

pattern – The value of pattern must be a regular expression.
minValue – Defines lower bound of the date value. It can be specified in format "yyyy-mm-dd".
maxValue – Defines upper bound of the date value. It can be specified in format "yyyy-mm-dd".

Short date values are stored in the full form (including time) in Oracle DB.

Example: Using shortDate data type.

<ber:attribute id="at_5012203" name="Installation date"
               dbName="INSTALL_DATE">
  <ber:description>The date of installation</ber:description>
    <ber:dataType>
      <ber:shortDate/>
   </ber:dataType>
</ber:attribute>

Codelist reference data type

This special data type means that the only possible value for the feature attribute is a record from a codelist (it refers a codelist value). This data type holds the codelist identifier and a displayable column identifier. The displayable column is the codelist column that will be displayed as the attribute value. Internally, the codelist key is stored as the attribute value. (For more information see chapter 5.)

Attributes

pattern – The value of pattern must be a regular expression.
refId – Refers to codeList Id.
displayColumn – Refers to codeList's display column.

Example: Using codeListRef data type.

<ber:attribute id="at_5012001" name="Diameter"
               dbName="C_W_DIAMETER" nillable="false">
  <ber:dataType> <!-- Reference to a code list -->
    <ber:codeListRef refId="cl_105" displayColumn="ca_10502"/>
  </ber:dataType>
</ber:attribute>

Default Values of Attributes

A default attribute value is set as an attribute value when creating a new feature in case that the value has not been specified. The expression inside the XML value element must have correct data type (string, number, date). If the attribute has a codeListRef data type the value must refer a key within the codelist.

Example: In the following example we define a default value for a codelist attribute Diameter. This value is set to Diameter attribute in case when new feature is inserted without specifying its Diameter.

<ber:attribute id="at_5012100_diameter" name="Diameter"
               dbName="C_W_DIAMETER" nillable="false">
  <ber:dataType>
    <ber:codeListRef refId="cl_105" displayColumn="ca_10502"/>
  </ber:dataType>
  <ber:defaultValue>
    <ber:value>-1</ber:value>
  </ber:defaultValue>
</ber:attribute>

Example: In the following example we define a default value for shortDate attribute

<ber:attribute id="at_date" name="" dbName="…">
  <ber:dataType>
    <ber:shortDate/>
  </ber:dataType>
  <ber:defaultValue>
    <ber:value>2020-01-28</ber:value>
  </ber:defaultValue>
</ber:attribute>

Default value can be defined as static value or as dynamic value depending on the values of other attributes. simpleQuery must be used in the definition. geometryQuery and relationQuery are not allowed,

Example: In the following example we define a default value which depends on another attribute. Default value is updated after updating the referred attribute

<ber:attribute id="at_nextCheckDate" name="Next check date" dbName="…">
  <ber:dataType>
    <ber:date/>
  </ber:dataType>
  <ber:dynamicDefaultValue>
    <ber:simpleQuery>
      <ber:attributeArray>
        <ber:attribute xpath="at_checkDate"/>
      </ber:attributeArray>
      <!-- choice of format or expression -->
      <ber:expression>{0} + 7</ber:expression>
    </ber:simpleQuery>
  </ber:dynamicDefaultValue>
</ber:attribute>

Example: In the following example we define default value with next parameter. The parameter specifies the increment value, which is added to the previously entered value when constructing more features in the client and this attribute is marked by the red checkbox.

<ber:attribute id="at_identifier" name="Identifier" dbName="…">
  <ber:dataType>
    <ber:decimal precision="10" scale="0"/>  
  </ber:dataType>
  <ber:defaultValue>
    <ber:value>1</ber:value>
    <ber:next>10</ber:next>
  </ber:defaultValue>
</ber:attribute>

Attribute Validation

Constraints on single attributes

There is a possibility to define constraints depending on its data type for each attribute. The attribute values are validated against these constraints when active operation is performed. Active operations mean feature insert or update. Obviously, the default attribute value (if defined) must meet the validation constraints.

Each data type has its own constraints inspired by XML Schema restrictions:

String Data Type Constraints


string	maxLength	maximal string length
	minLength	minimal string length
	pattern	regular expression that the value must match

Example: Setting the maximal length of a value.

  <ber:attribute id="at_5011005" name="Serial number"
       dbName="SERIAL_NUM">
    <ber:dataType>
      <ber:string maxLength="40" />
    </ber:dataType>
  </ber:attribute>

Decimal Data Type Constraints


decimal	minInclusive	minimal decimal value (decimal value >= value)
	maxInclusive	maximal decimal value (decimal value <= value)
	minExclusive	minimal decimal value (decimal value > value)
	maxExclusive	maximal decimal value (decimal value < value)
	pattern	regular expression that the decimal value must match
	precision	total number of digits
	scale	number of digits after decimal point

Example: Defining minimal and maximal decimal value for altitude attribute.

  <ber:attribute id="at_5012104" name="Altitude-beginning"
                 dbName="ALT_BEG">
    <ber:dataType>
      <ber:decimal precision="7" scale="2" minInclusive="-11034"
           maxInclusive="8848" />
    </ber:dataType>
  </ber:attribute>

Date and Short Date Data Type Constraints


date	minValue	minimal date value
	maxValue	maximal date value (format: yyyy-MM-dd or yyyy-MM-dd hh:mm:ss)
	pattern	regular expression that the decimal value must match

Example: Defining minimal and maximal date value for an installation date attribute.

  <ber:attribute id="at_5012103" name="Installation date"
       dbName="INSTALL_DATE">
    <ber:dataType>
      <ber:date minValue="1848-01-01" maxValue="2099-01-01" />
    </ber:dataType>
  </ber:attribute>

All data types have the common constraint pattern, which specifies regular expression. The value must match that expression. Regular expressions correspond to the type 3 grammars of the Chomsky hierarchy and may be used to describe a regular language. The accepted syntax is taken from Perl and it is compatible with Java or .NET form of expression language.

Example: Pattern for e-mail address.

^[\w-]+(?:\.[\w-]+)*@(?:[\w-]+\.)+[a-zA-Z]{2,7}$

Constraints on attributes combination

It’s possible to define set of more complex rules for every feature type. Every rule consists of:

condition – attribute filter. If this condition is true, constraints are evaluated. It’s possible to define more conditions. Constraints are evaluated only if all conditions are true. Possible operators in condition are: =, !=, >, <, <=, >=. The evaluated value can be number, string or NULL
constraint – constraint defines, that particular attribute:
- has to be equal, not equal, smaller or greater than something, or IN defined values
- can’t be NULL
- is set to particular value (including NULL value) –force attribute
- is read only

tip

If readOnly is combined with force attribute, attribute becomes not editable and particular value is set automatically by the system

warning

If some attributes values combination is required, it might be impossible to edit attribute data in client applications working in autosave mode. The constraints are evaluated after every change sent to the server.

warning

If a string codelist identifier is used, the value must be enclosed by apostrophes.

warning

If condition is based on derived or generated attributes, it’s not possible to use the force for setting of an attribute to a value.

Example: attributeRuleArray in model.xml.

<ber:attributeRuleArray>
  <ber:rule id="rule1" name="at1 -1">
    <ber:description>If at1 = -1 and at2 > 8, then at2 is set to NULL and becomes not editable, at3 is set to NULL but remains editable, at4 has to be NULL and becomes not editable, at5 has to be in 1, 2, 3</ber:description>
    <ber:condition>{at1} = -1</ber:condition>
    <ber:condition>{at2} > 8</ber:condition>
    <ber:constraint readOnly="true" force="true">{at2} = NULL</ber:constraint>
    <ber:constraint force="true">{at3} = NULL</ber:constraint>
    <ber:constraint readOnly="true">{at4} = NULL</ber:constraint>
    <ber:constraint>{at5} IN (1,2,3)</ber:constraint>
  </ber:rule>
  <ber:rule id="rule2" name="at2 &lt;= 0">
    <ber:description>If at2 &lt;= 0, then at3 is set to 0</ber:description>
    <ber:condition>{at2} &lt;= 0</ber:condition>
    <ber:constraint force="true">{at3} = 0</ber:constraint>
  </ber:rule>
  <ber:rule id="rule3" name="at3 &gt; 0">
    <ber:description>If at3&gt;0, then at4 can't be NULL, at5&gt;0</ber:description>
    <ber:condition>{at3} &gt; 0</ber:condition>
    <ber:constraint>{at4} != NULL</ber:constraint>
    <ber:constraint>{at5} &gt; 0</ber:constraint>
  </ber:rule>
</ber:attributeRuleArray>

Mandatory attributes

As described in the previous chapters, there are two possible ways to define that value of particular attribute cannot be null and has to be filled:

nillable="false" parameter at attribute definition
constraint != NULL at attribute rule definition

These possibilities seem to be equivalent, but the system behavior is slightly different, especially when it comes to manipulating data which breaks the rules. In case of nillable="false" parameter, the system really expects the value of such attribute to be filled. This definition should be used just in the situations when the data is really filled, it might be also complemented by generating not null constraints in the database in the future.

tip

In case of mandatory codelist attributes, the system generates simple joins between the semantic table and the codelist table if the lids.disableEmptyMandatoryCodelistAttribute="true" property is set. Simple join is expected to provide better performance than the outer join.
This simple join causes feature records with empty values of such mandatory codelist attributes to be excluded from the result set. In such case it’s necessary to fill the empty attribute with some “undefined” value which exists in the codelist and introduce additional constraint != “undefined” which forces the users to enter value different than “undefined” during the editing. Or the attribute should be defined as nillable="true" in combination with constraint != NULL.

If there are still empty codelist attributes with the nillable="false" parameter in the project database, this performance optimizing can't be used and the outer joins need to be generated. It's done by setting the lids.disableEmptyMandatoryCodelistAttribute="false" property

Unique attributes

Attribute values uniqueness constraint can be defined on combination of more attributes by uniqueRule in attributeRuleArray. The constraint can contain optional ignoreNullValues attribute to control how NULL values are handled during validation.

Definition is inherited from parent feature type to all child feature types
It’s not possible to include virtual attributes in the constraint
In case of featureRef attributes only the master feature SID is considered
In case of codelist attributes only the codelist primary key is considered

Example: Uniqueness defined for three attributes

<ber:attributeRuleArray>
  <ber:uniqueRule id="uc_1" name="Attributes values combination must be unique">
    <ber:description>NULL values are ignored</ber:description>
    <ber:constraint ignoreNullValues="true">{at_1},{at_2},{at_3}</ber:constraint>
  </ber:uniqueRule>
</ber:attributeRuleArray>

Unique attributes – obsolete definition

Unique constraint can be defined in metadata for a feature attribute. The definition can be redefined for child feature types. Database constraint is generated according to this flag. The database constraint usage defines following behavior in case of more feature types sharing the same attribute:

more feature types in one container - the constraint is evaluated for the whole container
more feature types in more containers - uniqueness is checked for every container separately

warning

This definition was replaced in LIDS 8.25.6 by the uniqueRule definition

Example: Uniqueness defined directly at the attribute definition

<ber:attribute id="at_123" name="Unique ID" dbName="ID" unique="true">
  <ber:dataType>
    <ber:decimal precision="12" scale="0"/>
  </ber:dataType>
</ber:attribute>

Example: Uniqueness defined for redefined attributes

<ber:redefinedFeatureAttributeArray>
  <ber:redefinedAttribute refId="at_456" unique="true"/>
  <ber:redefinedAttribute refId="at_789" unique="false"/>
</ber:redefinedFeatureAttributeArray>

Derived Attributes

Feature attribute can be defined as derived. Then its value is not provided directly by user by it is automatically derived from some other data in system.

Simple derived attributes

In case when attribute is derived from other attributes of the same feature it is called simple derived attribute. It is defined by simple query.

Example: In the following example we define a simple derived attribute Description.

<ber:derivedAttribute id="at_fibre_description" name="Description"       dbName="DESCRIPTION">
  <ber:dataType>
    <ber:string maxLength="255"/>
  </ber:dataType>
  <ber:attributeQuery preventRegeneration =”true”>
    <ber:simpleQuery>
      <ber:attributeArray>
        <ber:attribute xpath="at_fibre_cable_id_2"/>
        <ber:attribute xpath="at_fibre_ordernum"/>
        <ber:attribute xpath="at_telco_id"/>
      </ber:attributeArray>
      <ber:format>Cable id: {0}, {1,4} {2}</ber:format>
    </ber:simpleQuery>
  </ber:attributeQuery>
</ber:derivedAttribute>

attributeQuery – Mandatory element of derived attribute. Includes complete definition for attribute deriving.
preventRegeneration – Optional attribute. If set to true, the derived attribute will be updated only when changing the source attributes. The derived attribute will be exluded from the on demand regenerating.
simpleQuery – Definition for attributes derived from other attributes of the same feature.
attributeArray – List of attributes used for this attribute deriving. An update of any attribute in this array triggers refreshing of the derived attribute
format - Format of derived attribute value. Uses .NET syntax. Attributes from attribute array are referred by index in curly brackets. The first attribute in array has index {0}. It can be used to define format of decimal number or concatenating attributes with constant strings
expression– expression can be used instead of format. The expression string can also include attributes references in curly brackets. The expression is processed directly by the database, so the syntax has to comply to the used database engine

Example: Another example of simple derived attribute Cable length. Here expression is used instead of simple format to enable calling Oracle DB functions for attribute deriving.

<ber:derivedAttribute id="at_cable_length" name="Cable length [m]"      dbName="CABLE_LENGTH">
  <ber:dataType>
    <ber:decimal precision="10" scale="2"/>
  </ber:dataType>
  <ber:attributeQuery>
    <ber:simpleQuery>
      <ber:attributeArray>
        <ber:attribute xpath="at_length_of_routes"/>
        <ber:attribute xpath="at_length_of_ducts"/>
      </ber:attributeArray>
      <ber:expression>NVL({0},0)+ NVL({1},0)</ber:expression>
    </ber:simpleQuery>
  </ber:attributeQuery>
</ber:derivedAttribute>

Format element

Generally, a format element contains a text with one or more placeholders for referred attribute values. Every placeholder is enclosed in curly brackets. For example, in this simple format definition ber:formatDiameter: {0}mm, Length: {1}m</ber:format> are two placeholders just replaced by two values. But the placeholder can contain another formatting specifiers for more sophisticated result.

The formatting placeholder syntax is:

{index[,[+|-]alignment][:formatSpecifier[precision]]}

String formatting

We can define string alignment, for example:

Format	Value	Output
`->{0,10}<-`	"Hello"	->·····Hello<-
`->{0,-10}<-`	"Hello"	->Hello·····<-
`->{0,-10}<-`	"123456"	->123456····<-

Number formatting specifiers

Specifier	Type	Format	Output (Passed Double 1.42)	Output (Passed Int -12400)
D or d	Decimal (Whole number)	`{0:d}`	FormatException	-12400
E or e	Scientific	`{0:e}`	1.420000e+00	-1.240000e+04
F or f	Fixed point	`{0:f}`	1.420000	-12400.000000
G or g	General	`{0:g}`	1.42000	-14200.0
X or x	Hexadecimal	`{0:x4}`	FormatException	cf90

Number rounding

Format	Value	Output	Comment
`{0:F2}`	12345.6789	12345.68	rounds up
`{0:F0}`	12345.6789	12346	rounds up
`{0:F6}`	12345.6789	12345.678900
`->{0,10:F2}<-`	12345.6789	->··12345.68<-	rounds up
`->{0,-10:F0}<-`	12345.6789	->12346·····<-	rounds up

In case when feature attribute is derived from features connected by relation it is defined by relation query.

warning

If the relation association used in the query allows more features to be related (cardinality is not 1), it’s necessary to define some grouping function like min, max, count, sum , listagg. This is necessary to assure, that just one value is returned. Otherwise more values would be returned, and it wouldn’t be possible to save them in single attribute.

If there is no feature related by the relationAssoc used in the relationQuery, the returned value would be typically NULL. To return some reasonable result, fallbackValue attribute has to be defined. This works for derived attributes, not for virtual attributes. Format of fallbackValue for date attributes is "2024-01-23" for shortDate and "2024-01-23 12:00:00" for date. Example: In the following example extraction point simply derives identification of its service pipe to attributeService pipe – Identification. There is a relation between extraction point and service pipe (with id sr_5012200_5010200) that is used for this attribute deriving.

<ber:derivedAttribute id="at_5010202" name="Service pipe - Identification"     dbName="SP_IDENTIFICATION">
  <ber:dataType>
    <ber:string maxLength="40"/>
  </ber:dataType>
  <ber:attributeQuery>
    <ber:relationQuery>
      <ber:attributeArray>
        <ber:attribute xpath="at_5010007"/>
      </ber:attributeArray>
      <ber:relationAssoc refId="sr_5012200_5010200"/>
    </ber:relationQuery>
  </ber:attributeQuery>
</ber:derivedAttribute>

Example: Another example of attribute derived from related features. In this case derived attribute Parcel count derives number of parcels crossed by a pipeline segment. There is a relation between pipeline segment and parcels (with id sr_mps_parcel) that is used for this attribute deriving.

<ber:derivedAttribute id="at_5012100_countparc" name="Parcel count"      dbName="COUNT_PARC">
  <ber:dataType>
    <ber:decimal precision="5" scale="0"/>
  </ber:dataType>
  <ber:attributeQuery>
    <ber:relationQuery fallbackValue="0">
      <ber:expression>count(*)</ber:expression>
      <ber:relationAssoc refId="sr_mps_parcel"/>
    </ber:relationQuery>
  </ber:attributeQuery>
</ber:derivedAttribute>

Example: Use of an optional element <filterRelated> within <relationQuery> element. It is possible to define an OGC filter on semantics of the related features.

  <ber:derivedAttribute id="at_5060004_o" name="Service pipes in order count" dbName="COUNT_SERVICEP_O">
    <ber:dataType>
      <ber:decimal precision="5" scale="0"/>
    </ber:dataType>
    <ber:attributeQuery>
      <ber:relationQuery>
        <ber:expression>count(*)</ber:expression>
        <ber:relationAssoc refId="sr_5060000_5012200"/>
        <ber:filterRelated>
          <ogc:Filter>
            <ogc:And>
              <ogc:PropertyIsEqualTo>
                <ogc:PropertyName>at_5010100</ogc:PropertyName>
                <ogc:Literal>1</ogc:Literal>
              </ogc:PropertyIsEqualTo>
              <ogc:PropertyIsLike wildCard="%" singleChar="_" escapeChar="\">
                <ogc:PropertyName>@ftid</ogc:PropertyName>
                <ogc:Literal>ft_building%</ogc:Literal>
              </ogc:PropertyIsLike>
            </ogc:And>
          </ogc:Filter>
        </ber:filterRelated>
      </ber:relationQuery>
    </ber:attributeQuery>
  </ber:derivedAttribute>

PropertyIsEqualTo – Type of filter condition.
PropertyName – Item (attribute) the filter is applied to. If filer is applied to system attribute, “@” needs to be added.
Literal – Specification of filtering value.

Example: Use of an optional attribute inputRole which defines from which role of a relation to derive the value. Typically used for relations which include the same feature types in both roles.

<ber:derivedAttribute id="at_duct_1" name="Ducts 1 count" dbName="COUNT_DUCTS_1">
  <ber:description>Related ducts in role 1</ber:description>
  <ber:dataType>
    <ber:decimal precision="10" scale="0"/>
  </ber:dataType>
  <ber:attributeQuery>
    <ber:relationQuery>
      <ber:expression>count(*)</ber:expression>
      <ber:relationAssoc inputRole="rt_duct_1" refId="r_duct_duct"/>
    </ber:relationQuery>
  </ber:attributeQuery>
</ber:derivedAttribute>
<ber:derivedAttribute id="at_duct_2" name="Ducts 2 count" dbName="COUNT_DUCTS_2">
  <ber:description>Related ducts in role 2</ber:description>
  <ber:dataType>
    <ber:decimal precision="10" scale="0"/>
  </ber:dataType>
  <ber:attributeQuery>
    <ber:relationQuery>
      <ber:expression>count(*)</ber:expression>
      <ber:relationAssoc inputRole="rt_duct_2" refId="r_duct_duct"/>
    </ber:relationQuery>
  </ber:attributeQuery>
</ber:derivedAttribute>

Geometry derived attributes

Derivation of attribute value from geometry characteristics is performed by geometry query.

Example: Derivation by geometric function.

  <ber:derivedAttribute id="at_5010106" name="WGS-84 coordinates" dbName="WGS84_COORD">
    <ber:dataType>
      <ber:string maxLength="40"/>
    </ber:dataType>
    <ber:attributeQuery>
      <ber:geometryQuery>
        <ber:geometryFunction name="firstVertexX"/>
        <ber:geometryFunction name="firstVertexY"/>
        <ber:convertSrs outputSrs="EPSG:4326" attrIndexX="0" attrIndexY="1"/>
        <ber:format>{1}, {0}</ber:format>
      </ber:geometryQuery>
    </ber:attributeQuery>
  </ber:derivedAttribute>

geometryQuery – Definition for attributes derived from other attributes using geometry functions.
geometryFunction – You can use functions area, centroidX, centroidY, firsVertexX, firstVertexY, firstVertexZ, lastVertexX, lastVertexY, lastVertexZ, length (can be used also for perimeter of surface geometry), length2D (calculates projected 2D length for 3D line), maxX, maxY, maxZ, minX, minY, minZ, rotation, rotationGrad, rotationRad.
convertSrs – Conversion of spatial reference system. Parameters outputSrs, attrIndexX, attrIndexY.
format - Format of derived attribute value. Uses .NET syntax. Attributes from attribute array are referred by index in curly brackets. The first attribute in array has index {0}.
sharedSemanticsGraphicChild – Refers graphic child of feature type with the shared semantics.

Combined derived attributes

Query for deriving value can contain a combination of simple, geometry and relation query. Because of just one derived value is expected, the format or expression must be given for the concatenation of individual results.

ComplexQuery must contain:

exactly one simpleQuery
one relationQuery and / or one geometryQuery

warning

The relationQuery in complexQuery can’t include a relation with the same feature type in both roles.

Example: Derivation by more queries.

<ber:derivedAttribute id="at_complex" name="Complex info" dbName="COMPLEX_INFO">
  <ber:dataType>
    <ber:string maxLength="120"/>
  </ber:dataType>
  <ber:attributeQuery>
    <ber:complexQuery>
      <ber:queryArray>
        <ber:simpleQuery>
          <ber:attributeArray>
            <ber:attribute xpath="at_5012104"/>
            <ber:attribute xpath="at_5012105"/>
          </ber:attributeArray>
          <ber:expression>{1} - {0}</ber:expression>
        </ber:simpleQuery>
        <ber:geometryQuery>
          <ber:geometryFunction name="length"/>
          <ber:expression>nvl({0}, 0)</ber:expression>
        </ber:geometryQuery>
        <ber:relationQuery>
          <ber:attributeArray>
            <ber:attribute xpath="at_5040007"/>
          </ber:attributeArray>
          <ber:relationAssoc refId="r_5040000_5012100"/>
        </ber:relationQuery>
      </ber:queryArray>
      <!--ber:format>Gradient: {0}, Length: {1}, Main Id: {2}</ber:format-->
      <ber:expression>'Gradient: ' || nvl2({0},'{0}','') || ', Length: {1}, Main Id: {2}'</ber:expression>
    </ber:complexQuery>
  </ber:attributeQuery>
</ber:derivedAttribute>

Cross sections derived attributes

This type of attribute is intended for cross-section feature types (routes, ducts, cables). The deriving functions are crossSectionFunction with following possibilities:

csDescription – derives description of assigned cross section to a route attribute
csName – derives name of assigned cross section to a route attribute
maxPositionsCount – derives count of cable positions defined for a duct or for a route
assignedPositionsCount – derives count of used cable positions for a duct or for a route
freePositionsCount – derives count of free cable positions for a duct or for a route
mbrWidth / mbrHeight – derives width or height of MBR encapsulating geometry of assigned cross-section components. The cross-section used for calculating MBR are defined in includedGraphicTypeComponent element

Example: Derivation of name of assigned cross section.

  <ber:derivedAttribute id="at_cs_name" name="Cross section name" dbName="CS_NAME">
    <ber:dataType>
      <ber:string maxLength="100"/>
    </ber:dataType>
    <ber:attributeQuery>
      <ber:crossSectionQuery>
        <ber:crossSectionFunction name="csName"/>
      </ber:crossSectionQuery>
    </ber:attributeQuery>
  </ber:derivedAttribute>

Example: Derivation of cross-section width.

  <ber:derivedAttribute id="at_cs_width" name="Cross section width" dbName="CS_W">
    <ber:dataType>
      <ber:decimal precision="6" scale="2"/>
    </ber:dataType>
    <ber:attributeQuery>
      <ber:crossSectionQuery>
        <ber:crossSectionFunction name="mbrWidth"/>
        <ber:includedGraphicTypeComponentArray>
          <ber:includedGraphicTypeComponent refId="gtcs_0001_01"/>
          <ber:includedGraphicTypeComponent refId="gtcs_0001_02"/>
          <ber:includedGraphicTypeComponent refId="gtcs_0001_03"/>
        </ber:includedGraphicTypeComponentArray>
      </ber:crossSectionQuery>
    <ber:attributeQuery>
  </ber:derivedAttribute>

Security derived attributes

Security derived attribute is defined for deriving a security codelist value. Definition is similar to ordinary attribute, only there is a reference to a codelist (<ber:codeListRef refId="cl_018"…) and its column (…displayColumn="ca_01802"/>).

Example: Security derived attribute.

<ber:securityDerivedAttribute id="at_5120006_s" name="Operation status">
  <ber:dataType>
    <ber:codeListRef refId="cl_018" displayColumn="ca_01802"/>
  </ber:dataType>
  <ber:defaultValue>
    <ber:value>1</ber:value>
  </ber:defaultValue>
  <ber:attributeQuery>
    <ber:relationQuery>
      <ber:attributeArray>
        <ber:attribute xpath="at_5120005_s"/>
      </ber:attributeArray>
      <ber:expression>min({0})</ber:expression>
      <ber:relationAssoc refId="r_route_duct"/>
    </ber:relationQuery>
  </ber:attributeQuery>
</ber:securityDerivedAttribute>

Virtual attributes

The special case of derived attributes are virtual attributes. Opposite to derived attributes they are not physically stored in database. They exist only virtually, and they are derived every time they are required by client application. However, the definition is nearly same as the derived attribute definition – you can use the same functions, including geometric (see chapter 4.5.3).

Example: Definition of virtual attribute, used for visualization of material codelist id.

<ber:virtualAttribute id="at_5012115" name="Material ID">
  <ber:dataType>
    <ber:string maxLength="5"/>
  </ber:dataType>
  <ber:attributeQuery>
    <ber:simpleQuery>
      <ber:attributeArray>
        <ber:attribute xpath="at_5012003/ca_10201"/>
      </ber:attributeArray>
    </ber:simpleQuery>
  </ber:attributeQuery>
</ber:virtualAttribute>

tip

When you have feature type that is not abstract and this feature type has no geometry, you cannot define derived attribute with geometry function. It makes no sense. For feature without geometry, you can't compute length. LIDS AS will check this and does not allow to upload or start with such metadata. This problem is usually caused by previous version of migration. What to do:

Change feature type to be abstract.
Move derived attribute from parent feature type to all child feature types
Change derived attribute to normal attribute. Redefine this attribute in all children to be derived.
Create child feature type of the problematic feature type. Make this new feature type abstract. Move the derived attribute to the new feature type. Change parents for all child feature types of the problematic feature type to the new feature type.

warning

Attribute identifier (id) may be at most 30 characters long.

warning

Virtual attributes can't be used for subsequent deriving of other attributes, symbology tokens, DAs; also, they can't be redefined.

warning

Virtual attributes are not updated automatically when the source geometry / attributes change. Feature must be manually reloaded.

FeatureRef Attribute

Special type of attributes is featureRef attribute. In fact, the visible values represent values from master feature type in 1:N or 1:1 relation. Moreover, featureRef attributes are physically stored in semantic table instead of association table.

Example: Definition of featureRef attribute.

<ber:featureRefAttribute id="at_1" name="Some name" dbName="XY">
  <ber:dataType>
    <ber:featureRef>
      <ber:attribute refId="at_2"/>
      <ber:featureRefRelationAssoc refId="r_1"/>
    </ber:featureRef>
  </ber:dataType>
</ber:featureRefAttribute>

warning

Attribute identifier (id) may be at most 30 characters long.

warning

The referred master feature attributes can be of any data type including featureRef. It’s only not possible to refer system attributes this way. Referring featureRef attribute currently (LIDS 8.16) causes problems with the Search extension. It’s not possible to index such attributes.

warning

Access rights are not evaluated for the master feature attributes referred from featureRef attributes. This way the user can see also the attributes which are normally not accessible to him.

A featureRef attribute can define more attributes from the master feature directly. In such case, one of the referred attributes has to be marked by the default attribute.

Example: Definition featureRef attribute referring more attributes of master feature.

<ber:featureRefAttribute id="at_1" name="Some name" dbName="XY">
  <ber:dataType>
    <ber:featureRef>
      <ber:attribute refId="at_2"/>
      <ber:attribute refId="at_3" default="true"/>
      <ber:attribute refId="at_4"/>
      <ber:featureRefRelationAssoc refId="r_1"/>
    </ber:featureRef>
  </ber:dataType>
</ber:featureRefAttribute>

tip

To enable autocomplete when editing featureRef attribute in LIDS clients, following configuration is necessary:

the master feature type has to be indexed in Elastic and included in searchMetaGroup in explorer.xml
the master feature display attribute has to be indexed with fieldPreset - startswith in search.xml

        <ber:indexedAttribute>
          <ber:includeAttribute>at_master</ber:includeAttribute>
          <ber:fieldPreset>startswith</ber:fieldPreset>
        </ber:indexedAttribute>

FeatureRef Relation

Relation featureRefRelationAssoc must be defined for each featureRef attribute. It has master role and child role. Master role does not define cardinality, it must be 1 in every case.

tip

Optionally, it’s possible to specify orderBy element which defines according to which attribute the list of possible values is ordered when editing the featureRefAttribute.

Example: Definition of featureRefRelationAssoc:

<ber:featureRefRelationAssoc id="r_1" name="Some name">
  <ber:masterRole refId="rt_1">
    <ber:orderBy>
      <ber:attribute refId="at_XYZ" direction="ascending" position="0"/>
      <ber:attribute refId="at_ABC" direction="ascending" position="1"/>
    </ber:orderBy>
  </ber:masterRole>
  <ber:childRole refId="rt_2"/>
</ber:featureRefRelationAssoc>

Preserve display of deleted master feature

It’s possible to preserve the reference to the master feature even when the master feature is deleted. This behavior is activated by the attribute preserveMasterFeature in masterRole definition. In this case, new column with postfix _D is generated in database parallel to the featureRefAttribute. If the master feature is deleted, its SID is moved from the standard featureRefAttribute column to the_D column.

warning

The preserveMasterFeature="true" property should be used with caution. It may negatively impact performance. Child feature data is retrieved through the _D database view, which combines live table data with latest_history records from history tables. This additional processing can significantly increase query time.

Interface role

If the master role is interfaceRole in featureRef relation with preserveMasterFeature="true", then an _LD table is generated in the database for storing the latest versions of deleted features to improve the perfomance of data querying. This table must be initially populated with historical data by calling the /rest/features/latest-deleted/sync service.

Example: Definition of preserveMasterFeature
<ber:featureRefRelationAssoc id="r_1" name="Some name">
  <ber:masterRole refId="rt_1" preserveMasterFeature="true">
  <ber:childRole refId="rt_2"/>
</ber:featureRefRelationAssoc>

Generated Attribute

Special type of attribute is a generated attribute. It is a feature attribute referencing the number generator, which has to be also defined in section numberGeneratorArray.

Example: Definition of generated attribute.

<ber:numberGeneratorArray>
    <ber:numberGenerator id="seq_sernum" name="Serial number" dbName="SEQ_SER_NUMBER" startValue="1" step="1">
      <ber:description>Optional description</ber:description>
    </ber:numberGenerator>
  </ber:numberGeneratorArray>
...
<ber:generatedAttribute id="at_5011005" name="Serial number" dbName="SERIAL_NUM">
  <ber:dataType>
    <ber:string maxLength="40"/>
  </ber:dataType>
  <ber:attributeQuery>
    <ber:numberGeneratorQuery>
      <ber:numberGenerator refId="seq_sernum"/>
      <ber:format>SN_{0}</ber:format>
    </ber:numberGeneratorQuery>
  </ber:attributeQuery>
</ber:generatedAttribute>

Redefined Attribute

Feature attribute can be set as redefined. You can define feature attribute in a parent feature type and redefine some properties in children feature types.

What you can redefine:

Default values.
Whether the attribute is mandatory (nillable flag in model).
Forbidden operations (READ, QUERY, UPDATE).
Codelist reference (you can change a codelist data type to a different codelist, different codelist must be a filtered codelist based on previous codelist).
Derived attribute query (you can define deriving query in children feature types, you can change deriving query in children feature types).

You can change the type of the attribute from normal (parent) to derived in any child. You can make multiple redefinitions of one attribute.

Example 1:

Original definition of attribute:

  <ber:securityAttribute id="at_5120006_s" name="Operation status">
    <ber:dataType>
      <ber:codeListRef refId="cl_018" displayColumn="ca_01802"/>
    </ber:dataType>
    <ber:defaultValue>
      <ber:value>1</ber:value>
    </ber:defaultValue>
  </ber:securityAttribute>

Redefinition:

  <ber:redefinedFeatureAttributeArray>
    <ber:redefinedSecurityDerivedAttribute refId="at_5120006_s">
      <ber:attributeQuery>
        <ber:relationQuery>
          <ber:attributeArray>
            <ber:attribute xpath="at_5120006_s"/>
          </ber:attributeArray>
          <ber:expression>min({0})</ber:expression>
          <ber:relationAssoc refId="r_route_duct"/>
        </ber:relationQuery>
      </ber:attributeQuery>
    </ber:redefinedSecurityDerivedAttribute>
  </ber:redefinedFeatureAttributeArray>

Example 2:

Original definition of attribute:

        <ber:attribute id="at_5123405" name="Diameter [cm]" dbName="C_E_DIAMETER">
          <ber:dataType>
            <ber:codeListRef refId="cl_319" displayColumn="ca_31902"/>
          </ber:dataType>
        </ber:attribute>

Redefinition 1:

      <ber:redefinedFeatureAttributeArray>
        <ber:redefinedAttribute refId="at_5123405" nillable="false">
          <ber:defaultValue>
            <ber:value/>
          </ber:defaultValue>
        </ber:redefinedAttribute>
      </ber:redefinedFeatureAttributeArray>

Redefinition 2:

        <ber:redefinedDerivedAttribute refId="at_5123405">
          <ber:attributeQuery>
            <ber:relationQuery>
              <ber:attributeArray>
                <ber:attribute xpath="at_5123405"/>
              </ber:attributeArray>
              <ber:relationAssoc refId="r_duct_sch_duct"/>
            </ber:relationQuery>
          </ber:attributeQuery>
        </ber:redefinedDerivedAttribute>

Example 3: Multiple redefinitions of nillable, defaultValue, codelist reference property.

Original definition:

        <ber:attribute id="at_5012000_diameter" name="Diameter" dbName="C_W_DIAMETER" nillable="false">
          <ber:dataType>
            <ber:codeListRef refId="cl_105" displayColumn="ca_10502"/>
          </ber:dataType>
          <ber:defaultValue>
            <ber:value>-1</ber:value>
          </ber:defaultValue>
        </ber:attribute>

Redefinition 1:

   <ber:redefinedFeatureAttributeArray>
        <ber:redefinedAttribute refId="at_5012000_diameter">
          <ber:dataType>
            <ber:codeListRef refId="cl_505" displayColumn="ca_10502"/>
          </ber:dataType>
          <ber:defaultValue>
            <ber:value>15</ber:value>
          </ber:defaultValue>
        </ber:redefinedAttribute>
      </ber:redefinedFeatureAttributeArray>

Redefinition 2:

      <ber:redefinedFeatureAttributeArray>
        <ber:redefinedAttribute refId="at_5012000_diameter" nillable="true"/>
        <ber:redefinedAttribute refId="at_5012003" nillable="true"/>
        <ber:redefinedAttribute refId="at_5010001" nillable="true"/>
      </ber:redefinedFeatureAttributeArray>

Example 4: Redefinition with reference to shared semantics, redefinition contains geometry query.

Original definition:

        <ber:attribute id="at_5110004" name="Area [m²]" dbName="AREA">
          <ber:dataType>
            <ber:decimal precision="10" scale="2"/>
          </ber:dataType>
        </ber:attribute>

Redefinition:

     <ber:redefinedFeatureAttributeArray>
        <ber:redefinedDerivedAttribute refId="at_5110004" outputFormat=":f2">
          <ber:attributeQuery>
            <ber:geometryQuery>
              <ber:geometryFunction name="area"/>
              <ber:sharedSemanticsGraphicChild refId="ft_5111200"/>
            </ber:geometryQuery>
          </ber:attributeQuery>
        </ber:redefinedDerivedAttribute>
      </ber:redefinedFeatureAttributeArray>
  ...
      <ber:redefinedFeatureAttributeArray>
        <ber:redefinedDerivedAttribute refId="at_5110004">
          <ber:attributeQuery>
            <ber:geometryQuery>
              <ber:geometryFunction name="area"/>
              <ber:sharedSemanticsGraphicChild refId="ft_5114200"/>
            </ber:geometryQuery>
          </ber:attributeQuery>
        </ber:redefinedDerivedAttribute>
      </ber:redefinedFeatureAttributeArray>

Feature Info

Feature info defines the human readable feature identification. It is feature type based and is defined as a system attribute in the rootFeatureType. To define the identification, feature type can use any of its attributes. Reference to the desired attribute is located inside the feature type definition.

If defined, featureInfo identification is displayed for example in LIDS Explorer in Subordinate Features Tree.

Example: Definition of featureInfo system attribute.

    <ber:rootFeatureType id="ft_5000002" name="Root" abstract="true">
      <ber:description>ROOT_NODE</ber:description>
      <ber:featureAttributeArray>
        <ber:systemAttribute id="id" name="Feature ID"/>
        <ber:systemAttribute id="sid" name="Semantic ID"/>
...
        <ber:systemAttribute id="validTo" name="Valid To"/>
        <ber:systemAttribute id="featureInfo" name="Feature Info"/>
      </ber:featureAttributeArray>
    </ber:rootFeatureType>

Example: Feature info definition.

   <ber:featureType id="ft_damage" name="Damage" parentId="ft_inspection" abstract="false">
...
      <ber:featureAttributeArray>
...
      </ber:featureAttributeArray>
      <ber:featureInfo refId="at_inspection_description"/>
      <ber:formArray>
...
      </ber:formArray>
    </ber:featureType>

featureInfo – Defines the human readable feature identification.

tip

FeatureInfo definition is inherited from the parent feature types. Child feature type can define its own definition.

warning

Existing data needs to be refreshed after adding / modifying the definition by calling deriveFeatureInfos service.

Feature Attribute​

Feature Attribute Data Type​

String data type​

Decimal data type​

Date data type​

Short date data type​

Codelist reference data type​

Default Values of Attributes​

Attribute Validation​

Constraints on single attributes​

Constraints on attributes combination​

Mandatory attributes​

Unique attributes​

Unique attributes – obsolete definition​

Derived Attributes​

Simple derived attributes​

Format element​

Attributes derived from related features​

Geometry derived attributes​

Combined derived attributes​

Cross sections derived attributes​

Security derived attributes​

Virtual attributes​

FeatureRef Attribute​

FeatureRef Relation​

Preserve display of deleted master feature​

Generated Attribute​

Redefined Attribute​

Feature Info​

Feature Attribute

Feature Attribute Data Type

String data type

Decimal data type

Date data type

Short date data type

Codelist reference data type

Default Values of Attributes

Attribute Validation

Constraints on single attributes

Constraints on attributes combination

Mandatory attributes

Unique attributes

Unique attributes – obsolete definition

Derived Attributes

Simple derived attributes

Format element

Attributes derived from related features

Geometry derived attributes

Combined derived attributes

Cross sections derived attributes

Security derived attributes

Virtual attributes

FeatureRef Attribute

FeatureRef Relation

Preserve display of deleted master feature

Generated Attribute

Redefined Attribute

Feature Info