Skip to main content

Global Metadata Properties

Global Project Properties​

Global project properties are placed in the beginning of the model.xml file. They include various global based definitions.

Example: Global project definitions.

<ber:model xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:se="http://www.opengis.net/se" xmlns:ogc="http://www.opengis.net/ogc" xmlns:sld="http://www.opengis.net/sld" xmlns:ber="http://www.berit.com/ber">
  <ber:project name="LIDSdemo" version="7.5.0">
    <ber:description>LIDS Demo Project</ber:description>
    <ber:spatialInfo baseUnit="m" srs="EPSG:31467">
      <ber:range>
        <ber:x min="3449000" max="3464400"/>
        <ber:y min="5476300" max="5490500"/>
      </ber:range>
      <ber:tolerance>0.0005</ber:tolerance>
      <ber:coordinatesScale>2</ber:coordinatesScale>
    </ber:spatialInfo>
    <ber:languages>
      <ber:projectLanguage locale="en" name="English"/>
      <ber:language locale="cs" name="Czech"/>
      <ber:language locale="de" name="German"/>
      <ber:language locale="de-CH" name="Schwiizerdütsch"/>
      <ber:language locale="it" name="Italiano"/>
    </ber:languages>
  </ber:project>
  ...
</ber:model>

  • name – Defines project name.

  • version – Keeps the project version in any format.

  • description – Describes the project.

SpatialInfo and coordinate system​

  • spatialInfo – Specifies project spatial information.

  • srs – Identifies project spatial reference system.

  • baseUnit – Specifies project base units. It is restricted to one of: 'm', 'cm' or 'mm'.

  • tolerance – Specifies tolerance for some spatial functions, when two coordinates can be considered as being identical.

  • coordinatesScale – Optional definition. Number of fraction digits for rounding the coordinates

  • range – Defines project spatial area in the specified reference system. This range should cover all feature geometries from all database containers. The value should be set reasonably according to project data. If set too large, many spatial operations don’t work correctly.

In case of local coordinate system usage, it’s not possible to use the standard SRS code. It's possible to use a derived SRS like in the multi-crs.xml extension metadata instead. This means the project data is stored in such derived system instead of a standard one.

Example: Local derived coordinate system definition.

    <ber:spatialInfo baseUnit="m">
      <ber:derivedCRS id="Translated_31467" name="GK3 - translated">
        <ber:baseCRS refId="EPSG:31467"/>
        <ber:transform>
          <ber:translate offsetX="30" offsetY="0"/>
          <ber:rotation anchorX="3456926" anchorY="5481071">0</ber:rotation>
          <ber:scale>0.5</ber:scale>
        </ber:transform>
      </ber:derivedCRS>
      ...
    </ber:spatialInfo>

System Properties​

  • id – this by project specified number is used as a part of generated system identifiers (FID, SID, GTID, GID, setting id, association id, attachment id). It’s used to assure unique identifiers across the indiviual project instances on the same database. Possible values: numbers between 0 and 255

The metadata version from the system point of view is kept in the special part of metadata file. It specifies the current metadata system version and the minimal versions of particular system components that are able to handle the metadata. It is managed by the system itself. Do not edit it manually!

  • model – system version of metadata.

  • minClient – minimal version of LIDS Edit / Explorer.

  • minAS – minimal version of LIDS Application server.

Example: Metadata system version info.

  <ber:system id="0">
    <ber:version>
      <ber:model>101</ber:model>
      <ber:minClient>3064</ber:minClient>
      <ber:minAS>12919</ber:minAS>
    </ber:version>

Graphic Type Classes​

Inside the system, there is also a definition of classes for graphic tags and for collections. There are several possible classes for graphic tags:

  • DA – Displayable attributes.

  • PlacedCS – Placed cross-section.

  • CSReference – Cross-section reference for plot outputs.

  • BorderLine – By server generated border lines.

  • BorderPolygon – By server generated border polygons.

  • DetailReference – Detail reference for plot outputs.

  • DetailReferenceMap – This graphic type is used for detail reference plot in map frame.

  • GhostSymbol – Graphic tag type consisting of one or more point symbols at the same coordinates as the main graphics.

  • FreeGT – Manually created graphic tag.

  • DirectionSymbol – Symbol representing line direction.

  • BorderLineReduction – This graphic type is used for reduction consisting of lines.

  • BorderPolygonReduction – This graphic type is used for reduction consisting of polygon.

Other classes are used for collections:

  • Dimension – Standard MicroStation dimensions, collection graphic type

  • ExtDimension – Dimensions for LIDS dimensioning tool, collection graphic type

  • DenseAreaReference – Dense area reference for plot outputs, graphic tag

  • DenseAreaZoom – Plotting of dense areas, collection graphic type

  • Cell – This graphic type is created by breaking MicroStation cells into individual components.

  • Chart – This graphic type is used for storing the generated charts.

  • FreeCollection – This graphic type is used for manually created collection as master graphics.

  • SlopeHatch – This graphic type is used for generating slope hatches as master graphics.

Example: Definition of graphic type classes.

  <ber:system id="0">
     …
    <ber:graphicTypeClassArray>
      <!-- classes for graphic tags START -->
      <ber:graphicTypeClass id="DA" name="Displayable attribute">
        <ber:description>Displayable attributes, graphic tag</ber:description>
      </ber:graphicTypeClass>
      <ber:graphicTypeClass id="SimpleDimension" name="Simple dimension">
        <ber:description>For light clients, graphic tag</ber:description>
      </ber:graphicTypeClass>
      …
      <!-- classes for graphic tags END -->
      <!-- classes for collections START -->
      <ber:graphicTypeClass id="Dimension" name="Standard MicroStation dimension">
        <ber:description>Standard MicroStation dimensions, collection graphic type</ber:description>
      </ber:graphicTypeClass>
      <ber:graphicTypeClass id="ExtDimension" name="Extended dimension">
        <ber:description>Dimensions for LIDS dimensioning tool, collection graphic type</ber:description>
      </ber:graphicTypeClass>
      …
      <!-- classes for collections END -->
    </ber:graphicTypeClassArray>
  </ber:system>

Metadata Items​

In general, LIDS metadata is a set of collections of various metadata items. All metadata items have the same identification information - id, name, description.

Example: Metadata item (feature attribute).

<ber:attribute id="at_5010004" name="Note" dbName="NOTE">
  <ber:description>Notes for the record</ber:description>
   ...
</ber:attribute>

The identification attributes have these meanings and restrictions:

  • id – Globally unique metadata item identification. It has to start with a letter or underscore '' and may contain only letters, digits, underscores '', hyphens '-' or periods '.' . Its length is restricted to 40 characters (however model.xml is valid with any length of id).

  • name – Basic human readable metadata identification. Its length is restricted to 60 characters.

  • description – Optional additional information about metadata item. Displayed e.g. in tooltips. Length is not restricted in model.xml.

  • dbname – Used only for metadata items that are somehow represented in database. Following restrictions have to be considered when defining dbname:

  • May contain only letters, digits, underscores '_' and hyphens '-'

  • Length is restricted to 30 characters in case of Oracle and 64 characters in case of PostgreSQL. The allowed length includes also the generated postfixes in some cases, so the postfixes have to be considered when defining metadata as well. E.g. the generated name for a versioned graphical table will be expanded by _GR_H characters, causing maximum allowed value of dbname in metadata to be 25 characters instead of 30

  • Cannot start with LIDS, SAMO, SPATIAL, TMP, SEC, LCS, LOCK

  • label– Used for example for fields in forms. Its length is restricted to 64 characters.

warning

The most of metadata items have their names restricted to 60 characters. Some of them are items of special type – long name metaitems. They enable names up to 120 characters long.

Language Variants​

Metadata items’ names, descriptions and other properties displayed to the end user can exist in different variants corresponding to different languages.

The list of available languages for project metadata is configured in the project section of model.xml:

    <ber:languages>
      <ber:projectLanguage locale="en" name="English"/>
      <ber:language locale="cs" name="Czech"/>
      <ber:language locale="de" name="German"/>
      <ber:language locale="de-CH" name="Schwiizerdütsch"/>
      <ber:language locale="it" name="Italiano"/>
    </ber:languages>

  • projectLanguage - mandatory. It defines the language used for standard metadata files

  • language - zero or more additional language definitions

The resources used by the individual languages are stored in one or more files in CSV (comma-separated values) format.

The files are published as LIDS resources and are registered at the beginning of resource.xml:

  <ber:translationsArray>
    <ber:translation id="tr_water" name="Water category translations">
      <ber:formatArray>
        <ber:format file="translations_water.csv" name="csv" separator="," quote=’"’ escapeChar="\"/>
      </ber:formatArray>
    </ber:translation>
    <ber:translation id="tr_ele" name="Electro category translations">
      <ber:formatArray>
        <ber:format file="translations_ele.csv" name="csv" separator=";"/>
      </ber:formatArray>
    </ber:translation>
  </ber:translationsArray>
tip

Multiple translation files may be specified, their contents will be merged together. In case of a conflict (identical item and property values) the last value defined wins (ordered by the position in translationsArray and by the row order in each file).

Example translations.csv:

item;property;cs;en;de;de-CH
ft_5012100;name;Hlavní řad;Main pipeline segment;Hauptpipelinesegment;Hauptpipelin…
at_5012115;name;Materiál;;Material;Material

The first row contains:

  1. item text (case insensitive)

  2. property text (case insensitive)

  3. one or more locales in format language[_territory] (case insensitive) https://en.wikipedia.org/wiki/Locale_(computer_software)

The following rows contain:

  1. meta item identifier – e.g. feature type ID, attribute ID etc.

  2. meta item text property, like name, description or label.

  3. one or more translations matching the languages listed on the first row

  • if particular language translation is empty, the model language is used

  • the model language can be included here as well for the reference, but it’s ignored by the application. In the first version of implementation the model language string cannot be substituted by the value from the resource

Any additional column that has no title on the first row will be ignored.

warning

The file must be encoded in UTF-8. This may be a problem when editing the file in Excel, so using another tool is recommended (e.g., Notepad++, Google Spreadsheet).

Translatable metadata items​

model.xm

project – name, description

graphicTypeClass – name, description

container, groupContainer – name, description

codelist – name, description

codelist column – name, description

filteredCodeList – name, description

codelistBinding – name, description

interface – name, description

interfaceAttribute – name, description

attachmentType – name, description

graphicType – name

graphicTypeComponent – name

featureType – name, description

  • featureAttribute – name, description

  • graphicTagType – name, description

  • form – name

  • form caption – label

  • formField – label

backdropType – name, description

vicinityMap – name, description

category – name, description

backdropCategory – name, description

role – name, description

relationAssoc, spatialRelationAssoc, featureRefrelationAssoc, detailAssoc – name, description

linearTopologyAssoc, nodeRole, nodeType, edgeRole, edgeType

arealTopologyAssoc, arealLayer

linearTopologyConnection, startRole, endRole

tool.xml

tool – name, description

toolbox – name, description