Peirce Eichelberger
H D R Infrastructure, Inc.
8404 Indian Hills Drive
O m a h a , Nebraska 6 8 1 1 4
LAND/STRUCTURE/OCCUPANCY DATABASE DESIGN:
H A N D L I N G AN I N C R E A S I N G L Y C O M P L E X URBAN R E A L I T Y
ABSTRACT.
As the n e e d f o r m o r e s o p h i s t i c a t e d local
g o v e r n m e n t systems g r o w , simpler concepts are n e e d e d to help
deliver these systems. A subject database approach, independent of
the line a g e n c y o r g a n i z a t i o n a l s t r u c t u r e , p r o v i d e s f o r m o r e
d y n a m i c , longer lived data structures, while supporting higher
level g o v e r n m e n t a l f u n c t i o n s . T h e L a n d / S t r u c t u r e / O c c u p a n c y
subject database greatly reduces data redundancy and promotes data
sharing. It is a longer range concept that can quickly bring benefits
by using generic s y s t e m identification, f i l e / d a t a b a s e migration
planning and database as a "family of products" implementation
strategy.
INTRODUCTION
T h e first of the four following sections e x a m i n e s the need for a subject
d a t a b a s e a p p r o a c h u s e f u l in d e v e l o p i n g a d v a n c e d urban i n f o r m a t i o n systems.
Needs c o v e r e d include the ability to handle organizational changes, the ability to
s u p p o r t " h i g h e r level" f u n c t i o n s of g o v e r n m e n t , e n h a n c e d data s h a r i n g and
interchange and the ability to lessen data redundancy. T h e second section covers
p e r t i n e n t d e s i g n i s s u e s c r i t i c a l to the s u c c e s s f u l c o n c e p t u a l i z a t i o n and
implementation of the Land/Structure/Occupancy Database. T h e s e design issues
deal with the identification of recognizable entities, appropriate keys, importance of
addresses, k e e p i n g pace with vertical urbanization and the e n h a n c e d support of
map/graphic data structures.
T h e third section discusses implementation strategies, so the benefits of a
subject database approach can be experienced over the short term. Implementation
strategies involving an evolutionary approach, file migration and a reliance on a
"family of products" to speed implementation are discussed. The concluding section
recaps and restates salient points of the earlier sections.
NEED FOR A SUBJECT DATABASE
APPROACH
A subject database approach in general, and the Land/Structure/Occupancy
Database in particular, satisfies m a n y needs within a local g o v e r n m e n t information
m a n a g e m e n t context. T h e ability to support organizational c h a n g e using d y n a m i c
data structures is m o r e feasible within a d a t a b a s e e n v i r o n m e n t . B e c a u s e many
departments are involved with certain activities requiring a coordinated response,
database can support these "higher level" functions of government. Possibly the
most significant need met by database m a n a g e m e n t is in the p r o m o t i o n of data
-
1 -
sharing a m o n g participant agencies and f u n c t i o n s . T h i s s h a r i n g a l s o helps
ameliorate the very significant data redundancy that is everpresent in each local
government.
Supporting Organizational
Change
Local government computer systems have to last 5 - 1 0 + years in order to
"payback" the development costs. While the system may last several years, clearly
the data involved is much longer lived. This data in many cases will outlive the
s o f t w a r e / h a r d w a r e processors it is stored on. Organizational c h a n g e s in local
g o v e r n m e n t happen in subtle ways, though at other times m a j o r reorganizations
occur. It is very important that computer systems be developed and implemented
that are insulated, as much as possible, f r o m the daily organizational chart of the
local government. This insulation is possible because of the definition of data entities
that are easily recognizable by all involved local agencies. T h e s e independent
entities, or "things" that local government functions must deal with everyday, should
not be departmentally defined, but organizationally recognized. Land parcels versus
o w n e r s h i p / l a n d - u s e p a r c e l s o r o c c u p a n c i e s v e r s u s b u s i n e s s trade n a m e s are
examples of more universally accepted entities. Other examples of more broadly
d e f i n e d entities might be h o u s e h o l d s versus personal property tax accounts or
right-of-way designations versus areas external to privately o w n e d tax parcels.
S u b t l e c h a n g e s , such as w h a t agency is r e s p o n s i b l e for s i g n / z o n i n g
inspections, who inspects new properties under construction or w h o does the Chiet
Building Official report to? need to be handled with a minimum of disruption. Major
changes, such as the collection of a n e w user fee or charge, the establishment of a
Public Safety m e g a - a g e n c y also need to be equally s u p p o r t e d by distinct and
dynamic data structures. Figure 1 summarizes this subject database ability.
N e e d t o S u p p o r t H i g h e r L e v e l F u n c t i o n s of
Government
As society, its l a w s and its technology b e c o m e more c o m p l e x , a more
concerted o r g a n i z a t i o n a l e f f o r t , involving related agencies, is required. This
concerted approach is supported by subject databases which seek to help coordinate
activities based on mutually recognizable entities, data standards and defined data
relationships. So many more functions of government require a concerted effort by
multiple agencies that the approach has been constant reorganization of departments,
sections and regulatory functions. This shifting of organizational responsibilities,
along with the adoption of more complex laws and ordinances have generally been
only partially effective. A better approach is to allow the participant agencies to
share basic data to a higher level, so the data itself helps coordinate related, yet
separate, distinct functions. Local government undertakes new functions, existing
departments and staff are often responsible for new activities, in other cases new
departments or staff are organized for the new functions. N e w functions such as
historic preservation, environmental protection, c o m m e r c i a l revitalization. arson
prevention, crime prevention have specialized data requirements in their own right as
well as the need to access much existing data.
-
2
-
FIGURE 1
DYNAMIC ORGANIZATIONAL STRUCTURE AND STABLE
DATA STRUCTURES
Stable Data Structures
Some examples of higher level functions are code enforcement, subdivision
regulations, planning (in a generic sense), community development, redevelopment,
economic development, infrastructure management, public safety, social services,
revenue generation, property roll/register maintenance, mapping, licensing, arson
prevention and citizen service/request. The Land/Structure/Occupancy (or L/S/O for
short) Database concept is particularly appropriate in support of higher level
functions like code enforcement, subdivision regulations, planning, licensing, and
property roll/register maintenance. Note that other subject databases are also
required and can be conceptualized to support all other higher level government
functions.
These higher level functions, while taking advantage of a "specialization of
labor" possible with a line department organization chart, require multi-agency
responses. This coordination occurs during various permitting processes, during
public meetings and hearings, within coordinating committees, in response to field
- 3 -
actions, paperwork flows or in response to public policies or stated objectives, i.e.
master plans, growth management, or capital investment.
n n t a S h a r i n g anH Dntn
Interchange
Subject databases built upon common, recognizable entities greatly promote
data sharing, because of the adoption of agreed upon data standards within an
environment of data being stored independently and "not o w n e d " by any particular
application. With improved data independence, data can be made available to more
varied applications. Data can more feasibly be created once and used for more than
one purpose. With this sharing, data accessed can not only be in a more current
state of update, but all users are accessing the same values for that data element, i.e.
current property owner's n a m e and mailing address, for example. With enhanced
data sharing, less time is spent recollecting the same pieces of information time and
again. With multiple agencies having access to the same data at the same state of
update, the ability to trigger coordinated actions is decidedly increased. Knowing,
for e x a m p l e , that a particular structure at a specific address has multiple code
violations, i.e. health, fire, zoning and building code, should help to prioritize a
concerted effort among involved agencies.
By s h a r i n g critical i n f o r m a t i o n , a g e n c y c o o r d i n a t i o n is h e i g h t e n e d ,
referrals, reminders and data verification is improved. With more people accessing
the s a m e information any errors, omissions or needed updates will c o m e under
additional scrutiny. Updates, verification and auditing of critical data-sets can take
place on a more regular basis, rather than just once a year, etc.
Common and Ilninne Data
Elements
The concept of the L / S / O Database arose f r o m a detailed analysis of data
e l e m e n t usage within many local g o v e r n m e n t s . In planning for and designing
advanced geoprocessing systems, using database technology, it is very important to
d e v e l o p a sound m e t h o d o l o g y for: m e a s u r i n g data r e d u n d a n c y , identifying data
s y n o n y m s and h o m o n y m s , q u a n t i f y i n g inter- and intra-agency d a t a / i n f o r m a t i o n
Hows and establishing data creators. Looking at data elements that can be tied to
specific locations that support major processes/functions, we have found (see Figure
2) that fully one-third of these elements are redundant! In other words, 300-40U
data e l e m e n t s are r e d u n d a n t l y collected time and time again by m a n y local
government agencies. T h e s e data elements could be replaced by a m u c h smaller
pool of non-redundant elements amounting to approximately 30-50 elements.
T h i s 10:1 r e d u n d a n c y ratio, a l o n g with the o n e - t h i r d c o m m o n and
two-thirds unique data element designation, has held remarkably constant lor larger
cities m e d i u m sized cities, mature cities, sunbelt cities, and cities and counties. A
careful analysis of this smaller pool of elements leads directly to the identilication ot
the L/S/O entities and the L / S / O Database concept. A recent confirmation of these
ratios puts the ratio at a far larger 20:1 (2, p. 79), this analysis included data names
in working storage and other temporary name usage.
- 4 -
FIGURE
1
C O M M O N AND UNIQUE DATA E L E M E N T S
Arlington C o u n t y . Virginia
Geography 3%
Alexandria, Virginia
Geography
4 * Land 3%
I Structure 3%
./^Occupancy
U n d
Structure 3%
upancy 2%
Addraaa Related 5%
iRatatad
Contact ^formation 8%
Information
RlgM-of-Way Related 1%
RIght-ot-Way Reiated
9%
Unique 74%
O r l a n d o / O r a n g e C o u n t y , Florida
S a n J o s e , California
Geography 9%
Geography 8%
Land 5%
Land 9%
Structure 3%
Occupancy 3%
Structure 3%
Occupancy 1%
i Related
Addreaa RaWad
?%
Contact Inlormrtlon
S%
RIght-of-Way Reiated
2%
Contact Information S%
RlgM-of-Way Related 1%
Unique 64%
Source: Various H D R design documents
This smaller pool of data elements includes such data elements as: property
owner's name and mailing address, parcel/lot situs address, land use and space use,
business/establishment or trade names, structure type, land/parcel size, physical
dimension of the structure and other basic contact information. Note that these data
elements describe readily recognizable, physical entities or things that can be
identified in-the-field. In Figure 2, see also the significance of address data
elements--5-11 % of the total number of elements.
Other interesting facts about c o m m o n data elements is that they are often
used as keys, they are larger in average size and most often appear on base maps.
Not surprisingly, these common data elements are used as keys to identify the other
two-thirds of elements classified as unique. These c o m m o n data elements, used as
keys serve to uniquely identify the entities useful to the broadest spectrum of local
g o v e r n m e n t a g e n c i e s / f u n c t i o n s . C o m m o n data elements—their organization,
definition, f l o w , access and u s a g e paths d e t e r m i n e the database design and
architecture.
- 5 -
nrsir.N
ISSUES
These design issues are critical in the identification and implementation of
the L/S/O Database concept:
•
entity identification and the adoption of data standards
•
importance of addressing and the L/S/O hierarchy
•
need to extend the land records concept of the multi-purpose cadastre,
•
the need to support database communications with mapping/graphic
data structures.
Entity
Identification
An effective identification of entities begins with a systematic examination
and analysis of all relevant data elements. This analysis involves data element
naming, sizes and definitions. A Data Element Directory (DED) has been developed
for database and system design activities which establishes a needed rigor in the
identification of critical data elements. The D E D captures nearly thirty data elements
about each and every local government data element. A sampling of over 1,200 data
elements are normally collected and analyzed. Data elements involving place specific
activities, those that support critical land records/regulatory functions, those from
critical maps, permits, licenses, etc. are analyzed. Data elements that support large,
recurring governmental activities are also carefully analyzed. For geoprocessing
systems, data e l e m e n t s and f u n c t i o n s that are address related are particularly
i m p o r t a n t , since g e o g r a p h y p r o v i d e s f o r the most e f f e c t i v e , least c o m m o n
denominator in the linkages among databases.
By using standardized n a m i n g and coding conventions, the D E D is very
useful in the early identification of important entities. This activity also helps focus
on the n e e d f o r d a t a s t a n d a r d s , data a d m i n i s t r a t i o n a n d D B A (Data B a s e
Administrator) functions, so essential for successful database implementation. From
the D E D analysis, natural groupings of data arise, that point to tangible entities
recognizable by multiple agencies. Many data elements group around land parcels,
tax parcels or ownership parcels. Other elements relate to the physical structure, i.e.
height, floor area (gross or net), use or occupancy classification, n a m e , year built,
etc. Another natural grouping of elements relate to individual o c c u p a n c i e s or
businesses, i.e. business trade n a m e , address, licensing i n f o r m a t i o n , occupancy
dimensions, etc.
These natural groupings of data relate to the entities, though not necessarily
uniquely identifying them.
ftriHrpssinp
a n d «he L / S / O
Hierarchy
If the entities are readily identifiable, and they should be, even as they relate
to field activities, such as inspections, the next issue is to determine how the entities
relate to one another? In most cases there is a natural hierarchy of structures upon
parcels and occupancies within structures. T h e reality of the situation is that one
structure may be built on multiple parcels. This refers to a problem with the local
subdivision ordinance rather than with a problem of identifying a data structure or a
- 6 -
data model. Generally this natural hierarchy exists, exceptions can be h a n d l e d
w h e r e warranted. Figure 3 summarizes the addressing hierarchy as it relates to the
L/S/O Database schema.
FIGURE 3
LAND/STRUCTURE/OCCUPANCY
ADDRESSING HIERARCHY
a
3567
3569
3571
N. Grind BM.
E. Olfw Si
LfMrtflnlfeMhMi
OotftAriMroUkUm
C&nE.OIwSL)
UgdRraJM*m(5l2KGHndM}
LnkwtftaNmStauftMl
SrueluiUttKil
(BatoariBifttt)
(1S71E.0I»S.)
IntrKkflmNmSnjchnZ
SlndwW(taa2
BwNaiTndi tkn» Ocapncy 1
OcacanqrilQ
Octup«y2Q5
0cei(«ney207
U s i n g addresses as keys has been difficult in the past due to the lack of
standardization, f o r m a t and completeness (3). Virtually every local g o v e r n m e n t
activity, as it relates to services to citizens and property, should be locatable via a
situs or place address. T h e s e addresses should be maintained in a standardized
format, edited for c o m p l e t e n e s s and uniqueness and be usable as a key or link
between various subject databases. Note that s o m e addresses may not necessarily
be unique, cross-reference addresses, addresses "around the corner" should identify
the correct parcel, structure or unique parcel address.
With vertical urbanization the use of a unique occupancy identifier, for areas
with public access, should be encouraged and codified. Taller buildings in our local
g o v e r n m e n t j u r i s d i c t i o n s are i n c r e a s i n g l y i m p o r t a n t , not only t r o m a c o d e
enforcement/licensing perspective, but f r o m a revenue generation perspective, too.
These sub-structure/occupancy identifiers should be considered as a vertical address,
very necessary in an urban environment. Local addressing ordinances, schemes and
systems should be enhanced to include a regular system of occupancy identifiers.
T h e s e s c h e m e s need to be applied in s h o p p i n g malls, as well as in high rise
buildings. The identifiers need to be posted for ease of visibility. Provisions for the
enforcement of posting should also be specified.
Historically the inability to cross-reference records at beloyv the parcel level,
i.e. structures and occupancies, has resulted f r o m the m a n n e r in which addresses
have been posted in-the-field, and recorded. O t h e r problems have occurred due to
the confusion of entities—where does o n e inspection begin and e n d ? or where does
one occupancy or structure begin and another end? W h a t physical space relates to
the permit, license or other governmental paperwork?
E x t e n s i o n of t h e L a n d R e c o r d s
Concept
T h e acceptance of the multi-purpose Cadastre perpetuates a 2 dimensional
view of the u r b a n l a n d s c a p e (5, p. 14). T h e o v e r w h e l m i n g m a j o r i t y of
tax/assessment files view o u r cities as 2 dimensional parcels with m a n y related
attributes. T h e s e "flat files" d e s c r i b i n g flat p a r c e l s h a v e a d i f f i c u l t t i m e in
recognizing multiple structures on a parcel much less handling any occupancy level
data, such as condominiums, rental apartments, accessory uses, etc. By adopting an
L/S/O subject database approach, a m u c h more faithful representation of the urban
reality can be mirrored by basic data relationships. Buildings will be built upon land
parcels probably in the year 2030. Basic data relationships d e f i n e d today will
outlive the database management software acquired tomorrow. C o m p u t e r hardware,
terminals and other peripherals will also c o m e and go, yet basic data relationships
among tangible entities must be long lived.
W h i l e most m a p p i n g activities presently o n - g o i n g in local g o v e r n m e n t
involve 2 dimensional graphics, an increasing need for more 3 dimensional graphics
is being recognized. Three dimensional graphics are needed not only in the areas of
Facility M a n a g e m e n t , C A D / E (Computer Assisted Design/Engineering), but in site
analysis, terrain modelling and building siting/placement functions, too. While the
intent of the L/S/O Database is to provide', on a alphanumeric terminal, the ability to
g o to the 8th floor of a m a j o r building and browse occupancies clockwise off the
e l e v a t o r core, l o n g e r term g r a p h i c n e e d s will be to s u p p o r t 3 d i m e n s i o n a l
architectural sketches/renderings and plans. Many of these graphics internal to a
building will become commonplace, as automated plan review and plan submission
on floppy disks become a daily reality. Automated submission of subdivision plans,
as-built engineering drawings for subdivision improvements are already occurring in
some locales.
-
8
-
Tie to A u t o m a t e d M a p p i n g
Systems
Proper ties or links to g r a p h i c / m a p p i n g software and databases m u s t be
understood in order to unlock the m a x i m u m potential of these expensive systems.
In nearly all instances, it is not cost effective to merely a u t o m a t e the cartography,
without a proper recognition of the need to effectively link the graphic/cartographic
data structures with the many other geographic attributes in daily use. Clearly the
amount of attribute data portrayed on most manual maps is there for ease of access.
Much of this m a p attribute data, i.e. dimensions, addresses, many text descriptions
are redundantly displayed data c o m m o n to other often automated systems.
A recent analysis using the Data Element Directory on 13 m a p sets in
O r l a n d o / O r a n g e C o u n t y , Florida led to s o m e startling revelations. Of 248 data
elements appearing on the manual maps, only 72 (less than 3 0 % of the total m a p
elements) were graphic s y m b o l s or elements, i.e. parcel lines, street right-of-way
lines, lake b o u n d a r i e s , m a n h o l e s , catch basins, etc. Fully 7 1 . 4 % of all m a p
elements were either numeric or alphanumeric attributes displayed upon the m a p for
easy access, etc. (4, pp. IV6-IV7). Of over 1,200 total data elements in the D E D , it
is easy to see that those non-graphic, attribute data elements shown on maps are just
the "tip of the iceberg" of what might be useful to a broad spectrum of potential m a p
users. In other words, it is especially critical that the attribute databases consisting
of numeric and alphanumeric values be recognizable and easily displayable via the
mapping software and hardware. These graphic/attribute ties must be supported not
only for base mapping type systems, but for statistical mapping systems as well.
Subject database communications between graphic and attribute applications
is also p r o m o t e d by a c o m m o n identification of agreed upon entities. Graphics
s y s t e m s that d o not allow for an easy identification of parcels or right-of-way
segments, etc. inhibit an easy interchange of all data that can be related to the
entities. The challenge is to provide easy t w o way navigation a m o n g graphic or
attribute, subject databases, even though data may be on different hardware handled
by multiple D B M S ' s .
IMPLEMENTATION
STRATEGIES
Three strategies have proven effective in the adoption of a subject database
approach. T h e first deals with supporting generic systems which tightly couple
closely related system functions. The second strategy is one of file migration and
d a t a b a s e evolution. Ideal data structures are not built o v e r n i g h t , nor are they
implemented within the confines of just one or two generic application systems. The
third strategy involves the adoption of database technology as a locus of a family of
productivity products which allows for the quicker development of systems, along
with the availability of new tools available to more than just the local government
computing professionals.
Generic System
Identification
A c o n c e p t that p a r a l l e l s the d e f i n i t i o n of s u b j e c t d a t a b a s e s is the
implementation of systems that support generic processes or functions. A generic
-
9
-
process is:
"a group of logically related activities and decisions required to
m a n a g e r e s o u r c e s in support of a f u n d a m e n t a l or u n d e r l y i n g
function of government."
Generic systems tend to be more independent of organizational change, they tend to
more closely coordinate related activities and functions, they bring automation to
more users, earlier, they help lessen the n u m b e r of i n d e p e n d e n t s y s t e m s to be
designed, implemented and maintained. Generic systems also support the subject
database approach by lessening data redundancy.
A m o d u l a r approach to generic systems helps insulate the system f r o m
organizational changes. Issuing building permits, scheduling inspections, handling
citizen inquiries o c c u r n o matter what the organizational structure looks like.
Generic systems should support basic processes, i.e. what are the functions of the
building code needing automations support versus what staffer Jane Doe would like
to see on the permit application screen?
A generic process involves other organizational entities, i.e. plan reviews
involve multiple codes, not just the building code. T o be effective, for example, the
generic system should support these other agencies and staff as well as those in the
building agency. This brings automation to more staff faster, though the initial
system design and implementation is more comprehensive and takes longer.
Generic systems help reduce data redundancy, data collected at the start of a
process is m a d e available to f o l l o w - o n users. Citizen inquiry data c o n c e r n i n g
location and problem definition is m a d e available to a work order system which is
used to update an inventory, once field activities are completed.
File M i g r a t i o n a n d D a t a b a s e
Evolution
Subject databases by their very nature, except in rare cases, require access
to other already automated data. Must this data be in a database environment prior to
automating n e w subject databases and generic systems? If this were the case, little
progress would be m a d e in reaching ideal data structures and the burden on any
given system i m p l e m e n t a t i o n e f f o r t would be f a r too high. T h e ideal subject
database and the architecture of subject databases should be viewed as a longer term
goal. Transient data structures, batch linkages and database conversions provide a
progression toward the ideal goal.
The conversion process of an on-line system using "flat files" to a database
environment requires careful thought and planning. A redesign may be required
which might better be considered as a total system rewrite.
Over the interim, this data needs to migrate toward database structures either
by planned and controlled redundancy, i.e. certain data is off-loaded from the other
applications, formatted and standardized and loaded into a database structure. Data
updating is a c c o m p l i s h e d via daily o f f - l o a d s in a batch e n v i r o n m e n t . N e w e r
s o f t w a r e products are also facilitating these activities by allowing for the data to
migrate into database structures without a rewrite of the on-line systems (see ADR's
V S A M and DL-1 transparency products). A future problem is the migration of data
-10-
f r o m data model to data model or from one D B M S to another. With long lasting,
easily recognized entities any future data migration will be much easier than the first
(r)evolution of flat file to database.
D a t a b a s e a n d a F a m i l y of P r o d u c t s
T h e nucleus of the database approach is the D B M S s o f t w a r e or hardware.
S o m e locales have adopted database technology only as a fancy "access" method,
not as a method to free data f r o m o w n i n g applications. The promise of the benefits
of subject databases will be realized only with the adoption of other database related
c a p a b i l i t i e s . Q u e r y l a n g u a g e s , r e p o r t w r i t e r s , d a t a d i c t i o n a r i e s , application
generators, statistical packages, statistical mapping packages, database utilities are all
necessary to take full advantage of the database approach. M o r e capability must be
placed in the hands of the ultimate end user of the data. T h e s e capabilities must
s u p p o r t staff n e e d s for a m u l t i t u d e of a d - h o c d a t a a n a l y s i s a n d i n f o r m a t i o n
retrievals.
W i t h the d e v e l o p m e n t of n e w generic applications, all reporting output
should be c o m p l e t e d with a r e p o r t writer. C o m p l e x analyses, appropriately
c o m p l e t e d by the sophisticated information user, also need to be supported with
q u e r y l a n g u a g e s a n d statistical/business g r a p h i c s p a c k a g e s . W i t h m o r e data
interrelated via s u b j e c t d a t a b a s e s , that h a v e c o m m o n l y d e f i n e d entities, the
i n f o r m a t i o n c o n t e n t available f r o m a given n u m b e r of data elements increases
logarithmically due to the many more possible combinations of the data!
Application generator s o f t w a r e is also needed as it permits a much faster
implementation of on-line systems. System m a i n t e n a n c e and extendibility is also
greatly e n h a n c e d with the use of application generators and screen handlers. Data
dictionaries provide for a controlling of the expensive data resource.
CONCLUSION
In this era of technological change, stability can be obtained by using data
s t r u c t u r e s that s u p p o r t d y n a m i c v i e w s of the d a t a . D y n a m i c s c o m e f r o m
o r g a n i z a t i o n a l c h a n g e , as w e l l as f r o m the c h a n g i n g h a r d w a r e / s o f t w a r e
e n v i r o n m e n t . Data structures built a r o u n d r e c o g n i z a b l e entities p r o m o t e an
i n t e r c h a n g e and s h a r i n g of data, n o t only b e t w e e n a p p l i c a t i o n s , but b e t w e e n
databases, too. The Land/Structure/Occupancy Database was described as a subject
database which epitomizes an advanced use of D B M S technology within the local
government data processing environment. The L/S/O is composed of geographically
specific entities which identify (and organize) the m a n y c o m m o n and unique data
elements that local government handles on a daily basis.
T h e L / S / O s u b j e c t d a t a b a s e a p p r o a c h , while p r o v i d i n g a l o n g e r r a n g e
planning architecture, provides many short-term benefits dealing with: Data Base
Administration, a realization of the tremendous a m o u n t of data r e d u n d a n c y and,
supports a generic system approach to implementing a d v a n c e d urban information
systems.
-
11 -
REFERENCES
(1) Applied Data Research. ADR DL-1 Transparency. Princeton, NJ: A D R , Inc..
1984.
(2) Durell, William R. Data Administration. N e w York, N Y : M c G r a w - H i l l . Co..
1985.
(3) Guthrie, James. "Issues In The Design And Implementation Of An Addressing
System Project For Address Coordination in Edmonton (PACE)". Papers From The
Annual C o n f e r e n c e of the Urban and Regional Information Systems Association.
Minneapolis, M N : 1982, pp. 254-267.
(4)
H D R Infrastructure, Inc. I n t e r a c t i v e C o m p u t e r G r a p h i c s / G e o g r a p h i c
Information System. Orlando/Orange County, FL, 1986, pp. IV6-IV7.
(5) Panel on a M u l t i p u r p o s e Cadastre. N e e d For A M u l t i p u r p o s e C a d a s t r e .
Washington, DC: National Academy Press, 1980.
-12-