Lighting Asset Inventory & GIS Integration

A municipality's street lighting budget is only as good as its knowledge of the assets it owns. In practice the conversion decision is usually taken without an inventory — and once it is taken, whether the savings actually materialised can no longer be established.

Verigo does not work on the hardware side of this. It produces the spatial data layer underneath: the pole and luminaire inventory captured in the field, the road geometry a lighting-class calculation needs, and the integration that connects both to the organisation's GIS.

Four questions that go unanswered

When a lighting conversion is discussed, almost no organisation can answer these four questions from documentation:

• How many poles are there, where, and who owns them?
• What luminaires are on them, at what wattage, and how old?
• Which panel feeds which pole, and what is the connected load?
• Which street requires which lighting class?

These are not rhetorical. Each is an input to a tender document, a savings calculation and an acceptance measurement. While they are unanswered, competing bids are not comparable.

Inventory is a legal obligation, not a preference

The Turkish General Lighting Regulation requires the existing situation to be established when lighting assets are transferred, and the inventory to be updated after acceptance of new installations; pole number, luminaire wattage and count, and meter details are reported to the distribution company and TEDAŞ.

This became heavier in 2026: the lighting deduction from municipalities' share of general budget tax revenues rose from 20% to 60% for metropolitan municipalities. For the detail and the sources see the regulatory section of our smart street lighting guide.

What we deliver

• Pole and luminaire inventory — a georeferenced point layer with the attribute model below and a photo reference on every record
• Electrical hierarchy — panel, feeder and meter relations; total connected load per panel
• Road geometry and sections — width, lane count, surface and conflict areas; the input to an EN 13201 class calculation
• Proposed lighting class — an M/C/P class assigned to each road section using the CEN/TR 13201-1 weighting method
• M&V baseline — verified luminaire count, measured power and operating hours derived from the astronomical calendar
• GIS delivery— GeoPackage / PostGIS schema, OGC WMS/WFS services, CSV; mapped onto the organisation's existing city information system schema
• Raw data — LAS/LAZ point cloud and georeferenced 360° panoramic imagery

The data model: what belongs in a lighting asset record

The list below is the minimum attribute set required by both an EN 13201 class calculation and an IPMVP baseline. You can copy it directly into a specification.

Download the inventory template as CSV — no registration, direct download.

Field method

An inventory is not a form filled in by walking to each pole; that method is both slow and not repeatable. Verigo produces the data by measuring it:

• Vehicle-based mobile mapping — simultaneous LiDAR point cloud and 360° panoramic imagery. Pole position, height and bracket geometry are measured from the point cloud; luminaire type and physical condition are identified from the imagery.
• Aerial LiDAR and photogrammetry — for parks, shorelines and green areas a vehicle cannot enter. For the method itself see our article on data capture with LiDAR.
• GNSS-enabled field application — verification, filling gaps and matching physical labels or QR codes.
• Night-time circuit observation — mapping the panel–feeder–pole hierarchy. This cannot be derived at a desk; it is observed by switching circuits one at a time.

Data quality and acceptance criteria

Most inventory projects end in dispute because quality criteria were never written down. Three typical defects and how a specification prevents them:

• Duplicate records — the same pole counted twice on two passes. Acceptance criterion: no duplicate points within a stated radius, and a unique pole_id constraint.
• Positional drift — GNSS multipath error at roadsides and between tall buildings. Acceptance criterion: a numeric horizontal tolerance against independent control points, audited by sampling.
• Ownership conflict — TEDAŞ, municipal and highways boundaries undefined on the map. Acceptance criterion: ownership may not be left blank, and overlapping areas are reported separately.

GIS and city information system integration

An inventory left standing as a spreadsheet loses most of its value. Once the layer is related to zoning, parcel, road and utility layers in the same database, it becomes queryable: “how many luminaires in this district are over ten years old, and which panels feed them?”

Delivery is in open standards (OGC WMS/WFS, GeoPackage, PostGIS) so the data is never locked into one vendor's software. Where a city information system exists, the layer is mapped onto its schema; where it does not, it can be built with the approach in GIS-based decision support systems. The same data serves as the lighting asset layer of the city's 3D model and digital twin.

The inventory is the M&V baseline

The governing principle of IPMVP is that savings are not measured but inferred: they are the difference between adjusted baseline energy and reporting-period energy. For street lighting the baseline is built from three components:

1. verified luminaire count,
2. measured luminaire power (not the nameplate figure),
3. operating hours derived from the astronomical calendar.

The first two come straight from the inventory. This is why the inventory must be produced before the conversion, not after — an inventory captured afterwards cannot establish a baseline, and no savings claim built on it is falsifiable.

For public-sector work run under an energy performance contract, measurement and verification is already a contractual condition: it is carried out every year of the contract under TS ISO 50006 and IPMVP or TS ISO 50015, certified by a qualified Measurement and Verification Professional.

Clauses to put in your tender document

The following should be defined numerically in the technical specification of an inventory or conversion tender. Left undefined, the acceptance stage becomes negotiable:

1. Scope: road list, ownership boundaries and explicit exclusions
2. Coordinate system and delivery schema, with the EPSG code stated
3. Attribute list and mandatory fields (the data model above)
4. Method for measuring luminaire power — nameplate values not accepted
5. Positional tolerance and completeness ratio, audited by sampling
6. Baseline definition, measurement boundary and the chosen IPMVP option
7. Routine and non-routine adjustment rules (network extension, added or removed luminaires, tariff change)
8. Acceptance measurement: field measurement to EN 13201-4 with a calibrated ILMD — a simulation output is not a statement of compliance
9. Delivery formats and data ownership / reuse rights

What drives scope and duration

A single “per pole” unit price is not realistic for inventory work; the variables that drive scope differ sharply between projects. What we look at when preparing a proposal:

• Total road length and pole density — rural and city-centre differ greatly
• Share of areas unreachable by vehicle — parks, shoreline, pedestrian zones
• Whether the panel and feeder hierarchy requires night-time work
• State of existing records — none at all, or to be verified
• Whether the lighting-class calculation is in scope
• Target positional accuracy and delivery format

To discuss your scope against these headings, get in touch.