paper · 2026
도로 네트워크 위에서 지오코딩 없는 속성 결합
어린이보호구역, 속도 제한 구간, 주정차 금지 구역 등은 보통 좌표 폴리곤으로 저장된다 — 한 구역당 80–160개 부동소수점, 매 쿼리마다 공간 조인. BSI 정수로 가면 각 구역은 8–12개 정수로 줄고, 모든 쿼리가 정수 비교가 된다. 한국 주소 체계 전체를 위한 0-셀 / 1-셀 / 2-셀 위상 속성 스키마.
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.