4
0
Fork 0
The work done for the proof of concept for the information container
  • Python 33.8%
  • C# 20.3%
  • HTML 19.6%
  • CSS 13.8%
  • JavaScript 12.5%
Find a file
2026-09-10 10:02:06 +02:00
BC_Container_Reader Added tennet_id and single geometric file 2026-09-10 10:02:06 +02:00
BC_Tennet_RML Added tennet_id and single geometric file 2026-09-10 10:02:06 +02:00
.gitignore Initial_push 2026-08-04 15:04:16 +00:00
LICENSE Initial commit 2026-08-04 14:49:01 +00:00
README.md Added background info to readme 2026-08-06 11:22:36 +02:00

GeoJSON → Information Container POC

This POC was developed by BIM-Connected and BAM to explore how GIS data (GeoJSON) could be automatically translated into TenneT's information container format. For their projects, TenneT is exploring data exchange through this container structure, but that data commonly originates from GIS systems. Manually converting between the two is slow and error-prone. The goal of this POC was to test whether that translation could be automated, and whether the resulting container could then be visualized to verify the conversion — as a first step towards smoother, more reliable data collaboration between GIS and data-container-based workflows.

⚠️ Proof of concept — not production software. This repository contains a small, experimental proof of concept built to test whether GIS data (GeoJSON) could be parsed into a structured "information container" and subsequently visualized. It is not a generic GeoJSON toolchain. The RML mapping and the geometry parser were written and reverse-engineered against one specific set of GeoJSON exports (TenneT cable and area/"vlakken" data) and will most likely not work correctly on other GeoJSON files without changes to the mapping and/or parsing logic. Field names, geometry assumptions and the OTL vocabulary used here are all tailored to that specific source data.

What's in here

The repo contains two separate projects that together form a small pipeline: one parses GeoJSON into an information container, the other is a first POC for visualizing the result.

GeoJSON file(s)  ─▶  BC_Tennet_RML  ─▶  otl_export.zip (information container)  ─▶  BC_Container_Reader
                     (parsing)          (Alphanumeric / Geometric / Documentation)      (visualization POC)

1. BC_Tennet_RML — GeoJSON → information container (parser)

A small Python/Streamlit app that takes one or more GeoJSON files and converts them into an "information container": a zip file with the triples (RDF/Turtle) describing the parsed assets, split into the folders Alphanumeric/, Geometric/ and Documentation/.

What it does:

  • Runs each uploaded GeoJSON file through RMLMapper using mapping.ttl to produce OTL (TenneT object type library) triples for cables, substations, cable circuits ("hartlijnen") and work areas ("vakken").
  • Separately reads the raw geometry from the GeoJSON, converts it to WKT (this conversion is hand-written, not generated by RML) and writes it out as its own geometry graph per input file.
  • Bundles everything into a single downloadable otl_export.zip, structured as:
    • Alphanumeric/centrale_otl_export.ttl — the OTL triples for all uploaded files combined
    • Geometric/<filename>_geometry.ttl — one geometry file per GeoJSON input
    • Documentation/ — currently an empty placeholder folder

This is the "information container" the second project reads.

Requirements

  • Python 3.14+
  • Java (required by RMLMapper — the .jar is included in the project)
  • uv (recommended) or plain pip

Running it

cd BC_Tennet_RML

# using uv
uv sync
uv run streamlit run main.py

# or using plain pip
pip install -e .
streamlit run main.py

This opens a browser page where you can upload one or more GeoJSON files. rmlmapper-8.1.0-r380-all.jar and mapping.ttl must stay next to main.py — the app looks for them relative to the script.

Known limitations

  • Only understands the specific GeoJSON property structure used by the source cable/area exports it was built for (e.g. properties.id, properties.tennet_id, properties.label, properties.kabel_naam, properties.voltage, properties.zone). Other GeoJSON files will likely produce empty or incomplete output.
  • mapping.ttl covers four object types only: cables, substations, cable circuits ("hartlijn") and work areas ("vakken"/"vlakken"). It was not built to be a general-purpose RML mapping.
  • The WKT geometry conversion is a manual reimplementation of the GeoJSON geometry spec and hasn't been tested outside the sample data it was written against.

2. BC_Container_Reader — visualization POC

A Blazor WebAssembly (hosted) application intended to read the information container produced by BC_Tennet_RML and visualize the parsed cables/areas on screen, as a way to prove that the parsed data is correct and usable.

Current state: this project is a bare starting scaffold (default Blazor WASM-hosted template) — the actual container reading and visualization logic still needs to be built out. It's included here to show the intended second half of the pipeline and as a starting point, not as a finished viewer.

Requirements

  • .NET 10 SDK

Running it

cd BC_Container_Reader
dotnet run --project BC_Container_Reader

Then open the URL shown in the console (e.g. https://localhost:7239).


How the two projects fit together

  1. Export/obtain a GeoJSON file with cable or area ("vakken"/"vlakken") data in the same shape the mapping expects.
  2. Run BC_Tennet_RML, upload the GeoJSON file(s), and download the resulting otl_export.zip information container.
  3. Open/extend BC_Container_Reader to load that container and visualize the geometry, to confirm the parsed data is correct.

Get in touch

Interested in this approach or thinking about a similar solution for your own GIS/GeoJSON data? We're happy to talk through how it works, share what we learned building this POC, and help with adapting or implementing something like it for your use case. Feel free to reach out:


Disclaimer

Both projects were built quickly to test one specific idea and are shared here as-is for reference. Expect rough edges: minimal error handling, hard-coded assumptions about input data, no tests, and (for the visualizer) unfinished functionality. Contributions or forks that generalize the mapping/parsing to other GeoJSON schemas are welcome, but that was explicitly out of scope for this POC.