2

When using a protobuf schema that contains messages with fields of types like int64/sint64 and trying to visualize that with a custom renderer plugin, the decoded data that is passed to the renderer plugin contains fields with type number instead of Long from https://github.com/dcodeIO/Long.js/. I've been able to fix this in my local webapp by patching GeoJsonDataStoreHelper.js with

var Protobuf = require("protobufjs");
var Long = require("long");
Protobuf.util.Long = Long;
Protobuf.configure();

Is there anything I can do to fix this without changing the code of the visualization library? Otherwise rendering on OLP won't work.

cwde
  • 214
  • 1
  • 10

2 Answers2

2

at this moment you could fix that only temporarily like you did it by modification of geojson-datasource code directly. We are working on the proper support of int64 in our geojson package.

0

It is not available directly in GeoJSON plugin but is used in MapUtils that is passed to that plugin for some specific usecases. Basically in the renderer plugin, mapUtils is available as 4th argument to the toGeoJSON method https://developer.here.com/olp/documentation/data-visualization-library/dev_guide/pages/renderer-plugins.html

Reference to the corresponding class https://developer.here.com/olp/documentation/data-visualization-library/api_reference_typedoc/modules/_here_geojson_datasource.maputils.html

ichow
  • 131
  • 4
  • I already use mapUtils, but it does not help me with the problem that the decodedData argument already contains JavaScript numbers for fields that are specified as int64 in my .proto files. They should be decoded as Longs. Any hint on how to fix this? As decoding is not done in the renderer, I cannot fix the wrong int64 conversion. – cwde Sep 05 '18 at 09:11