paper · 2026
Geocoding-Free Attribute Binding on the Road Network
School zones, speed-limit segments, no-parking intervals are typically stored as coordinate polygons — 80–160 floating-point values per zone, requiring spatial joins at every query. Under BSI, each zone reduces to 8–12 integers and every query becomes an integer comparison. A 0-cell / 1-cell / 2-cell topological attribute schema for the entire Korean address system.
What this paper does
Spatial regions defined over a road network — school zones, speed-limit segments, no-parking intervals — are conventionally stored as coordinate polygons. A typical school zone covering 4–6 road segments requires roughly 80–160 floating-point values, and every “is this point inside the zone?” query goes through a spatial database with floating-point geometry.
But a school zone only matters on the roads that pass through it. Building interiors, courtyards, parks — none of those are road-user accessible. Coordinate geometry embeds an inherently one-dimensional phenomenon (zones on roads) into two-dimensional space, paying the full overhead of 2D spatial computation for a domain that does not require it.
This paper formalises a direct attribute-binding model on the BSI linear measure. Two attribute types cover the full space of address-based road data:
- Point attributes
(r, n, v)— pharmacies, hospitals, CCTV installations, any object with a road name address. - Interval attributes
(r, [n_a, n_b], v)— zones, segments, restrictions.
Both are queried by integer arithmetic alone, with no spatial database and no floating-point computation.
Compression
| Dataset | Coordinate form | Size | BSI form | Size |
|---|---|---|---|---|
| School zone (5 roads) | polygon, ~50 vertex pairs | ~800 B | 5 integer pairs | 40 B |
| Speed-limit segment | road geometry, ~20 vertices | ~320 B | (r, n_a, n_b) | 12 B |
| No-parking interval | polyline + buffer | ~160 B | (r, n_a, n_b) | 12 B |
| CCTV location | (lat, lng) + geocoding | 16 B + API call | (r, n) | 8 B |
The query-time cost difference is larger still. Zone membership becomes a single integer comparison (one CPU instruction, O(1)) instead of a polygon-buffer plus spatial-index plus floating-point intersection — typically O(log n) with a large geometry-operation constant, requiring PostGIS or equivalent infrastructure.
Worked example — Gangseo-gu school zones (88 records)
A school protection zone is legally defined as a 300 m perimeter around the school gate, with a 30 km/h speed limit applying within. This is an interval attribute — a zone on the roads surrounding the school, not a point.
The current public dataset publishes only the school’s road name address — one point, not the zone extent. The address binds immediately as a Type P (point) attribute:
공항대로36길 74 → (공항대로36길, 74, school)But representing the zone requires deriving the interval from the legal radius — a one-time spatial computation. Once derived, the resulting interval records are coordinate-free and permanently queryable by integer arithmetic.
The gap is in the data publication format, not the model. If zone datasets were published with explicit BSI start and end addresses per covered road segment — a straightforward extension of the existing RNADDR standard — Type I binding would be immediate, exactly as Type P binding is today. This paper proposes that interval attributes become a native field in future releases of zone-type public datasets.
What this completes
With the three-paper series:
- 0-cell (point) — building address attributes (existing RNADDR system)
- 1-cell (line, interval) — point and interval road attributes (this paper)
- 2-cell (face) — district and indoor face attributes (companion paper)
Queries that previously required PostGIS or a GIS server — facility density by road segment, zone membership, nearest POI within a routing path — become native integer operations on the BSI schema, executable in any SQL-capable database without spatial extensions.
Reach beyond Korea
Although demonstrated on the Korean Road Name Address system, the binding model applies to any urban infrastructure with linear topology: transit corridors, utility pipelines, railway lines, pedestrian networks all admit the same BSI-style parametrisation. The same integer-arithmetic query layer follows directly.
Status
Third in a three-paper series. The author is actively seeking collaborators in geographic information science, urban computing, and transportation engineering for formal peer-reviewed submission. Inquiries: whitepep@gmail.com.