Auditing existing data
Vibrancy Gradient
This concept can be represented as a density of venues, seen venue for data
Venue
- The CVR (Danish firm database) can be used if it is filtered to only show:
- Bars/Clubs: DB25 code 56.30.20
- Restaurants with alcohol licenses: DB25 code 56.11.10
- In addition, the data set must be joined with DAR (Address Register) to gain geometry.
- OSM: The venue could also be located as an amenity in the OpenStreetMap dataset, which has the advantage of focusing more on actual venues you can enter rather than the legal structure of a firm that operates bars, etc. However, the client has specified that only official Danish datasets can be used.
Friction Point
Friction points can be identified by combining police incident reports and Københavner-vink (website where residents can file official complaints). Merging theas datasets and joining them with the DAR dataset will render geospatial locations (points)
Transit Node
Transit nodes can be extracted from the travel plan dataset, but it is decided that this does not add value to the analysis and is therefore dropped.
“Public Social Space”
Public social spaces are hard to find datasets for, but they are so relevant to the analysis that it was decided to conduct primary data collection to locate and map them.
The Seasonal Mask
No existing dataset that can represent this in this context is deemed relevant, and it is also considered to be not feasible to identify the areas with sufficient representativeness, so the concept is dropped. This was also not a primary request from the client, but an identified “blindness”
Mobile Entities
Like for The Seasonal Mask, no existing dataset exists, and the location of the mobile entities is so varying over time that it is decided not to include them in the project
Domain of Discourse.
Design Rationale [2.2]: Data Modelling
Issue: How do we represent ‘Vibrancy’ and ‘Nightlife Intensity’ as logical entities?
The Conceptual Cast: To answer the City Council’s brief, we need to define Intent before we search for Extent (the data), for each surviving member of the Cast of Characters.
- The Entertainment Venue: A point entity representing a source of social activity.
- The Noise Incident: A proxy entity for “vibrant friction” between residents and nightlife.
- Public Social Space: A polygon entity for informal, unticketed socialisation.
- The Vibrancy Gradient: A continuous field derived from the above, not captured directly.
Transit Node was already dropped by Backflow at Auditing existing data (above) and is not carried forward.
Venue
Thematic specification. A Venue is a fixed-address premises currently trading as a bar, club, or pub open to public patrons — the same categorical boundary Auditing existing data (above) used to filter CVR by DB25 codes 56.30.20 and 56.11.10. A firm holding the right code but no longer trading is not a Realisation of Venue. A licensed hotel restaurant is a Realisation by code, but is flagged below for validation, since the Vibrancy Gradient concerns late-night nightlife specifically, not licensed catering in general. Discrete, not continuous: each Venue is an individually identifiable premises.
Spatial and temporal resolution. No MMU applies below the level of an individual firm — a Venue either operates from a specific address or it does not. Temporally, a Venue must be trading at the time of audit; the Seasonal Mask (pop-up bars, allotment parties) was already dropped at Auditing existing data, so no intermittent trading pattern is recognised as a valid Venue Realisation in this Domain of Discourse.
The thematic scale (NOIR).
| Entity | Attribute | Logical Type (NOIR) | Semantic Intent |
|---|---|---|---|
| Venue | Venue_Category | Nominal | Distinguishes between Bars, Clubs, and Pubs. |
| Venue | Vibrancy_Weight | Ordinal | A 1–5 rank of ‘loudness’ based on the venue type. |
| Venue | Opening_Time | Interval | Used to filter the ‘Late Night’ economy. |
| Venue | Capacity_Limit | Ratio | The maximum number of persons allowed (weight for KDE). |
Topological and Spatial-Relationship Constraints. No Venue may be topologically contained within the Tivoli Gardens polygon: Tivoli is itself modelled as a single Venue, so any kiosk, stage, or bar inside its perimeter is absorbed into that one Realisation rather than counted separately. This is a pure containment test — it makes no difference how far inside Tivoli a given premises sits, only whether its geometry falls within Tivoli’s boundary.
Noise Incident
Thematic specification. A proxy entity for “vibrant friction” between residents and nightlife: a single, time-stamped complaint record from either the police incident log or Københavner-vink, geocoded via DAR. Discrete: each Incident is one filed complaint, not an ongoing condition.
Spatial and temporal resolution. No MMU — a complaint is a point regardless of the extent of the disturbance it describes. Temporal resolution is the complaint’s filing timestamp; no minimum duration is required for a disturbance to count.
The thematic scale (NOIR).
| Entity | Attribute | Logical Type (NOIR) | Semantic Intent |
|---|---|---|---|
| Incident | Complaint_Type | Nominal | Categorises the source (Music, Shouting, Litter). |
Topological and Spatial-Relationship Constraints. None beyond falling within the municipal boundary of the study area; Noise Incidents are not tested against Tivoli or the harbour front.
Public Social Space
Thematic specification. An informal, unticketed space in which people gather without commercial gatekeeping — park, plaza, waterfront edge, or courtyard. The test is behavioural, not zoning-based: does informal socialisation actually occur there, not merely could it. A private courtyard with restricted access is not a Realisation, even where it physically resembles one.
Spatial and temporal resolution. The MMU is set at 50 m² — large enough to exclude the kind of incidental space the general discussion above warns against (2 m² of grass and a single bench), while including small plazas and courtyard gathering spots. No temporal resolution is imposed beyond the survey date; because the Seasonal Mask was dropped at Auditing existing data, a space that is only lively for part of the year is still counted if it meets the MMU and thematic test at the time of survey.
The thematic scale (NOIR).
| Entity | Attribute | Logical Type (NOIR) | Semantic Intent |
|---|---|---|---|
| Public Social Space | Space_Type | Nominal | Park, plaza, waterfront, courtyard. |
| Public Social Space | Observed_Footfall | Ordinal | Low / Medium / High, rated at time of survey. |
| Public Social Space | Area_m2 | Ratio | Measured extent; tested against the MMU before inclusion. |
Topological and Spatial-Relationship Constraints. A Public Social Space is only considered related to the harbour front if it lies within 25 metres of it and is not separated from it by a road carrying car traffic. The two clauses are tested differently: the 25 m threshold is a metric buffer test on the Space’s geometry; the road clause is a connectivity test against the road layer, and it overrides the buffer regardless of distance — a space 3 metres from the water across a four-lane road is excluded, while one 20 metres away with unobstructed access is included.
Vibrancy Gradient
Thematic specification. A continuous gradient, not a discrete entity: the more Venues and the more harbour-front-related Public Social Space in an area, the higher the Vibrancy. It has no boundary of its own — it is realised by interpolation across the Venue and Public Social Space Realisations above, not captured directly.
Spatial and temporal resolution. Because Vibrancy Gradient is continuous, an MMU in the Phase Three sense does not apply to it directly; its effective resolution is set by the interpolation method and output cell size chosen at Authoring the Analytical Schema, not fixed here.
The thematic scale (NOIR) and Topological/Spatial-Relationship Constraints. Not applicable at this Vantage Point: the Vibrancy Gradient carries no attributes of its own to type, and no relational constraints to test — it inherits both from its two inputs, already specified above.
Dropped concepts
Transit Node, the Seasonal Mask, and Mobile Entities were already resolved by Backflow at Auditing existing data (above), and therefore receive no Domain of Discourse entry: a concept dropped before formalisation does not need to be formalised.
Confronting the Sensoric Manifold
The framework above tells us what a Venue, a Noise Incident, and a Public Social Space are. It does not yet tell us whether the entities the Evaluation Matrix accepted actually behave that way on the street — and it does nothing at all for the one entity the Evaluation Matrix could not accept from any register.
Validation — the Venue layer. The CVR + DAR join gives a filtered, geocoded set of firms registered under DB25 codes 56.30.20 and 56.11.10. A spot-check walk through a sample of streets in the study area is still required before this set is trusted: firms close, change trade without re-registering, or hold an alcohol licence for premises that never, in practice, host the kind of late-night activity the Vibrancy Gradient is meant to capture — a licensed hotel restaurant, flagged above, is a perfectly valid Accept under the Evaluation Matrix and a poor fit for Vibrancy_Weight. Validation does not re-run the audit; it tests whether the register-derived Realisation still satisfies the thematic specification once confronted with the manifold, and flags exceptions for the Design Rationale rather than silently keeping or dropping them.
Collection — Public Social Space. This is where the Reject decision made during Auditing existing data (above) is actually discharged. Having no register to Accept or Transform, and having judged the concept too central to the Vibrancy Gradient to drop by Backflow, the workflow committed to Direct Procurement. That commitment is only meaningful once the Domain of Discourse above has fixed its terms: a field surveyor is sent out not to “find social spaces” in the abstract, but to test each candidate space against the thematic specification, discard anything below the 50 m² MMU, check it against the harbour-front constraint where relevant, and record it with the attributes already specified above.
Design Rationale [2.2 — continued]: The Epistemic Choice, resolved
Issue: Public Social Space has no register to Accept or Transform. Do we compromise the Vibrancy Gradient model to exclude it, or absorb the cost of fieldwork?
Position A — Backflow: Drop Public Social Space from the Cast of Characters; redefine Vibrancy Gradient as venue-density alone.
Position B — Direct Procurement: Field-survey candidate spaces against the formalised Domain of Discourse and fold the resulting Realisation into the Vibrancy Gradient as a second input alongside venue density.
Argument: Position A is cheaper but reintroduces exactly the omission the “workflow scoping” stage already flagged as a bias (official registers miss informal socialisation). Position B costs fieldwork hours but keeps the model faithful to the Refined Question. Position B is adopted; the cost is logged against project resourcing, not absorbed silently.
This is the Epistemic Choice: it could not be resolved in good faith until the Domain of Discourse above gave Public Social Space a testable definition — thematic specification, MMU, and the harbour-front constraint — to survey against.
Re-auditing existing data
Applying the protocol above to the datasets already Accepted or Transformed at Auditing existing data: the Venue and Noise Incident Realisations are re-checked against the now-rigorous Domain of Discourse (thematic specification, MMU, NOIR typing, and the Tivoli containment rule) rather than the looser Universe of Discourse concepts used the first time through. No dataset changes status on this pass — CVR + DAR remains Transform for Venue, and the police / Københavner-vink merge remains Transform for Noise Incident — but the Tivoli containment rule identified above is now flagged as a required post-processing step (a spatial clip removing any Venue Realisation that falls inside the Tivoli polygon) before either dataset is handed to the Analytical Schema.
Recording the Domain of Discourse
Schema. Three GeoPackage tables are created, one per entity, matching the Attribute Framework already specified above exactly:
| Venue: | |
|---|---|
| Name | Type |
| Geomatry | Point |
| Venue_Category | Text |
| Vibrancy_Weight | Integer |
| Opening_Time | Date/time |
| Capacity_Limit | Integer |
| Noise_incident: | |
|---|---|
| Name | Type |
| geometry | Point |
| Complaint_Type | Text |
| Public_social_space | |
|---|---|
| Name | Type |
| Geomatry | Polygon |
| Space_Type | Text |
| Observed_Footfall | Text/coded |
| Area_m2 | Float |
Vibrancy Gradient gets no table of its own — it is computed from the other three at Authoring the Analytical Schema, not recorded here.
Population — Venue and Noise Incident. The CVR + DAR join is loaded into venue; the police / Københavner-vink merge is loaded into noise_incident. The Tivoli containment clip identified during Re-auditing is applied here, as a post-load processing step, before the table is considered finished: any Venue Realisation falling inside the Tivoli Gardens polygon is removed, since Tivoli is itself the single Venue Realisation for that area.
Population — Public Social Space. This table is populated by backdrop digitalisation rather than by loading a register: the field surveyor’s paper sketches and notes from Confronting the Sensoric Manifold are digitised against a georeferenced aerial photograph of the study area, following the Backdrop Digitalisation workflow. Each digitised polygon is checked against the 50 m² MMU before being kept, and the harbour-front constraint (25 m buffer, not severed by a road carrying car traffic) is applied as a follow-up geoprocessing step once the full table is populated, since it is a compound constraint no single digitising action can enforce on its own.
Both populations converge on the same three schemas regardless of provenance: nothing in venue or public_social_space records whether a given row came from a register join or a field sketch, which is exactly what allows all three tables to be handed to Authoring the Analytical Schema as a single, uniform input.