21
1 1 1 1 1 A geographic data model is a representation of the real world that can be used in a GIS to produce maps, perform interactive queries, and execute analysis. Contemporary developments in database and software technology is enabling a new generation of geographic data models. These are the topics in this chapter: Modeling objects with GIS The progress of geographic data models The geodatabase, store of geographic data Features in an object-oriented data model Serving and accessing geographic data Building data models Viewing and designing geodatabases Guide to reading UML object diagrams Technology trends Object Object Object Object Object modeling and modeling and modeling and modeling and modeling and geodatabases geodatabases geodatabases geodatabases geodatabases D r a f t Modeling Our World The ESRI guide to GEOdatabase design ArcInfo 8.0 pre-release july 23, 1999 Copyright © 1999 Environmental Systems Research Institute, Inc. All rights reserved.

Object Modeling and Geodatabases chapter one - INPE · 12 • Modeling Our World—Draft for Pre-Release THE PROGRESS OF GEOGRAPHIC DATA MODELS A geographic data model is an abstraction

Embed Size (px)

Citation preview

9

11111A geographic data model is a representation ofthe real world that can be used in a GIS toproduce maps, perform interactive queries, andexecute analysis.

Contemporary developments in database andsoftware technology is enabling a newgeneration of geographic data models. Theseare the topics in this chapter:

• Modeling objects with GIS

• The progress of geographic data models

• The geodatabase, store of geographic data

• Features in an object-oriented data model

• Serving and accessing geographic data

• Building data models

• Viewing and designing geodatabases

• Guide to reading UML object diagrams

• Technology trends

ObjectObjectObjectObjectObjectmodeling andmodeling andmodeling andmodeling andmodeling andgeodatabasesgeodatabasesgeodatabasesgeodatabasesgeodatabases

123456789012345678901234567890121234567890123456789123456789012345678901234567890121234567890123456789123456789012345678901234567890121234567890123456789123456789012345678901234567890121234567890123456789123456789012345678901234567890121234567890123456789123456789012345678901234567890121234567890123456789123456789012345678901234567890121234567890123456789123456789012345678901234567890121234567890123456789123456789012345678901234567890121234567890123456789123456789012345678901234567890121234567890123456789123456789012345678901234567890121234567890123456789123456789012345678901234567890121234567890123456789123456789012345678901234567890121234567890123456789123456789012345678901234567890121234567890123456789123456789012345678901234567890121234567890123456789123456789012345678901234567890121234567890123456789123456789012345678901234567890121234567890123456789123456789012345678901234567890121234567890123456789123456789012345678901234567890121234567890123456789123456789012345678901234567890121234567890123456789123456789012345678901234567890121234567890123456789123456789012345678901234567890121234567890123456789123456789012345678901234567890121234567890123456789123456789012345678901234567890121234567890123456789123456789012345678901234567890121234567890123456789123456789012345678901234567890121234567890123456789123456789012345678901234567890121234567890123456789123456789012345678901234567890121234567890123456789123456789012345678901234567890121234567890123456789123456789012345678901234567890121234567890123456789123456789012345678901234567890121234567890123456789123456789012345678901234567890121234567890123456789123456789012345678901234567890121234567890123456789123456789012345678901234567890121234567890123456789123456789012345678901234567890121234567890123456789123456789012345678901234567890121234567890123456789123456789012345678901234567890121234567890123456789123456789012345678901234567890121234567890123456789123456789012345678901234567890121234567890123456789123456789012345678901234567890121234567890123456789123456789012345678901234567890121234567890123456789123456789012345678901234567890121234567890123456789

D r a f tModeling Our World

The ESRI guide toGEOdatabase design

ArcInfo 8.0pre-release

july 23, 1999Copyright © 1999

Environmental Systems Research Institute, Inc.All rights reserved.

10 • Modeling Our World—Draft for Pre-Release

The purpose of a Geographic Information System(GIS) is to provide a spatial framework to supportdecisions for the intelligent use of Earth’s resourcesand to manage the man-made environment.

Most often, a GIS presents information in the form ofmaps and symbols. Looking at a map gives you theknowledge of where things are, what they are, howthey can be reached through roads or othertransport, and what things are adjacent and nearby.A GIS can also disseminate information through aninteractive session with maps on a personalcomputer. This interaction reveals information thatis not apparent on a printed map.

For example, you can query all known attributes ofa feature, create a list of all things connected fromone point on a network to another, and performsimulations to gauge qualities such as water flow,travel time, or dispersion of pollutants.

The information display and analyis you wish tosupport depends upon how you model geographicobjects from the world.

MANY WAYS TO MODEL A SYSTEM

Our interaction with objects in the world is diverseand you can model them in many ways.

Consider one example, rivers. Rivers are interestingbecause they are natural features, they are used fortransportation, they delimit political or administrativeareas, and they are an important feature in theshape of a surface. Here are a few of the manyways you can think about modeling rivers in a GIS:

• As a set of lines that form a network. Eachsection of line has flow direction, volume, andother attributes of a river. You can apply a linearnetwork model to analyze hydrographic flow orship traffic.

• As a border between two areas. A river candelimit political areas such as provinces orcounties, or can be a barrier for natural regionssuch as wildlife habitats.

• As an areal feature with an accuraterepresentation of its banks, braids, and navigablechannels on the river.

• As a sinuous line forming a trough in a surfacemodel. From the river’s path through a surface,you can calculate its profile and rate of descent,the watershed it drains, and its flooding potentialfor a prescribed rainfall.

MAP USE GUIDES THE DATA MODEL

It’s clear that even a common type of geographicfeature such as a river can be represented in a GISin a variety of ways. No model is intrinsiclysuperior; the type of map you want to create andthe context of the problems to be solved will guidewhich model is best.

MODELING OBJECTS WITH GIS

Chapter 1 • Object modeling with geodatabases • 11

The geodatabase stores locators and addresses. A locator interpolates a location from an address using local postal conventions. You can finda geographic location for any address.

A network is a set of features that participate in a linear system suchas utility network, stream network,or road network. Networks are wellsuited for tracing analysis.

Rasters (images) are an efficient technology to capture large amounts of imaged data. They provide aninformative background display to feature layers on a map

Features are discrete objects on a map. Small objects are represented as points, long objects with lines and broad objects with polygons.

locationimage

surface

network

227 East Palace Avenue

representations of geographyfeatures

The earth's surface can be kept ina geodatabase in several forms; asa triangulated irregular network (TIN),as elevation values on pixels ina raster, or as contour lines.

12 • Modeling Our World—Draft for Pre-Release

THE PROGRESS OF GEOGRAPHIC DATA MODELS

A geographic data model is an abstraction of thereal world that employs a set of data objects tosupport map display, query, editing, and analysis.

ArcInfo 8 introduces a new object-oriented datamodel—the geodatabase data model—with thebenefit of representing natural behaviors andrelationships of features. To understand the impactof this new model, it is instructive to review threegenerations of geographic data models.

I THE CAD DATA MODEL

The very first computerized mapping systems drewvector maps with lines displayed on cathode raytubes and raster maps using overprinted characterson line printers. From this genesis, the 1960’s and70’s saw the refinement of graphics hardware andmapping software that could render maps withreasonable cartographic fidelity.

In this era, maps were typically created with generalpurpose CAD (Computer Aided Drafting) software.The CAD data model stored geographic data inbinary file formats with representations for points,lines, and areas. Scant information about attributeswas kept in these files; map layers and annotationlabels were the primary representation of attributes.

II THE COVERAGE DATA MODEL

In 1981, ESRI introduced its first commercial GISsoftware, ArcInfo, which implemented a secondgeneration geographic data model, the coveragedata model (also known as the georelational datamodel). This model has two key facets:

• Spatial data is combined with attribute data. Thespatial data is stored in indexed binary fileswhich are optimized for display and access. Theattribute data is stored in tables with a number ofrows equal to the number of features in thebinary tables and joined by a common identifier.

• Topological relationships between vector featurescan be stored. This means that the spatial datarecord for a line contains information aboutwhich nodes delimit that line, and by inference,which lines are connected, and also whichpolygons are on its right and left side.

The major advance of the coverage data model was

the ability for the user to customize feature tables;not only could fields be added, but database relatescould be set up to external database tables.

ArcPolygon

Labelpoint

Polygon Attribute Table

Arc Attribute Table

Point Attribute Table

Coverage Attributes in relational tables

Spatial data in relational tables

Due to the performance limitations of computerhardware and database software of the time, it wasnot practical to store spatial data directly in arelational database. Rather, the coverage data modelcombined spatial data in indexed binary files withattribute data in tables.

Despite this compromise of partitioning spatial andattribute data, the coverage data model has becomethe dominant data model in GIS. This has been forgood reason—the coverage data model made high-performance GIS possible and stored topologyfacilitated improved geographic analysis and moreaccurate data entry.

Limitations of the coverage data model

Yet, the coverage data model has an importantshortcoming—features are aggregated intohomogeneous collections of points, lines, andpolygons with generic behavior. The behavior of aline representing a road is identical to the behaviorof a line representating a stream.

The generic behavior supported by the coveragedata model enforces the topological integrity of adataset. An example is if you add a line across apolygon, it is automatically split into two polygons.

But it is desirable to also support the specialbehaviors of streams, roads, and other real-worldobjects. An example is that a stream flows in onedirection and when two stream segments combine,the flow of the downstream segment is the additionof the two upstream flows. Another example is thatwhen two roads cross, there ought to be a trafficintersection at their junction unless one of the roadsis an overpass or underpass.

Chapter 1 • Object modeling with geodatabases • 13

Customizing features in coverages

With the coverage data model, ArcInfo applicationdevelopers had some notable success in adding thistype of behavior to features through macro codewritten in the Arc Macro Language (AML). Manysuccessful, large-scale, industry-specific applicationswere built.

However, as applications became more complex, itbecame apparent there needed to be a better way toassociate behavior with features. The problem wasthat the developer had the task of keeping theapplication code in synchronicity with featureclasses—no easy task. The time had come for anew geographic data model with an infrastructureto tightly couple behavior with features.

III THE GEODATABASE DATA MODEL

ArcInfo 8 introduces a new object-oriented datamodel called the geodatabase data model. Thedefining purpose of this new data model is to letyou make the features in your GIS datasets smarterby endowing them with natural behaviors and toallow any sort of relationship to be defined amongfeatures.

The geodatabase data model brings a physical datamodel closer to its logical data model. The dataobjects in a geodatabase are mostly the sameobjects you would define in a logical data model,such as owners, buildings, parcels, and roads.

Further, the geodatabase data model lets youimplement the majority of custom behavior withoutwriting any code. Most behavior is implementedthrough domains, validation rules, and otherfunctions of the framework provided in ArcInfo.Writing software code is only necessary for themore specialized behaviors of features.

SCENARIOS OF OBJECT INTERACTIONS

To get a sense of why an object-oriented data modelis important, here are scenarios that illustratecommon tasks you might perform with features.From these scenarios, we’ll sift out the benefits ofan object-oriented data model and then reviewsome specific characteristics of the geodatabasedata model.

Adding and editing features

When you add geographic features to your GISdatabase, you want to ensure that features areplaced correctly according to rules such as these:

residentialagriculturalcommercialindustrial

table

row

column

• That the values that you assign to an attribute fallswithin a prescribed set of permissible values. Aparcel of land may only have certain land usessuch as 'residential', 'agricultural', or 'industrial'.

highway

transition

road

• That a feature can be placed adjacent orconnected to another feature only if certainconstraints are met. Placing a liquor store near aschool is not permitted by law. Or, a city roadcannot be connected to an highway without atransition segment such as an on-ramp.

• That collections of certain features conform totheir natural spatial arrangement. A streamsystem should always flow downhill. Flow downfrom a junction is the sum of flows upstream.

• That the geometry of a feature follows its logicalplacement. The lines and curves that make up aroad should be tangent. And, building cornersmost often form right angles.

14 • Modeling Our World—Draft for Pre-Release

Relationships among features

All objects in the world are entangled inrelationships with other objects. From theperspective of a GIS, these relationships can beconsidered to fall within three general categories;topological, spatial, and general.

These are some examples of each of these types ofrelationships:

• When you edit features in an electric utilitysystem, you want to be sure that the ends ofprimary and secondary lines connect exactly andthat you are able to perform tracing analysis onthat electric network. A set of topologicalrelationships are defined for you when loadingor editing features within a connected system.

• When you work with a map with buildings,blocks, and school districts, you might want todetermine which block contains a particularbuilding, the set of all buildings within a schooldistrict, and which blocks contain no buildings.A fundamental function of a GIS is to determinewhether a feature is inside, touching, outside, oroverlapping another feature. Spatial relationshipsare inferred from the geometry of features.

transformermeter

parcel

owner

• Some objects have relationships which are notpresent on a map. A parcel has a relationship toan owner, but the owner is not a feature on a

map. A general relationship connects the parceland the owner. Some features on a map haverelationships, but their spatial relationship isambiguous. A utility meter is in the generalvicinity of an electric transformer, but it is nottouching the transformer. The meter and thetransformer might not be reliably related by theirspatial proximity in crowded areas, so a generalrelationship ties the two features together.

Cartographic display

Most of the time, you will draw features on a mapwith pre-defined symbols, but sometimes you wantmore control over how your features are drawn.These are some specialized drawing behaviors:

5280

5280

• When you display a contour line, you want itselevation annotated along a flat section of thecontour, at an average interval such as fourinches, and not obscuring other features.

• When you draw roads on a detailed map, youwould like the road drawn as parallel lines withclean intersections wherever there is a roadintersection.

Circuit C

Circuit ACircuit B

Pole

• When multiple electrical wires are physicallymounted on the same set of utility poles, but youwould like to depict them as spread in a set ofparallel lines with a standard offset in map units.

Chapter 1 • Object modeling with geodatabases • 15

Interactive analysis

Dynamic map displays invite the user to touchfeatures and find properties, relationships, and tolaunch analyses. These are examples of some tasksyou may want to support upon selected features:

• Touch a feature on a map display and invoke aform to query and update its properties.

• Select a part of an electric network where linemaintenance is planned, find all affecteddownstream customers, and make a mailing listto notify them.

BENEFITS OF THE GEODATABASE DATA MODEL

The common thread throughout these scenarios isthat it is very useful to apply object-oriented datamodeling to features. Object-oriented data modelinglets you characterize features more naturally byletting you define your own types of objects, bydefining topological, spatial, and generalrelationships, and by capturing how these objectsinteract with other objects. Some of the benefits ofthe geodatabase data model are:

• A uniform repository of geographic data. All ofyour geographic data can be stored and centrallymanaged in one database.

• Data entry and editing is more accurate. Fewermistakes are made because most of them can beprevented by intelligent validation behavior. Formany users, this alone is a compelling reason toadopt the geodatabase data model.

• Users work with more intuitive data objects.Properly designed, a geodatabase contains dataobjects that corresponds to the user’s model of

data. Instead of generic points, lines, and areas,the user works with their objects of interest suchas transformers, roads, and lakes.

• Features have a richer context. With topologicalassociations, spatial representation, and generalrelationships, you not only define a feature’squalities, but its context with other features. Thislets you specify what happens to features whena related feature is moved, changed, or deleted.This context also lets you locate and inspect afeature that is related to another.

• Better maps can be made. You have more controlover how features are drawn and you can addintelligent drawing behavior. You can applysophisticated drawing methods directly inArcInfo’s mapping application, ArcMap. Highlyspecialized drawing methods can be executedthrough writing software code.

• Features on a map display are dynamic. Whenyou work with features in ArcInfo, they canrespond to changes in neighboring features. Youcan also associate custom queries or analytictools with features.

• Shapes of features are better defined. Thegeodatabase data model lets you use define theshapes of features using straight lines, circularcurves, elliptical curves, and Bezier splines.

• Sets of features are continuous. By their design,geodatabases can accomodate very large sets offeatures without tiles or other spatial partitions.

• Many users can edit geographic datasimultaneously. The geodatabase data modelsupports work flows where many people canedit features in a local area, and then reconcileany differences that emerge.

To be sure, you can realize some of these benefitswithout an object-oriented data model, but youwould be at a disadvantage—you would need towrite external code that would be loosely coupledto features and prone to complexity and error. Aprincipal advantage of the geodatabase data modelis that you have a framework that makes it as easyas possible to create intelligent features that mimicthe interactions and behaviors of real world objects.

16 • Modeling Our World—Draft for Pre-Release

A geodatabase can contain four representations ofgeographic data:

• vector data for representing features,

• raster data for representing images, griddedthematic data, and surfaces,

• triangulated irregular networks (TINs) forrepresenting surfaces, and

• locators and addresses for finding a geographicposition from an address.

A geodatabase stores all of these representations ofgeographic data in a commercial relationaldatabase. This lets geographic data be administeredcentrally by information technology professionalsand allows ArcInfo to leverage and keep pace withdevelopments in database technology.

REPRESENTING FEATURES WITH VECTORS

Many of the features in the world have well definedshapes. Vector data represents the shapes offeatures precisely and compactly as an ordered setof coordinates with associated attributes. Thisrepresentation supports geometric operations suchas calculating length and area, identifying overlapsand intersections, and finding other features whichare adjacent or nearby.

Vector data can be classified by dimension:

• Points are zero-dimensional shapes representgeographic features too small to be depicted aslines or areas. Points are stored as a single x,ycoordinate with attributes.

• Lines are one-dimensional shapes that representgeographic features too narrow to depict areareas. Lines are stored as a series of ordered x,ycoordinates with attributes. The segments of aline can be straight, circular, elliptical, or splined.

• Areas are two-dimensional shapes that representbroad geographic features that are stored as aseries of segments that enclose an area. Thesesegments form a set of closed areas.

Another type of vector data is annotation. These aredescriptive labels that are associated with features todisplay names and attributes.

THE GEODATABASE, STORE OF GEOGRAPHIC DATA

Vector data in a geodatabase has a structure thatdirects the storage of features by their dimensionand relationships. A feature dataset is the containerof spatial entities (features), non-spatial entities(objects), and the relationships between them.Topological associations are represented withgeometric networks and planar graphs.

A geodatabase also stores validation rules anddomains to ensure that when features are created orupdated, their attributes remain valid in the contextof related features and objects.

REPRESENTING GRIDDED DATA WITH RASTERS

Much of the data collected in a geodatabase is ingridded form. This is because cameras and imagingsystems record data as pixel values in a two-dimensional grid, or raster.

A pixel is a cell element of a raster and its valuescan depict a variety of data. A pixel can store thereflectance of light for part of the spectrum, a colorvalue for a photograph, a thematic attribute such asvegetative type, or surface value, or elevation.

REPRESENTING SURFACES WITH TINS

A triangulated irregular network (TIN) is a model ofa surface. A geodatabase stores TINs as anintegrated set of nodes with elevations and triangleswith edges through which an elevation (or z value)can be interpolated for any point within thegeographic extent of a TIN.

TINs enable surface analysis such as watershedstudies, visibility of a surface from an observationpoint, and delineation of surface features such asridges, streams and peaks. TINs can also depict thephysical relief of terrain.

Note: In ArcInfo 8.0, a geodatabase does not yet storeTINs. For the interim, TINs can be stored in coverageworkspaces.

FINDING ADDRESSES WITH LOCATORS

Perhaps the most common geographic task is tolocate a place by an address. A geodatabase canstore locators and addresses. Locators are methodsthat apply national postal conventions to convert anaddress to a position. You can interact with thesepoints as any other point feature on the map.

Chapter 1 • Object modeling with geodatabases • 17

inside a geodatabaseGeodatabase

Feature datasets

Coordinate system

Geometric networks

Planar graphs

Domains

Raster datasets

Rasters

Validation rules

Locators

Addresses

77 Sunset

rastersurface

vector

location

Raster datasets can represent an imaged map, a surface, anenvironmental attribute sampled on a grid, or photographs ofobjects referenced to features. Some raster data is collectedin bands which commonly represent different spectralranges of camera filters.

TIN datasets are triangulations of sets of irregularly locatedpoints with z-values (elevations) sampled from a surface.TINs are most often used to model the Earth's surface, butare also used to study the distribution of a continuousenvironmental factor such as chemical concentration.

Corporate and agency databases have many records withaddresses. These addresses can be located within ageodatabase. A locator is a method to convert an address toa geographic position. The found locations are displayed asfeatures on the map.

topology

data integrity

entitiesrelationships

Feature classes , subtypes

Object classes , subtypes

Relationship classes

A feature dataset contains objects and features and therelationships among them. An object is a non-spatial entityand a feature is a spatial entity. A relationship links twoentities.

Objects of the same kind are stored in a object class.Features of the same kind and with the same type ofgeometric shape are stored in a feature class.

A relationship class stores relationships between entities intwo object or feature classes.

A

Geometric networks model linear systems such as utilitynetworks and transportation networks. They support a richset of network tracing and solving functions.

Domains are sets of valid attribute values for objectattributes. They can be textual or numeric.

Validation rules enforce data integrity through relationshiprules and connectivity rules.

can be

inside or

outside of

feature

datasets

spatial referenceAll feature classes in a feature dataset share a commoncoordinate system. Because the feature dataset is thecontainer of topological associations, it is important toguarantee a common spatial reference.

Planar graphs model systems of line and area features as acontinuous coverage of an area. Planar graphs allowsfeatures to share common boundaries, such as countiessharing an outer boundary with a state.

TIN datasets

nodes edges

faces

18 • Modeling Our World—Draft for Pre-Release

FEATURES IN AN OBJECT-ORIENTED DATA MODEL

What differentiates ArcInfo 8 from antecedentreleases is that object-oriented methodology isapplied to geographic data modeling. A developerinteracts with data objects through a framework ofobject-oriented software classes called thegeodatabase data access objects.

There are three key hallmarks of object-orientation:polymorphism, encapsulation, and inheritance.

• Polymorphism means that the behaviors (ormethods) of an object class can adapt tovariations of objects. An example of this is thatthe core behavior of features, such as draw, addor delete operations, is mostly the same whetherthe features reside in a geodatabase, coverage, orshapefile.

• Encapsulation means that an object is accessedonly through a well-defined set of softwaremethods, organized into software interfaces. Thegeodatabase data access objects mask theinternal details of data objects and provide astandard programming interface.

• Inheritance means that an object class can bedefined to include the behavior of anotherobject class and have additional behaviors. Youcan create custom feature types in ArcInfo andinherit the behavior of standard features. Forexample, a transformer object can be extended(or sub-typed) from a standard ArcInfo featuretype such as a simple junction feature.

UNIFIED DATA MODEL

The geodatabase data access objects is a softwaretechnology that provides uniform access togeographic data from several data sources such asgeodatabases, coverages, and shapefiles.

ArcInfo developers interact with geographic datathrough a set of data objects, such as datasets,tables, feature classes, rows, objects, and features.These objects comprise a common and consistentview of geographic data.

Because of this unified data model, the ArcInfouser can work with geodatabases, coverages, andshapefiles in the same way. The unified data modelsimplifies how users work with data by emphasizingthe common characteristics of data.

EXTENSIBLE FEATURES

An important aspect of a geodatabase is that youcan optionally create custom features such astransformers and roads, instead of points and lines.

To the ArcInfo user, this means that a transformeror road has all of the standard display, query, andedit behavior of standard point features and linefeatures, but with additional behaviors. You canspecify that a transformer must be drawn touchinga power pole and perpendicular to the electric linethrough the pole. Or, when a road is edited, all ofits segments must be tangent.

A data modeler can use standard feature types toimplement a rich data model. For advancedapplications, a developer can extend the standardfeature types and create custom features using theobject-oriented technique of type inheritance.

Any custom feature that you create enjoys the sameperformance and functionality as the standardfeature types provided by ArcInfo. This offerslimitless opportunities for sophisticated applicationdevelopment.

FEATURES AND OBJECT-ORIENTATION

Features in a geodatabase are implemented as a setof relational tables. Some of these tables representcollections of features. Other tables representrelationships between features, validation rules, andattribute domains.

ArcInfo manages the structure and integrity of thesetables and presents an object-oriented geographicdata through the geographic data access objects.

All users and most developers will neither know norcare about the details of the internal structure of ageodatabase. The ArcCatalog application is youruser interface to establish, modify, and refine thestructure of your geodatabase.

The object view of data lets you focus your effortson building a geographic data model and hidesmost of the physical database structure of thegeodatabase. For more information on the physicalimplementation of geodatabases, read the [SDEconceptual guide].

Chapter 1 • Object modeling with geodatabases • 19

data components

data sources

ArcInfoapplications

geodatabase data access objects

geodatabase coverage shapefile

Junction-Feature

Simple-Junction-Feature

Complex-Junction-Feature

Transformer Switch SwitchGear-Cabinet

custom feature

types

standardfeature

types

Data can be viewed in three ways.

The relational table view of data exposes the internal details of the

physical storage as database tables.

The simple feature view presents datain the form of features without the

structure of topology and relationships.

The object view of data encapsulates the internal details and presents a

higher level of structure that is closer to the user's conceptual model of data.

The geodatabase data access objects includea number of software components that represent

the types of features that are ready for use.Shown here are some of the network feature

types. These have intrinsic behavior thatguarantee the topological integrity of features in a geometric network. Most data modelersuse standard feature types without extending

them through custom programming.

ArcInfo is versatile atdisplaying and analyzing

geographic features.ArcInfo supports a number

of data sources, amongthem geodatabases,

coverages and shapefiles.

features in a geodatabase

The geodatabase dataaccess objects are a

programming interfacethat largely hides any

differences among featuretypes from geodatabases,

coverages, and shapefiles.

These are some custom features which have been extended from the standard

feature types. They implementspecialized behaviors for custom

applications developed by data modelers and programmers.

unified data model

extensible features

data access

polymorphism

inheritance

encapsulationFeature-Dataset Table

Dataset

RelationshipClassObjectClass

Feature-Class

object view of data

relational table

geometry column

rules, domains

relationships

attributecolumns

relational tableview of data

simple feature view of data

points

lines

polygons

geometric shapes with attributes

20 • Modeling Our World—Draft for Pre-Release

SERVING GEOGRAPHIC DATA

ArcInfo accesses geographic data served throughArcSDE, the Arc Spatial Database Engine. ArcSDE isthe software technology that enables you to creategeodatabases that range from small to very largesets of geographic data and provides an openinterface to the relational database of your choice.

HOW A GEODATABASE EXTENDS A DATABASE

These are some of the facets of a geodatabase thatenhance relational database technology:

• A geodatabase can represent geographic data infour manifestations: discrete objects as vectorfeatures, continuous phenomena as rasters,surfaces as TINs, and references to places aslocators and addresses.

• A geodatabase stores shapes of features andArcInfo provides functions for performing spatialoperations such as finding objects that arenearby, touch, or intersect. A geodatabase has aframework for defining and managing thegeographic coordinate system for a set of data.

• A geodatabase can model topologicallyintegrated sets of features such as transportationor utility networks and subdivisions of landbased on natural resources or land ownership.

• A geodatabase can define general and arbitraryrelationships between objects and features.

• A geodatabase can enforce the integrity ofattributes through domains and validation rules.

• A geodatabase can bind the natural behavior offeatures to the tables which store features.

• A geodatabase can present multiple versions sothat many users can edit the same data.

PERSONAL AND MULTI-USER GEODATABASES

Geodatabases comes in two variants—personal andmulti-user.

Personal geodatabase support is built into ArcInfoand is suitable for project-oriented GIS. A personalgeodatabase is implemented as a Microsoft Accessdatabase. When you install ArcInfo, Microsoft Jet isalso installed, which provides the services forArcInfo to create and update Access databases. Youdo not need to separately install Microsoft Access.

For large enterprises, you can deploy multi-usergeodatabases with ArcSDE—the multi-user dataaccess extension to ArcInfo. ArcSDE is installed ona data server that administers your organization’srelational database. Through a TCP/IP network,ArcSDE serves geodatabases to the ArcInfoapplications running on personal computers.ArcSDE can be deployed on Windows NT or UNIX.

ArcSDE allows remote access to geographic dataand allows many users to view and edit the samegeographic data. ArcSDE is centrally tuned andmanaged by your database administrator.

AN OPEN AND SCALABLE DATA SERVER

ArcInfo allows you to configure and deploy smallto very large geodatabases. If you are working withmoderately sized datasets, you can deploy personalgeodatabases in ArcCatalog. This configurationyields good performance for datasets up toapproximately 250,000 objects and supports oneeditor and several simultaneous viewers.

For more demanding datasets and to support manyconcurrent editors, you can deploy the ArcSDEextension to ArcInfo on the relational database bestsuited for your organization.

These are some reasons to add the ArcSDEextension to your ArcInfo installation:

• You have limitless flexibility in scaling databases.

• You can deploy the relational database of yourchoice.

• You can serve geographic data from UNIX orWindows NT.

• You can serve data to other applications such asMapObjects, ArcIMS (Arc Internet Map Server),ArcView, and CAD client applications.

• You can centrally store and administergeodatabases.

• You can build Open GIS Consortium (OGC)compliant applications.

• You can build SQL applications to access thetables and rows in a geodatabase.

Chapter 1 • Object modeling with geodatabases • 21

Geodatabase

Feature dataset

Feature class

Feature class

Relationship class

Geometric network

Feature class

Geodatabase

Feature dataset

Feature class

Feature class

Feature class

Object class

Relationship class

Geodatabase

Object class

Relationship class

Feature class

Feature class

Feature class

Object class

open data frameworkgeographically enhanced

databasesGeodatabase

Raster datasetRaster

Feature class

Raster datasetRaster

A personal geodatabase isdirected towards personal orsmall work-group use. It canhandle small to moderately

sized datasets.

A geodatabase served through ArcSDE can manage very large sets of geographicdata and serve large numbers of viewers and editors. Geographic data is

accessed from a data server on a network. This GIS data is centrally administeredin large databases and integrates well with other corporate data. These databases

require a system administrator for permissions, tuning, and optimization.

Personal geodatabases areimplemented on the Microsoft

Jet engine which stores data asAccess databases.

ArcSDE operates on any leading relational database. The ArcInfo developer caninteract with a geodatabase through the geodatabase data access objects. A

developer can access an ArcSDE geodatabase outside of ArcInfo through a C API(application programmer interface) or a SQL API.

To model work flow processes, a geodatabase served through ArcSDE supportslong transactions and version management. A versioned geodatabase allowsmany editors to work concurrently and includes a framework for resolving edit

conflicts.

A personal geodatabase has all thefunctionality of a geodatabase

served through ArcSDE, except forversioning.

Geodatabases on any supported relational database operate identically.

relational databases

Personalgeodatabase

Personalgeodatabasesupport is built intoArcInfo andprovides access tolocal data.

ArcSDE

ArcSDE is a technology that uses thenative data types and operators in arelational or object-relational databaseand extends them to provide the completefunctionality of a geodatabase.

project GIS enterprise GIS

Geodatabase

LocatorAddresses

TIN dataset

Object class

A geodatabase is aninstance of a relational or

object-relational databasethat has been enhanced

by adding geographic datastorage, referential

integrity constraints, mapdisplay, feature editing,and analysis functions.

ArcSDE is the multi-user extension to ArcInfo

Access Oracle 8SQL

ServerInformix DB2 Others

22 • Modeling Our World—Draft for Pre-Release

ACCESSING GEOGRAPHIC DATA

A developer can access data in a geodatabase atthree basic levels:

• Through the geodatabase data access objects, asubset of ArcObjects, the software componentson which the desktop ArcInfo applications arebuilt.

• As simple non-topological features through theArcSDE API that complies with the Open GISConsortium simple feature specification.

• As raw rows, columns, and tables through thenative SQL interface of the relational database.

ACCESSING DATA THROUGH ARCOBJECTS

The richest level of accessing geographic data isthrough the geodatabase data access objects. At thislevel, the full structure of a geodatabase is revealed;topology, relationships, integrity rules, behavior, aswell as raster, surface, and location representations.

You can programmatically access data throughArcObjects using Visual Basic for Applications(VBA) inside ArcInfo or with Visual C++ or anyother COM compliant development environment.

This is a simplified UML diagram of a portion of thegeodatabase data access objects in ArcObjects. Thismodel is discussed further in Chapter 4, Thestructure of geographic data.

Feature-Dataset

Table

Geometric-Network

GeoDataset

Rule

1..*

1..* 1..*

Attributed-Relationship-

Class

RelationshipClass

ObjectClass

Feature-Class

Graph

WorkspaceDomain

Dataset

Raster-Dataset

TinDataset

0..1

ACCESSING DATA AS SIMPLE FEATURES

For many spatial applications, it is sufficient anddesirable to access geographic data in the form ofsimple non-topological features. This approach isespecially suitable for building integratedapplications for which geographic data is a vitalcomponent, but perhaps not the focus. Examplesinclude facilities management and traffic analysis.

ArcSDE exposes a simple feature applicationprogrammer interface (API) in C and Java that iscompliant with the Open GIS Consortium (OGC)simple features specification.

OGC is an organization that includes all of theleading spatial data vendors and has the purpose ofdeveloping standard software interfaces for the freeexchange of spatial information amongheterogeneous geographic information systems.

Organizations that have geographic data in variousformats on a networks can build applications thatintegrate this data in the form of simple features.

ESRI is a leading contributor to the OGC technicalspecifications and is committed to the openinterchange of geographic data.

ACCESSING DATA THROUGH SQL

A geographic information system is a rich repositoryof data about natural features or facilities such astransportation or utility networks. While this data iscollected and managed as a geodatabase, externaldatabase applications can effectively access andshare this data for non-geographic use.

Using the native SQL interfaces of your relationaldatabase, you can build applications to mine datafrom your geodatabases and use them for taskssuch as managing inventory, processing workorders, or statistical analysis.

In this view, a geodatabase is a set of tables, rows,and columns. Through the SQL interfaces, you cansee the internal database structure of a geodatabase,which includes metadata tables for objects such asnetworks. This structure is not directly visible inArcInfo and is managed through the user interfaceof ArcCatalog. You can selectively update attributesof rows that represent features, but you should takecare not to corrupt the structure of the geodatabase.

Chapter 1 • Object modeling with geodatabases • 23

accessing geodatabases

ArcInfo is a general purpose GIS application withadvanced editing and map display, spatial analysis, andtopological processing. Through ArcInfo, features inyour geodatabase act with full object awareness asexpressed with domains, validation rules, and customcode. The developer uses the geodatabase dataaccess objects in Visual Basic, Visual C++, or otherCOM compliant development environment.

relational databases

Personal geodatabase ArcSDE

GIS applications

spatial applications

Access Oracle 8SQL

ServerInformix DB2 Others

through thegeodatabasedata accessobjects inArcInfo,ArcSDE

throughArcSDE API,OGC SimpleFeatures API

through SQLinterface inrelationaldatabases

Some applications process spatial queries from a largegeodatabase and serve highly specialized functions.Examples are emergency response and businesslocation. Geodatabases can be accessed as simplefeatures though the ArcSDE simple feature API. Thisincludes both C and Java APIs. ArcSDE's simplefeature API is open and adheres to the OGC simplefeature specification. This allows features in ageodatabase to be used outside of ArcGIS applications.

Database applications sometimes need to extract datafrom a geodatabase, but not to display or spatiallyprocess that data. An example would be to pull or joinutility pole attributes from a geodatabase to a relationaldatabase so that an inventory can be taken. Thedatabase programmer can interact with the tables in ageodatabase through the native SQL interfaces. Thedeveloper should refrain from modifying any geographicshapes or geodatabase system tables.

database applications

Geometry

Multipoint

Segment

CircularArc

CurvePoint

EllipticArc

BezierCurve

Line

Polycurve

Polyline

Polygon

Ring

Path

Spatialapplicationdeveloper

Geodatabase

Object class

Relationship class

Feature class

Feature class

Raster datasetRaster

ArcInfodeveloper

Databasedeveloper

Developers can access a geodatabase through thegeodatabase data access objects in ArcInfo, through APIsthat expose simple features, or by the internal tables.Geodatabase

24 • Modeling Our World—Draft for Pre-Release

Designing a geodatabase is fundamentally the sameas designing any database. That’s because ageodatabase is an instance of a relationaldatabase—albeit one that contains a structure forrepresenting geographic data.

The geodatabase extends, yet simplifies, the designprocess by presenting an object-oriented datastructure that expresses the spatial and topologicalrelationships of geographic features. Part of thisstructure is a special facility for representing sets ofobjects as integrated systems—such as stream androad networks or sets of land parcels. This structureon a set of features is called topology.

The geodatabase data model is the bridge betweenpeople’s cognitive perception of the objectssurrounding them in the world and how thoseobjects are stored in relational databases.

GEODATABASE DESIGN

Traditional relational database design spans twobasic steps—the articulation of a logical data modeland the physical implementation of databasemodels (or schemas).

The logical data model captures the user’s view ofdata and the database model implements the datamodel within the framework of relational databasetechnology.

Designing a logical data model

The key task in building a logical data model is toprecisely define the set of objects of interest and toidentify the relationships between them.

Some examples of objects you might consider arestreets, parcels, owners, and buildings. Someexamples of their relationships are ‘located at’,‘owned by’, and ‘is part of’.

Once you have an initial logical data model, youcan validate it against the user’s requirements forentering, updating, and accessing data and bytesting it against the organization’s practices andprocedures (or, business rules).

It is especially important to involve representativesfrom each prospective user group. A logical datamodel built for a subset of users is guaranteed to

have deficiencies for overlooked users.

Building a logical data model is an iterative processand is an art that is acquired through experience.There is no single ‘correct’ model, but there aregood models and bad models. It’s difficult todetermine precisely when a model is correct andcomplete, but an indication that you are drawingclose is when you can answer these questions inthe affirmative:

• Does the logical data model represent all datawithout duplication?

• Does the logical data model support anorganization’s business rules?

• Does the logical data model accomodatedifferent views of data for distinct groups ofusers?

Representing logical data models

In the past, logical data models were often drawn inwhat are known as ‘entity-relationship diagrams’. Anumber of leading object-oriented modelers putforward various design methodologies and diagramnotations.

These methodologies emphasized different aspectssuch as data flow or use-case scenarios, but aproblem with entity-relationship diagrams is thattheir appearance varied with the designmethodology.

More recently, most object-oriented modelers haveadopted the Unified Modeling Language (UML),which is a standard notation for expressing objectmodels and is endorsed by leading software anddatabase companies.

It is important to note that UML is not a designmethodology, but rather a diagrammatic notation.With UML, you can adopt the object-orienteddesign methodology of your choosing and thenexpress the model in a standard way with UML.

This book uses UML for drawing ArcInfo’s objectmodel, called ArcObjects, and for drawing thecustom object models you can create in ageodatabase.

BUILDING DATA MODELS

Chapter 1 • Object modeling with geodatabases • 25

Implementing a physical database model

A physical database model is built from the logicaldata model. Typically, a specialist in relationaldatabases receives the logical data model from thedata modeler and uses the database administrationtools to define the database schema and create newdatabases ready for data transfer and entry.

The physical database design has some similarity tothe logical data model, but there are differences.Classes of objects may be split or joined whenimplemented in tables. Rules and relationships canbe expressed in several ways.

An important benefit of the geodatabase is that it isa physical implementation of data, but it lets youstructure your data in a fashion that is close to thelogical data model.

Elements of the logical and database models

These are the basic elements of the logical datamodel and their corresponding database elements.

Object

Attribute

Class

Row

Column, Field

Table

Database elementsLogical elements

A logical data model is an abstraction of the objectsthat we encounter in a particular application. Thisabstraction is converted into database elements.

An object represents an entity such as a house,lake, or customer. An object is stored as a row.

An object has a set of attributes. Attributescharacterize qualities of an object, such as its name,a measure, a classification, or an identifier (or key)to another object. Attributes are stored in a databasein columns (or fields).

A class is a set of similar objects. Each object in aclass has the same set of attributes. A class is storedin a database as a table. The rows and columns ina table form a two-dimensional matrix.

Handling complex data

Relational databases enjoy their commercialdominance because they implement a simple,elegant and well understood theory. This simplicityis at once a strength and a weakness—it isconceptually straight-forward to build relationaldatabases, but difficult to model complex data.

Geographic databases contain complex data. Theshapes of line and area features are structured setsof coordinates that cannot be well represented withstandard atomic field types such as integer, real,string. Further, features are gathered into systemsthat have explicit topological relationships, implicitspatial relationships, or general relationships.

The relational database is the foundation for ageodatabase. A key purpose of the geodatabase isto handle the complexity of geographic data with auniform data model independent of the relationaldatabase underneath.

Chapter 12, Geodatabase design guide, returns tothese topics in the context of designing andbuilding geodatabases.

logical data modelreality

database implementation

Building

LandParcel

Person building

person

ownership

parcel

A logical data model is constructed torepresent the objects of interest to an

application.From the logical data model,a database model is built in

a relational database.

26 • Modeling Our World—Draft for Pre-Release

GUIDELINES FOR GEODATABASE DESIGN

The structure of a geodatabase—feature datasets,feature classes, topological groupings, relationships,and other elements—lets you design geographicdatabases that are close to their logical data models.For a data modeler, this is the essential reason forthe introduction of geodatabases into ArcInfo 8.

These are the basic steps to design a geodatabase:

• Model the user’s view of data. Perform interviewswith users, understand an organization’sstructure, and analyze the business requirements.

• Define objects and relationships. Build the logicaldata model with the set of objects and how theyare related to one another.

• Select geographic representation. Determinewhether vector, raster, surface, or locationrepresentation is best for the data of interest.

• Match to geodatabase elements. Fit the objects inthe logical data model into the elements of ageodatabase.

• Organize geodatabase structure. Build thestructure of a geodatabase with consideration ofthematic groupings, topological associations, anddepartment responsibility of data.

This topic is discussed in greater detail in Chapter12, Geodatabase design guide.

steps to building a geodatabase

Building

LandParcel

Person

Geodatabase

Feature dataset

Geometric network

Feature class

123

45

model the user's view of data

define objects and relationships

select geographic representation

match to geodatabase elements

organize geodatabase structure

identify organizational functionsdetermine data needed to support functionsorganize data into logical groupings

identify and describe objectsspecify relationships between objectsdocument model in diagram

represent discrete features with points, lines, areascharacterize continuous phenomena with rastersmodel surfaces with TINs or rasters

determine geometry type of discrete featuresspecify relationships between featuresimplement attribute types for objects

organize systems of featuresdefine topological associationsassign coordinate systemsdefine relationships and rules

Chapter 1 • Object modeling with geodatabases • 27

GUIDE TO READING UML OBJECT DIAGRAMS

You can approach ArcInfo in two ways; as a userof applications such as ArcMap and ArcCatalog oras a software developer building customapplications.

Data modelers straddle these two worlds—you usethe applications for most of your work in creatinggeodatabases, but you will sometimes write softwarecode, especially if you are trying to create rich datamodels that support powerful applications.

One aim of this book is to present the importantdata modeling concepts both as they are applied inthe ArcInfo applications and the ArcInfo softwarecomponents, which are called ArcObjects.

A pattern through this book is to first present theconcepts for a topic as you experience it through theArcInfo application. Next, that topic is summarizedwith an annotated diagram of the relevant section ofthe ArcInfo object model diagram.

An example of this presentation is that the topic ofthe structure of geodatabases, feature datasets, andfeature classes is first discussed with the user’sperspective of the catalog. Next, the programmer’sperspective is summarized with a diagram of part ofthe geodatabase data components.

These two views have similarities, but subtledifferences. A user interface sometimes hides detailsabout software components that are important to theprogrammer. One goal of this book is to give youthe insight to bridge the user and developerperspectives.

Reading the class diagrams

This is the key for the object model diagrams youwill find throughout this book.

Abstract-Class

InstantiableClass

Typeinheritance

Instantiation

Association

Aggregation

Composition

1..*

Multiplicity

CreateableClass

This notation is based on the UML (UnifiedModeling Language) notation, an industrydiagramming standard for object-oriented analysisand design.

The object model diagrams are an importantsupplement to the information you receive in objectbrowsers. The development environment, VisualBasic or other, lists all of the many classes andmembers, but does not hint at the structure of thoseclasses. These diagrams complete yourunderstanding of the ArcInfo components.

This book uses UML to document the ArcInfosoftware components, ArcObjects, and to illustratecustom data models that you can build.

Classes and objects

There are three types of classes shown in the UMLdiagrams—abstract classes, createable classes, andinstantiable classes.

An abstract class cannot be used to create newobjects, but it is a specification for subclasses. Anexample is that a ‘line’ could be an abstract classfor ‘primary line’ and ‘secondary line’ classes.

A createable class represents objects that you candirectly create using the object declaration syntax inyour development environment. In Visual Basic,this is written with the Dim As New <object> orCreateObject(<object>) syntax.

An instantiable class cannot directly create newobjects, but objects of this class can be created as aproperty of another class or created by functionsfrom another class.

In the Visual Basic object browser, you can inspectall of the ArcInfo createable and instantiableclasses, but not the abstract classes.

Relationships

Among abstract classes, createable classes, andinstantiable classes, there are several types of classrelationships possible.

Associations represent relationships between classes.They have defined multiplicities at both ends.

28 • Modeling Our World—Draft for Pre-Release

1..*1..*Owner Land parcel

In this diagram, an owner can own one or manyland parcels and a land parcel can be owned byone or many owners.

A Multiplicity is a constraint on the number ofobjects that can be associated with another object.This is the notation for multiplicities:

1 - One and only one. Showing this multiplicity isoptional; if none is shown, ‘1’ is implied. 0..1 - Zero or one M..N - From M to N (positive integers)

* or 0..* - From zero to any positive integer 1..* - From one to any positive integer

Type inheritance defines specialized classes whichshare properties and methods with the superclassand have additional properties and methods.

Line

PrimaryLine

SecondaryLine

This diagram shows that a primary line (createableclass) and secondary line (createable class) aretypes of a line (abstract class).

Instantiation specifies that one object from oneclass has a method with which it creates an objectfrom another class.

TransformerPole

A pole object might have a method to create atransformer object..

Aggregation is an asymmetric association in whichan object from one class is considered to be a‘whole’ and objects from the other class areconsidered ‘parts’.

TransformerBank

Transformer3

A transformer bank has exactly three transformers.In this design, transformers can be associated witha transformer bank, but may also exist after thetransformer bank is removed.

Composition is a stronger form of aggregation inwhich objects from the ‘whole’ class control thelifetime of objects from the ‘part’ class.

CrossarmPole1..*

A pole contains one or many crossarms. In thisdesign, a crossarm cannot be recycled when thepole is removed. The pole object controls thelifetime of the crossarm object.

Expressing models with diagram notation

If you are unaccustomed to this type of diagramnotation, practice reading the examples above andconceive of your own examples. Before long, you’llread these diagrams with ease.

You’ll find that it is worth your effort to understandthis notation. It describes object models in a conciseand expressive way and will facilitate yourconceptual understanding of the ArcInfo softwarecomponents.

Understanding this notation is also critical if youcreate custom features by extending thegeodatabase data access objects. With ArcCatalog,you can launch a CASE environment to createcustom data models with a visual user interface.This interface is based on manipulating graphicalsymbols from the UML notation.

Chapter 1 • Object modeling with geodatabases • 29

TECHNOLOGY TRENDS

A geographic information system is at its core adatabase management system enhanced to store,index, and display geographic data.

ArcInfo 8 is a significant release of new GIStechnology that exploits several importanttechnology trends just as they have become readyfor commercial implementation. These trendscollectively realize the vision of GIS as ageographically-enabled database.

The timing of ArcInfo 8 is fortuitous as it occursduring the convergence of several criticaldevelopments in software and database technology.These are the principal trends that shape thetechnological framework of ArcInfo 8.

Spatial data and databases

When the coverage data model was firstimplemented, practical considerations led to thespatial component of geographic data beingcontained in binary files with unique identifiers torows in relational database tables that stored featureattributes.

With performance and functional advances indatabase technology, it is now possible andadvantageous to store all spatial data directly withinthe same database tables as attribute data.

The gain from storing spatial data directly withincommercial databases is improved dataadministration, the utilization of data access andmanagement services, and closer integration with theother databases that an organization manages.

Moreover, the ArcInfo user can select from any ofthe industry-leading relational databases to host theirgeographic databases.

User interface

Applications developed for Microsoft Windows haveset a new standard for ease-of-use and consistency.Users have become accustomed to expectedbehaviors for mouse interaction, menus, dialogs, andthe like. These user interface standards have madepowerful applications accessible and usable bypeople who are not computer experts.

ArcInfo 8 thoroughly implements the Windows

standards for user interface and stands as a newmilestone in making GIS software easier to use.

Software component architecture

Modern software is built on software componentarchitectures, examples of which are Microsoft COM(Component Object Model), CORBA (CommonObject Request Broker Architecture), and Java RMI(Remote Method Invocation).

The idea behind components is to divide softwarefunctionality into discrete, independent pieces thatcan be developed, tested, and combined intoprograms. By their design, components can be usedto build any number of applications withoutmodification. This is a high level of software re-use.

The benefit of software component architectures isbetter software quality, better performance, and theability to update software versions without affectingother installed software.

ArcInfo 8 is built on the Microsoft COM architecturebecause it is the most robust and reliablecomponent framework for desktop applications.

Programming environment

Visual programming environments such as VisualBasic have become the norm for applicationdevelopment.

The benefits of using these languages are the largepool of experienced programmers and the richnessof these environments. It is no longer necessary ordesirable to use proprietary macro languages.

ArcInfo 8 uses Visual Basic for Applications as itsembedded macro language for customizing itsapplications, ArcMap and ArcCatalog. Other COMcompliant languages such as Visual C++ can beused to extend the geodatabase data model.

Trends in summary

The common theme of these technology trends isopen standards and interoperability.

The benefit of implementing these trends is toleverage technology from other segments whichenables ESRI to concentrate its research anddevelopment on core GIS functionality.