Convention, not a standard · Esri Utility Network semantics in open files · no ArcGIS lock-in · starter for ~100–1000 meter LV villages
IEEE Smart Village Technology Committee uses a GeoJSON + JSON pack so a mini-grid can be loaded offline into the Village Simulator, traced by feeder, and later bound to read-only metering application programming interfaces (APIs). Ideas borrow from Esri’s Utility Network (devices, junctions, lines, subnetworks, associations) without requiring Esri software.
This pack is a convention, not a standard. Esri Utility Network is Esri’s schema; the ISV/open pack is GeoJSON layers plus associations, not an OGC standard.
Living schema + demo pack:
smart-village-simulator/villages ↗
(_schema/, _template/, demo-lv/). This page is the human map of that contract.
Geometry stays in files. Telemetry stays on demand by asset id. A thousand-meter village must not dump a year of kWh into GeoJSON. Map packs travel offline (USB, laptop, no cloud). When an asset is selected, a feed registry resolves that id to a read-only API or message topic.
How this split was defined: a Technology Committee Digital Twin minimum — what you need to open a village offline in the Village Simulator, pick a feeder, and reach meters by stable id. Sized for ~100–1000 customer meters. Contract lives in smart-village-simulator/villages/_schema.
Sample layers: the simulator ships villages/demo-lv/ with at least one feature in every Essential file and every Nice-to-have class listed below (junctions, enclosure, disconnect, recloser, neutral, terminals, containment / attachment, and feeds/registry.json). Copy that pack or start from villages/_template/.
Sized for a schematic village on the order of 100–1000 customer meters (one island, a few feeders). Scale by repeating feeders and service laterals — do not invent a transmission model.
village.json — site id, name, WGS84 origin, bbox, statusnetwork/subnetworks.geojson — island + each feedernetwork/structure.geojson — poles (cabinets optional here)network/electric-lines.geojson — trunk / primary / secondary / servicenetwork/electric-devices.geojson — meters, transformers, generation or station head, EMS cabinets if usednetwork/associations.json — connectivity edges joining those idsid, assetClass, assetGroup, subnetworkIdnetwork/electric-junctions.geojson — bus, splice, tap, service_point (Esri Junction class)neutral line class; multi-port terminals[] on transformers and EMSphase, nominalKv, ratedA, globalId (UUID)feeds/registry.json — Live Twin API bindings by asset id (not required for a pure Digital Twin)This is a convention, not a standard — not OGC, not a certified profile.
The essential / nice-to-have split above is not an Esri label — Esri’s Utility Network does not publish that binary list. We borrow semantics, not ArcGIS files. Esri domain networks use Device, Line, Junction, Assembly, and SubnetLine classes, plus a Structure network and associations (connectivity, containment, attachment). See Esri’s domain networks ↗ and structure network ↗.
Maps cleanly: our electric-devices ≈ Device (+ some Assembly roles); electric-lines ≈ Line; structure ≈ StructureJunction; subnetworks ≈ subnetwork / feeder identity (Esri also generates SubnetLine); associations.json ≈ association table.
Deferred to nice-to-have for field practicality: a full Esri build expects Junction features wherever lines meet, Assembly containers, StructureLine / StructureBoundary, terminals on multi-port devices, and systematic containment / attachment. We allow those as richer packs so brownfield teams can ship a traceable meter map before digitizing every splice and vault.
villages/<siteId>/
village.json
network/
subnetworks.geojson
structure.geojson
electric-devices.geojson
electric-junctions.geojson # optional
electric-lines.geojson
associations.json
feeds/
registry.json # Live Twin bindings; may be empty for Digital Twin only
| Field | Required? | Notes |
|---|---|---|
id | Yes | Stable string. Same id used in associations and in API bindings. |
assetClass | Yes | e.g. meter, pole, xfmr, trunk, feeder |
assetGroup | Yes | structure · electric_device · electric_junction · electric_line · subnetwork |
subnetworkId | Yes (network features) | Feeder or island id for filter / LOD. |
globalId | Recommended | UUID if ids are site-local. |
terminals | Nice-to-have | Multi-port devices (transformer H/X, EMS north/south). |
label, phase, status | Recommended | Human label; A/B/C or ABC; in-service flags. |
associations.json holds the graph. Geometry does not imply connectivity by itself.
fromId → toId (optional terminals, phase, subnetworkId)Trace: walk connectivity within one subnetworkId, then climb toward the island controller. See _schema/connectivity-rules.json in the simulator repo.
| LOD | When | Load | API |
|---|---|---|---|
| 0 | Region / multi-site | village.json bbox + pin | none |
| 1 | Village open | subnetworks + trunk lines + poles | optional feeder rollups |
| 2 | Feeder selected | that feeder’s devices, junctions, laterals | EMS / feeder-head meter |
| 3 | Meter / house selected | service laterals already in pack | that meter’s reads only |
feeds/registry.json maps asset id → feed descriptor (URL template, topic, auth ref). Secrets stay out of the pack. Any metering vendor API is welcome; Technology Committee adapters grow over time (including SparkNet-HTTP, GroundBolt-class site stacks, MeshEMS message topics, and others).
village.json status: hypothetical · survey · as-built · unverified. Mock villages built in simulator BUILD mode and real field maps should live in separate stores until a review migrates a pack.
This pack is one village (about 100–1000 customer meters). A country electrification map is a different scale. NRECA International’s public note on the Liberia National Electrification Analysis: Mapping a Path Towards Universal Access ↗.
That page says the work was funded by the World Bank, with Liberia’s Rural and Renewable Energy Agency and the Ministry of Mines and Energy. The platform holds Liberia Electricity Corporation distribution and transmission (existing and planned), plus structures and roads, and compares densification, intensification, and expansion for on-grid and off-grid. This wiki has not checked the file format, whether it follows a Utility Network schema, or whether any layer is an ISV village pack.
Another country-scale layer, not a village pack. The IEA commentary Africa’s electricity access planners turn to geospatial mapping (26 March 2024) describes an open model, with MIT, UMass Amherst, and e-GUIDE, released as Open Energy Maps. It uses satellite images and building footprints, trained where a utility meter can be matched to a building. The published maps name Ghana, Senegal, and Uganda. The commentary says the model picked which buildings have electricity with over 80% accuracy, and cut the error on building demand estimates by 40% against the tools planners were using. Night-time lights, the older proxy, score about a square kilometre and miss a small off-grid house.
Planners use that building layer to choose grid extension, a mini-grid, or a standalone system, and to size the supply. This pack starts after that choice. The feeder, the meter, and the disconnect live here. The join is a building and a meter at that building: the polygon stays in the country file, the kWh stays a read by asset id. An estimated demand is not a meter reading. This wiki has not opened the polygon files, and has not checked that any of them is an ISV village pack.
Village Simulator hub · villages schema ↗ · OpenAMI · TC 2.0 review (SparkNet-HTTP / GroundBolt feed binding) · Nairobi workshop · GitHub issue #65 ↗