Rendering Functions

The renderer plugin code must declare a single function that returns an object with one of these functions in it:

Both synchronous getGeoJSON and asynchronous getGeoJSONAsync functions return an object with GeoJSON data in the bodyproperty:

  contentType: "application/vnd.geo+json; charset=utf-8",
  body: geoJsonData

Only one of these functions must be declared. If both are present, GeoJsonDataSource throws an exception.

These functions accept a single parameter that is an object containing raw source data and provides access to various helpers and utilities.

Typically, you should use the synchronous function to convert raw data to the GeoJSON format. If your plugin can perform any asynchronous tasks, then you must implement the getGeoJSONAsync function. Examples of asynchronous tasks are HTTP requests to external APIs or usage of geometry data providers. To see a sample implementation of the Data Inspector Library's sync and async rendering functions, see Plugin Examples.


The getGeoJSON and getGeoJSONAsync functions accept a single params parameter. It is an object with these properties in it:

  • params.decodeResult { object }: The decodeResult object provides access to raw data and has two properties:

    • partitionId {string}: partition ID
    • data { object }: raw partition data decoded by protobuf
  • params.logger { object }: The GeoJSON data source uses a logger that implements the ILogger interface and is completely set up to log information to the console. The logger provides the following functions:

    // trace
    logger.trace("Trace message");
    // debug
    logger.debug("Hello again log");
    // log
    logger.log("Hello log");
    // info"Hello again log");
    // warning
    logger.warn("Hello again log");
    // error
    logger.error("Hello again log");

    By default, the log level is set to Warn, and you can change it at any point after the GeoJsonDataSource instance has been created:

    // Possible log levels are: Trace = 0, Debug = 1, Log = 2, Info = 3, Warn = 4, Error = 5.
    geoJsonDataSource.rendererPluginLogger.level = LogLevel.Info;

    or in the plugin code:

    params.logger.level = 0;

    You can also pass multiple messages to any of the logger's methods:

    logger.log("Log message", "Another log message", "One more log message");
  • params.layer { object }: The layer object contains all layer properties. For a full list of layer properties, see Catalog2Layer.

  • params.mapUtils { object }: The mapUtils object provides a set of helpful converters that can be used while decoding data into GeoJSON. For more information, see MapUtils.

  • params.geometryDataProviders { object }: The geometryDataProviders object has async getters that are used to access various geometry data providers to map data. Currently, there are two data providers available:

    • getSegmentAnchorDataProvider: an asynchronous method whose promise resolves with a SegmentAnchorGeometryDataProvider instance.
    • getRoadSegmentsDataProvider: an asynchronous method whose promise resolves with a BaseRoadSegmentsDataProvider instance.

Referencing Source Data in GeoJSON

Renderer plugins work as converters from the source data format to GeoJSON. While a plugin can put some additional data payload to a GeoJSON feature's properties, it is not the best place to store original raw data. The intended use of properties is to configure visual styles and provide human-readable tooltips.

A proper way to provide access to source data is to map a GeoJSON feature (the output of the plugin) to a source data object (the input for the plugin). This can be done by providing the properties.protobufRef property for a feature. It contains a path to the original raw data property that this feature visualizes such as prop.someArray[34].prop2.

You can see the usage of properties.protobufRef in the above-mentioned sample plugin for visualizing HMC topology data. The source data root object has two arrays - node and segment, and the corresponding protobufRef properties are node[12] and segment[43].

If you look at the speed limit sample plugin, it generates a bit deeper path to the source data property: speed_limit[2].segment_anchor_index[137].

When you select a certain feature on the map, the Data Inspector Library's DataInspector widget highlights the selected feature and moves focus to the corresponding source data node in the DecodedPanel, as in the figure below:

Source Data Node
Figure 1. Source Data Node


According to the GeoJSON specification, FeatureCollection cannot contain properties. So, for visualization needs, you can specify identical protobufRef paths for multiple features.

Version Dependency Resolution

The Data Inspector Library has a built in mechanism for version dependency resolution between different catalogs and the corresponding versions of regional HERE Map Content (HMC) catalogs (Japan, China, or rest of the world) in the Data Inspector. This works for visualizing data like traffic or speed limits that contains no road geometry information.

For example, speed limit lines from the HMC Navigation Attributes layer must be mapped to road geometries from the HMC Topology Geometry layer. The new mechanism, in this case, aligns the versions of speed limit lines data and road geometry data to omit any errors and get the most accurate visualization. The Data Inspector reads layer dependencies and automatically retrieves geometry information from the corresponding regional HMC catalog.

Note that if you have no access permissions to the necessary HMC catalog, or the correct HMC is not defined in the dependencies of the layer to be visualized, the most recent HMC version is used by default (China or rest of the world).

For more information on how to set layer dependencies, see the CLI Developer Guide.

results matching ""

    No results matching ""