Manage a composite layer

The HERE platform supports the use of composite versioned layers. Composite layers let you avoid data duplication by structuring a data dependency.

For example, you can use composite layers to create a new product catalog by patching in partitions from an existing catalog, while leaving the rest of the map unchanged.

Overview

A composite versioned layer consists of two or more versioned layers, where one extends another. The dependency is defined during layer creation.

Partition data is published to the extension layer. When partitions are retrieved from the extension layer, overridden partitions are served from the extension layer, while unchanged partitions are served from the base layer.

📘

Note

• super denotes the layer of a catalog being extended
• extension denotes the layer in the composite catalog that extends super catalog

Creation of composite versioned layer

The layer must be created with the extends field pointing to the super layer for the extension.

{
    "id": "layer",
    "name": "Layer",
    "summary": "Layer summary",
    "description": "Layer description",
    "partitioning": {
        "scheme": "heretile",
        "tileLevels": [
            12
        ]
    },
    "contentType": "application/json",
    "billingTags": [
        "Billing tag"
    ],
    "layerType": "versioned",
    "versionedLayerProperties": {
        "extends": {
            "catalogHrn": "hrn:here:data::olp-here:super-catalog",
            "layerId": "layer",
            "baseVersion": 0
        }
    }
}

Publishing to composite versioned layer

Composite layers are published in the same way as other layers, but they must include version dependencies in the response.

{
  "details": {},
  "layerIds": [
    "layer"
  ],
  "versionDependencies": [
    {
      "direct": true,
      "hrn": "hrn:here:data::olp-here:super-catalog",
      "version": 1
    }
  ]
}

Partitions retrieval of composite versioned layer

You can retrieve composite layer partitions in the same way as normal versioned layers.

There is a context parameter in the partitions endpoint of a metadata service that allows you to define the context of retrieval.

• default is the default value if none is given. For composite layers, the partitions retrieval is done for both layers current and the layer it extends. For normal layers, this is the only valid context.
• extension only retrieves partitions for the extension layer.
• super only retrieves partitions for the super layer.

Changes retrieval of composite versioned layer

You can retrieve composite layer changes in the same way as normal versioned layers.

• default is the default value if none is given. For composite layers, the changes retrieval is done for both layers current and the layer it extends. For normal layers, this is the only valid context.
• extension only retrieves changes for the extension layer.
• superonly retrieves changes for the super layer.

Rebasing of composite versioned layer

During publication, the base version of a super catalog is specified for a new commit to the composite versioned layer. Rebasing is a publication, when the specified version is higher than the one is used for the latest commit. It's publisher responsibility to make sure the partition overrides applied previously, adapted to the new version of the extended catalog.