Permanent ID concept in HERE Data

Symptoms
--------

Customers may experience one or more of the following:

A map object ID appears unchanged across multiple map releases.
The same numeric ID is observed on different object types and is assumed to be a duplicate.
A permanent ID changes after a map upgrade, administrative boundary restructuring, or data model migration.
A newly created object appears with a temporary or non-permanent ID in a specific release.
Applications using stored object IDs cannot match an object after certain map conversion or restructuring activities.
Questions arise regarding the valid numeric range and uniqueness of HERE map object identifiers.

Answer
------

Permanent IDs (PVIDs) are designed to provide stable identification of map entities across HERE map releases. A permanent ID is globally unique within its object type, such as a Link, Node, Lane, Face, or Point Feature. However, the same numeric value can exist in different object types because uniqueness is enforced within each object category rather than across all map objects.

In specific situations, including map upgrades, migration to different map architectures, or administrative restructuring, a permanent ID may change. This behavior is expected and does not indicate data corruption.

Applies To
----------

HERE Map Data Products
HERE RDF (Relational Data Format)
HERE Base Map Content
HERE Navigation and Routing Data

Entities That Use Permanent IDs
-------------------------------

The following map entities typically use permanent identifiers:

Lane
Face
Point Features
Administrative Areas
Built-up Areas
Districts
Complex Features
Complex Administrative Areas
Complex Intersections
Complex Roads

Examples of permanent identifiers in RDF include:

Address Point ID
Admin Place ID
Association ID
Building ID
Cartographic Feature ID (Carto ID)
Complex Feature ID
Condition ID
Country ID
Face ID
Feature Point ID
Lane ID
Lane Navigation Strand ID
Link ID
Name ID (with limited exceptions)
Navigation Strand ID
Node ID
POI ID
Road Link ID
Sign ID
Zone ID

Root Cause
----------

Permanent IDs are generated to identify map entities consistently throughout the map production lifecycle. The identifier allocation process ensures uniqueness within an object type and supports long-term reference to specific map features.

In rare production scenarios, updates may initially be created in a database copy rather than directly in the live production database. During this process, temporary non-permanent identifiers can be assigned before a permanent identifier becomes available in a future release.

Numeric Range and ID Structure
------------------------------

Most map object permanent identifiers use 32-bit integer values and generally fit within an N(10) numeric scheme. Some object types are exceptions and may use larger ranges. For example:

Lane ID: commonly stored as N(12)

The identifier space is separated into permanent and non-permanent ranges:

### Permanent Range

Used for production map entities intended to remain stable across releases.

### Non-Permanent Range

Used in exceptional workflows where content is generated outside the live production database. These identifiers may later be replaced by permanent IDs in subsequent releases.

Important: No cross-reference is provided between a temporary non-permanent ID and the permanent ID assigned later.

Impact
------

Applications that persist object references should understand the following:

Permanent IDs are generally stable across releases.
Stability is expected within the same map architecture and object lifecycle.
Administrative restructuring or major map migrations can result in ID changes.
Non-permanent IDs should not be treated as long-term references.
Object type must always be considered together with the ID value when determining uniqueness.

Expected vs. Unexpected Behavior
--------------------------------

### Expected Behavior

Permanent IDs remain stable across normal map updates.
Identical numeric values may exist for different object types.
ID changes occur after major map migrations or administrative restructuring.
Temporary non-permanent IDs appear in limited exceptional production scenarios.

### Unexpected Behavior

Assuming a permanent ID is globally unique across all object types.
Using non-permanent IDs as long-term references.
* Expecting a mapping table between temporary IDs and future permanent IDs.

Recommended Actions
-------------------

1. Store both the object type and the permanent ID when maintaining references.
2. Validate whether an ID belongs to a permanent or non-permanent range before using it as a long-term key.
3. Review object mappings after major map architecture upgrades or administrative boundary changes.
4. Avoid building business logic that assumes all permanent IDs remain unchanged indefinitely.
5. Reconcile downstream systems when consuming releases affected by restructuring events.

Keywords / Tags
---------------

Permanent ID, PVID, RDF, Link ID, Node ID, Lane ID, Face ID, POI ID, Admin Place ID, Object Identifier, HERE Map Data, Non-Permanent ID, Map Release, Administrative Restructuring, Feature Identification