Developing a System of Public Addresses

1
Developing a System of Public Addresses

• as a language for location dependent
  information

Morten Lind mol_at_kms.dk National Survey and
Cadastre, Denmark
2
My Background

• Organisation National Survey and Cadastre
• State Authority for Sea Charts, Topographic
  mapping, Cadastre and subdivision of land
  (parcels)
• Responsible by law for co-ordination of mapping,
  geodata and related issues
• Position Product Development Department
• Resp. product development, data integration and
  co-ordination and development of public spatial
  data
• Senior Consultant Address issues, datamodelling,
  metadata and data quality

3
Nordic Countries and Denmark

• This is Denmark
• Pop. 5,3 mill
• Indiana/Wisconsin
• 43,000 km2
• 16,500 sq mi.
• ½ Indiana/Maine
• lt 171 meters
• No mountains!
• No wilderness!
• Intensive agriculture
• Urban areas
• 4 mill. buildings
• 2,2 mill. addresses

4
Agenda

• 1. Introduction
• The address as a "human language" reference
  system
• 2. Address System in Denmark/Nordic
• Status and new perspectives
• 3. Datamodelling the Address
• Attribute or entity? Who should care?
• 4. Developing a Public Address Register
• The process and methods
• The benefits of "roof-top" address data

5
1. Introduction

• The address as a human language reference system

6
House Numbers in Ancient Pompeii?
According to experts No
7
Present Cities in Liguria, Italy
Yes detailed house numbers
8
Modern Cities of US and Canada
Yes detailed house numbers
9
Address System as Infrastructure
Bratislava, aug. 1968 Students removing house
number and street signs
10
Elements of an Address Identification
11
Note Differences Europe vs. US

• Europe Simple/Independent street names
• No Street/Avenue method
• No numbering of streets (like 4th Aavenue)
• No House no. directions (Like 2nd Street West)
• Europe (?) Simple Odd/Even House nos
• House numbers increasing by 2 (1, 3, 5 )
• Often optional suffix A..Z (Like 101B)
• Why?
• Different layout of street network No regular
  grid

12
European Street Network Structure
Regular, gridded layout
Self grown network (spiders web) Defence/Military
purposes
13
Odd and even Numbers
14
Georeferencing by Identifiers
15
Characteristics of the Address

• It is simple, well known and widespread!
• Known, understood and used by everybody
• It is suitably detailed!
• In built-up areas where we live Find the right
  front door or stairway entrance
• It is practical and logical!
• Based on the way we get about Hierarchical
  structure allow us to navigate and approximate
  locations
• It is visible!
• Signs with street names and house numbers
  (perhaps the most valuable property of the
  address system.)

16
2. Address System in Denmark

• (and Nordic Countries)
• - Status and new perspectives

17
Status Extent of Address System
18
Status Common Address Format
19
Status Linking Public IT-systems
Person
Property
Business
20
Address approach in Nordic countries

• Backbone is population/property registers
• Has adopted trad. urban area street/house no.
  system
• Has extended address system to rural areas
• Has standardized system across local authorities
• Address is a public adminstrative id/key
• Address is enforced by legislation
• Links a person/property/business to a location
• Enables register based census' and statistics

21
New Perspective Common use of Data
22
New Perspective Legislation
23
3. Datamodelling the Address

• - attribute or entity? Who should care?

24
Inconsistency Different Address Sets
10 business entities have the address Ruggaardsv
ej 60 Building register has 5 addresses Ruggaard
svej 60A-E
25
Inconsistency Different Address Sets
9 business entities have the address Svendborgve
j 90 Building registre has 1 address Hestehaven
1
26
Inconsistency Different Address Context
27
Attribute Approach
28
New Model Entity Approach
Other users
29
New Datamodel Address and Building
30
New Datamodel Address Properties
31
New Model Conclusion

• Strengthens the system of addresses
• Address is enforced as an independent object type
• Address instance will exist "of itself"
• Address can be equipped with its own data
• The model puts focus on address authority
• An address instance is defined by
• A spatial location (co-ord. or ref. to spatial
  object)
• A reference to a named road etc.
• A named label (house no) reflects relative
  position

32
New Goal Register of Public Addresses
33
4. Developing a Public AddressRegister

• The process and methods
• The benefits of roof-top address data

34
Local/National Address Project

• Participation in project - july 2001
• Municipalities in first / last phases of work
• Municipalities pending/no info

35
Data Sources
36
Preliminary Data Q Control (Register)
Joining address data from different registers by
use of Property No.
37
Preliminary Data Q Control (Base Maps)
Creating polygons by use of house nos with same
street code
Correct Street Code Polygon
Errors in Basemap Street Code for these House Nos
38
Automatic Data Capture
39
Control and Editing Calculated Data
40
Public Specifications and Quality Control
41
Monthly Update Based on Plot No.
3) Plot No. co-ordinates are transferred into
Address Table as a approximated, temporary
Georeference
1) For every address without coord. Plot No,
Parish Code etc. is looked up
2) Cadastre Db is queried for Plot Nos centroid
co-ordinates
42
Status and Completeness
Co-ordinate completeness from 86 (red) to 99
(green), July 2001
43
Result Positional Accuracy
44
Result Completeness (for Queries)
45
Result Completeness (for Presentation)
46
Comparison Accuracy Depends
47
on area type!
48
Rooftop Address Benefits Drawbacks

• Benefits
• Positional accuracy address pinpoints exact
  building
• Completeness by spatial search all addresses are
  represented
• Reliability in spatial joins queries on
  "neighbor objects" or join with databases
• Simple data structure can be stored in a simple
  database table
• Simple queries simple browse or search using SQL
• Drawbacks
• Price and costs More costly data
  capture/maintenance - depending
• No network address is not connected to
  underlying road network
• Managing inaccurate information Need facilities
  for calculating in between house numbers etc.

49
Conclusions

• (almost done )

50
Conclusions Requirements and Challenges

• Common Rules and Standards
• Strict legislation or formal standards required
• Common definitions, concepts and formats needed
• Proper Management
• Determination of authority and custodianship
  needed
• Agreements and rules must ensure participation
• Good Access and Wide Use
• An Address Register/gazetteer should be
  developed
• Easiest possible access to data and use of data

51
A GIS Pioneer from last Century
Thank You to Curious George and to Margret and
H.A. Rey, (1941)