Catalogs that can be defined within the Studio Desktop are based on single geodatabase table. For any catalog table defined in the Class Configuration, a corresponding schema is stored as well. At runtime, the schema for a catalog is used to assemble the content for the dedicated catalog.

Catalog Tables allow for creating domains and multi-stage (contingent) catalogs. Catalog tables are typically part of the schema of the underlying geodatabase, or at minimum, part of the map where the current layer or standalone table is defined.

All catalog schemas are managed in the configuration using unique names. Within the Catalog Schema Repository, catalog schemas can be registered, modified, or removed.

Catalog Types

There are two types of catalogs, that can be registered at the repository:

•Catalogs based on Lookup-Tables

•Catalogs based on Contingent-Tables

Domain or Lookup Tables

Domain or Lookup Tables are used for the definition of Domain Values. The simpliest lookup table consists just out of a single column, that contains all the domain values.

A lookup table supports the following features:

•Coded Values

•Visibility

•Sort Order

•Favorites

Coded Values

A Lookup Table that supports Coded Values defines two columns, where one columns defines the code (usually a numerical value) and the other columns refers to the corresponding label or title (usually a text value).

Visibility and Historization

Usually, all rows from a Lookup Table are assembled into the corresponding domain catalog. If specific entries shall be part of the domain catalog, but not explicitly selectable from the UI, the visibility for those entries can be defined using an additional column, that contains the values 1 or 0 (or null referring to default).

Sort Order

Domain entries from a Lookup Table can be set in a specific order using an additional column used for sorting. A Sort Order column usually defines numerical values.

Favorite Declaration

Specific Domain entries can be marked as Favorites. A domain entry marked as Favorite will appear in the Favorite List. Favorites are defined using an additional column, that contains the values 1 or 0 (or null referring to default).

Contingent Tables

Contingent Tables are used for the definition of Multistage Catalogs. Multistage or Multilevel Catalogs are used to combine values for a set of attributes, whose values define predefined tuples.

The schema for a Contingent Table consists out of a set of key domains and an optional set of additional domains. The columns for every key and additional domain are part of the schema of the Contingent Table.

Configuration

All Catalog Schemas are made persistent with the application configuration file (default.vgappconf). This is a JSON file that contains the schemas section.

The schemas section in the default.vgappconf is defined as a dictionary of schema names and schema definitions:

 "schemas": {
   "<Catalog Name>": {
     "$type": "<Catalog Type>",
     "table": "<Catalog Table>",
     ...
   }

The following JSON catalog types are currently supported:

•lookupTable - Use this $type for the definition of a domain or lookup table.

•contingentTable  - Use this $type in order for the definition of contingent- or multistage tables.

Domain Table Configuration

Table CAT_LIFECYCLE_STATUS

Table Schema

The Table Schema for this sample catalog is as following:

The configuration entry at default.vgappconf is as following:

  "Lifecycle_Stats": {
      "$type": "lookupTable",
      "table": "CAT_LIFECYCLE_STATUS",
      "column": "STAT_ID",
      "labelColumn": "DISPLAY_NAME",
      "visibilityColumn": "IS_VISIBLE",
      "sortColumn": "SORT_ORDER",
      "favoriteColumn": "FAV_MARKER"
    }

Contingent Table Catalog Configuration

Sample 1 "Pipeline Types"

Table CAT_PIPE_TYPES

Table Schema

The Table Schema for this sample catalog is as following:

The configuration entry at default.vgappconf is as following:

  "PipeTypes": {
      "$type": "contingentTable",
      "table": "CAT_PIPE_TYPES",
      "domains": {
        "$type": "contingentProperties",
        "$values": [
          {
            "column": "LT_CODE",
            "labelColumn": "LT_NAME",
            "sortColumn": "LT_SORT"
          },
          {
            "column": "MAT_CODE",
            "labelColumn": "MAT_NAME"
          },
          {
            "column": "PROF_DIM"
          }
        ]
      },
      "additions": {
        "$type": "contingentProperties",
        "$values": [
          {
            "column": "SAP_TP_NO"
          }
        ]
      }
    }

This sample defines that schema for a contingent catalog table structured as following:

<pre> Pipeline +- Type [LT_CODE] | +- Material [MAT_CODE] | +- Profile Diameter [PROF_DIM] => SAP Technical Place [SAP_TP_NO] </pre>

The hierachical catalog is defined using the LT_CODE column, for root items, entries from MAT_CODE column are used as children at level 1 and entries from the PROF_DIM column are used as leafs at level 2

The nodes defined by the LT_CODE and MAT_CODE columns are defined as coded values where the LT_CODE and MAT_CODE columns refer to the data (or code) and the LT_NAME and MAT_NAME columns contain the titles (or labels) for this nodes.

The column SAP_TP_NO is defined, when a proper PROF_DIM leaf is selected.

Sample 2 "Address Navigation"

Table by_adressen

The configuration entry in default.vgappconf is as follows:

   "PipeTypes": {
      "$type": "contingentTable",
      "table": "by_adressen",
      "domains": {
        "$type": "contingentProperties",
        "$values": [
          {
            "column": "dstr_id",
            "labelColumn": "distr"
          },
          {
            "column": "cty"
          },
          {
            "column": "strcode",
            "labelColumn": "str",
            "visibilityColumn": "str_hist"
          },
          {
            "column": "hnr",
            "sortColumn": "hnr_sort"
          }
        ]
      }
    }

This sample defines that schema for a contingent catalog table structured as follows:

<pre> +- District [dstr_id] +- City [cty] +- Street [strcode] +- House No [hnr] </pre>

Storage locations for Catalog Tables

With no further information, catalog tables are resolved from the current map by default. In which, the given catalog table name is either the name of the layer or standalone table from the TOC, or the given name is equal to the table name behind the resolved map member.

The catalog tables from the configuration can be resolved using relative and absolute item URLs to local databases that are part of the current project.

Catalog tables that refer to feature layers URLs can also be used.

Queryable Catalogs

Any catalog that is defined using the schema from the application configuration is defined as a Queryable Catalog by default. This means the table is located and queried (the first time) when items are fetched. This is in contrast to domains and contingent values that are popuplated when a feature or object class is loaded. This means that domains and contingents can be queried only when the feature or row is opened within the Attribute Form.