Overview of Map Architecture and Structure
HERE Lanes consist primarily of road networks represented by the Topology Models enriched by numerous attributes. Layers in Catalogs list the separate memory-optimized layers containing the map data based on these models. This data is delivered using the Native (Protobuf) Publication Format, Tiling, Versioning, and Compression to further optimize the modular availability of this data. For more information, see the sections below.
Topology Models
HERE Lanes comprises various layers based on the Road Centerline Model and Lane Model. The layer in the Road Centerline Model contains road topology and geometry. Layers in the Lane Model contain lane topology, geometry, and lane-level attributes.
The "Logical Data Model" part of this document describes the logic underlying these topology models and the various attributes enriching them.
The "Format Specification" part of this document describes the Protocol Buffer implementation of these topology models and their attributes.
Layers in Catalogs
The HERE Lanes Catalog includes logical layers to optimize storage space and update efficiency for common use cases.
Native (Protobuf) Publication Format
The HERE Native schema for HERE Lanes is published as files using Google's Protocol Buffer data format for its balance of size efficiency, support for schema evolution, language support and general ease of use.
Proto3 Syntax
The current version of HERE Lanes uses the Proto3 syntax dialect. This newer (circa 2015) dialect is an enhancement to the existing Proto2 syntax, offering new language features and the potential for broader client language support. The Protocol Buffer runtime software supports both dialects in parallel and encoding formats are compatible (with some limitations). Support for the Proto3 syntax was introduced in the Protocol Buffer Runtime v3.0.0, so this is the minimum version required to work with the current HERE Lanes data.
The choice to move to Proto3 syntax was driven by the new language features and opportunity created by switching to an entirely new schema design a while back, which freed us from the need to maintain backwards compatibility with the legacy format.
Native (Protobuf) Schema Organization
Each layer in HERE Lanes exposes a specific type of data. As such, each layer has its own unique top-level message type. For example, tiles in the road-topology-geometry layer contain a single top-level TopologyLayerTile message. Each layer has top-level (and other) embedded messages packaged together in layer-specific .proto schema files. For example, the topology layer messages are in the "layer-topology.proto" schema file.
Where there are common message structures reused across layers, we make use of the Protocol Buffer "import" facility to access them from common.proto files. For example, most layer schema files will import the common.proto file with common topology referencing messages.
The schema files containing all the Protocol Buffer message definitions required for a given layer are packaged into a single zip archive and also published in the catalog. This zip archive is available as a non-tiled (generic) partition in the schema layer associated with that data layer in metadata for the catalog.
Native (Protobuf) Usage
In general we follow the Google Protocol Buffers Style Guide.
Tiling
Map data is partitioned using the HEREtile Tiling Scheme and published at level 14.
Versioning
The HERE Lanes catalog (a unified group of data layers) is published as version-controlled "snapshots". A single catalog version number is assigned to each dataset including the entire map across all layers and tiles. Every map update increments the overall map version number. Map layers and tiles can then be retrieved by version with internal consistency across all published content layers and tiles.
Compression
Published map tiles are compressed with the ZIP compression scheme. HTTP requests for these files will be returned with the HTTP headers Content-Type "application/x-protobuf" and Content-Encoding "gzip". In addition, the catalog layers that use compressed tiles will have the same "Content-Type" and "Content-Encoding" values specified in the layer metadata.
