The Data Inspector provides rendering settings and an embedded JS editor that you can use to develop your custom renderer plugin code.
With these tools, you can create, modify, and instantly run custom GeoJSON renderer plugins for default layer schemas (provided by the HERE Open Location Platform (OLP)) and your custom layer schemas through:
OLP Portal Data Inspector (accessible from the Inspect tab on the layer details' page in the OLP Portal
For this option to work, you do not need to install Node.js, additional Data Inspector Library modules, or any third-party components. Just log in to the OLP Portal with your OLP credentials.
Local Data Inspector
For this option to work, you need to install Node.js and the Data Inspector Library along with the example applications. With that done, you can see the
geojson / DI / pluginexample application that showcases the implementation of a sample renderer plugin.
The Data Inspector IDE enables you to solve the following typical use cases:
In this case, for a custom layer schema that has no GeoJSON plugin, you are provided with a predefined plugin JS template. The template contains detailed inline instructions where to put your code in the embedded editor.
When you are working with the data in a catalog layer and need to temporarily change the existing visualization to answer your specific questions about the data.
In this case, you can modify the renderer plugin bundled with the original layer schema in the editor and run the code right away to inspect the output in the Data Inspector's map view.
Later, once you are satisfied with the plugin’s behavior, you can download the plugin locally, bundle the plugin with your schema, and publish the schema to OLP to use it with the layer. To create or extend a schema, a Maven Archetype is provided. For more information, see Create and Extend Schemas.
The Rendering Settings panel in the Data Inspector allows you to work with layer schemas and renderer plugins.
The Schema field shows the data schema that is currently assigned to a catalog layer.
By default, the original schema assigned to a catalog layer is loaded, along with the bundled renderer plugin (if available).
You can load your custom data schemas as a ZIP archive by clicking the More button on the right and selecting Open schema.
If you load a schema without a renderer plugin, no data is visualized, and the Rendering plugin field shows Missing. To fix this, you can do one of the following:
Develop your own renderer plugin: For this, click the Create plugin button to open the editor and type your code.
Reset your custom schema: For this, click the More button and select Reset to load the original schema assigned to the selected layer.
Load another data schema with a bundled renderer plugin.
The Rendering plugin field informs you about the renderer plugin that is currently applied for the selected data schema:
Found: Tells you that a renderer plugin has been detected in the currently loaded schema and applied.
Custom code: Tells you that the currently loaded renderer plugin has been modified.
Missing: Tells you that no renderer plugin bundled with the currently loaded schema has been found.
The editor enables you to load your local plugin JS file into the Data Inspector to run it on the layer data that has been already loaded into the Data Inspector. For this, click the More button on the right and select Open plugin. To return to the renderer plugin bundled with the currently loaded schema, select More > Reset.
To modify your plugin code, click the Edit plugin button to open the embedded editor. Once satisfied with the results, you can download the modified JS file to save your code by selecting More > Download.
You can open the plugin code editor by clicking the Create/Edit plugin button in the Rendering Settings panel.
- Extended code-editing functionality
- Live JS syntax highlighting
- JS file drag-and-drop
- Code auto-completion
- Syntax error indication
If you create a renderer plugin from scratch, the editor contains a plugin JS template with detailed inline instructions. To see a sample implementation of the Data Inspector Library rendering functions and style properties, see Plugin Examples and Style GeoJSON Visualization.
You can also drag-and-drop your local plugin JS file directly into the editor area. In this case, the file is loaded into the browser memory for the duration of the catalog connection session.
To launch your plugin code, click the Run button above. The layer data is rendered in the Data Inspector's map view. Once satisfied with the results, you can download the modified JS file to save your code with the Download button).
While developing your plugin, any errors that may occur can be viewed in your browser's developer tools.
Note: Restoring Unsaved Plugin Code
The renderer plugin editor automatically saves your plugin code to your browser's local storage. So, in case of browser crash, or if you accidentally leave or reload the plugin editor page with unsaved changes, you can restore your code from the previous session. The browser additionally prompts you about unsaved changes in case you reload or leave the plugin editor page.
You can debug renderer plugin JS code with your browser's built-in developer tools. To launch developer tools on most popular browsers, you can use the
Because plugin code and its evaluated object are not accessible through a global scope object or the
<script> tag, you need to add
debugger statements to those lines in code on which you want the debugger to pause execution. After you open the developer tools and rerun the plugin code (by selecting a new tile or clicking Run), the browser starts debugging at the first active breakpoint it encounters. For more information on the JS
debugger statement, see MDN Web Docs.
Each time you update code, the renderer plugin object is dynamically recreated by the Data Inspector Library with the JS
eval function. That is why, if you manually place breakpoints at certain lines using a browser's developer tools, the breakpoints become invalid after you update the plugin code. Only breakpoints created with
debugger statements persist, so make sure that you remove them in the production version of your plugin code.