One Register for Benches, Lights, Bins and Surfaces: What Data Model Works?

Agree on what an 'asset' is before picking a schema

A register fails or succeeds on definitions, not on field types. For a bench, light column or bin the natural unit is the physical instance with a location and service history, not 'a bench in general'. This matches how asset management frameworks work: in Scotland, street furniture is collected as a national point dataset that councils maintain under a common roads asset management framework and refresh annually.

Before designing fields, fix the hierarchy: territory or zone of responsibility (yard, square, street) → site or segment → individual object or surface. That way dispatchers, accounting and cleaning contractors can all read the same structure.

• Decide explicitly what counts as a 'surface': paving slabs, asphalt and rubber playground surfacing have very different life spans and need separate asset types.
• Choose the level of detail — every bin individually, or grouped equipment as one complex asset.
• Record the ownership reality up front: not everything on municipal land is municipal property.

One geometry does not fit all: points versus areas

The most important structural decision is how to store position. A bench, light, bin, post or table is a point asset with a single coordinate and its own record. Toronto publishes street furniture as a point layer with a documented data dictionary, and Scotland marks its national street furniture set explicitly as point-type geometry.

Surfaces are different. Asphalt, paving slabs and rubber playground surfacing cannot honestly be a point: they occupy an area or a long narrow strip, so they need polygon or line geometry segmented into homogeneous pieces. Only then can each segment carry its own age, material and condition rating for planning repairs.

The CityGML standard draws a similar line. Urban furniture is its own feature class with level-of-detail geometries from LOD1 to LOD4, while road and footway surfaces are modelled as separate spaces with an explicit surface material attribute. The practical answer is therefore not 'one layer for everything' but one governed register in which geometry follows asset type.

• Point assets: benches, bins, lights, posts, tables, information boards — coordinate plus attributes.
• Area assets: tiled or asphalt paving, playground surfacing, planting beds, equipment zones.
• Line assets: narrow footways and paths best segmented by length instead of digitised as full polygons.

The attribute core every record needs

For different departments to reconcile reports, every record needs a stable unique identifier. When Russia planned a national register of courtyards and public spaces inside the GIS Housing and Utilities system, the stated principle was that each yard and each object receives a unique identifier and a state assessment. The same idea scales down to a city register.

Lifecycle fields matter as much as identity. CityGML gives city furniture a creation date and a termination date plus references to external systems. In a working register these become installation date, removal or replacement date, warranty end, responsible owner and contractor.

• asset_id — unique and immutable when data moves between systems.
• location and zone reference (address, yard, square) rather than coordinates alone.
• type and subtype codes from a controlled vocabulary.
• install_date, removal_date, warranty_end — the lifecycle.
• owner and contractor — who is accountable and who maintains.
• status: in service, requires repair, decommissioned.

Controlled vocabularies, not free text

The most common reason registers stop being useful is the 'type' field filled with free text: 'bench w/ bin', 'seat', 'lava'. Nobody can aggregate that. The cure is shared code lists for type, material, condition and responsible organisation.

CityGML stores furniture class, function and usage as separate controlled code lists. For a Russian or Eastern European register, base the taxonomy on the street-furniture classification from the Ministry of Construction guidelines and split it into levels: category → type → variant. Example: category 'street furniture' → type 'bench' → variant 'bench with backrest for a courtyard'.

• Start from a normative category list but prune it to what your territory actually holds.
• Add types through an agreed workflow, never in the field by an operator.
• Material and colour belong in dictionaries too — they drive purchasing and anti-vandalism decisions.

Condition and work history make a register worth keeping

A register that only lists objects ages badly. Value appears when each asset carries a condition rating and a work history. For point assets store a condition grade and the date of the last inspection. For surfaces, condition only makes sense per segment: divide paving into homogeneous segments and keep a score and a repair plan for each, in the spirit of pavement condition indexes used for roads.

Do not retell history in text. Link the register to work orders by asset identifier so a dispatcher can see that bench 1021 had a new backrest fitted yesterday and will not send a crew twice.

• last_inspection_date and next_inspection_date tuned to the asset type.
• condition_grade on one shared scale, for example excellent / fair / needs repair.
• work_order_ids linking out to tickets instead of a textual retelling of jobs.
• photo_url with a capture date, essential when accepting work from a contractor.

Governance: the owner, the cycle and the public layer

A data structure is only half the solution. You need one owner of the register, a refresh rule, and a procedure for entering changes when work is accepted or assets are removed. Scotland aggregates municipal furniture into a national dataset on a set schedule; Toronto publishes contract-managed furniture as open data with a documented field dictionary.

There is also a public dimension: under Russia's comfortable urban environment programme, the GIS Housing and Utilities system publishes lists of improvement sites, deadlines, work types, contractors and budgets. A clean internal register becomes the source for such public reports instead of a separate paper ledger.

• Appoint a single data owner, whether a department or a GIS operator.
• Fix the cycle: full inventory once a year, incremental edits on every accepted and completed job.
• Connect the register to open data and public reporting so it never drifts from what residents see.

Do not over-engineer the first version

Resist collecting every imaginable attribute on day one. Start with the core — identifier, coordinates, type, status, condition — and add fields only when a real task demands them, such as procurement, repair planning or resident complaints.

Watch accuracy expectations. A point layer at a scale around 1:50 000, as in the Scottish set, confirms presence and approximate position but is not survey-grade. For surface polygons record the source of the digitised boundaries, and keep legal status (whose balance sheet) separate from technical inventory.

• Do not merge geometry and bookkeeping: link a furniture point to its area territory by reference.
• Record coordinate accuracy and source (field survey, cadastre, photo).
• Never pack type, condition and owner into one field — split them across dictionaries.