<%BANNER%>

Map Algebra

Permanent Link: http://ufdc.ufl.edu/UFE0022567/00001

Material Information

Title: Map Algebra A Data Model and Implementation of Spatial Partitions for Use in Spatial Databases and Geographic Information Systems
Physical Description: 1 online resource (126 p.)
Language: english
Creator: Mckenney, Mark
Publisher: University of Florida
Place of Publication: Gainesville, Fla.
Publication Date: 2008

Subjects

Subjects / Keywords: algebra, algorithms, databases, gis, graph, implementation, maps, modeling, plane, spatial, sweep, thematic, topological
Computer and Information Science and Engineering -- Dissertations, Academic -- UF
Genre: Computer Engineering thesis, Ph.D.
bibliography   ( marcgt )
theses   ( marcgt )
government publication (state, provincial, terriorial, dependent)   ( marcgt )
born-digital   ( sobekcm )
Electronic Thesis or Dissertation

Notes

Abstract: The idea of a map is a fundamental metaphor in spatial systems. For instance, in the fields of geographical information systems (GIS), spatial databases, geography, robotics, computer assisted design (CAD), and spatial cognition, the arrangement of spatial data into map form plays a primary role in the composition, representation, and analysis of spatial data. However, no models of maps currently exist that provide a precise definition of a spatial data type for maps and operations over them. Instead, many informal definitions are provided, many of which are tied to specific implementation concepts. Furthermore, although the integration of spatial databases into spatial fields such as GIS has received much attention, the notion of integrating maps into databases has been overlooked. Thus, the idea of integrating maps into SQL and performing queries over them has not yet been explored. This thesis describes the design and implementation of Map Algebra, a type system and operations for maps in spatial databases. We provide a three level approach to defining Map Algebra. First, we provide an abstract model of maps. This is a mathematical description of maps and their operations and topological predicates. This model is defined on formal mathematical concepts that are not implementable in computer systems; therefore, we then provide a discrete model of maps based on discrete concepts that can be translated to computer systems. We then provide an implementation model of maps, complete with algorithms to implement map operations, that can be directly implemented in a computer system. Furthermore, we develop a query language called Map Query Language that can be used to pose queries over maps in databases.
General Note: In the series University of Florida Digital Collections.
General Note: Includes vita.
Bibliography: Includes bibliographical references.
Source of Description: Description based on online resource; title from PDF title page.
Source of Description: This bibliographic record is available under the Creative Commons CC0 public domain dedication. The University of Florida Libraries, as creator of this bibliographic record, has waived all rights to it worldwide under copyright law, including all related and neighboring rights, to the extent allowed by law.
Statement of Responsibility: by Mark Mckenney.
Thesis: Thesis (Ph.D.)--University of Florida, 2008.
Local: Adviser: Schneider, Markus.
Electronic Access: RESTRICTED TO UF STUDENTS, STAFF, FACULTY, AND ON-CAMPUS USE UNTIL 2010-08-31

Record Information

Source Institution: UFRGP
Rights Management: Applicable rights reserved.
Classification: lcc - LD1780 2008
System ID: UFE0022567:00001

Permanent Link: http://ufdc.ufl.edu/UFE0022567/00001

Material Information

Title: Map Algebra A Data Model and Implementation of Spatial Partitions for Use in Spatial Databases and Geographic Information Systems
Physical Description: 1 online resource (126 p.)
Language: english
Creator: Mckenney, Mark
Publisher: University of Florida
Place of Publication: Gainesville, Fla.
Publication Date: 2008

Subjects

Subjects / Keywords: algebra, algorithms, databases, gis, graph, implementation, maps, modeling, plane, spatial, sweep, thematic, topological
Computer and Information Science and Engineering -- Dissertations, Academic -- UF
Genre: Computer Engineering thesis, Ph.D.
bibliography   ( marcgt )
theses   ( marcgt )
government publication (state, provincial, terriorial, dependent)   ( marcgt )
born-digital   ( sobekcm )
Electronic Thesis or Dissertation

Notes

Abstract: The idea of a map is a fundamental metaphor in spatial systems. For instance, in the fields of geographical information systems (GIS), spatial databases, geography, robotics, computer assisted design (CAD), and spatial cognition, the arrangement of spatial data into map form plays a primary role in the composition, representation, and analysis of spatial data. However, no models of maps currently exist that provide a precise definition of a spatial data type for maps and operations over them. Instead, many informal definitions are provided, many of which are tied to specific implementation concepts. Furthermore, although the integration of spatial databases into spatial fields such as GIS has received much attention, the notion of integrating maps into databases has been overlooked. Thus, the idea of integrating maps into SQL and performing queries over them has not yet been explored. This thesis describes the design and implementation of Map Algebra, a type system and operations for maps in spatial databases. We provide a three level approach to defining Map Algebra. First, we provide an abstract model of maps. This is a mathematical description of maps and their operations and topological predicates. This model is defined on formal mathematical concepts that are not implementable in computer systems; therefore, we then provide a discrete model of maps based on discrete concepts that can be translated to computer systems. We then provide an implementation model of maps, complete with algorithms to implement map operations, that can be directly implemented in a computer system. Furthermore, we develop a query language called Map Query Language that can be used to pose queries over maps in databases.
General Note: In the series University of Florida Digital Collections.
General Note: Includes vita.
Bibliography: Includes bibliographical references.
Source of Description: Description based on online resource; title from PDF title page.
Source of Description: This bibliographic record is available under the Creative Commons CC0 public domain dedication. The University of Florida Libraries, as creator of this bibliographic record, has waived all rights to it worldwide under copyright law, including all related and neighboring rights, to the extent allowed by law.
Statement of Responsibility: by Mark Mckenney.
Thesis: Thesis (Ph.D.)--University of Florida, 2008.
Local: Adviser: Schneider, Markus.
Electronic Access: RESTRICTED TO UF STUDENTS, STAFF, FACULTY, AND ON-CAMPUS USE UNTIL 2010-08-31

Record Information

Source Institution: UFRGP
Rights Management: Applicable rights reserved.
Classification: lcc - LD1780 2008
System ID: UFE0022567:00001


This item has the following downloads:


Full Text
xml version 1.0 encoding UTF-8
REPORT xmlns http:www.fcla.edudlsmddaitss xmlns:xsi http:www.w3.org2001XMLSchema-instance xsi:schemaLocation http:www.fcla.edudlsmddaitssdaitssReport.xsd
INGEST IEID E20101220_AAAAJK INGEST_TIME 2010-12-21T04:21:19Z PACKAGE UFE0022567_00001
AGREEMENT_INFO ACCOUNT UF PROJECT UFDC
FILES
FILE SIZE 31959 DFID F20101220_AACTIV ORIGIN DEPOSITOR PATH mckenney_m_Page_119.QC.jpg GLOBAL false PRESERVATION BIT MESSAGE_DIGEST ALGORITHM MD5
8ac7acb6efae99d6daa266bbea46a409
SHA-1
84401888f3c2a5cf2515210fb262bee983ca0512
95173 F20101220_AACSGH mckenney_m_Page_090.jpg
83308f1e523dd48ea5cdeb233db940fa
074723f02eb7f9d548695c6ec33addeda4a7085c
84966 F20101220_AACSFT mckenney_m_Page_075.jpg
e4dfcba2cabf8e15630bfcaabb06dca0
e43d8c3064a19bf07ba083053b9f391af8e3a385
7707 F20101220_AACTIW mckenney_m_Page_119thm.jpg
12a90b75a603757fa754314c40064cdf
a1128b1b038a83156ea9683d911b2c5c98c9fd63
106108 F20101220_AACSGI mckenney_m_Page_091.jpg
2561102e9f6b0ba61d7b1d28f60d288a
f47d4f0f866caf342eee19796dc0760060ced03e
109586 F20101220_AACSFU mckenney_m_Page_076.jpg
f7a7671b3f2430693f98927e943a7980
b44ca8e34721668668e37e7b6fef25f8145dbd68
8343 F20101220_AACTIX mckenney_m_Page_120thm.jpg
bd2187611adccdf0c005f6820ca873af
5c2d622e81af4a0e8e2edfc8e8e8b097bfab7591
99085 F20101220_AACSGJ mckenney_m_Page_092.jpg
43b1f98de9ea3e21231c6e2f3f22d6a2
3d083145b696cd9a257eb963e5c98c3d0e328626
115088 F20101220_AACSFV mckenney_m_Page_077.jpg
afe3e8cc52c4c0b7d1254fd120629283
147b4adf14e07abef44a8c9411a1a1147075d849
35741 F20101220_AACTIY mckenney_m_Page_121.QC.jpg
91a6fcaf7200bdd1a4a5b41a612d3b74
23d47f01c95ce5609a90ef8931db75bb5a3f8c39
107821 F20101220_AACSGK mckenney_m_Page_093.jpg
04b07cf021e0d5d528b3ed7112384f9e
b58557b3cd2aa09f835950d02f5e5df931eec852
100263 F20101220_AACSFW mckenney_m_Page_078.jpg
f1c288af145eaa12b52054ca74d93a44
5e00429599e85d216cd447f55ba432720dc53064
8444 F20101220_AACTIZ mckenney_m_Page_121thm.jpg
0ec051b4caa3cf2a49d3e9254af0384c
2363639606b80b9e6a0656fd75e5addcaeeba958
111479 F20101220_AACSGL mckenney_m_Page_094.jpg
89f2826aa7d70a1f2ac6b49ce1975598
2f334419efae6c88c21d6871dfdf6d4a586ab4f0
120523 F20101220_AACSFX mckenney_m_Page_079.jpg
5bb4f9bb936c3e4103c1979ce9486402
f028100d68d06da13c1d6d6d1784518db3d38985
106450 F20101220_AACSHA mckenney_m_Page_109.jpg
1f6612d4d3bcfde0f65423f6f8ec8bb2
9344910ff89270c39ef845fd21652676b940814f
91992 F20101220_AACSGM mckenney_m_Page_095.jpg
a824e68be5bd0b639f15dc865e556bfe
4305bf25208ab97a845f7b3c39a95bdcd25b7c24
90007 F20101220_AACSFY mckenney_m_Page_080.jpg
bc18c6b259284b34584092883b869879
9f5408b6d601aa973d1f07e2bca768886fc0374c
120206 F20101220_AACSHB mckenney_m_Page_110.jpg
47a126d38dbcaeaba0ae14ba13f287b4
45b18cb56ebd323f1336295ca14253c02ef9b3d9
103763 F20101220_AACSGN mckenney_m_Page_096.jpg
880d1d13a1a4aa7561f7b7f668694a3a
31c67567be2864652ba8d9a894ba2ac1e9ef3612
45885 F20101220_AACSFZ mckenney_m_Page_081.jpg
0a2d5877a36591751f1862fa51a4b572
bbcb0acc80b1653bfc83951e08b14df80586ef68
108489 F20101220_AACSHC mckenney_m_Page_111.jpg
2ac67d43c27b05d45354fc4f8e0b951d
6eef409f8ac821414123f8d6071186319157fb7a
112205 F20101220_AACSGO mckenney_m_Page_097.jpg
14245b7a67ed0e480280f0c12534d4ab
a856da87955e04e75e7509099105497f86a55401
112802 F20101220_AACSHD mckenney_m_Page_112.jpg
e91fcac44d14a5577e8b4698a0c4bf4e
f374863955dcd2f44605514ef0284abed8048d4b
115787 F20101220_AACSGP mckenney_m_Page_098.jpg
b42e96c87a8c7d43c7ed24ddd4147ed8
de53635e27ac79bb53be1e5df1446cbb34112af3
76245 F20101220_AACSHE mckenney_m_Page_113.jpg
e66f7cd3f51b1d622d26c9f409b18436
b128e243e5395ed5de5bc1f72c37d66e6ad6ac5d
92234 F20101220_AACSGQ mckenney_m_Page_099.jpg
973b98953efb1076619dde43b6814397
1cc2635ccfdc2c4cff6d671679d6ed37184786ee
82016 F20101220_AACSHF mckenney_m_Page_114.jpg
4be95d96dc0529121c1347aca686314b
e11b6b5d304a2c66cc92b61d30b10832233255e5
115994 F20101220_AACSGR mckenney_m_Page_100.jpg
61ff1f5ebabedbc4a5da293643455d64
eb3170beeab5b0601ad01fa2234cf92305fc75a1
40804 F20101220_AACSHG mckenney_m_Page_115.jpg
1d36edd7252135343f7e8e3c1b838deb
7fe4b483ab6b16a9e4c093d2154d88a546a62eb1
109681 F20101220_AACSGS mckenney_m_Page_101.jpg
adb6dbe82dcafaab8d959ce61c9a1034
e89da489b48eff9f5735caa003cf95d9435741fd
104129 F20101220_AACSHH mckenney_m_Page_116.jpg
589b613b0b56cba620d7862de3402ad4
ec5bf8631c47bb7cce12fa39488a5b752a978f08
115176 F20101220_AACSGT mckenney_m_Page_102.jpg
a46d25fa681b5601968cf03fa46c7c75
7b9bb7ef91618d72fae8f59f3b040fd6af260e75
114947 F20101220_AACSHI mckenney_m_Page_117.jpg
e71ed78d935263ec9150d0c007fc80f3
52fcb0bd58de3740630a347394e95aa3fbbfc57d
109382 F20101220_AACSGU mckenney_m_Page_103.jpg
5af2de9427bd88f62d9b24cd76632170
26d04b9ccad5675c2444d224c6bfeda68f135be9
109774 F20101220_AACSHJ mckenney_m_Page_119.jpg
779957f325205d9d3398ba4ca5671d28
41cfab0dc1b724121054c9cb21a1e771181d0fd7
110259 F20101220_AACSGV mckenney_m_Page_104.jpg
06faad6a35f9c7af7a427d759330fc5b
d31f78ded1f15505b86d1e537a80e3a17f3a83df
126340 F20101220_AACSHK mckenney_m_Page_120.jpg
c09fc0c319dff69569b137bdd73a3c4a
7a8a2f47c2f535b4882ea75fc5ac21e2416c9ad4
93985 F20101220_AACSGW mckenney_m_Page_105.jpg
a7c1d1f4b7c8acaf1979af0eea01fb66
d9236acdac57fae1cff23296542d4e28262a0858
128115 F20101220_AACSHL mckenney_m_Page_122.jpg
d24f5965ea0b188e10df20913bea97bd
5585b42660859a52d1888f0358bd194eb251cb2f
88566 F20101220_AACSGX mckenney_m_Page_106.jpg
9450c3d4ce0637a7852340405ec9ebe6
52364a2e4c15622e83fc1777a0b651f1b88866d4
1051951 F20101220_AACSIA mckenney_m_Page_013.jp2
e320d4fbc60c8454c60a77e0aa4ed468
d179b71d9e6bfc5cb210b62c2887cd525635b16a
123997 F20101220_AACSHM mckenney_m_Page_123.jpg
f9be3a85ea64f4755922729756bfd1db
34b10fd5492478a776a0e47ff8ee1455bdef08f3
113028 F20101220_AACSGY mckenney_m_Page_107.jpg
e8eeeaf37724bd9ff2cd776f49efd978
6363e53835151283782d51e972d3a559d61bb004
1051974 F20101220_AACSIB mckenney_m_Page_014.jp2
dfc914128b0a822dfa39a04f644400e7
c502115bd65e2bc235c527d979325a96625fc013
33880 F20101220_AACSHN mckenney_m_Page_125.jpg
9022b4590bbdcf5ce7cb165b5bbc08f7
846133737c53556aaa2e68a1e3032d5daf5d3e9e
1051956 F20101220_AACSIC mckenney_m_Page_015.jp2
67e944f8cf73131d4920f8e8da9cc7bf
70c844a650d3cd2cea9c5d07f77c7d9dab63369a
32183 F20101220_AACSHO mckenney_m_Page_126.jpg
36eba7984a811b262a99042283d2eec8
6d4e58cff8ef90664b1a8cf153be56f6ce2d2f2c
108835 F20101220_AACSGZ mckenney_m_Page_108.jpg
6d9a04980fd0b5e4b1285f3b6c628653
1af7520df6a2c1863d79d1f8fbb8cbeae08ea462
1051979 F20101220_AACSID mckenney_m_Page_016.jp2
e931574ddcf0556d1b15b0040e537ba8
d9c3d9f91e227737ea79c8d48a60031e6332ffe3
310233 F20101220_AACSHP mckenney_m_Page_001.jp2
4f4712c8d7094ce8ac2a9f15cdc8e031
bb918a7adb614cd94b5146692b15106d125680e3
F20101220_AACSIE mckenney_m_Page_017.jp2
fa71b0e9f37bee486364d5484ea1ea66
426ff6784bc7d55456a7ece0694341f98cb007b7
28688 F20101220_AACSHQ mckenney_m_Page_002.jp2
6470ec05dc523b8264e4f7514320c969
39528bf0606a1e60fcb2ea24d8de7e5edc637076
1051972 F20101220_AACSIF mckenney_m_Page_018.jp2
d159cc290bc3632289a9f41a4c86e894
086a64f9938a782fa0234c40d28d2fd76e35b54f
130887 F20101220_AACSHR mckenney_m_Page_003.jp2
a74be0ec66925642881dbb93ee821bd3
23335c45c1acce02e583803529d45fa169630f70
1051947 F20101220_AACSIG mckenney_m_Page_019.jp2
2e17a340a7fc6795f01478f33d3058e0
b4169b6c5483df6d15019d7a7019d4f44787f12f
1051980 F20101220_AACSHS mckenney_m_Page_004.jp2
eaa9442a4d5f53a668a5e84ff6fa84f5
b937ae77f611d2d3d50ad7b65cbbfae5bc959ac3
546574 F20101220_AACSIH mckenney_m_Page_020.jp2
f0c1441f0ada11c8947ca7bc503e72da
b12626d8cb36c4e243479cf2e9f42472a175669a
1051969 F20101220_AACSHT mckenney_m_Page_005.jp2
f4290e85a317a5655a210e85754984b6
e9ab0eef0760261c6ccfe1e25befddb97acd81ac
1051983 F20101220_AACSII mckenney_m_Page_021.jp2
f33b617a0d7546056109f85b7f037f2d
c6d1eaf6f4d665bc9ccacab67233fe42690bfcbb
934568 F20101220_AACSHU mckenney_m_Page_006.jp2
cd620cc4e268b5043d7447ea499d08c1
a22492200021b318557dad5f637d29f385225241
1051948 F20101220_AACSIJ mckenney_m_Page_022.jp2
2e73c567aff0a2673cb7764a127e78b7
6a45addc29a432412cb6f54269e71cce1b932071
1051977 F20101220_AACSHV mckenney_m_Page_007.jp2
6e2713bd4c9d498784c305e4742fcdba
10b36dcbb3ea28bb30a711784fc89ac749894aa2
F20101220_AACSIK mckenney_m_Page_023.jp2
97231767913afeb613721ee275162afe
e8e7e51925412e4fb44483d264aa43831d368299
1051986 F20101220_AACSHW mckenney_m_Page_008.jp2
901d578ee712678e069d60bcecf1861b
27c4d188ae62329c809723fbb450e1c5bba2f756
1051955 F20101220_AACSIL mckenney_m_Page_024.jp2
c2b89378df09d7324383a92df5ab2daf
b8210a56bf0f4efc09888464be38d10fd5cf5d69
1051954 F20101220_AACSHX mckenney_m_Page_009.jp2
32914c23f0622fe199325962c83ae580
a372ef03ed39072a6d615e7a1a7c7a65e9285fdb
1051967 F20101220_AACSIM mckenney_m_Page_025.jp2
d1fd39f6bf0115d968ee86a75eb910fe
a491c5cf382c5268d8c7719bfaff05436bcf85bf
F20101220_AACSHY mckenney_m_Page_011.jp2
631e305c31a0d63730008e681537baf5
f2be92cee55d772e831f5ea346df85fbca91ef9b
F20101220_AACSJA mckenney_m_Page_040.jp2
633ada7841e72880bf1dfe6e327925f1
b1d89b150fbfff938635d0923a6ba973b876c209
1051895 F20101220_AACSIN mckenney_m_Page_026.jp2
c81eeb287603108f106a7452010a88c7
74763a188e1832c409d9ad0592cedd3f7ec955f7
1051960 F20101220_AACSHZ mckenney_m_Page_012.jp2
9abfe853ebbac5b618c6ef83dce97921
385195c0d94723ff57e99b54e8968ab67fe3e685
937066 F20101220_AACSJB mckenney_m_Page_041.jp2
0e967176805e69e1fbaa3bcaca316dd4
0ad20be20832af423850af452d7b007eab3d8ee1
F20101220_AACSIO mckenney_m_Page_027.jp2
a63d873b615297304fcbdc0f686ecf6c
c172452fbc416a671a7afbe5e2a4683624979a3d
1051932 F20101220_AACSJC mckenney_m_Page_043.jp2
218fd5f7077fbc204b7f86542509588d
a6f39c888de3174f71eaef9e080a8db2891faba5
F20101220_AACSIP mckenney_m_Page_028.jp2
36636ec40fd9a353380e152817f6d5c1
dab5accd1d5bbe9b89953c893c4d868e8d6ada69
1051936 F20101220_AACSJD mckenney_m_Page_044.jp2
2003c2bec550ad191841917bec970ef0
2415a8b1d30b6e67149dfef07fbd6add88b99beb
1051973 F20101220_AACSIQ mckenney_m_Page_029.jp2
bf0a4f3b7646070736216bdb2136f05e
518499d17bf9d8e7716212f0a1d7bc0646d1a6b3
1051908 F20101220_AACSJE mckenney_m_Page_045.jp2
37fd852fc50bdc2b47b6972c48d2d967
6b5fc2a3c00160ef395fd3259d1a82d3c375e377
1051978 F20101220_AACSIR mckenney_m_Page_030.jp2
95d2a2fddbfe274fb44b6e3771663263
ff3eda354de1374bf02a49cd3bc92e179d46c8c9
965324 F20101220_AACSJF mckenney_m_Page_046.jp2
606f992085111e34c76e0bba8a750c50
39cda5e73c3d22233971cc4421bd217c4fe13d0f
F20101220_AACSIS mckenney_m_Page_031.jp2
3982b06478789ae07ce3780f331b8573
6cba505920882c0c46df2f440d6796d7436c2827
593454 F20101220_AACSJG mckenney_m_Page_047.jp2
7b4c46fdf11ce739cefde178e363296b
b755318cb7873da5077f44ddc005d67e4dd36036
F20101220_AACSIT mckenney_m_Page_032.jp2
a84fa648bfe72da8835c28e56eb04e3e
8c55682c771aa60bdd0a0f652186536049ee21a9
246355 F20101220_AACSJH mckenney_m_Page_049.jp2
deb428a9c72c6c4ea7d2cbd8516c0e97
2a79d788c1a091ebbb4be487f34778ffcd8513ce
F20101220_AACSIU mckenney_m_Page_033.jp2
cff255feb03b170201311eea77a9ccdb
ec276ad6f5fe8709c9015e6804f021b5d0ed0709
1051958 F20101220_AACSJI mckenney_m_Page_050.jp2
5f7f7872f2d92bb429a3779c7365454a
add139dfeba848fc40d5d5dd424c9f408a24efdf
80237 F20101220_AACSIV mckenney_m_Page_034.jp2
2ba34e024ce7b9565667b9d845a2b801
d00288e94cb58870822c10a2ff117725dcabd4bd
F20101220_AACSJJ mckenney_m_Page_051.jp2
5722fdaac45cca0fee00198ca09f3a3f
9a94ff389e7c0c1742a9d5317ab4180c80d72008
1051976 F20101220_AACSIW mckenney_m_Page_035.jp2
a201c126d3877e8fa8836bce50396077
2dc541d58a5a3033f4c5c636e1b47d40eaf794e0
F20101220_AACSJK mckenney_m_Page_052.jp2
5583643f48405df5779508f15286981c
7a425c615754c344fbc4456a572ee7b68d40c6ff
329243 F20101220_AACSIX mckenney_m_Page_036.jp2
93b15793d56b4ab0e06a29000be26594
31414dc297203bf9afbaf83b949168540c479ece
1051892 F20101220_AACSJL mckenney_m_Page_053.jp2
31b58a6b46ec83d21bba233d692e48c1
dd29f5c86125d90ca3d51e4045e2ab0e8792ee7a
F20101220_AACSIY mckenney_m_Page_037.jp2
d70336a10bcfeaa23a53e1d0bf577d07
88a3785f44e09aa7cc510c048f78880e1ea7ac15
F20101220_AACSKA mckenney_m_Page_068.jp2
85b0c5d8d94dd3711ae5abfc93dad8e9
838ac4deb1fcfe1b684e3ea1f01480bc118204bd
1027338 F20101220_AACSJM mckenney_m_Page_054.jp2
e1254a4f78889d449ee3877ea4a0fc6a
ce910e2eeefc89a32883c3d13e849daca165ba4f
F20101220_AACSIZ mckenney_m_Page_039.jp2
4fadb52e744b5c20979d7797ab533b73
b29d203dfba9657b4cecfc20136e737d84872b63
1051966 F20101220_AACSKB mckenney_m_Page_069.jp2
ef038034659d4e3d262b5fbeec909105
fcbb0577f5112603899a9c4aa99920ddc186a317
919934 F20101220_AACSJN mckenney_m_Page_055.jp2
9f29cc0361bb09fd7348f9a2cb117811
0322b0aa063810e8e6ddcd3641f9be7219c3a69b
1051938 F20101220_AACSKC mckenney_m_Page_070.jp2
fa3df3818178c4818a59c4046a93a374
8aec9aea8c7047a2f4df30d69faf7aa2040e58b2
1051919 F20101220_AACSJO mckenney_m_Page_056.jp2
cfd9d7a57919f120177a83051feaad79
db19261dd619001bc01f38cfd9c72a3a72d37e10
1051883 F20101220_AACSKD mckenney_m_Page_071.jp2
0d081995e24531f064286f7d7f5c78f0
1bfe7b97012ebe7dc99aa89309d68ba69d819664
F20101220_AACSJP mckenney_m_Page_057.jp2
d9f828889db35e92dff0b3a51d3a6071
e2e10d19a6fdb724dc78be187d491d6d8d18c49d
F20101220_AACSKE mckenney_m_Page_072.jp2
38b56291c601327bcec261bfe726b531
9a42d0770cbc18c529652d0ae958a9ebdab098be
1051984 F20101220_AACSJQ mckenney_m_Page_058.jp2
1be3f65d043a708ec3b8c661d5ba2e10
48d69dc01a94a563cbbc63a4cdc944830c4b9514
994387 F20101220_AACSKF mckenney_m_Page_073.jp2
d44b4d782c98c378860bdfd903d020bf
db31905d0b6f5ae0c6aec23c43dc206a40467248
F20101220_AACSJR mckenney_m_Page_059.jp2
77071482cab9f54184dd5d7f6cdb3f82
468b3a7b7e2b2b253348ad58ad6e00a5eebb3bb9
F20101220_AACSKG mckenney_m_Page_074.jp2
0c1c9a4d77018acd22c583c6d487c191
f05d9ef9c3204e8a0a2c04915df7dc413d497f19
1051929 F20101220_AACSJS mckenney_m_Page_060.jp2
eceeee6a7497fcf203ccb6cdfb9e22cf
210face4de53f0e13a7d93c64449360e2f1e1048
995637 F20101220_AACSKH mckenney_m_Page_075.jp2
0e938bb69158c1ea9f99b8581a7e7a91
7227bd42f3dbf682b0158b21a3a487f8143a751c
F20101220_AACSJT mckenney_m_Page_061.jp2
140312916e7243a6f437ced610033a72
8a9da58da4b5b939d2be9ee6f6bf3060bf61449b
F20101220_AACSKI mckenney_m_Page_076.jp2
b73d514fe097eb93efae4252b4847b76
09c81badf7e60fc2db29d47685f1df4ffc846512
F20101220_AACSJU mckenney_m_Page_062.jp2
7a3d9d6019331197b24b28790dbc1a1a
f158f45895cea69c7b07d664187bdbdb36541b1a
1051950 F20101220_AACSKJ mckenney_m_Page_077.jp2
231ab7e57f063d8e45e2eb6a4f28d918
c77546eda5e50ad1da50fa5b4e0ca00eb11ed206
1051952 F20101220_AACSJV mckenney_m_Page_063.jp2
f02c8a39e73197faf4dc5f9b37b6c469
a2c242c0b24c74071d86761ab6baa314e86dee1b
1051961 F20101220_AACSKK mckenney_m_Page_078.jp2
dbebc7574a0363c8dfbd33e52e06829b
ac366c5988176fde23f78370e9690aa3ead58934
1051933 F20101220_AACSJW mckenney_m_Page_064.jp2
54381db271ed1b4d9dcaffea47059792
c9c2011d313abafbaa1a56cead075926806fc125
1051981 F20101220_AACSKL mckenney_m_Page_079.jp2
5efa153820cf38f18a9014458173b51e
63045318022b4cfdd318cb35f60a501dcc0ac1bd
1051985 F20101220_AACSJX mckenney_m_Page_065.jp2
55a2d05edb2cf41bdbecf128c5e617ee
e8c411fba43ec41da3c5eb0f241a29cd590f87be
F20101220_AACSLA mckenney_m_Page_094.jp2
92e22c12148a4c3008f508d61730d1af
4fea76ba9511221b322339c1dac8c4e01961af4b
F20101220_AACSKM mckenney_m_Page_080.jp2
b080cfd19f20a53ee9721748ae83bd45
2e1a081907a34d9ef65ef083d6b804221b0f781f
966272 F20101220_AACSJY mckenney_m_Page_066.jp2
a6b05208b11f50b849af96e70b9b520f
c556b6bd7f7d07ca96d61e0c3d4d7d1d68f8c804
1009196 F20101220_AACSLB mckenney_m_Page_095.jp2
f15102a1da824afdc78044859f3b07ac
f2eaa2ab7d14342f02c80258d693daf820a076e9
507124 F20101220_AACSKN mckenney_m_Page_081.jp2
b6f72ce13d4fe6d06d8bfbdb33d8a15c
f1c0eb3c179ef3b6e534f0f7cb030b5623d0fe5d
F20101220_AACSJZ mckenney_m_Page_067.jp2
82d7721db0e7b31031c7bc8513ac8b96
0a50eed41539b97281015e1871cffb9835948fcc
F20101220_AACSLC mckenney_m_Page_096.jp2
565dab61e842221e2c080f3f4b6c5e24
7b62dca74b49f868875d3c3fd2a33e012ffffd01
F20101220_AACSKO mckenney_m_Page_082.jp2
eb39324bf0727cfeef9ae3250c812df3
627ff8700e3544b3426f153c37e8f285e5dacce5
F20101220_AACSLD mckenney_m_Page_097.jp2
ce5b7dc2a43f9fbaad5ecbaab2e1f536
677029b876d6583fe4c9df3619ab57b8ed234d79
F20101220_AACSKP mckenney_m_Page_083.jp2
1db129860b2b24e59428878e46b85ba5
28e6ac1de03c13fd176e43ed2be1004e7207ccfc
F20101220_AACSLE mckenney_m_Page_098.jp2
864f2b08a45e432df1ccaa298bf81976
a35facc9f0369cca3381bde4ca035ccf3aac9d07
F20101220_AACSKQ mckenney_m_Page_084.jp2
b3eb0743ee0c68333fc35d8ce244c847
947ab339b033185a60b0d30043c354687a55891e
1041806 F20101220_AACSLF mckenney_m_Page_099.jp2
0157f136f881e0be09ff36d7f7404827
17ce611ca407afbf29d66cd3ac4336c4a607e918
F20101220_AACSKR mckenney_m_Page_085.jp2
245133c920fb164b02d59351ee4be4b0
486177bbcad3e2a130005ac3935273e5c380daf5
1051975 F20101220_AACSLG mckenney_m_Page_100.jp2
306d64c0e2c0f0853f4c15c9c30bdbfc
b11309cd48d6c741cab17c957652e795a1d369da
F20101220_AACSKS mckenney_m_Page_086.jp2
57b8a3d7feb6edce7eedb047d0529ede
93f1b4a5f0818e63c34ab00b8d27f19b776058bb
F20101220_AACSLH mckenney_m_Page_101.jp2
3bb26646c54f0fd072ac29ea46c1c1e4
983c9293f1a291cb2631180af49133a75ec81b7d
1051965 F20101220_AACSKT mckenney_m_Page_087.jp2
0f7036421caae52ef0e26003b9570c26
e2e74e5620e5700b874dbd8db9fc711cdc3a1a69
F20101220_AACSLI mckenney_m_Page_102.jp2
f3a49ab6bc9fbd4cbe85c55fb9a5a014
dab1c4ccf6b5a3fb8ed4c120ef53ffe7e57f3ead
934180 F20101220_AACSKU mckenney_m_Page_088.jp2
4d1095839e5c06ebc4c33022b84d001a
b2532ecb580f0017e1c537d45afcfae950477a79
1051915 F20101220_AACSKV mckenney_m_Page_089.jp2
b53f71324a8ed84a37a66be2d284702d
3ac334f6adaaa1b81ff8edf267b163020e81c737
F20101220_AACSLJ mckenney_m_Page_103.jp2
d6582320f441a5de93d46929ea04d31e
5553cd5a47b1c71fc847591db251094fe7eae053
F20101220_AACSKW mckenney_m_Page_090.jp2
236338b7f2e80c07d5942806bb9529da
db260e23c3657d3a5b09e53ff93e76c59416e7ce
F20101220_AACSLK mckenney_m_Page_104.jp2
aeb8426ca7c3cc8d3562f8e8c88b04f4
50c83a4966e711606752818e7b78f56f0b8233a8
F20101220_AACSKX mckenney_m_Page_091.jp2
df1b801360bfff20488f4196d81ac7d0
444cf0a97ee44abeed05ab1252a277616ab66b34
1048707 F20101220_AACSLL mckenney_m_Page_105.jp2
7f6951f642444b921e57e0f7b2d128e5
1e7994f69ffc3447daf1e30e87a99310391d64ba
F20101220_AACSKY mckenney_m_Page_092.jp2
26809e945d6e495e581df1801e4d7f3a
80cfc5f23cf6ae072d24252b391607e1b687bc8d
F20101220_AACSMA mckenney_m_Page_120.jp2
7f66391081f7f19e387c44683dc4c296
a21a50a8d63d34cf24d1f2290ff9027402e764da
972875 F20101220_AACSLM mckenney_m_Page_106.jp2
aa66594bb261be0a8f7d8ac2433772c4
1556748ad60fa3d27522136c8525ffc3a662e7dd
F20101220_AACSKZ mckenney_m_Page_093.jp2
9419cd12964d922ddccd26fdbb85c421
5ce0b7aead482373a7666f111c457084b0044eff
1051924 F20101220_AACSMB mckenney_m_Page_121.jp2
3e3b9c28f2bb03976ce8fadaee84cf80
aca6a4cea367259f7027f01e83a355d4da685b01
F20101220_AACSLN mckenney_m_Page_107.jp2
71ca325f832840a4b4ad6f83bec12ee9
7cc3d26f048203052dab722f3fa0028b7b386309
F20101220_AACSMC mckenney_m_Page_122.jp2
b0d486195a940dfb6efee94f3784b968
100f85db37562ebe828909b044913a2e3f397b06
1051968 F20101220_AACSLO mckenney_m_Page_108.jp2
c0371151c5111bd81018149a27a08c56
50c730c6d63d8ec8cf27daa1ded5823943ccb597
1051905 F20101220_AACSMD mckenney_m_Page_123.jp2
3dc3b7a1552467c990c149c7f0b540dc
ca5cba9f0895b166793813b6dad9a594f68f832b
F20101220_AACSLP mckenney_m_Page_109.jp2
ff2826313cb1ca8f7c7a92b59f34748a
72698f19a3e10982952135dd08e10427559ce32b
F20101220_AACSME mckenney_m_Page_124.jp2
c38513852a6a2ec0288f2bd765087795
5bdb6337c7956409ed43d43a635ff7c231e9ebc3
F20101220_AACSLQ mckenney_m_Page_110.jp2
69600563784638214439f86eac89e4e4
0a4c6b3f69822dce494947ea27ad992de68f0925
377054 F20101220_AACSMF mckenney_m_Page_125.jp2
bbe8d4e3721f88bd23150754e613b2be
f8257c12b1a2290127ea2d48cc2434e5ae9c873e
F20101220_AACSLR mckenney_m_Page_111.jp2
8f2cfe035eab5178fc3b35d0b5f9e931
03c6e663a94ee73a042fa46697d6498a98758cc4
352094 F20101220_AACSMG mckenney_m_Page_126.jp2
7c5dd8817483a39dd1ec1c8e1cd2c7c8
6f5db2a05157aefa83586c5dadb61d91da3286cf
1051982 F20101220_AACSLS mckenney_m_Page_112.jp2
9edc1f287f1f3846772440611f038bd2
e86c0a5089edaeaf8fcbac4a24dcfff5867c8a2b
25271604 F20101220_AACSMH mckenney_m_Page_001.tif
1331ab5580a1a153da8feca25ccdb13f
c4103b7241a3f1a1a197138a1ac58ea064c0dfb9
849601 F20101220_AACSLT mckenney_m_Page_113.jp2
370f0232ab5fa06e01ebfb4f1de9dc62
79f7c6f66136f09c06dc4f250e9f691f4b71d0a7
F20101220_AACSMI mckenney_m_Page_002.tif
bf779072c781168fcfd91de59e77c69f
60d8c88ef823234f22214afdb703f877b323b06c
912052 F20101220_AACSLU mckenney_m_Page_114.jp2
9a7e27a0f8fbfc3f45e97bba554d0f3e
19856b3b90eee9bd81b534eb8cc47555db5ba66c
F20101220_AACSMJ mckenney_m_Page_003.tif
47e07ad573df648db1160350d98e2c1a
c85909b7163c509ca3d75e5e1ce7396f7b3b651c
468021 F20101220_AACSLV mckenney_m_Page_115.jp2
db6b3fd74419c7188ae3b3ceb7b1e7ea
368693c39e409612744ed3662925f9c7b941a981
F20101220_AACSMK mckenney_m_Page_004.tif
bf36a1254252316bb223e1495c9b3205
05d7b12f23c44c2d9be4e9cb682a2b491dd355bc
F20101220_AACSLW mckenney_m_Page_116.jp2
a6899789d155f77d14e5a878be240311
6563ba652b50977f9fce6291e6ffd515196ec1a7
F20101220_AACSML mckenney_m_Page_005.tif
c954af1e08b0e1e9cdb80b82bf7110c5
9dbc62e18e397aa340e913ffa1f20f8b1f56c029
1051964 F20101220_AACSLX mckenney_m_Page_117.jp2
ca7034ed8609f9a89e9ce504ed5deea8
890bfbe2e25c19d6591327631ec2df2bf24aae00
F20101220_AACSNA mckenney_m_Page_020.tif
0d8e4894c74584bec712f6e4e718acd9
3af8c2c9cb2d0bc257b2f46e7e5fd584fad4edef
F20101220_AACSMM mckenney_m_Page_006.tif
5eb53f13fd38636ed677f41b10a1d5c2
186a8a2173b0d5a6e728de5d6503216bdc41c11f
907278 F20101220_AACSLY mckenney_m_Page_118.jp2
a3cf296498e79b5d0427c5b26786f149
51d01dc42724f2c82aa2481f8d09ab23daac9b59
F20101220_AACSNB mckenney_m_Page_021.tif
3c826c2871a69218cb764de1849821e5
6c6b2a4259e9c8f50ae07580ebfe5f807690933f
F20101220_AACSMN mckenney_m_Page_007.tif
3e7a00c1766904ab73e02f248f5a4317
e6174a0277087d9f1f0f801fdf76b6246a33a693
1051959 F20101220_AACSLZ mckenney_m_Page_119.jp2
3684cd353bc225a30fd39007fb9efa4a
a0be48cf72450f02af193eff00352e32043082c9
F20101220_AACSNC mckenney_m_Page_022.tif
43ef788f40d47e18035d65410b210ff8
39b287a305e78daf4b495ac1c7c0287e82e70736
F20101220_AACSMO mckenney_m_Page_008.tif
9540c4ca0c82e35c9da7f9a7394b5564
1d401c21f7f60c3250fbbc045bd6544649fa5a43
F20101220_AACSND mckenney_m_Page_023.tif
0e60eb505b9f2d902bc73c5319f7e719
806f4ff4b8659f496b3aa715399081fe10ea2b75
F20101220_AACSMP mckenney_m_Page_009.tif
3fa6cd852a0dd3e17ce9923b1289deda
1ab9f32828f4eb46aeaea82b1687a14a571095eb
F20101220_AACSNE mckenney_m_Page_024.tif
e0286f5c8c504c239c4ef6d56d9ded05
cb98a4f276d5394657b979451edc0fe3641de633
F20101220_AACSMQ mckenney_m_Page_010.tif
cf1dded4d04a6a0baf59d03044213bb1
2d5eac74c7869314f2570f7545672d90bbac1c16
F20101220_AACSNF mckenney_m_Page_025.tif
f38be0400e405026650ec700c57d6445
ea7b6ad9aa190d463322155e8d913de72b067864
F20101220_AACSMR mckenney_m_Page_011.tif
24500349f5e76a9c504b07af65a89edf
bc1096a3bdbc3b69f2b753620756f7524e3d5eb1
F20101220_AACSNG mckenney_m_Page_026.tif
15e6caa1f0ffa709bbfe03c670f54fea
d587397ba2f10079d14591b03ad6e8bdde9da130
F20101220_AACSMS mckenney_m_Page_012.tif
84f36dd52b69501993ca3eddede3aa82
34e28de1f79d1fafeffd97b66906a449b31d598b
F20101220_AACSNH mckenney_m_Page_027.tif
dd622a34501672b7be7445fe677c94b8
217b5358779713f2d9ebda98ede220d350dcb734
F20101220_AACSMT mckenney_m_Page_013.tif
8b6e979a613c0d6146e024b50762b0e1
e620e38512ec1ccf0e9d3606b4e8a18df62eea83
F20101220_AACSNI mckenney_m_Page_028.tif
ad90e1b232fb7ef0abc41cfe791f50f6
8710c3971bcd4543bc4463fa21c92d8436b4da60
F20101220_AACSMU mckenney_m_Page_014.tif
4785f2815bc7535b6ebd2bb01dc1c707
576e609f9ceb1c546f50e4862637ecb3bb8a3b52
F20101220_AACSNJ mckenney_m_Page_029.tif
dc911055e3a01a5eb56ccf123c4c3b58
d8df25658d8f06389e655548fa1b0bdb7ca12107
F20101220_AACSMV mckenney_m_Page_015.tif
43da37e56fa73846f5c5059ff2b4a111
e6c6af06c49a3b97c5367162ad3e5cb9249591c9
F20101220_AACSNK mckenney_m_Page_030.tif
13bad5d347f7bba45cef42e160e31953
692eac7903a595cf0aa565bfa4cb02e088b1966e
F20101220_AACSMW mckenney_m_Page_016.tif
77e810eb5d15d9b69def7955ed3fabaa
ceddc03952e6257596581c0ea751f51aa4113618
F20101220_AACSNL mckenney_m_Page_031.tif
17f453b2d5392568bae307e4a067500f
4699bc2ffda05dc5f9e03c4f20b09ab36aafbd72
F20101220_AACSMX mckenney_m_Page_017.tif
4211f96c4d6fc054fb9bdbf8c79acb95
c5442a512e96b9576edfb2248b06b6ad11fad624
F20101220_AACSOA mckenney_m_Page_046.tif
121a50da5f1a26476b72229a4b42a7f0
eb6c748c7956d059f55b8e1ff3e323f1ba613059
F20101220_AACSNM mckenney_m_Page_032.tif
52a68340027f2703cfbbf12123361ea3
243b0aa947cc2de8157940dce6e2f0650ba53c5f
F20101220_AACSMY mckenney_m_Page_018.tif
adda3f026749aa001b83254834855a9c
3bd9a227c582cf2482202db51311a144a8e66dbe
F20101220_AACSNN mckenney_m_Page_033.tif
f26f43afda2a09b39b6196811c259b91
216746549a21e0867e095163a653bb676ca1c23a
F20101220_AACSMZ mckenney_m_Page_019.tif
f8bc33268315bfd3b03d226821939718
6b3e830bf21aefec8f6de910c6dd43761c4c9d00
F20101220_AACSOB mckenney_m_Page_047.tif
6cfdb0027d7c1023a63f1fa637508f8b
5465cf12d5ded0620b9815086cc1d53db13df660
F20101220_AACSNO mckenney_m_Page_034.tif
bec14da2a6990c4f6c5e7b5aae4b9eaf
e872a5826984159fbd1940cf2d8069c9c81929b6
F20101220_AACSOC mckenney_m_Page_048.tif
375b134041c0742c0a0c846246238717
517bfdedad0bb39235549e0cc95537fc04914bce
F20101220_AACSNP mckenney_m_Page_035.tif
ac4a4269c8006556c0a9390425400178
3fc1e14689344e3dfff150ac371999f241d28b58
F20101220_AACSOD mckenney_m_Page_049.tif
f31874d5a36fca106f91033e3fa5453f
78277278105fe2f349ece7d78b41da171e19e19e
F20101220_AACSNQ mckenney_m_Page_036.tif
fe22e183aa5f0ba4fd7ca2a780c2c423
eed53e57c25a6175ebe695e1973f59cd1494b0a3
F20101220_AACSOE mckenney_m_Page_050.tif
aabec474c343a614a1788ad3c0a8038b
219b2e9fa2b807a29fe28682c51b748e1ff55d66
F20101220_AACSNR mckenney_m_Page_037.tif
f9e84533720b9a8e128ce1e5af7b5858
9b7e34074d27c34b7c6e76bfbe8ed45f92d0082f
F20101220_AACSOF mckenney_m_Page_051.tif
14f0a41aabeef5e0fe6dd713f749a3bf
88a9289e1770a780867a39f89b44d3df7f3d4e64
F20101220_AACSNS mckenney_m_Page_038.tif
91ca00d3fad8eda0d0c7e70ee20a765c
32ddf7af990339218f8bc5cdc6ba9e7ffe3d8618
F20101220_AACSOG mckenney_m_Page_052.tif
e07571112288d1c0a24d10c39515847e
303ba82daa0878b0b38592823024713526211d3e
F20101220_AACSNT mckenney_m_Page_039.tif
df9be69cdab566ba15e6ec58401d7336
b52624679b9ffa69d7e1f4ffa57ad5815a623237
F20101220_AACSOH mckenney_m_Page_053.tif
6ba75b02db89bf223ad42d187fa08fe2
bbf168735399d725b2c009bf55f717d9d6d0ed30
F20101220_AACSNU mckenney_m_Page_040.tif
8a7a568ffaf3f3056f1e6baeef56cc7f
c8da6f2987ab559e969fe3a20fc7a06ef5d9a565
F20101220_AACSOI mckenney_m_Page_054.tif
4b443f1d9973956f2643864644822235
d1a2dd26efa6f776021d29499c8d2c44d75800b9
F20101220_AACSNV mckenney_m_Page_041.tif
ecf795f40374dfa1735d9c1b3c09fcde
7494378be1e15c524ffdae20792949db15b6fac9
F20101220_AACSOJ mckenney_m_Page_055.tif
c49de1b132cebc1f0ad0cf19e63c1f19
4b1722f8c963dc90b6b58b326c49ce52acd7e13a
F20101220_AACSNW mckenney_m_Page_042.tif
44a06c3c459d4bdd477c8ff0af633041
1998b4871b3fb6fdcb2862a7c2908a6bbdbb1d2c
F20101220_AACSOK mckenney_m_Page_056.tif
4aa495ad31f0db6619456085699559ad
9b14e180741ab240f5dd17cbdff1d75c794e0466
F20101220_AACSNX mckenney_m_Page_043.tif
7dd1f58d754427fb66037a24b0029703
49547dfbd40d2d9f6e4aafb3fafe965c5bec68f9
F20101220_AACSPA mckenney_m_Page_072.tif
4148bc536dde84e1294337e387fa2c24
1c15e6aac73bfb1e68625bc837cc0ecca689153f
F20101220_AACSOL mckenney_m_Page_057.tif
43af3173db22792f34877ac66c21c3dc
37fe7cd8aa9500b8e65d77bfa5dfa80e81c40409
F20101220_AACSNY mckenney_m_Page_044.tif
d582c174f8dcdef1442fbcce386c0114
6ac07be6f98f049f99b14fda07c4b1239709ec50
F20101220_AACSPB mckenney_m_Page_073.tif
158303ea56b7fa315f731e6e457e1d0f
6ae6fe877eed7cd47c5b80100232b9786e69a203
F20101220_AACSOM mckenney_m_Page_058.tif
f7f2834b6db1049b12f9f7303d4d9b69
36f50f73213f1aeb1c8bc80824590cd0ad0d4c7a
F20101220_AACSNZ mckenney_m_Page_045.tif
b92acc49b461c4408cd4de116d28e08f
0ba7031b98e3e49b9e31c3575a295a4bdedd6396
F20101220_AACSON mckenney_m_Page_059.tif
c5e05004b6d507475a6986a914b2f7e0
d30fb4780056c8f6c82c08203ab0178b2f714145
F20101220_AACSPC mckenney_m_Page_074.tif
ec625e0f2aec5c6776cf41186ddcca5d
baf148c613517636e7d491ea93e856c9f8d86b46
F20101220_AACSOO mckenney_m_Page_060.tif
69736a4a35445bb992d6644b7b42b51a
c7f4ca41109a448ebbbe5c80ed6f8a5cf78c6542
F20101220_AACSPD mckenney_m_Page_075.tif
4a8c319f0baca30f32a3c970d3e76748
0e126e03d0e59bf4b7a92eae05f3889ebb4b9d69
F20101220_AACSOP mckenney_m_Page_061.tif
4074f99cddc7db48c1137aa106afef69
6d3e21e8e8d0c267ef9745f4badf81c9b3a29974
F20101220_AACSPE mckenney_m_Page_076.tif
aa99fb041bf6019de0245200940e092d
77854f391a15618a0a12dadb17d2fc6daf3da9c1
F20101220_AACSOQ mckenney_m_Page_062.tif
feebf814013dd77db3f2088b43f307e8
3ce5a590669ca578f9fb54cba8cde95ecb1f1694
F20101220_AACSPF mckenney_m_Page_077.tif
d548e2b6d6a4fbb89cc8be41a8af3d82
6849d21192c9b62d7c97a353db90b8f448a61162
F20101220_AACSOR mckenney_m_Page_063.tif
9b4d65c75f2e672a30b89ceb59c180e4
b96683e5733c344c4d0e07c40ba7ace349367328
F20101220_AACSPG mckenney_m_Page_078.tif
2fc0870c3cfd01b945ecd4e42a5ead3f
1ebad16b7c956d24c32229dd5b0e16342cdcad05
F20101220_AACSOS mckenney_m_Page_064.tif
1b17de93ace0502a689010700348b2a5
a5cb5d4d664b84dff86ddb47f41e179ad47ceab0
F20101220_AACSPH mckenney_m_Page_079.tif
704b1775c293c9b1b5880f64da5f638c
5fa4667e5e7a59b6f7ef27f3351e1d78c5f195b2
F20101220_AACSOT mckenney_m_Page_065.tif
8290a946682139597bec875375eb9be0
67de963aa13c84b60f653a400c95d57cdba0aca9
F20101220_AACSPI mckenney_m_Page_080.tif
57563b7bc7609e191648b847693822a9
9a5cec17ef71bb70e7010645e387fab357ba5de7
F20101220_AACSOU mckenney_m_Page_066.tif
f2226a913758c7b96652ab7a4e25d619
fcc49fa9ad0880ead51252a12965fef45fa67f50
F20101220_AACSPJ mckenney_m_Page_081.tif
64f832040f165aaecb756c19a02fd653
dd43ab01d76fe69741c6f598d785f5b42097819b
F20101220_AACSOV mckenney_m_Page_067.tif
a8f3f0c1ccee4da4ab9de8a8d3acc1fa
520c2577b1ef1390c5bfaa832f8421e703d82217
F20101220_AACSPK mckenney_m_Page_082.tif
068f0b45ceba54a6586a88e3fca039e8
065685496040b2e7aa1d3e18325480ff30599f03
F20101220_AACSOW mckenney_m_Page_068.tif
b29af78c28e75cf3f4e2f3798f999aa6
bea3e7dd873a84cfe8a714109b9623cd981cb24d
F20101220_AACSQA mckenney_m_Page_098.tif
501ad17b1c24f402a7f8ba25f211e146
85a0f2e8ee3af3330e9238d9c7d015e1813648ac
F20101220_AACSPL mckenney_m_Page_083.tif
9bdf59511b39e03a50205871270586f5
de977257f7194e76c6133cd5b4699e8cc5e5f2af
F20101220_AACSOX mckenney_m_Page_069.tif
c0ace499513992db5b01315ba6a76e4b
47a3008d700ffaf92f2f870809459e1c2f7d4e05
F20101220_AACSQB mckenney_m_Page_099.tif
5689702d7e7abb3a47549953239d0ecd
7688aedc6290f0fd47b1a2c379ff6062fb76069d
F20101220_AACSPM mckenney_m_Page_084.tif
4add7dfc015ded462d0d16145cfd484d
bb957de46f435114d4c5472104aa5fd6b1a2f751
F20101220_AACSOY mckenney_m_Page_070.tif
e53d75f27e0890706405494134daedf9
5dc53bf8de334feb4653220c64a4ce2825f3b0d3
F20101220_AACSQC mckenney_m_Page_100.tif
b0e70a27ea11cf00209eb720947e5c28
b4c59c78dd0238f8e3aa2d42381a2a059ee1aa5c
F20101220_AACSPN mckenney_m_Page_085.tif
b8eb12c8faccbff9086328066f11e5ff
ec1a9ba28417f45cf26f14cc59f9ae63763aaea2
F20101220_AACSOZ mckenney_m_Page_071.tif
a3943a4294b39d382577730e18ad5ccd
d567d9c04cd6d78caee4612e6989964782485cbb
F20101220_AACSPO mckenney_m_Page_086.tif
baad1442c3226ddfebfd212e36442b96
65daa6f119d3981745fb74f2cbbd380e8bc56dd9
F20101220_AACSQD mckenney_m_Page_101.tif
f77c03b0aa207de8e0fb631c62141152
73884217196bcaa801cfef2e26813c01450b62e2
F20101220_AACSPP mckenney_m_Page_087.tif
478260e71b496281570a26c4e9343514
0e8ee9906ad9507a0b1ba215327d0be85c60177d
F20101220_AACSQE mckenney_m_Page_102.tif
800f0ffed0eada1337c98f171f919325
814506b32421bdd95ebdac699c2c5c3c73033090
F20101220_AACSPQ mckenney_m_Page_088.tif
33ad9251232961c9cc8d8af25220c2fa
5a545b9fc8e6cd448f0c79e138342301abeeeeb5
F20101220_AACSQF mckenney_m_Page_103.tif
cb78cf5b5f6922c4c5e13312f32ca50b
60036f8d86ddf620331bbe24d631714cb70bcb50
F20101220_AACSPR mckenney_m_Page_089.tif
ace43c3358ebf2ca994fd145be4c7fae
0f0136db1180fdd161cd11a0fd53e38ada8cd0a4
F20101220_AACSPS mckenney_m_Page_090.tif
2e8666ad38d4fafc2b2390e8fe97e47f
e81108354cae4d60d5090a78cbd77a71a4c30ebc
F20101220_AACSQG mckenney_m_Page_104.tif
dbc1d6d8e2971ed615a9d93754eaf754
c6e7fc0d302b862e4be7bf8680fad826df790a2e
F20101220_AACSPT mckenney_m_Page_091.tif
edf82ae30adc91989d6759de5811709f
5aabdb812bd96e992190e60675310410974989cf
F20101220_AACSQH mckenney_m_Page_105.tif
279a7402796f179a8c9b97668f152f78
e4ba4458c94e9be6f623eecf1561242cc0844209
F20101220_AACSPU mckenney_m_Page_092.tif
7384132fab0946eb9a154743f5621b4d
faa02525a8926588c77040fde3d0a08d35910d1b
F20101220_AACSQI mckenney_m_Page_106.tif
8b146ecda1e2a8d6e1a636da3c90b8e3
7a04c15448e6dcabcc6309e347ea172530fca1ce
F20101220_AACSPV mckenney_m_Page_093.tif
cc111ca8e28bc57a92cdceda54b289db
82614ce5b2298a28bb5a09a8197c744164519a7d
F20101220_AACSQJ mckenney_m_Page_107.tif
48d7923cdd06eb75c16e0e01d2ef18e3
05f08cc2e39813c19eef8da488ddac4c4fc3db90
F20101220_AACSPW mckenney_m_Page_094.tif
06e78d9e9ea8bb53864ef73582ff5296
8df3d4fd9d63bf40d653f4121fd194ccd2e85adb
F20101220_AACSQK mckenney_m_Page_109.tif
4d8b19db4b8e72abae3e79d7be72a812
218c79116a4321225045ff08c9e5207177113217
F20101220_AACSPX mckenney_m_Page_095.tif
3fdd7ac14587b4cece6b581e4b383cb2
80931e5385b2df5e4085f3c49bdc9d5cd3078951
9633 F20101220_AACSRA mckenney_m_Page_001.pro
f6498956423fff18048f9e8fe3898708
112468cd332327f45517234c3c38041f823ea6e1
F20101220_AACSQL mckenney_m_Page_110.tif
c3d623ee90dba39bf3f89623ee1b0d02
6ee5122ec0bf12ebcf9df0de7bae3fedef8acde7
F20101220_AACSPY mckenney_m_Page_096.tif
21a85ebc7b952aac5bb3c88d02a83705
f427e6fb7e65ae1e56a90fbbd5bbda0b43cb6238
858 F20101220_AACSRB mckenney_m_Page_002.pro
4a884f6f101508327e39fe14d824c81e
3358a4480e5ee782db3c72ee39ebb3b1e09de86e
F20101220_AACSQM mckenney_m_Page_111.tif
67e37efb160fedc0141cbe9f3aef593b
da1031a9be5426a2536c37c6118374520a4028d5
F20101220_AACSPZ mckenney_m_Page_097.tif
694ac95a54ac9da38af9ffdfb82093d2
51072e225604bb0390c64623098986a02b603d68
4736 F20101220_AACSRC mckenney_m_Page_003.pro
531aabe1f6988aaec67646472031735b
e18113842f034a37065f911f8ecda1e9c03e3e11
F20101220_AACSQN mckenney_m_Page_112.tif
1b1241707a60586841c8511587e1ff1f
dbc67a07187c8f0da0d934c01d0b31516b8bec08
41063 F20101220_AACSRD mckenney_m_Page_005.pro
734029c55273ece923853247c285e436
66a7267da22f0243526ae4d69496f494bcf204b1
F20101220_AACSQO mckenney_m_Page_113.tif
8f068bd7048fa879aa88023714a27dd2
56775a1f6aeb5a47a849149d724cd643a9eed30b
F20101220_AACSQP mckenney_m_Page_114.tif
6fa25fff34c4f88b7711304ca4e41f70
cbfe1a18ba459a83a2b03f2590b4e6df601919e5
21140 F20101220_AACSRE mckenney_m_Page_006.pro
959ea42d75487fae120f7e4872849192
07ed9a8c40db6efb81a19d48907100c8841c3b37
F20101220_AACSQQ mckenney_m_Page_115.tif
2d14fdba3c9682db76697b61cf3bf5fa
c56439cf09af7595384056d4aec337edbb12ed7e
66020 F20101220_AACSRF mckenney_m_Page_007.pro
35e9deef2f781b904d6a5e1f81ad6e56
32f01c2224f74233ea9210ce4ccfb269023557c8
F20101220_AACSQR mckenney_m_Page_116.tif
91e0a110e095a52d01618258e7212e9e
49bd1880bb75c34cc9c150155e1aab71c783c052
48433 F20101220_AACSRG mckenney_m_Page_008.pro
d0f7af402881ebc9a28be98bc70954ee
3fc605e8a8c79db6b9cf263c835adf89f8d0ae5d
F20101220_AACSQS mckenney_m_Page_118.tif
671e7526251deb925332f016f446ba0b
426d644211ff0f628d10ed8ca48d50466dfa740d
52310 F20101220_AACSRH mckenney_m_Page_009.pro
9c926275e8727e4ca3d37c53026e2cf1
46a4e8476c8eea95201878e7cf7e89e4ae920cf4
F20101220_AACSQT mckenney_m_Page_119.tif
d64d82e7d5cd1932ab9724dca5be19aa
7207aff55b5b428951a237b6578f81438e7743da
4787 F20101220_AACSRI mckenney_m_Page_010.pro
8857878222b3473fc878f5c849b95392
d22f1bf46b39e55b0436f823924fb061a91ccaae
F20101220_AACSQU mckenney_m_Page_120.tif
60de5a188a80252f8f1c617328395037
249f2021ce645eb0202649f08d11753db969e45c
55746 F20101220_AACSRJ mckenney_m_Page_011.pro
9918f3f4a679ad95be1c2b04404e65e2
cbd0d0dd51463cc3ddb1bbd7f401180016aae90d
F20101220_AACSQV mckenney_m_Page_121.tif
d24971f1121b9297877e8c26bab54305
59567c721d8e349ccbd771682a567a8a59d1c0e6
61692 F20101220_AACSRK mckenney_m_Page_012.pro
44fdcc80af52a404dd342094af404f08
d6970675e325bd50105260ba8c44563a4dd1528d
F20101220_AACSQW mckenney_m_Page_122.tif
a1db94fe9a85d2677afce26fec01aecf
6962041cfdbdd96759d7b22eedb7a8c16439aa77
58657 F20101220_AACSSA mckenney_m_Page_031.pro
7c463db2dd7013181331b99ae7f27cbb
716a0a8554fc64332ff702f4fd937ea62350199c
60252 F20101220_AACSRL mckenney_m_Page_014.pro
1e4eb94c5135b7ebc75e95bd2338da45
5155751862286ac81c8118a06049ffdc03675510
F20101220_AACSQX mckenney_m_Page_123.tif
a3f7c2ed66bc12e846f4cdf223525749
0ecad3b299d46788f841f8b3f4ab9b9859c73608
61508 F20101220_AACSSB mckenney_m_Page_032.pro
6fd6ee72fb2f9f207706066745b65136
3189a5cbaf261d32b2b33b141eabc201cc471d43
58365 F20101220_AACSRM mckenney_m_Page_015.pro
c95ca873b46768f85e6e576fdb70d702
4bae1d98188906068389f604880b6b3ad5ddd820
F20101220_AACSQY mckenney_m_Page_124.tif
a4a5e03f5cc958c4c18325f0e81cec92
e742bb9c35f9e1c7cc956070c0bb849ea7fb6544
58334 F20101220_AACSSC mckenney_m_Page_033.pro
ced51ba2f8aaa48dfce5abfb5f7eaa4e
d39356d84094967d4ce63b26042e80ab5f22977e
59520 F20101220_AACSRN mckenney_m_Page_016.pro
f4d68aae9e018369723e07af864783e0
92d3f99c54061a78a2456ae91861239cd1164104
F20101220_AACSQZ mckenney_m_Page_125.tif
ffca25e824098d88d686302a40f968f0
cda85b86698b7608783498c64ceb6a56ae104b76
3160 F20101220_AACSSD mckenney_m_Page_034.pro
cc0116330a3bd9520051ac8cdd978841
6a851cca59cf8aaae987fa9bb60ac47a78b22b20
58176 F20101220_AACSRO mckenney_m_Page_017.pro
84a3a23a2c0e974aff80e97eea4fc1e2
2213b535394a2678671f3bb473c48a02589c2b38
56760 F20101220_AACSSE mckenney_m_Page_035.pro
b96c57d83ee8a7b51c74a276bb5ec119
63d94a89407f3476c320bffc65651ec486c5c1a1
45340 F20101220_AACSRP mckenney_m_Page_018.pro
18a564467e8a5c95bfb39d6566f2b480
e11778512aa12c1d9a2f3b91ac12a48595302f1a
57569 F20101220_AACSRQ mckenney_m_Page_019.pro
8c232c7b977544e9f34a16094949d6e6
f41ac102668a5565eda1ffe3beb5c53e6b6234e9
9803 F20101220_AACSSF mckenney_m_Page_036.pro
6940a53acb7d28af88719b621bb7c9a2
c9d7edcc186fe9a265ec169b82439532042c5089
22711 F20101220_AACSRR mckenney_m_Page_020.pro
e03c30cdb18c1aa46a6b79e9fe4736ee
cc4d9acd5410c5248a4f5198364f7a41a10a7e4f
56430 F20101220_AACSSG mckenney_m_Page_037.pro
783d7a7e849d979f636a513f09581553
bf934fe5785979f527a626ef93b78f01acd0c40e
45334 F20101220_AACSRS mckenney_m_Page_021.pro
0f78c6752af1cc87a4af8688eaa6f021
fb24526394e54fb4fe9a6d86a79156fef742f0a6
57126 F20101220_AACSSH mckenney_m_Page_038.pro
bd91417f2f981b86817b1e715e97a052
fbf8b081c546c35bb10ee17bea10268980b5083d
47792 F20101220_AACSRT mckenney_m_Page_023.pro
77756c5dc7b3732265c18e9fc9bef838
2679179cbea2ce1a4ca0a6ebb6920cd7ba2a0fa6
48309 F20101220_AACSSI mckenney_m_Page_039.pro
59283015f8a4590dc8978ec0edb09860
2d79aeddedf6258b74298a5fd40c256bfcd9b20b
54702 F20101220_AACSRU mckenney_m_Page_024.pro
602c914cd3996a2ff15b1bd87001def8
dec70383185d7e47eb1c56345f82a577bdd797d8
48639 F20101220_AACSSJ mckenney_m_Page_040.pro
e80eb5a3f34b4b642a666547fd244fda
38f6e9f278afa80698a15cfbb09e25e70dc8360f
61139 F20101220_AACSRV mckenney_m_Page_025.pro
e59cef313868d431be5108e9e73cb9f8
2110efe0fef140f5f0edc5c432c6171aa575b1e2
41470 F20101220_AACSSK mckenney_m_Page_041.pro
324bb2d24cf4f2bfd47622c30d64c889
f17d401d3ff4b2e1eb7023fbd65ea32cdf7cbdf7
61791 F20101220_AACSRW mckenney_m_Page_027.pro
ceef8b721c615e2c121c77c6e2bfec7f
2cda9e51f323040cb9b4de392be4befb6bc489b2
51535 F20101220_AACSSL mckenney_m_Page_042.pro
44a799fe1c23dc0d0a6dd2f617424da6
8accc44374a8da2fe1312f9c56351019a92574fd
60826 F20101220_AACSRX mckenney_m_Page_028.pro
fbc2383096c8799c836c4aec66199113
7ffe06802fef088a2d3e650ce13a31fdfcbdac9d
47651 F20101220_AACSTA mckenney_m_Page_057.pro
69e972c4e28aa5b566bdaf18f0aaf5db
12c85b8913ddd3efc91d26428e10ebf2d1615a0e
54546 F20101220_AACSSM mckenney_m_Page_043.pro
a90ce44bb52cf50eb57e7518b3967b9c
45b69e4b8e81a579d7fe013733b8d6aafb6e3366
62690 F20101220_AACSRY mckenney_m_Page_029.pro
2026b158bbe12454a3252fab4eda791c
7c6b3e65942d3232450f8fb06132ef450a16a8d4
48651 F20101220_AACSTB mckenney_m_Page_058.pro
04ee9d161f1a9333341c33b5b9d1bb81
8f5c2f733c0478072bd5bf2d01c88fc7aa81f39a
45280 F20101220_AACSSN mckenney_m_Page_044.pro
4a9ce15bc6be999ce232bc7980f47962
b6b67120d4ae52f7f4f3091389641438f3171ba3
59384 F20101220_AACSRZ mckenney_m_Page_030.pro
c27248ea0e7782a9a705f3640f2d88cb
472de407b78c80ecc410547e025a21cc2796e92a
48387 F20101220_AACSTC mckenney_m_Page_059.pro
aa3df189544b6d4ac7195c54fef4c90f
81f613f3483726f22627a5c5733075401be06bdc
48710 F20101220_AACSSO mckenney_m_Page_045.pro
3f25f5e229fb4365040ece672f832894
9a761cc2a6cb8374fc6806bc7bc35a21e0ca2c11
55304 F20101220_AACSTD mckenney_m_Page_060.pro
757d1baf5d428110b946c2f621f1e8f5
ba98c594024e775bad1fbbdfa7bfd6b6eb2d732e
40902 F20101220_AACSSP mckenney_m_Page_046.pro
e7b9a7292f540e9bbd6c939923b1a7ba
96477516768444513c80a3071036f3edceca6753
42920 F20101220_AACSTE mckenney_m_Page_061.pro
86e2875cf0728264da66e9d0a502596f
b88a564c8d2bd9cc527bf158e062779c7b2dda49
24427 F20101220_AACSSQ mckenney_m_Page_047.pro
27a673c10842b854ca5c04766c20796f
0310d1d8b4af826db6b97d1b95c83cbeab010c96
53945 F20101220_AACSTF mckenney_m_Page_062.pro
7c262551cd463f7b61da45e85c9270a2
01850698db385b107216a6070a170b08546d30f4
40281 F20101220_AACSSR mckenney_m_Page_048.pro
a01cfc1b8002c33e13de40b94f67cc39
aa7c1ed53aaad481d653d20d919a2ec7cf0d5a90
10177 F20101220_AACSSS mckenney_m_Page_049.pro
620e6cd12a55a3b78cf4ec30f93821c9
4adc6ee9ff6436744b7e5423eec8967d0bffdafd
49367 F20101220_AACSTG mckenney_m_Page_063.pro
1af04404e8c073e25b275c93eab1cd83
325ab7c51300e2d79711e9e7981f6f0e6dac9b8c
57105 F20101220_AACSST mckenney_m_Page_050.pro
c023aaaf2e78edc053b8aae506fc3e25
c73bd58ac213d4a90cc2c3f9400a1935b6daa2f2
52017 F20101220_AACSTH mckenney_m_Page_064.pro
eed96561061c05bceae3aa7a2f08ee43
3013b7d5b5502dfb7e68530141ab5ac52bf4abf9
59667 F20101220_AACSSU mckenney_m_Page_051.pro
35742fce38474062f35413d24587bed7
f916f75ca88e6dc3eb92c869b48c2613cc3ef22b
52992 F20101220_AACSTI mckenney_m_Page_065.pro
c5975f26b2360510f7c37701c14caa91
5542b1ca7bf44d64ef2034893652879aef4cf7f7
55687 F20101220_AACSSV mckenney_m_Page_052.pro
7fa1348947a204b6293e07a652a1ed12
8ab74cf5eced676fd1b381bc1cbd8c73df866684
38328 F20101220_AACSTJ mckenney_m_Page_066.pro
9aa138a9c529922d4c19c495fb681fb9
8b0b7b47bb18092f1e141a6734f931c77f23540b
51756 F20101220_AACSSW mckenney_m_Page_053.pro
633933cafc6bb2f04c89665a8dded9c2
27532e2a3d2cb93f188b93e5472df506c0c0e56e
55199 F20101220_AACSTK mckenney_m_Page_067.pro
a08fb854e8689b4869d8ba3e84ad267f
92572ccf837df08baa6c9aa4524eff92e8d2cd56
41715 F20101220_AACSSX mckenney_m_Page_054.pro
2d01f6fd898d38956316d68ecfa115d8
12c196ecf88beefa6debe1022efda3b2b76f3cf0
50254 F20101220_AACSUA mckenney_m_Page_083.pro
a44898b8388e8e28c24451f05ed8cdc0
eb2dfd5d93fbe18bbfc310552f29677c524e4389
57256 F20101220_AACSTL mckenney_m_Page_068.pro
48a33cd95530376e8b6e86d5f097b65a
a14c2949f29dbd39757081b1e523edd02b687cb9
37281 F20101220_AACSSY mckenney_m_Page_055.pro
cf44867bfddf266a8101afc0c0463380
43e822a6d2bbe0ce71dfe7c035625a400c5eea59
55202 F20101220_AACSUB mckenney_m_Page_084.pro
b479b951024e15b2fadb2e402794d395
e7c8ee97e2d191657c9a8ba433cc8742cc691806
65983 F20101220_AACSTM mckenney_m_Page_069.pro
02cf85c675552737172cb02c753206bd
69c7bc4f694fa2fd1e39aee4291d3d77535d36d9
46903 F20101220_AACSSZ mckenney_m_Page_056.pro
1635491e8a0ff76ab72f348a121d6dea
5f17ac1430507be82940d4b0753757a614266936
49472 F20101220_AACSUC mckenney_m_Page_085.pro
987f8ebdacc5fb433aa5a074f29b5ff0
ede7e64f494f28b8e5a00108fc9feebcd796179a
39342 F20101220_AACSTN mckenney_m_Page_070.pro
c064bf74e8b6818d224e0d815feb4056
beacb4041101186a171a600b728b2aca1de14023
46014 F20101220_AACSUD mckenney_m_Page_086.pro
cd507a3fe9395aca5d5c0a4bd974a89f
37b52e846c69c328edf7cd70b9f2ce6295cc06c0
61674 F20101220_AACSTO mckenney_m_Page_071.pro
5600f3fc702357ab8c5e0abbcd1cc6be
df060aac73a63b1395253a6ab56dfb411c8e2e01
43756 F20101220_AACSUE mckenney_m_Page_087.pro
fa5b3e9f586c6fdebe6a6c73c1f5bf5a
4af93dba67f4b3632a90c3f338ec82e77fef45ab
57038 F20101220_AACSTP mckenney_m_Page_072.pro
72dc3551900e6c07efe3a828ee4ae046
699eba8af2ef8e23801b2954b683eb91be31ad28
39225 F20101220_AACSUF mckenney_m_Page_088.pro
cc33157dbc66808d0540c071a64008b4
f171750771c4c3c7eef982fcf55fc29a7613ed7e
40945 F20101220_AACSTQ mckenney_m_Page_073.pro
7adb50c4f2636cf033308f0ee3062eae
93b5b6c3dc6b74b892a7cfe251b71cbde1363ba2
61665 F20101220_AACSUG mckenney_m_Page_089.pro
f74dfbeeb262b6b9b18c47b85805d834
ec11a0b0ce271879c795debb1eae1adb5b489890
55513 F20101220_AACSTR mckenney_m_Page_074.pro
71276768f4db069091e726a6b7e1562f
f94ff5474236906674824c1c90e53b34eb78eee9
2739 F20101220_AACTAA mckenney_m_Page_122.txt
7b52f718bc2386dd434833748dcac801
383a38ce5bfe0161af77554fc8c4cd9a63d454e7
37999 F20101220_AACSTS mckenney_m_Page_075.pro
5939e3a6198dc7a226736055d28b01a1
7751f0b7ca5cd30b9ee7bd7e73b3e54c0884eef7
2675 F20101220_AACTAB mckenney_m_Page_123.txt
76400a35ad1aced9b0d49e5a1f73d3b0
69b13f81b186bb1b4b73f69b51b0a5e2be66430d
52038 F20101220_AACSUH mckenney_m_Page_091.pro
bc3ce0c5305a51bdf96d88ce1fb7d82c
ae39d46b853e3cf73230c4b23fb4fe1161b9c059
57367 F20101220_AACSTT mckenney_m_Page_076.pro
08d69a412219b02ef662f945d904063d
27c4c47ed27bd601b82715adeb5f913310691464
634 F20101220_AACTAC mckenney_m_Page_125.txt
e5437b457f5865d98f5fa30bad2e57d9
565507278a5c1bc7f5d4440e354b616af3049b77
50779 F20101220_AACSUI mckenney_m_Page_092.pro
cf7361099a6100d873e2a6eab23e2996
539d9c492521e9705cab4b7dcab0498ffeb3931e
F20101220_AACSTU mckenney_m_Page_077.pro
e539c82f7544877a558679f40223abf2
5e2a3e7afaa8a9eb9a37800ed3f5318c81362491
583 F20101220_AACTAD mckenney_m_Page_126.txt
9f10a6d38c3010439fd0babf1ffa301f
035cdbf02839f70c42d37401fe29b8cb1436a9b6
55512 F20101220_AACSUJ mckenney_m_Page_093.pro
c0226a8471e971966a7e29dc1a3b6237
2bec392d8c85e87821e06a160447a38bb42f5eb9
50882 F20101220_AACSTV mckenney_m_Page_078.pro
8e8def50fd06da5386f56951b97a06f5
6d73e4390765fad150d3a891d1d7206d594c374f
2206 F20101220_AACTAE mckenney_m_Page_001thm.jpg
9debaf188e6bb0bc03fe17326c26bd65
f3fb5a56fff393b28b27240c1d46381df44172ed
60177 F20101220_AACSUK mckenney_m_Page_094.pro
033fba277cc9e1db8278bdd8ee6e00f8
2d5e6c8142c9d402d4ca7228147d1d9652dbc802
63547 F20101220_AACSTW mckenney_m_Page_079.pro
d5ea48d713a9dd3c4c4da638726f184d
234b59dff42997626566793180724a552535051a
1033470 F20101220_AACTAF mckenney_m.pdf
d7fad23fa9fb76a81bdffd0ddee688f3
df3af81584c8ab30c814e01c766e2f085f3780d5
47699 F20101220_AACSVA mckenney_m_Page_110.pro
07d9533ba43270b20eba82f02ddeea28
fd5194236b4b693150e1958a23ef3eecae39c2c3
46429 F20101220_AACSUL mckenney_m_Page_095.pro
cdd9fc048795d1cda0cee46badce4066
bfae9ad65730178e6b47cd874c2b02b1a2b032e8
44776 F20101220_AACSTX mckenney_m_Page_080.pro
fa16edd18db7cdec3ffdeb6a5d97ef71
4b3f6a69439cac152599d783af387fe9335486e8
3470 F20101220_AACTAG mckenney_m_Page_020thm.jpg
e84c3af0f8f2c1509bfb161694914f72
1e70f839a2009851e36e285177af8d4e688fe237
57281 F20101220_AACSVB mckenney_m_Page_111.pro
cf6a0aa8005ee60b8c5ada63001df9e2
01d2c3a9668d9a0d31ad1e503fdf287817c19e32
56630 F20101220_AACSUM mckenney_m_Page_096.pro
881d5b6b727025ee47447a1f042a65aa
4cb3c22227b6843a10a7bcd807853c9f27d2dafe
22546 F20101220_AACSTY mckenney_m_Page_081.pro
2cd26b5e4eb1e88d93139354f2b890b6
19783ff231750a35523ffd6cb50b7623ffa04137
37477 F20101220_AACTAH mckenney_m_Page_007.QC.jpg
21caba2407c79b325c09acc9428549d9
8f0f37306ea1a0dffd7229b1afa7a55ee3c52e2a
59273 F20101220_AACSVC mckenney_m_Page_112.pro
e28183c86ae6b589d4e178835961b050
3b89ffaece77d53b025bedb0880d072efeaae2f8
60892 F20101220_AACSUN mckenney_m_Page_097.pro
ac36ae06f4750e5072dc33eae9af8aed
f7cc822f8a1e6c2227c5cab59c182063d3c0e446
52372 F20101220_AACSTZ mckenney_m_Page_082.pro
1a2ecbeaac26ae609852f6a2f3cacd13
5d8bf4ed01724b516c4747800f8ce3b5cd3e0ffd
35449 F20101220_AACTAI mckenney_m_Page_120.QC.jpg
3e8ca7e5f2fca31a676391aff82432b2
b8e6bf834b92790d0fa58ca77fc7f30433237fc8
34442 F20101220_AACSVD mckenney_m_Page_113.pro
3ced200696a0596e2f55788b28075225
ccae6b4b6e773707235638b2ec14d88e69f1ceac
62248 F20101220_AACSUO mckenney_m_Page_098.pro
15643f5ea775a9bba5a250492155c572
2fc28ad98989319cdbb890b440fac40af5b97a43
6817 F20101220_AACTAJ mckenney_m_Page_099thm.jpg
6b01485b4401da8b3f15629d8aa1bd27
d3f7f1313e1ed6f0fcfdf3cb34f8ba5e81cf310a
47228 F20101220_AACSUP mckenney_m_Page_099.pro
e7438ec180d77bf7af202cf32b017243
444bca1f8b5014da19187dbfa075a0e567dad4d5
32660 F20101220_AACTAK mckenney_m_Page_074.QC.jpg
8242c97307cb487a348c0c6312aadd42
9c3612bbc146246558dfbdd5928dd53a5dc143b3
37642 F20101220_AACSVE mckenney_m_Page_114.pro
374828cdb942a1c2b6fb184dd3680ec4
a9e64c0d0485bad8b59ee2af17365116eeda5fd7
64104 F20101220_AACSUQ mckenney_m_Page_100.pro
161c37c282bf6fad49bfbf03589894e7
1b4b3beb7de7c236739af5b300c0f972ba93b76b
7855 F20101220_AACTAL mckenney_m_Page_032thm.jpg
432d06d4a9b60bf77da5ca4ab1b27fbd
4d84c0262c3b7e44678b4a36f4fa2c3197e7787f
19841 F20101220_AACSVF mckenney_m_Page_115.pro
bf1259194bee20ecc9d75db9c42e1b86
26710b7434ea397e5d1af647f3994262ba965242
55406 F20101220_AACSUR mckenney_m_Page_101.pro
ee8d2b3d8973bfa6b70c4a103ec96c86
5a5ee8bb460f1e285847c75ba2066794df2cd0a7
23151 F20101220_AACTBA mckenney_m_Page_118.QC.jpg
bee131d01b66f62fffdd8c444e2ca021
958fc9d7bd57ffa7933816fd9ffd1e5cbdc96634
29089 F20101220_AACTAM mckenney_m_Page_057.QC.jpg
4810fc266a3fcd4dd2668ad57595f609
6a0008ad95b5ca2590d35ec55043ab03957beab9
53646 F20101220_AACSVG mckenney_m_Page_116.pro
67f259c7b091239ec5929a9ef5e917ec
feda7bd97789f19f18f908e08e1032851900803d
63008 F20101220_AACSUS mckenney_m_Page_102.pro
f4fa4b1a2da91eefb7d8d2ffcbcdaef6
d863a2e5b642624d967965e46279475e5f8538a4
4089 F20101220_AACTBB mckenney_m_Page_047thm.jpg
0ce588a46dcbc407654a7f8e9980dcbb
3461981951a13a4e963d8b498f1d5546f1891d22
28788 F20101220_AACTAN mckenney_m_Page_059.QC.jpg
29d01ebdadc7cdcd6148769c6f293b50
265ca9fd25d6a16c1d9bbefbb3e2be5c6a711483
60877 F20101220_AACSVH mckenney_m_Page_117.pro
1996f2e999f8bfe39ddcfb87b1e0beae
012be20ee5ee3a967d8c60928653741b81527f75
58190 F20101220_AACSUT mckenney_m_Page_103.pro
1ff2cd539da0fbeed369d4bb3f7034ee
21d050c2fcbfed88e6617482d085648dcde84dba
6794 F20101220_AACTBC mckenney_m_Page_113thm.jpg
f2b967a568da8578d6697f692a4e1393
b333b9566f656c833998348b4b89ca4c63ef3e45
34899 F20101220_AACTAO mckenney_m_Page_016.QC.jpg
5f6d345e0ea44c50de63206147b63e35
a9862caa1e214f6ba0a6c53b4b7b5aa8760440ce
59892 F20101220_AACSUU mckenney_m_Page_104.pro
828d6febffef74342f59da6ecaf4912d
ef7cb4dba929b56cb27968f886e034d92a4f1ad6
7565 F20101220_AACTBD mckenney_m_Page_051thm.jpg
fb94331f1a1fdcbb8de45ca3fd011959
d0632d81b7a596287ace1a0bb07f59e41018c63d
7305 F20101220_AACTAP mckenney_m_Page_086thm.jpg
e23ed1a9f952d5a0b57acdd16d18f94a
bdb39a0e4dba3c8785a0b1534627e228d9410afd
37589 F20101220_AACSVI mckenney_m_Page_118.pro
73166835d7ee8d4472399cc9f558926c
7207f3daeebed54c1700da160395e17abe5ca3c8
48275 F20101220_AACSUV mckenney_m_Page_105.pro
8b5b243fc9ba305b731f9f53d248c947
9af5e989f3e49fcf94ec3a909cb83836a5d6569b
38353 F20101220_AACTBE mckenney_m_Page_048.QC.jpg
91f6f7c8b5a08ae7948cfdaff182693e
1d1e92984d52dfa45346ec06b4222474d07e92fd
8149 F20101220_AACTAQ mckenney_m_Page_091thm.jpg
625d95800343f6486e15a651bcef0cf7
8cc35a196bc148f5147df109efaa17585433b931
59044 F20101220_AACSVJ mckenney_m_Page_119.pro
747395fbe2ddf8acfecea429f39cdb1f
aee246170edb8d2972f5a1d1d4e35ceccab922d8
40702 F20101220_AACSUW mckenney_m_Page_106.pro
1ae8659329a277846eded69069c5ed3b
d83413e404f7731dc200bb62f22071901798fb33
7766 F20101220_AACTBF mckenney_m_Page_067thm.jpg
d6b775c60f97cb5bcc10343fdb6c19b8
d6b3a9065f4cfe9690db6d824867510b0e4fadeb
30029 F20101220_AACTAR mckenney_m_Page_008.QC.jpg
11bc62d477e7b2cbd26e51cc54f57239
e5a139f234c06c37aa582e73f69e976328bb5e21
67191 F20101220_AACSVK mckenney_m_Page_120.pro
e0dce7ffacc8dea262e2e0f7183d046c
175cf558f95c28c5f10169971edb619b6465fbfd
59194 F20101220_AACSUX mckenney_m_Page_107.pro
1a634310eff04a46db33dbc703505e1a
2a8b652d4accd2bf3b4716925ec7711cf515fef0
35673 F20101220_AACTBG mckenney_m_Page_117.QC.jpg
8f23f8212967b43a337f654cdbf6a369
2964e0d04172d07935c39748a7763308aa1420db
2300 F20101220_AACSWA mckenney_m_Page_011.txt
f2f1a3bb77b1ad9ac330f23d57a36778
3d958ca40ff3f2a8526999c0742b2e0aa0abe6ce
66491 F20101220_AACSVL mckenney_m_Page_121.pro
1200605d81fd5443f00be101b41a628c
19ff4d6e194b0a3e7d83bca5c01c396ba770c25a
57050 F20101220_AACSUY mckenney_m_Page_108.pro
641c5668e240e1ea1697494c06cc4c52
27b990d8c7fbdcbcdd302bf36856a5da0d369089
8993 F20101220_AACTBH mckenney_m_Page_001.QC.jpg
aa1cfdc5b315a99291e5e1db339e3a7c
62a3d6bc4db4984c9c9c29f8a5bdbb9c2c13671d
2423 F20101220_AACSWB mckenney_m_Page_012.txt
17c91b0214288a1d4ec27ae054e5c627
ac08d8488c79e55f659db3ee6566dbb18da55515
8079 F20101220_AACTAS mckenney_m_Page_076thm.jpg
e904e9ad447fa995ed3ad9521c5d0eb7
e74859a00b28b7cd7ef88668a2220ac87167afcc
68455 F20101220_AACSVM mckenney_m_Page_122.pro
7c2b5b937844620d49d24eae0c715912
a4e24938eeeec485693131df1274d8bc8a7bd332
57341 F20101220_AACSUZ mckenney_m_Page_109.pro
ac2517939c2369c9dcebff1812f9dc61
0332b66c90748a2361f7983e0179051833115426
8163 F20101220_AACTBI mckenney_m_Page_094thm.jpg
7ac52bc2dc29969fa872c7efc1c4d727
3e46059002f2fd3e94cc1a98933671b3a128812d
2372 F20101220_AACSWC mckenney_m_Page_013.txt
1abfe5eea961408727364c4b476a9f2a
23a4d8825ad76f1c8e98043b4b5819fc2ba18615
6941 F20101220_AACTAT mckenney_m_Page_057thm.jpg
65299170717d53eef05541c4cbac0ce4
f5fb3dfc2da9a8b0092e49d09b2fc240ad355573
66183 F20101220_AACSVN mckenney_m_Page_123.pro
7a47238e35eea55be2853a2b287f9bcc
56961c5df46fbc8bb1b06cd35961f1b6b1e61c73
31737 F20101220_AACTBJ mckenney_m_Page_039.QC.jpg
19178eac450af130317573ee00ef8fa0
d3c2f67d84c6d1f5ebcab0040bc477e4483cb024
2403 F20101220_AACSWD mckenney_m_Page_014.txt
07347d1198d3d5991650834dbc2e49f4
4543391e6a9eee7af39b1192986eeceddadb680c
8016 F20101220_AACTAU mckenney_m_Page_124thm.jpg
185d419a15dc0b272561418111c9957b
bec6786bc358d1b653a19fd39a1ca348b2de2bff
15564 F20101220_AACSVO mckenney_m_Page_125.pro
0017f21a6f3f7d7498d4f382b0731ffc
03dd42d424dcfe6cd1227ba2103fcbd3371d1fc7
29399 F20101220_AACTBK mckenney_m_Page_056.QC.jpg
eaa69adefd35c700f4cf2cc147888475
6f16b21268f17d795592ea68ad0750ade64b0ef0
2298 F20101220_AACSWE mckenney_m_Page_015.txt
97e7119d7dc1c7b2b7c04e79a5e5ca91
4ce1bd488d0cde28e21adcf53caf03655d918a1c
8036 F20101220_AACTAV mckenney_m_Page_027thm.jpg
1bb09c4956a6b3bacae7701a3ef69dd4
94fbd97ad09cad7b69de6df51b9b82225e54b6e3
13790 F20101220_AACSVP mckenney_m_Page_126.pro
26fe4be723113e436010b7bc3e13ee91
900c62c2c0a25a67a6ac6131a6bc06e2b16ff8e0
7616 F20101220_AACTBL mckenney_m_Page_040thm.jpg
1502b50036360db4f863a751f9a8a08b
11cd322c242eba5c1d9f268196ff8c55609a9786
2367 F20101220_AACSWF mckenney_m_Page_016.txt
28e6c13204e8c0e9b25adbf083d0ce6a
787d18530e07035802854ba0e9cdbb5e47f2dd26
34739 F20101220_AACTAW mckenney_m_Page_104.QC.jpg
37943dd8c7c69ab88fff7c6ff353a617
9f7ee06e04714d39b41dbc989a13d1f7242455de
502 F20101220_AACSVQ mckenney_m_Page_001.txt
e7428e45671d9f4e0f6459aa1c512563
9682803c6f7070ea459f0ba09a845d3dc07db35e
4213 F20101220_AACTCA mckenney_m_Page_003.QC.jpg
ff5995806e9ffa14d442345c15360eff
2c8af8c971849f0806059f0be82f48c5c128cdf4
36060 F20101220_AACTBM mckenney_m_Page_025.QC.jpg
0bfdb8e8d1a31598a45a0b8a28f76edd
757ad8a46742ca98efda46715a9427c41b243e8c
2290 F20101220_AACSWG mckenney_m_Page_017.txt
85c5c8030746c0aafa63be6ac3100a07
5bc1ed8644ef393281e4a8b80406aab3cddfd999
7243 F20101220_AACTAX mckenney_m_Page_044thm.jpg
7f50f50d0fb6c3dcb9484de2a3a850ef
5ab34a4b1dfd264a62a6cf6943fabfa9b7c07719
87 F20101220_AACSVR mckenney_m_Page_002.txt
cb18a5fdd6ea4534901790d2617ae130
64fd06c199eab557cfee26d6f6e9adedbf7dc85e
7408 F20101220_AACTBN mckenney_m_Page_035thm.jpg
36535ac28e93cc3e7a5238e922d7c84a
ef7e56d3889a58c88a6eb67062e80e85d0c1f771
2066 F20101220_AACSWH mckenney_m_Page_018.txt
a2c41f0eeb0865ed156cf76b29279d9c
3a8666c2482081e6efebf62383b3a1ac6c6794ee
7878 F20101220_AACTAY mckenney_m_Page_014thm.jpg
ced225b9e46d6d93dff90009251385c3
d5f9c1b9689c435289ada27e985d45fbfff00444
225 F20101220_AACSVS mckenney_m_Page_003.txt
bee754dc3fb5b726bbc84e1bf2ce1ff9
dcffe25f5bb7e14fcda412ae4ac2ab8d60a66314
1346 F20101220_AACTCB mckenney_m_Page_003thm.jpg
54f2aded9c13e700a5d9d483e3726869
fa62d824fb878f2b26bdf57e034eb07023b01db7
32104 F20101220_AACTBO mckenney_m_Page_084.QC.jpg
bd1ce335a96559a18ea83251807b8631
3baaa5eac771d473f92fa0d4d4fbda860803c366
2271 F20101220_AACSWI mckenney_m_Page_019.txt
79afc51655a4ff973191f26bd78e9b0f
ff203c0c308e60bff4f5d674624f0cf265a31a0c
7236 F20101220_AACTAZ mckenney_m_Page_042thm.jpg
f250030cdc1eb9f9d9bd2e4ad5701d6f
68539ff8fb00bb687dacf9f2dd4d15e10632f10c
1441 F20101220_AACSVT mckenney_m_Page_004.txt
7c16161bc3c548403aa0d428f7b6416b
e833741589d8ea5a2f4c3476d63d21dd6553689d
29793 F20101220_AACTCC mckenney_m_Page_004.QC.jpg
728080c381196e08c550c6979661c651
13bef80bc486dc0a4c528ad98213c5e988490313
37240 F20101220_AACTBP mckenney_m_Page_079.QC.jpg
11b6f1856785391d76abf01d9ead2f66
c590041d199c009c1dbd0654d6b25074ce1e1186
1956 F20101220_AACSVU mckenney_m_Page_005.txt
f027ed8a0506734958196a5cfb9d3afc
081b9d6d7e929d90258348d8605a2ec529663941
6263 F20101220_AACTCD mckenney_m_Page_004thm.jpg
481f531b4bf3a8abec69a209f1505b15
d2335e56427609ef5aad81726a95b66cc7db9c8d
9614 F20101220_AACTBQ mckenney_m_Page_125.QC.jpg
b6ea094f0036c17cfbcf90cbc641975f
5da56f620e371663d106dce1036b16d0637679d1
910 F20101220_AACSWJ mckenney_m_Page_020.txt
75381ed7ea4abe3f55eb3826bba1225f
d78aaa3b3495fec595f277b6d0f63a0a49dbf357
887 F20101220_AACSVV mckenney_m_Page_006.txt
d838431f7dfd3203a624fe327cf2c93c
87418fcc7080c3f2aefd95a870aaab9ada3e9d25
24635 F20101220_AACTCE mckenney_m_Page_005.QC.jpg
dc8a356ab0a5f584c178cd152e4d0b00
133ee75161aca4c3c49fd8c89879d8f17724ba34
7564 F20101220_AACTBR mckenney_m_Page_050thm.jpg
d7ac7987677a335e0684e216a79d57a2
fff02f816fd9f7f5a55c10cb101e813876b1804b
1960 F20101220_AACSWK mckenney_m_Page_021.txt
83fb8acc9b46b5b5ef2880b3c68d4658
92e5a4f5320b265b7429e9d2cdd04f016ab6cac3
2832 F20101220_AACSVW mckenney_m_Page_007.txt
c783537c9b1bef287f21526ed58dc81a
4365ecf54dbaa94c82290de760c85b3225da2764
5118 F20101220_AACTCF mckenney_m_Page_005thm.jpg
3af156c0605b3e236dfbcbdc709cc7d7
043d2aa0643c905fcc97963d1507ff6ca435f6d6
1969 F20101220_AACSXA mckenney_m_Page_039.txt
ca5a615cac431f471bf503aab2d6436a
b547ad1be4df8a2d34d954b86188eb5351d0a93e
7289 F20101220_AACTBS mckenney_m_Page_021thm.jpg
e106b3a1cccf3d53d3c5f5a232d54b9d
b2f91951c19bc9ddb34df3ab5af38d34573fdb33
2165 F20101220_AACSWL mckenney_m_Page_022.txt
45f0e0f6cbc20d608eaa138108b52fd9
9ef2f737a863ee7ccd383c33ee9bbe1a3f9daf25
1971 F20101220_AACSVX mckenney_m_Page_008.txt
404e3d5b7bbe4f3a436319d824802942
6d37a44b7d5e16bb423e323a2d6c8692cc684b70
13012 F20101220_AACTCG mckenney_m_Page_006.QC.jpg
cf8bd5dcbe3dc6d6096006a0cbe47cd9
4f5a2254b54d45c26bc5d4c0ae306e1b46df8245
2027 F20101220_AACSXB mckenney_m_Page_040.txt
f6ea724ade4fdc1c291ff841f2eae3da
5f8b3b79440fd60d6d7d7d92a4a66a668915303c
1926 F20101220_AACSWM mckenney_m_Page_023.txt
3689a3f787f4fc54412304f0ef4925ea
1a60e76b1733a3deac39648a4765e285ebf04611
2244 F20101220_AACSVY mckenney_m_Page_009.txt
5ca4973e4d9331e852e0b24aa23bd833
eeb1a2e5cdbe38f9615d76ed4e933b9f1e353d82
3231 F20101220_AACTCH mckenney_m_Page_006thm.jpg
3750d4082ab06734dad83c2846556200
9d3c9c86c863ee3064d9301a1e549272a7ed3f54
1807 F20101220_AACSXC mckenney_m_Page_041.txt
b0882a7d6af109cb92147d6b914f695b
945bc29b04aeddb7d6f60780a91b03258b216c1c
7936 F20101220_AACTBT mckenney_m_Page_049.QC.jpg
040e0471854f3f4788d368e9ad47ffb5
363a67a5958f152abc97f54a72a414848748fbb6
2228 F20101220_AACSWN mckenney_m_Page_024.txt
bf3ccaed7ac593467252f4195e1e0fdf
fdf461182e5f02b60c0c3d3d5c84212ba1df5ebc
195 F20101220_AACSVZ mckenney_m_Page_010.txt
5583b45441ff70e08c0340959f71c724
1dcf587554245838150363239ed4fcdb1a0f25ce
8411 F20101220_AACTCI mckenney_m_Page_007thm.jpg
0e8c58f3e4b65ae5557458d03276e5dc
153685ae4c6fdc8f7f5a19b138dcb58c836ac388
2123 F20101220_AACSXD mckenney_m_Page_042.txt
d47a044d3c42be5181b9d1770492ae25
3a6f19145ab034d057791e7328542f46b65d7b52
32224 F20101220_AACTBU mckenney_m_Page_082.QC.jpg
319e93f3a81695546b12d024b82cbccf
893a8a1068fa9da1e40d5c5c77cebba782ff16c2
2396 F20101220_AACSWO mckenney_m_Page_025.txt
b430f7a90585656ba1a6a5c3cf96d8df
f1201546da1292f688cb2e153fcc9117f87453e4
6372 F20101220_AACTCJ mckenney_m_Page_008thm.jpg
d162c7f2aa018e0e21a0c8fa5ee5ebac
f225ead5706f443c7c305c94da42e49f4d9e2f08
2211 F20101220_AACSXE mckenney_m_Page_043.txt
c65d132dd322c68a84962e936bb45821
2f8fbf13c82851603fc884cc22c6d4e11b2ba264
34028 F20101220_AACTBV mckenney_m_Page_108.QC.jpg
69411b2893abc13c4a6b71fed832d405
6fe53fc234ee384cbd82fb4cc97ba298f25b41f1
2172 F20101220_AACSWP mckenney_m_Page_026.txt
40f6bbef9a5e7e9bbec6bcaf1e4172e3
58c98008fae750d5899b0fe56e691223923b6fcf
30676 F20101220_AACTCK mckenney_m_Page_009.QC.jpg
9fbcc5cce1545f908be09d47197e49ba
8dbcd9290386e3783ffe74038f2d13a241821137
1797 F20101220_AACSXF mckenney_m_Page_044.txt
8ab5c1ff01f648c4c78f5ce62eb5edd3
4f4ec387f831d447dbbb698d83ec268bd27f3ddd
34205 F20101220_AACTBW mckenney_m_Page_031.QC.jpg
4fb708cd943955b4285782cf793876f7
1881b27cc10cea8c8130125dbb682682091b295a
2384 F20101220_AACSWQ mckenney_m_Page_028.txt
b38a1761c20b5b3cb8634faf0a80f405
768fc3dfbf474b3304faa806880b0afeb30d69c8
7064 F20101220_AACTCL mckenney_m_Page_009thm.jpg
d79e0a8e9a7c8bdd23bcefee5b1c85ae
07a611c5f24c7a17c348b9cd6d4a5389e0e29364
2068 F20101220_AACSXG mckenney_m_Page_045.txt
5bab517561b5b6cb69acd87c8c8f13b2
0161800484c2a868ecdec98ac68b7b43d42a85f0
191115 F20101220_AACTBX UFE0022567_00001.xml FULL
049142ae979294fd7c8f458d94eb5edd
215bcf540a0599dbbe056bde9d9171787d18b158
2333 F20101220_AACSWR mckenney_m_Page_030.txt
72e5869a9fa15e40c447f2d9de1ea3da
73f548f5f1e7aa62d73c54a0bac1b08cd72c86ea
33106 F20101220_AACTDA mckenney_m_Page_019.QC.jpg
2ff254c15a12e37c6191d4872d92aaaa
8c09ac03bc3c9156cdd37dfdc409ee43a6990ce4
3984 F20101220_AACTCM mckenney_m_Page_010.QC.jpg
508fa80db67c25949673688fc4c1eaf9
4d114409c7346aa3429f63080a48fd2d08e9fa59
1762 F20101220_AACSXH mckenney_m_Page_046.txt
362c327bda88f7b413c7b6bdea268ccc
01aea8103f95952e2399132e1a715d5040b93ad4
1757 F20101220_AACTBY mckenney_m_Page_002.QC.jpg
1f6975f0199cf6300499aa62f0f77e13
fbe20c33e6832ee891c3003f038f549b39c9d151
2302 F20101220_AACSWS mckenney_m_Page_031.txt
35c9bca3082c3408043bd156393c858e
05d9b3c5be2266535104efae81e9b02a7623127b
7526 F20101220_AACTDB mckenney_m_Page_019thm.jpg
2a3e1a678581156c2150a9b068c8898e
6a05056295d229b4f02c86758f8ef8265520246b
1274 F20101220_AACTCN mckenney_m_Page_010thm.jpg
d449a748f4463cd833177e8f51552f93
c5f54cda5afe95553aab8a37ce0ecf57f7cb3a85
982 F20101220_AACSXI mckenney_m_Page_047.txt
ac1b0ac2e318a0f47b68862b88439d2d
2e5dbf30effa79f1cee23ff7fd17a05e2e23d8c8
670 F20101220_AACTBZ mckenney_m_Page_002thm.jpg
519f24800c3fa7deba46852c662af533
ac2fa14da75f1140d12b419e373b372f6dc13a4e
2407 F20101220_AACSWT mckenney_m_Page_032.txt
78b3302960fc5394241fba5ecec7083b
e9f041b68edd8cd57a0a8a2331873c696ebbf311
14734 F20101220_AACTDC mckenney_m_Page_020.QC.jpg
d09274381659089fd0632849d61b6a07
8257d3246bbcc43e9bac952067e232c49a9d56ea
32390 F20101220_AACTCO mckenney_m_Page_011.QC.jpg
55b2e8e4cd339000826c0c492a74ae2c
99b8504ba6b92426c53c2e74463da00936b1c994
2079 F20101220_AACSXJ mckenney_m_Page_048.txt
ee11485f5a7c1d3d0c084e1a7637bc33
fa37c11dd8135fa158a6e4ad0f1c8fcdf8bd23bf
2296 F20101220_AACSWU mckenney_m_Page_033.txt
e240db6df58af86d958d2924f8340c7b
7fa7350af4a2a3d03f503faa35780d8131ef2971
29866 F20101220_AACTDD mckenney_m_Page_021.QC.jpg
cf92cbfd1deb1e812182e1ffa8f00bb8
d56d1dda8e39adc088ac1a1a3e1ea7743345fddf
7356 F20101220_AACTCP mckenney_m_Page_011thm.jpg
34191a1c40d86683e3cb64ad5c1a5337
99ae35627e3e1cfb36c9c7bc466c9c5d5e4717b4
132 F20101220_AACSWV mckenney_m_Page_034.txt
f5a258c5c934506d7de9f39e42affaee
763f663216c86f5c2871f5147ff4061dae9c2d88
32143 F20101220_AACTDE mckenney_m_Page_022.QC.jpg
732809ae11bd317a4e975a400826357a
ead59e43c4c4c22b8a09f6790d25ed8c1d6297d0
7941 F20101220_AACTCQ mckenney_m_Page_012thm.jpg
001eef323011165b1f4568751eb53470
78ebbe50811dae26cedbdbfb91c4e015f2ab7efd
685 F20101220_AACSXK mckenney_m_Page_049.txt
cc8bbec55ae73990ec02540e5cb3192f
95dcce91fb7c3f8c8ba3e103ba5bee45c777ad58
2292 F20101220_AACSWW mckenney_m_Page_035.txt
8c8c999fd493cb9adee996070a9d88a3
bfa5cfd4c7de209dbdecdb20114dda4a5f431489
7651 F20101220_AACTDF mckenney_m_Page_022thm.jpg
4615bb2981e029638765a45c02b1a702
b685e2c1202f8e05d5cfcadcb89278279487207c
29378 F20101220_AACTCR mckenney_m_Page_013.QC.jpg
173b7a7d48140546c7395afc71f2fcbf
f4e54c3e6e408a763747abbe3aa2bef96769c4ce
2343 F20101220_AACSXL mckenney_m_Page_050.txt
31896569fb23438f073e5c8f51269cde
a9fc0557e47f9fd7528dc6fdd7a9d664edad8815
408 F20101220_AACSWX mckenney_m_Page_036.txt
85d1725d72e82967580fcf90c5cdf53b
69455dd7108e797e0d7c4cf75c5f8d22d10f5c76
32442 F20101220_AACTDG mckenney_m_Page_023.QC.jpg
ea1d4d2066c7520bf904f729b879135e
16611b59ba2c7174f70fe42b94cd4280c4dd352e
2278 F20101220_AACSYA mckenney_m_Page_068.txt
d430e63b6e79a82874cd3c3c9ee02ddd
1dd83eb9dd660c42b360e60a63fa8caeae204514
34565 F20101220_AACTCS mckenney_m_Page_014.QC.jpg
02ae8981d85ffdb15586332f27e8a104
e03358a296bae9ab8a156528b00d75e97b5e7eae
1863 F20101220_AACSXM mckenney_m_Page_054.txt
e09e20800c497ecacf5fa3d55f30e992
5efec493506b4af87442d9f20218aeac20eec434
2276 F20101220_AACSWY mckenney_m_Page_037.txt
a390cf348fafa279a6b4988199e4630e
5e6d18fde0897d7b53a104cbb9beb478ea57009d
7945 F20101220_AACTDH mckenney_m_Page_023thm.jpg
2604a5a2ceafb1592246dc58aab20603
0e21be7488f239d6f636a72d5c54ae174c534a7b
2581 F20101220_AACSYB mckenney_m_Page_069.txt
dbe51fda039df3f98912a6e6a474ae63
43445014f134b715bd59591f600e08aff7c6bcca
33258 F20101220_AACTCT mckenney_m_Page_015.QC.jpg
a283aad0fdc9e7d71685c8f8cbb90823
8650aa5d3b9df42d97daef46a78f11b6f0931111
1648 F20101220_AACSXN mckenney_m_Page_055.txt
fc1be0b1f66ef5be5bcb23c1dbf042f1
a6a49b7eec6c01f28c1f61a53e87b02f6d81d4de
2359 F20101220_AACSWZ mckenney_m_Page_038.txt
2b181c26e73888702707903c7532403b
d9e913580b89cb86fc04690f04fda0c036bd1f72
32126 F20101220_AACTDI mckenney_m_Page_024.QC.jpg
bbc7a7c9f5396343bde6c968fffe9556
d95fee0a579ad8bf45df8356b4b90492c536ae0d
1605 F20101220_AACSYC mckenney_m_Page_070.txt
1ce999195f8f413d0392fe2f3c7e8017
0e26495306bd72192b6d33a3107708c521d956fa
1880 F20101220_AACSXO mckenney_m_Page_056.txt
7b3580c896443c9904749eca962c0757
5bebf8eb6751659927044640dd3b8c222abb3b90
7357 F20101220_AACTDJ mckenney_m_Page_024thm.jpg
cb632ed6926626d41fcf02ec1b4f6efe
d56dc04514add973818bf60bbafad6500f06044a
2413 F20101220_AACSYD mckenney_m_Page_071.txt
da8d2aa9683d081b46ac15f2facb64e0
7c27d48dc8c4f4f499b807e15c2332106a4cd34e
7650 F20101220_AACTCU mckenney_m_Page_015thm.jpg
358c2dbbe911de3a78238bbe36452f64
63591bb8c1c940c547846f0c185e4f5d0b04b670
1898 F20101220_AACSXP mckenney_m_Page_057.txt
a48345e80861cf831e54adac5b7c4238
ddcf26f7904f9fbecdb3d6cef1dd262163c45271
7991 F20101220_AACTDK mckenney_m_Page_025thm.jpg
b01c6aa05fb269dd78b730888ab260e8
1ff66d2bf08f61829a14801366d8dc1e82dce99d
2249 F20101220_AACSYE mckenney_m_Page_072.txt
e5952eedfee1adbee98b0251d93a3fd9
0aa3db27fcd31b7074c45b0e97ed5e9c2d885001
7957 F20101220_AACTCV mckenney_m_Page_016thm.jpg
ddd5c8855179b5d7401437a9c9ce5d58
c35a922047924fc70077510e74526e1630d76ad3
1927 F20101220_AACSXQ mckenney_m_Page_058.txt
47399af86c0ab1d34ec37de3e20802b4
ced8bd228fd9e18cabd82408b4da9f9cfa949abf
29924 F20101220_AACTDL mckenney_m_Page_026.QC.jpg
520b03205662e98e9eb13e5deefd5d7c
f9021851568843675a60331d4f6f5d135aedefba
1737 F20101220_AACSYF mckenney_m_Page_073.txt
434f92ed445db82e2951b240d614ab9c
b1e220e5357146a8af45dd5019faaf9b1140ecc4
34392 F20101220_AACTCW mckenney_m_Page_017.QC.jpg
0d048b7350873b66b625f04420fe44b8
cdf6ab19691886d5d8c099fd89eea1712ba4e577
1922 F20101220_AACSXR mckenney_m_Page_059.txt
7bec72f0f7429b1c4e7c5738aad55366
ef2427b9cc456209518c15a59b95f729c1a44e01
33070 F20101220_AACTEA mckenney_m_Page_035.QC.jpg
266b09bcd05031db09466b634f0fee9a
67e0572157dfa94e71945af7e7aff96dad181c5d
7341 F20101220_AACTDM mckenney_m_Page_026thm.jpg
10d202e8b4fb316a3b695f0ca47288a6
331c5a275925d817c1846755df7424b4ed69fb3b
2241 F20101220_AACSYG mckenney_m_Page_074.txt
ca179ca5181974571c6f37c37034e7c4
7c22e3f481851272dda5644af2c5d76026876b69
7860 F20101220_AACTCX mckenney_m_Page_017thm.jpg
4e7a2cdbd3f71dd188317969403c3db3
d5691b438c10c8eb2de1f4e37c606f45fa5ab2e6
2202 F20101220_AACSXS mckenney_m_Page_060.txt
e699cff6116f5bfdce8f2af4a242ed06
6549f219130063f6d9b72c67eb8f1e1a510bd6de
10916 F20101220_AACTEB mckenney_m_Page_036.QC.jpg
40a715aab19a9201879003d0b1adedee
251e8dec76c3bac35324f8c8f0ecc98b765ff8ee
35292 F20101220_AACTDN mckenney_m_Page_027.QC.jpg
88c66a204a122319e4eb90250a361f51
67b7d55eaab529e21c489d6dfe698b4b3f442602
F20101220_AACSYH mckenney_m_Page_075.txt
2a64584a6b4a20ca65d92e3d5cff00bd
2a35af88359a52eb384ba7ecd42543c58a2c3b9e
28959 F20101220_AACTCY mckenney_m_Page_018.QC.jpg
e6befd58f699e1c716009be80aec667a
94b32cc86219bcc8564ac56aa53479fb1ecb60dc
1765 F20101220_AACSXT mckenney_m_Page_061.txt
d38fb6b7f44672387060eaef8f5c28a1
4f8fa67a962f84641234e14c4a7f177a0c79b5d1
3227 F20101220_AACTEC mckenney_m_Page_036thm.jpg
e6b81163467f21c7438fdcfbfdc9d7c5
7d820475ffaf504d9a3dbe3dc4501d3748f377db
35285 F20101220_AACTDO mckenney_m_Page_028.QC.jpg
3d8e89fff64abbc2be668e76e1c442cd
a83000aa6424bf9c191b5d7d224d05f024e080b1
2280 F20101220_AACSYI mckenney_m_Page_076.txt
e96dfa359859c95f9295dd45cd4d1633
adee46af64940b69e6d46da3fb532da855398594
6796 F20101220_AACTCZ mckenney_m_Page_018thm.jpg
29647e97c9bd6f0dc756cb8d7d4ace48
1dbf044762e80fd6d66cd311073e04aad96f989b
2129 F20101220_AACSXU mckenney_m_Page_062.txt
84b94088cf8732aaa7162875de201d94
8f4b95892f433b01569def1736d6f7eb8eb9db99
33917 F20101220_AACTED mckenney_m_Page_037.QC.jpg
29e828f64cfddcf31a9d44cdb8f634f5
ef22e811fb983c8271981a5ce9eba3e305246e7d
7931 F20101220_AACTDP mckenney_m_Page_028thm.jpg
68e4b3cdc2cc6921c489fa9e288bb4f0
9890af58c04974cdeb9f847ec9cfb2591a140c23
2418 F20101220_AACSYJ mckenney_m_Page_077.txt
dfe06d9727d802a27bfe0c9897aa09b5
576d215711789f4dd78060c0aaab43416311f847
1965 F20101220_AACSXV mckenney_m_Page_063.txt
6fdb0e5317bccc3cc6c50dc56616d0f8
884c9cfa585630432b68abbb66cf911cccef07d2
7710 F20101220_AACTEE mckenney_m_Page_037thm.jpg
70dadc3556fa8779268d871197e22187
bfe458b84909a92349af3c6df0a4bc66a08dffb6
35879 F20101220_AACTDQ mckenney_m_Page_029.QC.jpg
5c0ce82c00561e963be8a95f9310afa8
41f8934515b789b07636d760becdb0be8de68815
2087 F20101220_AACSYK mckenney_m_Page_078.txt
c99dfc02baded9d3ff148d6d6235b979
37835c9e59056fa9eb87276b86207d6af87d4797
2058 F20101220_AACSXW mckenney_m_Page_064.txt
f363b5a0932195a0c02d2025c6ebf91f
fe6a48b8a59bf7ea0fbbf83aa6fd52d4c64a2a09
33339 F20101220_AACTEF mckenney_m_Page_038.QC.jpg
6a3b714ed2903ac7576c66338a5b2fa0
0b3b88152b3b914fef378fdbe2461541a464dcf2
8104 F20101220_AACTDR mckenney_m_Page_029thm.jpg
d5a031c63aa42cef76c05e0a2987f024
76afc9c34e672ce910b1186eec026fe6e126b409
2093 F20101220_AACSXX mckenney_m_Page_065.txt
219e125505e9e3c7adad55c0a7bfff7a
bfb0f0d4514ba2c523acb26cbabbe6ad8441eb4d
F20101220_AACSBE mckenney_m_Page_108.tif
0a13a8c0734d88341d7f4b49b9fe2bf3
aeb54bfd925031e5dfa92135176cd9dc10b2e416
7602 F20101220_AACTEG mckenney_m_Page_038thm.jpg
0427d15ab1f9a9d9299979c33c61a359
b8f5abf45f7645ecb9a680d66e259f6548b2cf54
2232 F20101220_AACSZA mckenney_m_Page_096.txt
d966d51ac6d1caf8652670608831341d
e8f61c993f8c42f3bfd7a8193af9249f0d9e859b
F20101220_AACTDS mckenney_m_Page_030.QC.jpg
8cde8e6b31cdbb1f8d2ecdece71fcc99
0bd60b478bc5ba23419186950f0d5eae517ce8e9
900 F20101220_AACSYL mckenney_m_Page_081.txt
e70440b384657b81a5824b507f8c2428
20d42c385f09373932ff4c126735013f6bfb381e
1528 F20101220_AACSXY mckenney_m_Page_066.txt
b95b6373679b02ee61c4a178ae8e57cf
248558623dd1d957ec73feefd21b8aad5c80399f
127327 F20101220_AACSBF mckenney_m_Page_121.jpg
ffcc3afdceff411d469f1add91245dbd
619213d3632010e5fc0194cc6cd08da88893bc33
7923 F20101220_AACTEH mckenney_m_Page_039thm.jpg
08b6ff623c1e2372630ab4938d445791
f01d834770e470cbc2fb91fe08ca53e67ae193ff
2389 F20101220_AACSZB mckenney_m_Page_097.txt
011b74716d038e27ae989004acedfb35
91ae5c3562ea615acbc88e88770839b60bf11b68
7720 F20101220_AACTDT mckenney_m_Page_030thm.jpg
bd2aa2f34b56190b3edb1f54d679494b
4c802c0b698f3cfeb41626e5988840013a959313
2128 F20101220_AACSYM mckenney_m_Page_082.txt
60d4394575cfbf7986b98c9de32c9847
97ec4b5a17b75ecdadad03962cf7f76fe6c0353f
2259 F20101220_AACSXZ mckenney_m_Page_067.txt
12a482dff7efc9a1ea2bf5d2eb6aa207
1977ca4a38613fcf051e603a4d916db890003dbe
F20101220_AACSBG mckenney_m_Page_126.tif
8e950ac867885f0c0d21664ceb0bcb92
55f8c2ac91a565153c312d4aaa567cf4fd849f2b
31361 F20101220_AACTEI mckenney_m_Page_040.QC.jpg
9e5acb3f56d793706d216263c5286a68
272f4779ab756259c79f671d58a9d4094f563b85
2439 F20101220_AACSZC mckenney_m_Page_098.txt
9811e9be69aeaa6459324c995b1b5177
7e8bb37b80d7f82167858a352774d25b00e5d030
7800 F20101220_AACTDU mckenney_m_Page_031thm.jpg
7918852040d63d91ee7505ec1d8f6677
6d2294de19de88c6ce30b71b3d952202150aaec0
1988 F20101220_AACSYN mckenney_m_Page_083.txt
f1315c6c1b90da62d93ee92c4df76307
7fee0f5b4f9f49ec05ad3146a60f911093b34ccf
7188 F20101220_AACSBH mckenney_m_Page_084thm.jpg
e08c4b44326f6b1f4f2f83ee26977ea4
74272081baa80e2dc637e4feffc31c4b71336085
24481 F20101220_AACTEJ mckenney_m_Page_041.QC.jpg
096d0231e6768e95f9b2d6aa456da800
61f0fd77938ddfd116597e6615f09a7c7557af5d
1923 F20101220_AACSZD mckenney_m_Page_099.txt
7ccf89ec7cc03baf509be723f6f4bfa9
e07b9accf3d27641fc6a8040bc5f41717c17544d
2282 F20101220_AACSYO mckenney_m_Page_084.txt
b8ffc5a0ef882662afd947e85ddeb1db
9156da1a81e2b94ece3c5a758147e0ede055740e
7749 F20101220_AACSBI mckenney_m_Page_068thm.jpg
6b120335834d5c449311dd377d8ea764
9a1900b773d02c7559555ccd95a066d76d11c62d
6431 F20101220_AACTEK mckenney_m_Page_041thm.jpg
2d701eff5c30927de2ba65d64e7a0408
c4d96910d643df3ec506de6d2509eb6f0a8cba01
2518 F20101220_AACSZE mckenney_m_Page_100.txt
eabf638dbfb99caa61cfd7e5a1151ea8
3fa8e2194c9c169378ec1fbaebd7cdecf53305b1
35618 F20101220_AACTDV mckenney_m_Page_032.QC.jpg
ad5b04a798d5a1f336cf4f0bacbafe26
8ed2852710feca0074d8d12560fd8cc64b948c6f
F20101220_AACSYP mckenney_m_Page_085.txt
a4e9c831cff9c014a79fbecd557f660d
163184075d54f547c6de491eeb2c165d79614c19
114883 F20101220_AACSBJ mckenney_m_Page_032.jpg
377c66483ba2990645c9f5ed3efef0aa
ac769c954c8f889fbd844edd8b9e380ea178c4cc
30000 F20101220_AACTEL mckenney_m_Page_042.QC.jpg
b9b0436de5556756244b51914db42726
0edea154afad44ff290c506b891fb679d1b7be76
2245 F20101220_AACSZF mckenney_m_Page_101.txt
6249be7c1583ecf8d14ab843e8770c47
a9aca2fea7df221b82d8ce2dba0635d9a9cadb1a
34261 F20101220_AACTDW mckenney_m_Page_033.QC.jpg
c85d4b86458884b78dd708caeab868ec
903e53a72e958c07d699e260c854ee1203abcc13
1925 F20101220_AACSYQ mckenney_m_Page_086.txt
31a1c800f44bd720286565d506751732
379fe336d23963798e1c0bc71cae4a7c0129fd7e
108700 F20101220_AACSBK mckenney_m_Page_015.jpg
a83ac7c9f3b972644799f73bd5b173a3
831cd8b4ed0f032fc8488e0bc75fd21a7fa867db
32398 F20101220_AACTEM mckenney_m_Page_043.QC.jpg
6a0e5081eeb84b19c8d617239c6f5b83
22ccf27ef834be553d4f0abf31a9803a4a88384a
2471 F20101220_AACSZG mckenney_m_Page_102.txt
abfc580bcc41cf58bbc1fac32ed68c22
05ea84a3c64741b99931bd85ca27b3e2aaeb32d1
7614 F20101220_AACTDX mckenney_m_Page_033thm.jpg
8e1d44b148d46f831562cfabe8165829
4bf70073f9882bc3b962b0fcd1292df177972983
1725 F20101220_AACSYR mckenney_m_Page_087.txt
31cf6987c249aba0d225bc5b96f1b327
a9084a9c43cbc5d58b2abf0b9a4a10888202d705
26943 F20101220_AACTFA mckenney_m_Page_054.QC.jpg
f0f8c0fa734c0e33dccf943f6d9d5558
861a28a83816c6765a455c60298614e89e84d555
7604 F20101220_AACSBL mckenney_m_Page_062thm.jpg
c52eca7ffc16629e65a6cb43fd9dee2f
71ba822fb3513f9b910921f683cc201b33bd322e
7379 F20101220_AACTEN mckenney_m_Page_043thm.jpg
1feffbbc9fe802431a001ad3056b8734
2de555558ad3596a40d8448c8dd7cf7e3ab16584
2287 F20101220_AACSZH mckenney_m_Page_103.txt
1c4c308624ec94b128cef5d37965a2d7
9eed9c6e98025791c7acb212346333200c51932c
3049 F20101220_AACTDY mckenney_m_Page_034.QC.jpg
a7dcaeca84822a28c8ac8f0b39916675
1b32a4d298eb8be65073a8ef72bce955832084bf
1719 F20101220_AACSYS mckenney_m_Page_088.txt
461b045688b2a561a8e7c1e3926792a8
ae3d57480f0a45221735a62f43f85909e55066df
6773 F20101220_AACTFB mckenney_m_Page_054thm.jpg
4520130c2b3fdaa26b67817cf9b87d05
8aa4b794c561d494a0f1f9ac224add60c26ec85f
47519 F20101220_AACSBM mckenney_m_Page_090.pro
c7b684c0e1f155f4423ad4947a2ad46c
f136f76c2bcc0fb8e585747b213e4761312c5977
30258 F20101220_AACTEO mckenney_m_Page_044.QC.jpg
7a2b4034cde9e6acb15efaa2135b76f8
ee86a35c45fd273a272764c3257fa5c5996a33af
2357 F20101220_AACSZI mckenney_m_Page_104.txt
082858f7b0e19e20f8d5d55e916b8493
1da501d6fe80e28d82b6d18c182be05a5db8f5f3
981 F20101220_AACTDZ mckenney_m_Page_034thm.jpg
7b1d8196ad7f115cbc9a7ff09f099dd6
8cc74f2644cd0f0c1b59a0c5b704a722572a61b1
2430 F20101220_AACSYT mckenney_m_Page_089.txt
338c283c14e8c8f1c3019328e69a2654
1e74085603bb2faf303d7e929b2ccd2c24d986fa
35104 F20101220_AACSCA mckenney_m_Page_107.QC.jpg
f064966f1a3450a8b6c0efaa8396bc23
482949c5b1bcd01c6128a9987f4341005c15b81a
23631 F20101220_AACTFC mckenney_m_Page_055.QC.jpg
8cb7744152984b7c75e7638bb941ec44
41f53b0f4edaff9af98e535040883cd7ae5d58c6
7401 F20101220_AACSBN mckenney_m_Page_085thm.jpg
921daf5c6eb3dad9e05eeabb8621d1c9
8329e686c78f912e9bde71d86b712603d6b682e2
28460 F20101220_AACTEP mckenney_m_Page_045.QC.jpg
51f7533ef8bbc31e0dfa9ba824c39b12
e15a582c58a6c000502b986bce8d0ce15220cae5
1957 F20101220_AACSZJ mckenney_m_Page_105.txt
99427a1a81c133c05545f88bc41f1ed1
adf7aec4d9a9f1e8aed237e4ce598dfd4608460a
1943 F20101220_AACSYU mckenney_m_Page_090.txt
20409f3652dadccdff9ebd0f5ba651d1
10548ab0488e2853fffc00da5c39db8428fac6c9
121125 F20101220_AACSCB mckenney_m_Page_010.jp2
0a2d615000f228b296e17ade491ce7e1
0e23527206ee373f3f0d3662dc412814f4dc9795
7087 F20101220_AACTFD mckenney_m_Page_056thm.jpg
f649528cafcca070a5977e7de2f8f8d1
7bdbdcfaba2e486dd00cb01d5a664e12b37d55b9
6212 F20101220_AACSBO mckenney_m_Page_055thm.jpg
35c06985d109cc303a9d1be517f30707
cefde7d3a40e653d2a34d65d75a850efaa20eb0e
6960 F20101220_AACTEQ mckenney_m_Page_045thm.jpg
681c554652c3f812b0c14000b5c1f412
86967678c1e2560382d005d78db2177649046eee
1768 F20101220_AACSZK mckenney_m_Page_106.txt
56544ade00011fda4f464ef0640d8d77
c9ad387ca2aaa9baf3b380022a7db72a3e521a1b
2193 F20101220_AACSYV mckenney_m_Page_091.txt
db527adce184438dd561adc7cc14a67c
4b9aeb5c6536c81b3f62138efcb31b924d681665
7678 F20101220_AACSCC mckenney_m_Page_109thm.jpg
f3991ef19c1e3975ecac304c253d42a0
cb459d2975ad393adc7696bd161c7a858e6f31fe
30386 F20101220_AACTFE mckenney_m_Page_058.QC.jpg
ed3e679fbb0929584797a36692dc5940
21c6c79edd56932d8453507ea88aa1afc5f2abce
24993 F20101220_AACTER mckenney_m_Page_046.QC.jpg
760efe4339fff8e2bfdab002659814ed
ba476fddd1610e0442c1d930560892aca667e33b
2335 F20101220_AACSZL mckenney_m_Page_107.txt
33252e78da62ad380ac4b0afdcdcfa0b
a8524a3c7c5c037d4df64f600b14b0168385edd1
2064 F20101220_AACSYW mckenney_m_Page_092.txt
e3372de0562bd3aa5041a9a67130484c
7dbb04e2ced15913ba83ee45411692316889df9a
7139 F20101220_AACSCD mckenney_m_Page_013thm.jpg
9df6ea2b3bff80788cc1e6658d0fcc7c
d59a152eafc44e5175debbfea235db317e276da5
7260 F20101220_AACTFF mckenney_m_Page_058thm.jpg
2721202912d7db9a0a6a09cc86a2b51e
421e04761dd3cee2601ef3dbf2e32acc87d72820
8668 F20101220_AACSBP mckenney_m_Page_034.jpg
4478aefcef5c1c46c9bb12bd9a7fb95d
aed604d5eaebfa53ef5274c140a4c792254b3f75
6220 F20101220_AACTES mckenney_m_Page_046thm.jpg
c8a31e8ec942cf200fd57491e1fcd67b
8a3bbc4fd70692dc52bdea1e8b0c8e1e0a02e321
2252 F20101220_AACSYX mckenney_m_Page_093.txt
57ac4578ae8d8fc2514a1719501b1282
fd141e8555e6e1d9c138370b6b86668f11976532
2705 F20101220_AACSCE mckenney_m_Page_124.txt
b3ebe10849e45104667b29701b7be7bb
0e60075f0d96445746fc373ad55bd648e673bc42
7110 F20101220_AACTFG mckenney_m_Page_059thm.jpg
79351361516d564c34c3e57f3c277de8
34789188d4b66b9a3397eed0094970e604b5bcbc
2445 F20101220_AACSBQ mckenney_m_Page_126thm.jpg
e68d3c287abf4fe58d2f05136873f26f
132a47ce28dc33d8cd0794582fa472674c76b3b6
15950 F20101220_AACTET mckenney_m_Page_047.QC.jpg
a868f2830bb8a153c4033f85f326f9d9
64b4bef289a6f00373cecb2e0e3a28c4eafdf5ce
2251 F20101220_AACSZM mckenney_m_Page_108.txt
d1326b742bdc4406f230a4c42f3bb804
17656bce46bbd4e6c0194cbe6e0ea26b861fddc7
F20101220_AACSYY mckenney_m_Page_094.txt
e91a74a23290af3351678d45c5eb394a
174122bfd2fa7bda5006f7b4b348a66ad95b7d27
26777 F20101220_AACSCF mckenney_m_Page_095.QC.jpg
c333e7e5eef4f0e88fb5b6c58a6f1f5e
332b655969387a6e95c4ddb033e77b34f35d5f3f
32728 F20101220_AACTFH mckenney_m_Page_060.QC.jpg
617100a9e4bfd2ce01dcd723bd1d1f99
aef6333df2b095fecc62cb442d0972f061ded653
49829 F20101220_AACSBR mckenney_m_Page_013.pro
91330666cb164770f59fd915082cb37c
56841e38362d4ad698161cf0a9f674320ba58687
10502 F20101220_AACTEU mckenney_m_Page_048thm.jpg
667241a91395751a3c2cf95aa58a2eb8
d2b4f182ecd2e6c2ff7c79554448f2785784095c
2263 F20101220_AACSZN mckenney_m_Page_109.txt
fbb81d471382967e8cc07d12787f1eec
65793324dbebd42a7f6ffe017d6851757cb2c307
1864 F20101220_AACSYZ mckenney_m_Page_095.txt
03b84ee13699feee265cfa3006911251
26e83c768bd114a42bd8ed8a8f46d522a2c4e08b
7392 F20101220_AACSCG mckenney_m_Page_052thm.jpg
eb4d05d4e01500e513c922c655243658
c90623dfb65708f272e48ad30dbc53896e4abe44
7505 F20101220_AACTFI mckenney_m_Page_060thm.jpg
fec1aac96e4894edff50d9c364d2839b
68c42d0c96a41b48f0c9986a4f2bc4d103585c71
49962 F20101220_AACSBS mckenney_m_Page_026.pro
4ba6e286a86710c758c83ac362bd3205
59716bfb44f962e2efda099020ef39c5d7be5dbd
2436 F20101220_AACTEV mckenney_m_Page_049thm.jpg
6138b4dcdaae39a4c60b7d7ee0792713
c35712df4e2ebb707da43b89b750d3f4efa719ac
F20101220_AACSZO mckenney_m_Page_110.txt
97486c99bfb161ea7b2ba66abcd59034
e8e15d21b459e6a09b3fadfb258ef8cadcad0ce4
2059 F20101220_AACSCH mckenney_m_Page_053.txt
a042a9e1a4976f4dab9c20368922e093
61d72e9df2303522123ed7620fcd6407e3a5c908
31174 F20101220_AACTFJ mckenney_m_Page_061.QC.jpg
f5903d6f38331339b0ed892896524bcb
2dd99ce878c8b914cc0c2a21b4a537d16038a640
1051949 F20101220_AACSBT mckenney_m_Page_042.jp2
6b180a84fb1aeb83adb201aa7210681f
2609ed8840b7afe1e90d5a168561c5a43abfb480
32636 F20101220_AACTFK mckenney_m_Page_062.QC.jpg
aa6b86075384a70325dd756977b4383b
71c0c74ac254148e09e5db2462709209183f572b
2257 F20101220_AACSZP mckenney_m_Page_111.txt
64a49518261edc1f384fc5a882ba6b06
e5fae7955bef3af4240f40f31dd048fcdff31397
F20101220_AACSCI mckenney_m_Page_051.txt
4143b847863c7ed9fecc2cb363e9a4b1
df5efdf9b3dda3eb0cf6a837831ccb98ff1a0017
31070 F20101220_AACTFL mckenney_m_Page_063.QC.jpg
a6ae41c97922c6a648b71e8d9c9da603
d409f066db2ab6b4ad157f89377354e1b72009fd
34122 F20101220_AACTEW mckenney_m_Page_050.QC.jpg
db1fe2b53256b5749812a046beaa8faf
74cab674c023f6722ee1de4560b9b820cd7d7b25
2325 F20101220_AACSZQ mckenney_m_Page_112.txt
b57f8b81f56bdc91cf78984744e18b03
1320f3dd5777a60dc6762a3da064780979e980ab
67527 F20101220_AACSCJ mckenney_m_Page_124.pro
f703a433c8781a19a3ee5b168c2fbf47
c6d842b88c51d3f05b163945d09c36a2e607a357
2200 F20101220_AACSBU mckenney_m_Page_052.txt
022b2bee4892a1f450693cd16900fee4
a255326130e1beea5fcad346f5b1b79b44cfecaa
33533 F20101220_AACTGA mckenney_m_Page_072.QC.jpg
7d52023f0a00fb35fb59fd281b92c52f
6d6b2ca25011523536b90254ad2ae98ba104b0c1
7248 F20101220_AACTFM mckenney_m_Page_063thm.jpg
92540e9e66b1042f8a9170b869fa10e0
c01a6f7c8c79bd5ed352781f87998b701047e556
33914 F20101220_AACTEX mckenney_m_Page_051.QC.jpg
85e1adf15fd182d085481797598230a8
6063355acce8b52604a447b3c7a9547efb60ba9c
1472 F20101220_AACSZR mckenney_m_Page_113.txt
ee5df2572da8c012b2ea7e772826a6fa
0c6d738268433530b44fd0fe7a2c8b7b2ee8051f
6815 F20101220_AACSCK mckenney_m_Page_088thm.jpg
7533b59670d73d6c03caffaf29ab1d87
9b87d7fd8e524d903fe9a9147220a744e445af15
F20101220_AACSBV mckenney_m_Page_061thm.jpg
c8e2be2d099b6f2c349e4085ccc99a28
10f93146f5a7641eed3cea4deb5507e63e7f8659
7762 F20101220_AACTGB mckenney_m_Page_072thm.jpg
21698c3c2faa0dd99eb93d1fa935c257
c7f61209bf24ca0a3eb21e7c4c086e8f90485591
7773 F20101220_AACTFN mckenney_m_Page_064thm.jpg
6fabeef5507dda9b2ab0dfc5f62d0d9d
0d95e248e06038710a8f8ab050b3f58abca918c8
33520 F20101220_AACTEY mckenney_m_Page_052.QC.jpg
9ef099bba4d38e13a8a3d2412ed0c791
3618fd8fd4608412b8c7b250c8beb76fe9a78572
1685 F20101220_AACSZS mckenney_m_Page_114.txt
c24f93d75fbe3e9e9192aa3218778a64
601990171e9f1c84d4b92787ba7e01e56b214d5e
F20101220_AACSCL mckenney_m_Page_104thm.jpg
7707e8367a2cbe537a47dd695e67fcbc
5d92b5723dbbc6e4f7deb277ceaafecc1e69168a
35420 F20101220_AACSBW mckenney_m_Page_012.QC.jpg
9e90652de5a3bbad030ccfcd5d4a6ebe
d7c582f28f3b8982226569cd81a8cc84cbcd8769
25872 F20101220_AACTGC mckenney_m_Page_073.QC.jpg
26c2c3191585c8be84e5a38a4a7013b8
80a77144dbdb1c8898a731e31d20d915e70b3981
33540 F20101220_AACTFO mckenney_m_Page_065.QC.jpg
94e4c22d4c6003a504a029962ee56f54
fa0b314116e9ed5ba72227a46122f580c08b0d26
791 F20101220_AACSZT mckenney_m_Page_115.txt
62708150e4e0db1abee42d2cd312ce48
b98ff4abacfec3317aa2341a5bbf41e5d45a9970
F20101220_AACSCM mckenney_m_Page_117.tif
c0f41c96d17b125c4d6de37afe20e77f
64702d47d0e466f257fec1406fadd4cc64485f49
F20101220_AACSBX mckenney_m_Page_038.jp2
4353d9cb8c8bdfcdeb31b749d745fae2
08585b5814b77e0ffed6d01b6e4d2f5d0ef8ba35
7588 F20101220_AACTEZ mckenney_m_Page_053thm.jpg
5c0ce8e05d0ef6d9b3c6893e9cdff74e
5192215735378cc30c2c083bffc2c82103a12aca
6082 F20101220_AACTGD mckenney_m_Page_073thm.jpg
0347e550fa63f072d1aecd0a84db124a
32980e7c9597db83c6e241a83849120a832e8c8d
7574 F20101220_AACTFP mckenney_m_Page_065thm.jpg
7a69ed1a8ed25b8f43f2bc08e97a8a7e
f58422f79f6d3d5caf4db81031b208b655c61d46
2187 F20101220_AACSZU mckenney_m_Page_116.txt
6e52584b00fb561c5650d0329b6edecd
cb5c437f701faca88644515dfe37a84227d12473
2007 F20101220_AACSCN mckenney_m_Page_080.txt
2fb77a0d8c26cc6a7b0499c54b6980b2
71a86ee356c1fb3c81255a34576a855f2825e216
126604 F20101220_AACSBY mckenney_m_Page_124.jpg
a747dfd52526d58d764536004feb579b
4dc931ffa0c801358e9c81d191c6e0dbd560d8e2
7370 F20101220_AACTGE mckenney_m_Page_074thm.jpg
d22cc50a0b6ca8dd1adceed7d7ca0c09
cfcec713c6d63c2e4c9d0cb59a34c75b23007a99
24949 F20101220_AACTFQ mckenney_m_Page_066.QC.jpg
2d62f6d9a5fa73a9d083075b224babde
4e0fa8abe37f96ef53bd81544c7671c5912ade6a
2391 F20101220_AACSZV mckenney_m_Page_117.txt
68b040265dad520596a3099a6a5af6d3
3e664132bf279fa602e9e0cc4ce9f63f9d934c17
31391 F20101220_AACSDC mckenney_m_Page_001.jpg
ec887c03643b5d9c7b5abc48029b2b5f
d0c5844672e7daa5ea6b1d283918f09578204ac3
2491 F20101220_AACSCO mckenney_m_Page_079.txt
fb3b31dc7e6aac9f0e7a2f82b47e61ab
5c3c0260743fa088abb60d9a0548c1f1040f5f06
31753 F20101220_AACSBZ mckenney_m_Page_004.pro
9078e4229a6181ff957fb95473f86c62
0eec9ec6b45e56718ea4994f841c72a2a82284f9
26580 F20101220_AACTGF mckenney_m_Page_075.QC.jpg
2966fefa02e398ef2b3136f4680a2df2
551fbb8b25af45d7858b88f31389d295d8418568
5894 F20101220_AACTFR mckenney_m_Page_066thm.jpg
c1d97641990e1c8b5ff1ef8d25228acc
5c5748dec345b534424bfa9cf8e76f9c80bcb280
1503 F20101220_AACSZW mckenney_m_Page_118.txt
08456a936bc0cf9673855e6ae7167e1a
bc007fb65b9ea6f3cfc7cb0b7289a5e82a6c3cef
5049 F20101220_AACSDD mckenney_m_Page_002.jpg
a2ba50a2595ba04a3b5182421d48c14a
bc59b30a19510a91d5e0ac34a58d6afc6882ae77
72701 F20101220_AACSCP mckenney_m_Page_118.jpg
e111744d4af6d20062ad051c9530d295
f91c025c715dffb979707300d40b81244d20acb4
6842 F20101220_AACTGG mckenney_m_Page_075thm.jpg
49df6a0c758e7b51e415bd344af004a0
2b6659e0f4b49662236e897f10e97ae68ea37564
33049 F20101220_AACTFS mckenney_m_Page_067.QC.jpg
ef71f8281dac6b16d7d1d99e9f19949e
4bdaf3ad58722dc92a3b3e8c2990e1cab23a823c
2420 F20101220_AACSZX mckenney_m_Page_119.txt
a61010d40b00e2d3538806eb32c458ec
36124fa733522841e45c9a27c7ac97ca41cd38d8
12498 F20101220_AACSDE mckenney_m_Page_003.jpg
fda3fd51dac16541044dfd17776367fd
478e02cb8ff1f854198ee03d9cb5749a1ec720df
113154 F20101220_AACSCQ mckenney_m_Page_012.jpg
4e3c2ff1751cd0de3711afac346f2166
f1fc37acf002dd7fe848fdd6bad6ec29cb9f6676
34686 F20101220_AACTGH mckenney_m_Page_076.QC.jpg
853bca5fdba47928df8872d51b5438bb
bffd0fc441ef40dc85e5af4e92f1e1169adb23ad
33673 F20101220_AACTFT mckenney_m_Page_068.QC.jpg
723aa51d1b60226c031a62da62c77765
69dee29e17c611313721b7940efd26eeb9658657
2678 F20101220_AACSZY mckenney_m_Page_120.txt
07553449c6cee913516e3b84a7996e73
8778e437308b7ca149d7f1bcc6d36fc025d44318
104192 F20101220_AACSDF mckenney_m_Page_004.jpg
9e3282ea7b43f5146338a12cd171cfbc
8bec77cfb12060da76bbb3fc5d6185402297d53c
112156 F20101220_AACSCR mckenney_m_Page_016.jpg
50a2e6efd398d15379cd3d04a2794a9f
c069f0dfa2f081f70e157cba5922bfd42238d031
36070 F20101220_AACTGI mckenney_m_Page_077.QC.jpg
54ca49a9e4edd7645f6de3fa9c0f807a
af99c4ad40c8b731529dbdd8e561fe2a889d9c37
37250 F20101220_AACTFU mckenney_m_Page_069.QC.jpg
5cde4f43e7c6bd74302add91d5aadd78
c85dcd0ae444d4afbc549d9e1760f937807db9b1
2661 F20101220_AACSZZ mckenney_m_Page_121.txt
19b15250ecca7645456545c348def8c7
c5fbbd23c8a22d6e035582a34b6309f3db86a06a
86766 F20101220_AACSDG mckenney_m_Page_005.jpg
90809c2ba43514da33a4220ef2f12435
b1527d50ccedc1514c70f161c5f4bbdc55c6f4a3
2456 F20101220_AACSCS mckenney_m_Page_029.txt
a92b42241e6c563baead01ea6be4a455
434be946d47690233596901ab27e0df799c60289
8125 F20101220_AACTGJ mckenney_m_Page_077thm.jpg
9d0a92f68642f1493215720629d1b352
f475f7616bdb84ca2828c2124729a8ec9276e669
8299 F20101220_AACTFV mckenney_m_Page_069thm.jpg
025e14aece0e8693f9476141b67584d1
9265f94bdcb2eeb517384bc94a51f1e028c8ed48
48883 F20101220_AACSDH mckenney_m_Page_006.jpg
ae1d11b66c0119c35f211ef184d42ab5
4f284a534bb7549dee1f596a39bd4b8f9772f9f4
83932 F20101220_AACSCT mckenney_m_Page_088.jpg
1a17fd68ef742e481c93d1e15ceca73d
3ac68631a1c178c1a748bd4b85b1210d2a1ec96c
31063 F20101220_AACTGK mckenney_m_Page_078.QC.jpg
b98ec5642370de7d019c3ab1a2557d88
0fed01bd4fdac89f36764db4a77cdad85c6e1373
29470 F20101220_AACTFW mckenney_m_Page_070.QC.jpg
5ec1e577ccfc22f014b2ac20c7d76073
a3b9d6121874ca8b7c5501259244479b1fda08e1
140897 F20101220_AACSDI mckenney_m_Page_007.jpg
28f90ed80a2b3fffb8555885976fcf4f
3884982f9b5c886634dffae31f56fe39b75c4b94
31882 F20101220_AACSCU mckenney_m_Page_064.QC.jpg
a942441b72d74db9bca3214f8ccd48cc
ba31f8f978a6b175c372fc06d448a4466768f2bd
7320 F20101220_AACTGL mckenney_m_Page_078thm.jpg
7e2337401297ae21197e6bc640d2fb15
6c752a29483bd2c3cccdebdd705d3782c256c4a2
107507 F20101220_AACSDJ mckenney_m_Page_008.jpg
f8a90b8f1dcb3fa0e6bd90706fb93828
1da3412073cdb407d83b590a3b94de1af55c26fc
8139 F20101220_AACTHA mckenney_m_Page_089thm.jpg
6dd58b82dfdbf334b00194405d391f57
81cad82ea1d28a75ac2ffb7964c09e5598e311ef
8162 F20101220_AACTGM mckenney_m_Page_079thm.jpg
504a9dd9b073e8de8a26cc468685057f
8a77bd863587d891a6fc1f5c2314ebe66fb11c95
7372 F20101220_AACTFX mckenney_m_Page_070thm.jpg
605e025c97e8be5b9d8f3466449508e7
f65753fd4f0275c4df3c9b18d5aa8852d14776dc
102578 F20101220_AACSDK mckenney_m_Page_009.jpg
5f428c10fb9e8db81fb6d01ba5ec663e
f17c1d49345f6c1e4ee0a7e31c09579652256b7a
54853 F20101220_AACSCV mckenney_m_Page_022.pro
757de7cef227dcf75187ec48eebbc007
b461889788ffb4a5681a865597cfd678ee390abb
29502 F20101220_AACTHB mckenney_m_Page_090.QC.jpg
54ff4a3d06f6673aeeb853a2eb5bff15
ca983b1f088a9aaa9253ac9569a3108c9d5d502e
28255 F20101220_AACTGN mckenney_m_Page_080.QC.jpg
815598d6c85b3f158834ff60e44b5161
f5da3b36384dc00f0c1e429e14d36f7188b329ff
35830 F20101220_AACTFY mckenney_m_Page_071.QC.jpg
12de0a9f17b04e20a9e722883a1a9491
2ba5e832a00093844e01a7709340254de079cda7
11525 F20101220_AACSDL mckenney_m_Page_010.jpg
a6b56397254c5fac274698de8cdc2f96
a000d1aaaea6ea1e8562b335983a737160d399a6
1051894 F20101220_AACSCW mckenney_m_Page_048.jp2
6300042de41a464aed298fe07c9e5ed0
7e156f5ac210f5c2322202dc88c40bf895cf0fa9
7410 F20101220_AACTHC mckenney_m_Page_090thm.jpg
d5cadeb30d6f14528748cda06f7745b3
064e27f2ada90df123b8a5bcd4b5fcea47607dbb
6917 F20101220_AACTGO mckenney_m_Page_080thm.jpg
f74248d2b0415e622d14d7b790a99a88
ebc5743835e381bfe72fc37f08342f6abe721d77
7906 F20101220_AACTFZ mckenney_m_Page_071thm.jpg
6036d863d59e0cfe7cc593a251e4cb6c
1d7d597d50366a435464b688ca484770a6c8f898
105701 F20101220_AACSDM mckenney_m_Page_011.jpg
0bc7474cbf4c6211c024b503a0ee9670
e1cee4106b9660da57d8a9ee45ca4ebf3aa69a28
30127 F20101220_AACSCX mckenney_m_Page_053.QC.jpg
d2acc7b1ed87f6a1bdf3e1cfff3e6e12
7599ab5326332b30d067adc6da3cf39b74ae03d6
112959 F20101220_AACSEA mckenney_m_Page_028.jpg
e369bd4ab2f6bc20e9b2982ba1bfe73f
b0cd875a1f72ec923d68f2a7904aa2e97b507cb2
33394 F20101220_AACTHD mckenney_m_Page_091.QC.jpg
c04eca8f639f0dd29a8f7f2086cac824
e761cb791f56be72cb6a5a3b13f5a67141b2aee0
14218 F20101220_AACTGP mckenney_m_Page_081.QC.jpg
3093c0389b43a815ce2400b8d13f683f
ab905a50d3b11a7a927cbed3040ca60fddd64e54
95869 F20101220_AACSDN mckenney_m_Page_013.jpg
21e9a1512b43e55084baf283ec6d4a61
6539b29d80519e31ac98fa5fd2bb0fed59820e40
2417 F20101220_AACSCY mckenney_m_Page_027.txt
25349c74c2dcd3bd35c84408b4431d62
258dd52938752a3cfc83195ffd7cc77eed8041f7
115905 F20101220_AACSEB mckenney_m_Page_029.jpg
413ce635b893fa6821f84d30e259ad49
57166e818242c62fac2812fe0186050b8ac6bcbf
29188 F20101220_AACTHE mckenney_m_Page_092.QC.jpg
7dc410207d4a8a6969e330028046d905
32468bf58d2e3cee3554640df40506db969c5dcf
3481 F20101220_AACTGQ mckenney_m_Page_081thm.jpg
635caefa92a0d5c6de1d37781a597bb4
50e1cf94a18c63ca283a410be94187db2822fb85
111522 F20101220_AACSDO mckenney_m_Page_014.jpg
271a3943f2c273e7f1d414301f0d60d4
7d58cce169f874e4ea78d6ca78ec387221b88a4f
147625 F20101220_AACSCZ UFE0022567_00001.mets
ff108d5177f9f63502525086c9333238
d4b1a474619bf7883463f616d5720f11264e0cba
111259 F20101220_AACSEC mckenney_m_Page_030.jpg
4a20bb145e0ac52630d087dcce2a17eb
75228452813ea2fd6417b549d687ae5b299c7e65
F20101220_AACTHF mckenney_m_Page_092thm.jpg
a6103481bd0d5ad5800a49586647c17f
8e5bb6fba894873ab4acfa63b90adbd3d4a5736d
7343 F20101220_AACTGR mckenney_m_Page_082thm.jpg
c201ff9c2285ebd809efbbd122447d46
fb0b15236531e9be0a0c661cd10dfe2ed251197e
110645 F20101220_AACSDP mckenney_m_Page_017.jpg
70e27c0b78bd639fc5b0cc29f743980c
027060812473c4bcf4c53e5d57df2d6552f6233b
110966 F20101220_AACSED mckenney_m_Page_031.jpg
722565e5e7d1f9639b2a18035b079686
515e4d7757683eac5eaada68a8386997b9c76589
31509 F20101220_AACTHG mckenney_m_Page_093.QC.jpg
f9043ff05b719ccc1b8364c4928895a4
68825c32c4711978f20dc66f6bed1fcd5f3d75cd
31740 F20101220_AACTGS mckenney_m_Page_083.QC.jpg
d78073a7bd805d8311155f45c8ccd8ca
a09cddd91165e5706587840234e862e5a35636aa
90272 F20101220_AACSDQ mckenney_m_Page_018.jpg
3d4b48b814feaecd5f8c518c427847b5
565d7a82f94b3c755583b56c46a27563b22a08b3
109191 F20101220_AACSEE mckenney_m_Page_033.jpg
5093a2d06b7c61757d3382dcbb61b9da
a6da1fa54369ec0d023a1df14988e67a15fae5b7
7595 F20101220_AACTHH mckenney_m_Page_093thm.jpg
1c25315cca6ed5a4e675ceb4df7b37f4
9da2ff71d56f87dc3bb82c079ae545d3a1c9419b
7209 F20101220_AACTGT mckenney_m_Page_083thm.jpg
22f2126e3f17cccd9e9cbd91e692a1a3
e3da7792320315d64ea6dd6e54b7e1faf11b9b55
107417 F20101220_AACSDR mckenney_m_Page_019.jpg
7093aecfe72c448b6ba63cd743aecadc
a45b91d4fc15a0a89f9ffcb95762370530621c65
106616 F20101220_AACSEF mckenney_m_Page_035.jpg
d6014643f8d9950631689b0999ecb27b
61b9ed289b71c0b395009195ad9c2ceaa013a44a
34890 F20101220_AACTHI mckenney_m_Page_094.QC.jpg
bb46938b2d342ebacc9d1be01e8992b9
0a031cdfa9cd3de0e6206a06a794ddfe3b6fce2b
31083 F20101220_AACTGU mckenney_m_Page_085.QC.jpg
bdafa233d50bb3b0b3350aa9f3fc7040
98f5381a0f21fb3acef1a60d3fb5a4b65d2a88ae
47633 F20101220_AACSDS mckenney_m_Page_020.jpg
d42b3c7c07c1c0e64aa70924764984aa
8a8530f3b1879df64eee2594161a5c9fe64fcfa3
33856 F20101220_AACSEG mckenney_m_Page_036.jpg
99bbb674fde0dfacb3e93f94ceee7771
8d31c84bc8990a0db82e443bbe1cf103f01c3720
6587 F20101220_AACTHJ mckenney_m_Page_095thm.jpg
939033ac055ee6fbe840d4dafaf894a7
c930b688a18ce237a12d436efa6b5718c9743c44
30949 F20101220_AACTGV mckenney_m_Page_086.QC.jpg
4c681062578414ad3e6d75e0a3a4373e
11fc5d0667539c874aa4ecb677a042f5d2e20709
93284 F20101220_AACSDT mckenney_m_Page_021.jpg
b9a91f6486e01e2706e8f40cd10f694a
9321cbd88e21a59ab1cb52d17e65e6b09b3efd88
106657 F20101220_AACSEH mckenney_m_Page_037.jpg
7ee40bd727d2c9a6534f9856612a22e7
234755ed914582cb6b3b7f811bb57e96548d0ab4
32568 F20101220_AACTHK mckenney_m_Page_096.QC.jpg
b1663af8d595ea7c5fcddec66d703799
09416c57c40040d2fd644bd39f0950d284f92adc
29427 F20101220_AACTGW mckenney_m_Page_087.QC.jpg
c85050f5cc4370aa906bcd24f3025f11
01e1ec205451a23e6aa15fdbd0e1ac2ba096e202
102571 F20101220_AACSDU mckenney_m_Page_022.jpg
ed97072d1cb210bd98bf78415642bcbe
d07a50c846386f4cf6da6a4955a248af479f4d7c
108506 F20101220_AACSEI mckenney_m_Page_038.jpg
ad5ca897cf94ea5edd89f1b3e0958f09
25c2b60232730f34fed57226fbdbcb76f8e66245
7635 F20101220_AACTHL mckenney_m_Page_096thm.jpg
3d4431a7510a23e3db93a932be26fd71
9153981e97adb9cf14c8ff9fdac76f1b4c3ba60d
7739 F20101220_AACTGX mckenney_m_Page_087thm.jpg
ebd3e8f9cb37dc09000bfccc6408e5fd
cc69d01ea512f365e7f67deb4909bbc075a961ef
104848 F20101220_AACSDV mckenney_m_Page_023.jpg
84be9965129def83dd986bbda54f60fc
6dbb8719f16df79109425aed648d830c437e970a
100042 F20101220_AACSEJ mckenney_m_Page_039.jpg
41cff81faca079e89e744d4c829939b1
681e40410d566fdab7688d72446b889d8763d038
6887 F20101220_AACTIA mckenney_m_Page_105thm.jpg
34971313a73b4f219767ecc322b57eff
ed702acde5997cc07023f48fa3cc951b7b8686ce
34569 F20101220_AACTHM mckenney_m_Page_097.QC.jpg
b7bc2b6b36d4a0a16ea47e1a2e18d229
0bd67e25d9d2b927e625bba9c6e0bcfe797dad03
99241 F20101220_AACSEK mckenney_m_Page_040.jpg
a8bfc39f7b9db24fdaf29fd0a59b7c5b
b8d8bc2eaf3b131f0803a1194d3307cf258f3add
27718 F20101220_AACTIB mckenney_m_Page_106.QC.jpg
438bf4e5b6ef82cb43ed5c5eec05d386
450e4a81216a75fefd1ba64ecec1f70d4c4c8337
8120 F20101220_AACTHN mckenney_m_Page_097thm.jpg
618c118ff211a8941b31583836c19343
4551294c974ec78bba2352c0a9370a5e222a1307
26273 F20101220_AACTGY mckenney_m_Page_088.QC.jpg
864582b7658397b26aba16c36b4814aa
d9124c6627509385d65869f1ac6dbd37cb402f46
102582 F20101220_AACSDW mckenney_m_Page_024.jpg
e9b19b717feb3c0f024ba0d679e0f8c3
a45332ef8aaede075e612c007d775ad7722cab3c
78983 F20101220_AACSEL mckenney_m_Page_041.jpg
d3ab8dd404704fc91636e3332e1bf824
bce7721cc60cdb21fe5fa77092d193b7ede97e8c
7475 F20101220_AACTIC mckenney_m_Page_106thm.jpg
fabb3c410920ff0762c7d32bf91fe7b8
d31b525e0a56ac9a3ba43a9db5520f6b8fc33c90
F20101220_AACTHO mckenney_m_Page_098.QC.jpg
3f19516729461828ac2c7899da95b016
aa7ebabf11ab668fbbe1fc4c31d2358aa0fac0de
35205 F20101220_AACTGZ mckenney_m_Page_089.QC.jpg
c37762499e97f6b4dd1fd56ae9e813e0
18f722c46480615a15b389068422c907d482312d
114775 F20101220_AACSDX mckenney_m_Page_025.jpg
9c5c99d5f1a37df0b9d5e64d254fac04
0aead02c665b38bdae67d2b513826fb0eb18263e
91616 F20101220_AACSFA mckenney_m_Page_056.jpg
8dacfb86391da1895e6b3a0533b3b7f2
54defdc6657d9e56fd7b468821fa09da71cdd55d
94521 F20101220_AACSEM mckenney_m_Page_042.jpg
313ab2fee1a2ef16f633f28eb5c08d0a
00d3ba472e2780b43223d3bd7cf0dea5e884740c
F20101220_AACTID mckenney_m_Page_107thm.jpg
a57c7f219bcb4cc96432fad25f4aa18b
cf46cfd92e650d703915bd374b15645951685a82
8229 F20101220_AACTHP mckenney_m_Page_098thm.jpg
2759a03859c6e89a22f6551eb5dfa854
38a74364f7e048b051f6b0139409aa26c4c44750
97201 F20101220_AACSDY mckenney_m_Page_026.jpg
f172373adc80dd1204e4becc7635b4ea
1f9a4fc4b25f219ceedbf599f2d4bdb69ed7d3eb
92386 F20101220_AACSFB mckenney_m_Page_057.jpg
fe5b86ab83831cc936d0638f1fba2731
66a1d8cd473afc7ca972922b891f000e83918c65
100129 F20101220_AACSEN mckenney_m_Page_043.jpg
5eb17ba7dc04f48bc13a63910910ab49
9bcf288163066afb85361afb7213f4348919bb4e
7898 F20101220_AACTIE mckenney_m_Page_108thm.jpg
79f689448c1c87fab681f86c0e8a998b
21fbab0748edef77a833e18f8d32b7275624a71d
27936 F20101220_AACTHQ mckenney_m_Page_099.QC.jpg
a80bd6de0d3d67cfd429687ba8225c3b
7bbdd2cb95eaf02b4415f36195c444fe918b8c13
114359 F20101220_AACSDZ mckenney_m_Page_027.jpg
e10864658cb526d8b6e7bd31654c6de2
e913b8cd7e1174b7383e0f933471aba1ec0d6fcf
95898 F20101220_AACSFC mckenney_m_Page_058.jpg
cce3a6707a13413135c4c4639d2e700f
cb941dc2831f66d2c7b01594340040b4d96cacfa
96799 F20101220_AACSEO mckenney_m_Page_044.jpg
7453d88ecd7c9893b7ec90ad0af56645
d1f92ae639cfd44efd0184244e5171bd90c92031
33426 F20101220_AACTIF mckenney_m_Page_109.QC.jpg
ad134b1b0db6d525f400a09a794c211b
27999c3673627b4da5a9d219873ca527f1442bd6
35967 F20101220_AACTHR mckenney_m_Page_100.QC.jpg
24f686242555172e722d11e7458f9806
2cf2e112edd108fc3572db17b540277b6ff2784e
96422 F20101220_AACSFD mckenney_m_Page_059.jpg
f1961e3135c1de0304e3bc2629299b1b
f4a3f8ace7e2f5849491bed5fbb0d0d3b46e1a2a
91012 F20101220_AACSEP mckenney_m_Page_045.jpg
da8c6c0b698f6b7d8f260aa9314b896f
52701135d9b5d3a9e732797988883fe83ea4349a
36585 F20101220_AACTIG mckenney_m_Page_110.QC.jpg
cea39db16952b4a282c3884552fc2d70
d98a20f74d4808c711593b6777466f3a774b9de9
8096 F20101220_AACTHS mckenney_m_Page_100thm.jpg
af3954f51d10d8b8460d0a1e8ee888e8
9455ae2010ef0d02c2e50a8610f57b3736257ced
106190 F20101220_AACSFE mckenney_m_Page_060.jpg
cf6662d4030a65e2ac93271a6074aa20
8c38c2790008be3230bf1df3e3915b5098434131
77375 F20101220_AACSEQ mckenney_m_Page_046.jpg
c8cf1139eb920b60196342232a7ad05b
5ab6d5984e0eb22a9034595ba6bfcb74789e3968
9251 F20101220_AACTIH mckenney_m_Page_110thm.jpg
ebe8377843b5c039b52ae1d1d573bdfb
4c92d17764a11a7a2b9ba2f0108cd2f317a0b89e
33837 F20101220_AACTHT mckenney_m_Page_101.QC.jpg
bc81436077b8c4fceafc6e59e7da1fda
ee7a17c7f54209dfe256980d7a9fbcc728acadca
98163 F20101220_AACSFF mckenney_m_Page_061.jpg
da57ec04fa55306c28a316b22790e36c
4e5e927fb5cf5dc29511411c03f78ba6aaa2b0b6
48852 F20101220_AACSER mckenney_m_Page_047.jpg
f639db556b40f4add9145a9dff8d11f3
3dbd3a2544e0398ffaa84123747e40d5d2ac3060
34090 F20101220_AACTII mckenney_m_Page_111.QC.jpg
f81c4ac6e786053b226bba5945d8b485
6088208981340943a6ce62b950d5eacd420675d3
7990 F20101220_AACTHU mckenney_m_Page_101thm.jpg
cd86c171228ecad2da1909f483764e58
40a1017a6c3296e09b5e3e84c80870a386dec1cd
104688 F20101220_AACSFG mckenney_m_Page_062.jpg
a08806e6d381c4061ef26bb5e934f0ea
04d81a94b1d073852fc5bd1328095a1771e6de6a
125123 F20101220_AACSES mckenney_m_Page_048.jpg
26c6c59c1f888106ca768d2c8e908067
cf45354025cecb87624941521e60ca9384f8e96b
7763 F20101220_AACTIJ mckenney_m_Page_111thm.jpg
e22c68e0b7567fb54f8b66f3244d82b6
0f213478ca2b1a623e3e57938046c641a7c26d7f
35941 F20101220_AACTHV mckenney_m_Page_102.QC.jpg
5f444b184cdc538c1d3037b4a14230be
efd68ae6b34861475fbfb1069073deea2e4b98ff
97054 F20101220_AACSFH mckenney_m_Page_063.jpg
b3ef37a7674d4356034eb633b6216617
14ebddd7c0943e5939b34583cfbd42bb313accd6
27774 F20101220_AACSET mckenney_m_Page_049.jpg
e118d673bada3beaaaf63f287423b123
d3e43ed896b013472e14e399c7f331b0c6085655
34942 F20101220_AACTIK mckenney_m_Page_112.QC.jpg
9f5f9e86283481aafaae074440691262
5796ef62b81b5a3d538827b2149fbc0ad4260267
8078 F20101220_AACTHW mckenney_m_Page_102thm.jpg
129719979514ac93af80231ec817f31e
2b6c3c97fc9d7d6ec3c9ba0e5a2db47c6b1e7a2b
104467 F20101220_AACSFI mckenney_m_Page_064.jpg
9abc082d4572d05205afb1eabf40e2ff
4484e670f2984b740c90998edc293de9bccf211a
109996 F20101220_AACSEU mckenney_m_Page_050.jpg
fd78b31848c61d3946c15724f94f132a
541d5bfbbbe71ebd986f0c15ed05b41e3ba2719e
7799 F20101220_AACTIL mckenney_m_Page_112thm.jpg
b2813859228d0c061f2649f5ca681f29
a2087102e17f71fb3b712a35c47c0a9b03419860
34142 F20101220_AACTHX mckenney_m_Page_103.QC.jpg
8e783bbaa20ac3d0e25cadd03d74c049
bda0c691aef21e9933d1d0f046a9828ab6e4a26d
108908 F20101220_AACSFJ mckenney_m_Page_065.jpg
353b29e824132579f308e8dda9a9003e
9c0835a7e7c230f7bf9405febb401fa1a57f5d0a
111355 F20101220_AACSEV mckenney_m_Page_051.jpg
786a2250031cc35ccf75c8d5a4a1dda4
ac9e35345c568b418ed435b13e7246ed6340006d
35336 F20101220_AACTJA mckenney_m_Page_122.QC.jpg
ef796c807dfb10429631954b139190d7
5f15afd1ff960308c49389d93eb2c352e883fe96
24388 F20101220_AACTIM mckenney_m_Page_113.QC.jpg
b8c503319612910450204a57ecb6757f
6e8a68c01d736d04e3e6e6274031da4992f491e1
7892 F20101220_AACTHY mckenney_m_Page_103thm.jpg
3d34cd94f5eaf0c77f103d9aedc8a4fe
baab0a5538411c686a2a32dd5c572c2bf2dfd93b
81149 F20101220_AACSFK mckenney_m_Page_066.jpg
c8d205b770b6c23660888621cf6f6c00
380c86cd3735bd50b1871e961c351fafa98c36af
106441 F20101220_AACSEW mckenney_m_Page_052.jpg
15af7ac4d9dac04bb9d779e92e267195
0d5ccf6f72793008ad78316c0bfe66529db1b719
8166 F20101220_AACTJB mckenney_m_Page_122thm.jpg
983ed9809fa329c7c2371022de514455
8d40639dc6de4070192708533055b53c3ca5cdd3
25233 F20101220_AACTIN mckenney_m_Page_114.QC.jpg
28a7905ba537569a13f359db92d2e6a5
041260b4fc7ef068babc8ef5eeea97456693239c
104971 F20101220_AACSFL mckenney_m_Page_067.jpg
804d1225305083b88499e0f56afff204
f136f8b4884972d6ab404ae4c2b9c48c01d45973
34749 F20101220_AACTJC mckenney_m_Page_123.QC.jpg
80f558af2ae6cbc87a8efc26e5e5f527
09a5c59cf47fac78b9cce51b00c24f061ba24d49
6966 F20101220_AACTIO mckenney_m_Page_114thm.jpg
fb0ef837823d60419d35cb932725549b
09c3fcc9a34268b56c14a780c1202fe2a810cf64
27200 F20101220_AACTHZ mckenney_m_Page_105.QC.jpg
80f5b9754feeba026eb2efa98a9213bb
759dadfec0364b217a23df1f3a7398d97d28dce4
103288 F20101220_AACSGA mckenney_m_Page_082.jpg
26c3e2b1fdb80f7665c7781827bddad2
afc64b7fcca2a2c3e15296206cfc006bed7a1c5a
107899 F20101220_AACSFM mckenney_m_Page_068.jpg
a0d4b6861eef33a256c5b65e2c7899ec
fee096b7ca90cbb6a7d9b96d29d484a8293f0506
91913 F20101220_AACSEX mckenney_m_Page_053.jpg
d2b44a69479f91d36625773edbfeda33
9e8550693c043c90c180e94b466d0e6555caa4e3
8164 F20101220_AACTJD mckenney_m_Page_123thm.jpg
430723a53aa2681be98cb0df1906047a
3a87f5ef6a868c7bab604fa75edb71591ede2976
12892 F20101220_AACTIP mckenney_m_Page_115.QC.jpg
689e290b41bac0151723668eb7f74436
0f40d5426ae7579e77ed76aad374464ec235d3a4
101181 F20101220_AACSGB mckenney_m_Page_083.jpg
e2912ace0b5286027a807352795836fc
838e466db86787f5231387cc77107e36225cd8da
119410 F20101220_AACSFN mckenney_m_Page_069.jpg
7778eaccf8912adbdf6752ae21c08e25
17debc9679d9a91b0e9d7a68850cbb87ce77f635
88069 F20101220_AACSEY mckenney_m_Page_054.jpg
aa3963d05108d9e57daef33e93a36fa1
edfca32c737cc59f4b543aec4d2fc0283b74f9ac
34577 F20101220_AACTJE mckenney_m_Page_124.QC.jpg
7b20e33d022eac3825661387de371ceb
0e3fbf79ade12bc0fc8d9d5171d145de6e4fac02
2980 F20101220_AACTIQ mckenney_m_Page_115thm.jpg
4cfaa9f688168511673ac21669af157f
d45544824f7ee2db4cf92b0ea0ac65f62b08f6a6
102314 F20101220_AACSGC mckenney_m_Page_084.jpg
4b502d2c6ce2085b86dd2656afd63c49
aea84eb48990e23bba957f8f5d155f1a1106fdbc
94882 F20101220_AACSFO mckenney_m_Page_070.jpg
dbd9f50b355dbbd02796507024411813
c48baae5f0a8dec003e63405ed5bfb96ebb52288
72213 F20101220_AACSEZ mckenney_m_Page_055.jpg
62a35ac27ad4e9e3507c2efd120dd45a
f90ae80f56a0b34b1f98f2211d943d1ea6c92156
2482 F20101220_AACTJF mckenney_m_Page_125thm.jpg
159b83d5f7bcabf77e7e4b88cf544822
49bbc68e0a25174dc28f0fa299fa4ebdf09fbbaf
32362 F20101220_AACTIR mckenney_m_Page_116.QC.jpg
0dbc858d18a6c876dc284e1c35f50ead
ce00e77618baccfc7904edb85cff6c679f039cbb
99254 F20101220_AACSGD mckenney_m_Page_085.jpg
2e655398c7d8209631aaef40cd181938
b15e1b844dc625e4194173040825475eccc34083
114907 F20101220_AACSFP mckenney_m_Page_071.jpg
6c0e4ce040a7dfca52c0ad5783615edc
1e633c1c6137948be39150893a464e1dcbb90711
10069 F20101220_AACTJG mckenney_m_Page_126.QC.jpg
9ea40a61637c8e8b214d3db66b08b2e3
d01e64b43eb79606d59d729b4c43565c2f80a512
7218 F20101220_AACTIS mckenney_m_Page_116thm.jpg
ce0a2684b2ad18b539a47f0104d75453
e4e8d29da54ec2d5b5ae3355a297e35f9dbdda0b
95884 F20101220_AACSGE mckenney_m_Page_086.jpg
6b2480dd2b3a7a867605e21bd4041f88
b95101580dfa1d9e91d6977cbed5ec0f85925e78
109497 F20101220_AACSFQ mckenney_m_Page_072.jpg
c3ac5c6b6d201b2cead9ef0bbe166e94
d22ae6aba6d9b3633e99df392c8e0c1584294594
8042 F20101220_AACTIT mckenney_m_Page_117thm.jpg
d4dd5d2aef9d6c56409d4c665077136f
4dbb4e9f65172d69a026d917b97b9be94f6d3ade
93070 F20101220_AACSGF mckenney_m_Page_087.jpg
eab5ccd1a2b9ce5ded38857677f30c91
8ca64b1eed84293f9073fdc37468765cdd8e90ac
83081 F20101220_AACSFR mckenney_m_Page_073.jpg
7d6353b7c0bd5a0873be5db26a42f308
b5c0e49d32cbf136f792a316e74d3348315529a7
5511 F20101220_AACTIU mckenney_m_Page_118thm.jpg
f3c53c68d96dd7569fbd35bc940033e9
ac2d0953f7d7d4e0daa5e4b1689e0afd4eef79d2
113302 F20101220_AACSGG mckenney_m_Page_089.jpg
0a529cc1b7a6aa0edc6bc4b263944a8a
29efcff51299af0cdc8b63519745f7a96fb6e6fd
103195 F20101220_AACSFS mckenney_m_Page_074.jpg
9565d3f533cf6ef59cb8074a7ee051df
34981d48c7173e6171a66b3727ab5eefad1ded47







MAP ALGEBRA: A DATA MODEL AND IMPLEMENTATION
OF SPATIAL PARTITIONS FOR USE IN SPATIAL DATABASES
AND GEOGRAPHIC INFORMATION SYSTEMSir


















By
MARK( MCK(ENNEY


A DISSERTATION PRESENTED TO THE GRADUATE SCHOOL
OF THE UNIVERSITY OF FLORIDA IN PARTIAL FULFILLMENT
OF THE REQUIREMENTS FOR THE DEGREE OF
DOCTOR OF PHILOSOPHY

UNIVERSITY OF FLORIDA

2008

































(E 2008 Mark McE~enney









ACKNOWLEDGMENTS

I would like to acknowledge the members of my committee and thank them for the

support they have given me throughout my time at the University of Florida.










TABLE OF CONTENTS


pagfe


ACKNOWLEDGMENTS


LIST OF TABLES.


LIST OF FIGURES

ABSTRACT


CHAPTER


1 INTRODUCTION

1.1 Motivation.
1.2 Problem Statement.
1.3 Goals and Solutions .


2 RELATED WORK( .......... .......


2.1 Traditional Spatial Types
2.1.1 Spatial Data Models
2.1.2 Operations ....
2.1.3 Topologfical Relationships
2.2 Spatial Data Types for Maps
2.2.1 Spatial Data Models
2.2.2 Operations ....
2.2.3 Topological Relationships


:3 AN INFORMAL OVERVIEW OF SPATIAL PARTITIONS


4 THE ABSTR ACT MODEL OF SPATIAL PARTITIONS .......


4.1 Spatial Partitions.
4.2 Operations. .... .... ...
4.3 Topologfical Relationships

5 QUERYING SPATIAL PARTITIONS: THE ITSER VIEW OF
DATABASES .....

5.1 Types of Map Queries ....... .
5.2 Map Query Language: A High-level Query Language for r
5.2.1 Data Model .....
5.2.2 MQL Querying Syntax . ...
5.2.3 Querying Maps .....
5.2.3.1 Map queries . ..


MAPS IN SPATIAL
. 50

50
Mlaps .. .. .. 52
. 52
. 55
. 57
. 57
. 58
. 59


5.2.3.2
5.2.3.3


Component attribute queries .....
Component queries ......











5.3 Querying Maps in Databases Using SQL ... .. .. 60
5.3.1 Data Model ......... . .. 60
5.3.2 Creating Maps ......... .. .. 61
5.:3.3 Querying Maps ......... .. .. 62
5.:3.3.1 Map queries ....... ... .. 6:3
5.:3.3.2 Component attribute queries ... .. .. 64
5.:3.3.3 Component queries ..... ... .. 65

6 THE DISCRETE MODEL OF SPATIAL PARTITIONS .. .. .. 67

6.1 Definitions from Graph Theory . ..... .. 67
6.2 Representing Spatial Partitions as Graphs ... ... .. 68
6.3 Properties of Spatial Partition Graphs ...... .. 76

7 THE IMPLEMENTATION MODEL OF SPATIAL PARTITIONS .. .. .. 82

7.1 Map2D: an Implementation Model of Map Algebra .. .. .. 82
7. 1.1 A Data Model For Representing Spatial Partitions .. .. .. .. 82
7.1.2 Algorithms for Map Operations .... ... .. 86
7.1.2.1 Intersect ....... ... .. 87
7. 1.2.2 Relabel ........ ... .. 92
7. 1.2.3 Refine ...... ...... ....... 96
7. 1.2.4 Combining operations to form new operations .. .. .. 106
7.2 A Prototype Implementation of Map Algebra .. .. .. .. .. 107
7.3 Performance Comparison of Map2D Algorithms with an Existing GIS .. 108
7.3.1 Method of Comparison . ...... .. 108
7.3.2 Results ........... ......... 111

8 CONCLUSION ......... ... .. 116

REFERENCES ..... .._._.. ........_._.. 119

BIOGRAPHICAL SK(ETCH ....._._. .. .. 126










LIST OF TABLES


Table page

2-1 A suninary of spatial systems and their treatment of maps. .. .. .. 26

4-1 The first 42 valid matrices and protoypical drawings representing the possible
topologfical relationships between maps. Each drawing shows the interaction
of two maps, one nmap is niedium-grey and has a dashed boundary, the other is
light-grey and has a dotted boundary. Overlapping nmap interiors are dark-grey,
and overlapping boundaries are drawn as a solid line. For reference, the figures
for matrix 41 shows two disjoint maps and the figure for matrix 1 shows two
equal maps. ......... ... .. 48

4-2 The final 7 valid matrices and protoypical drawings representing the possible
topological relationships between maps. ...... .... . 49










LIST OF FIGURES


Figure page

1-1 A depiction of current spatial system architecture. The data 1... -r manages storage
and retrieval of data from a file system or database. The middleware 1 ore-r performs
processing. The user interface 1... -r provides user interaction mechanisms. .. 13

1-2 Our proposed system architecture. . ...... . 18

2-1 Examples of complex spatial objects. A) A complex point object. B) A complex
line object. C) A complex region object. ...... .. 21

2-2 Sample composite region with two components presenting a hole-like structure. 22

2-3 A depiction of various spatial operations applied to two regions. A) The first
argument region. B) The second argument region. C) The intersection of the
regions. D) The union of the regions. E) The difference of the regions. .. .. 23

2-4 The 9-intersection matrix for spatial objects A and B ... .. .. 24

3-1 A sample spatial partition with two regions. A) The spatial partition annotated
with region labels. B) The spatial partition with its region and boundary labels.
Note that labels are modeled as sets of attributes in spatial partitions. .. .. 36

4-1 A spatial partition xr with two disconnected faces, one containing a hole. A)
The interior (xo"). B) The boundary (8xr). D) The exterior (xr-). Note that the
labels have been omitted in order to emphasize the components of the spatial
partition. ......... .... . 39

4-2 The application of the refine operation to a spatial partition. A) A spatial partition
with two regions and its boundary and region labels. B) The result of the refine
operation on Figure A. ........ . .. 40

5-1 Two sample maps. A) A map with labels consisting of a single string named
crop. B)A map with labels consisting of a pair of integers, indicating the average
temperature and rainfall for each region, named Avg_ Temp? and Avg_Rain, respectively.
54

5-2 A relation containing a map2D column and the associated label tables. The table
MaplAttributeTable is associated with the map with ID equal to 1 in the table
MapTable, and the table Map2AttributeTable is associated with the map with
ID equal to 2 in the table MapTable. . .... .. 61

6-1 A spatial partition and its corresponding SSPG. A) The refinement of the partition
in Figure 3-1A. B) The SSPG corresponding to Figulre A. Nodeless edges are
dashed. ......... ..... . 70










6-2 A labeled plane nodeless pseudograph for the partition in Figure :3-1. The edges
and vertices are marked so that the sets of vertices, edges, nodeless edges, and
faces can he expressed more easily. ........ .. .. 75

7-1 A map showing an industrial and commercial zone. ... .. .. .. 8:3

7-2 A complex region object with each segment labeled. ... .. .. .. 85

7-:3 Two different views of a map. A) The map represented in the implementation
model of Map Algebra. B) The map with its segments labeled. .. .. .. .. 86

7-4 The result of the intersect operation applied to two maps. .. .. .. 87

7-5 Aggregating map labels in an intersect operation. A) The first argument map.
B) The second argument map. C) The the result of .l_ eating the argument
maps' labels during an intersect operation. .... ... . 88

7-6 The result of the plane sweep portion of the intersect algorithm for the maps
shown in Figure 7-5. A) The labeled geometry. B) The mapping. .. .. .. 90

7-7 The resulting label table from an intersect operation. A) The label table for
the map shown in Figure 7-5A. B) The label table for the map shown in Figure
7-5B. C) The label table computed as the result of an intersect operation. .. 91

7-8 Processing halfsegments in a region. A) Processingf the smallest halfsegfment b
of the sequence. B) Processing half segment k of a cvele. .. .. .. 101

7-9 The result of the r ,lItr; _. operation applied to two maps.. .. .. . .. 106

7-10 Images of the PMAI di pl w~ing the final result of the or J.~;;i algorithm test for
each of the data sets used. . .. ... .. .. 110

7-11 Running times for the intersect operation in PMAI and GISX. .. .. .. .. 11:3

7-12 Running times for the or ,lIt;_. operation in PMAI and GISX. .. .. .. .. 114









Abstract of Dissertation Presented to the Graduate School
of the University of Florida in Partial Fulfillment of the
Requirements for the Degree of Doctor of Philosophy

MAP ALGEBRA: A DATA MODEL AND IMPLEMENTATION
OF SPATIAL PARTITIONS FOR USE IN SPATIAL DATABASES
AND GEOGRAPHIC INFORMATION SYSTEMSir

By

Mark McE~enney

August 2008

CI. ny~: Markus Schneider
MI li r~: Computer Engineering

The idea of a map? is a fundamental metaphor in spatial systems. For instance, in the

fields of geographical information systems (GIS), spatial databases, geography, robotics,

computer assisted design (CAD), and spatial cognition, the arrangement of spatial data

into map form pil- a primary role in the composition, representation, and analysis of

spatial data. However, no models of maps currently exist that provide a precise definition

of a spatial data type for maps and operations over them. Instead, many informal

definitions are provided, many of which are tied to specific implementation concepts.

Furthermore, although the integration of spatial databases into spatial fields such as

GIS has received much attention, the notion of integrating maps into databases has been

overlooked. Thus, the idea of integrating maps into SQL and performing queries over them

has not yet been explored. This thesis describes the design and implementation of M~ap

Algebra, a type system and operations for maps in spatial databases. We provide a three

level approach to definingf Map Algebra. First, we provide an abstract model of maps. This

is a mathematical description of maps and their operations and topological predicates.

This model is defined on formal mathematical concepts that are not implementable in

computer systems; therefore, we then provide a discrete model of maps based on discrete

concepts that can be translated to computer systems. We then provide an implementation

model of maps, complete with algorithms to implement map operations, that can be










directly implemented in a computer system. Furthermore, we develop a query language

called M~ap Query Liem:l;' y.l: that can be used to pose queries over maps in databases.










CHAPTER 1
INTRODUCTION

The idea of a mesp is a fundamental metaphor in spatial systems. For instance,

in the fields of geographical information systems (GIS) [1-8], spatial databases [9-

15], robotics [16-19], computer assisted design (CAD) [20-23], and spatial cognition

[18, 24, 25], the arrangement of spatial data into map form pll li- aa primary role in the

composition, representation, and analysis of spatial data. Specifically, in applications such

as spatial databases systems (SDS), GISs, and global positioning systems (GPS), the

map itself pll li-4 a central role in that the map is the primary user interface tool. GISs

in particular have adopted maps for geoprocessing, and a rich set of geoprocessing tools

has been developed around them. Thus, maps in the context of GISs and SDSs and the

functionality provided in these systems are of vital importance to industry, government,

and the many scientific fields which make use of these systems.

The general goal of this dissertation is to examine the way maps are implemented

and operated on in current spatial systems, and discover methods to improve the

representation and storage of map data and the v- .1-< that users can interact with maps.

We approach this goal by attempting to integrate maps as first cleas~s citizens in databases.

In the next few sections we motivate our goal by providing a more detailed discussion of

the state of the art with regard to maps in spatial systems, identifying problems related

to the current state of the art in maps, and identifying some specific goals to improve the

state of the art that the remainder of this thesis will address.

1.1 Motivation

In general, spatial systems can he conceptualized as consisting of three components

arranged as shown in Figure 1-1: a data 1... -r, a processing or middleware component,

and a user interface. The data 1... -r is typically implemented as a spatial database or

file system that manages the physical storage of the spatial data. The middleware 1.,-< c

performs operations and computations that the data 111-< v does not provide. Typical










examples of such computations are coordinate projections, triangulation of ]~in.hvons, and

the preparation of data for input to the user interface. The visualization lIn-
data to the user and processes user input, which is passed back to the middleware 1.,-< c

and the data 1... vr. In the following, we discuss each lI-;- r in more detail. Specific systems

and their capabilities are discussed in Section 2.

We begin by examining the data 1 e -< c in spatial systems. As was mentioned before,

the data 1... -r is used to store the actual spatial data. Spatial data itself is stored in the

form of .spretial primitives, which are the fundamental units of spatial objects. In early

systems, spatial primitives consisted of points and .straight line .segments, which were

used to construct spatial objects such as points, lines, and regions. The first generations

of spatial data storage stored these primitives in files [26, 27]. Because file systems

typically provide only input/output operations, all spatial operations were implemented in

middleware, and the file system was used only for storage. When databases began to be

used to store spatial data instead of file systems, the database was treated much like a file

system in that it was only used for storage and spatial operations were still implemented

in middleware [2, 14, 28-30]. For example, a region would be assigned a unique identifier,

and all straight line segments that made up the region would exist in tuples in a database

table along with the region identifier indicating which region they belonged to. Thus, a

join operation was typically required between a region table and table containing straight

line segments in order to construct a region. This proved to have poor performance,

and, because the spatial objects were not known by the database, all operations were

implemented in middleware.

The advent of extensible database systems [:31-39] provided a solution to the

problems with the original attempt to integrate spatial data into databases. With an

extensible database, the database could be made aware of a .spatial clette t~ype consisting

of both data and operations over the data [10, 14, 15, 40]. Therefore, a database could

manipulate a spatial data type, such as a region, as if it were any other type of which the










User Interface
Application ProgramAP

Middleware Laye
Processing Layer
(map operations)

Map Construction Layer
(map representation)

Data Layer
DBMS
Data Storage
(spatial primitives)


Figure 1-1. A depiction of current spatial system architecture. The data 1... ;r manages
storage and retrieval of data from a file system or database. The middleware
1... -r performs processing. The user interface 1... -r provides user interaction
mechanisms.


database was aware. Thus, operations like spatial intersection, union, and difference could

be moved from middleware directly into the database. In other words, spatial objects

became first class citizens in the database, allowing SQL queries over spatial objects

that took advantage of spatial operations. The result was increased performance and

flexibility of spatial systems. The current state of the art in spatial systems is to use a

data 1 ... r consisting of a database that is aware of points, lines, and regions, together with

operations such as spatial intersection, union, difference, and topological predicates.

The role of the middleware 1 ... r has typically been to provide operations that are not

available in the data 1... -r. Because current spatial databases are aware of concepts such

as points, lines, and regions, the middleware 1 .v. r in current systems combines these more

simple spatial objects to form more complex spatial arrangements, typically GIS map~s.

Here we use the term GIS maps to mean a map as it is defined in the GIS literature [3-6]:

a map is a collection of map 1...r-is such that each map 1...;r is composed of points, lines,

and regions that are optionally associated with attribute data. Therefore, a middleware

1... ri collects points, lines, and regions from the database, and arranges them into map

1... ris, which compose a GIS map [1]. Once a map is created, it is passed up to the










visualization 1... -r, which handles issues such as clipping, di p~liningf thematic information,

and providing color and texture to maps for display.

In summary, Figure 1-1 illustrates the architecture of current spatial systems.

The data 1... -r of current systems utilizes a database which can store and manipulate

the spatial primitives of points, lines, and regions. The middleware 1 ... -r contains a

component that can collect these spatial primitives and construct a map from them. 1Vap

operations, such as overlaying l~;ivr; are performed on constructed maps, and the results

are presented to the user through a visualization or user interface 1... r.

It is clear that the concept of a map is important in spatial systems due to the fact

that they are almost universally used in such systems. However, given the state of the

art as discussed above, we note that the current middleware implementation of maps is

strikingly similar to the middleware implementations of points, lines, and regions that

existed in earlier systems. Specifically, we note that the spatial components of maps (i.e.,

the points, lines, and regions that compose the map) can be spread across multiple tables

in a database. Therefore, we postulate that a middleware implementation of maps suffers

similar problems to the middleware implementation of points, lines, and regions. However,

the open problem exists that there is currently no method of integrating a map type into a

database data 1... -r of spatial systems. In other words, maps are not first class citizens in

databases. In order to integrate maps as first class citizens in databases we must address

the additional open problem that querying mechanisms for maps in databases have not

been thoroughly studied. Currently, map attributes, such as names, populations, etc., can

be queried and spatial queries can be performed over the points, lines, and regions that

compose a map, but queries over maps themselves are unavailable. For example, it is not

possible to find all maps in a database that form a submap of a query map.

1.2 Problem Statement

Based on the current state of the art of spatial systems and the previous discussion,

the overall problem this thesis addresses is to discover methods for integrating maps










as first class citizens into spatial systems. We split this problem into five sub problems

that can be addressed individually: (i) we must have a definition of maps that describes

their properties, (ii) we must know the semantics of map operations, (iii) we must be

able to determine relationships between maps based on their geometries (i.e., topological

relationships), (iv) we must have a way to express queries over maps that provides access

to all features of maps as well as map operations and predicates, (v) we must have efficient

methods of implementing maps and operations in spatial systems.

A formal definition of maps that precisely describes their properties is essential for

definingf operations and predicates and ensuring closure properties of maps over them.

In C'!s Ilter 2, we will see that many definitions for maps exist, but they are all based on

informal descriptions or treat maps as collections of more primitive spatial types, and

not as first class citizens. Therefore, in order to address this problem, we must provide

a precise definition of maps based upon mathematical concepts instead of intuitive

descriptions.

The existence of a formal model of maps based on mathematical concepts will allow

the definition of precise semantics for map operations. Therefore, we must provide such

semantic descriptions of map operations that currently exist based upon our model. This

will allow us to ensure operational closure, guaranteeing that map properties are preserved

through the application of such operations.

A formal model of maps based on mathematical concepts can also be leveraged to

define the relationships of two maps in space. An important class of spatial queries over

traditional spatial types is the class of topological queries. Topological queries are based

upon topological predicates (Section 2) which indicate qualitative properties between a

pair of spatial objects such as .Il11 Il:ency or inclusion. These predicates form the basis

of spatial index structures as well as topologfical queries. Because of the importance of

this class of queries, we need to define topologfical relationships between maps based on a

formal definition of maps.










Because our overall goal is to include maps as first class citizens in databases, we

must provide some method for users to interact with maps in databases. Therefore, we

must provide some mechanism to interact with maps based on SQL, which is the standard

database querying language. Because maps are currently not treated as first class citizens,

no method of integrating map types into SQL currently exists. Therefore, we must show

how maps can he represented in a database context, and develop a method for integrating

map operations and map querying mechanisms into SQL.

Finally, the map data type and operations over it must he implemented. Therefore,

we must provide an implementation for maps consisting of a data model and operations

that preserves the properties of maps and the semantics of map operations. Furthermore,

the operations over maps must he implemented efficiently, and the data model must

support the operations adequately. Thus, we must provide algorithms for operations and

implement them in order to verify their efficiency.

1.3 Goals and Solutions

In order to address the problems discussed in the previous section, we require a

formal type .system or rll, l~an for maps which precisely defines the semantics of maps and

operations over maps. Although maps and their operations are described in many works

[3-7, 40 these definitions are all informal. In such cases, situations may arise in which

the semantics of an operation are unclear; therefore, we will define a new M~ap Algebma

that provides precise semantics. We approach the development of Map Algebra from three

levels: the abstract level, the discrete level, and the implementation level. At the abstract

level, we define a purely mathematical model of maps. This allows us to precisely describe

the properties of maps. Using this model, we can then identify map operations, and

precisely define their semantics. Alap operations differ from traditional spatial operations

because maps are thematic; therefore, map operations must take care of thematic data as

well as geometric data. Furthermore, we can address the concerns of closure properties of

map operations at this level. At this level, we can also leverage the formal definition of










maps to discover topological relationships between maps. Therefore, by completing the

abstract definition of Map Algebra, we will provide solutions to problems (i), (ii), and (iii)

mentioned above.

Given the abstract model of Map Algebra, we can consider constructs necessary for

querying maps. We approach the problem of querying maps from two levels. First, we

develop a new map query language, called MQL, that is able to express queries over maps.

This is a special purpose language designed around maps, and is intended as a high level,

user view of maps in databases. We then show how MQL constructs can be expressed in

SQL. By creating a method to integrate maps into SQL, we can consider maps as first

class citizens in a database setting as well as take advantage of the wide acceptance of

SQL by database users.

Once the abstract model of Map Algebra, including querying mechanisms, is

complete, we consider the implementation of maps in computer systems. This is achieved

by first considering Map Algebra at the discrete level. A discrete model of maps translates

the abstract model of maps into the discrete domain by defining discrete representations,

such as graph representations, for the map data model defined at the abstract level. The

discrete model should preserve the properties of the abstract model, but eliminate the

need for concepts such as infinite point sets and continuous mappings. The result is a

model that can represent maps based solely on discrete concepts. By defining a discrete

representation of maps, we can ensure that the properties of maps defined at the abstract

level are transferred into the discrete domain. This will allow us to ensure that maps

represented in discrete methods are valid in the sense that they preserve the properties of

maps as defined in the abstract, mathematical model.

At the implementation level, we focus on developing data structures and algorithms

that can be used to implement a map data type. The properties of the implementation

model of maps should be identical to the properties of the abstract and discrete models of

maps, but be oriented towards implementation. The implementation model should provide










mechanisms for users to create, store, and manipulate maps. Once the implementation

model is complete, we can directly implement it in a database system. The creation of an

implementation model address problem (v) mentioned above.

Recall that the general goal of this proposal is to discover methods to improve the

representation and storage of map data and the r- .--s that users can interact with maps.

Based on the state of the art of spatial systems and the problems identified above, we

refine the goal of this proposal to discover a method by which maps can be integrated as

first class citizens in database systems, including a method by which maps can be queried.

Figure 1-2 provides a pictorial description of this goal. In essence, we aim to move the

map functionality in spatial systems from the middleware 1... ri to the data 1... r.

Once an implementation of Map Algebra is achieved, we hypothesize that it will be

superior to current map implementations in several respects. We summarize the goals of

our Map Algebra implementation in terms of the following three hypotheses.

Hypothesis 1. By integrating maps as first class citizens in databases, constructing

maps and performing operations over maps will be more efficient than current methods of

implementing maps

Because maps are currently implemented in middleware, GIS maps must be

constructed from their component points, lines, and regions that are stored in the

data 1... -r. Therefore, a processing step must take place to perform this construction

User Interface
Visualization Program AP

Data Layer
DBMS
Processing Layer
(map operations)

Data Storage
(map data and basic spatial data)


Figure 1-2. Our proposed system architecture.










in addition to retrieving the map components that are possibly scattered across multiple

tables in a database. If a map is stored as a single database object, then it can simply

be read directly from the database, and this construction step is no longer needed.

Furthermore, the output of spatial operations, such as map overlay, is often unstructured,

meaning that the algorithm computes the line segments that form the resulting geometry,

but does not identify the spatial primitives in the resulting geometry (i.e., the points,

lines, and regions). A separate algorithm must he used to identify the spatial primitives

of the resulting map [41]. We hypothesize that the integration of maps as first class

citizens in spatial databases will eliminate much of the overhead processing associated

with middleware implementations of maps.

Hypothesis 2. By integrating maps
that utilize maps will be less complex and easier to implanent

1\odern databases provide a significant amount of functionality regarding data access

and storage. Specifically, databases typically provide transactions, concurrency control,

data recovery, an SQL interface, and multi-user access. If a map is implemented as a

type in a database system, the database automatically provides these services. If a map

is implemented in middleware, these concepts must he implemented explicitly, which

typically results in duplication of database services in the middleware 11s-c v. Therefore,

we hypothesize that a database implementation of a map type will allow application code

to be less complex since applications do not have to implement these database services.

We will investigate this hypothesis through implementing a prototype system hased on

our map concept. If we can successfully implement our map concept without the use of a

middleware 111-< r, then all map functionality will be provided by the database, which will

also provide the traditional database services.

Hypothesis 3. By integrating maps
can be provided that is curr ll;; unavailable in .spatial .s;;l 1.i










Current spatial systems provide an immense amount of geoprocessing tools and

operations for maps. However, we believe that integrating a map type into a database

will provide additional functionality that does not exist in current systems. For example,

a map type in a database can be directly used in SQL queries. Therefore, map queries

can be issued from both within and externally to a GIS environment. External queries

are possible because GIS middleware libraries are not required for the execution of

map queries. Furthermore, complex queries involving maps, such as computing nested

subqueries and .l_ egates, can be directly expressed in SQL and do not require a

middleware 1., ;-r or even a GIS intermediary. This provides more flexibility when

accessing maps since any technology with database connectivity using SQL can issue

queries over maps.









CHAPTER 2
RELATED WORK(

We present the work related to 1\ap Algebra in two general categories: work

related to traditional spatial data types, and work related to data types for maps. In

each category, we discuss the various data models that have been proposed, as well as

operations and topologfical predicates that have been developed for the models.

2.1 Traditional Spatial Types

Traditional spatial data types provide models for representing individual points, lines,

and regions. This is the approach that has typically been taken in spatial data modeling.

2.1.1 Spatial Data Models

We distinguish two generations of spatial data types. The types of the first generation

have a simple structure, and are known as the .simple .spatial types [42-45]. A .simple

point describes an element of the Euclidean plane RW2. A .simple line is a one-dimensional,

continuous geometric structure embedded in RW2 with two end points. A .simple region is a

two-dimensional point set in RW2 and topologically equivalent to a closed disk.

Additional requirements of applications as well as needed closure properties of

operations led to the second generation of complex .spatial clette types [45-47] illustrated

in Figure 2-1 ([10] for a survey). A complex point is a finite point collection (e.g., the

positions of all lighthouses in Florida). A complex line is an arbitrary, finite collection of

one-dimensional curves, i.e., a spatially embedded network possibly consisting of several

cl;i ini! connected components (e.g., the Nile Delta). A complex region permits multiple



.**: 6 8


A B C

Figure 2-1. Examples of complex spatial objects. A) A complex point object. B) A
complex line object. C) A complex region object.










areal components, called faces, and holes in faces (e.g., Italy with its mainland and

offshore islands as components and with the Vatican as a hole).

Two additional spatial data types for regions have been proposed as intermediate

steps between simple and complex regions. These are, composite regions [48] and simple

regions with holes [45, 47, 49]. A composite region can contain multiple faces, but no

holes. In other words, a composite region consists of finitely many simple regions that

are either cl;i int! or meet at single points. Although holes are not allowed in composite

regions, "hole-like" configurations can exist if two components of one region touch at a

single point of their boundaries at two different locations (Figure 2-2).





Figure 2-2. Sample composite region with two components presenting a hole-like structure.


A simple region with holes contains only a single face, with finitely many holes. The

holes in a simple region with holes are allowed to meet at a point, but cannot form a

configuration that causes the interior of the region to be disconnected. In other words, a

hole-like structure cannot he formed by the holes in a simple region with holes. Intuitively,

a simple region with holes is a complex region that has only a single face.

Each spatial type is defined such that it is made up of three parts: the interior,

bo;,, Jlm;, and exterior. Given a spatial object ,4, these components are indicated

respectively as 40, dA, and ,4-. For example, the boundary of a line is its endpoints,

and its interior consists of the lines that connect the endpoints. The exterior of a line

consists of all points in RW2 that are not part of the interior or boundary. Similarly, the

boundary of a region is the line that defines the region's border. The interior consists of

all points that lie inside the region, and the exterior consists of all points that are not part

of the boundary or interior. These concepts are required for the definition of topological

relationships between spatial types (defined in the next section).















A B C D E

Figure 2-3. A depiction of various spatial operations applied to two regions. A) The first
argument region. B) The second argument region. C) The intersection of the
regions. D) The union of the regions. E) The difference of the regions.


2.1.2 Operations

Research into spatial operations over the traditional spatial types has traditionally

centered around the point set operations of intersection, union, and n li,.- [14, 15, 50-52].

If two spatial objects are considered as point sets, then the intersection, union, and

difference operations correspond to set operations over those sets. For example, Figure 2-3

shows the result of these operations for a pair of regions.

Research into implementing these operations has built on concepts from computational

geometry. Specifically, plane sweep algorithms from computational geometry [53, 54] have

been adapted to compute geometric intersection, union, and difference over spatial objects

given that the objects are represented as a sequence of straight line segments [55-58]. This

has resulted in algorithms capable of computing such intersections in O(n Ig n + k) time for

geometric objects with a straight line segments and k intersecting segments.

2.1.3 Topological Relationships

The study of topological relationships between objects in space has been the subject

of a vast amount of research [44, 45, 49, 59]. In the areas of databases and GIS, the

motivation for formally defining topological relationships between spatial objects has been

driven by a need for querying mechanisms that can filter these objects in spatial selections

or spatial joins based on their topological relationships to each other, as well as a need for

appropriate mechanisms to aid in spatial data analysis and spatial constraint specification.










4o n Bo / 0 ,4o n 8B / 0 ,4o n B- few
8,4n Bo/ 8 ,4An 8B 0 8 ,An B- fe
4- n Bo / 0 ,4- n 8B / 0 ,4- n B- few


Figure 2-4. The 9-intersection matrix for spatial objects A and B


Topological relationships indicate qualitative properties of the relative positions of

spatial objects that are preserved under continuous transformations such as translation,

rotation, and scaling. Quantitative measures such as distance or size measurements

are deliberately excluded in favor of modeling notions such as connectivity, .Il11 Il-ency,

dl;id..ilsh I11, -- inclusion, and exclusion. Attempts to model and rigorously define the

relationships between certain types of spatial objects have lead to the development

of three popular approaches: the 9-intersection model [44], which is developed based

on point set theory and point set topology, the calculus based method [45], which is

also hased on point set topology, and the R'C' model [59], which utilizes spatial logic.

Because the definitions of spatial objects are based on topological principles, and

the inability of the calculus based method to identify a complete set of topological

relationships, the 9-intersection model is typically used to model topological relationships

between spatial objects in the field of SDSs. The 9-intersection model characterizes the

topological relationship between two spatial objects by evaluating the non-emptiness of the

intersection between all combinations of the interior ("), boundary (8) and exterior (-) of

the objects involved. A unique 3 x 3 matrix, termed the 9-intersection mardrixr (911\), with

values filled as illustrated in Figure 2-4 describes the topological relationships between a

pair of objects:

Various models of topologfical predicates based on the 9-intersection model using

both component derivations, in which relationships are derived based on the interactions

of all components of spatial objects, and composite derivations, in which relationships

model the global interaction of two objects, exist in the literature. Examples of component









derivations can be found in [48, 49]. In [49], the authors define topological relationships

between regions with holes in which each of the relationships between all faces and holes

are calculated. Given two regions, R and S, containing m and a holes respectively, a total

of (n + m + 2)2 topological predicates are possible. It is shown that this number can be

reduced mn + m + n + 1, however, the total number of predicates between two objects

depends on the number of holes the objects contain. Similarly, in [48], predicates between

complex regions without holes are defined based on the topological relationship of each

face within one region with all other faces of the same region, all faces of the other region,

and the entire complex regions themselves. Given regions S and R with m and a faces

respectively, a matrix is constructed with (m+n+2)2 entrieS that represent the topological

relationships between S and R and each of their faces.

The most basic example of a composite derivation model (in which the global

interaction of two spatial objects is modeled) is the derivation of topological predicates

between simple spatial objects in [44]. This model has been used as the basis for modeling

topological relationships between object components in the component models discussed

above. In [46], the authors apply an extended 9-intersection model to point sets belonging

to complex points, lines, and regions. Based on this application, the authors are able to

construct a composite derivation model for complex data types and derive a complete and

finite set of topological predicates between them, thus resolving the main drawback of the

component derivation model.

More recently, it has been observed that composite models of topological relationships

between spatial objects are 11g lobal in that they characterize an entire scene by a single

topological relationship that may hide local information about the object's relationship

[60]. The hiding of local information is expressed in two owsi~ in global topological

relationship models: through the dominance problem, and the composition problem.

The dominance problem indicates the property that the global view exhibits dominance

properties among the topological relationships as defined by the 9-intersection model. For










Table 2-1. A summary of spatial systems and their treatment of maps.
Map Model Middleware Thematic Map Geometric Operational Data Level
Maps Model Map Model Closure Topological
Constraint
Enforcement
Raster / / /
Collections /
Graph Models /
Tigfris / / /
ESRI GIS / /
Map Algebra / / /


example, while building roads between two .Il11 Il:ent countries, one might be interested to

know that there is a dl;id .ilst island in one of the countries for which a bridge to the other

country is required. The cl;idn~!~ IIal!11 --< in this case is overshadowed or dominated by the

existing meet (.ll11 Il:ent) situation between the countries' mainlands. The composition

problem expresses the property that a global topological predicate may indicate a certain

relationship between two objects that does not exist locally. For example, consider

two complex regions that have individual faces that satisfy the inside,covers, and meet

predicates. Globally, this configuration satisfies the overlap predicate even though no

faces overlap? locally. These properties have been addressed through the local tcor.~I JI.:y/ arl

relationship? models between composite regions [60] and between complex regions [61].

These approaches model a topological relationship between two multicomponent objects

based on the topological relationships that exist between the components of the objects.

Furthermore, it is shown that these models are more expressive than the global 9IM

models in that they can distinguish all the topological scenes that the 9IM models can

distinguish, plus many more.

2.2 Spatial Data Types for Maps

2.2.1 Spatial Data Models

In this section, we examine the various approaches that have been taken to model

maps in both the literature and in commercial GIS products. We present each approach

to modeling maps, and then evaluate the approach with respect to four criteria. First,










we determine if the map model that is described or implemented is a middleware map

model, or if it is actually a data level map model in spatial systems. We ;?i that a

map model is middleware if the map requires construction or processing outside of the

database or file system in which it is stored. Second, we determine if the system provides

thematic maps, meaning a map geometry annotated with thematic information, or

non-thematic maps, consisting of only a map geometry. In the non-thematic case, it

may be possible for a system to store thematic information separately from the map

geometry, but it is not included in the map model itself. Third, we check if operational

closure has been formally addressed. This is important since without formally addressing

operational closure, we cannot be certain that the result of map operations will be

valid in all circumstances. Finally, we find whether each model provides a mechanism

to enforce topological constraints between map contents within the model, or if an

external mechanism is required. External mechanisms of constraint enforcement are

undesirable since they can be difficult to express outside of the relational data model

and require computational overhead to enforce. For research models that do not provide

an implementation, we evaluate the model based on its properties and description. We

summarize the findings of this evaluation in Table 2-1.

The first approach to modelling maps that we discuss is the raster, or more generally,

tessellation approach. Tesselation approaches [7, 62] impose a tessellation scheme on the

underlying space and assign a value to each cell. A region in this approach consists of

all .ll11 Il:ent cells with an identical label. Therefore, a map is considered to be a bounded

tessellation such that each cell carries a label, i.e., maps in this scheme are thematic.

However, tessellation maps generally allow only a single label for each cell, or sometimes

a few labels. A disadvantage to the tessellation approaches is that they do not scale well

to handling large numbers of labels in each cell due to the high storage requirement of

these approaches. The advantage of the tessellation approach is that it aligns nicely with

data collection mechanisms, such as sampling an area divided into a grid, or taking data










from a sensor network. Thus, tessellation approaches provide a thematic map type, and

an algebra exists over tessellation maps with operational closure [7]. Furthermore, they

implicitly enforce topological constraints over its contents since values are constrained

to grid cells. However, tessellation approaches are limited in generality since they are

geometrically constrained to the tessellation scheme in use, and tessellation representations

of data can he very large, especially if high resolution cells are required.

The collection approach to modeling maps takes the view that a map is simply a

collection of more basic spatial entities that may satisfy certain topological constraints.

This is the approach taken in [12-15, 40, 51]. In general, collection types do not implicitly

support thematic maps, but model maps as purely geometric structures. Some models

provide mechanisms to associate thematic data with the individual components of the

map, but the thematic data is not part of the map definition. Furthermore, no type

closure is provided. In fact, the semantics of operations over collections, even in the

specification provided by the Open Geospatial Consortium, are defined informally and

are ambiguous. Additionally, no method of enforcing topological constraints over map

contents is provided. However, it is possible to treat an entire geometric collection as a

single object in the data level of spatial systems, meaning that they avoid a middleware

implementation.

In [11, 63], the authors consider modeling maps as special types of plane graphs. This

is an interesting approach to modelling maps because two-dimensional maps typically

impose a plane graph on the embedding space. Problems in the proposed methods arise

when different spatial objects in the map share coordinates. For example, given the

method of deriving a plane graph from a collection of points, lines, and regions, it is

unclear if a spatial point object that has the same coordinates as the endpoint of a spatial

line object in the plane graph can he distinguished. Furthermore, the authors require a

separate structure to model what they term the combinatorial structure of a plane graph,

which includes the topologfical relationships between different spatial components of the










graph. Therefore, this model allows a geometric map type modeled as a single graph, but

does not incorporate thematic information. Furthermore, operational closure over such

maps is not discussed, nor is the specification and enforcement of topological constraints.

The Topologically Integrated Geographic Information System (TIGRIS) [2, 26, 27]

is unique in that is an early system that incorporated maps into its spatial data storage

model. In the TIGRIS system, the individual traditional spatial objects are stored in a

map which contains no overlapping regions. For example, if a region representing Florida

and a region representing a hurricane that partially overlaps Florida are stored, then three

regions are actually stored by TIGRIS, the region representing the intersection of Florida

and the hurricane, the region consisting of the part of Florida that is cl;i~ ini with the

hurricane, and vice versa. These three regions are referred to as tcor..I ~l.:y/ arl primitives,

from which the original regions can be reconstructed. Although maps were integrated at

a deep level in this system, a map type was not available to the user except through a

middleware map implementation. Furthermore, the map storage was utilized to provide a

spatial algebra for points, lines, and regions, but not for maps. Therefore, no operational

closure was provided over maps. However, this system used the map storage to enforce

topological constraints over regions at the data level.

We focus our discussion of commercial GIS map offerings on the software provided

by Environmental Systems Research Institute (ESRI), since it is an industry standard

and has had portions of its architecture published in the literature. In general, the ESRI

software provides maps to users as a user interface that visualizes individual point,

line, and region objects. Therefore, maps are implemented in a middleware 1 e. -r that

manipulates the more basic spatial types. The closest technology to a data level map

data type that ESRI provides is the notion of topologies in [1]. A topology, in this sense,

is a collection of spatial objects that satisfy certain topological constraints; specifically,

spatial data objects are only allowed to meet or be disjoint. The drawback to topologies

is that they do not have a formal model to handle thematic data, and thus maps are










implemented as geometric constructs. Furthermore, the description of the implementation

of topologies reveals that they are implemented as a middleware type, and thus, the

toplogical constraints over the contents of a topology must he expressed and enforced with

an algorithm in a middleware 1.wr.T

Fr-om an implementation standpoint, research into maps has focused on data

structures that are able to represent topologfical information about map components.

Specifically, these structures represent .Il11 Il-ency information about the regions in maps.

Furthermore, these models typically represent the boundary of a map as a collection of

straight line segments. The earliest of these structures to be studied was the winged edge

.structure [23]. This structure is straightforward and can he implemented in memory or

on disk. The winged edge structure associates the edges that define the boundary of a

map with the regions they separate using a unique region identifier. Furthermore, an edge

identifier is associated with each edge. In addition to carrying the region identifiers of the

.Il1i Il-ent regions, each edge also carries an edge identifier indicating which edge would

be encountered next if traversingf the current region in a clockwise or counter-clockwise

direction. Therefore, traversing all edges that bound a region is performed rather easily

using these edge identifiers. The dc;lld;, connected edge list [57] is a similar structure that

maintains less information at each edge, and is therefore more compact.

Another structure used for implementing maps is the quad edge .structure [64]. This

structure is unique in that it represents the boundary of a map, which turns out to be a

plane graph when using most map models, and the dual of the plane graph imposed by

the boundary of the map. Furthermore, an algebra is defined that allows a pointer to be

moved around the map on either the boundary graph, or its dual. Therefore, this structure

allows connectivity queries, in which a chain of regions can he identified that connect two

argument regions, to be computed using existing graph algorithms. The drawback to this

structure, as opposed to the winged edge structure and the doubly connected edge list, is










that it is more complicated to construct and maintain, and it is not as compact as more

information is explicitly represented.

We base our Map Algebra on the model of maps presented in [65]. The authors of

this paper define an abstract, mathematical data model that formally describes the type

of spatial partitions. A spatial partition is the partitioning of the plane into regular, open

point sets such that each point set is associated with a label. The use of labels to identify

point sets allows thematic information to be modeled implicitly in spatial partitions.

Furthermore, operations are defined over spatial partitions, and it is shown that the

operations are closed over the type of spatial partitions. A detailed description of the type

of spatial partitions is provided in OsI Ilpter 4. The main drawback to this model is that

it is based on the concepts of infinite point sets and mappingfs that are not able to be

represented discretely. This has been addressed in [66], in which a graph model of spatial

partitions is defined. This model has the same properties of the spatial partition model,

but is represented using discrete concepts. A detailed description of spatial partition

graphs is provided in Section 6

2.2.2 Operations

In addition to modeling the geometric and thematic aspects of maps, operations

over maps have been extensively investigated [3-10, 14, 15, 40, 51, 67-69]. Here we

briefly describe some of the operations. Note that all operations known over maps can be

expressed in terms of three power operations [65]. We present these power operations in

detail in Section 4.2, and intuitively describe some of the more well known map operations

here. The most well known map operation is the map ot J.~; t An overlay takes two maps

as arguments, and computes a resulting map that contains the spatial and thematic data

of both argument maps. For instance, consider a map of the United States that only

contains a single region representing the entire country, and a map containing a single

region representing a high temperature zone that partially overlaps the map of the US.

The overlay of these maps would contain three regions, one representing the portions










of both maps that overlap, and the other two representing the parts of the argument

maps that do not overlap each other. Furthermore, the overlapping portion of the maps

is labeled with the labels of both maps, and the non-overlapping portions carry the

labels from their respective argument maps. A similar operation is the sup~erimp~osition

operation, in which the overlapping portions of the maps carry only the label from the

first of the argument maps. Thus, one map is superimposed over the other such that the

original of the first map remains in the result, and only the portion of the second map that

does not intersect any part of the first remains. The difference operation is also similar to

the overlay operation, except overlapping portions of the argument maps are removed from

the result. This is similar to a difference operation between complex regions. Additionally,

operations exist that operate solely on the attribute data of maps. For example, the

aggregate operation computes .I__-oegates of values of the neighborhood of regions. For

instance, in a map of counties, an .I__-oegate could be used to calculate the population of

all counties that share a boundary with a specific county. Due to the large amount of map

operations, we cannot present them all here and direct the reader to the referenced works

for more information.

Implementing operations. In this section, we consider approaches to implementing

the mapc oIr;,l; operation, since a variation of the overlay operation is required to

compute nearly all spatial operations over maps. The implementation of operations over

maps has developed in two distinct classes: operations based on a collection approach to

modeling maps, and operations based on a data type approach to modeling maps. The

collection approach to modeling maps considers a map as a collection of more simple data

types. Therefore, operations based on this approach utilize techniques that help to manage

collections of spatial data objects. The common factor in these implementations is that

an operation is broken down into two steps: a filter step and a rel~i,- step. This idea is

common in spatial index mechanisms used in spatial databases [70-75]. For example,

to compute the spatial intersection of two collections of geometries, one must compute










the intersection of all pairs of geometries from the respective collections. However, we

can reduce the amount of intersections that must be computed if we ignore pairs that

obviously do not intersect. We can distinguish such pairs by maintaining a minimum

bo;,,../.:l .9 Ir,:1 .;.g. for each geometry in both collections. We can then do a simple test

to see if the minimum bounding rectangles of two geometries intersect; if they do not,

then the geometries do not intersect. Thus the filter step finds all pairs of geometries that

may intersect based on a minimum bounding rectangle analysis. The refine step then

performs an actual intersection algorithm on the pairs of geometries that pass through the

filter step. This is the approach used in [76-78]. Although this method performs well for

the collection approach to modeling maps, it does not apply to the data type approach

to modeling maps in which the individual components of the map are not represented

individually.

The data type approach to modeling maps represents a map as a single object.

Therefore, algorithms to overlay maps in this approach cannot use the filter and refine

steps that are utilized in the collection approach. Instead, the entire map geometry is

considered as a whole. Computational geometry algorithms for this type of map overlay

algorithm have been proposed [56, 79-82]. The main drawback to this type of algorithm

is that regions whose minimum bounding boxes do not intersect are still included in the

computation of spatial algorithms since the entire maps are considered as single objects.

Although this approach is still .I-i-uplle tically faster than the collection approaches

(since all pairs of regions do not need to be computed, this approach has complexity

identical to the type of plane sweep algorithm used), the collection approaches can be

faster in situations when few map components intersect. This has lead to schemes such as

partitioning maps to address this problem [81, 82].

2.2.3 Topological Relationships

The subject of topological relationships between maps has not yet been considered

in the literature. Instead, models of topologfical relationships between the components of










maps, i.e., points, lines, and regions, have been studied extensively. These models were

discussed previously.









CHAPTER :3
AN INFOR1\AL OVERVIEW OF SPATIAL PARTITIONS

In this paper, we model maps as .spatial partitions, as discussed in [65, 66, 8:3, 84].

The definition of spatial partitions is rather dense, so we begin by providing an intuitive

description of them, and then present the formal definition in later sections.

A spatial partition, in two dimensions, is a subdivision of the plane into pairwise

cl;idnital regions such that each region is associated with a label or attribute having simple

or complex structure, and these regions are separated from each other by boundaries.

The label of a region describes the thematic data associated with the region. All points

within the spatial partition that have an identical label are part of the same region.

Topological relationships are implicitly modeled among the regions in a spatial partition.

For instance, neglecting common boundaries, the regions of a partition are ah-- .1-< disjoint;

this property causes maps to have a rather simple structure. Note that the exrterior of a

spatial partition (i.e., the unbounded face) is ahr-l-.1 labeled with the I symbol. Figure

:$-1A depicts an example spatial partition consisting of two regions.

We stated above that each region in a spatial partition is associated with a single

attribute or label. A spatial partition is modeled by mapping Euclidean space to such

labels. Labels themselves are modeled as sets of attributes. The regions of the spatial

partition are then defined as consisting of all points which contain an identical label.

Adji ... n i regions each have different labels in their interior, but their common boundary

is assigned the label containing the labels of both .Il11 Il-ent regions. Figure :$-1B shows an

example spatial partition complete with boundary labels.

In [65], operations over spatial partitions are defined based on known map operations

in the literature. It is shown that all known operations over spatial partitions can he

expressed in terms of three fundamental operations: intersection, relabel, and refine.

Furthermore, the type of spatial partitions is shown to be closed under these operations,













(I:



(I:


Figure 3-1.


A sample spatial partition with two regions. A) The spatial partition
annotated with region labels. B) The spatial partition with its region and
boundary labels. Note that labels are modeled as sets of attributes in spatial
partitions.


indicating that the type of spatial partitions is closed under all known operations over

them.









CHAPTER 4
THE ABSTRACT MODEL OF SPATIAL PARTITIONS

Although the abstract model of spatial partitions has been presented in [65] and

later refined in [83], these definitions required some modification in order to define both

topological predicates over maps and the discrete model of spatial partitions. We present
the modified definition here. We first introduce the mathematical notation and definitions

required to formally define spatial partitions. Then, the formal mathematical type

definition of spatial partitions is presented.

We now briefly summarize the mathematical notation used throughout the following

sections. The application of a function f : A B to a set of values S CA is defined as

f (S) := { f(x)|x E S} C B. In some cases we know that f (S) returns a singleton set, in

which case we write f [S] to denote the single element, i.e. f (S) = {y} < f [S] = y.

The inverse function f-l : B 2A Of f is defined as f- (y) := {x E A| f(x) = y}. It is

important to note that f-l is a total function and that f-l applied to a set yields a set

of sets. We define the range function of a function f : A B that returns the set of all

elements that f returns for an input set A as rug(f) := f(A).

Let (X, T) be a topological space [85] with topology T C 2", and let S C X. The

interior of S, denoted by So, is defined as the union of all open sets that are contained

in S. The closure of S, denoted by S is defined as the intersection of all closed sets that

contain S. The exterior of S is given by S- := (X S)o, and the boundary or frontier of

S is defined as dS := S nX S. An open set is ,n cl;lar if A =Ao [86]. In this paper, we

deal with the topologfical space RW2

A partition of a set S, in set theory, is a complete decomposition of the set S into

non-empty, disjoint subsets {Sili E I}, called blocks: (i) Vi ElI : Si / 0, (ii) Ui] s =

S, and (iii) Vi, jE I, i / j : Si n Sj = 0), where I is an index set used to name

different blocks. A partition can equivalently be regarded as a total and surjective function

f : S I. However, a spatial partition cannot be defined simply as a set-theoretic









partition of the plane, that is, as a partition of RW2 Or aS a function f : I22~I o

two reasons: first, f cannot he assumed to be total in general, and second, f cannot he

uniquely defined on the borders between .Il11 Il-ent subsets of RW2

4.1 Spatial Partitions

In [65], spatial partitions have been defined in several steps. First a .sprtirel I'o.;; ~:,.'9

of type A is a total function xr : RW2 2A. The existence of an undefined element IA

is required to represent undefined labels (i.e., the exterior of a partition). Definition 1

identifies the different components of a partition within a spatial mapping. The labels on

the borders of regions are modeled using the power set 2A; a border of xr (Definition 1(ii))

is a block that is mapped to a subset of ,4 containing two or more elements, as opposed to

a region of xr (Definition 1(i)) which is a block mapped to a singleton set. The interior of

xr (Definition 1(iii)) is defined as the union of xr's regions. The bo;, e.'./.;
1(iv)) is defined as the union of xr's borders. The exrterior of xr (Definition 1(v)) is the

block mapped IA. As an example, let xr be the spatial partition in Figure 3-1 of type

X = {,4, B, I}. In this case, rng(xr) = { {,4, {B}, {1}, {,4, B}, {A,41}, {B, I}, {,, B, I}}.

Therefore, the regions of xr are the blocks labeled {,4}, {B}, and {1} and the boundaries

are the blocks labeled {A,4B}, {A,41}, {B, I}, and {A,4B, I}. Figure 4-1 provides a

pictorial example of the interior, exterior, and boundary of a more complex example map

(note that the borders and boundary consist of the same points, but the boundary is a

single point set whereas the borders are a set of point sets).

Definition 1. Let xr be a spatial mapping of type A
(i) p(xr) := xr-l(rng(r) n {X E 2A| |X| = 1}) (regions)

(ii) Lo(iT) := iT-l(rng(iT) n {X E 2A| |X| > 1}) (borders)

(nt)x :=Usemixtwo-s nle~r~ior)

(iv) 8xi := UbEw~r) b (boundary)

(v) (e = xt({A 7or)
A .sprtirel partition of type ,4 is then defined as a spatial mapping of type ,4 whose

regions are regular open sets [86] and whose borders are labeled with the union of labels















B C


Figure 4-1. A spatial partition xr with two disconnected faces, one containing a hole. A)
The interior (xo"). B) The boundary (8xr). D) The exterior (xr-). Note that the
labels have been omitted in order to emphasize the components of the spatial
partition.


of all .Il11 Il-ent regions. From this point forward, we use the term partition to refer to a

spatial partition.

Definition 2. A spretirel partition of type 24 is a spatial mapping xr of type ,4 with:

(i) V'r E p(x) : r = ro

(ii) Vb E W(jT) : iT[b] = {xT[[r]]|r E p(x)> A bc Br}
The remaining portion of the definition of spatial partitions requires the use of the

refine operation over spatial partitions. This operation is formally defined in Section 4.2,

and so we provide an intuitive definition here. The refine operation over spatial partitions

uniquely identifies the connected components of a partition. Recall that two regions in a

partition can share the same label if they are disjoint or meet at a point. Given a partition

xr containing multiple regions with the same label, the operation r. Ro. (xr) returns a

partition with identical structure to xr, but with every region having a unique label. This

is achieved by appending an integer to the label of each region that shares a label with

another region. Figure 4-2 shows an example partition and the same partition after

performing a refine operation. Note that the notation (,4, 1) indicates that the integer 1

has been appended to label ,4.

The boundary of a spatial partition implicitly imposes a graph on the plane.

Specifically, the boundaries form an undirected planar graph. The edges of the graph

are the points mapped to the boundaries between two regions. The vertices of the graph

are the points mapped to boundaries between three or more regions. We identify edges














A B

Figure 4-2. The application of the refine operation to a spatial partition. A) A spatial
partition with two regions and its boundary and region labels. B) The result
of the refine operation on Figure A.


and vertices based on the cardinality of their labels. However, due to degenerate cases, we

must use the refinement of a partition to identify these features. We define the set of edges

and vertices imposed on the plane by a spatial partition as follows:

Definition 3. Born.'.Li t ti points of a .spretial partition xr

(i) e(xr) = {be E : |a[b]| = 2}

(ii) v(xr) = {b E : |a[b]| > 2}

4.2 Operations

Three basic spatial partition operations have been defined that can he used to form

the formal definitions of all other known partition operations: intersection, relabel, and

r.R.These are the only operations we present in this paper since the number of map

operations is large and all other operations can he formulated using these three. Each

of these operations is closed over the set of valid spatial partitions, meaning that if valid

partitions are supplied as arguments to these operations, a valid partition will be returned

[65]. The intersection of two partitions xr and a, of types ,4 and B respectively, returns a

spatial partition of type A x B such that each interior point p of the resulting partition

is mapped to the pair of labels (x [p], a p], and all order points are mapped to the set

of labels of all .Il11 Il-ent regions. Formally, the definition of intersection of two partitions

xr and a of types ,4 and B can he described in several steps. First, the regions of the

resulting partition must he known. This can he calculated by a simple set intersection of









all regions in both partitions, since n is closed on regular open sets.


pn(xr, a) := {r n sir E p(x) As p(a)}

The union of all these regions gives the interior of the resulting partition: Ln(Kr, a) :=

Urep,(x,a)r. Next, the spatial mapping restricted just to the interior is calculated by

mapping each interior point p E I := Ln(r, a) to the pair of labels given by xr and a:


"r := Ap : I. {((x [p] a [p) }

Finally, the boundary labels are derived from the labels of all .Il11 Il:ent regions. Let

R := pn(r, a), I := Ln(iT, a), and F := RW2 I. Then we have:

intersection : [ A] x [ B] [ Ax B]

intersection(xr, a) := xl U Ap : F.{xyl[[r]]|r E RAp E r}

Relabeling a partition xr of type A by a function f : A B is defined as f o xr, i.e., in

the resulting partition of type B each point p is mapped to f(xrp)) (recall that xr(p) yields

a singleton set, e.g. {a}, and that f applied to this yields the singleton set { f(a)}).

relabel : [ A] x (A B) [ B]

relabel(xr, f) := Ap : R2.f~~

The refinement of a partition identifies the connected components of the partition.

This is achieved by relabeling the connected components of a partition with consecutive

numbers. A connected component of an open set S is a maximum subset S cT such

that any two points of T can be connected by a curve lying completely inside T [85]. Let

y(r) = {cl,...c,}) denote the set of connected components in a region r. Then, reli,.

can be defined in several steps. The regions of the resulting partition are the connected

components of all regions of the original partition:









The union of all these regions results in the interior of the resulting partition: L,(xr) :=

UrEpy(")r. This means that the set of interior and boundary points are not changed by
refine .

We can now define the resulting partition on the interior:


x: := {(p, {xrp], i)})|r E p(x) A Y(r) = {c1,.., cnr} A ie {1,..., nr} Ap E cs}


Finally, we derive the labels for the boundary from the interior, much like the

definition for intersection. Let R := p,(xr), I := L,(xr), and F := RW2 I. Then:

relit..-: [A] [A x N]

rcle. (xr) := xrl U Ap : F.{xyl[[r]]|r E RAp E r}


4.3 Topological Relationships

In this section, we describe a method for deriving the topologfical relationships

between a given pair of maps. We begin by describing various approaches to the problem,

then outline our chosen method, and finally derive the actual relationships based on this

method. Note that in this section, we refer to maps as map? geometries because topological

relationships consider only the spatial aspects of maps, and not their thematic attributes.

In order to define a complete, finite set of topologfical relationships between map

geometries, we employ a method similar to that found in [46], in which the 9-intersection

model is extended to describe complex points, lines, and regions. In Section 4.1, we

defined a point set topological model of map geometries in which we identified the interior,

exterior, and boundary point sets belonging to maps. Based on this model, we extend the

9-intersection model to apply to the point sets belonging to map objects. However, due to

the spatial features of map geometries, the embedding space (RW2), and the interaction of

map geometries with the embedding space, some topological configurations are impossible

and must be excluded. Therefore, we must identify topological constraints that must be

satisfied in order for a given topologfical configuration to be valid. Furthermore, we must










identify these constraints such that all invalid topological configurations are excluded,

and the complete set of valid configurations remains. We achieve this through a proof

technique called Pr...-f-lut-Constraint-and-Drawing, in which we begin with the total set of

512 possible 9-intersection matrices, and determine the set of valid configurations by first

providing a collection of topologfical constraint rules that invalidate impossible topologfical

configurations, and second, validating all matrices that satisfy all constraint rules by

providing a prototypical spatial configuration (i.e., the configurations can be drawn in the

embedding space). Completeness is achieved because all topological configurations are

either eliminated by constraint rules, or are proven to be possible through the drawing of

a prototype. The remainder of this section contains the constraints, and the prototypical

drawings of map geometries are shown in Table 4-1.

We identify eight constraint rules that 9IMs for map geometries must satisfy in

order to be valid. Each constraint rule is first written in sentences and then expressed

mathematically. Following each rule is the rationale explaining why the rule is correct. In

the following, let xr and o- be two spatial partitions.

Lemma 1. Each component of a map? geometry intersects at least one component of the

other map? geometry:
(VC7x E {xTo, a,-} : O~ n oo 0 V Ox Cn o- 0 V Ox Cn o-- 0 )

A (VC, E {aoo, Do, o-> : C, n no 0 v C, n Dr 0 v C, n xr- 0)

Proof. Because spatial mappings are defined as total functions, it follows that

xo" U 8xr U xr- = RW2 and that oao U Bo- U o-- = RW2. Thus, each part of xr must intersect

at least one part of o-, and vice versa. o

Lemma 2. The exteriors of two map? geometries rl~i;, r, intersect:

jT- n o- 0

Proof. The closure of each region in a map geomtry corresponds to a complex region

as defined in [46]. Since complex regions are closed under the union operation, it

follows that the union of all regions that compose a map geometry is a complex region,










whose boundary is defined by a Jordan curve. Therefore, every spatial partition has an

exterior. Furthermore, in [65], the authors prove that spatial partitions are closed under

intersection. Thus, the intersection of any two spatial partitions is a spatial partition that

has an exterior. Therefore, the exteriors of any two spatial partitions intersect, since their

intersection contains an exterior. O

Lemma 3. If the boundary of a map geometry intersects the interior of another map

geometry, then their interiors intersect:





Proof. Assume that a boundary b of partition xr intersects the interior of partition a

but their interiors do not intersect. In order for this to be true, the label of the regions

on either side of b must be labeled with the empty label. According to the definition of

spatial partitions, a boundary separates two regions with different labels; thus, this is

impossible and we have a proof by contradiction. o



Lemma 4. If the bo;,n Jl~r a of a map geometry intersects the exterior of a second map

geometry, then the interior of the first map geometry intersects the exterior of the second:





Proof. This proof is similar to the previous proof. Assume that the boundary b of

partition xr intersects the exterior of partition a but the interior of xr does not intersect

the exterior of a. In order for this to be true, the label of the regions on either side of b

must be labeled with the empty label. According to the definition of spatial partitions, a

boundary separates two regions with different labels; thus, this is impossible and we have a

proof by contradiction. o

Lemma 5. If the boundaries of two map geometries are equivalent, then their interiors

intersect:










(aOr = aa 4 xo n a 0) m> (C j d) a (-c V d) where

r = OxP n a 0 A xo"n a =0m A aOxn ao=0m

A b~xn,- =0M A jT- n 8J=0

d = xo~ p 0 0

Proof. Assume that two spatial partitions have an identical boundary, but their interiors

do not intersect. The only configuration which can accommodate this situation is if one

spatial partition's interior is equivalent to the exterior of the other spatial partition.

However, according to Lemma 2, the exteriors of two partitions ah-- 0-4 intersect. If

a partition's interior is equivalent to another partition's exterior, then their exteriors

would not intersect. Therefore, this configuration is not possible, and the interiors of two

partitions with equivalent boundaries must intersect. o

Lemma 6. If the boundary of a mesp geometry is ..-, pl. 1. llt contained in the interior of

a .second mesp geometry. then the boundary and interior of the .second mesp geometry must

intersect the exrterior of the fast. and vice verses:

(a;T C ao i T- n afmA~- o 0"f ) a (-e v d) where

c = OxT n ao 0 A aOx n aa = 0 A aOx n a- = 0

d = xr-0D 0 a A xr no 0f

Proof. If the boundary of spatial partition xr is completely contained in the interior of

spatial partition o-, it follows from the Jordan Curve Theorem that the boundary of o- is

completely contained in the exterior of xr. By Lemma 4, it then follows that the interior of

o- intersects the exterior of xr. o

Lemma 7. If the boundary of one mesp geometry is ..-, pl. 1. let contained in the interior

of a .second mesp geometry. and the bo a J.; < ti of the .second mesp geometry is -i d* /* 7 /

contained in the exrterior of the fast. then the interior of the fast mesp geometry cannot

intersect the exterior of the .second and the interior of the .second mesp geometry must

intersect the exrterior of the fast and vice verses:










((a;T C ao A T- op aa qr = 0 A Xr- n ao 0 ))

a (c j d) a (-c V d) where

c = OxT n ao 0 A aOx n aa = 0 A aOx n a- = 0

A ~o, n S = 0 A Xr- n aa 0

d = o" n a- = 0 A r na to 0

Proof. We construct this proof in two parts. According to Lemma 6, if 8xr c ao, then

xr- n ao / 0. Now we must prove that xo" cannot intersect a-. Since 8xr c ao, it follows

that xo" intersects ao. Therefore, the only configuration where x" n a- / 0i can occur is if

a contains a hole that is contained by xr. However, in order for this configuration to exist,

the da would have to intersect the interior or the boundary of xr. Since the lemma specifies

the situation where xr- > Be, this configuration cannot exist; thus, the interior of xr cannot

intersect the exterior of a. o

Lemma 8. If the boundary of a map? geometry is ,-..;;;;.1. i li contained in the exterior

of a second map? geometry and the bo aJ:~~ri of the second map? geometry is ,-..;;;~l~;.1.L,

contained in the exterior of the first, then the interiors of the map? geometries cannot

intersect:



o (c j d) a (-c V d) where




d= xopn o=0

Proof. The lemma states that the interiors of two cl;i- ..111 maps do not intersect. Without

loss of generality, consider two map geometries that each consist of a single region. We

can consider these map geometries as complex region objects. If two complex regions

are11-..1,1then their interiors do not intersect. We can reduce any arbitrary map to a

complex region by computing the spatial union of its regions. It follows that because the










interiors of two disjoint regions do not intersect, the interiors of two dl;i~ ;!1 maps do not

intersect. O

Using a simple program to apply these eight constraint rules reduces the 512 possible

matrices to 49 valid matrices that represent topologfical relationships between two maps

geometries. The matrices and their validating prototypes are depicted in Table 4-1.

Finally, we summarize our results as follows:

Theorem 1. Based on the 9-intersection model for spatial partitions, 49 different topologi-

cal relationships exist between two map geometries.

Proof. The argumentation is based on the Pr...-f-by-Constraint-and-Drawing method.

The constraint rules, whose correctness has been proven in Lemmas 1 to 8, reduce the

512 possible 9-intersection matrices to 49 matrices. The ability to draw prototypes of the

corresponding 49 topological configurations in Table 4-1 proves that the constraint rules

are complete. O













Table 4-1.


The first 42 valid matrices and protoypical drawings representing the possible
topological relationships between maps. Each drawing shows the interaction of
two maps, one map is medium-grey and has a dashed boundary, the other is
light-grey and has a dotted boundary. Overlapping naap interiors are dark-grey,
and overlapping boundaries are drawn as a solid line. For reference, the figure
for matrix 41 shows two disjoint maps and the figure for matrix 1 shows two
equal maps.


Matrix 1


Matrix 2


Matrix 3


Matrix 4


Matrix 5


Matrix 6


Matria 7


1 1 0
0 1 0
0 01
Matria R


1 01
0 1 0
0 01
Matrix 9


1 1 1
0 1 0
0 01
Matrix 10


Matrix 11







Matrix 17







Matrix 23



11



Matrix 29







Matrix 315


Matrix 12







Matrix 18







Matrix 24


O)
0 01
0 11
1 01
Matrix 30



11 0
10 0
11 1
Matrix 36i


S10 1 1 111 11 11 1
1 10 1 10 0 01 1 01
0 01 0 01 0 01 0 01
Matrix 13 Matrix 14 Matrix 15 Matrix 16



S10 1 1 111 0 0 1 1 0
1 11 1 11 0 10 0 1 0
0 01 0 01 1 01 1 01
Matrix 19 Matrix 20 Matrix 21 Matrix 22



(1 00 1 10 1 01 1 1 1
1 10 1 10 1 1 0 1 1 0
1 01 1 01 1 01 1 01
Matrix 25 Matrix 26 Matrix 27 Matrix 28


Matrix 31

( 1 1





Matrix 37


(1 0 0

1 1 0
1 1 1


Matrix 32







Matrix 38



1 1 0
1 1 0
1 1 1


1 01
1 1 1
1 01
Matrix 33



1 1 0
0 1 0
1 1 1
Matrix 39



1 01
1 1 0
1 1 1


1 1 1
1 1 1
1 01
Matrix 34



0 01
0 1 0
1 1 1
Matrix 40



1 1 1
1 1 0
1 1 1


1 01 1 11
0 10 01 0
1 11 11 1
Matrix 41 Matrix 42



0 01 1 11
0 01 0 01
1 11 11 1







































Table 4-2. The final 7 valid matrices and protoypical drawings representing the possible
topologfical relationships between maps.
Matrix 43 Matrix 44 Matrix 45 Matrix 46


(10 1 1 11 0 01 0 1

1 01 1 01 0 11 0 11
1 11 1 11 1 11 11 1
Matrix 47 Matrix 48 Matrix 49



1 11 1 01 11 1
0 11 1 11 11 1
1 11 1 1 1 ]1 1









CHAPTER 5
QUERYING SPATIAL PARTITIONS: THE USER VIEW OF MAPS IN SPATIAL
DATABASES

The previous chapter defined an abstract, mathematical model of maps in the form

of spatial partitions. This model defines the type of spatial partitions as well as the

semantics of operations over spatial partitions. In this chapter, we show how the type

of spatial partitions and the operations over them can be queried and manipulated by a

user. We approach this problem at two levels: first, we define a method to express map

queries that is independent of database concepts such as SQL, and second, we show how

SQL constructs can be extended to provide map querying capabilities, and implement

the constructs provided in the first step. We assume the existence of a spatial database

that is aware of a type called mapE2D, which represents the type of spatial partitions.

Furthermore, we assume that the database is aware of operations and topologfical

predicates over spatial partitions. In following sections, we discuss the types of queries

that can be performed over the database type of map2D, provide a suitable, high-level

database representation for the type map2D, and show how map2D instances can be

created and queried in such a database.

5.1 Types of Map Queries

In Section 2, we discussed traditional spatial data types and their operations. Recall

that these traditional spatial types only represent a geometry, and do not integrate

thematic information. Furthermore, the spatial operations over them are purely geometric

in nature and do not take into account thematic attributes (instead, thematic attributes

are associated with a spatial object, but are considered separately from the object's

geometry). This has lead to a relatively straightforward implementation of the traditional

spatial types into spatial databases since queries over these types are restricted to

involving only the geometry of a spatial object. For example, traditional spatial queries

answer questions such as "return all regions that intersect a given query region", or

"return all regions with an area greater than one thousand square miles". Furthermore,









attribute queries over traditional spatial types are straightforward since they deal only

with attributes stored along with a spatial object (i.e., the attributes are separate from the

spatial object. The spatial object itself consists solely of a geometry). Therefore, queries

such as "return all regions that have a population greater than one thousand" do not need

to access a spatial object, but only an attribute stored separately from a spatial object.

As we have seen, spatial partitions differ significantly from the traditional spatial

types due to their integration of both spatial and thematic information. Thus, maps can

be queried in different owsi~ than the traditional spatial types. For example, a map query

may ask to return maps based on the attributes associated with the regions that make

up the map. The traditional spatial types have no method to associate attributes with

individual components of spatial objects. An example map query would be to "return all

maps that have a region named Floricl I

Traditional spatial types have two types of queries associated with them, spatial

queries and attribute queries. As we have seen, maps allow for new types of queries

due their more complex structure and the integration of attribute data in the data

type definition. Thus, instead of being defined merely as a geometry, a map has four

components which may be involved in queries: (i) a map geometry, (ii) components in

the form of regions that compose the geometry, (iii) attributes associated with each

region, and (iv) possibly attributes associated with the entire map as well. Therefore, we

classify map queries into four classes of queries: map? queries, which look at the map as a

whole; map? attribute queries, which are similar to attribute queries over traditional spatial

objects in that they deal with attributes stored separately from a map object; component

attribute queries, which deal with the attributes associated with regions in a map; and

component queries, which deal with the regions that compose a map. In the following

sections we discuss each query type in more detail and show how queries of each type can

be expressed. Note that map attribute queries are identical to thematic queries involving










the traditional spatial types; therefore, they are simply traditional queries that do not

interact with a map or its components, and we do not discus them further.

5.2 Map Query Language: A High-level Query Language for Maps

In this section, we approach the concept of querying maps from the perspective

of a user who is not familiar with databases or SQL. Therefore, we treat a map as an

abstract data type that hides the details of its implementation from the user. This has

the consequence that such a language is independent of the underlying implementation,

and can he implemented over any type of storage medium, such as a database, file system,

or computer memory. In the following, we develop the Map Query Language (11QL)

incrementally by first examining the data model of maps used in MQL, and then showing

how the various classes of map queries can he expressed in MQL.

5.2.1 Data Model

As mentioned above, in this section we treat a map as an abstract data type and

make no assumptions as to the implementation or storage medium associated with a map

implementation. However, we cannot simply use the definition of spatial partitions as

given in C'!s Ilter 4 since it is too general for creating a query language meant for users

with little technical knowledge of querying mechanisms. Specifically, we must pose some

constraints on map labels. Therefore, for the purposes of MQL, we define a new data type

called label which enforces constraints over the structure and contents of spatial partition

labels for querying with MQL.

The first constraint for labels that we require is that labels can only contain data

that corresponds to a set of defined types. In general, such a set can consist of any defined

type, but for illustration purposes, we will assume that the attributes contained in labels

must he of type string or integer, where a string is a sequence of characters, and an integer

is a number belonging to the set of integers. The second constraint is that all labels in a

map must he defined by a single label component type, which is defined as a list such that










each item in the list consists of a type associated with a label component attribute (i.e., an

identifier that uniquely identifies the attribute in the label). More formally:

Definition 4. Let T = {.string, integer} be the .set of valid label component ';,.Ii.. for

attributes contained in a label .such that t .string is t .sequence of characters and
is a number .r Z .

Let IDS be the .set of <
is a tup~le of pairs LS = (al : b ., a,. b,2) where ai E T and bi E IDS.

The MQL create label type statement that allows a user to create label types and

associate them with an identifier:

Definition 5. Let IDS be the .set of valid label component attributes and T be the .set of

valid label component ';,.Ii.. The create label statement can then be used to create lesbel~s
follows:

C'REATE LABEL TYPE 1 (al : b, ., a,. b,z) where ai E T and 1, bi E IDS

Given a label type, a label is then a tuple containing a value of the appropriate label

component type for each pair in the associated label type. Furthermore, each value can he

identified by the label component attribute defined in the label type:

Definition 6. Let LT be a label type 7. #,....1 by C'REATE LABEL TYPE LT (al

bl,..., a,. b,2) where ai E T and bi E IDS.

A label of type LT is then I. It...l
Figure 5-1 depicts two sample maps that satisfies these label constraints. The label

type for the map shown in Figure 5-1A is (.string : C'rop), and the label structure for

the map shown in Figure 5-1B is (integer : Av Temp, integer : Avy _Resin). These label

types can he created by a user with the following statements, respectively: C'REATE

L/ABEL TYPE field_crop (.string : C'rop) and C'REATE LABEL TYPE climeste_deste

(integer : Av Temp, integer : Avy _Resin). These maps will be used throughout this section

to illustrate MQL concepts.











Wheat
86, 22
Comn


A B

Figure 5-1. Two sample maps. A) A map with labels consisting of a single string named
crop. B)A map with labels consisting of a pair of integers, indicating the
average temperature and rainfall for each region, named Avg_ Temp and
Avg_Rain, respectively.


Recall that a spatial partition is defined by a spatial mapping xr := RW2 2A, where A

is the set of all region labels, with some restrictions (Definition 2). Due to the restrictions

placed on labels above, we only consider the subset of spatial partitions whose spatial

mapping restricts the set A to labels that satisfy a given label type. Thus, given label type

LT, we consider spatial partitions defined by the spatial mapping ar := RW2 2 T. For

example, the map shown in Figure 5-1A has a label type field_crop = (string : Crop) and

a spatial mapping ar : RW2 2field-cro. We refer to the type of spatial partitions whose

set of region labels is constrained by a label type LT as map2D,,. We refer to the type

of spatial partitions consisting of maps with any valid label type as mapfD. MQL is a

mechanism to pose queries over maps of the type map2D.

In order to show how maps can be created in MQL, we introduce some notation and

new operations. These operations and notations facilitate the expression of queries in

MQL. Specifically, these operations provide the ability to create new map2D instances and

add regions to map2D instances:

Definition 7.

Given a label t~ype LT and an .J~~:. MI; r M~, the MQ&L map create statement returns a

new map with no regions:

CREATE M~AP M~ (LT)










The add operation takes
be added the map2D instance. and a label and adds the argumentt region and label to the

map2D instance:

add := mapE2DLT x region x LT

Furthermore, we assume an assignment operator exists for the type map2D in the

form of: '=

Therefore, in order to create the maps in Figure 5-1, we would use the following

sequence of MQL statements:

C'REATE LABEL TYPE feld _crop(.string : C'rop)

C'REATE LABEL TYPE climate _dates(integer : Av Temp, integer : Avy _Resin)

C'REATE AfAP All (Aeld _crop)

C'REATE AfAP i:' (climate_dates)

Once we have created maps, we can then add regions to them. Let r, s, t, and a he

regions, each corresponding to a region in the maps shown in Figure 5-1. We can then add

these regions to their respective maps as follows:







5.2.2 MQL Querying Syntax

Based on the type of map2D, we now define the constructs necessary to pose queries

in MQL. A MQL statement consists of three components called clauses: the FIND clause,

the IN clause, and the THAT clause. The FIND clause indicates what will be returned by

the query. MQL statements can return either map2D instances or labels. Therefore, the

FIND clause contains either the keyword AfAP, to indicate that a map will be returned by










the query, or a label type that indicates the structure of labels that will be returned by the

query.

The IN clause contains a list of map2D instances that query a will be performed over.

In MQL implementations, this list will correspond to a database relation or file system

structure, but for the purposes of definingf a user concept that is not tied to a specific

implementation, we will represent it simply as a list.

Finally, the THAT clause contains a boolean expression that is evaluated over each

of the map objects in the IN clause, their labels, and/or their component regions. In

order to achieve this, we introduce two functions: CONTAINS_LABELO and CON-

TAINS_REGIONG that evaluate a Boolean expression and return the result. The CON-

TAINS_LABELO operation contains a boolean expression involving labels of the maps

in the IN clause. The CONTAINS_REGIONG operation contains a boolean expression

involving the component regions of the maps in the IN clause. The signatures for these

functions are:

Definition 8. The boolean expression given as an argument to the CONTAINS _LABEL

function will be applied to the label associated with each region in a map?. The boolean

expression given as an argument to the CONTAINS _REGION function will be applied to

each component region of a given map?.

CONTAINS_LABEL := boolean_exp~ression B I

CONTAINS_REGION := boolean_exp~ression B I

The IN clause of an MQL expression can contain a boolean expression consisting of

predicates over maps, CONTAINS_LABELO statements, and CONTAINS_REGIONG

statements. We refer to such a boolean expression as a criteria. Therefore, a MQL

statement returns maps or labels from a list of maps that satisfy a given criteria

Therefore, the structure of an MQL query is as follows:










Definition 9. Let LT be a label typ~e. Let the notation xly mean that x or y I,,re be used,

but not both

FIND M~AP | LT

IN MI,... Mi E mapf2D

THAT criteria

It is straightforward to consider MQL statements where maps are returned, since

any map in the IN clause that satisfies the given criteria will be returned. However MQL

statements that return labels are not as straightforward. If a label structure is given in the

FIND clause, then the query will return all the labels from every map in the IN clause

that satisfies the criteria. However, labels will only be included in the result that strictly

conform to the label structure given (i.e., the labels have the same type and identifier

as given in the label structure in the FIND clause of the MQL query). In the following

subsections, we show how the different classes of map queries can be expressed in MQL.

5.2.3 Querying Maps

At this point, the user has the ability to create maps and add regions and their

corresponding labels to maps. In the following sections, we examine how a user can pose

queries over maps and execute map operations using MQL constructs. We provide a

discussion of each class of map queries identified previously, providing sample queries and

showing how they can be expressed in MQL. New operations are introduced as they are

needed.

5.2.3.1 Map queries

Map queries, as stated previously, are queries that consider a map as a whole, often

involving map operations. For example, queries that return all maps whose area is larger

than one thousand square feet or that calculate the overlay of a pair of maps, or that

return maps based on a topological relationship fall into this category. In general, queries

of this type can be expressed in a straightforward manner as long as the appropriate map










operation is defined. For example, in order to find all maps in a table with an area greater

than one thousand, the user would use an area operation:

Query 5.2.1. FIND AfAP IN All. it.' THAT 1000

Queries involving geometric operations, such as overlay, can he expressed by simply

calling the appropriate operations:

Query 5.2.2. MS3 = Or J.;;;,,' ll. ME2 )

Finally, if we assume that we have a topological predicate between maps named

intersects available, which returns a value of true if two maps intersect, we can discover all

maps that intersect a query map as follows:

Query 5.2.3. FIND AfAP IN All. if.' THAT intersects( MS )

5.2.3.2 Component attribute queries

The class of component attribute queries does not correlate with any type of queries

over the traditional spatial types. This is because the ability to associate attribute data

with the components of spatial objects is unique to spatial partitions. For example a

user may want to find the names of all maps that contain a region that contains the crop

wheat. Such a query makes use of the C'ONTAINS_LABEL function in its criteria to look

at the label of each region in each map in the IN clause:

Query 5.2.4. FIND AfAP IN All. it.' THAT C'ONTAINS_LABEL( C'rop = 'wheat' )

Because the map All contains a region with a label containing an identifier "Crop"

and the value i.l,! I ", the C'ONTAINS_LABEL with the supplied argument will evaluate

to true for map All, and it will be returned.

A more complex query would return attributes from regions in a map that satisfy

some criteria. For example, a user may wish to find the average temperature for all regions

in maps that have an average rainfall greater than 20 inches. Recall that if a label type

is specified in the FIND clause of a MQL query, all labels will be returned for any map










that satisfies the criteria in the MQL statement. Therefore, we require a mechanism to

isolate only the labels that satisfy the given criteria in a map. We achieve this by making

the observation that every region in a map, when considered separately from the map,

forms a singleton map?. A singleton map is map that contains only a single region, which

means it has only a single region label. If each region of every map in the IN clause can

he considered separately, then we can return the labels only for the singleton maps that

satisfy the criteria. In order to achieve this, we assume the existence of a map operation

Agel~nd := map2D 2nzap2D which takes a map2D instance, and returns a set of

singleton maps such that each map in the result set corresponds to a region in the original

map. This function can then he used in the IN clause of MQL. Therefore, we can express

the desired query as:

Query 5.2.5. FIND ((integer: Avy_Temp?)) IN Exrprend(1/!l). Exrprend(1/3)~ THAT C'ON-

TAINS_LA BEL ( Av Resin > 20 )

5.2.3.3 Component queries

Component queries allow users to query maps based on their components, i.e. regions.

These are similar in concept to component attribute queries, but deal with the region

geometries contained in a map instead of the region attributes. For example, if a user

wishes to return all maps that contain a region with an area greater than one thousand

square miles, they could use an
Query 5.2.6. FIND AfAP IN All. if:' THAT C'ONTAINS_REGION( areal) > 1000)

Another useful query is to extract regions from a map that satisfy some predicate.

For example, to find all regions in a map with area greater than one thousand square

miles, a user could pose the following query:

Query 5.2.7. FIND AfAP IN Exrpend ( All ) THAT 1000










5.3 Querying Maps in Databases Using SQL

In the previous section, we showed how maps can be queried using the MQL

language. In this section, we consider querying maps in SQL and show how the concepts

from MQL can be expressed in SQL. We assume the existence of a database that is aware

of the type mapE2D, as defined previously, and the operations and predicates over it.

5.3.1 Data Model

The data model for maps in spatial databases should support the four classes of

queries discussed above. Therefore, we propose a data model for spatial partitions in a

database to be composed of two components: the geometric component and the label

component. The geometric component consists of the map geometry, and is implemented

as a column type named mapE2D. This is similar in concept to the implementation

of traditional spatial types in databases. The difference between map2D and the

implementation of traditional types is that each region in the map is associated with a

region identifier which will be used to associate each region with its attribute data.

The second component to the map2D type consists of the attributes for each region.

We assume that each instance of a map2D in a column is associated with a label table,

which contains the attributes for each region in the map. The only constraint we place

on the label table is that it must contain a column of type integer named ,n I...o ~_.:.1 that

is used to associate each tuple in the label table with a region in its corresponding map.

By storing the region attributes in a separate database table, instead of within the map2D

data type itself, we allow the user to perform queries over the attributes associated with

regions using standard SQL. This facilitates the the class of component attribute queries

described above. Finally, we assume that a map instance stores the information necessary

to identify its corresponding label table. Figure 5-2 shows an example instance of a table

containing a column of type map2D which contains two tuples, and the label tables

associated with the map stored in each tuple.










MaplAttributeTable
region_id: int Crop: str
1 Wheat
2 Corn


Map2AttributeTable
region_id: int IAvg Temp: int IAvg Rain: int
1 98 14
2 86 22


Figure 5-2. A relation containing a map2D column and the associated label tables. The
table MaplAttributeTable is associated with the map with ID equal to 1 in
the table MapTable, and the table Map2AttributeTable is associated with the
map with ID equal to 2 in the table MapTable.


5.3.2 Creating Maps

In this section we show how we can extend the SQL CREATE and INSERT

constructs to accommodate the creation of tables containing map columns and tuples

containing maps. We assume that the database is aware of the data model of maps as

discussed in the previous section, specifically the type mapE2D. We now show how a user

can create the tables depicted in Figure 5-2.

Consider a user who wishes to create a map in a database. We assume that this user

begins with an empty database (i.e.., a database containing no tables) and performs the

necessary steps to create a map2D instance within the database. The first step the user

must take in order to create a map is to create a table in which the map will be stored.

Since the database is aware of the map2D type, we can simply use a create table command

as shown below:

Statement 5.3.1. CREATE TABLE M~apTable( ID: int, Name: str, Geom: map2D )

Note that the above statement creates only the table named \! IIpTable" and does

not create any tuples. In order to associate labels with the regions in a map, a map must

be associated with a label table. Therefore, the user must create a label table for a map










in order to associate the map with the table. The creation of label table is analogous to

defining a label type for a map in MQL. A label table will be associated with a particular

map, and its schema will define the structure and types of the attributes stored in it (i.e.,

each tuple is analogous to a label). Recall that we impose the restriction on a label table

that it must contain a column of type integer with the name ,n I... t.._.:ll that will be used

to associate each entry in the label table with a region in the map. For example, to create

the table named "AlaplAttributeTable" in Figure 5-2, a user would use the following

statement :

Statement 5.3.2. C'REATE TABLE IaftelAttribute~able( ,eI.: y..t._..:~ int. crop: .str )

Given a label table, a user can then create a map whose regions are associated with

the labels in the label table through an insert statement. We assume the existence of a

map constructor, which we indicate as map2D( string lesbel~able ), that takes the name of

a label table as an argument and returns an empty map object that is associated with the

label table. In other words, the map object stores the name of the label table internally.

Thus, a map can he inserted into the "AlapTable" by:

Statement 5.3.3. INSERT INTO IalTpable V/ALUES(1 i Iafrs_A '. map2D(

Afrsp~lAttribute Trble ) )

5.3.3 Querying Maps

In this section, we show how the classes of queries given above can he expressed over

the given data model for maps in spatial databases. For each class of queries, we show how

SQL can he extended to express the MQL queries that have been given previously.

In order to express MQL queries in SQL, we make some general observations. First,

the three clauses of an MQL statement, FIND, IN, THAT, correspond to the SQL

statement clauses of SELEC'T, FROM, and WHERE, respectively. In the SELECT

clause, a user can return a map by indicating that values of a column of type map2D are

returned. The list of maps found in the IN clause of MQL will be expressed as a relation










in the FROM~ clause of SQL. Finally, the boolean expression in the THAT clause of MQL

will be expressed in the WHERE clause of SQL. In later sections, we will show how the

functions introduced in MQL can be expressed in SQL.

Note that when a query that returns labels is expressed in MQL, a label structure

is given in the FIND clause. This is necessary since maps in the IN clause may have

different label structures, and two maps may have labels containing attributes with the

same identifier, but different types. By expressing the desired label structure in the query,

such cases can be resolved since the type of the desired attribute is clearly expressed.

Therefore, we introduce a notation to achieve the same effect in SQL. If there is some

ambiguity about the type of an attribute in the SELECT clause of an SQL statement

because it refers to an attribute found in a map label, then the type must explicitly

provided in the query in the form of (';,p. : .:l. ,:/. .~ r).

5.3.3.1 Map queries

Map queries consider a map as a whole, often involving map operations. For instance,

discovering maps with a total area greater than a given amount, or computing map

operations such as overlay or intersection fall into this category. In Queries 5.2.1 5.2.3,

we showed how various map queries can be expressed in MQL. Expressing the same

queries in SQL is relatively straightforward since we are treating maps as column types.

For example, Query 5.2.1 can be expressed as:

Query 5.3.1. SELECT Geom FROM M~apTable WHERE Geom.area0 > 1000

Queries involving map operations are slightly more complex in SQL than MQL since

the argument maps must be identified explicitly in the relations in which they reside.

Query 5.2.2 might be expressed as:

Query 5.3.2. SELECT O; el.;;;,' M1.Geom, M -'.Geom ) FROM M~apTable Ml1, M~apTable

M -' WHERE M1l.ID = 1AND M -'.ID = 2










Similarly, topological predicates between maps, as expressed in MQL in Query 5.2.3

can he expressed as:

Query 5.3.3. SELEC'T Al.Geom FROM~ IafTepble All. AftepTable it.' WHERE it.'.ID

= AND Intersects( Al Geom. Iif '.Geom )

Note that these queries can he expressed in a relatively straightforward manner, since

they are similar in concept to traditional spatial queries over the traditional spatial types.

In other words, we are querying the spatial object as a whole, and simply using operations

and predicates that take instances of the spatial types as arguments. This is the approach

taken in querying the traditional spatial types.

5.3.3.2 Component attribute queries

Expressing component attribute queries in SQL is conceptually more simple than

expressing them in MQL since the label tables are implemented as relations. This means

that we can use standard SQL to query them. For example, a user may wish to know the

average temperature of regions whose average rainfall is greater than 20 inches per year for

regions in Map_B in Figure 5-2. Such a query could be expressed as:

Query 5.3.4. SELEC'T Av Temp? FROM~ IafrspAttribute~able WHERE Av Resin > 20

This works if the user is aware of the name of a label table for a given map. If the

user does not know this information, we must provide a means of accessing a map's

label table through the map type itself. In MQL, this is achieved through the use of the

C'ONTAINS_LABEL operation. Therefore, we must extend SQL to include an operation

that achieves the same functionality. We introduce an operation called GetLabel~able

which takes a map2D instance as an argument and returns the relation consisting of the

label table associated with the given map. Given such an operation, we can then express

component attribute queries given instances of the map2D type:

Query 5.3.5. SELEC'T Avy_ Temp? FROM~ GetLabelTreble( SELEC'T GEOM~ FROM~

IafTapHble WHERE ID = E ) WHERE Av Rain > 20









However, querying a label table directly does not allow us to express queries such as

Query 5.2.4 and Query 5.2.5. The query above only queries the label table of a single map,

whereas Query 5.2.4 and Query 5.2.5 execute over multiple maps. In order to achieve this

in SQL, we require the use of a correlated attribute query. A correlated attribute query

is similar in concept to a correlated suhquery in that a suhquery is run repeatedly for

multiple values specified in its containing query. Correlated attribute queries typically

require that attribute types he specified in a query, as was discussed previously. For

example to return all maps that contain a region with an average rainfall greater than 20

inches, we could express the query as:

Query 5.3.6. SELECT Geom FROM~ IafTepble All WHERE EXISTS ( SELECT *

FROM~ GetLabel able ( ll. Geom ) WHERE (integer:Av Resin) > 20 )

Thus, the suhquery is executed for each map geometry stored in 'MapTable'. Using

this concept of correlated attribute queries, we can respectively express MQL Query 5.2.4

and MQL Query 5.2.5 as:

Query 5.3.7. SELECT Geom FROM~ IafTepble All WHERE EXISTS ( SELECT *

FROM~ GetLabel~able(All. Geom) WHERE (string:C'rop) = 'Wheat' )

Query 5.3.8. SELEC'T (integer:Avy_ Temp?) FROM~ IalsTable All WHERE EXISTS (

SELEC'T FROM~ GetLabel able ( All.Geom ) WHERE (integer:Av Resin) > 20 )

Note that because the label tables of maps stored in the same column can have

different label structures, it is possible that some label tables will not contain a column

named "Avg_Rain" with type integer. Thus, if any error occurs due to schema elements

not <::1-1;1! the suhquery simply returns no values and the query continues executing.

5.3.3.3 Component queries

Component queries are similar in concept to component attribute queries, but deal

with the region geometries contained in a map instead of the region attributes. Because

the map geometry is stored in the column type mapE2D, we cannot use a correlated










subquery concept similar to the approach used in component attribute queries. Instead,

we must provide access to the regions in a map in a manner which corresponds to SQL

and relational constructs. In MQL we were able to express component queries using the

Expland operator. We can express this class of queries in SQL by defining the Expland

function in terms of relations. Therefore, we define the Expland function to take a map

geometry and return a relation consisting of singleton maps such that each singleton map

represents a region in the original map. Furthermore, each singleton map will have a label

table associated with it containing a single region label. For example, if a user wishes to

return all regions from a map that have an area greater than one thousand square miles

(as in MQL Query 5.2.6), they could use the Expland operator in conjunction with an area

operator defined for regions as follows:

Query 5.3.9. SELECT M~1.Geom FROM~Expland( SELECT Geom from M~apTable ) as

M1 WHERE area( M1.Geom ) > 1000

We can also use the Expand operator in correlated subqueries to identify maps that

contain regions that satisfy some predicate. For example, to return all maps that contain

a region with an area greater than one thousand square miles (as in MQL Query 5.2.7) a
user could write:

Query 5.3.10. SELECT M~1.Geom FROM~ M~apTable M~1 WHERE EXISTS ( SELECT

M2. Geom FROM~ Expland ( M~1.Geom ) as MS2 WHERE area( M2. Geom ) > 1000 )









CHAPTER 6
THE DISCRETE MODEL OF SPATIAL PARTITIONS

The abstract model of spatial partitions maps each point in the plane to a specific

label. However, computers provide only a finite resolution for the representation of data

which is not adequate for the explicit representation of abstract spatial partitions. In

order to represent maps in computers, a discrete map model is required that preserves

the properties of spatial partitions while providing a finite representation that is suitable

for storage and manipulation in computers. In this section, we provide a Il'u./', model of

spatial partitions, which is a graph theoretic, discrete model of spatial partitions. Note

that there is some ambiguity among graph terms in the literature, especially concerning

terms indicating graphs that are allowed to contain loops and multiple edges between

pairs of vertices. We begin this section by first providing an overview of graph terms and

definitions that we use to develop our model.

6.1 Definitions from Graph Theory

In graph theory, a graph is a pair G = (V, E) of disjoint sets such that V is a set of

vertices and E CV xV is a set of vertex pairs indicating edges between vertices. We

denote the sets of vertices and edges for a given graph g as V(g) and E(g), respectively.

A I,,l.:llrap~h is a pair GM/ = (V, E) of cl;i~ 10~ sets with a mapping E V xV allowing

a multigraph to have multiple edges between a given pair of vertices. A loop in a graph

is an edge that has a single vertex as both of its endpoints. A multigraph with loops is a

pseudomlrl1, and is defined as a pair Gp = (V, E) with a mapping E V x V. Finally,

a nodeless pseudoynrl // is a pseudograph that (possibly) contains edges that form loops

that connect no vertices and that intersect no other edges or vertices. We define a nodeless

pseudograph as a triple GN = (V, E, NV) (where NV is the set of nodeless edges) with

mapping E V x V.

A path is a non-empty graph P = (V, E) such that V = {vl,...,v,}, E=

{vlv2, v, -v,} and all I are distinct. Given a graph g = (V, E), a path of g is a










graph p = (V,, E,) where V, C V(g) A E, C E(g) where p satisfies the definition of a

path. A I ,;;.1 is a path whose first and last vertices are identical, defined by a non-empty

graph C = (V, E) such that V = {vl, ..., v,}, E = {vlv2, v,l U1Where all I are

distinct and n > 3. Given a graph g = (V, E), a cycle of g is a graph c = (Ve, Ec) where

Vc C V(g) A Ec C E(G) where c satisfies the definition of a cycle. The length of a

cycle is the number of its edges. A I3...1;,1 i..nal arc is the union of finitely many straight line

segments embedded into the plane and is homeomorphic to the closed unit interval [0, 1].

We use the terms arc and polygonal arc interchangeably.

A graph is planar if it can be embedded in the plane such that no two edges intersect.

A particular drawing of a graph is an embedding of the graph. A particular planar graph

can have multiple embeddingfs in the plane such that edges in each embedding are drawn

differently. A particular embedding of a planar graph is a plane il'.,4.1, Formally, a plane

graph is a pair (V, E) such that VC R 2, eVery edge is an arc between two vertices, the

interior of an edge contains no vertex, and no two edges intersect except at their vertices.

A plane graph g may contain cycles. We w?-a cycle c in plane graph g is minimal if there

does not exist a path in g that splits the pakei-on induced by c into two pieces. We use the

notation C(g) to indicate the set of minimal cycles in the graph g.

6.2 Representing Spatial Partitions as Graphs

In this section, we define the type of spatial partition Ilrpl'l' that is able to model

both the structural and labelling properties of spatial partitions in a graph. We first

attempt to define a graph based on the vertex and edge structure of a partition, but show

that this is not sufficient because the labels of the partition are not explicitly represented

in such a graph. We then define a new type of graph that is capable of representing both

the structural and labelling properties of a spatial partition and that is defined based on

discrete concepts. We then show how such a graph can be obtained from a given spatial

partition.










Recall that in the abstract model of spatial partitions, we can identify a graph

structure based on the boundary of a partition xr. Specifically, we observe that we can

identify v(xr), the set of points that are vertices, and e(xr), the set of point sets belonging

to edges of a partition. However, we cannot simply assign the vertices and edges to a pair

(V, E) in order to achieve a graph representation of xr since it is possible for nodeless edges

to be present in e(xr). For example, the boundary of the rightmost face of region ,4 in

Figure :3-1 is composed of two nodeless edges; these edges are nodeless because the label

of every point they contain is a set containing two attributes (i.e., no point in the edge

satisfies the definition of a vertex in a partition). Therefore, we must use a triple (V, E, NV)

consisting of the sets of vertices, edges, and nodeless edges to represent a partition as a

graph. Deriving the set V front a partition xr is trivial because we can directly identify

the set of vertex points v(xr). Definition :3 defines the set of all edges of xr as e(xr); thus, it

does not differentiate between edges and nodeless edges. It follows that the set of nodeless

edges of a partition, NV, is a subset of e(xr), but we cannot identify NV by simply examining

labels. Intuitively, the label of a nodeless edge should not form a subset of the label of any

vertex. However, in Figure :3-1, the label of the boundary of the upper order of the left

face of region A and the labels of both orders of the right face of region ,4 are the same.

Therefore, we cannot necessarily differentiate nodeless edges front edges by comparing

labels. We can circumvent this problem if we can differentiate identically labeled edges

front different faces of the same region. This can he achieved through the r. ~it.. operation.

Each nodeless edge in xr can he identified as an edge in a = r. ~i,.(xr) whose label does not

form a subset of any vertex label (a vertex lies on an edge in the refinement of a partition

iff the edge label is a subset of the vertex label). Note that the refine operation does not

alter the edge structure of a partition, only its labels. Therefore, we can use a = r. ~i,.(xr)

to identify the set of nodeless edges NV in xr by ?iing that each edge in a whose label

does not form a subset of any vertex label in a is in the set NV. The edges of xr can then

he calculated as E = e(xr) NV. Figure 6-1A shows the refinement of the partition in





A B

Figure 6-1. A spatial partition and its corresponding SSPG. A) The refinement of the
partition in Figure 3-1A. B) The SSPG corresponding to Figure A. Nodeless
edges are dashed.


Figure 3-1. Figure 6-1B shows the graph representation of the partition in Figure 6-1A

obtained by the method described above (nodeless edges are dashed). Because deriving a

graph from a partition in this fashion results in a graph that exactly represents the edge

structure of the partition from which it is derived, we call this type of graph a structural

.spatial partition Il'arll, (SSPG), and define it formally as follows:

Definition 10. Given t .spretial partition xr of ';,I'.11 A and its r. it.. i,. a. = rola.~(xr). we

construct

E = (a) N

Nv = {ne E (a)|21c E v(a) : e(n) C a(v)}
The SSPG is able to represent the structural aspects of a spatial partition, but it

does not maintain the labelling information of the partition. Because a SSPG is defined

based on a given partition, the spatial mapping for the partition is known. Therefore, the

label for any edge or vertex in a SSPG can he determined through the associated spatial

mapping, but this is insufficient for our purposes as we require an explicit representation

of labels. However, the SSPG has the property that it is a plane nodeless p~seudomlr y./

(PNP) :

Theorem 2. Given a partition xr of ';i'i'. 24 its corresponding SSPG is a plane nodeless










Proof. The definition of a nodeless graph states that a nodeless graph may contain

nodeless edges; therefore, an SSPG is nodeless by definition. Similarly, the definition of a

pseudograph states that the graph may contain multiple edges between the same vertices

and loops. An SSPG is therefore a pseudograph by definition because it does not exclude

such features. Now we must prove that a SSPG is a plane graph. The edges of an SSPG

are taken directly from a spatial partition, which is embedded in RW2, indicating that the

SSPG is an embedded graph. By the definition of spatial partitions, an edge in a partition

is a border defined by a one-dimensional point set consisting of points mapped to a single

label. Furthermore, this label is derived from the regions which the border separates.

Assume that there exists two borders in a spatial partition that cross, which implies that

the SSPG for this partition will contain two edges that intersect. In order for this to

occur, these edges must separate regions that overlap, which violates the definition of

spatial partitions. Therefore, a spatial partition cannot contain two borders that intersect,

except at endpoints. Because the edges of an SSPG are taken directly from a spatial

partition, then no two edges of an SSPG can intersect. Thus, the SSPG is a plane nodeless

pseudograph. O

Although an SSPG can be easily obtained from a spatial partition, using a SSPG to

model spatial partitions is inadequate for two reasons. First, spatial partitions depend

on the concept of labels, so the graph representation of a partition must include a label

representation. The SSPG does not implicitly model the labels of regions, edges, or

vertices; rather, it depends on the existence of a spatial mapping. Second, the edges in

the SSPG are taken directly from a spatial partition, which is defined on the concept of

infinite point sets that we cannot directly represent discretely. Despite these drawbacks,

the SSPG does have the nice property that because a SSPG is defined based on a given

spatial partition, we know that any given SSPG is valid in the sense that it represents

a valid spatial partition. Therefore, we proceed in two phases: we first define a type of

graph that is capable of discretely representing the structural properties, and explicitly










representing the labeling properties, of spatial partitions. We then show how we can

derive graphs of this type from spatial partitions. This allows us to define a valid graph

representation of any given spatial partition.

It follows from Theorem 2 that an embedded graph that models a spatial partition

such that its edges and vertices correspond to the partition's edges and vertices,

respectively, must be a PNP. However, a PNP does not model the labeling of spatial

partitions. In order to model labels in a graph, we must associate labels with some feature

in a graph. In spatial partitions, the labels of boundaries can be derived from the labels

of the regions they represent. Thus, it is possible to derive all edge and vertex labels in a

partition from the region labels. Therefore, we choose to associate labels in a graph with

features that are analogous to regions in spatial partitions. We are tempted to associate

labels with minimum cycles in a graph representing a spatial partition, however, this is

not able to accurately model situations in which a region in the spatial partition contains

another region such that the boundaries of the regions are disjoint (e.g., the region labeled

A2 and the hole it contains in Figure 6-1A). Instead, we associate labels with minimum

I4...1;;. ;.1. I- (j!PCs) in graphs representing partitions. A minimum polycycle in a PNP G is

a set of minimum cycles consisting of a minimum cycle co (the outer cycle), and all other

minimum cycles in G that lie within co, and not within any other minimum cycle. Note

that a minimum cycle of a plane graph induces a region in the plane defined by a Jordan

curve. Therefore, we can differentiate between the interior, boundary, and exterior of such

a region. We denote the region induced in the plane by the minimum cycle C of plane

graph G as R(C). We now formally define minimum polycycles:

Definition 11. Given a plane nodeless pseudomlrl1, G, a minimum polycycle of G is a

,pay./, M~PC = (V, E, NV where V CV G, E CE G, NCN c V and C M~PC) CC ),

containing an outer cycle co E C(M~PC) and zero or more inner cycles cl,..., c, E

C(M~PC) such that:










(i) Vv E V : (3d E C(M~PC)|v e V(d))

(ii) Ve E E : (3d E C(M~PC)l |E E(d))

(iii) Vu E NV: (3d E C(M~PC)|n E NV(d))

(iv) Vci / co E C(M~PC) : 8R(c,) C (8R(co) U R(co)o)

(v) 3cj, Ck~ E C(M~PC) |cj / co A Ck Co A Cj Ck9

A 8R(cj) C (8R(Ck)U R(Ck o

(vi) $d E C(G)|(8R(d) c (8R(co) U R(co)o)) A ~(d E C(M~PC))

A (Vci / co E C(M~PC) : n(8R(d) C (8R(c )U R(ce)o)
Thus, a MPC induces a region in the plane that may contain holes defined by the

minimum cycles that lie in the interior of the outer cycle. Furthermore, by associating

labels with MPCs in a graph representing a spatial partition, we do not need to explicitly

represent the labels of edges and vertices in the graph since they can be derived by simply

finding all MPCs that an edge or vertex participates in. We denote the set of all MPCs for

a PNP G as M~C(G).

The second problem with SSPGs is that the edges are defined as infinite point sets.

We require a discrete representation of edges. Therefore, in addition to assigning labels

to MPCs, we define our new type of graph such that its edges are arcs consisting of a

finite number of straight line segments. We define the labeled plane nodeless pseudov'-'rl/*

(LPNP) as a PNP with labeled MPCs, denoted faces, and edges modeled as arcs as
follows :

Definition 12. Given an alphabet of labels EL, a labeled plane nodeless pseudograph

is 1, I;, by the four-tup~le LPNP = (V, E, NV, F) consisting of a set of vertices, a set of

arcs forming edges between vertices, a set of arc loops forming nodeless edges, and a set of

faces, with:










V c R2

E C V xVx (RW2) nhr nAT iS Hnite and echC edge iS GR aTC GTCrS

with endp~oints in V and segment endp~oints in RW2

NV C (RW2) nhr nAT iS Hnite (nOdeeSS aTC lOOpS)

F c {(le E L, me M C((V, E, N))))}
Recall that in the definition of spatial partitions, an unbounded face is explicitly

represented with an empty label corresponding to the exterior of the partition. We do

not explicitly model this unbounded face in the LPNP for two reasons: (i) we cannot

guarantee that the edges incident to the unbounded face of a LPNP will form a connected

graph, and (ii) if the edges incident to the unbounded face do form a connected graph, we

cannot guarantee that it will be a cycle. However, we can determine if an edge in a LPNP

is incident to the unbounded face if it participates in only a single MPC. This follows from

the fact that each edge separates two regions in a partition. Because all bounded faces are

modeled as MPCs in a LPNP, an edge that participates in only a single face must separate

a MPC and the unbounded face.

The LPNP allows us to discretely model a labeled graph structure, but we have

not yet discussed how we can obtain a LPNP for a given spatial partition. Note that

because the edges of a LPNP are defined as arcs, they cannot directly represent edges

from a partition. Instead, each edge in a LPNP is an approximation of an edge in its

corresponding spatial partition. Therefore, we define the approximation function a~ that

takes an edge from a partition and returns an arc which approximates that edge. Given

a spatial partition xr of type A and an edge approximation function a~, we derive the

corresponding LPNP in a similar manner as we derived the SSPG from a partition. The

set of vertices in the LPNP is equivalent to v(xr). In order to calculate the nodeless edges,

we consider the refinement o- = re ~in.(xr). Nodeless edges are then identified as all edges

in o- whose label is not a subset of any vertex label. The set of edges is then difference

of e(xr) and the set of nodeless edges. Finally, each labeled MPC consists of the set of









El~V = {V1, V2 }
E = {E1, E2, E3 }
vi V2 = { NV1, NV2 }
E2 N2F= {(A, ({V1, V2}, {E1, E2}, 0)),
(A, (0, 0, {NV1, NV2})),
E3 (B, {V1, V2}, {E2, E3}, 0)),


Figure 6-2. A labeled plane nodeless pseudograph for the partition in Figure 3-1. The
edges and vertices are marked so that the sets of vertices, edges, nodeless
edges, and faces can be expressed more easily.


approximations of the edges surrounding each region in a along with the label of the

corresponding face in xr. Given an edge e, we use the notation Ve(e) to indicate the set of

vertices that e connects. Figure 6-2 depicts the LPNP for the partition shown in Figfure

,3-1.

Definition 13. Given a spatial partition xr of type A, edge ap~prox~imation function a~, and

a = relin. (x), we derive a LPNVP = (V, E, NV,F) from x as follows:






Em = {c( E~ al((e)| E 1Vo) A cBrAae)EE




Nm = {a~(u)|n E w(o-) An B r A a~(u) E N}


Vm = Ueem Ve(e)
Note that it is possible to approximate edges in a partition in multiple v-wsi~. Thus, a

single spatial partition may have multiple LPNPs that represent it.

In the definition of LPNPs, no restrictions are placed on the labels of MPCs.

Therefore, it is possible for an labeled graph to fit the definition of an LPNP, but be

labeled in such a way that violates the definition of spatial partitions. In other words,

a LPNP may be labeled such that no spatial partition exists from which the LPNP can









be derived. A simple example of this is a LPNP containing two MPCs that have the

same label and share an edge. Because edges only separate regions with different labels

in a partition, this LPNP can not be derived from any valid spatial partition. Thus, the

set of all valid LPNPs is larger than the set of LPNPs that can be derived from some

spatial partition. We define a LPNP that can be derived some spatial partition as a spatial

partition Il'~rll, (SPG).

Definition 14. A spatial partition graph G is a labeled plane nodeless pseudograph such

that there exists some valid partition from which G can be derived.

6.3 Properties of Spatial Partition Graphs

In the previous section, we defined the type of spatial partition graphs and showed

how a SPG can be derived from a given spatial partition. However, we currently define a

SPG as being valid only if it can be derived from a valid spatial partition. Given a labeled

graph in the absence of a spatial partition, we currently cannot determine if the graph is

a SPG. In this section, we discuss the properties of SPGs such that we can determine if a

SPG is valid by examining its structure and labels.

Given a LPNP in the absence of a source partition from which it can be derived,

we must ensure that structural and labelling properties of the LPNP are consistent with

the properties of spatial partitions. To achieve this, we examine the properties of spatial

partitions, defined by Definition 2 and Definition 3, and show how these properties are

expressed in SPGs derived from spatial partitions. We then define the properties of SPGs

and show that any LPNP that satisfies these properties is a SPG.

Recall that a SSPG is a PNP. It follows from Theorem 2 that any graph that models

the edges of a partition as graph edges and vertices of a partition as graph vertices

must be a PNP. Therefore, a graph cannot be a SPG if it is not a PNP. This is already

expressed indirectly by the definition of SPGs as LPNPs.

Definition 2 formally defines constraints on spatial mappings that specify the type of

partitions. These constraints indicate that (i) the regions in a partition are regular open










point sets, and (ii) the borders separate uniquely labeled regions and carry the labels of all

.Il1i Il:ent regions. From these properties of partitions, we can derive properties of SPGs.

By (i), we infer that all edges and vertices in a SPG must be part of a MPC. If an edge

is not part of a MPC, then the edge does not separate two regions. Instead, it extends

either into the interior of a MPC or into the unbounded face of the SPG, forming a cut

in the polygon induced by the MPC or the unbounded face. If a vertex exists that is not

part of a MPC, then it is either a lone vertex with no edges emanating from it, or it is

part of a sequence of edges that are not part of a MPC. In the first case, the vertex either

exists within the region induced by a MPC or the unbounded face of the LPNP, forming a

puncture. In the second case, the vertex exists in a sequence of edges that is not part of a

MPC, which we have already determined to be invalid.

By the second property of spatial partitions (ii), we infer that edges must separate

uniquely labeled MPCs. Therefore, there cannot be an edge in an LPNP that participates

in two MPCs with the same label. Fut hermore, every region in a partition must be

labeled. It follows that every MPC in a SPG must be labeled. Because the unbounded

face is not explicitly labeled in a SPG, one special case exists: a MPC forming a hole in a

SPG (i.e., labeled with 1) cannot share an edge with the unbounded face, as this would

result in an edge separating two regions with the same label.

Definition 3 further identifies properties of spatial partitions. According to this

definition, edges in spatial partitions ah-- .1-< have two labels, and vertices ahr-l- .- have

three or more labels. Recall that in LPNPs, the unbounded face of the graph is not

explicitly labeled. Therefore, in a SPG, all edges must participate in either one or two

MPCs. Edges incident to the unbounded face of the graph will participate in only one

MPC. The requirement that vertices have three or more labels in a spatial partition

indicates that at a vertex, at least three regions meet. It follows that in a SPG, each

vertex has at least a degree of three. Furthermore, because the unbounded face is not

explicitly labeled, vertices must have at least two labels in a SPG (i.e., a vertex must









participate in at least two MPCs). We summarize the properties of SPGs and show that

any LPNP that satisfies these properties is a SPG:


Definit


;ion 15. An SPG G has the following properties:
(i) G is a plane nodeless pseudov'-'rll, (Theorem 2)

(ii) Ve E E(G) U NV(G), B(1,X) E F(G)|e E E(X) U NV(X) (.Ii.o ()

(iii) Vv E V(G), B(1, X) E F(G)I |E V(X) (.Ii.o ()

(iv) Vv E V(G) : degree(v) > 3(D .1. )

(v) Ve E E(G) U NV(G) :

1 < | {(1, X) E F(G)|e E E(X) U N(X)}| < 2(D .1. )

(vi) VlX) 1,X)EFG|1=1

(}]el E E(X1) U N(X1), e2 E E(X2) U N(X2) 61 = 62 (. nl.o i)

(vii) Vm E M~C(G),3f = (1,X) E F(G)|m = X(D nl. (i)

(viii) Ve E E(G)UN I(G) |

| {(1, X) E F(G)|e E E(X) U NV(X)}| = 1 : 1 / 1} D nl.)i)
em 3. Any LPNP that st/:I. 4 the properties in D. 60.1...0i 15 is a SPG.


Theory


Proof. The properties listed in Definition 15 indicate how the properties of spatial

partitions are expressed in SPGs. From Theorem 2, we know that a valid SPG must be

a PNP. Definition 2(i) states that all regions in a partition must be regular open sets.

Because the faces in a SPG are analogous to regions in a spatial partition, this means that

all edges and vertices must belong to some face, otherwise, they form a puncture or cut

in some face of the SPG. Definition 15(ii) and Definition 15(iii) express this requirement.

Definition 2(ii) states that borders in a partition between regions carry the labels of both

regions. This implies that an edge in a spatial partition separates regions with different

labels, and that every region in a spatial partition has a label. Definition 15(vi) and

Definition 15(vii) express this by stating that if an edge participates in two faces of a SPG,

those faces have different labels, and that every MPC in a SPG is a labeled face of the

SPG. Because the unbounded face is not labeled, we must explicitly state that no edge










that participates in a cycle forming a hole can have only a single label, as this implies that

an edge is separating two regions with the I label (Definition 15(viii)). Definition 3 states

that edges in a partition carry two region labels, and that vertices carry three or more

region labels. Because the unbounded face is not labeled in a SPG, we cannot directly

impose these properties on a SPG. Instead, we observe that the number of region labels on

a vertex in a partition indicates a minimum number of regions that meet at that vertex.

Therefore, we can express this property in SPG terms by stating that vertices in a SPG

must have degree of at least three (Definition 15(iv)). The edge constraint from Definition

3 can be specified in terms of a SPG by the property that an edge must participate in

exactly one or two faces, indicating that the edge will have exactly one or two labels

(Definition 15(v)). Therefore, all properties of partitions are expressed in terms of SPGs in

Definition 15, and any LPNP that satisfies these properties is a SPG. O

We now have the ability to either derive a valid SPG from a spatial partition, or

verify that a SPG is valid in the absence of a spatial partition from which it can be

derived. Finally, we show that given a valid SPG, we can directly construct a valid spatial

partition that exactly models the SPG's spatial structure and labels. Recall that a spatial

partition is defined by a spatial mapping that maps points to labels and satisfies certain

properties. Therefore, to construct a partition from a SPG, we must be able to derive

a spatial mapping from a SPG. We can construct such a mapping based on the labeled

MCPs of a SPG. Each MCP of a SPG induces a pI~uk-_on in the plane that is associated

with a label. Each of these polygons is a spatial region, and is defined by its boundary,

which separates the interior of the pI~uk-_on from its exterior. Therefore, we can identify

the interior, boundary, and exterior of such a polygon. We use the notation R(X) to

denote the polygon induced in the plane by MCP X. A point that falls into the interior

a polygon can therefore be mapped directly to that pI~uk-_on's label. The labels of points

belonging to edges in the SPG are slightly more difficult to handle. Each point belonging

to an edge is mapped to the labels of each face in which the edge participates. If an edge









happens to be incident to the unbounded face (it is an edge participating in a single
minimum cycle), it also is mapped to the I label. Similarly, each vertex is mapped to the

labels of each cycle in which it participates. If a vertex is incident to the unbounded face,

it is also mapped to the I label. A vertex is incident to the unbounded face if and only

if it is the endpoint of an edge that is incident to the unbounded face. In order to define

this mapping, we first provide a notation to distinguish between edges and vertices that

are incident to the unbounded face, and those that are not. We then show how to derive a

spatial partition from a SPG:

Definition 16. Given a SPG G, we distinguish two sets of edges: the set containing edges

incident to the unbounded face, denoted El, and the set containing edges not incident

to the unbounded face, denoted Eb. Likewise, we distinguish two sets of vertices: the set

containing vertices incident to the unbounded face, denoted VI, and the set containing

vertices not incident to the unbounded face, denoted Vb. TheSe SetS aTC I. I;: u s fol G OOWS:
EI(G) = {e E E(G) U NV(G)| | {(1, X) E F(G)|e E E(X) U NV(X)}| = 1}

Eb(G) = (E(G) U NV(G)) E (G)

Vi(G) = {v e V(G)|(3e E Ellv E Ve(e))}

Vb(G) = V(G) VI(G)
Definition 17. Given a SPG G, we can dir, .-ile construct a spatial partition xr of type A

as follows:
A={Il|(, X) E F(G)} U {1}
{l|(1, X) E F(G) Ap e R(X)o} if 3(1, X) E F(G)|p E R(X)o (1)
{1} if $(1, X) E F(G)|I
p E R(X)o U aR(X) (2)
(p) = < {l|(1, X) E F(G) A pe OR(X)} if (3(1, X) E F(G)|p E OR(X))

A ($e E E(G)|p E e) (3)
{l|(1, X) E F(G) A pe OR(X)} U {1} if (3(1, X) E F(G)|p E OR(X))
A (3e E E (G)|p E e) (4)









In Definition 17, the type of a spatial partition derived from a SPG consists of the set

of labels of faces in the SPG. The mapping is then defined by finding the labels of all faces

a point participates in. If a point p lies in the interior of a face (1), then the label of that

point will be the label of the face. If p does not lie in the interior or boundary of any face

(2), it maps to the label 1. If p lies on a boundary that is not incident to the unbounded

face (3), it is mapped to the set of labels of all faces that include p in its boundary. Note

that because face boundaries include vertex points, this case handles the mapping of

both edge and vertex points. Similarly, if p lies on a face boundary that is incident to the

unbounded face (4), then p is mapped to the set of labels from all faces which include p, as

well as the label 1.










CHAPTER 7
THE IMPLEMENTATION MODEL OF SPATIAL PARTITIONS

At this point, we have an abstract model of Map Algebra that precisely defines the

seniantics of maps and their operations and predicates. Furthermore, we have shown how

to represent maps in a discrete manner such that they maintain the properties of the

abstract model. In this chapter, we provide an intplenientation model of Map Algebra

consisting of a data model for maps and algorithms for computing nmap operations.

Furthermore, we show how operations over maps can he combined to form new nmap

operations. We then describe a prototype intplenientation of Map Algebra and perform a

performance comparison of the Map Algebra intplenientation with an existing GIS.

7. 1 Map2D: an Implementation Model of Map Algebra

The intplenientation model of nmap Algebra takes into account the abstract and

discrete models of spatial partitions, as well as the user view of maps in databases

presented in OsI Ilpter 5. Because the goal of this thesis is to incorporate maps as first-class

citizens in databases, our intplenientation model is designed to intplenient Map Algebra

in a database. Therefore, the data model and algorithms assume the existence of a

database that can support a type called Irl q:D either natively or through some extension

mechanism.

7.1.1 A Data Model For Representing Spatial Partitions

The data model for the intplenientation model of Map Algebra follows the ideas

presented in OsI Ilpter 5 for a data model of maps in databases. Recall that this model is

centered around the concept of storing nmap labels in a traditional database table so that

traditional SQL queries can he posed over them, while the nmap geometry is stored in a

database colunin type. We follow the same approach in our intplenientation model of Map

Algebra. In order to explain the concepts of the intplenientation model more clearly, we

will refer the nmap shown in Figure 7-1 throughout the following discussion.

















Figure 7-1. A map showing an industrial and commercial zone.


The label portion of a map is implemented nearly identically to the explanation given

in C'! Ilpter 5. The labels of a map are stored as tuples in a database table. We impose

the restriction that a table containing map labels must contain a column named ,n y...o ~_.:.1

of type integer that will be used to associate a label with a region contained in a map

geometry. The advantage of this approach is that the label table can be used in standard

SQL queries without any SQL extensions. Also, labels can be manipulated with standard

SQL, and no special purpose label operations must be introduced.

The geometry portion of a map is more complex than the label portion. Our goal is

to incorporate the geometry portion of a map directly as a column type in a database.

Therefore, we must implement the geometry portion as a single object that can be

incorporated into a DBMS through extension mechanisms or through extending the

DBMS code itself. There are several considerations that must be addressed in the

design of the geometry: (i) the map geometry must support map operations that will

be performed over it, and (ii) the concept of regions must be maintained in the geometry

and map regions must be able to be identified, associated with labels in a label table, and

reconstructed.

In order to address the first concern, we make the observation that nearly all map

operations can be expressed in terms of the intersect and relabel operations presented in

the abstract model of Map Algebra [65, 83, 87]. Although the relabel operation can have

geometric consequences in a map, it is primarily an operation over labels. The intersect

operation, however, is primarily a geometric operation that has consequences regarding the

labels of a map. Because geometric operations tend to be more computationally intensive









than label operations, we focus the design of the map geometry on the requirements of

the intersect operation. In C'!s Ilter 2, we showed that geometric operations are computed

optimally by using a plane sweep algorithm. Thus, a plane sweep algorithm is an ideal

choice for implementing the intersect operation, and we will design our data model based

on the requirements for a plane sweep algorithm.

The plane sweep algorithm requires a specific input structure for geometric objects,

specifically, geometric objects are required to be represented as a sequence of ha~lf-, ,it? t.14

ordered in inrTif- ~iI,,r ,. order. For regions, this is achieved as follows: we define the type

inif,irT? -I,, ,:l = {(s, d)|s E segment, d E bool} where -.9;;;.;.? is the type incorporating

all straight line segments bounded by two points p and q, and a point is a coordinate

(x, y). A halfsegment is a hybrid between a point and a segment since it has features

of both geometric structures. For a halfsegment h = (s, d), if d is true (false), the

smaller (greater) endpoint of a is the dominating point of h, and & is called a left (right)

inrt if,,ite ,./ Hence, each segment s is mapped to two halfsegments (s, true) and (s, false).

Furthermore, halfsegments are typically annotated with an interior-above flag, which

indicates whether the interior of the region lies above or below the halfsegfment. In

addition to the use of halfsegments, the representation of a region object requires an

order relation on halfsegments. Let dp be a function which yields the dominating point

of a halfsegment. For two distinct halfsegments hi = (sl, dr) and h2 = s2, d2) With a

common endpoint p, let a( be the enclosed angle such that Oo < a( < 1800. Let a predicate

rot(hl, h2) be true if, and only if, hi can be rotated around p through a( to overlap h2 ill a

counterclockwise direction. We define a complete order on halfsegments as:

hi < h&2

dp3(hl) < dp(h2) V (1)

(d3(hl) = dp(h2) 1 2 ~lAd) V (2a)

(di = d2 A rTO@ 1, 2)) V (2b)

(dl = d2 A COllinet@81 82~) A len 81) < lenCH)) 82

















Figure 7-2. A complex region object with each segment labeled.


Since a segment can be substituted by two halfsegments, a region object can be

implemented as an ordered sequence (array) of halfsegments. As an example, Figure 7-2

shows a complex region object (with a single face containing a hole) whose segments are

laeldas et& as ru) n &=(as, false) denote the left and right halfsegments of

a segment si respectively. The ordered sequence of halfsegments for this complex region is



Although this definition of halfsegfments is sufficient for computing geometric

operations, maps must take into account the labels of regions in addition to geometric

information. Therefore, we modify the halfsegment definition to include region labels

instead of an interior-above flag. Therefore, each halfsegment will contain two region

labels represented as integers, the label for the region that lies above the halfsegment, and

the label for the region that lies below the halfsegfment. Thus, we have intlT .I,it te =

{(s, a, b, d)|s a segment, as Z be Z d E bool}. We assume that the region labels

correspond to regions in a label table identified by a region_id column, or to some specified

value indicating the exterior of a map.

Therefore, we represent a map geometry as a sequence of ordered halfsegments, each

labeled with the region that lies above the halfsegfment, and the region that lies below

the halfsegment. Note that the definition of spatial partition graphs defines a SPG by its

edges and nodeless edges, which in turn are defined as connected sequences of straight line

segments. The halfsegments in the implementation model of spatial partitions represent

these straight line segments in a SPG. Therefore, the geometry of a map represented as

a SPG and a map represented in the implementation model of spatial partitions in the









MapTable Mapl Attri buteTable S4
ID: int Geom: map2D region_id: int zone: str 5
1 Industrial 1 2
1 ~~~2 Commercial S 3S


A B

Figure 7-3. Two different views of a map. A) The map represented in the implementation
model of Map Algebra. B) The map with its segments labeled.


same embedding space are identical. Furthermore, it is possible, based on region labels, to

reconstruct an SPG given a map represented in the implementation data model of Map

Algebra. This means that the properties of spatial partitions defined over SPGs can be

checked and enforced at the implementation level.

As an example of the implementation data model of Map Algebra, consider the map

shown in Figure 7-1. If we have a database that is aware of the column type mapE2D that

implements the geometry portion of a map, as we have shown, then the map in Figure

7-1 could be stored in the database as shown in Figure 7-3A. If we label the segments of

the map as shown in Figure 7-3B and we assume a region label of 0 for the exterior, then

the halfsegments in halfsegment order would be: (h, 1, 0), (h ,0 ) h,1 ) h,1 )
(h ,, 2, 0), (hE, 0, 1), (hi, 1, 2), (h 0, 2), (h 0, 2), (hi, 2, 0) where h( Sj k re n

hi = (Si, j, k, false) for segment Si.

7.1.2 Algorithms for Map Operations

In C'!s Ilter 2, we saw that research efforts have provided algorithms to compute

spatial operations over map geometries. In this section, we provide algorithms for

the three fundamental map operations of intersect, relabel, and re ~in based on the

implementation data model of Map Algebra. We then show how these operations can be

combined to form new operations. Note that in the literature, the intersect operation is

frequently referred to as or el r;,













SIntersee tion


Figure 7-4. The result of the intersect operation applied to two maps.


7.1.2.1 Intersect

The intersect operation and its variants have received significant attention in

database, computational geometry, and GIS literature. Our implementation follows

the concepts presented in these papers, but is tailored to our particular data model. Recall

that the intersect operation, as defined in the abstract model, takes two maps and returns

a third such that each point in the third map carries the label assigned to each identical

point in the argument maps. Figure 7-4 depicts two sample maps and the result of the

intersect operation applied to them.

In essence, our intersection algorithm is identical to a traditional plane sweep

algorithm in that it traverses the argument maps in halfsegfment order and computes

the intersections of line segments, and the resulting regions in the result map. The main

difference in our algorithm to traditional plane sweep algorithms is the handling of region

labels. Recall that regions in the result of an intersection algorithm will carry labels from

both argument maps. Therefore, we must determine the labels of all regions in the result

map in addition to computing the geometric intersection of the argument maps. We

achieve this in two steps. First, as the plane sweep algorithm progresses, we mark each

halfsegment with the labels of all regions whose interiors directly order the halfsegment,

or contain the halfsegment. We call this label aggregation. For example, Figure 7-5 shows

two maps represented in the implementation model of 1\ap Algebra, complete with region





0
2~2
0 210
02 2
0


A B



01

1 1,2 2, 0
0 1 1 1,21212 22
1 100
10




Figure 7-5. Aggregating map labels in an intersect operation. A) The first argument map.
B) The second argument map. C) The the result of .l__-oegating the argument
maps' labels during an intersect operation.


labels on the segments. The third map shows the ..-:-o negated labels as a result of label

.I -_ regfation during an intersection. Note that segments that lie in the interior of a region

from one of the original maps will have the label of that region on both sides of the

halfsegfment .

Aggregated labels provide the information necessary to identify the labels from

the original regions that should be applied to a region in the result of an intersection

of two maps. However, the halfsegment definition used by the implementation model of

Map Algebra only allows two integers to be used as region labels. Therefore, in addition

to label .I regfation, we use a label I,,rl '1 :':(. which maps .I__regfated labels to a new

label value that uniquely identifies the region. It is straightforward to implement such a

mapping using an AVL tree with the search key consisting of the pair of labels from the

original maps. Therefore, each region in the result map that consists of an overlapping

portion of regions from both argument maps will have an .I__-oegfate label, and that

.I_ egfate label will be mapped to a new region label in the result. As the plane sweep










progresses during an intersect algorithm, the result map is annotated with the result of the

label mapping, not the .I__-oegated labels.

The final problem that must be addressed is how to determine the ..-:-o negate labels.

As the plane sweep algorithm progresses, it maintains a sorted list of halfsegfments called

the status structure that contains all halfsegfments that intersect the sweep line. These

halfsegments are sorted in the order according to where they intersect the sweep line.

If we assume the sweep line is vertical, then the halfsegments are sorted with respect

to the y coordinate of the point where they intersect the sweep line. We assume that

each halfsegfment in the status structure is marked with a Afla indicating which of the

original maps it belongs to. Given this information, we are able to compute the .I__oregate

labels for a halfsegfment based on the halfsegfment below it in the status structure. For

example, assume that one argument map to the intersect operation is called A and the

other B. When a halfsegment h from map A is added to the status structure, we look at

the halfsegment immediately below it in the status structure, halfsegment j. Note that

we look at the halfsegfment below the current one due to the halfsegfment ordering defined

previously (all halfsegments that are less than the current halfsegment will already be

present in the status structure, or will have been processed). If h and j are from different

maps, then we look at the label from j for the region that lies above it. If that region

is the exterior, then it is clear that h does not intersect a region from the opposing map

(again, this is due to the halfsegment ordering). If the above label for j is a region label,

then h lies in the interior of the region bounded by halfsegment j. Therefore, h is marked

with the label of the region above j for both its below and above labels. If halfsegment

h and j are from the same map, then we '"li- any .I__ negated labels from j to h. This is

because both h and j lie in the same region from the opposing map, and thus, should be

.I_ regfated with that region's label.

A special case of label .I_ egation occurs when two halfsegment h and j, respectively

from each argument map, overlap along a line. In this case, the above label from each





I 1 10 1 o 1, 2 3



A B

Figure 7-6. The result of the plane sweep portion of the intersect algorithm for the maps
shown in Figure 7-5. A) The labeled geometry. B) The mapping.


halfsegment is combined, and the below label from each halfsegment is combined to form

the ..-:-o negate label. Because a boundary is present from regions from both maps, then

neither & or j lie in the interior of another region, so no label will be .I_ negated to both

the above and below labels of either halfsegfment.

The result of the plane sweep portion of the intersect algorithm will be a new map in

the implementation model of Map Algebra and a label mapping that maps pairs of labels

from the original maps, to labels in the new map. Thus, given the maps in Figure 7-5A

and Figure 7-5B, the result at this point is shown in Figure 7-6.

Finally, the label table for the new map must be constructed based on the information

from the label tables of the original maps. The new label table contains all columns from

the label table of the original maps, except it will contain only a single region_id column.

Furthermore, each column name will have the integer 1 or 2 appended if it came from the

label table in the first or second argument map to the intersect operation, respectively.

This ensures that no naming conflicts occur.

The last step of the intersect algorithm is to populate the new label table. First, all

labels for regions in the first argument map that have portions that did not intersect any

region from the second map are added to the label table. These regions can be determined

during the plane sweep and kept in a list. Second, the same procedure is done for regions

in the second argument map that contain a portion that does not overlap any region









MaplAttributeTable


Map2AttributeTable


1 region of interest


I


Iture area


A B
Map3AttributeTable
region_id: int description: str description: str
1 region of interest

2 high temperature area

3 region of interest high temperature area



Figure 7-7. The resulting label table from an intersect operation. A) The label table for
the map shown in Figure 7-5A. B) The label table for the map shown in
Figure 7-5B. C) The label table computed as the result of an intersect
operation.


from the first argument map. Note that for these labels, the values in columns from the

opposing map will be given default or empty values. Then, the mapping from .I__ negate

labels to new region labels is used to construct the labels for overlapping regions from the

argument maps. Thus, if the label tables for the maps shown in Figure 7-5A and Figfure

7-5B are assumed to be those shown in Figure 7-7A and Figure 7-7B, the the label table

of their intersection would be the table shown in Figure Figure 7-7C. The algorithms for

these procedures are given in Algorithm 2 and Algorithm 1.

It is known that a sweep line algorithm can run optimally in O( lg n + k) time for

input maps with a total of a segments and k intersections. Furthermore, our algorithm

utilizes a mapping of region labels implemented as an AVL tree. Therefore, we must

take into account the time complexity of adding region labels. In the worst case, every

region from one map can intersect every region from the opposing map. Therefore, for

two maps respectively containing r and a regions, the complexity of computing the

region label mapping is O(rs Ig rs). However, the number of intersecting regions in two

maps tends to be low, especially compared to the number of segments in the maps.

Furthermore, geometric configurations, in practice, typically do not approach such extreme


Sregion_id: int Idescription: str region_id: int Idescription: str


]1 2 high tempera










Algorithm 1: The plane sweep portion of the intersect algorithm.
Input: Two maps M~ and P as defined by the implementation model of Map
Algebra. An empty mapping A of labels from the original maps to labels in
the result map. Empty lists LM/ and LN to hold labels from the original
maps that exist in the result map.
Output: Map Q
1 Initialize sweep line structures. while not end of sweep do
2 if h iS a IC/{ft ,~rT *'iI,,. then
3 Advance sweep line to h. h is the left-most halfsegment yet to be processed;
4 Find j, the halfsegment below h in the status structure;
s if h and j are from different maps then
B Aggregate the above and below labels for h based on j;
7 Update the mapping A if any overlapping regions are detected;
s end
9 Update the list LM/ if no overlapping regions are detected for a label from

1o Update the list LN if no overlapping regions are detected for a label from NV;
11 else
12 If Overlapping regions exists, update h's label based on mapping A;
13 Add h and its corresponding left halfsegfment to Q;
14 end
1s end


cases of many regions overlapping many other regions. We will provide running times

of an implementation of this algorithm over actual spatial data in later sections that

support these claims. Therefore, the running time of this algorithm in the worst case is

O(n Ig n + k + rs Ig rs), with the n Ig n + k terms typically dominating the running time.

7.1.2.2 Relabel

The relabel operation, as defined by the abstract model for maps, takes a map and a

relabeling function which is then used to alter the labels of a map. A relabeling may have

geometric consequences. For instance, relabeling a region to the exterior label effectively

removes a region from a map. Another example is relabeling a region such that its new

label is identical to an .ll11 Il:ent region will merge the two regions, causing any boundaries

that exist between them to disappear.










Algorithm 2: The algorithm to compute the label table for intersecting two maps.
Input: The label tables for two maps MrL and Ps. A mapping A of labels from the
original maps to labels in the result map. Lists LM/ and LN of labels from
the original maps that exist in the result map.
Output: Label table QL
1 Create the label table QL;
2 for each region label in LM/ do
3 COmpute a tuple for QL consistingf of label attributes from LM/ and default
values for attributes from LN;
4 IHSert the new tuple in QL;
s end
a for each region label in LN do
7 Compute a tuple for QL consisting of label attributes from LN and default
values for attributes from LMIr
s Insert the new tuple in QL;
9 end
to for each entry in no~rlrydery( A do
11 The mapping entry consists of region labelS TM/, rrN, and rQ for region labels in
M~, NV, and Q, respectively;
12 COmpute a tuple for QL consistingf of label attributes from LM/ and LN with
region~ids equal to rM/ and rry, respectively;
13 IHSert the new tuple with region_id rQ in QL;
14 end


Fr-om an implementation perspective, definingf a method for a user to create a

relabeling function that can then be passed to an operation is non-trivial. Therefore, we

approach the problem of relabeling from a different perspective. Our approach is to allow

a user to modify a label table for a map, and then run a general relabeling operation that

determines any geometric implications of the modifications to the label table, and updates

the map geometry accordingly. This approach does not require a method of passing a

relabeling function to the relabel operation, while not sacrificing any generality.

As was briefly mentioned in the examples above, the relabeling operation can have

two geometric consequence: (i) labels may be removed from a label table, which implies

that the region with that label has been deleted; and (ii) a label in the label table may

be altered such that it is identical to another label in the label table, meaning that two

regions have been merged into a single region (requiring any shared boundaries between










the regions to be removed). Thus, our relabel operation must he able to detect and enforce

these changes in the map geometry.

The relabel operation consists of two parts, a duplicate label identification part,

and a geometric consistency enforcement part. The duplicate label identification part

identifies labels in the label table that are identical, but that have different regfion~id

values. This is achieved by computing a Cartesian product of a label table with itself, and

then disregarding all tuples that are not identical except for their region_ids. The result is

a relation containing pairs of identical labels that belong to different regions. This relation

is traversed, and a mapping is constructed such that the regfion_id value of duplicate labels

are mapped to the same regfion_id value. Furthermore, a list is constructed of all regfion_id

values that exist in the label table.

Once the mapping of duplicate labels and the list of region_ids in the label table are

constructed, they are used to determine changes to the map geometry. This is achieved

by traversing the halfsegment sequence of the map geometry. For each halfsegment, the

region label for the region above the halfsegfment is checked against the label mapping and

label list. If the region label is not in the label list, then the corresponding label has been

removed from the label table, and the region should no longer exist in the map. Therefore,

the region label for the halfsegment is changed to the exterior label. If the region label is

in the label list, then the mapping is checked. If the label exists in the ]rn lpplinr then it

is changed to the label to which it is mapped. The same procedure is performed for the

label of the region helow the current halfsegment. Finally, once the above and below labels

of the halfsegment have been processed, a final check is performed to ensure that the

above and below labels are not identical. If these labels are identical, then the halfsegment

orders two regions with identical labels, and thus, is removed. Algorithm 3 summarizes

the relabel algorithm.

Given a map with r regions and n halfsegments, it takes O(T2) time to compute the

Cartesian product, since each region has a single label. The mapping of region labels










Algorithm 3: The relabel algorithm.
Input: A map M~ and its corresponding label table LM.r
Output: Map M~ with the geometric changes implied by its label table LM/ applied.
1 Compute the Cartesian product LM/ x LMIr
2 Keep only the tuples in LM/ x LM/ that have different region_ids and identical labels;
3 Create mapping A that maps region~ids for equivalent labels to the same region~id;
4 CTOate liSt V of regfion~ids in LMIr
s for each intlT .I,itr ,./ h in M~ do
a Get the above label a of h;
7 Get the below label b of h;
sif a exists in It .711.t.':,i~ A then
9 Replace ac with Ithe value to which~ it maps;
10 end
11 if a does not exists in list V then
12 Replace a with the exterior label;
13 end
14 if b exists in I't ~l.:,:.l't A then
is Replace b with the value to which it maps;
io end
17 if b does not exists in list V then
Is Replace b with the exterior label;
19 end
20 if a = b then
21 Remove h from M~;
22 end
23 end


can be implemented using an AVL tree, which results in a complexity of O(r Ig r). An

AVL tree can also be used to implement the list of regfion~ids, which then facilitates

searching the list in O(r Ig r). Finally, the halfsegment list must be traversed once,

which takes linear time O(u). Therefore, the total time complexity for this algorithm is

O(n + T2 + r ig r). Because the number of regions in map tends to be small compared to

the number of halfsegments, this algorithm performs well in practice. Furthermore, it is

possible to create specialized relabel algorithms for specific types of relabeling that are

much faster, but this algorithm is general in the sense that it can correct a map geometry

with respect to any modifications a user makes to a label table. This turns out to be










very valuable when using relabel in conjunction with other existing operations in order to

create new operations.

7.1.2.3 Refine

The refine operation, as was defined previously, relabels region faces such that every

region in a map has only a single face. In other words, any regions that consist of multiple

faces in a map will be altered such that each face is a single region in the map after a

refine operation has been performed. In the implementation model of Map Algebra,

this is achieved by altering the label table of a map such that two faces of a region will

have unique labels, and every face of a region in a map will have a unique regionid. We

compute this in two steps. First, the map geometry is modified so that each region face is

identified by a unique regionid. Second, the label table is modified so that every regionid

in the map geometry refers to a unique label in the label table.

The first step of the refine algorithm requires a technique known as I .;. 1. walking.

In essence, given the left most halfsegment of a cycle (i.e., a region face in a map), it

is possible to find each successive halfsegment that makes up the cycle of halfsegments

efficiently. First, we present the algorithm to walk the cycles in a region. We then extend

the method to work on cycles in a map. We then discuss the second part of the refine

operation

Walking Cycles in Regions.

Because this this section deals with regions, we will assume a halfsegment structure

as defined for regions, i.e., a halfsegfment contains a segment, a boolean Afla indicating if

it is a left or right halfsegfment, and a boolean Afla indicating if the interior of the region

lies above or below the halfsegment. Furthermore, we develop this algorithm to determine

the component view of a region. In essence, the algorithm determines which cycles in a

region are outer cycles, which are hole cycles, and to which outer cycle each hole belongs.

It also determines if a region is valid. Although all of these properties are not required for

the cycle walk portion of the refine algorithm, they are none the less useful, so we include










them. We assume that the input to our algorithm is a sequence of ordered halfsegfments.

If the input represents a region, the algorithm returns the region with its cyclic structure

information, otherwise, the algorithm exits with an error message indicating the input

sequence does not form a semantically correct region. We begin by providing a high level

overview of the algorithm and then present the algorithm and provide a discussion of its

details.

In general terms, the algorithm must identify all cycles present in the halfsegment

sequence, and classify each cycle as either an outer cycle or a hole cycle of a particular

face. To accomplish this, each halfsegment is visited once by the algorithm. Note that due

to the definition of the type region, each segment belongs to exactly one cycle. When a

halfsegfment is visited, the algorithm marks the halfsegfment indicating to which face and

cycle it belongs, and whether that cycle is an outer cycle or a hole cycle. The algorithm

does not alter the input when marking halfsegments, rather a parallel array to the input

sequence is used to represent the cycle information. The algorithm visits halfsegments by

stepping through the input list sequentially.

The first halfsegment in the input sequence will ahr-l-w be part of the outer cycle

of a face, due to the definition of complex regions and the halfsegment ordering defined

previously. Therefore, it can be visited and marked correctly. Once a halfsegment has been

visited, it is possible to visit and correctly mark all other halfsegments in the cycle that

it belongs to in a procedure which we denote as the I .;. 1. walk. Thus, all halfsegfments

that form the cycle to which the first halfsegment in the input sequence belongs are then

visited. The algorithm then begins stepping through the remaining halfsegments. The

next unvisited halfsegment encountered will be part of a new cycle. The algorithm then

visits this new halfsegment. The algorithm can deduce whether this halfsegment is an

outer cycle of a new face or a hole in an existing face by examining where the halfsegment

lies in relation to already known cycles. To determine this, we use a plane sweep algorithm

to step through the halfsegfments. Thus, we can take advantage of the plane sweep status









structure to find whether or not the current halfsegment lies in the interior of a previously

visited face. Once the new halfsegment is visited, we perform a cycle walk from it. Then,

the algorithm continues stepping through the input list until it reaches another unvisited

halfsegfment, visits it, and repeats this procedure. The algorithm is shown in Algorithm 4.

To properly describe the algorithm outlined in Algorithm 4, we introduce several

notations. The function info(h) for a given halfsegment h returns its cyclic information,

that is, its owning cycle, and if part of a hole, its owning face. A cycle owns a halfsegment

if the halfsegment is part of the boundary of the cycle, and a face owns a hole if the hole is

inside the face. We define the function NewC;,. 1. (h) to annotate h with a unique identifier

for a new cycle. Let f be a halfsegment belonging to an outer cycle of a face. The function

Owns(h, f) annotates the halfsegment h to indicate that it belongs to a hole in the face

that owns f Finally, we employ the function V/isit () to mark a point p as having been

visited. The function V/isited () is used to verify is point p was marked as visited already.

Points are only marked as visited when a halfsegment with dominating point p has been

visited during the cycle walk. We mark points as being visited in order to identify the

special case of a hole cycle that meets the outer cycle of a face at a point. The function

V/isited(h) is used to verify if halfsegment h has been visited already. A halfsegment has

been visited if it has been annotated with face/hole information. For a halfsegment h, we

can directly compute its corresponding right (left) halfsegment Ab, Which we call its brother

by switching its boolean flag indicating which end point is dominant. We define the next

halfsegment in the cycle to which h belongs as h+ such that the dominating endpoint of

Ab is equal to the dominating point dp(h+) and &+ / Ab and &+ is the first halfsegment

encountered when rotating hb clockwise (in an outer cycle) or counter-clockwise (in a hole

cycle) around its dominating point. The previous halfsegment in the cycle is similarly
defined as h_.

Classifying Outer and Hole Cycles: By using a sweep line, the algorithm steps

through the halfsegfment sequence to find the smallest unannotated halfsegfment h,










Algorithm 4: The algorithm for deriving the component view of a region.
Input: Sequence of unannotated halfsegments H
Output: Sequence H with fully annotated halfsegments
1 while not end of sweep do
2 Advance sweep line to h. h is the left-most halfsegment yet to be annotated;
3 Using sweep line status, determine h as part of an outer cycle or a hole cycle;
4 N600//. In (h); I/iSit(dp(h));
s if h belongs to a hole then
a Using sweep line status, retrieve halfsegment f from its owning outer cycle;
7 Owns (h, f );
sSet cycle walk mode to use counter-clockwise .Il11 Il:ency;
9 81Se
1o Set cycle walk mode to use clockwise .Il11 Il:ency;
11 end
/* Begin walking the cycle */
12 CRA h;
13 while c~ h do
14 if I/iSited(dp(c)) then
is q <- c; c <- c_; NewC;;. 1. (c); Owns(c, h);
io while dp(c) / dp(q) do
/* Trace back anchored hole */
17 info(c_) <- info(c); c <- c_;
Is end
19 81Se
20 if(ROC) 4- info(h); V/isit(dp(c)); ct <- 0;
21 end
22 end
23 end


create a new cycle for this halfsegment, and mark its dominating point as visited

(line 2-4). At this point, the algorithm needs to determine whether h belongs to a

hole cycle (line 5) or an outer cycle (line 9). If a cycle is identified as a hole cycle, the

outer cycle to which it belongs must also be identified (line 6-7), and the cycle must

be walked using counter-clockwise .Il11 Il:ency of halfsegments (line 8). Recall that the

plane sweep algorithm maintains the sweep line status structure, which is a ordered

list of active segments, such that it provides a consistent view of all halfsegments that

currently intersect the sweep line, up to the current event (the addition or removal of a

halfsegment). By examining the halfsegment directly below a halfsegment & in the sweep










line status, we can determine whether & is a part of an outer cycle or a hole cycle of an

existing face. In other words, if halfsegment p is directly below halfsegment & in the sweep

line status structure and the interior-above flag of p is set to true, it follows that & is

either in the interior of the cycle to which p belongs, or & is part of the cycle to which p

belongs. Recall that as soon as a halfsegfment is classified as being apart of a hole or face,

the cycle to which it belongs is walked (Section 7.1.2.3) and all other halfsegments in that

cycle are marked accordingly (lines 12-22). Therefore, if a halfsegment belongs to the same

cycle as any halfsegment that has been previously encountered by the sweep line, it is

already known to which face and/or hole cycle it belongs. Furthermore, all halfsegments

that are less than a given halfsegment in halfsegment order have already been classified.

Therefore, we can determine if an unmarked halfsegment belongs to a hole or outer cycle

by examining the halfsegment immediately below it in the sweep line status structure.

Fr-om the definition of a face, the outer cycle of a face of a region ah-- .1-< covers

(encloses) all of its hole cycles. This means that the smallest halfsegment of this face is

ah--li-s a part of the outer cycle. This is also true for the entire region object where the

smallest halfsegment in the ordered sequence is ak- .1-< a part of the first outer cycle of the

first face. Furthermore, due to the order relation of halfsegments and the cyclic structure

of a pakei-on, the smallest halfsegment of a face will ak-n-li- be a left halfsegment with

the interior of the face situated above it. Thus, when we process this halfsegment, we set

its interior-above flag to indicate this fact. Since we have classified this cycle as an outer

cycle, we can walk the cycle and set the interior-above flag for all halfsegments of this

cycle. For example, Figure 7-8A illustrates the case where the smallest halfsegment of the

sequence is processed and the cycle is classified as an outer cycle.

Once the first outer cycle of a face in a region has been processed, we continue to

process halfsegments that have not yet been classified based on the plane sweep status

structure. Figure 7-8B shows an example. Here, we add/remove visited halfsegments

into/from the sweep line status in sequence ordered up to the smallest unvisited










status status



A B

Figure 7-8. Processing halfsegments in a region. A) Processing the smallest halfsegment &
of the sequence. B) Processing halfsegment k of a cycle.


halfsegment k. This halfsegment must be the start of a new cycle that we must now

classify. We know k is the start of a new cycle because all halfsegments of an existing cycle

that include a halfsegment j such that j < k must have been marked as visited by the

walking process. Once we reach this new cycle represented by its starting halfsegment k,

we add this halfsegment into the sweep line status. We classify the type of cycle k belongs

to by examining the interior-above flag of the halfsegment p (its predecessor) which was

already visited and sits immediately below k in the sweep line status structure. If the

predecessor indicates that the interior of the face is above it (the interior-above attribute

of p is set to true), then k lies in the interior of the cycle to which p belongs, thus, k must

be part of a hole cycle and the interior of the face to which k belongs must lie below k.

If the interior-above Afla of p indicates that the interior of the face to which p belongs

is below p, then the current halfsegment k must be part of an outer cycle of a new face.

In case that there is no predecessor, then the current halfsegment must be a part of an

outer cycle of a new face, because it does not lie in the interior of any other face's outer

cycle. Once the cycle is classified as either an outer cycle of a new face or a hole cycle of

an existing face, the cycle walking procedure is carried out to determine all halfsegments

that belong to the cycle.

Walking Cycles: In general terms, we use the phrase walking a I,~ .; 1. to indicate

the traversal of a cycle such that each halfsegment that forms the cycle is visited.

Furthermore, the halfsegments in such a traversal are visited in the order in which they

appear in the cycle. In other words, given a halfsegment h, all halfsegments in the cycle

to which h belongs are found by repeatedly finding &+ until the the original halfsegment










is encountered again. For example, when walking the outer cycle of the region in Figure

7-2 in clockwise order beginning from S1, the halfsegments would be encountered in the

order hi,, hi, hi, hl,, h5, & ,. The two main challenges to this portion of the algorithm are

(i) to identify cycles correctly such that they correspond to the unique representation of a

region as stated in the definition of complex regions, and (ii) to achieve this efficiently. In

this section we show how to satisfy the first challenge. Time complexity is discussed in the

next section.

When a halfsegment & is encountered by the algorithm that has not yet been

classified, it is classified as belonging to a hole or outer cycle in line 5. If h belongs to an

outer cycle, then the cycle walk portion of the algorithm in lines 12-22 is executed. Due to

the halfsegfment ordering and the definition of regions, the smallest unvisited halfsegfment

in the input sequence that the plane sweep encounters is ah-- .1-< a left halfsegment of an

outer cycle of a face and the interior of that face ah-- .1-< lies above the halfsegment. If we

rotate Ab clockwise around its dominating point, it will intersect the interior of the face.

Thus, the first halfsegfment encountered when rotating hb clockwise around its dominating

point will be part of the outer cycle of the same faces (except for a special case discussed

below) and will be & We know this to be true because if we find &+ in this fashion and

it turns out to be part of another face, then two faces would intersect, which is prohibited

by the definition of complex regions. It follows that each successive halfsegment in the

outer cycle can be found by rotating the brother of the current halfsegment clockwise

around its dominating point because the location of the interior relative to the halfsegfment

can ah-- .1-< be deduced based on the previous halfsegment encountered in the cycle walk.

One special case occurs when walking outer cycles: the existence of a hole in a face

that meets the outer cycle at a point. When walking an outer cycle that contains such

a hole, the halfsegfments that form the hole will be classified as being part of the outer

cycle using the procedure just described. In order to remedy this, we mark each point

that is a dominating point of a halfsegment encountered during the cycle walk (line 20).










Each time we find a new halfsegment that is part of an outer cycle, we first check if its

dominating point has been visited yet (line 14). If it has been visited, then we know that

we have encountered that point before, and a hole cycle that meets the outer cycle must

have been discovered. When this happens, we loop backwards over the cycle until we

find the halfsegment whose dominating point has been visited twice (lines 15-18). The

halfsegments forming the hole are then marked as such. The remainder of the outer cycle

is then walked.

Walking a hole is identical to walking an outer cycle, except that a counter-clockwise

rotation from hb is used to find h A counter-clockwise rotation is required because the

interior of the face is intersected by hb when rotating hb around its dominating point.

When walking holes, the special case exists that two holes may meet at a point. Thus,

we employ the same strategy to detect this case as we did with the special case of a hole

meeting a face (lines 15-18).

Walking Cycles in Maps.

Walking cycles in a map is similar to walking cycles in a region. However, there are

some differences. First, because regions in a map can share halfsegfments that separate

them, we cannot simply mark a halfsegment as being visited. Instead, we must identify

if we have visited the halfsegment when walking the cycles of the region above the

halfsegment, or below the halfsegment. Therefore, two parallel arrays are required to store

this information, one to mark the above side of halfsegfments that have been visited, and

the other to mark the below side. The second difference is that the purpose of the refine

algorithm is to give every face in a map a unique label. Therefore, we must remember

the region_id of each face we have visited, and change the region_id of any face that has

the same region_id of a face that has already been visited to a new, unique region~id.

We achieve this by maintaining a mapping of region~id values from the original map to

region_id values in the refined map. At the first halfsegment encountered for each cycle,

we check the mapping to see if the region_id for the new cycle is in the mapping. If not,










then it is the first time that regfion_id has been encountered. In this case, we add the

region_id to the mapping such that it maps to itself. If the region_id is already in the

]rn llling_ then we add the old region_id to the mapping such that it maps a new region~id

.r; furthermore, as the cycle corresponding to the face is being walked, the region_id for

every halfsegment in the cycle is changed to .r. These are the only modifications required

for the cycle walking algorithm presented above to be applied to the refine operation of

maps.

Extending the Label Table.

The second part of the refine operation alters the label table for a map so that it

is consistent with the map geometry created in the cycle walking portion of the refine

algorithm. In order to ensure that region labels remain unique, the label table for the map

being refined is altered so that it contains an additional column, which we will call ref,

of type integer. This column is given a default value, such as -1, that is not used as a

region_id value. Once the label table has this new column, then the tuples corresponding

to the labels of the new regions (which previously were faces of regions) in the map must

he inserted. This is achieved using the label mapping computed during the cycle walk.

Recall that the cycle walk portion of the algorithm returns a mapping A from region~ids

belonging to the map before the cycle walk portion of the algorithm has taken place, to

region_ids belonging to the map after the cycle walk portion of the algorithm has taken

place. Therefore, for each region~id i in ,4 that maps to a new region_id .) that is not in

the label table, a tuple with region_id .) must he inserted into the label table with identical

attribute values as the tuple with region_id i, except that the ref column must contain a

different value than the tuple with region_id i. Therefore, the value of .) is used in the ref

column, since it is unique. Once every entry in the mapping has been processed, the refine

operation is complete. Algorithm 5 and Algorithm 6 summarize this.

From the discussion of the cycle walk portion of the algorithm, it is clear that the

plane sweep and altering of halfsegment labels takes O(n Ig n) time for a map with n










Algorithm 5: The cycle walk portion of the refine algorithm.
Input: A map Af.
Output: Af modified according to the refine operation, and a label mapping A.
1 Initialize sweep line structures;
2 while not end of .sweep? do
3 Get next halfsegment b with an unvisited side;
4 if above .side of h has not yet been visited then
.5 ('I!. I 1: mapping A for above label a of h;
a if a is in no~rr:44:ity i then
7 Set a to map to new region~id c in ,4;
s ('I!s In,.- a to c in h;
9 Walk the cycle as in Algorithm 4, marking the appropriate side of
halfsegfments as being visited and changing appropriate labels;
io else
11 Set a to map to a in A;
12 Walk the cycle as in Algorithm 4, marking the appropriate side of
halfsegments as being visited;
13 end
14 end


if


below .side of h has not yet been visited then
('I!. I 1: mapping 24 for below label b of h;
if b is in I,, .711~:,.:,i 4 then
Set b to map to new regrion~id c in i,4
('!, .Is,,- b to c in h;
Walk the cycle as in Algorithm 4, marking the appropriate side of
halfsegfments as being visited and changing appropriate labels. Use
counter-clockwise ordering around points.;
else
Set b to map to b in ,4;
Walk the cycle as in Algorithm 4, marking the appropriate side of
halfsegments as being visited. Use counter-clockwise ordering around
points.;
end


Id


24
25 e
26 end


~nd


halfsegments. The addition of a mapping of region labels to new region labels can he

implemented using an AVL tree, and thus has a complexity of O(r Ig r) time for a map

containing r faces. Finally, the portion of the algorithm that alters the label table must

alter each existing tuple, plus insert a new tuple for each new region identified in the cycle

walk portion of the algorithm. Thus for a map containing r faces, this takes O(r) time










Algorithm 6: The label table modification portion of the refine algorithm.
Input: A label table LM/ for map M~ and a mapping A from the cycle walk portion
of the refine algorithm.
Output: Label table LM/ modified according to the label mapping A.
1 Add a new column named ref to LM/ With a default value;
2 for each entry a b in A do
3 if a! =b then
4 COnStruct tuple t identical to the tuple with regfion~id a in LMIr
s Set the regfion_id of t to b;
a Set the ref column value of t to b;
7 end
a end



C A,C
A X overlays A,B
B







Figure 7-9. The result of the ot. JIt; _. operation applied to two maps.


since each tuple is modified or inserted once. Therefore, the time complexity for the refine

algorithm is O(n Ig n + r Ig r + r). Since the number of halfsegments in a map is typically

much greater than the number of regions, this tends to be dominated by first term.

7.1.2.4 Combining operations to form new operations

It is possible to combine the previous three operations to create new operations. For

instance, a common operation for maps is to overlay two maps such that the result map

only contains the intersecting portions of regions in the original maps. We denote this

operations ot J.~;,;_ (to differentiate it from the term ot J.~;t which typically refers to the

intersect operation described above), and show an example in Figure 7-9.

In order to compute the ot. ,l~r;_~ we simply combine the intersect and relabel

operations defined previously. Given two argument maps, M~ and P, we first compute










the intersect operation, resulting in map Q. Recall that the label table for the map

Q will have all columns from the label tables for M~ and P; furthermore, the column

names corresponding to columns that came from the first argument map, M~, will have

a 1 appended, and the column names corresponding to columns that came from the

second argument map P, will have 2 appended. In order to compute the ot e l~n; we

must remove all regions from Q that cover an area that is covered by a region in only a

single argument map. We can identify those regions due to the fact the the attributes

in the label table for all attributes from a single argument region will have a default

value. Therefore, we must simply remove the tuples that satisfy this property. Once those

tuples are removed, the relabel operation is executed over Q, which enforces the geometric

consequences of removing tuples from the label table of Q (i.e., the corresponding regions

are removed). After the relabel, Q contains the result of the or .,~rt;_. operation applied to

M~ and P.

7.2 A Prototype Implementation of Map Algebra

In order to test the implementation model of Map Algebra presented in the previous

section, we have produced a prototype implementation of the data model and the

intersect, relabel, and refine algorithms. Our implementation is in C++ and uses an

Oracle database to store the geometric and attribute data for maps. The implementation

follows the presented model very closely. We used Oracle database extension mechanisms

to create a database type mapf2D, which holds the map geometry in the form of ordered

halfsegfments, each annotated with the ID of the region that lies above and below it. The

attributes are stored in a label table. However, due to limitations in the extensibility

mechanisms of Oracle, the intersect, relabel, and refine operations were not able to be

implemented in the database itself. Instead, the map geometry data must be read from

the database by an external library which runs the algorithms, and the writes the result

back to the database. Although this is not optimal in the sense that map data must be

copied to and from the database, because we were able to take advantage of database










extension mechanisms for the map geometry, we are still able to use the transaction

functionality provided by the DBMS.

Recall that a hypothesis we made to motivate the use of maps as first class citizens in

databases was that spatial systems would be easier to implement and less complex. Our

implementation confirms this at two levels. First, we are able to directly use functionality

provided by databases. By using database extension mechanisms to implement Map

Algebra, we are able to utilize database transactions, persistent storage, and multi-user

access. Furthermore, we are able to use standard SQL to pose queries over attribute data,

as well as maps. Furthermore, a single map type is used to represent spatial data in the

database and in the viewer, so we completely avoid a middleware 1 e. -r, and can directly

di pl wi the results of operations without any post-processing. Therefore, this hypothesis

has been confirmed by our implementation. In the following sections, we look at the

performance of map operations in our system in order to test the proposed hypothesis that

implementing maps as first class citizens in spatial systems increases performance.

7.3 Performance Comparison of Map2D Algorithms with an Existing GIS

In order to test the effectiveness of our Map Algebra model, we have conducted a

performance comparison between our Prototype M~ap Algebra Imp~lementation (PMAI),

and an existing GIS. We have chosen to compare PMAI against a commercial GIS product

that has existed for many years, is considered and industry standard, and that is used

worldwide. We will refer to this system as GISX. GISX has been optimized throughout its

lifecycle for performance, and thus, is an ideal candidate to judge the performance of our

system against.

7.3.1 Method of Comparison

The goal of our comparison is to test the relative performance of operations of GISX

and PMAI. Therefore, we will take a data set, use it as input for operations in both

systems, and compare the time it takes to run those operations. In order to make a fair

comparison, we choose operations implemented in both systems and that have the same










semantics. Because maps are not first class citizens in GISX, it is clear that the algorithms

for operations in both systems will be different, so we choose operations that should

have the same result in both systems given the same input data. Therefore, we choose to

test the or Ar ;, operation (what we call intersect in Map Algebra), and the intersection

operation, what we call or l.;;;

The overlay operation is a good choice to compare the two systems because it is

implemented directly in both PMAI and GISX. Furthermore, overlay forms the basis of

many other operations, so it should provide insight into the relative performance of map

processing in general in both systems.

The or Ar ; _. (intersection) operation in PMAI is built using a combination of

intersect and relabel, therefore, PMAI does not have a special purpose algorithm

optimized for this operation. Thus, we expect the performance of this algorithm in

PMAI to be less than that of the overlay algorithm. However, a comparison with the

GISX implementation should provide insight into the feasibility of using combinations of

intersect, relabel, and refine to implement other operations, instead of implementing a

special purpose algorithm for every operation.

We have chosen three data sets to use as input for operations, each taken from

the TIGER 2007 shapefiles provided by the U.S. Census. Each data set consists of the

counties of the states of Vermont, Florida, and Texas, respectively. Vermont was chosen as

the first data set because it is a small state with few counties. Florida is a medium sized

state with about fifty counties. Finally, Texas is a large state with about two hundred

counties. Therefore, each data set reflects a different size in terms of the number of

halfsegments used to represent the state, and an increasing number of counties, which

form the regions in the maps. Furthermore, the TIGER data set is useful because it

provides attributes for each county.

In order to test each operation, a map is chosen from one of the three data sets. The

original map is stored, along with a copy of the map that has been moved in space slightly























Figure 7-10. Images of the PMAI displaying the final result of the ot J.~;; algorithm test
for each of the data sets used.


such that a significant portion of the new map intersects the old map. These two maps

are then used as input to an operation. The time it takes to run the operation is recorded,

and the operation is repeated two more times on the input and the average running time

is kept. The result of the operation is then used as input to the operation again, with

another < li- of the original map that has been moved in a different direction than the

first copy, but that still overlaps a significant portion of the original map. Again, the

running time is averaged for three runs over these inputs, and the output is used in the

next iteration. This process is repeated five times for each data set, and the running times

are recorded. For reference, the final map generated for each data set after completing this

process five times using the ot J.~; z operation is shown in Figure 7-10. These images are

screenshots of our PMAI used to test Map Algebra concepts. Note that some counties are

excluded from the data sets because the regions that represent them in the TIGER data

files do not conform to the definition of complex regions. In other words, these regions

include cycles that are not closed or that contain dangling segments.

We have chosen to perform the experiment as stated above because for each

iteration that an operation is run, the number of halfsegfments needed to represent the

map increases, as well as the number of regions in the map. Thus, as the number of

iterations increases, we are able to see how the running time of each operation scales as

the argument data size and complexity increases. Furthermore, because we have chosen a










small, medium, and large data set, we are also able to determine (in the early iterations)

how each operation performs on small and non-complex data. Therefore, the results of

running these operations should provide a general picture of the performance of each

system.

Note that because of the design differences of GISX and PMAI, simply timing the

total execution from issuing the command until command completion is misleading. This

is because PMAI stores maps in a database, and thus, data must be transferred across a

network connection for loading and storage. GISX stores data in files, so it must simply

read the data from disk. Therefore, we do not count the time it takes to load files for

operations. By observing the disk activity patterns of GISX during operations, it seems

that data is loaded before an operation begins executing. Thus, we feel this is a reasonable

decision. Furthermore, data files are on the order of a few megabytes to tens of megabytes,

which takes a negligible amount of time to load from disk compared to the running time

of the operations tested. The GISX algorithm seems to write the result of operations

incrementally throughout the running of an operation. Therefore, we write the result

of operations in PMAI to disk and include that in the overall running time (we do not

include the network transfer time for writing back to the database). We achieve a fine

grained control over which portions of operations are timed in PMAI through the use

of a stopwatch software mechanism that can be started and stopped from within the

PMAI source code, and which computes time on the order of milliseconds. The GISX

algorithm provides its own timing mechanism that records the total time of an operation

on the order of seconds. Thus, we are able to time comparable input/output functionality

between operations, and the time it takes to compute the result.

7.3.2 Results

The results of running the tests described above are summarized in Figure 7-11

and Figure 7-12. Each graph shows the average running time for an algorithm in both

PMAI and GISX, and the number of halfsegfments in the resulting map. In Figure 7-11,










it is clear that the PMAI algorithm runs more quickly than its counterpart in GISX in

every instance. Furthermore, as the number of halfsegments increase the performance gap

between the algorithms tends to increase as well.

Recall that there are two methods of computing a map overlay, the filter and refine

methods that treat each map as a collection of individual regions, and the object method

that treats a map as a single object. The PMAI approach uses the object method;

therefore, the number of overlapping regions in two argument maps does not affect the

running time of geometric portion of the algorithm. However, in the filter and refine

approach, a geometric algorithm must he computed for every pair of regions that overlap.

In many cases, this means that a region must he processed multiple times, once for each

region whose bounding box overlaps its bounding box. Given our method of testing, it

is possible that the increased number of regions in each successive overlay operation is

causing the GISX algorithm's performance degradation. However, the filter and refine

approach should perform significantly better than the PMAI approach when few regions

overlap. This is because most regions will be identified during the filter step and not

he included in the refine step. The object method, however, involves all regions in two

argument maps in every case. In other words, the PMAI algorithm does not make use of

any filtering hased on bounding boxes. In order to test this assumption, we computed the

intersect operation between the final maps of Vermont and Florida that result from the

experiment described above using the or JIt;, operation. The resulting map contained

840294 halfsegfments :3056 regions. Furthermore, the maps of Florida and Vermont do not

intersect, and are far enough apart that their bounding boxes do not intersect. However,

when this experiment was run, it took an average :33.67 seconds for GISX to compute the

result, and an average of 12.97 seconds for PMAI to compute the result. Thus, the PMAI

approach is a good choice even in situations that favor the filter and refine method. This

is due to the fact that a significant part of the running time of the overlay algorithm in











Vermont Counties


Florida Counties
45



30
25
20 i +GISX

15 g~ Algebra
10


356854 590782 819824
240092 473148 700102
Number of halfsegments in result map


6

5

41


+GISX
+ Map
Algebra


2



53546 78032 99450 120252 140188
Number of halfsegments in result map

Texas Counties


60 i
50 ~1
40
30
20 IY
k
to ~'


Agbra


1060704 1778852
703980 1418034 2140732
Nulmber of halfseaments in re1Sult man


Figure 7-11. Running times for the intersect operation in PMAI and GISX.


PMAI deals with intersecting halfsegments. When no halfsegments intersect, each map is

simply traversed.

In Figure 7-12, the running time for PMAI is broken down into its constituent parts.

Recall the or JIt; _. algorithm in PMAI consists first of an or Jairl algorithm, then a

query to remove the labels of the non-intersecting portions of the argument maps from

the result map, then a relabel operation. The running time for each of these components

is shown. For the Vermont and Florida data sets, the PMAI algorithm clearly performs

better than the GISX algorithm. However, we see that for the Texas data set, the GISX

algorithm performs better in nearly every case. The overlay portion of the algorithm runs

competitively, but as the complexity of the maps increases in terms of the number of











Verrnont Counties


Florida Counties
10




O relabel time
5 5 query time
4 overlay time
3 GISX



253946 234886 208914
240092 254800 214546
Number of halfsegments in result map


O] relabel time
II query time
Overlay time
-GSX


60
50
,40
a, 30
E
i~ 20

10


0 relabel time
query time
overlay time
tGISX



885298 1117578
703980 1030696 1175804
Number of halfsegments in res ult m ap


Figure 7-12. Running times for the ot JI~r _. operation in PMAI and GISX.



regions, the query and relabel portions of the algorithms begin to increase. Recall that

these algorithms include a quadratic component with respect to the number of regions

in the maps involved. Thus, this is reflected in the overall running time. It should be

noted that the GISX algorithm is most likely a special purpose algorithm, while the PMAI

algorithm is emulated by combining different algorithms. Therefore, even though the

performance of the PMAI algorithm is poor in the largest data set, the PMAI algorithm

performs well for small and medium sized data sets. Thus, the approach of creating

operations by combining other operations is feasible in many cases.

In general, these results show that considering maps as first class citizens in spatial

systems results in significant performance gains for geoprocessing. Furthermore, emulating


53546 54504 52388 52682 45764
Num ber of halfsegm ents in result map

Texas Counties










operations through the combination of other operations, instead of creating a special

purpose algorithm for every operation, is also feasible for small and niediunt data sets.

However, it should be noted that the PMAI intplenientation is rather basic in that no

optintizations to reduce nienory consumption are used. Thus, if more ..-z -a ressive nienory

nianagenient techniques are used, large data sets may perform better using this approach.

Finally, even in cases that favor filter and refine methods of computing spatial operations,

the PMAI approach of using maps as first class citizens still performs well in operations.

By incorporating bounding box refinement methods into PMAI, this performance may be

able to be increased even further.









CHAPTER 8
CONCLUSION

In this thesis, we have provided a definition of Map Algebra at three levels. At the

abstract level, the model of spatial partitions defines a mathematical type for maps and

the precise semantics of operations over them. Furthermore, topological relationships

between maps, a subject that has not been explored in the literature, were identified

and defined. Using this definition, we were able to design a query language for maps

in spatial databases and show how it could be implemented using an extended SQL. A

discrete model of maps based on the abstract model was then developed in an effort to

move Map Algebra into an implementable concept. This model, based on graph theory,

provided a mechanism to enforce map type validation at the discrete level by defining the

properties of maps at the discrete level. Finally, at the implementation level, we defined a

data model for maps and algorithms to compute map operations. We then implemented

these algorithms and performed a performance test over the implementation of Map

Algebra comparing it to a mature, commercial system. The results showed that the Map

Algebra implementation outperformed the commercial GIS in terms of execution times

for operations in nearly every test performed. This result validates the approach and

the execution of Map Algebra as a competitor to traditional map processing techniques

currently in use.

In C'!. Ilter 1, we introduced three hypothesis about the effects of integrating maps

as first class citizens in databases. Hypothesis 1 claimed that integrating maps as first

class citizens in databases would prove to be more efficient than emulating maps in a

middleware 1., ;-r. In Section 7.3, we showed that our Map Algebra implementation

outperformed a mature commercial GIS for operations implemented with an algorithm

specifically tailored to that operation, and in most cases outperformed the GIS in

operations that were implemented by combining other operations in the Map Algebra

implementation.










Hypothesis 2 in C'!. Ilter 1 stated that implementing maps as first class citizens would

lead to an easier implementation of map operations and map systems. We found this

to be true in practice. The Map Algebra implementation consisted of a single map data

type that was implemented as a software library. This single library was then integrated

directly into an extensible DBMS, and a visualizer program. By integrating the library

into a DBMS, we were able to directly utilize database services such as transaction

control, persistent storage management, and multi-user access. Thus, none of these

functionalities needed to be re-implemented in middleware. Because the visualizer program

was also aware of the map type, no middleware 1... -r was required to convert data formats

for display, or even for operations. Therefore, the implementation was simplified as

compared to an implementation requiring a traditional middleware 1... r.

Finally, hypothesis 3 stated that by integrating maps into databases, we could achieve

new functionality. We found that through database extension mechanisms, it is possible to

directly use maps in SQL queries in databases. Furthermore, notions such as topological

relationships can be implemented and included in the database extension mechanism so

that they can be used in SQL statements as well. Furthermore, we were able to identify

the types of queries possible over maps in databases, and show how an extended SQL

can be used to perform them. The result is that new functionality can be implemented

for maps in databases. Furthermore, we defined a map query language, MQL, which was

defined such that people without database experience could use the language. Thus, we

have made headway into bringing map functionality in databases to the larger scientific

community, and not simply database experts.

The results of this thesis show that the concepts presented in Map Algebra form a

competitive method to represent, store, and manage spatial data. However, Map Algebra,

as presented, is only initial work into the large area of spatial data handling in terms of

maps. For example, the spatial partition data model used to define maps in Map Algebra

can only represent maps containing region features. Therefore, maps containing point and










line features cannot be represented. Developing a map data model to handle such maps is

a significant undertaking, as the complexity of maps increases greatly with the addition

of new features. Furthermore, notions such as network processing regarding spatially

embedded networks has not been investigated in terms of Map Algebra.

In addition to new directions in spatial data modeling, Map Algebra concepts can also

be applied to physical data storage mechanisms for spatial data. For example, instead of

storing collections of regions in separate tuples of a database table, a map may be used to

store the data. This would allow the performance advantages of map processing algorithms

from Map Algebra to be utilized by more basic spatial types such as regions. Furthermore,

using maps to implement spatial database joins has shown promise for being efficient, even

when indexes are not available on the data.

In conclusion, by rethinking the storage and representation of maps in spatial

databases, we have been able to introduce new, efficient methods of spatial data

management and processing. The concepts developed in Map Algebra show promise

for improving many aspects of spatial data management, even in cases where traditional

spatial types are used instead of maps. Furthermore, there is much work still to be done in

this area, and Map Algebra provides a platform to identify new problems and implement

solutions.










REFERENCES

[1] E. G. Hoel, S. Menon, and S. Morehouse, "Building a Robust Relational
Implementation of Topology," in SSTD, 200:3, pp. 508-524.

[2] J. Herring, "TIGRIS: A Data Model for an Object-Oriented Geographic Information
System," C'omp~uter~s and Geosciences, vol. 18, no. 4, pp. 44:3452, 1992.

[:3] 31. DeMers, Fundramental~s of G. g ur l'l.:. Information S;; I- iii;; John Wiley and Sons,
1990.

[4] P. Burrough and R. McDonnell, Princip~les of G...gul'rll, ..- Infortuation S;,;l1.i
Oxford University Press, 1998.

[5] J. Malczewski, G15 and M~ulticriteria Decision A,...rle;,: John Wiley and Sons, 1999.

[6] I. Heywood, S. Cornelius, and S. Carver, Introduction to G... glrayl,.:..rl Infortuation
S;;i.;,-Prentice Hall, 2002.

[7] C. D. Tomlin, G..-yeapitl,:~.. Information S;,;-. ii;- and Carrtri,, ,,, ,Je., M~odelling.
Prentice-Hall, 1990O.

[8] J. K(. Berry, "Fundamental Operations in Computer-Assisted Map Analysis," Int.
Journal of C~~ l,.gory.1;..al Infortuation So/;,;l~;- vol. 1, no. 2, pp. 119-136, 1987.

[9] A. U. Frank, "Overlay Processing in Spatial Information Systems," in Proc. of the 8th
Int. Symp?. on C'omp~uter-A~ssisted C'ar'i',.i''i,t;, AUTOG'ARTO 8, 1987, pp. 16-31.

[10] 31. Schneider, Spertical Dates Types for Dettebase So/;,~i;, F'inite Resolution Geometry
for G...gu ~rplel..- Infortuation So-;,; -ii Berlin Heidelberg: Springer-\ ~11_ 1997, vol.
LNCS 1288.

[11] R. Viana, P. Alagillo, E. Puppo, and P. A. Ramos, \!l, ll-VMap: A Multi-Scale
Model for Vector Maps," Geoinfortuatica, vol. 10, no. :3, pp. :359-394, 2006.

[12] W. C. Filho, L. H. de Figueiredo, 31. Gattass, and P. C. Carvalho, "A Topological
Data Structure for Hierarchical Planar Subdivisions," in 4th SIAAF C'onference on
Geometric Design, 1995.

[1:3] A. Voisard and B. David, \! ppIII!! Conceptual Geographic Models onto DBMS Data
Models," Berkeley, CA, Tech. Rep. TR-97-005, 1997.

[14] R. H. Gilting, "Geo-Relational Algebra: A Model and Query Language for Geometric
Database Systems," in Int. C'onf. on Ex~tending Dettebase T.. I.. J.-it~~;, (EDB T), 1988,
pp. 506-527.

[15] R. H. Gilting and 31. Schneider, "Realm-Based Spatial Data Types: The ROSE
Algebra," V/LDB Journal, vol. 4, pp. 100-14:3, 1995.










[16] T. Bittner, "The Qualitative Structure of Built Environments," Fundata. Inf., vol. 46,
no. 1-2, pp. 97-128, 2001.

[17] V. Tsetsos, C. Anagnostopoulos, P. K~ikiras, P. Hasiotis, and S. HT Il111. T 1symiades,
"A Human-Centered Semantic ?-i.<1,, li;..1, System for Indoor Environments," perser,
vol. 0, pp. 146-155, 2005.

[18] S. Vasudevan, S. Gachter, V. Nguyen, and R. Siegwart, "Cognitive Maps for Mobile
Robots-an Object Based Approach," Robot. Anton. Syst., vol. 55, no. 5, pp. :359-371,
2007.

[19] S. Thrun, "Robotic Mapping: a Survey," pp. 1-35, 200:3.

[20] R. O. C. Tse and C. Gold, "TIN Meets CAD: Extending the TIN Concept in GIS,"
Future Gener. C'omp~ut. Syst., vol. 20, no. 7, pp. 1171-1184, 2004.

[ 21] Bo;, e. Jlir ri Grap~h Op~erators for Non ,:n Is,..Tl: I~ Geometric M~odeling TryI~ .I J.-i;i Represen-
testions. Elsevier, 1988.

[22] 31. Alantyla, Introduction to Solid M~odeling. New York, NY, USA: W. H. Freeman &
Co., 1988.

[2:3] B. G. Baumgart, "Winged Edge Polyhedron Representation." Stanford, CA, USA,
Tech. Rep., 1972.

[24] 31. Rauhal and 31. F. Worhoys, "A Formal Model of the Process of Wayfinding in
Built Environments," in C'OSIT '99: Proceedings of the International C'onference on
Spertical Infortuation Theory: C'ognitive and C'omp~utational Forundations of G... gorll./:.
Information Science. London, UK(: Springer-V. ~11 1999, pp. :381-399.

[25] U.-J. Riletschi and S. Timpf, "Modelling Wayfinding in Public Transport: Network
Space and Scene Space," in Spertial C'ognition, ser. Lecture Notes in Computer
Science, C. Freksa, 31. K~nauff, B. K~rieg-Brikkner, B. N. 11. I and T. Barkowsky, Eds.,
vol. :334:3. Springer, 2004, pp. 24-41.

[26] F. R. Broome and D. B. Meixler, "The TIGER Data Base Structure," C'ari,.,'*'ir' I
and G..- yI,~rr1,:~. Information So/;,;l~;- vol. 17, pp. :39-48, Jan 1990.

[27] J. Herring, "TIGRIS: Topologically Integrated Geographic Information Systems," in
8th International Symp~osium on C'omp~uter A~ssisted C'ar'i',.,i''i,t;, 1987, pp. 282-291.

[28] N. S. C'I I1.; and K(. S. Fu, "A Relational Database System for Images," in Pictorial
Information So/;,;l~;- N. S. C'I Ils~ and K. S. Fu, Eds. Springer, 1980, pp. 288-321.

[29] N. Roussopoulos, C. Faloutsos, and T. Sellis, "An Efficient Pictorial Database System
for PSQL," IEEE Tan~s. Softw. Eng., vol. 14, no. 5, pp. 6:39-650, 1988.

[:30] 31. J. Egenhofer, "Spatial SQL: A Query and Presentation Language," IEEE Tmanscc-
tions on K~nowledge and Dates Engineering, vol. 6, no. 1, pp. 86-95, 1994.










[31] P. M. Aoki, "How to Avoid Building Datablades that K~now the Value of Everything
and the Cost of Nothing," 1999, pp. 122-133.

[32] S. Banerjee, V. K~rishnamurthy, and R. Murthy, "All Your Data: The Oracle
Extensibility Architecture," in Component Database S;,liii ser. Morgan K~aufmann
Series in Data Management Systems, K(. R. Dittrich, Ed. Morgan K~aufmann
Publisher, 2001, ch. 3, pp. 71-104.

[33] J. Davis, "IBM's DB2 Spatial Extender: Managing Geo-Spatial Information within
the DBMS," Tech. Rep., 1998.

[34] D. S. Batory, J. R. Barnett, J. F. Garza, K(. P. Smith, K(. Tsukuda, B. C. Twichell,
and T. E. Wise, "GENESIS: An Extensible Database Management System," vol. 14,
no. 11, pp. 1711-1730, 1988.

[35] M. Carey and L. Haas, "Extensible Database Management Systems," vol. 19, no. 4,
pp. 54-60, 1990.

[36] M. J. Carey, D. J. DeWitt, and S. L. Vandenberg, "A Data Model and Query
Language for EXODUS," 1988, p. 413423.

[37] L. M. Haas, W. C'I I.1. G. M. Lohman, J. McPherson, P. F. Wilms, G. Lapis, B. G.
Lind .;?i, H. Pirahesh, M. J. Carey, and E. J. Shekita, "Starburst Mid-Flight: As the
Dust Clears," vol. 2, no. 1, pp. 143-160, 1990.

[38] L. A. Rowe and M. Stonebraker, "The POSTGRES Data Model," 1987, pp. 83-96.

[39] H. J. Schek, H.-B. Paul, M. H. Scholl, and G. Weikum, "The DASDBS Project:
Objectives, Experiences, and Future Prospects," vol. 2, no. 1, pp. 25-43, 1990.

[40] M. Scholl and A. Voisard, "Thematic Map Modeling," in SSD '90: Proceedings of the
first symposium on Design and implementation of 'tr ,I. spatial databases. New York,
NY, USA: Springer-Verlag New York, Inc., 1990, pp. 167-190.

[41] M. McE~enney, A. Pauly, R. Praing, and M. Schneider, "Ensuring the Semantic
Correctness of Complex Regions," in Advances in Conceptual M~odeling Foundations
and Applications, ER Workshops, 2007, pp. 409-418.

[42] A. Fr-ank and W. K~uhn, "Cell Graphs: A Provable Correct Method for the Storage of
Geometry," in -,.7 Int. Symp?. on Spatial Data Hat,~I...11/st 1986, pp. 411-436.

[43] M. J. Egenhofer, A. Frank, and J. P. Jackson, "A Topological Data Model for Spatial
Databases," in 1st Int. Symp?. on the Design and Implementation ofIL~rry.- Spatial
Databases. Springer-\ ~11 q 1989, pp. 271-286.

[44] M. J. Egenhofer and J. Herring, "Categorizing Binary Topological Relations Between
Regions, Lines, and Points in Geographic Databases," National Center for Geographic
Information and Analysis, University of California, Santa Barbara, Technical Report,
1990.










[45] E. Clementini and P. Di Felice, "A Model for Representing Topological Relationships
between Complex Geometric Features in Spatial Databases," Infortuation S;,l1.i
vol. 90, pp. 121-136, 1996.

[46] 31. Schneider and T. Behr, "Topological Relationships between Complex Spatial
Objects," AC'~f Tan~s. on Dettebase So/;,~i;, (TODS), vol. 31, no. 1, pp. 39-81, 2006.

[47] 31. F. Worhoys and P. Bofakos, "A Canonical Model for a Class of Areal Spatial
Objects," in Srd Int. Symp?. on Advances in Spertical Dettebases. Springer-V. ~11 g 199:3
pp. :36-52.

[48] E. Clementini, P. Di Felice, and G. Califano, "Composite Regions in Topological
Queries," Infortuation So/;,~i;; vol. 20, pp. 579-594, 1995.

[49] 31. J. Egenhofer, E. Clementini, and P. Di Felice, "Topological Relations between
Regions with Holes," Int. Journal of C~~~lr~,.:yn ,/.a Infortuation So/;,;l~;- vol. 8, pp.
128-142, 1994.

[50] R. H. Gilting, "An Introduction to Spatial Database Systems," The V/LDB Journal,
vol. :3, no. 4, pp. :357-399, 1994.

[51] Z. Huang, P. Svensson, and H. Hauska, "Solving Spatial Analysis Problems with
GeoSAL, A Spatial Query Language," in Proceedings of the 6th Int. Working C'onf.
on Scientific and Statistical Dettebase i.f~r,..rll. I,. .1 Institut f. Wissenschaftliches
Rechnen Eidgfenoessische Technische Hochschule Ziirich, 1992, pp. 1-17.

[52] U. Lipeck and K(. Neumann, "Modelling and Manipulating Objects in Geoscientific
Databases," in ER, S. Spaccapietra, Ed. North-Holland, 1986, pp. 67-85.

[5:3] J. L. Bentley and T. A. Ottmann, "Algorithms for Reporting and Counting
Geometric Intersections," IEEE Tan~s. C'omput., vol. 28, no. 9, pp. 64:3647, 1979.

[54] B. C'!s i...!!.- and H. Edelshrunner, "An Optimal Algorithm for Intersecting Line
Segments in the Plane," J. AC \/I vol. :39, no. 1, pp. 1-54, 1992.

[55] R. Gilting, T. de Ridder, and 31. Schneider, Inspl.I in.. 1.1 .I n. I. of the ROSE Algebra:
Efficient Algorithms for Realm-Based Spatial Data Types," in SSD '95: Proceedings
of the 4th International Symp~osium on Advances in Spertical Dettebases. London, UK(:
Springer-Verlag, 1995, pp. 216-239.

[56] 31. de Berg, 31. K~reveld, 31. Overmars, and O. Schwarzkopf, C'ompubstional Geome-
i, ; Algorithms and Applications. Berlin, Germany: Springer-Verlag, 2000.

[57] D. E. Muller and F. P. Preparata, "Finding the Intersection of Two Convex
Polyhedra," Theor. C'omput. Sci., vol. 7, pp. 217-2:36, 1978.

[58] J. Nievergelt and F. Preparata, "Plane-sweep Algorithms for Intersecting Geometric
Figures," C'ommun. AC'\/I vol. 25, no. 10, pp. 7:39-747, 1982.










[59] D. A. Randell, Z. Cui, and A. Cohn, "A Spatial Logic Based on Regions and
Connection," in' Ineraioa C'onference on Principles of Knowledge Representer-
tion and Rectsoning, 1992, pp. 165-176.

[60] 31. McE~enney, A. Pauly, R. Praing, and 31. Schneider, "Preserving Local Topological
Relationships," in AC \f/ Symp. on G. ..gl'rl' :y -.. Information S;,;I. ;;; (AC \f 015).
AC'jl1 2006, pp. 12:31:30.

[61] -, "Local Topological Relationships for Complex Regions," in Int. Symp. on
Spertical and Temporal Dettebases (SSDT), 2007, pp. 20:3220.

[62] H. Ledoux and C. Gold, "A Horonoi-Based Map Algebra," in Int. Symp. on Spertial
Dates Il~r:I .:.1 ,:i Jul 2006.

[6:3] L. D. Floriani, P. Alarzano, and E. Puppo, "Spatial Queries and Data Models,"
in Information The <;; II. Formentini, Eds. Springfer-Verlagf, Lecture Notes in Computer Science, N.716,
1992, pp. 11:31:38.

[64] L. Guibas and J. Stolfi, "Primitives for the Manipulation of General Subdivisions and
the Computation of Horonoi," A C'.1 Treens. Grap~h., vol. 4, no. 2, pp. 74-123, 1985.

[65] 31. Erwig and 31. Schneider, "Partition and Conquer," in Srd Int C'onf. on Spertial
Information Theory (G'OSIT). Springer-Verlag, 1997, pp. :389-408.

[66] 31. McE~enney and 31. Schneider, "Spatial Partition Graphs: A Graph Theoretic
Model of Maps," in Int. Symp. on Spedical and Temporal Dettebases (SSDT), 2007, pp.
167-184.

[67] J. Dangermond, "A Classification of Software Components Commonly Used in
Geographic Information Systems," in Introdud.. t;, Recedings in G. I, ll.:yepi.. Informes-
tion So/;,~i;; 1990, pp. 30-51.

[68] H. K~riegel, T. Brinkhoff, and R. Schneider, "Combination of Spatial Access Methods
and Computational Geometry in Geographic Database Systems," in SSD '91:
Proceedings of the Second International Symp~osium on Advances in Spertical Dettebases.
London, UK(: Springfer-Verlagf, 1991, pp. 5-21.

[69] C. R. Valenzuela, "Data Analysis and Modeling," in Remote Sensing and G...gol'rl'l.-
crel Infortuation S;,l. iii for Resource i.f~r t..rll. I,,. ,. in Developing C'ountries, 1991, pp.
:335-348.

[70] A. Guttman, "R-trees: a Dynamic Index Structure for Spatial Searching," in SIG-
M~OD '84: Proceedings of the 1984 AC11~/ SlICITOD International C'onference on
1.frt.ry;n;.4ofettr.New York, NY, USA: AC11L 1984, pp. 47-57.

[71] R. Finkel and J. Ben~tlh v, "Quad Trees: A Data Structure for Retrieval on Composite
K~eys," Acta Inf., vol. 4, pp. 1-9, 1974.










[72] J. Robinson, "The K(-D-B-tree: a Search Structure for Large Multidimensional
Dynamic Indexes," in SlICIT/OD '81: Procefedings of the 1981 AC11~/ SlICITOD Interna-
tional Conference on Ma~r..~rll I,. of Data. New York, NY, USA: ACil 1981, pp.
10-18.

[73] J. Nievergelt, H. Hinterberger, and K(. Sevcik, "The Grid File: An Adaptable,
Symmetric Multikey File Structure," AC'~f Trans. Database Syst., vol. 9, no. 1, pp.
38-71, 1984.

[74] R. H. Gilting and H.-P. K~riegel, \1!ul a bin is-!sula i1 B-tree: An Efficient Dynamic File
Structure for Exact Match Queries," in GI rla1,~ I -1.;9.;;. ser. Informatik-Fachberichte ,
R. Wilhelm, Ed., vol. 33. Springer, 1980, pp. 375-388.

[75] J. Orenstein, "A Comparison of Spatial Query Processing Techniques for Native and
Parameter Spaces," SIGM~OD Rec., vol. 19, no. 2, pp. 343-352, 1990.

[76] J. M. Patel and D. J. DeWitt, "Partition Based Spatial-Merge Join," SlIC ITOD Rec.,
vol. 25, no. 2, pp. 259-270, 1996.

[77] L. Becker, A. Giesen, K(. Hinrichs, and J. Vahrenhold, "Algorithms for Performing
Polygonal Map Overlay and Spatial Join on Massive Data Sets," in SSD '99: Proceed-
ings of the 6th International Symp~osium on Advances in Spatial Databases. London,
UK(: Springer-\ ~11 1999, pp. 270-285.

[78] P. van Oosterom, "'An R-tree Based Map-Overlay Algorithm," in EGIS/M~ARI '94,
Paris, 1994, pp. 318-327.

[79] U. Finke and K(. H. Hinrichs, "Overlaying Simply Connected Planar Subdivisions
in Linear Time," in SCG '95: Proceedings of the eleventh annual symposium on
Computational geometry. New York, NY, USA: ACijL, 1995, pp. 119-126.

[80] U. Finke and K(. Hinrichs, "A Spatial Data Model and a Topological Sweep Algorithm
for Map Overlay," in SSD r'- ': Proceedings of the Third International Symp~osium on
Advances in Spatial Databases. London, UK(: Springer-\ ~11 1993, pp. 162-177.

[81] L. Arge, O. Procopiuc, S. R Ian. -i.-- l!ini, T. Suel, and J. S. Vitter, "Scalable
Sweeping-Based Spatial Join," in V/LDB '98: Proceedings of the 24rd International
Conference on V/ery la r ge~ Data Bases. San Francisco, CA, USA: Morgan K~aufmann
Publishers Inc., 1998, pp. 570-581.

[82] H. K~riegel, T. Brinkhoff, and R. Schneider, "An Efficient Map Overlay Algorithm
based on Spatial Access Methods and Computational Geometry," in International
Workshop on DBM~Ss for G.** 9**'rl'l ...~ rl Applications, Capri, Italy, 1991, pp. 16-17.

[83] M. McE~enney and M. Schneider, "Advanced Operations for Maps in Spatial
Databases," in Int. Symp. on Spatial Data Il~r:I...11.el Jul 2006.










[84] -, "Topological Relationships Between Map Geometries," in Advances in
Dettebases: C'oncepts. S;,;l. ;;; and Applications. 18th International C'onference
on Dettebase S;,l. noi for Advanced Applications, 2007.

[85] J. Dugundi, Try.. ~I J..;, Allyn and Bacon, 1966.

[86] R. B. Tilove, "Set Membership Classification: A Unified Approach to Geometric
Intersection Problems," IEEE Trans. on C'omp~uters, vol. C-29, pp. 874-883, 1980.

[87] 31. Erwig and 31. Schneider, "Formalization of Advanced Map Operations," in 9th
Int. Symp?. on Spertical Data Hat,~I...11/st 2000, pp. Sa.3-17.









BIOGRAPHICAL SKETCH

Mark McE~enney was raised in Beaumont, Texas where he attended Monsignor

K~elly High School. Upon graduation, Mark attended Tulane University in New Orleans,

Louisana where he completed a BS in computer science in 2003 and a MS in computer

science in 2004. He then began his Ph.D. studies at the University of Florida. Mark

earned his Ph.D. in Computer Engineering in August 2008, and then joined the Department

of Computer Science at Texas State University as a tenure-track assistant professor.





PAGE 1

MAPALGEBRA:ADATAMODELANDIMPLEMENTATION OFSPATIALPARTITIONSFORUSEINSPATIALDATABASES ANDGEOGRAPHICINFORMATIONSYSTEMS By MARKMCKENNEY ADISSERTATIONPRESENTEDTOTHEGRADUATESCHOOL OFTHEUNIVERSITYOFFLORIDAINPARTIALFULFILLMENT OFTHEREQUIREMENTSFORTHEDEGREEOF DOCTOROFPHILOSOPHY UNIVERSITYOFFLORIDA 2008 1

PAGE 2

c r 2008MarkMcKenney 2

PAGE 3

ACKNOWLEDGMENTS Iwouldliketoacknowledgethemembersofmycommitteeandth ankthemforthe supporttheyhavegivenmethroughoutmytimeattheUniversi tyofFlorida. 3

PAGE 4

TABLEOFCONTENTS page ACKNOWLEDGMENTS ................................. 3 LISTOFTABLES ..................................... 6 LISTOFFIGURES .................................... 7 ABSTRACT ........................................ 9 CHAPTER 1INTRODUCTION .................................. 11 1.1Motivation .................................... 11 1.2ProblemStatement ............................... 14 1.3GoalsandSolutions ............................... 16 2RELATEDWORK .................................. 21 2.1TraditionalSpatialTypes ........................... 21 2.1.1SpatialDataModels .......................... 21 2.1.2Operations ................................ 23 2.1.3TopologicalRelationships ........................ 23 2.2SpatialDataTypesforMaps ......................... 26 2.2.1SpatialDataModels .......................... 26 2.2.2Operations ................................ 31 2.2.3TopologicalRelationships ........................ 33 3ANINFORMALOVERVIEWOFSPATIALPARTITIONS ........... 35 4THEABSTRACTMODELOFSPATIALPARTITIONS ............. 37 4.1SpatialPartitions ................................ 38 4.2Operations .................................... 40 4.3TopologicalRelationships ........................... 42 5QUERYINGSPATIALPARTITIONS:THEUSERVIEWOFMAPSINSPATI AL DATABASES ..................................... 50 5.1TypesofMapQueries ............................. 50 5.2MapQueryLanguage:AHigh-levelQueryLanguageforMaps ....... 52 5.2.1DataModel ............................... 52 5.2.2MQLQueryingSyntax ......................... 55 5.2.3QueryingMaps ............................. 57 5.2.3.1Mapqueries .......................... 57 5.2.3.2Componentattributequeries ................ 58 5.2.3.3Componentqueries ...................... 59 4

PAGE 5

5.3QueryingMapsinDatabasesUsingSQL ................... 60 5.3.1DataModel ............................... 60 5.3.2CreatingMaps .............................. 61 5.3.3QueryingMaps ............................. 62 5.3.3.1Mapqueries .......................... 63 5.3.3.2Componentattributequeries ................ 64 5.3.3.3Componentqueries ...................... 65 6THEDISCRETEMODELOFSPATIALPARTITIONS ............. 67 6.1DenitionsfromGraphTheory ........................ 67 6.2RepresentingSpatialPartitionsasGraphs .................. 68 6.3PropertiesofSpatialPartitionGraphs .................... 76 7THEIMPLEMENTATIONMODELOFSPATIALPARTITIONS ........ 82 7.1Map2D:anImplementationModelofMapAlgebra ............. 82 7.1.1ADataModelForRepresentingSpatialPartitions .......... 82 7.1.2AlgorithmsforMapOperations .................... 86 7.1.2.1Intersect ............................ 87 7.1.2.2Relabel ............................ 92 7.1.2.3Rene ............................. 96 7.1.2.4Combiningoperationstoformnewoperations ....... 106 7.2APrototypeImplementationofMapAlgebra ................ 107 7.3PerformanceComparisonofMap2DAlgorithmswithanExis tingGIS ... 108 7.3.1MethodofComparison ......................... 108 7.3.2Results .................................. 111 8CONCLUSION .................................... 116 REFERENCES ....................................... 119 BIOGRAPHICALSKETCH ................................ 126 5

PAGE 6

LISTOFTABLES Table page 2-1Asummaryofspatialsystemsandtheirtreatmentofmaps. ........... 26 4-1Therst42validmatricesandprotoypicaldrawingsrepr esentingthepossible topologicalrelationshipsbetweenmaps.Eachdrawingshow stheinteraction oftwomaps,onemapismedium-greyandhasadashedboundary, theotheris light-greyandhasadottedboundary.Overlappingmapinter iorsaredark-grey, andoverlappingboundariesaredrawnasasolidline.Forref erence,thegure formatrix41showstwodisjointmapsandthegureformatrix 1showstwo equalmaps. ...................................... 48 4-2Thenal7validmatricesandprotoypicaldrawingsrepre sentingthepossible topologicalrelationshipsbetweenmaps. ....................... 49 6

PAGE 7

LISTOFFIGURES Figure page 1-1Adepictionofcurrentspatialsystemarchitecture.The datalayermanagesstorage andretrievalofdatafromalesystemordatabase.Themiddl ewarelayerperforms processing.Theuserinterfacelayerprovidesuserinterac tionmechanisms. ... 13 1-2Ourproposedsystemarchitecture. ......................... 18 2-1Examplesofcomplexspatialobjects.A)Acomplexpointo bject.B)Acomplex lineobject.C)Acomplexregionobject. ...................... 21 2-2Samplecompositeregionwithtwocomponentspresenting ahole-likestructure. 22 2-3Adepictionofvariousspatialoperationsappliedtotwo regions.A)Therst argumentregion.B)Thesecondargumentregion.C)Theinter sectionofthe regions.D)Theunionoftheregions.E)Thedierenceofther egions. ..... 23 2-4The9-intersectionmatrixforspatialobjects A and B ............... 24 3-1Asamplespatialpartitionwithtworegions.A)Thespati alpartitionannotated withregionlabels.B)Thespatialpartitionwithitsregion andboundarylabels. Notethatlabelsaremodeledassetsofattributesinspatial partitions. ..... 36 4-1Aspatialpartition withtwodisconnectedfaces,onecontainingahole.A) Theinterior( ).B)Theboundary( @ ).D)Theexterior( ).Notethatthe labelshavebeenomittedinordertoemphasizethecomponent softhespatial partition. ....................................... 39 4-2Theapplicationofthereneoperationtoaspatialparti tion.A)Aspatialpartition withtworegionsanditsboundaryandregionlabels.B)There sultoftherene operationonFigure A ................................ 40 5-1Twosamplemaps.A)Amapwithlabelsconsistingofasingl estringnamed crop .B)Amapwithlabelsconsistingofapairofintegers,indica tingtheaverage temperatureandrainfallforeachregion,named Avg Temp and Avg Rain ,respectively. ............................................. 54 5-2Arelationcontainingamap2Dcolumnandtheassociatedl abeltables.Thetable Map1AttributeTableisassociatedwiththemapwithIDequal to1inthetable MapTable,andthetableMap2AttributeTableisassociatedw iththemapwith IDequalto2inthetableMapTable. ........................ 61 6-1AspatialpartitionanditscorrespondingSSPG.A)There nementofthepartition inFigure3-1A.B)TheSSPGcorrespondingtoFigure A .Nodelessedgesare dashed. ........................................ 70 7

PAGE 8

6-2Alabeledplanenodelesspseudographforthepartitioni nFigure3-1.Theedges andverticesaremarkedsothatthesetsofvertices,edges,n odelessedges,and facescanbeexpressedmoreeasily. ......................... 75 7-1Amapshowinganindustrialandcommercialzone. ................ 83 7-2Acomplexregionobjectwitheachsegmentlabeled. ................ 85 7-3Twodierentviewsofamap.A)Themaprepresentedinthei mplementation modelofMapAlgebra.B)Themapwithitssegmentslabeled. .......... 86 7-4Theresultofthe intersect operationappliedtotwomaps. ............ 87 7-5Aggregatingmaplabelsinanintersectoperation.A)The rstargumentmap. B)Thesecondargumentmap.C)Thetheresultofaggregatingt heargument maps'labelsduringanintersectoperation. ..................... 88 7-6Theresultoftheplanesweepportionoftheintersectalg orithmforthemaps showninFigure7-5.A)Thelabeledgeometry.B)Themapping. ........ 90 7-7Theresultinglabeltablefromanintersectoperation.A )Thelabeltablefor themapshowninFigure7-5A.B)Thelabeltableforthemapsho wninFigure 7-5B.C)Thelabeltablecomputedastheresultofanintersec toperation. ... 91 7-8Processinghalfsegmentsinaregion.A)Processingthes mallesthalfsegment h ofthesequence.B)Processinghalfsegment k ofacycle. ............. 101 7-9Theresultofthe overlay 2 operationappliedtotwomaps. ............. 106 7-10ImagesofthePMAIdisplayingthenalresultofthe overlay algorithmtestfor eachofthedatasetsused. .............................. 110 7-11RunningtimesfortheintersectoperationinPMAIandGI SX. .......... 113 7-12Runningtimesforthe overlay 2 operationinPMAIandGISX. .......... 114 8

PAGE 9

AbstractofDissertationPresentedtotheGraduateSchool oftheUniversityofFloridainPartialFulllmentofthe RequirementsfortheDegreeofDoctorofPhilosophy MAPALGEBRA:ADATAMODELANDIMPLEMENTATION OFSPATIALPARTITIONSFORUSEINSPATIALDATABASES ANDGEOGRAPHICINFORMATIONSYSTEMS By MarkMcKenney August2008 Chair:MarkusSchneiderMajor:ComputerEngineering Theideaofa map isafundamentalmetaphorinspatialsystems.Forinstance, inthe eldsofgeographicalinformationsystems(GIS),spatiald atabases,geography,robotics, computerassisteddesign(CAD),andspatialcognition,the arrangementofspatialdata intomapformplaysaprimaryroleinthecomposition,repres entation,andanalysisof spatialdata.However,nomodelsofmapscurrentlyexisttha tprovideaprecisedenition ofaspatialdatatypeformapsandoperationsoverthem.Inst ead,manyinformal denitionsareprovided,manyofwhicharetiedtospecicim plementationconcepts. Furthermore,althoughtheintegrationofspatialdatabase sintospatialeldssuchas GIShasreceivedmuchattention,thenotionofintegratingm apsintodatabaseshasbeen overlooked.Thus,theideaofintegratingmapsintoSQLandp erformingqueriesoverthem hasnotyetbeenexplored.Thisthesisdescribesthedesigna ndimplementationof Map Algebra ,atypesystemandoperationsformapsinspatialdatabases. Weprovideathree levelapproachtodeningMapAlgebra.First,weprovidean abstractmodel ofmaps.This isamathematicaldescriptionofmapsandtheiroperationsa ndtopologicalpredicates. Thismodelisdenedonformalmathematicalconceptsthatar enotimplementablein computersystems;therefore,wethenprovidea discretemodel ofmapsbasedondiscrete conceptsthatcanbetranslatedtocomputersystems.Wethen providean implementation model ofmaps,completewithalgorithmstoimplementmapoperatio ns,thatcanbe 9

PAGE 10

directlyimplementedinacomputersystem.Furthermore,we developaquerylanguage called MapQueryLanguage thatcanbeusedtoposequeriesovermapsindatabases. 10

PAGE 11

CHAPTER1 INTRODUCTION Theideaofa map isafundamentalmetaphorinspatialsystems.Forinstance, intheeldsofgeographicalinformationsystems(GIS)[ 1 { 8 ],spatialdatabases[ 9 { 15 ],robotics[ 16 { 19 ],computerassisteddesign(CAD)[ 20 { 23 ],andspatialcognition [ 18 24 25 ],thearrangementofspatialdataintomapformplaysaprima ryroleinthe composition,representation,andanalysisofspatialdata .Specically,inapplicationssuch asspatialdatabasessystems(SDS),GISs,andglobalpositi oningsystems(GPS),the mapitselfplaysacentralroleinthatthemapistheprimaryu serinterfacetool.GISs inparticularhaveadoptedmapsforgeoprocessing,andaric hsetofgeoprocessingtools hasbeendevelopedaroundthem.Thus,mapsinthecontextofG ISsandSDSsandthe functionalityprovidedinthesesystemsareofvitalimport ancetoindustry,government, andthemanyscienticeldswhichmakeuseofthesesystems. Thegeneralgoalofthisdissertationistoexaminethewayma psareimplemented andoperatedonincurrentspatialsystems,anddiscovermet hodstoimprovethe representationandstorageofmapdataandthewaysthatuser scaninteractwithmaps. Weapproachthisgoalbyattemptingtointegratemapsas rstclasscitizens indatabases. Inthenextfewsectionswemotivateourgoalbyprovidingamo redetaileddiscussionof thestateoftheartwithregardtomapsinspatialsystems,id entifyingproblemsrelated tothecurrentstateoftheartinmaps,andidentifyingsomes pecicgoalstoimprovethe stateoftheartthattheremainderofthisthesiswilladdres s. 1.1Motivation Ingeneral,spatialsystemscanbeconceptualizedasconsis tingofthreecomponents arrangedasshowninFigure 1-1 :adatalayer,aprocessingormiddlewarecomponent, andauserinterface.Thedatalayeristypicallyimplemente dasaspatialdatabaseor lesystemthatmanagesthephysicalstorageofthespatiald ata.Themiddlewarelayer performsoperationsandcomputationsthatthedatalayerdo esnotprovide.Typical 11

PAGE 12

examplesofsuchcomputationsarecoordinateprojections, triangulationofpolygons,and thepreparationofdataforinputtotheuserinterface.Thev isualizationlayerdisplays datatotheuserandprocessesuserinput,whichispassedbac ktothemiddlewarelayer andthedatalayer.Inthefollowing,wediscusseachlayerin moredetail.Specicsystems andtheircapabilitiesarediscussedinSection 2 Webeginbyexaminingthedatalayerinspatialsystems.Aswa smentionedbefore, thedatalayerisusedtostoretheactualspatialdata.Spati aldataitselfisstoredinthe formof spatialprimitives ,whicharethefundamentalunitsofspatialobjects.Inearl y systems,spatialprimitivesconsistedof points and straightlinesegments ,whichwere usedtoconstructspatialobjectssuchaspoints,lines,and regions.Therstgenerations ofspatialdatastoragestoredtheseprimitivesinles[ 26 27 ].Becauselesystems typicallyprovideonlyinput/outputoperations,allspati aloperationswereimplementedin middleware,andthelesystemwasusedonlyforstorage.Whe ndatabasesbegantobe usedtostorespatialdatainsteadoflesystems,thedataba sewastreatedmuchlikeale systeminthatitwasonlyusedforstorageandspatialoperat ionswerestillimplemented inmiddleware[ 2 14 28 { 30 ].Forexample,aregionwouldbeassignedauniqueidentier andallstraightlinesegmentsthatmadeuptheregionwoulde xistintuplesinadatabase tablealongwiththeregionidentierindicatingwhichregi ontheybelongedto.Thus,a joinoperationwastypicallyrequiredbetweenaregiontabl eandtablecontainingstraight linesegmentsinordertoconstructaregion.Thisprovedtoh avepoorperformance, and,becausethespatialobjectswerenotknownbythedataba se,alloperationswere implementedinmiddleware. Theadventofextensibledatabasesystems[ 31 { 39 ]providedasolutiontothe problemswiththeoriginalattempttointegratespatialdat aintodatabases.Withan extensibledatabase,thedatabasecouldbemadeawareofa spatialdatatype consisting ofbothdataandoperationsoverthedata[ 10 14 15 40 ].Therefore,adatabasecould manipulateaspatialdatatype,suchasaregion,asifitwere anyothertypeofwhichthe 12

PAGE 13

6TFS*OUFSGBDF .JEEMFXBSF-BZFS %BUB-BZFS "QQMJDBUJPO1SPHSBN 1SPDFTTJOH-BZFSNBQPQFSBUJPOTn .BQ$POTUSVDUJPO-BZFS NBQSFQSFTFOUBUJPOn %#.4 %BUB4UPSBHF TQBUJBMQSJNJUJWFTn "1* Figure1-1.Adepictionofcurrentspatialsystemarchitect ure.Thedatalayermanages storageandretrievalofdatafromalesystemordatabase.T hemiddleware layerperformsprocessing.Theuserinterfacelayerprovid esuserinteraction mechanisms. databasewasaware.Thus,operationslikespatialintersec tion,union,anddierencecould bemovedfrommiddlewaredirectlyintothedatabase.Inothe rwords,spatialobjects became rstclasscitizens inthedatabase,allowingSQLqueriesoverspatialobjects thattookadvantageofspatialoperations.Theresultwasin creasedperformanceand rexibilityofspatialsystems.Thecurrentstateofthearti nspatialsystemsistousea datalayerconsistingofadatabasethatisawareofpoints,l ines,andregions,togetherwith operationssuchasspatialintersection,union,dierence ,andtopologicalpredicates. Theroleofthemiddlewarelayerhastypicallybeentoprovid eoperationsthatarenot availableinthedatalayer.Becausecurrentspatialdataba sesareawareofconceptssuch aspoints,lines,andregions,themiddlewarelayerincurre ntsystemscombinesthesemore simplespatialobjectstoformmorecomplexspatialarrange ments,typically GISmaps HereweusethetermGISmapstomeanamapasitisdenedintheG ISliterature[ 3 { 6 ]: amapisacollectionofmaplayerssuchthateachmaplayerisc omposedofpoints,lines, andregionsthatareoptionallyassociatedwithattributed ata.Therefore,amiddleware layercollectspoints,lines,andregionsfromthedatabase ,andarrangesthemintomap layers,whichcomposeaGISmap[ 1 ].Onceamapiscreated,itispasseduptothe 13

PAGE 14

visualizationlayer,whichhandlesissuessuchasclipping ,displayingthematicinformation, andprovidingcolorandtexturetomapsfordisplay. Insummary,Figure 1-1 illustratesthearchitectureofcurrentspatialsystems. Thedatalayerofcurrentsystemsutilizesadatabasewhichc anstoreandmanipulate thespatialprimitivesofpoints,lines,andregions.Themi ddlewarelayercontainsa componentthatcancollectthesespatialprimitivesandcon structamapfromthem.Map operations,suchasoverlayinglayers,areperformedoncon structedmaps,andtheresults arepresentedtotheuserthroughavisualizationoruserint erfacelayer. Itisclearthattheconceptofamapisimportantinspatialsy stemsduetothefact thattheyarealmostuniversallyusedinsuchsystems.Howev er,giventhestateofthe artasdiscussedabove,wenotethatthecurrentmiddlewarei mplementationofmapsis strikinglysimilartothemiddlewareimplementationsofpo ints,lines,andregionsthat existedinearliersystems.Specically,wenotethatthesp atialcomponentsofmaps(i.e., thepoints,lines,andregionsthatcomposethemap)canbesp readacrossmultipletables inadatabase.Therefore,wepostulatethatamiddlewareimp lementationofmapssuers similarproblemstothemiddlewareimplementationofpoint s,lines,andregions.However, theopenproblemexiststhatthereiscurrentlynomethodofi ntegratingamaptypeintoa databasedatalayerofspatialsystems.Inotherwords,maps arenot rstclasscitizens in databases.Inordertointegratemapsasrstclasscitizens indatabaseswemustaddress theadditionalopenproblemthatqueryingmechanismsforma psindatabaseshavenot beenthoroughlystudied.Currently,mapattributes,sucha snames,populations,etc.,can bequeriedandspatialqueriescanbeperformedoverthepoin ts,lines,andregionsthat composeamap,butqueriesovermapsthemselvesareunavaila ble.Forexample,itisnot possibletondallmapsinadatabasethatformasubmapofaqu erymap. 1.2ProblemStatement Basedonthecurrentstateoftheartofspatialsystemsandth epreviousdiscussion, theoverallproblemthisthesisaddressesistodiscovermet hodsforintegratingmaps 14

PAGE 15

asrstclasscitizensintospatialsystems.Wesplitthispr oblemintovesubproblems thatcanbeaddressedindividually:(i)wemusthaveadenit ionofmapsthatdescribes theirproperties,(ii)wemustknowthesemanticsofmapoper ations,(iii)wemustbe abletodeterminerelationshipsbetweenmapsbasedontheir geometries(i.e.,topological relationships),(iv)wemusthaveawaytoexpressqueriesov ermapsthatprovidesaccess toallfeaturesofmapsaswellasmapoperationsandpredicat es,(v)wemusthaveecient methodsofimplementingmapsandoperationsinspatialsyst ems. Aformaldenitionofmapsthatpreciselydescribestheirpr opertiesisessentialfor deningoperationsandpredicatesandensuringclosurepro pertiesofmapsoverthem. InChapter 2 ,wewillseethatmanydenitionsformapsexist,buttheyare allbasedon informaldescriptionsortreatmapsascollectionsofmorep rimitivespatialtypes,and notasrstclasscitizens.Therefore,inordertoaddressth isproblem,wemustprovide aprecisedenitionofmapsbaseduponmathematicalconcept sinsteadofintuitive descriptions. Theexistenceofaformalmodelofmapsbasedonmathematical conceptswillallow thedenitionofprecisesemanticsformapoperations.Ther efore,wemustprovidesuch semanticdescriptionsofmapoperationsthatcurrentlyexi stbaseduponourmodel.This willallowustoensureoperationalclosure,guaranteeingt hatmappropertiesarepreserved throughtheapplicationofsuchoperations. Aformalmodelofmapsbasedonmathematicalconceptscanals obeleveragedto denetherelationshipsoftwomapsinspace.Animportantcl assofspatialqueriesover traditionalspatialtypesistheclassoftopologicalqueri es.Topologicalqueriesarebased upontopologicalpredicates(Section 2 )whichindicatequalitativepropertiesbetweena pairofspatialobjectssuchasadjacencyorinclusion.Thes epredicatesformthebasis ofspatialindexstructuresaswellastopologicalqueries. Becauseoftheimportanceof thisclassofqueries,weneedtodenetopologicalrelation shipsbetweenmapsbasedona formaldenitionofmaps. 15

PAGE 16

Becauseouroverallgoalistoincludemapsasrstclassciti zensindatabases,we mustprovidesomemethodforuserstointeractwithmapsinda tabases.Therefore,we mustprovidesomemechanismtointeractwithmapsbasedonSQ L,whichisthestandard databasequeryinglanguage.Becausemapsarecurrentlynot treatedasrstclasscitizens, nomethodofintegratingmaptypesintoSQLcurrentlyexists .Therefore,wemustshow howmapscanberepresentedinadatabasecontext,anddevelo pamethodforintegrating mapoperationsandmapqueryingmechanismsintoSQL. Finally,themapdatatypeandoperationsoveritmustbeimpl emented.Therefore, wemustprovideanimplementationformapsconsistingofada tamodelandoperations thatpreservesthepropertiesofmapsandthesemanticsofma poperations.Furthermore, theoperationsovermapsmustbeimplementedeciently,and thedatamodelmust supporttheoperationsadequately.Thus,wemustprovideal gorithmsforoperationsand implementtheminordertoverifytheireciency. 1.3GoalsandSolutions Inordertoaddresstheproblemsdiscussedinthepreviousse ction,werequirea formal typesystem or algebra formapswhichpreciselydenesthesemanticsofmapsand operationsovermaps.Althoughmapsandtheiroperationsar edescribedinmanyworks [ 3 { 7 40 ],thesedenitionsareallinformal.Insuchcases,situati onsmayariseinwhich thesemanticsofanoperationareunclear;therefore,wewil ldeneanew MapAlgebra thatprovidesprecisesemantics.Weapproachthedevelopme ntofMapAlgebrafromthree levels:theabstractlevel,thediscretelevel,andtheimpl ementationlevel.Attheabstract level,wedeneapurelymathematicalmodelofmaps.Thisall owsustopreciselydescribe thepropertiesofmaps.Usingthismodel,wecanthenidentif ymapoperations,and preciselydenetheirsemantics.Mapoperationsdierfrom traditionalspatialoperations becausemapsarethematic;therefore,mapoperationsmustt akecareofthematicdataas wellasgeometricdata.Furthermore,wecanaddresstheconc ernsofclosurepropertiesof mapoperationsatthislevel.Atthislevel,wecanalsolever agetheformaldenitionof 16

PAGE 17

mapstodiscovertopologicalrelationshipsbetweenmaps.T herefore,bycompletingthe abstractdenitionofMapAlgebra,wewillprovidesolution stoproblems(i),(ii),and(iii) mentionedabove. GiventheabstractmodelofMapAlgebra,wecanconsidercons tructsnecessaryfor queryingmaps.Weapproachtheproblemofqueryingmapsfrom twolevels.First,we developanewmapquerylanguage,calledMQL,thatisabletoe xpressqueriesovermaps. Thisisaspecialpurposelanguagedesignedaroundmaps,and isintendedasahighlevel, userviewofmapsindatabases.WethenshowhowMQLconstruct scanbeexpressedin SQL.BycreatingamethodtointegratemapsintoSQL,wecanco nsidermapsasrst classcitizensinadatabasesettingaswellastakeadvantag eofthewideacceptanceof SQLbydatabaseusers. OncetheabstractmodelofMapAlgebra,includingqueryingm echanisms,is complete,weconsidertheimplementationofmapsincompute rsystems.Thisisachieved byrstconsideringMapAlgebraatthediscretelevel.Adisc retemodelofmapstranslates theabstractmodelofmapsintothediscretedomainbydenin gdiscreterepresentations, suchasgraphrepresentations,forthemapdatamodeldened attheabstractlevel.The discretemodelshouldpreservethepropertiesoftheabstra ctmodel,buteliminatethe needforconceptssuchasinnitepointsetsandcontinuousm appings.Theresultisa modelthatcanrepresentmapsbasedsolelyondiscreteconce pts.Bydeningadiscrete representationofmaps,wecanensurethatthepropertiesof mapsdenedattheabstract levelaretransferredintothediscretedomain.Thiswillal lowustoensurethatmaps representedindiscretemethodsarevalidinthesensethatt heypreservethepropertiesof mapsasdenedintheabstract,mathematicalmodel. Attheimplementationlevel,wefocusondevelopingdatastr ucturesandalgorithms thatcanbeusedtoimplementamapdatatype.Thepropertieso ftheimplementation modelofmapsshouldbeidenticaltothepropertiesoftheabs tractanddiscretemodelsof maps,butbeorientedtowardsimplementation.Theimplemen tationmodelshouldprovide 17

PAGE 18

mechanismsforuserstocreate,store,andmanipulatemaps. Oncetheimplementation modeliscomplete,wecandirectlyimplementitinadatabase system.Thecreationofan implementationmodeladdressproblem(v)mentionedabove. Recallthatthegeneralgoalofthisproposalistodiscoverm ethodstoimprovethe representationandstorageofmapdataandthewaysthatuser scaninteractwithmaps. Basedonthestateoftheartofspatialsystemsandtheproble msidentiedabove,we renethegoalofthisproposaltodiscoveramethodbywhichm apscanbeintegratedas rstclasscitizensindatabasesystems,includingamethod bywhichmapscanbequeried. Figure 1-2 providesapictorialdescriptionofthisgoal.Inessence,w eaimtomovethe mapfunctionalityinspatialsystemsfromthemiddlewarela yertothedatalayer. OnceanimplementationofMapAlgebraisachieved,wehypoth esizethatitwillbe superiortocurrentmapimplementationsinseveralrespect s.Wesummarizethegoalsof ourMapAlgebraimplementationintermsofthefollowingthr eehypotheses. Hypothesis1. Byintegratingmapsasrstclasscitizensindatabases,con structing mapsandperformingoperationsovermapswillbemoreecien tthancurrentmethodsof implementingmaps Becausemapsarecurrentlyimplementedinmiddleware,GISm apsmustbe constructedfromtheircomponentpoints,lines,andregion sthatarestoredinthe datalayer.Therefore,aprocessingstepmusttakeplacetop erformthisconstruction 6TFS*OUFSGBDF %BUB-BZFS 7JTVBMJ[BUJPO1SPHSBN "1* 1SPDFTTJOH-BZFSNBQPQFSBUJPOTn %#.4 %BUB4UPSBHF NBQEBUBBOECBTJDTQBUJBMEBUBn Figure1-2.Ourproposedsystemarchitecture. 18

PAGE 19

inadditiontoretrievingthemapcomponentsthatarepossib lyscatteredacrossmultiple tablesinadatabase.Ifamapisstoredasasingledatabaseob ject,thenitcansimply bereaddirectlyfromthedatabase,andthisconstructionst episnolongerneeded. Furthermore,theoutputofspatialoperations,suchasmapo verlay,isoften unstructured meaningthatthealgorithmcomputesthelinesegmentsthatf ormtheresultinggeometry, butdoesnotidentifythespatialprimitivesintheresultin ggeometry(i.e.,thepoints, lines,andregions).Aseparatealgorithmmustbeusedtoide ntifythespatialprimitives oftheresultingmap[ 41 ].Wehypothesizethattheintegrationofmapsasrstclass citizensinspatialdatabaseswilleliminatemuchoftheove rheadprocessingassociated withmiddlewareimplementationsofmaps. Hypothesis2. Byintegratingmapsasrstclasscitizensindatabases,spa tialsystems thatutilizemapswillbelesscomplexandeasiertoimplemen t Moderndatabasesprovideasignicantamountoffunctional ityregardingdataaccess andstorage.Specically,databasestypicallyprovidetra nsactions,concurrencycontrol, datarecovery,anSQLinterface,andmulti-useraccess.Ifa mapisimplementedasa typeinadatabasesystem,thedatabaseautomaticallyprovi destheseservices.Ifamap isimplementedinmiddleware,theseconceptsmustbeimplem entedexplicitly,which typicallyresultsinduplicationofdatabaseservicesinth emiddlewarelayer.Therefore, wehypothesizethatadatabaseimplementationofamaptypew illallowapplicationcode tobelesscomplexsinceapplicationsdonothavetoimplemen tthesedatabaseservices. Wewillinvestigatethishypothesisthroughimplementinga prototypesystembasedon ourmapconcept.Ifwecansuccessfullyimplementourmapcon ceptwithouttheuseofa middlewarelayer,thenallmapfunctionalitywillbeprovid edbythedatabase,whichwill alsoprovidethetraditionaldatabaseservices. Hypothesis3. Byintegratingmapsasrstclasscitizensindatabases,map functionality canbeprovidedthatiscurrentlyunavailableinspatialsys tems. 19

PAGE 20

Currentspatialsystemsprovideanimmenseamountofgeopro cessingtoolsand operationsformaps.However,webelievethatintegratinga maptypeintoadatabase willprovideadditionalfunctionalitythatdoesnotexisti ncurrentsystems.Forexample, amaptypeinadatabasecanbedirectlyusedinSQLqueries.Th erefore,mapqueries canbeissuedfrombothwithinandexternallytoaGISenviron ment.Externalqueries arepossiblebecauseGISmiddlewarelibrariesarenotrequi redfortheexecutionof mapqueries.Furthermore,complexqueriesinvolvingmaps, suchascomputingnested subqueriesandaggregates,canbedirectlyexpressedinSQL anddonotrequirea middlewarelayerorevenaGISintermediary.Thisprovidesm orerexibilitywhen accessingmapssinceanytechnologywithdatabaseconnecti vityusingSQLcanissue queriesovermaps. 20

PAGE 21

CHAPTER2 RELATEDWORK WepresenttheworkrelatedtoMapAlgebraintwogeneralcate gories:work relatedtotraditionalspatialdatatypes,andworkrelated todatatypesformaps.In eachcategory,wediscussthevariousdatamodelsthathaveb eenproposed,aswellas operationsandtopologicalpredicatesthathavebeendevel opedforthemodels. 2.1TraditionalSpatialTypes Traditionalspatialdatatypesprovidemodelsforrepresen tingindividual points lines and regions .Thisistheapproachthathastypicallybeentakeninspatia ldatamodeling. 2.1.1SpatialDataModels Wedistinguishtwo generations ofspatialdatatypes.Thetypesoftherstgeneration haveasimplestructure,andareknownasthe simplespatialtypes [ 42 { 45 ].A simple point describesanelementoftheEuclideanplane R 2 .A simpleline isaone-dimensional, continuousgeometricstructureembeddedin R 2 withtwoendpoints.A simpleregion isa two-dimensionalpointsetin R 2 andtopologicallyequivalenttoacloseddisk. Additionalrequirementsofapplicationsaswellasneededc losurepropertiesof operationsledtothesecondgenerationof complexspatialdatatypes [ 45 { 47 ]illustrated inFigure 2-1 ([ 10 ]forasurvey).A complexpoint isanitepointcollection(e.g.,the positionsofalllighthousesinFlorida).A complexline isanarbitrary,nitecollectionof one-dimensionalcurves,i.e.,aspatiallyembeddednetwor kpossiblyconsistingofseveral disjointconnectedcomponents(e.g.,theNileDelta).A complexregion permitsmultiple $ # Figure2-1.Examplesofcomplexspatialobjects.A)Acomple xpointobject.B)A complexlineobject.C)Acomplexregionobject. 21

PAGE 22

arealcomponents,called faces ,andholesinfaces(e.g.,Italywithitsmainlandand oshoreislandsascomponentsandwiththeVaticanasahole) Twoadditionalspatialdatatypesforregionshavebeenprop osedasintermediate stepsbetweensimpleandcomplexregions.Theseare, compositeregions [ 48 ]and simple regionswithholes [ 45 47 49 ].Acompositeregioncancontainmultiplefaces,butno holes.Inotherwords,acompositeregionconsistsofnitel ymanysimpleregionsthat areeitherdisjoint,ormeetatsinglepoints.Althoughhole sarenotallowedincomposite regions,\hole-like"congurationscanexistiftwocompon entsofoneregiontouchata singlepointoftheirboundariesattwodierentlocations( Figure 2-2 ). Figure2-2.Samplecompositeregionwithtwocomponentspre sentingahole-likestructure. Asimpleregionwithholescontainsonlyasingleface,with nitelymanyholes.The holesinasimpleregionwithholesareallowedtomeetatapoi nt,butcannotforma congurationthatcausestheinterioroftheregiontobedis connected.Inotherwords,a hole-likestructurecannotbeformedbytheholesinasimple regionwithholes.Intuitively, asimpleregionwithholesisacomplexregionthathasonlyas ingleface. Eachspatialtypeisdenedsuchthatitismadeupofthreepar ts:the interior boundary ,and exterior .Givenaspatialobject A ,thesecomponentsareindicated respectivelyas A @A ,and A .Forexample,theboundaryofalineisitsendpoints, anditsinteriorconsistsofthelinesthatconnecttheendpo ints.Theexteriorofaline consistsofallpointsin R 2 thatarenotpartoftheinteriororboundary.Similarly,the boundaryofaregionisthelinethatdenestheregion'sbord er.Theinteriorconsistsof allpointsthatlieinsidetheregion,andtheexteriorconsi stsofallpointsthatarenotpart oftheboundaryorinterior.Theseconceptsarerequiredfor thedenitionoftopological relationshipsbetweenspatialtypes(denedinthenextsec tion). 22

PAGE 23

ABCDE Figure2-3.Adepictionofvariousspatialoperationsappli edtotworegions.A)Therst argumentregion.B)Thesecondargumentregion.C)Theinter sectionofthe regions.D)Theunionoftheregions.E)Thedierenceofther egions. 2.1.2Operations Researchintospatialoperationsoverthetraditionalspat ialtypeshastraditionally centeredaroundthepointsetoperationsof intersection union ,and rene [ 14 15 50 { 52 ]. Iftwospatialobjectsareconsideredaspointsets,thenthe intersection,union,and dierenceoperationscorrespondtosetoperationsovertho sesets.Forexample,Figure 2-3 showstheresultoftheseoperationsforapairofregions. Researchintoimplementingtheseoperationshasbuiltonco nceptsfromcomputational geometry.Specically,planesweepalgorithmsfromcomput ationalgeometry[ 53 54 ]have beenadaptedtocomputegeometricintersection,union,and dierenceoverspatialobjects giventhattheobjectsarerepresentedasasequenceofstrai ghtlinesegments[ 55 { 58 ].This hasresultedinalgorithmscapableofcomputingsuchinters ectionsin O ( n lg n + k )timefor geometricobjectswith n straightlinesegmentsand k intersectingsegments. 2.1.3TopologicalRelationships Thestudyoftopologicalrelationshipsbetweenobjectsins pacehasbeenthesubject ofavastamountofresearch[ 44 45 49 59 ].IntheareasofdatabasesandGIS,the motivationforformallydeningtopologicalrelationship sbetweenspatialobjectshasbeen drivenbyaneedforqueryingmechanismsthatcanlterthese objectsinspatialselections orspatialjoinsbasedontheirtopologicalrelationshipst oeachother,aswellasaneedfor appropriatemechanismstoaidinspatialdataanalysisands patialconstraintspecication. 23

PAGE 24

0@ A \ B 6 = ? A \ @B 6 = ? A \ B 6 = ? @A \ B 6 = ? @A \ @B 6 = ? @A \ B 6 = ? A \ B 6 = ? A \ @B 6 = ? A \ B 6 = ? 1A Figure2-4.The9-intersectionmatrixforspatialobjects A and B Topologicalrelationshipsindicatequalitativeproperti esoftherelativepositionsof spatialobjectsthatarepreservedundercontinuoustransf ormationssuchastranslation, rotation,andscaling.Quantitativemeasuressuchasdista nceorsizemeasurements aredeliberatelyexcludedinfavorofmodelingnotionssuch asconnectivity,adjacency, disjointedness,inclusion,andexclusion.Attemptstomod elandrigorouslydenethe relationshipsbetweencertaintypesofspatialobjectshav eleadtothedevelopment ofthreepopularapproaches:the 9-intersectionmodel [ 44 ],whichisdevelopedbased onpointsettheoryandpointsettopology,the calculusbasedmethod [ 45 ],whichis alsobasedonpointsettopology,andthe RCCmodel [ 59 ],whichutilizesspatiallogic. Becausethedenitionsofspatialobjectsarebasedontopol ogicalprinciples,and theinabilityofthecalculusbasedmethodtoidentifyacomp letesetoftopological relationships,the9-intersectionmodelistypicallyused tomodeltopologicalrelationships betweenspatialobjectsintheeldofSDSs.The9-intersect ionmodelcharacterizesthe topologicalrelationshipbetweentwospatialobjectsbyev aluatingthenon-emptinessofthe intersectionbetweenallcombinationsoftheinterior( ),boundary( @ )andexterior( )of theobjectsinvolved.Aunique3 3matrix,termedthe 9-intersectionmatrix (9IM),with valueslledasillustratedinFigure 2-4 describesthetopologicalrelationshipsbetweena pairofobjects: Variousmodelsoftopologicalpredicatesbasedonthe9-int ersectionmodelusing both componentderivations ,inwhichrelationshipsarederivedbasedontheinteractio ns ofallcomponentsofspatialobjects,and compositederivations ,inwhichrelationships modeltheglobalinteractionoftwoobjects,existinthelit erature.Examplesofcomponent 24

PAGE 25

derivationscanbefoundin[ 48 49 ].In[ 49 ],theauthorsdenetopologicalrelationships betweenregionswithholesinwhicheachoftherelationship sbetweenallfacesandholes arecalculated.Giventworegions, R and S ,containing m and n holesrespectively,atotal of( n + m +2) 2 topologicalpredicatesarepossible.Itisshownthatthisn umbercanbe reduced mn + m + n +1;however,thetotalnumberofpredicatesbetweentwoobje cts dependsonthenumberofholestheobjectscontain.Similarl y,in[ 48 ],predicatesbetween complexregionswithoutholesaredenedbasedonthetopolo gicalrelationshipofeach facewithinoneregionwithallotherfacesofthesameregion ,allfacesoftheotherregion, andtheentirecomplexregionsthemselves.Givenregions S and R with m and n faces respectively,amatrixisconstructedwith( m + n +2) 2 entriesthatrepresentthetopological relationshipsbetween S and R andeachoftheirfaces. Themostbasicexampleofacompositederivationmodel(inwh ichtheglobal interactionoftwospatialobjectsismodeled)isthederiva tionoftopologicalpredicates betweensimplespatialobjectsin[ 44 ].Thismodelhasbeenusedasthebasisformodeling topologicalrelationshipsbetweenobjectcomponentsinth ecomponentmodelsdiscussed above.In[ 46 ],theauthorsapplyanextended9-intersectionmodeltopoi ntsetsbelonging tocomplexpoints,lines,andregions.Basedonthisapplica tion,theauthorsareableto constructacompositederivationmodelforcomplexdatatyp esandderiveacompleteand nitesetoftopologicalpredicatesbetweenthem,thusreso lvingthemaindrawbackofthe componentderivationmodel. Morerecently,ithasbeenobservedthatcompositemodelsof topologicalrelationships betweenspatialobjectsare global ,inthattheycharacterizeanentirescenebyasingle topologicalrelationshipthatmayhide local informationabouttheobject'srelationship [ 60 ].Thehidingoflocalinformationisexpressedintwowaysin globaltopological relationshipmodels:throughthe dominanceproblem ,andthe compositionproblem Thedominanceproblemindicatesthepropertythatthegloba lviewexhibits dominance propertiesamongthetopologicalrelationshipsasdenedb ythe9-intersectionmodel.For 25

PAGE 26

Table2-1.Asummaryofspatialsystemsandtheirtreatmento fmaps. MapModelMiddleware Maps ThematicMapModel GeometricMapModel OperationalClosure DataLevelTopologicalConstraintEnforcement Raster XXX Collections X GraphModels X Tigris XXX ESRIGIS XX MapAlgebra XXX example,whilebuildingroadsbetweentwoadjacentcountri es,onemightbeinterestedto knowthatthereisadisjointislandinoneofthecountriesfo rwhichabridgetotheother countryisrequired.Thedisjointednessinthiscaseisover shadowedordominatedbythe existing meet (adjacent)situationbetweenthecountries'mainlands.Th ecomposition problemexpressesthepropertythataglobaltopologicalpr edicatemayindicateacertain relationshipbetweentwoobjectsthatdoesnotexistlocall y.Forexample,consider twocomplexregionsthathaveindividualfacesthatsatisfy the inside covers ,and meet predicates.Globally,thiscongurationsatisestheover lappredicateeventhoughno faces overlap locally.Thesepropertieshavebeenaddressedthroughthe localtopological relationship modelsbetweencompositeregions[ 60 ]andbetweencomplexregions[ 61 ]. Theseapproachesmodelatopologicalrelationshipbetween twomulticomponentobjects basedonthetopologicalrelationshipsthatexistbetweent hecomponentsoftheobjects. Furthermore,itisshownthatthesemodelsaremoreexpressi vethantheglobal9IM modelsinthattheycandistinguishallthetopologicalscen esthatthe9IMmodelscan distinguish,plusmanymore. 2.2SpatialDataTypesforMaps 2.2.1SpatialDataModels Inthissection,weexaminethevariousapproachesthathave beentakentomodel mapsinboththeliteratureandincommercialGISproducts.W epresenteachapproach tomodelingmaps,andthenevaluatetheapproachwithrespec ttofourcriteria.First, 26

PAGE 27

wedetermineifthemapmodelthatisdescribedorimplemente disamiddlewaremap model,orifitisactuallyadatalevelmapmodelinspatialsy stems.Wesaythata mapmodelismiddlewareifthemaprequiresconstructionorp rocessingoutsideofthe databaseorlesysteminwhichitisstored.Second,wedeter mineifthesystemprovides thematicmaps,meaningamapgeometryannotatedwiththemat icinformation,or non-thematicmaps,consistingofonlyamapgeometry.Inthe non-thematiccase,it maybepossibleforasystemtostorethematicinformationse paratelyfromthemap geometry,butitisnotincludedinthemapmodelitself.Thir d,wecheckifoperational closurehasbeenformallyaddressed.Thisisimportantsinc ewithoutformallyaddressing operationalclosure,wecannotbecertainthattheresultof mapoperationswillbe validinallcircumstances.Finally,wendwhethereachmod elprovidesamechanism toenforcetopologicalconstraintsbetweenmapcontentswi thinthemodel,orifan externalmechanismisrequired.Externalmechanismsofcon straintenforcementare undesirablesincetheycanbediculttoexpressoutsideoft herelationaldatamodel andrequirecomputationaloverheadtoenforce.Forresearc hmodelsthatdonotprovide animplementation,weevaluatethemodelbasedonitsproper tiesanddescription.We summarizethendingsofthisevaluationinTable 2-1 Therstapproachtomodellingmapsthatwediscussisthe raster ,ormoregenerally, tessellation approach.Tesselationapproaches[ 7 62 ]imposeatessellationschemeonthe underlyingspaceandassignavaluetoeachcell.Aregionint hisapproachconsistsof alladjacentcellswithanidenticallabel.Therefore,amap isconsideredtobeabounded tessellationsuchthateachcellcarriesalabel;i.e.,maps inthisschemearethematic. However,tessellationmapsgenerallyallowonlyasinglela belforeachcell,orsometimes afewlabels.Adisadvantagetothetessellationapproaches isthattheydonotscalewell tohandlinglargenumbersoflabelsineachcellduetothehig hstoragerequirementof theseapproaches.Theadvantageofthetessellationapproa chisthatitalignsnicelywith datacollectionmechanisms,suchassamplinganareadivide dintoagrid,ortakingdata 27

PAGE 28

fromasensornetwork.Thus,tessellationapproachesprovi deathematicmaptype,and analgebraexistsovertessellationmapswithoperationalc losure[ 7 ].Furthermore,they implicitlyenforcetopologicalconstraintsoveritsconte ntssincevaluesareconstrained togridcells.However,tessellationapproachesarelimite dingeneralitysincetheyare geometricallyconstrainedtothetessellationschemeinus e,andtessellationrepresentations ofdatacanbeverylarge,especiallyifhighresolutioncell sarerequired. The collection approachtomodelingmapstakestheviewthatamapissimplya collectionofmorebasicspatialentitiesthatmaysatisfyc ertaintopologicalconstraints. Thisistheapproachtakenin[ 12 { 15 40 51 ].Ingeneral,collectiontypesdonotimplicitly supportthematicmaps,butmodelmapsaspurelygeometricst ructures.Somemodels providemechanismstoassociatethematicdatawiththeindi vidualcomponentsofthe map,butthethematicdataisnotpartofthemapdenition.Fu rthermore,notype closureisprovided.Infact,thesemanticsofoperationsov ercollections,eveninthe specicationprovidedbytheOpenGeospatialConsortium,a redenedinformallyand areambiguous.Additionally,nomethodofenforcingtopolo gicalconstraintsovermap contentsisprovided.However,itispossibletotreatanent iregeometriccollectionasa singleobjectinthedatalevelofspatialsystems,meaningt hattheyavoidamiddleware implementation. In[ 11 63 ],theauthorsconsidermodelingmapsasspecialtypesofpla negraphs.This isaninterestingapproachtomodellingmapsbecausetwo-di mensionalmapstypically imposeaplanegraphontheembeddingspace.Problemsinthep roposedmethodsarise whendierentspatialobjectsinthemapsharecoordinates. Forexample,giventhe methodofderivingaplanegraphfromacollectionofpoints, lines,andregions,itis unclearifaspatialpointobjectthathasthesamecoordinat esastheendpointofaspatial lineobjectintheplanegraphcanbedistinguished.Further more,theauthorsrequirea separatestructuretomodelwhattheytermthe combinatorialstructure ofaplanegraph, whichincludesthetopologicalrelationshipsbetweendie rentspatialcomponentsofthe 28

PAGE 29

graph.Therefore,thismodelallowsageometricmaptypemod eledasasinglegraph,but doesnotincorporatethematicinformation.Furthermore,o perationalclosureoversuch mapsisnotdiscussed,noristhespecicationandenforceme ntoftopologicalconstraints. TheTopologicallyIntegratedGeographicInformationSyst em(TIGRIS)[ 2 26 27 ] isuniqueinthatisanearlysystemthatincorporatedmapsin toitsspatialdatastorage model.IntheTIGRISsystem,theindividualtraditionalspa tialobjectsarestoredina mapwhichcontainsnooverlappingregions.Forexample,ifa regionrepresentingFlorida andaregionrepresentingahurricanethatpartiallyoverla psFloridaarestored,thenthree regionsareactuallystoredbyTIGRIS,theregionrepresent ingtheintersectionofFlorida andthehurricane,theregionconsistingofthepartofFlori dathatisdisjointwiththe hurricane,andviceversa.Thesethreeregionsarereferred toas topologicalprimitives fromwhichtheoriginalregionscanbereconstructed.Altho ughmapswereintegratedat adeeplevelinthissystem,amaptypewasnotavailabletothe userexceptthrougha middlewaremapimplementation.Furthermore,themapstora gewasutilizedtoprovidea spatialalgebraforpoints,lines,andregions,butnotform aps.Therefore,nooperational closurewasprovidedovermaps.However,thissystemusedth emapstoragetoenforce topologicalconstraintsoverregionsatthedatalevel. WefocusourdiscusionofcommercialGISmapoeringsonthes oftwareprovided byEnvironmentalSystemsResearchInstitute(ESRI),since itisanindustrystandard andhashadportionsofitsarchitecturepublishedinthelit erature.Ingeneral,theESRI softwareprovidesmapstousersasauserinterfacethatvisu alizesindividualpoint, line,andregionobjects.Therefore,mapsareimplementedi namiddlewarelayerthat manipulatesthemorebasicspatialtypes.Theclosesttechn ologytoadatalevelmap datatypethatESRIprovidesisthenotionof topologies in[ 1 ].Atopology,inthissense, isacollectionofspatialobjectsthatsatisfycertaintopo logicalconstraints;specically, spatialdataobjectsareonlyallowedto meet orbe disjoint .Thedrawbacktotopologies isthattheydonothaveaformalmodeltohandlethematicdata ,andthusmapsare 29

PAGE 30

implementedasgeometricconstructs.Furthermore,thedes criptionoftheimplementation oftopologiesrevealsthattheyareimplementedasamiddlew aretype,andthus,the toplogicalconstraintsoverthecontentsofatopologymust beexpressedandenforcedwith analgorithminamiddlewarelayer. Fromanimplementationstandpoint,researchintomapshasf ocusedondata structuresthatareabletorepresenttopologicalinformat ionaboutmapcomponents. Specically,thesestructuresrepresentadjacencyinform ationabouttheregionsinmaps. Furthermore,thesemodelstypicallyrepresenttheboundar yofamapasacollectionof straightlinesegments.Theearliestofthesestructuresto bestudiedwasthe wingededge structure [ 23 ].Thisstructureisstraightforwardandcanbeimplemented inmemoryor ondisk.Thewingededgestructureassociatestheedgesthat denetheboundaryofa mapwiththeregionstheyseparateusingauniqueregioniden tier.Furthermore,anedge identierisassociatedwitheachedge.Inadditiontocarry ingtheregionidentiersofthe adjacentregions,eachedgealsocarriesanedgeidentieri ndicatingwhichedgewould beencounterednextiftraversingthecurrentregioninaclo ckwiseorcounter-clockwise direction.Therefore,traversingalledgesthatboundareg ionisperformedrathereasily usingtheseedgeidentiers.The doublyconnectededgelist [ 57 ]isasimilarstructurethat maintainslessinformationateachedge,andisthereforemo recompact. Anotherstructureusedforimplementingmapsisthe quadedgestructure [ 64 ].This structureisuniqueinthatitrepresentstheboundaryofama p,whichturnsouttobea planegraphwhenusingmostmapmodels,andthedualofthepla negraphimposedby theboundaryofthemap.Furthermore,analgebraisdenedth atallowsapointertobe movedaroundthemaponeithertheboundarygraph,oritsdual .Therefore,thisstructure allowsconnectivityqueries,inwhichachainofregionscan beidentiedthatconnecttwo argumentregions,tobecomputedusingexistinggraphalgor ithms.Thedrawbacktothis structure,asopposedtothewingededgestructureandthedo ublyconnectededgelist,is 30

PAGE 31

thatitismorecomplicatedtoconstructandmaintain,andit isnotascompactasmore informationisexplicitlyrepresented. WebaseourMapAlgebraonthemodelofmapspresentedin[ 65 ].Theauthorsof thispaperdeneanabstract,mathematicaldatamodelthatf ormallydescribesthetype of spatialpartitions .Aspatialpartitionisthepartitioningoftheplaneintore gular,open pointsetssuchthateachpointsetisassociatedwithalabel .Theuseoflabelstoidentify pointsetsallowsthematicinformationtobemodeledimplic itlyinspatialpartitions. Furthermore,operationsaredenedoverspatialpartition s,anditisshownthatthe operationsareclosedoverthetypeofspatialpartitions.A detaileddescriptionofthetype ofspatialpartitionsisprovidedinChapter 4 .Themaindrawbacktothismodelisthat itisbasedontheconceptsofinnitepointsetsandmappings thatarenotabletobe representeddiscretely.Thishasbeenaddressedin[ 66 ],inwhichagraphmodelofspatial partitionsisdened.Thismodelhasthesamepropertiesoft hespatialpartitionmodel, butisrepresentedusingdiscreteconcepts.Adetaileddesc riptionofspatialpartition graphsisprovidedinSection 6 2.2.2Operations Inadditiontomodelingthegeometricandthematicaspectso fmaps,operations overmapshavebeenextensivelyinvestigated[ 3 { 10 14 15 40 51 67 { 69 ].Herewe brierydescribesomeoftheoperations.Notethatalloperat ionsknownovermapscanbe expressedintermsofthree poweroperations [ 65 ].Wepresentthesepoweroperationsin detailinSection 4.2 ,andintuitivelydescribesomeofthemorewellknownmapope rations here.Themostwellknownmapoperationisthe mapoverlay .Anoverlaytakestwomaps asarguments,andcomputesaresultingmapthatcontainsthe spatialandthematicdata ofbothargumentmaps.Forinstance,consideramapoftheUni tedStatesthatonly containsasingleregionrepresentingtheentirecountry,a ndamapcontainingasingle regionrepresentingahightemperaturezonethatpartially overlapsthemapoftheUS. Theoverlayofthesemapswouldcontainthreeregions,onere presentingtheportions 31

PAGE 32

ofbothmapsthatoverlap,andtheothertworepresentingthe partsoftheargument mapsthatdonotoverlapeachother.Furthermore,theoverla ppingportionofthemaps islabeledwiththelabelsofbothmaps,andthenon-overlapp ingportionscarrythe labelsfromtheirrespectiveargumentmaps.Asimilaropera tionisthe superimposition operation,inwhichtheoverlappingportionsofthemapscar ryonlythelabelfromthe rstoftheargumentmaps.Thus,onemapissuperimposedover theothersuchthatthe originaloftherstmapremainsintheresult,andonlythepo rtionofthesecondmapthat doesnotintersectanypartoftherstremains.The dierence operationisalsosimilarto theoverlayoperation,exceptoverlappingportionsofthea rgumentmapsareremovedfrom theresult.Thisissimilartoadierenceoperationbetween complexregions.Additionally, operationsexistthatoperatesolelyontheattributedatao fmaps.Forexample,the aggregate operationcomputesaggregatesofvaluesoftheneighborhoo dofregions.For instance,inamapofcounties,anaggregatecouldbeusedtoc alculatethepopulationof allcountiesthatshareaboundarywithaspeciccounty.Due tothelargeamountofmap operations,wecannotpresentthemallhereanddirectthere adertothereferencedworks formoreinformation. Implementingoperations .Inthissection,weconsiderapproachestoimplementing the mapoverlay operation,sinceavariationoftheoverlayoperationisreq uiredto computenearlyallspatialoperationsovermaps.Theimplem entationofoperationsover mapshasdevelopedintwodistinctclasses:operationsbase donacollectionapproachto modelingmaps,andoperationsbasedonadatatypeapproacht omodelingmaps.The collectionapproachtomodelingmapsconsidersamapasacol lectionofmoresimpledata types.Therefore,operationsbasedonthisapproachutiliz etechniquesthathelptomanage collectionsofspatialdataobjects.Thecommonfactorinth eseimplementationsisthat anoperationisbrokendownintotwosteps:a lter stepanda rene step.Thisideais commoninspatialindexmechanismsusedinspatialdatabase s[ 70 { 75 ].Forexample, tocomputethespatialintersectionoftwocollectionsofge ometries,onemustcompute 32

PAGE 33

theintersectionofallpairsofgeometriesfromtherespect ivecollections.However,we canreducetheamountofintersectionsthatmustbecomputed ifweignorepairsthat obviouslydonotintersect.Wecandistinguishsuchpairsby maintaininga minimum boundingrectangle foreachgeometryinbothcollections.Wecanthendoasimple test toseeiftheminimumboundingrectanglesoftwogeometriesi ntersect;iftheydonot, thenthegeometriesdonotintersect.Thusthelterstepnd sallpairsofgeometriesthat mayintersectbasedonaminimumboundingrectangleanalysi s.Therenestepthen performsanactualintersectionalgorithmonthepairsofge ometriesthatpassthroughthe lterstep.Thisistheapproachusedin[ 76 { 78 ].Althoughthismethodperformswellfor thecollectionapproachtomodelingmaps,itdoesnotapplyt othedatatypeapproach tomodelingmapsinwhichtheindividualcomponentsofthema parenotrepresented individually. Thedatatypeapproachtomodelingmapsrepresentsamapasas ingleobject. Therefore,algorithmstooverlaymapsinthisapproachcann otusethelterandrene stepsthatareutilizedinthecollectionapproach.Instead ,theentiremapgeometryis consideredasawhole.Computationalgeometryalgorithmsf orthistypeofmapoverlay algorithmhavebeenproposed[ 56 79 { 82 ].Themaindrawbacktothistypeofalgorithm isthatregionswhoseminimumboundingboxesdonotintersec tarestillincludedinthe computationofspatialalgorithmssincetheentiremapsare consideredassingleobjects. Althoughthisapproachisstillasymptoticallyfasterthan thecollectionapproaches (sinceallpairsofregionsdonotneedtobecomputed,thisap proachhascomplexity identicaltothetypeofplanesweepalgorithmused),thecol lectionapproachescanbe fasterinsituationswhenfewmapcomponentsintersect.Thi shasleadtoschemessuchas partitioningmapstoaddressthisproblem[ 81 82 ]. 2.2.3TopologicalRelationships Thesubjectoftopologicalrelationshipsbetweenmapshasn otyetbeenconsidered intheliterature.Instead,modelsoftopologicalrelation shipsbetweenthecomponentsof 33

PAGE 34

maps,i.e.,points,lines,andregions,havebeenstudiedex tensively.Thesemodelswere discussedpreviously. 34

PAGE 35

CHAPTER3 ANINFORMALOVERVIEWOFSPATIALPARTITIONS Inthispaper,wemodelmapsas spatialpartitions ,asdiscussedin[ 65 66 83 84 ]. Thedenitionofspatialpartitionsisratherdense,sowebe ginbyprovidinganintuitive descriptionofthem,andthenpresenttheformaldenitioni nlatersections. Aspatialpartition,intwodimensions,isasubdivisionoft heplaneintopairwise disjoint regions suchthateachregionisassociatedwitha label or attribute havingsimple orcomplexstructure,andtheseregionsareseparatedfrome achotherby boundaries Thelabelofaregiondescribesthethematicdataassociated withtheregion.Allpoints withinthespatialpartitionthathaveanidenticallabelar epartofthesameregion. Topologicalrelationshipsareimplicitlymodeledamongth eregionsinaspatialpartition. Forinstance,neglectingcommonboundaries,theregionsof apartitionarealwaysdisjoint; thispropertycausesmapstohavearathersimplestructure. Notethatthe exterior ofa spatialpartition(i.e.,theunboundedface)isalwayslabe ledwiththe ? symbol.Figure 3-1 Adepictsanexamplespatialpartitionconsistingoftworeg ions. Westatedabovethateachregioninaspatialpartitionisass ociatedwithasingle attributeorlabel.Aspatialpartitionismodeledbymappin gEuclideanspacetosuch labels.Labelsthemselvesaremodeledassetsofattributes .Theregionsofthespatial partitionarethendenedasconsistingofallpointswhichc ontainanidenticallabel. Adjacentregionseachhavedierentlabelsintheirinterio r,buttheircommonboundary isassignedthelabelcontainingthelabelsofbothadjacent regions.Figure 3-1 Bshowsan examplespatialpartitioncompletewithboundarylabels. In[ 65 ],operationsoverspatialpartitionsaredenedbasedonkn ownmapoperations intheliterature.Itisshownthatallknownoperationsover spatialpartitionscanbe expressedintermsofthreefundamentaloperations:inters ection,relabel,andrene. Furthermore,thetypeofspatialpartitionsisshowntobecl osedundertheseoperations, 35

PAGE 36

{A} {B} {A} { } { } A \"^ \#^ \"^ \^ \#r^ \"r#^ \"r^ \"r^ \"r^ \^ \"r#r^ B Figure3-1.Asamplespatialpartitionwithtworegions.A)T hespatialpartition annotatedwithregionlabels.B)Thespatialpartitionwith itsregionand boundarylabels.Notethatlabelsaremodeledassetsofattr ibutesinspatial partitions. indicatingthatthetypeofspatialpartitionsisclosedund erallknownoperationsover them. 36

PAGE 37

CHAPTER4 THEABSTRACTMODELOFSPATIALPARTITIONS Althoughtheabstractmodelofspatialpartitionshasbeenp resentedin[ 65 ]and laterrenedin[ 83 ],thesedenitionsrequiredsomemodicationinordertode neboth topologicalpredicatesovermapsandthediscretemodelofs patialpartitions.Wepresent themodieddenitionhere.Werstintroducethemathemati calnotationanddenitions requiredtoformallydenespatialpartitions.Then,thefo rmalmathematicaltype denitionofspatialpartitionsispresented. Wenowbrierysummarizethemathematicalnotationusedthro ughoutthefollowing sections.Theapplicationofafunction f : A B toasetofvalues S A isdenedas f ( S ):= f f ( x ) j x 2 S g B .Insomecasesweknowthat f ( S )returnsasingletonset,in whichcasewewrite f [ S ]todenotethesingleelement,i.e. f ( S )= f y g = ) f [ S ]= y Theinversefunction f 1 : B 2 A of f isdenedas f 1 ( y ):= f x 2 A j f ( x )= y g .Itis importanttonotethat f 1 isatotalfunctionandthat f 1 appliedtoasetyieldsaset ofsets.Wedenetherangefunctionofafunction f : A B thatreturnsthesetofall elementsthat f returnsforaninputset A as rng ( f ):= f ( A ). Let( X;T )beatopologicalspace[ 85 ]withtopology T 2 x ,andlet S X .The interior of S ,denotedby S ,isdenedastheunionofallopensetsthatarecontained in S .The closure of S ,denotedby S isdenedastheintersectionofallclosedsetsthat contain S .The exterior of S isgivenby S :=( X S ) ,andthe boundary or frontier of S isdenedas @S := S \ X S .Anopensetis regular if A = A [ 86 ].Inthispaper,we dealwiththetopologicalspace R 2 A partition ofaset S ,insettheory,isacompletedecompositionoftheset S into non-empty,disjointsubsets f S i j i 2 I g ,calledblocks:(i) 8 i 2 I : S i 6 = ; ; (ii) S i 2 I S i = S; and(iii) 8 i;j 2 I;i 6 = j : S i \ S j = ; ; where I isanindexsetusedtoname dierentblocks.Apartitioncanequivalentlyberegardeda satotalandsurjectivefunction f : S I .However,aspatialpartitioncannotbedenedsimplyasase t-theoretic 37

PAGE 38

partitionoftheplane,thatis,asapartitionof R 2 orasafunction f : R 2 I ,for tworeasons:rst, f cannotbeassumedtobetotalingeneral,andsecond, f cannotbe uniquelydenedonthebordersbetweenadjacentsubsetsof R 2 4.1SpatialPartitions In[ 65 ],spatialpartitionshavebeendenedinseveralsteps.Fir sta spatialmapping oftype A isatotalfunction : R 2 2 A .Theexistenceofanundenedelement ? A isrequiredtorepresentundenedlabels(i.e.,theexterio rofapartition).Denition 1 identiesthedierentcomponentsofapartitionwithinasp atialmapping.Thelabelson thebordersofregionsaremodeledusingthepowerset2 A ;a border of (Denition 1 (ii)) isablockthatismappedtoasubsetof A containingtwoormoreelements,asopposedto a region of (Denition 1 (i))whichisablockmappedtoasingletonset.The interior of (Denition 1 (iii))isdenedastheunionof 'sregions.The boundary of (Denition 1 (iv))isdenedastheunionof 'sborders.The exterior of (Denition 1 (v))isthe blockmapped ? A .Asanexample,let bethespatialpartitioninFigure 3-1 oftype X = f A;B; ?g .Inthiscase, rng ( )= ff A g ; f B g ; f?g ; f A;B g ; f A; ?g ; f B; ?g ; f A;B; ?gg Therefore,theregionsof aretheblockslabeled f A g f B g ,and f?g andtheboundaries aretheblockslabeled f A;B g f A; ?g f B; ?g ,and f A;B; ?g .Figure 4-1 providesa pictorialexampleoftheinterior,exterior,andboundaryo famorecomplexexamplemap (notethatthebordersandboundaryconsistofthesamepoint s,buttheboundaryisa singlepointsetwhereasthebordersareasetofpointsets). Denition1. Let beaspatialmappingoftype A (i) ( ):= 1 ( rng ( ) \f X 2 2 A jj X j =1 g )( regions ) (ii) ( ):= 1 ( rng ( ) \f X 2 2 A jj X j > 1 g )( borders ) (iii) := S r 2 ( ) j [ r ]6 = f? A g r ( interior ) (iv) @ := S b 2 ( ) b ( boundary ) (v) := 1 ( f? A g )( exterior ) A spatialpartition oftype A isthendenedasaspatialmappingoftype A whose regionsareregularopensets[ 86 ]andwhosebordersarelabeledwiththeunionoflabels 38

PAGE 39

ABCD Figure4-1.Aspatialpartition withtwodisconnectedfaces,onecontainingahole.A) Theinterior( ).B)Theboundary( @ ).D)Theexterior( ).Notethatthe labelshavebeenomittedinordertoemphasizethecomponent softhespatial partition. ofalladjacentregions.Fromthispointforward,weusethet erm partition torefertoa spatialpartition. Denition2. A spatialpartition oftype A isaspatialmapping oftype A with: (i) 8 r 2 ( ): r = r (ii) 8 b 2 ( ): [ b ]= f [[ r ]] j r 2 ( ) ^ b @r g Theremainingportionofthedenitionofspatialpartition srequirestheuseofthe reneoperationoverspatialpartitions.Thisoperationis formallydenedinSection 4.2 andsoweprovideanintuitivedenitionhere.Thereneoper ationoverspatialpartitions uniquelyidentiestheconnectedcomponentsofapartition .Recallthattworegionsina partitioncansharethesamelabeliftheyaredisjointormee tatapoint.Givenapartition containingmultipleregionswiththesamelabel,theoperat ion rene ( )returnsa partitionwithidenticalstructureto ,butwitheveryregionhavingauniquelabel.This isachievedbyappendinganintegertothelabelofeachregio nthatsharesalabelwith anotherregion.Figure 4-2 showsanexamplepartitionandthesamepartitionafter performingareneoperation.Notethatthenotation( A; 1)indicatesthattheinteger1 hasbeenappendedtolabel A Theboundaryofaspatialpartitionimplicitlyimposesagra phontheplane. Specically,theboundariesformanundirectedplanargrap h.Theedgesofthegraph arethepointsmappedtotheboundariesbetweentworegions. Theverticesofthegraph arethepointsmappedtoboundariesbetweenthreeormorereg ions.Weidentifyedges 39

PAGE 40

{A, } {A, } {C, } {C, } {A}{A,C} {C} {A,C} {A} { } A {(A,1), } {(A,2), } {C, } {C, } {(A,1)} {(A,1),C} {C} {(A,2),C} {(A,2)} { } B Figure4-2.Theapplicationofthereneoperationtoaspati alpartition.A)Aspatial partitionwithtworegionsanditsboundaryandregionlabel s.B)Theresult ofthereneoperationonFigure A andverticesbasedonthecardinalityoftheirlabels.Howev er,duetodegeneratecases,we mustusetherenementofapartitiontoidentifythesefeatu res.Wedenethesetofedges andverticesimposedontheplanebyaspatialpartitionasfo llows: Denition3. Boundarypointsofaspatialpartition areclassiedasbeinga vertex or asbeingpartofan edge byexaminingtherenement = rene ( ) asfollows: (i) ( )= f b 2 : j [ b ] j =2 g (ii) ( )= f b 2 : j [ b ] j > 2 g 4.2Operations Threebasicspatialpartitionoperationshavebeendenedt hatcanbeusedtoform theformaldenitionsofallotherknownpartitionoperatio ns: intersection relabel ,and rene .Thesearetheonlyoperationswepresentinthispapersince thenumberofmap operationsislargeandallotheroperationscanbeformulat edusingthesethree.Each oftheseoperationsisclosedoverthesetofvalidspatialpa rtitions,meaningthatifvalid partitionsaresuppliedasargumentstotheseoperations,a validpartitionwillbereturned [ 65 ].Theintersectionoftwopartitions and ,oftypes A and B respectively,returnsa spatialpartitionoftype A B suchthateachinteriorpoint p oftheresultingpartition ismappedtothepairoflabels( [ p ] ; [ p ]),andallborderpointsaremappedtotheset oflabelsofalladjacentregions.Formally,thedenitiono fintersectionoftwopartitions and oftypes A and B canbedescribedinseveralsteps.First,theregionsofthe resultingpartitionmustbeknown.Thiscanbecalculatedby asimplesetintersectionof 40

PAGE 41

allregionsinbothpartitions,since \ isclosedonregularopensets. \ ( ; ):= f r \ s j r 2 ( ) ^ s 2 ( ) g Theunionofalltheseregionsgivestheinterioroftheresul tingpartition: \ ( ; ):= [ r 2 \ ( ; ) r .Next,thespatialmappingrestrictedjusttotheinteriori scalculatedby mappingeachinteriorpoint p 2 I := \ ( ; )tothepairoflabelsgivenby and : I := p : I: f ( [ p ] ; [ p ]) g Finally,theboundarylabelsarederivedfromthelabelsofa lladjacentregions.Let R := \ ( ; ), I := \ ( ; ),and F := R 2 I .Thenwehave: intersection :[ A ] [ B ] [ A B ] intersection ( ; ):= I [ p : F: f I [[ r ]] j r 2 R ^ p 2 r g Relabelingapartition oftype A byafunction f : A B isdenedas f ,i.e.,in theresultingpartitionoftype B eachpoint p ismappedto f ( ( p ))(recallthat ( p )yields asingletonset,e.g. f a g ,andthat f appliedtothisyieldsthesingletonset f f ( a ) g ). relabel :[ A ] ( A B ) [ B ] relabel ( ;f ):= p : R 2 :f ( ( p )) Therenementofapartitionidentiestheconnectedcompon entsofthepartition. Thisisachievedbyrelabelingtheconnectedcomponentsofa partitionwithconsecutive numbers.Aconnectedcomponentofanopenset S isamaximumsubset S T such thatanytwopointsof T canbeconnectedbyacurvelyingcompletelyinside T [ 85 ].Let r ( r )= f c 1 ;:::c n r g denotethesetofconnectedcomponentsinaregion r .Then, rene canbedenedinseveralsteps.Theregionsoftheresultingp artitionaretheconnected componentsofallregionsoftheoriginalpartition: p r ( ):= [ r 2 ( ) r ( r ) 41

PAGE 42

Theunionofalltheseregionsresultsintheinteriorofther esultingpartition: r ( ):= [ r 2 r ( ) r .Thismeansthatthesetofinteriorandboundarypointsaren otchangedby rene. Wecannowdenetheresultingpartitionontheinterior: I := f ( p; f [ p ] ;i ) g ) j r 2 ( ) ^ r ( r )= f c 1 ;:::;c n r g^ i 2f 1 ;:::;n r g^ p 2 c i g Finally,wederivethelabelsfortheboundaryfromtheinter ior,muchlikethe denitionforintersection.Let R := r ( ), I := r ( ),and F := R 2 I .Then: rene :[ A ] [ A N ] rene ( ):= I [ p : F: f I [[ r ]] j r 2 R ^ p 2 r g 4.3TopologicalRelationships Inthissection,wedescribeamethodforderivingthetopolo gicalrelationships betweenagivenpairofmaps.Webeginbydescribingvariousa pproachestotheproblem, thenoutlineourchosenmethod,andnallyderivetheactual relationshipsbasedonthis method.Notethatinthissection,werefertomapsas mapgeometries becausetopological relationshipsconsideronlythespatialaspectsofmaps,an dnottheirthematicattributes. Inordertodeneacomplete,nitesetoftopologicalrelati onshipsbetweenmap geometries,weemployamethodsimilartothatfoundin[ 46 ],inwhichthe9-intersection modelisextendedtodescribecomplexpoints,lines,andreg ions.InSection 4.1 ,we denedapointsettopologicalmodelofmapgeometriesinwhi chweidentiedtheinterior, exterior,andboundarypointsetsbelongingtomaps.Basedo nthismodel,weextendthe 9-intersectionmodeltoapplytothepointsetsbelongingto mapobjects.However,dueto thespatialfeaturesofmapgeometries,theembeddingspace ( R 2 ),andtheinteractionof mapgeometrieswiththeembeddingspace,sometopologicalc ongurationsareimpossible andmustbeexcluded.Therefore,wemustidentifytopologic alconstraintsthatmustbe satisedinorderforagiventopologicalcongurationtobe valid.Furthermore,wemust 42

PAGE 43

identifytheseconstraintssuchthatallinvalidtopologic alcongurationsareexcluded, andthecompletesetofvalidcongurationsremains.Weachi evethisthroughaproof techniquecalled Proof-by-Constraint-and-Drawing ,inwhichwebeginwiththetotalsetof 512possible9-intersectionmatrices,anddeterminethese tofvalidcongurationsbyrst providingacollectionoftopologicalconstraintrulestha tinvalidateimpossibletopological congurations,andsecond,validatingallmatricesthatsa tisfy all constraintrulesby providingaprototypicalspatialconguration(i.e.,thec ongurationscanbedrawninthe embeddingspace).Completenessisachievedbecausealltop ologicalcongurationsare eithereliminatedbyconstraintrules,orareproventobepo ssiblethroughthedrawingof aprototype.Theremainderofthissectioncontainsthecons traints,andtheprototypical drawingsofmapgeometriesareshowninTable 4-1 Weidentifyeightconstraintrulesthat9IMsformapgeometr iesmustsatisfyin ordertobevalid.Eachconstraintruleisrstwritteninsen tencesandthenexpressed mathematically.Followingeachruleistherationaleexpla iningwhytheruleiscorrect.In thefollowing,let and betwospatialpartitions. Lemma1. Eachcomponentofamapgeometryintersectsatleastonecomp onentofthe othermapgeometry: ( 8 C 2f ;@; g : C \ 6 = ? C \ @ 6 = ? C \ 6 = ? ) ^ ( 8 C 2f ;@; g : C \ 6 = ? C \ @ 6 = ? C \ 6 = ? ) Proof. Becausespatialmappingsaredenedastotalfunctions,itf ollowsthat [ @ [ = R 2 andthat [ @ [ = R 2 .Thus,eachpartof mustintersect atleastonepartof ,andviceversa. 2 Lemma2. Theexteriorsoftwomapgeometriesalwaysintersect: \ 6 = ? Proof. Theclosureofeachregioninamapgeomtrycorrespondstoaco mplexregion asdenedin[ 46 ].Sincecomplexregionsareclosedundertheunionoperatio n,it followsthattheunionofallregionsthatcomposeamapgeome tryisacomplexregion, 43

PAGE 44

whoseboundaryisdenedbyaJordancurve.Therefore,every spatialpartitionhasan exterior.Furthermore,in[ 65 ],theauthorsprovethatspatialpartitionsareclosedunde r intersection.Thus,theintersectionofanytwospatialpar titionsisaspatialpartitionthat hasanexterior.Therefore,theexteriorsofanytwospatial partitionsintersect,sincetheir intersectioncontainsanexterior. 2 Lemma3. Iftheboundaryofamapgeometryintersectstheinteriorofa nothermap geometry,thentheirinteriorsintersect: (( @ \ 6 = ? ) \ 6 = ? ) ^ ( \ @ 6 = ? ) \ 6 = ? )) (( @ \ = ? \ 6 = ? ) ^ ( \ @ = ? \ 6 = ? )) Proof. Assumethataboundary b ofpartition intersectstheinteriorofpartition buttheirinteriorsdonotintersect.Inorderforthistobet rue,thelabeloftheregions oneithersideof b mustbelabeledwiththeemptylabel.Accordingtothedenit ionof spatialpartitions,aboundaryseparatestworegionswithd ierentlabels;thus,thisis impossibleandwehaveaproofbycontradiction. 2 Lemma4. Iftheboundaryofamapgeometryintersectstheexteriorofa secondmap geometry,thentheinterioroftherstmapgeometryinterse ctstheexteriorofthesecond: (( @ \ 6 = ? ) \ 6 = ? ) ^ ( \ @ 6 = ? ) \ 6 = ? )) (( @ \ = ? \ 6 = ? ) ^ ( \ @ = ? \ 6 = ? )) Proof. Thisproofissimilartothepreviousproof.Assumethattheb oundary b of partition intersectstheexteriorofpartition buttheinteriorof doesnotintersect theexteriorof .Inorderforthistobetrue,thelabeloftheregionsoneithe rsideof b mustbelabeledwiththeemptylabel.Accordingtothedenit ionofspatialpartitions,a boundaryseparatestworegionswithdierentlabels;thus, thisisimpossibleandwehavea proofbycontradiction. 2 Lemma5. Iftheboundariesoftwomapgeometriesareequivalent,then theirinteriors intersect: 44

PAGE 45

( @ = @ ) \ 6 = ? ) ( c ) d ) ( : c d )where c = @ \ @ 6 = ? ^ \ @ = ? ^ @ \ = ? ^ @ \ = ? ^ \ @ = ? d = \ 6 = ? Proof. Assumethattwospatialpartitionshaveanidenticalbounda ry,buttheirinteriors donotintersect.Theonlycongurationwhichcanaccommoda tethissituationisifone spatialpartition'sinteriorisequivalenttotheexterior oftheotherspatialpartition. However,accordingtoLemma 2 ,theexteriorsoftwopartitionsalwaysintersect.If apartition'sinteriorisequivalenttoanotherpartition' sexterior,thentheirexteriors wouldnotintersect.Therefore,thiscongurationisnotpo ssible,andtheinteriorsoftwo partitionswithequivalentboundariesmustintersect. 2 Lemma6. Iftheboundaryofamapgeometryiscompletelycontainedint heinteriorof asecondmapgeometry,thentheboundaryandinteriorofthes econdmapgeometrymust intersecttheexterioroftherst,andviceversa: ( @ ) \ @ 6 = ? ^ \ 6 = ? ) ( : c d )where c = @ \ 6 = ? ^ @ \ @ = ? ^ @ \ = ? d = \ @ 6 = ? ^ \ 6 = ? Proof. Iftheboundaryofspatialpartition iscompletelycontainedintheinteriorof spatialpartition ,itfollowsfromtheJordanCurveTheoremthattheboundaryo f is completelycontainedintheexteriorof .ByLemma 4 ,itthenfollowsthattheinteriorof intersectstheexteriorof 2 Lemma7. Iftheboundaryofonemapgeometryiscompletelycontainedi ntheinterior ofasecondmapgeometry,andtheboundaryofthesecondmapge ometryiscompletely containedintheexterioroftherst,thentheinteriorofth erstmapgeometrycannot intersecttheexteriorofthesecondandtheinteriorofthes econdmapgeometrymust intersecttheexterioroftherstandviceversa: 45

PAGE 46

(( @ ^ @ ) ) ( \ = ? ^ \ 6 = ? )) ( c ) d ) ( : c d )where c = @ \ 6 = ? ^ @ \ @ = ? ^ @ \ = ? ^ \ @ = ? ^ \ @ 6 = ? d = \ = ? ^ \ 6 = ? Proof. Weconstructthisproofintwoparts.AccordingtoLemma 6 ,if @ ,then \ 6 = ? .Nowwemustprovethat cannotintersect .Since @ ,itfollows that intersects .Therefore,theonlycongurationwhere \ 6 = ? canoccurisif containsaholethatiscontainedby .However,inorderforthiscongurationtoexist, the @ wouldhavetointersecttheinteriorortheboundaryof .Sincethelemmaspecies thesituationwhere @ ,thiscongurationcannotexist;thus,theinteriorof cannot intersecttheexteriorof 2 Lemma8. Iftheboundaryofamapgeometryiscompletelycontainedint heexterior ofasecondmapgeometryandtheboundaryofthesecondmapgeo metryiscompletely containedintheexterioroftherst,thentheinteriorsoft hemapgeometriescannot intersect: (( @ ^ @ ) ) ( \ = ? )) ( c ) d ) ( : c d )where c = @ \ = ? ^ @ \ @ = ? ^ @ \ 6 = ? ^ \ @ = ? ^ \ @ 6 = ? d = \ = ? Proof. Thelemmastatesthattheinteriorsoftwodisjointmapsdono tintersect.Without lossofgenerality,considertwomapgeometriesthateachco nsistofasingleregion.We canconsiderthesemapgeometriesascomplexregionobjects .Iftwocomplexregions aredisjoint,thentheirinteriorsdonotintersect.Wecanr educeanyarbitrarymaptoa complexregionbycomputingthespatialunionofitsregions .Itfollowsthatbecausethe 46

PAGE 47

interiorsoftwodisjointregionsdonotintersect,theinte riorsoftwodisjointmapsdonot intersect. 2 Usingasimpleprogramtoapplytheseeightconstraintrules reducesthe512possible matricesto49validmatricesthatrepresenttopologicalre lationshipsbetweentwomaps geometries.Thematricesandtheirvalidatingprototypesa redepictedinTable 4-1 Finally,wesummarizeourresultsasfollows: Theorem1. Basedonthe9-intersectionmodelforspatialpartitions,4 9dierenttopologicalrelationshipsexistbetweentwomapgeometries. Proof. Theargumentationisbasedonthe Proof-by-Constraint-and-Drawing method. Theconstraintrules,whosecorrectnesshasbeenproveninL emmas 1 to 8 ,reducethe 512possible9-intersectionmatricesto49matrices.Theab ilitytodrawprototypesofthe corresponding49topologicalcongurationsinTable 4-1 provesthattheconstraintrules arecomplete. 2 47

PAGE 48

Table4-1.Therst42validmatricesandprotoypicaldrawin gsrepresentingthepossible topologicalrelationshipsbetweenmaps.Eachdrawingshow stheinteractionof twomaps,onemapismedium-greyandhasadashedboundary,th eotheris light-greyandhasadottedboundary.Overlappingmapinter iorsaredark-grey, andoverlappingboundariesaredrawnasasolidline.Forref erence,thegure formatrix41showstwodisjointmapsandthegureformatrix 1showstwo equalmaps. Matrix1 0@ 100010001 1A Matrix2 0@ 110010001 1A Matrix3 0@ 101010001 1A Matrix4 0@ 111010001 1A Matrix5 0@ 100110001 1A Matrix6 0@ 110110001 1A Matrix7 0@ 101110001 1A Matrix8 0@ 111110001 1A Matrix9 0@ 111001001 1A Matrix10 0@ 111101001 1A Matrix11 0@ 101011001 1A Matrix12 0@ 111011001 1A Matrix13 0@ 101111001 1A Matrix14 0@ 111111001 1A Matrix15 0@ 100010101 1A Matrix16 0@ 110010101 1A Matrix17 0@ 101010101 1A Matrix18 0@ 111010101 1A Matrix19 0@ 100110101 1A Matrix20 0@ 110110101 1A Matrix21 0@ 101110101 1A Matrix22 0@ 111110101 1A Matrix23 0@ 111101101 1A Matrix24 0@ 001011101 1A Matrix25 0@ 101011101 1A Matrix26 0@ 111011101 1A Matrix27 0@ 101111101 1A Matrix28 0@ 111111101 1A Matrix29 0@ 100100111 1A Matrix30 0@ 110100111 1A Matrix31 0@ 111100111 1A Matrix32 0@ 100010111 1A Matrix33 0@ 110010111 1A Matrix34 0@ 001010111 1A Matrix35 0@ 101010111 1A Matrix36 0@ 111010111 1A Matrix37 0@ 100110111 1A Matrix38 0@ 110110111 1A Matrix39 0@ 101110111 1A Matrix40 0@ 111110111 1A Matrix41 0@ 001001111 1A Matrix42 0@ 111001111 1A 48

PAGE 49

Table4-2.Thenal7validmatricesandprotoypicaldrawing srepresentingthepossible topologicalrelationshipsbetweenmaps. Matrix43 0@ 101101111 1A Matrix44 0@ 111101111 1A Matrix45 0@ 001011111 1A Matrix46 0@ 101011111 1A Matrix47 0@ 111011111 1A Matrix48 0@ 101111111 1A Matrix49 0@ 111111111 1A 49

PAGE 50

CHAPTER5 QUERYINGSPATIALPARTITIONS:THEUSERVIEWOFMAPSINSPATIA L DATABASES Thepreviouschapterdenedanabstract,mathematicalmode lofmapsintheform ofspatialpartitions.Thismodeldenesthetypeofspatial partitionsaswellasthe semanticsofoperationsoverspatialpartitions.Inthisch apter,weshowhowthetype ofspatialpartitionsandtheoperationsoverthemcanbeque riedandmanipulatedbya user.Weapproachthisproblemattwolevels:rst,wedenea methodtoexpressmap queriesthatisindependentofdatabaseconceptssuchasSQL ,andsecond,weshowhow SQLconstructscanbeextendedtoprovidemapqueryingcapab ilities,andimplement theconstructsprovidedintherststep.Weassumetheexist enceofaspatialdatabase thatisawareofatypecalled map2D ,whichrepresentsthetypeofspatialpartitions. Furthermore,weassumethatthedatabaseisawareofoperati onsandtopological predicatesoverspatialpartitions.Infollowingsections ,wediscussthetypesofqueries thatcanbeperformedoverthedatabasetypeofmap2D,provid easuitable,high-level databaserepresentationforthetypemap2D,andshowhowmap 2Dinstancescanbe createdandqueriedinsuchadatabase. 5.1TypesofMapQueries InSection 2 ,wediscussedtraditionalspatialdatatypesandtheiroper ations.Recall thatthesetraditionalspatialtypesonlyrepresentageome try,anddonotintegrate thematicinformation.Furthermore,thespatialoperation soverthemarepurelygeometric innatureanddonottakeintoaccountthematicattributes(i nstead,thematicattributes areassociatedwithaspatialobject,butareconsideredsep aratelyfromtheobject's geometry).Thishasleadtoarelativelystraightforwardim plementationofthetraditional spatialtypesintospatialdatabasessincequeriesoverthe setypesarerestrictedto involvingonlythegeometryofaspatialobject.Forexample ,traditionalspatialqueries answerquestionssuchas\returnallregionsthatintersect agivenqueryregion",or \returnallregionswithanareagreaterthanonethousandsq uaremiles".Furthermore, 50

PAGE 51

attributequeriesovertraditionalspatialtypesarestrai ghtforwardsincetheydealonly withattributesstoredalongwithaspatialobject(i.e.,th eattributesareseparatefromthe spatialobject.Thespatialobjectitselfconsistssolelyo fageometry).Therefore,queries suchas\returnallregionsthathaveapopulationgreaterth anonethousand"donotneed toaccessaspatialobject,butonlyanattributestoredsepa ratelyfromaspatialobject. Aswehaveseen,spatialpartitionsdiersignicantlyfrom thetraditionalspatial typesduetotheirintegrationofbothspatialandthematici nformation.Thus,mapscan bequeriedindierentwaysthanthetraditionalspatialtyp es.Forexample,amapquery mayasktoreturnmapsbasedontheattributesassociatedwit htheregionsthatmake upthemap.Thetraditionalspatialtypeshavenomethodtoas sociateattributeswith individualcomponentsofspatialobjects.Anexamplemapqu erywouldbeto\returnall mapsthathavearegionnamedFlorida". Traditionalspatialtypeshavetwotypesofqueriesassocia tedwiththem,spatial queriesandattributequeries.Aswehaveseen,mapsallowfo rnewtypesofqueries duetheirmorecomplexstructureandtheintegrationofattr ibutedatainthedata typedenition.Thus,insteadofbeingdenedmerelyasageo metry,amaphasfour componentswhichmaybeinvolvedinqueries:(i)amapgeomet ry,(ii)componentsin theformof regions thatcomposethegeometry,(iii)attributesassociatedwit heach region,and(iv)possiblyattributesassociatedwiththeen tiremapaswell.Therefore,we classifymapqueriesintofourclassesofqueries: mapqueries ,whichlookatthemapasa whole; mapattributequeries ,whicharesimilartoattributequeriesovertraditionalsp atial objectsinthattheydealwithattributesstoredseparately fromamapobject; component attributequeries ,whichdealwiththeattributesassociatedwithregionsina map;and componentqueries ,whichdealwiththeregionsthatcomposeamap.Inthefollow ing sectionswediscusseachquerytypeinmoredetailandshowho wqueriesofeachtypecan beexpressed.Notethatmapattributequeriesareidentical tothematicqueriesinvolving 51

PAGE 52

thetraditionalspatialtypes;therefore,theyaresimplyt raditionalqueriesthatdonot interactwithamaporitscomponents,andwedonotdiscusthe mfurther. 5.2MapQueryLanguage:AHigh-levelQueryLanguageforMaps Inthissection,weapproachtheconceptofqueryingmapsfro mtheperspective ofauserwhoisnotfamiliarwithdatabasesorSQL.Therefore ,wetreatamapasan abstractdatatypethathidesthedetailsofitsimplementat ionfromtheuser.Thishas theconsequencethatsuchalanguageisindependentoftheun derlyingimplementation, andcanbeimplementedoveranytypeofstoragemedium,sucha sadatabase,lesystem, orcomputermemory.Inthefollowing,wedeveloptheMapQuer yLanguage(MQL) incrementallybyrstexaminingthedatamodelofmapsusedi nMQL,andthenshowing howthevariousclassesofmapqueriescanbeexpressedinMQL 5.2.1DataModel Asmentionedabove,inthissectionwetreatamapasanabstra ctdatatypeand makenoassumptionsastotheimplementationorstoragemedi umassociatedwithamap implementation.However,wecannotsimplyusethedenitio nofspatialpartitionsas giveninChapter 4 sinceitistoogeneralforcreatingaquerylanguagemeantfo rusers withlittletechnicalknowledgeofqueryingmechanisms.Sp ecically,wemustposesome constraintsonmaplabels.Therefore,forthepurposesofMQ L,wedeneanewdatatype called label whichenforcesconstraintsoverthestructureandcontents ofspatialpartition labelsforqueryingwithMQL. Therstconstraintforlabelsthatwerequireisthatlabels canonlycontaindata thatcorrespondstoasetofdenedtypes.Ingeneral,suchas etcanconsistofanydened type,butforillustrationpurposes,wewillassumethatthe attributescontainedinlabels mustbeoftype string or integer ,whereastringisasequenceofcharacters,andaninteger isanumberbelongingtothesetofintegers.Thesecondconst raintisthatalllabelsina mapmustbedenedbyasingle labelcomponenttype ,whichisdenedasalistsuchthat 52

PAGE 53

eachiteminthelistconsistsofatypeassociatedwitha labelcomponentattribute (i.e.,an identierthatuniquelyidentiestheattributeinthelabe l).Moreformally: Denition4. Let T = f string ; integer g bethesetofvalidlabelcomponenttypesfor attributescontainedinalabelsuchthatastringisasequen ceof characters andaninteger isanumber x 2 Z LetIDSbethesetofallpossiblevaluesforalabelcomponent attributeA LabelType isatupleofpairs LS =( a 1 : b 1 ;:::;a n : b n ) where a i 2 T and b i 2 IDS TheMQL createlabeltype statementthatallowsausertocreatelabeltypesand associatethemwithanidentier: Denition5. Let IDS bethesetofvalidlabelcomponentattributesand T bethesetof validlabelcomponenttypes.The createlabelstatement canthenbeusedtocreatelabelsas follows: CREATELABELTYPE l ( a 1 : b 1 ;:::;a n : b n ) where a i 2 T and l;b i 2 IDS Givenalabeltype,alabelisthenatuplecontainingavalueo ftheappropriatelabel componenttypeforeachpairintheassociatedlabeltype.Fu rthermore,eachvaluecanbe identiedbythelabelcomponentattributedenedinthelab eltype: Denition6. Let LT bea labeltype denedbyCREATELABELTYPE LT ( a 1 : b 1 ;:::;a n : b n ) where a i 2 T and l;b i 2 IDS Alabeloftype LT isthendenedasatuple L =( c 1 2 a 1 ;:::;c n 2 a n ) Figure 5-1 depictstwosamplemapsthatsatisestheselabelconstrain ts.Thelabel typeforthemapshowninFigure 5-1 Ais( string : Crop ),andthelabelstructurefor themapshowninFigure 5-1 Bis( integer : Avg Temp ; integer : Avg Rain ).Theselabel typescanbecreatedbyauserwiththefollowingstatements, respectively: CREATE LABELTYPEeld crop ( string : Crop )and CREATELABELTYPEclimate data ( integer : Avg Temp ; integer : Avg Rain ).Thesemapswillbeusedthroughoutthissection toillustrateMQLconcepts. 53

PAGE 54

Wheat Corn 98, 14 86, 22 AB Figure5-1.Twosamplemaps.A)Amapwithlabelsconsistingo fasinglestringnamed crop .B)Amapwithlabelsconsistingofapairofintegers,indica tingthe averagetemperatureandrainfallforeachregion,named Avg Temp and Avg Rain ,respectively. Recallthataspatialpartitionisdenedbyaspatialmappin g := R 2 2 A ,where A isthesetofallregionlabels,withsomerestrictions(Den ition 2 ).Duetotherestrictions placedonlabelsabove,weonlyconsiderthesubsetofspatia lpartitionswhosespatial mappingrestrictstheset A tolabelsthatsatisfyagivenlabeltype.Thus,givenlabelt ype LT ,weconsiderspatialpartitionsdenedbythespatialmappi ng := R 2 2 LT .For example,themapshowninFigure 5-1 Ahasalabeltype eld crop =( string : Crop )and aspatialmapping : R 2 2 eld crop .Werefertothetypeofspatialpartitionswhose setofregionlabelsisconstrainedbyalabeltype LT as map2D LT .Werefertothetype ofspatialpartitionsconsistingofmapswithanyvalidlabe ltypeas map2D .MQLisa mechanismtoposequeriesovermapsofthetypemap2D. InordertoshowhowmapscanbecreatedinMQL,weintroduceso menotationand newoperations.Theseoperationsandnotationsfacilitate theexpressionofqueriesin MQL.Specically,theseoperationsprovidetheabilitytoc reatenewmap2Dinstancesand addregionstomap2Dinstances: Denition7. Givenalabeltype LT andanidentier M ,theMQL mapcreatestatement returnsa newmapwithnoregions: CREATEMAP M ( LT ) 54

PAGE 55

Theaddoperationtakesamap2Dinstancedenedbyalabeltyp e LT ,aregionto beaddedthemap2Dinstance,andalabelandaddstheargument regionandlabeltothe map2Dinstance: add := map2D LT region LT Furthermore,weassumeanassignmentoperatorexistsforth etypemap2Dinthe formof:`='. Therefore,inordertocreatethemapsinFigure 5-1 ,wewouldusethefollowing sequenceofMQLstatements: CREATELABELTYPEeld crop ( string : Crop ) CREATELABELTYPEclimate data ( integer : Avg Temp ; integer : Avg Rain ) CREATEMAPM1 ( eld crop ) CREATEMAPM2 ( climate data ) Oncewehavecreatedmaps,wecanthenaddregionstothem.Let r;s;t; and u be regions,eachcorrespondingtoaregioninthemapsshowninF igure 5-1 .Wecanthenadd theseregionstotheirrespectivemapsasfollows: add ( M 1 ;r; (` wheat ')) add ( M 1 ;s; (` corn ')) add ( M 2 ;t; (98 ; 14)) add ( M 2 ;u; (86 ; 22)) 5.2.2MQLQueryingSyntax Basedonthetypeofmap2D,wenowdenetheconstructsnecess arytoposequeries inMQL.AMQLstatementconsistsofthreecomponentscalled clauses :the FIND clause, the IN clause,andthe THAT clause.The FIND clauseindicateswhatwillbereturnedby thequery.MQLstatementscanreturneithermap2Dinstances orlabels.Therefore,the FIND clausecontainseitherthekeyword MAP ,toindicatethatamapwillbereturnedby 55

PAGE 56

thequery,oralabeltypethatindicatesthestructureoflab elsthatwillbereturnedbythe query. The IN clausecontainsalistofmap2Dinstancesthatqueryawillbe performedover. InMQLimplementations,thislistwillcorrespondtoadatab aserelationorlesystem structure,butforthepurposesofdeningauserconcepttha tisnottiedtoaspecic implementation,wewillrepresentitsimplyasalist. Finally,the THAT clausecontainsabooleanexpressionthatisevaluatedover each ofthemapobjectsinthe IN clause,theirlabels,and/ortheircomponentregions.In ordertoachievethis,weintroducetwofunctions: CONTAINS LABEL() and CONTAINS REGION() thatevaluateaBooleanexpressionandreturntheresult.Th e CONTAINS LABEL() operationcontainsabooleanexpressioninvolvinglabelso fthemaps inthe IN clause.The CONTAINS REGION() operationcontainsabooleanexpression involvingthecomponentregionsofthemapsinthe IN clause.Thesignaturesforthese functionsare: Denition8. Thebooleanexpressiongivenasanargumenttothe CONTAINS LABEL functionwillbeappliedtothelabelassociatedwitheachre gioninamap.Theboolean expressiongivenasanargumenttothe CONTAINS REGION functionwillbeappliedto eachcomponentregionofagivenmap. CONTAINS LABEL := boolean expression B CONTAINS REGION := boolean expression B The IN clauseofanMQLexpressioncancontainabooleanexpression consistingof predicatesovermaps, CONTAINS LABEL() statements,and CONTAINS REGION() statements.Werefertosuchabooleanexpressionasa criteria .Therefore,aMQL statementreturnsmapsorlabelsfromalistofmapsthatsati sfyagivencriteria Therefore,thestructureofanMQLqueryisasfollows: 56

PAGE 57

Denition9. Let LT bealabeltype.Letthenotation x j y meanthat x or y maybeused, butnotboth FIND MAP j LT IN M 1 ;:::M n 2 map2D THAT criteria ItisstraightforwardtoconsiderMQLstatementswheremaps arereturned,since anymapinthe IN clausethatsatisesthegivencriteriawillbereturned.Ho weverMQL statementsthatreturnlabelsarenotasstraightforward.I falabelstructureisgiveninthe FIND clause,thenthequerywillreturnallthelabelsfromeverym apinthe IN clause thatsatisesthecriteria.However,labelswillonlybeinc ludedintheresultthatstrictly conformtothelabelstructuregiven(i.e.,thelabelshavet hesametypeandidentier asgiveninthelabelstructureinthe FIND clauseoftheMQLquery).Inthefollowing subsections,weshowhowthedierentclassesofmapqueries canbeexpressedinMQL. 5.2.3QueryingMaps Atthispoint,theuserhastheabilitytocreatemapsandaddr egionsandtheir correspondinglabelstomaps.Inthefollowingsections,we examinehowausercanpose queriesovermapsandexecutemapoperationsusingMQLconst ructs.Weprovidea discussionofeachclassofmapqueriesidentiedpreviousl y,providingsamplequeriesand showinghowtheycanbeexpressedinMQL.Newoperationsarei ntroducedastheyare needed.5.2.3.1Mapqueries Mapqueries,asstatedpreviously,arequeriesthatconside ramapasawhole,often involvingmapoperations.Forexample,queriesthatreturn allmapswhoseareaislarger thanonethousandsquarefeetorthatcalculatetheoverlayo fapairofmaps,orthat returnmapsbasedonatopologicalrelationshipfallintoth iscategory.Ingeneral,queries ofthistypecanbeexpressedinastraightforwardmannerasl ongastheappropriatemap 57

PAGE 58

operationisdened.Forexample,inordertondallmapsina tablewithanareagreater thanonethousand,theuserwoulduseanareaoperation: Query5.2.1. FINDMAPINM1,M2THATarea() > 1000 Queriesinvolvinggeometricoperations,suchasoverlay,c anbeexpressedbysimply callingtheappropriateoperations: Query5.2.2. M3=Overlay(M1,M2) Finally,ifweassumethatwehaveatopologicalpredicatebe tweenmapsnamed intersects available,whichreturnsavalueof true iftwomapsintersect,wecandiscoverall mapsthatintersectaquerymapasfollows: Query5.2.3. FINDMAPINM1,M2THATintersects(M3) 5.2.3.2Componentattributequeries Theclassofcomponentattributequeriesdoesnotcorrelate withanytypeofqueries overthetraditionalspatialtypes.Thisisbecausetheabil itytoassociateattributedata withthecomponentsofspatialobjectsisuniquetospatialp artitions.Forexamplea usermaywanttondthenamesofallmapsthatcontainaregion thatcontainsthecrop wheat.Suchaquerymakesuseofthe CONTAINS LABEL functioninitscriteriatolook atthelabelofeachregionineachmapinthe IN clause: Query5.2.4. FINDMAPINM1,M2THATCONTAINS LABEL(Crop=`wheat') BecausethemapM1containsaregionwithalabelcontaininga nidentier\Crop" andthevalue\wheat",the CONTAINS LABEL withthesuppliedargumentwillevaluate to true formapM1,anditwillbereturned. Amorecomplexquerywouldreturnattributesfromregionsin amapthatsatisfy somecriteria.Forexample,ausermaywishtondtheaverage temperatureforallregions inmapsthathaveanaveragerainfallgreaterthan20inches. Recallthatifalabeltype isspeciedinthe FIND clauseofaMQLquery,alllabelswillbereturnedforanymap 58

PAGE 59

thatsatisesthecriteriaintheMQLstatement.Therefore, werequireamechanismto isolateonlythelabelsthatsatisfythegivencriteriainam ap.Weachievethisbymaking theobservationthateveryregioninamap,whenconsidereds eparatelyfromthemap, formsa singletonmap .Asingletonmapismapthatcontainsonlyasingleregion,wh ich meansithasonlyasingleregionlabel.Ifeachregionofever ymapinthe IN clausecan beconsideredseparately,thenwecanreturnthelabelsonly forthesingletonmapsthat satisfythecriteria.Inordertoachievethis,weassumethe existenceofamapoperation Expand := map 2 D 2 map 2 D ,whichtakesamap2Dinstance,andreturnsasetof singletonmapssuchthateachmapintheresultsetcorrespon dstoaregionintheoriginal map.Thisfunctioncanthenbeusedinthe IN clauseofMQL.Therefore,wecanexpress thedesiredqueryas: Query5.2.5. FIND((integer:Avg Temp))INExpand(M1),Expand(M2)THATCONTAINS LABEL(Avg Rain > 20) 5.2.3.3Componentqueries Componentqueriesallowuserstoquerymapsbasedontheirco mponents,i.e.regions. Thesearesimilarinconcepttocomponentattributequeries ,butdealwiththeregion geometriescontainedinamapinsteadoftheregionattribut es.Forexample,ifauser wishestoreturnallmapsthatcontainaregionwithanareagr eaterthanonethousand squaremiles,theycouldusean area operatordenedforregionsasfollows: Query5.2.6. FINDMAPINM1,M2THATCONTAINS REGION(area() > 1000) Anotherusefulqueryistoextractregionsfromamapthatsat isfysomepredicate. Forexample,tondallregionsinamapwithareagreaterthan onethousandsquare miles,ausercouldposethefollowingquery: Query5.2.7. FINDMAPINExpand(M1)THATarea() > 1000 59

PAGE 60

5.3QueryingMapsinDatabasesUsingSQL Intheprevioussection,weshowedhowmapscanbequeriedusi ngtheMQL language.Inthissection,weconsiderqueryingmapsinSQLa ndshowhowtheconcepts fromMQLcanbeexpressedinSQL.Weassumetheexistenceofad atabasethatisaware ofthetype map2D ,asdenedpreviously,andtheoperationsandpredicatesov erit. 5.3.1DataModel Thedatamodelformapsinspatialdatabasesshouldsupportt hefourclassesof queriesdiscussedabove.Therefore,weproposeadatamodel forspatialpartitionsina databasetobecomposedoftwocomponents:thegeometriccom ponentandthelabel component.Thegeometriccomponentconsistsofthemapgeom etry,andisimplemented asacolumntypenamed map2D .Thisissimilarinconcepttotheimplementation oftraditionalspatialtypesindatabases.Thedierencebe tweenmap2Dandthe implementationoftraditionaltypesisthateachregionint hemapisassociatedwitha regionidentierwhichwillbeusedtoassociateeachregion withitsattributedata. Thesecondcomponenttothemap2Dtypeconsistsoftheattrib utesforeachregion. Weassumethateachinstanceofamap2Dinacolumnisassociat edwitha labeltable whichcontainstheattributesforeachregioninthemap.The onlyconstraintweplace onthelabeltableisthatitmustcontainacolumnoftypeinte gernamed region id that isusedtoassociateeachtupleinthelabeltablewitharegio ninitscorrespondingmap. Bystoringtheregionattributesinaseparatedatabasetabl e,insteadofwithinthemap2D datatypeitself,weallowtheusertoperformqueriesoverth eattributesassociatedwith regionsusingstandardSQL.Thisfacilitatesthetheclasso fcomponentattributequeries describedabove.Finally,weassumethatamapinstancestor estheinformationnecessary toidentifyitscorrespondinglabeltable.Figure 5-2 showsanexampleinstanceofatable containingacolumnoftypemap2Dwhichcontainstwotuples, andthelabeltables associatedwiththemapstoredineachtuple. 60

PAGE 61

*%JOU /BNFTUS (FPNNBQ% .BQ@" .BQ@# SFHJPO@JEJOU$SPQTUS 8IFBU $PSO SFHJPO@JEJOU"WH5FNQJOU "WH3BJOJOU .BQ5BCMF .BQ"UUSJCVUF5BCMF .BQ"UUSJCVUF5BCMF Figure5-2.Arelationcontainingamap2Dcolumnandtheasso ciatedlabeltables.The tableMap1AttributeTableisassociatedwiththemapwithID equalto1in thetableMapTable,andthetableMap2AttributeTableisass ociatedwiththe mapwithIDequalto2inthetableMapTable. 5.3.2CreatingMaps InthissectionweshowhowwecanextendtheSQL CREATE and INSERT constructstoaccommodatethecreationoftablescontainin gmapcolumnsandtuples containingmaps.Weassumethatthedatabaseisawareofthed atamodelofmapsas discussedintheprevioussection,specicallythetype map2D .Wenowshowhowauser cancreatethetablesdepictedinFigure 5-2 Considerauserwhowishestocreateamapinadatabase.Weass umethatthisuser beginswithanemptydatabase(i.e..,adatabasecontaining notables)andperformsthe necessarystepstocreateamap2Dinstancewithinthedataba se.Therststeptheuser musttakeinordertocreateamapistocreateatableinwhicht hemapwillbestored. Sincethedatabaseisawareofthemap2Dtype,wecansimplyus eacreatetablecommand asshownbelow: Statement5.3.1. CREATETABLEMapTable(ID:int,Name:str,Geom:map2D) Notethattheabovestatementcreatesonlythetablenamed\M apTable"anddoes notcreateanytuples.Inordertoassociatelabelswithther egionsinamap,amapmust beassociatedwithalabeltable.Therefore,theusermustcr eatealabeltableforamap 61

PAGE 62

inordertoassociatethemapwiththetable.Thecreationofl abeltableisanalogousto deningalabeltypeforamapinMQL.Alabeltablewillbeasso ciatedwithaparticular map,anditsschemawilldenethestructureandtypesofthea ttributesstoredinit(i.e., eachtupleisanalogoustoalabel).Recallthatweimposethe restrictiononalabeltable thatitmustcontainacolumnoftypeintegerwiththename region id thatwillbeused toassociateeachentryinthelabeltablewitharegioninthe map.Forexample,tocreate thetablenamed\Map1AttributeTable"inFigure 5-2 ,auserwouldusethefollowing statement: Statement5.3.2. CREATETABLEMap1AttributeTable(region id:int,crop:str) Givenalabeltable,ausercanthencreateamapwhoseregions areassociatedwith thelabelsinthelabeltablethroughan insert statement.Weassumetheexistenceofa mapconstructor,whichweindicateas map2D(stringlabelTable) ,thattakesthenameof alabeltableasanargumentandreturnsanemptymapobjectth atisassociatedwiththe labeltable.Inotherwords,themapobjectstoresthenameof thelabeltableinternally. Thus,amapcanbeinsertedintothe\MapTable"by: Statement5.3.3. INSERTINTOMapTableVALUES(1,`Map A',map2D( `Map1AttributeTable')) 5.3.3QueryingMaps Inthissection,weshowhowtheclassesofqueriesgivenabov ecanbeexpressedover thegivendatamodelformapsinspatialdatabases.Foreachc lassofqueries,weshowhow SQLcanbeextendedtoexpresstheMQLqueriesthathavebeeng ivenpreviously. InordertoexpressMQLqueriesinSQL,wemakesomegeneralob servations.First, thethreeclausesofanMQLstatement, FIND IN THAT ,correspondtotheSQL statementclausesof SELECT FROM ,and WHERE ,respectively.IntheSELECT clause,ausercanreturnamapbyindicatingthatvaluesofac olumnoftypemap2Dare returned.Thelistofmapsfoundinthe IN clauseofMQLwillbeexpressedasarelation 62

PAGE 63

inthe FROM clauseofSQL.Finally,thebooleanexpressioninthe THAT clauseofMQL willbeexpressedinthe WHERE clauseofSQL.Inlatersections,wewillshowhowthe functionsintroducedinMQLcanbeexpressedinSQL. NotethatwhenaquerythatreturnslabelsisexpressedinMQL ,alabelstructure isgiveninthe FIND clause.Thisisnecessarysincemapsinthe IN clausemayhave dierentlabelstructures,andtwomapsmayhavelabelscont ainingattributeswiththe sameidentier,butdierenttypes.Byexpressingthedesir edlabelstructureinthequery, suchcasescanberesolvedsincethetypeofthedesiredattri buteisclearlyexpressed. Therefore,weintroduceanotationtoachievethesameeect inSQL.Ifthereissome ambiguityaboutthetypeofanattributeinthe SELECT clauseofanSQLstatement becauseitreferstoanattributefoundinamaplabel,thenth etypemustexplicitly providedinthequeryintheformof( type : identier ). 5.3.3.1Mapqueries Mapqueriesconsideramapasawhole,ofteninvolvingmapope rations.Forinstance, discoveringmapswithatotalareagreaterthanagivenamoun t,orcomputingmap operationssuchasoverlayorintersectionfallintothisca tegory.InQueries 5.2.1 5.2.3 weshowedhowvariousmapqueriescanbeexpressedinMQL.Exp ressingthesame queriesinSQLisrelativelystraightforwardsincewearetr eatingmapsascolumntypes. Forexample,Query 5.2.1 canbeexpressedas: Query5.3.1. SELECTGeomFROMMapTableWHEREGeom.area() > 1000 Queriesinvolvingmapoperationsareslightlymorecomplex inSQLthanMQLsince theargumentmapsmustbeidentiedexplicitlyintherelati onsinwhichtheyreside. Query 5.2.2 mightbeexpressedas: Query5.3.2. SELECTOverlay(M1.Geom,M2.Geom)FROMMapTableM1,MapTab le M2WHEREM1.ID=1ANDM2.ID=2 63

PAGE 64

Similarly,topologicalpredicatesbetweenmaps,asexpres sedinMQLinQuery 5.2.3 canbeexpressedas: Query5.3.3. SELECTM1.GeomFROMMapTableM1,MapTableM2WHEREM2.ID =3ANDIntersects(M1.Geom,M2.Geom) Notethatthesequeriescanbeexpressedinarelativelystra ightforwardmanner,since theyaresimilarinconcepttotraditionalspatialquerieso verthetraditionalspatialtypes. Inotherwords,wearequeryingthespatialobjectasawhole, andsimplyusingoperations andpredicatesthattakeinstancesofthespatialtypesasar guments.Thisistheapproach takeninqueryingthetraditionalspatialtypes.5.3.3.2Componentattributequeries ExpressingcomponentattributequeriesinSQLisconceptua llymoresimplethan expressingtheminMQLsincethelabeltablesareimplemente dasrelations.Thismeans thatwecanusestandardSQLtoquerythem.Forexample,auser maywishtoknowthe averagetemperatureofregionswhoseaveragerainfallisgr eaterthan20inchesperyearfor regionsinMap BinFigure 5-2 .Suchaquerycouldbeexpressedas: Query5.3.4. SELECTAvg TempFROMMap2AttributeTableWHEREAvg Rain > 20 Thisworksiftheuserisawareofthenameofalabeltablefora givenmap.Ifthe userdoesnotknowthisinformation,wemustprovideameanso faccessingamap's labeltablethroughthemaptypeitself.InMQL,thisisachie vedthroughtheuseofthe CONTAINS LABEL operation.Therefore,wemustextendSQLtoincludeanopera tion thatachievesthesamefunctionality.Weintroduceanopera tioncalled GetLabelTable whichtakesamap2Dinstanceasanargumentandreturnsthere lationconsistingofthe labeltableassociatedwiththegivenmap.Givensuchanoper ation,wecanthenexpress componentattributequeriesgiveninstancesofthemap2Dty pe: Query5.3.5. SELECTAvg TempFROMGetLabelTable(SELECTGEOMFROM MapTableWHEREID=2)WHEREAvg Rain > 20 64

PAGE 65

However,queryingalabeltabledirectlydoesnotallowusto expressqueriessuchas Query 5.2.4 andQuery 5.2.5 .Thequeryaboveonlyqueriesthelabeltableofasinglemap, whereasQuery 5.2.4 andQuery 5.2.5 executeovermultiplemaps.Inordertoachievethis inSQL,werequiretheuseofa correlatedattributequery .Acorrelatedattributequery issimilarinconcepttoacorrelatedsubqueryinthatasubqu eryisrunrepeatedlyfor multiplevaluesspeciedinitscontainingquery.Correlat edattributequeriestypically requirethatattributetypesbespeciedinaquery,aswasdi scussedpreviously.For exampletoreturnallmapsthatcontainaregionwithanavera gerainfallgreaterthan20 inches,wecouldexpressthequeryas: Query5.3.6. SELECTGeomFROMMapTableM1WHEREEXISTS(SELECT* FROMGetLabelTable(M1.Geom)WHERE(integer:Avg Rain) > 20) Thus,thesubqueryisexecutedforeachmapgeometrystoredi n`MapTable'.Using thisconceptofcorrelatedattributequeries,wecanrespec tivelyexpressMQLQuery 5.2.4 andMQLQuery 5.2.5 as: Query5.3.7. SELECTGeomFROMMapTableM1WHEREEXISTS(SELECT* FROMGetLabelTable(M1.Geom)WHERE(string:Crop)='Wheat ') Query5.3.8. SELECT(integer:Avg Temp)FROMMapTableM1WHEREEXISTS( SELECT*FROMGetLabelTable(M1.Geom)WHERE(integer:Avg Rain) > 20) Notethatbecausethelabeltablesofmapsstoredinthesamec olumncanhave dierentlabelstructures,itispossiblethatsomelabelta bleswillnotcontainacolumn named\Avg Rain"withtypeinteger.Thus,ifanyerroroccursduetosche maelements notexisting,thesubquerysimplyreturnsnovaluesandtheq uerycontinuesexecuting. 5.3.3.3Componentqueries Componentqueriesaresimilarinconcepttocomponentattri butequeries,butdeal withtheregiongeometriescontainedinamapinsteadofther egionattributes.Because themapgeometryisstoredinthecolumntype map2D ,wecannotuseacorrelated 65

PAGE 66

subqueryconceptsimilartotheapproachusedincomponenta ttributequeries.Instead, wemustprovideaccesstotheregionsinamapinamannerwhich correspondstoSQL andrelationalconstructs.InMQLwewereabletoexpresscom ponentqueriesusingthe Expand operator.WecanexpressthisclassofqueriesinSQLbydeni ngthe Expand functionintermsofrelations.Therefore,wedenethe Expand functiontotakeamap geometryandreturnarelationconsistingofsingletonmaps suchthateachsingletonmap representsaregionintheoriginalmap.Furthermore,eachs ingletonmapwillhavealabel tableassociatedwithitcontainingasingleregionlabel.F orexample,ifauserwishesto returnallregionsfromamapthathaveanareagreaterthanon ethousandsquaremiles (asinMQLQuery 5.2.6 ),theycouldusethe Expand operatorinconjunctionwithan area operatordenedforregionsasfollows: Query5.3.9. SELECTM1.GeomFROMExpand(SELECTGeomfromMapTable)as M1WHEREarea(M1.Geom) > 1000 WecanalsousetheExpandoperatorincorrelatedsubqueries toidentifymapsthat containregionsthatsatisfysomepredicate.Forexample,t oreturnallmapsthatcontain aregionwithanareagreaterthanonethousandsquaremiles( asinMQLQuery 5.2.7 ),a usercouldwrite: Query5.3.10. SELECTM1.GeomFROMMapTableM1WHEREEXISTS(SELECT M2.GeomFROMExpand(M1.Geom)asM2WHEREarea(M2.Geom) > 1000) 66

PAGE 67

CHAPTER6 THEDISCRETEMODELOFSPATIALPARTITIONS Theabstractmodelofspatialpartitionsmapseachpointint heplanetoaspecic label.However,computersprovideonlyaniteresolutionf ortherepresentationofdata whichisnotadequatefortheexplicitrepresentationofabs tractspatialpartitions.In ordertorepresentmapsincomputers,a discretemapmodel isrequiredthatpreserves thepropertiesofspatialpartitionswhileprovidinganit erepresentationthatissuitable forstorageandmanipulationincomputers.Inthissection, weprovidea graphmodelof spatialpartitions ,whichisagraphtheoretic,discretemodelofspatialparti tions.Note thatthereissomeambiguityamonggraphtermsintheliterat ure,especiallyconcerning termsindicatinggraphsthatareallowedtocontainloopsan dmultipleedgesbetween pairsofvertices.Webeginthissectionbyrstprovidingan overviewofgraphtermsand denitionsthatweusetodevelopourmodel. 6.1DenitionsfromGraphTheory Ingraphtheory,agraphisapair G =( V;E )ofdisjointsetssuchthat V isasetof verticesand E V V isasetofvertexpairsindicatingedgesbetweenvertices.W e denotethesetsofverticesandedgesforagivengraph g as V ( g )and E ( g ),respectively. A multigraph isapair G M =( V;E )ofdisjointsetswithamapping E V V allowing amultigraphtohavemultipleedgesbetweenagivenpairofve rtices.A loop inagraph isanedgethathasasinglevertexasbothofitsendpoints.Am ultigraphwithloopsisa pseudograph ,andisdenedasapair G P =( V;E )withamapping E V V .Finally, a nodelesspseudograph isapseudographthat(possibly)containsedgesthatformlo ops thatconnectnoverticesandthatintersectnootheredgesor vertices.Wedeneanodeless pseudographasatriple G N =( V;E;N )(where N isthesetofnodelessedges)with mapping E V V A path isanon-emptygraph P =( V;E )suchthat V = f v 1 ;:::;v n g ;E = f v 1 v 2 ;:::;v n 1 v n g andall v i aredistinct.Givenagraph g =( V;E ),apathof g isa 67

PAGE 68

graph p =( V p ;E p )where V p V ( g ) ^ E p E ( g )where p satisesthedenitionofa path.A cycle isapathwhoserstandlastverticesareidentical,denedb yanon-empty graph C =( V;E )suchthat V = f v 1 ;:::;v n g ;E = f v 1 v 2 ;:::;v n v 1 g whereall v i are distinctand n 3.Givenagraph g =( V;E ),acycleof g isagraph c =( V c ;E c )where V c V ( g ) ^ E c E ( G )where c satisesthedenitionofacycle.The length ofa cycleisthenumberofitsedges.A polygonalarc istheunionofnitelymanystraightline segmentsembeddedintotheplaneandishomeomorphictothec losedunitinterval[0 ; 1]. Weusetheterms arc andpolygonalarcinterchangeably. Agraphis planar ifitcanbeembeddedintheplanesuchthatnotwoedgesinters ect. Aparticulardrawingofagraphisan embedding ofthegraph.Aparticularplanargraph canhavemultipleembeddingsintheplanesuchthatedgesine achembeddingaredrawn dierently.Aparticularembeddingofaplanargraphisa planegraph .Formally,aplane graphisapair( V;E )suchthat V R 2 ,everyedgeisanarcbetweentwovertices,the interiorofanedgecontainsnovertex,andnotwoedgesinter sectexceptattheirvertices. Aplanegraph g maycontaincycles.Wesayacycle c inplanegraph g is minimal ifthere doesnotexistapathin g thatsplitsthepolygoninducedby c intotwopieces.Weusethe notation C ( g )toindicatethesetofminimalcyclesinthegraph g 6.2RepresentingSpatialPartitionsasGraphs Inthissection,wedenethetypeof spatialpartitiongraphs thatisabletomodel boththestructuralandlabellingpropertiesofspatialpar titionsinagraph.Werst attempttodeneagraphbasedonthevertexandedgestructur eofapartition,butshow thatthisisnotsucientbecausethelabelsofthepartition arenotexplicitlyrepresented insuchagraph.Wethendeneanewtypeofgraphthatiscapabl eofrepresentingboth thestructuralandlabellingpropertiesofaspatialpartit ionandthatisdenedbasedon discreteconcepts.Wethenshowhowsuchagraphcanbeobtain edfromagivenspatial partition. 68

PAGE 69

Recallthatintheabstractmodelofspatialpartitions,wec anidentifyagraph structurebasedontheboundaryofapartition .Specically,weobservethatwecan identify ( ),thesetofpointsthatarevertices,and ( ),thesetofpointsetsbelonging toedgesofapartition.However,wecannotsimplyassignthe verticesandedgestoapair ( V;E )inordertoachieveagraphrepresentationof sinceitispossiblefornodelessedges tobepresentin ( ).Forexample,theboundaryoftherightmostfaceofregion A in Figure 3-1 iscomposedoftwonodelessedges;theseedgesarenodelessb ecausethelabel ofeverypointtheycontainisasetcontainingtwoattribute s(i.e.,nopointintheedge satisesthedenitionofavertexinapartition).Therefor e,wemustuseatriple( V;E;N ) consistingofthesetsofvertices,edges,andnodelessedge storepresentapartitionasa graph.Derivingtheset V fromapartition istrivialbecausewecandirectlyidentify thesetofvertexpoints ( ).Denition 3 denesthesetofalledgesof as ( );thus,it doesnotdierentiatebetweenedgesandnodelessedges.Itf ollowsthatthesetofnodeless edgesofapartition, N ,isasubsetof ( ),butwecannotidentify N bysimplyexamining labels.Intuitively,thelabelofanodelessedgeshouldnot formasubsetofthelabelofany vertex.However,inFigure 3-1 ,thelabeloftheboundaryoftheupperborderoftheleft faceofregion A andthelabelsofbothbordersoftherightfaceofregion A arethesame. Therefore,wecannotnecessarilydierentiatenodelessed gesfromedgesbycomparing labels.Wecancircumventthisproblemifwecandierentiat eidenticallylabelededges fromdierentfacesofthesameregion.Thiscanbeachievedt hroughthe rene operation. Eachnodelessedgein canbeidentiedasanedgein = rene ( )whoselabeldoesnot formasubsetofanyvertexlabel(avertexliesonanedgeinth erenementofapartition itheedgelabelisasubsetofthevertexlabel).Notethatth ereneoperationdoesnot altertheedgestructureofapartition,onlyitslabels.The refore,wecanuse = rene ( ) toidentifythesetofnodelessedges N in bysayingthateachedgein whoselabel doesnotformasubsetofanyvertexlabelin isintheset N .Theedgesof canthen becalculatedas E = ( ) N .Figure 6-1 Ashowstherenementofthepartitionin 69

PAGE 70

\"rn^ \#^ \"rn^ \^ \#r^ \"rnr#^ \"rnr^ \"rnr^ \"rnr^ \^ \"rnr#r^ A B Figure6-1.AspatialpartitionanditscorrespondingSSPG. A)Therenementofthe partitioninFigure 3-1 A.B)TheSSPGcorrespondingtoFigure A .Nodeless edgesaredashed. Figure 3-1 .Figure 6-1 BshowsthegraphrepresentationofthepartitioninFigure 6-1 A obtainedbythemethoddescribedabove(nodelessedgesared ashed).Becausederivinga graphfromapartitioninthisfashionresultsinagraphthat exactlyrepresentstheedge structureofthepartitionfromwhichitisderived,wecallt histypeofgrapha structural spatialpartitiongraph (SSPG),anddeneitformallyasfollows: Denition10. Givenaspatialpartition oftype A anditsrenement = rene ( ) ,we constructastructuralspatialpartitiongraph SSPG =( V;E;N ) with: V = ( ) E = ( ) N N = f n 2 ( ) j @ v 2 ( ): ( n ) ( v ) g TheSSPGisabletorepresentthestructuralaspectsofaspat ialpartition,butit doesnotmaintainthelabellinginformationofthepartitio n.BecauseaSSPGisdened basedonagivenpartition,thespatialmappingfortheparti tionisknown.Therefore,the labelforanyedgeorvertexinaSSPGcanbedeterminedthroug htheassociatedspatial mapping,butthisisinsucientforourpurposesaswerequir eanexplicitrepresentation oflabels.However,theSSPGhasthepropertythatitisa planenodelesspseudograph (PNP): Theorem2. Givenapartition oftype A ,itscorrespondingSSPGisaplanenodeless pseudograph. 70

PAGE 71

Proof. Thedenitionofanodelessgraphstatesthatanodelessgrap hmaycontain nodelessedges;therefore,anSSPGisnodelessbydenition .Similarly,thedenitionofa pseudographstatesthatthegraphmaycontainmultipleedge sbetweenthesamevertices andloops.AnSSPGisthereforeapseudographbydenitionbe causeitdoesnotexclude suchfeatures.NowwemustprovethataSSPGisaplanegraph.T heedgesofanSSPG aretakendirectlyfromaspatialpartition,whichisembedd edin R 2 ,indicatingthatthe SSPGisanembeddedgraph.Bythedenitionofspatialpartit ions,anedgeinapartition isaborderdenedbyaone-dimensionalpointsetconsisting ofpointsmappedtoasingle label.Furthermore,thislabelisderivedfromtheregionsw hichtheborderseparates. Assumethatthereexiststwobordersinaspatialpartitiont hatcross,whichimpliesthat theSSPGforthispartitionwillcontaintwoedgesthatinter sect.Inorderforthisto occur,theseedgesmustseparateregionsthatoverlap,whic hviolatesthedenitionof spatialpartitions.Therefore,aspatialpartitioncannot containtwobordersthatintersect, exceptatendpoints.BecausetheedgesofanSSPGaretakendi rectlyfromaspatial partition,thennotwoedgesofanSSPGcanintersect.Thus,t heSSPGisaplanenodeless pseudograph. AlthoughanSSPGcanbeeasilyobtainedfromaspatialpartit ion,usingaSSPGto modelspatialpartitionsisinadequatefortworeasons.Fir st,spatialpartitionsdepend ontheconceptoflabels,sothegraphrepresentationofapar titionmustincludealabel representation.TheSSPGdoesnotimplicitlymodelthelabe lsofregions,edges,or vertices;rather,itdependsontheexistenceofaspatialma pping.Second,theedgesin theSSPGaretakendirectlyfromaspatialpartition,whichi sdenedontheconceptof innitepointsetsthatwecannotdirectlyrepresentdiscre tely.Despitethesedrawbacks, theSSPGdoeshavethenicepropertythatbecauseaSSPGisde nedbasedonagiven spatialpartition,weknowthatanygivenSSPGis valid inthesensethatitrepresents avalidspatialpartition.Therefore,weproceedintwophas es:werstdeneatypeof graphthatiscapableofdiscretelyrepresentingthestruct uralproperties,andexplicitly 71

PAGE 72

representingthelabelingproperties,ofspatialpartitio ns.Wethenshowhowwecan derivegraphsofthistypefromspatialpartitions.Thisall owsustodeneavalidgraph representationofanygivenspatialpartition. ItfollowsfromTheorem 2 thatanembeddedgraphthatmodelsaspatialpartition suchthatitsedgesandverticescorrespondtothepartition 'sedgesandvertices, respectively,mustbeaPNP.However,aPNPdoesnotmodelthe labelingofspatial partitions.Inordertomodellabelsinagraph,wemustassoc iatelabelswithsomefeature inagraph.Inspatialpartitions,thelabelsofboundariesc anbederivedfromthelabels oftheregionstheyrepresent.Thus,itispossibletoderive alledgeandvertexlabelsina partitionfromtheregionlabels.Therefore,wechoosetoas sociatelabelsinagraphwith featuresthatareanalogoustoregionsinspatialpartition s.Wearetemptedtoassociate labelswithminimumcyclesinagraphrepresentingaspatial partition;however,thisis notabletoaccuratelymodelsituationsinwhicharegionint hespatialpartitioncontains anotherregionsuchthattheboundariesoftheregionsaredi sjoint(e.g.,theregionlabeled A 2 andtheholeitcontainsinFigure 6-1 A).Instead,weassociatelabelswith minimum polycycles (MPCs)ingraphsrepresentingpartitions.Aminimumpolycy cleinaPNP G is asetofminimumcyclesconsistingofaminimumcycle c o (theoutercycle),andallother minimumcyclesin G thatliewithin c o ,andnotwithinanyotherminimumcycle.Note thataminimumcycleofaplanegraphinducesaregioninthepl anedenedbyaJordan curve.Therefore,wecandierentiatebetweentheinterior ,boundary,andexteriorofsuch aregion.Wedenotetheregioninducedintheplanebythemini mumcycle C ofplane graph G as R ( C ).Wenowformallydeneminimumpolycycles: Denition11. Givenaplanenodelesspseudograph G ,a minimumpolycycle of G isa graph MPC =( V;E;N ) where V V ( G ) E E ( G ) N N ( G ) ,and C ( MPC ) C ( G ) containingan outercycle c o 2 C ( MPC ) andzeroormore innercycles c 1 ;:::;c n 2 C ( MPC ) suchthat: 72

PAGE 73

( i ) 8 v 2 V :( 9 d 2 C ( MPC ) j v 2 V ( d )) ( ii ) 8 e 2 E :( 9 d 2 C ( MPC ) j e 2 E ( d )) ( iii ) 8 n 2 N :( 9 d 2 C ( MPC ) j n 2 N ( d )) ( iv ) 8 c i 6 = c o 2 C ( MPC ): @R ( c i ) ( @R ( c o ) [ R ( c o ) ) ( v ) @ c j ;c k 2 C ( MPC ) j c j 6 = c o ^ c k 6 = c o ^ c j 6 = c k ^ @R ( c j ) ( @R ( c k ) [ R ( c k ) ) ( vi ) @ d 2 C ( G ) j ( @R ( d ) ( @R ( c o ) [ R ( c o ) )) ^: ( d 2 C ( MPC )) ^ ( 8 c i 6 = c o 2 C ( MPC ): : ( @R ( d ) ( @R ( c i ) [ R ( c i ) )) Thus,aMPCinducesaregionintheplanethatmaycontainhole sdenedbythe minimumcyclesthatlieintheinterioroftheoutercycle.Fu rthermore,byassociating labelswithMPCsinagraphrepresentingaspatialpartition ,wedonotneedtoexplicitly representthelabelsofedgesandverticesinthegraphsince theycanbederivedbysimply ndingallMPCsthatanedgeorvertexparticipatesin.Weden otethesetofallMPCsfor aPNP G as MC ( G ). ThesecondproblemwithSSPGsisthattheedgesaredenedasi nnitepointsets. Werequireadiscreterepresentationofedges.Therefore,i nadditiontoassigninglabels toMPCs,wedeneournewtypeofgraphsuchthatitsedgesarea rcsconsistingofa nitenumberofstraightlinesegments.Wedenethe labeledplanenodelesspseudograph (LPNP)asaPNPwithlabeledMPCs,denoted faces ,andedgesmodeledasarcsas follows: Denition12. Givenanalphabetoflabels L ,a labeledplanenodelesspseudograph isdenedbythefour-tupleLPNP =( V;E;N;F ) consistingofasetofvertices,asetof arcsformingedgesbetweenvertices,asetofarcloopsformi ngnodelessedges,andasetof faces,with: 73

PAGE 74

V R 2 E V V ( R 2 ) n where n isniteandeachedgeisanarc(arcs withendpointsin V andsegmentendpointsin R 2 ) N ( R 2 ) n where n isnite(nodelessarcloops) F f ( l 2 L ;m 2 MC (( V;E;N ))) g Recallthatinthedenitionofspatialpartitions,anunbou ndedfaceisexplicitly representedwithanemptylabelcorrespondingtotheexteri orofthepartition.Wedo notexplicitlymodelthisunboundedfaceintheLPNPfortwor easons:(i)wecannot guaranteethattheedgesincidenttotheunboundedfaceofaL PNPwillformaconnected graph,and(ii)iftheedgesincidenttotheunboundedfacedo formaconnectedgraph,we cannotguaranteethatitwillbeacycle.However,wecandete rmineifanedgeinaLPNP isincidenttotheunboundedfaceifitparticipatesinonlya singleMPC.Thisfollowsfrom thefactthateachedgeseparatestworegionsinapartition. Becauseallboundedfacesare modeledasMPCsinaLPNP,anedgethatparticipatesinonlyas inglefacemustseparate aMPCandtheunboundedface. TheLPNPallowsustodiscretelymodelalabeledgraphstruct ure,butwehave notyetdiscussedhowwecanobtainaLPNPforagivenspatialp artition.Notethat becausetheedgesofaLPNParedenedasarcs,theycannotdir ectlyrepresentedges fromapartition.Instead,eachedgeinaLPNPisanapproxima tionofanedgeinits correspondingspatialpartition.Therefore,wedenethea pproximationfunction that takesanedgefromapartitionandreturnsanarcwhichapprox imatesthatedge.Given aspatialpartition oftype A andanedgeapproximationfunction ,wederivethe correspondingLPNPinasimilarmanneraswederivedtheSSPG fromapartition.The setofverticesintheLPNPisequivalentto ( ).Inordertocalculatethenodelessedges, weconsidertherenement = rene ( ).Nodelessedgesarethenidentiedasalledges in whoselabelisnotasubsetofanyvertexlabel.Thesetofedge sisthendierence of ( )andthesetofnodelessedges.Finally,eachlabeledMPCcon sistsofthesetof 74

PAGE 75

V1 V2 E1 E2 E3 N1 N2 V = f V 1 ;V 2 g E = f E 1 ;E 2 ;E 3 g N = f N 1 ;N 2 g F = f ( A; ( f V 1 ;V 2 g ; f E 1 ;E 2 g ; ? )) ; ( A; ( ? ; ? ; f N 1 ;N 2 g )) ; ( B; f V 1 ;V 2 g ; f E 2 ;E 3 g ; ? )) ; ( ? ; ( ? ; ? ; f N 2 g )) g Figure6-2.Alabeledplanenodelesspseudographforthepar titioninFigure 3-1 .The edgesandverticesaremarkedsothatthesetsofvertices,ed ges,nodeless edges,andfacescanbeexpressedmoreeasily. approximationsoftheedgessurroundingeachregionin alongwiththelabelofthe correspondingfacein .Givenanedge e ,weusethenotation V e ( e )toindicatethesetof verticesthat e connects.Figure 6-2 depictstheLPNPforthepartitionshowninFigure 3-1 Denition13. Givenaspatialpartition oftype A ,edgeapproximationfunction ,and = rene ( ) ,wederivea LPNP =( V;E;N;F ) from asfollows: V = ( ) E = f ( e 2 ( ) j: ( ( e ) 2 N )) g N = f ( n 2 ( ) j @ v 2 ( ): ( n ) ( v )) g F := 8 r 2 ( ) j r s 2 ( ):( l; ( V m ;E m ;N m )) 2 F where : l = 1 ( r ) E m = f ( e ) j e 2 ( ) ^ e @r ^ ( e ) 2 E g N m = f ( n ) j n 2 ( ) ^ n @r ^ ( n ) 2 N g V m = S e 2 E m V e ( e ) Notethatitispossibletoapproximateedgesinapartitioni nmultipleways.Thus,a singlespatialpartitionmayhavemultipleLPNPsthatrepre sentit. InthedenitionofLPNPs,norestrictionsareplacedonthel abelsofMPCs. Therefore,itispossibleforanlabeledgraphtotthedeni tionofanLPNP,butbe labeledinsuchawaythatviolatesthedenitionofspatialp artitions.Inotherwords, aLPNPmaybelabeledsuchthatnospatialpartitionexistsfr omwhichtheLPNPcan 75

PAGE 76

bederived.AsimpleexampleofthisisaLPNPcontainingtwoM PCsthathavethe samelabelandshareanedge.Becauseedgesonlyseparatereg ionswithdierentlabels inapartition,thisLPNPcannotbederivedfromanyvalidspa tialpartition.Thus,the setofallvalidLPNPsislargerthanthesetofLPNPsthatcanb ederivedfromsome spatialpartition.WedeneaLPNPthatcanbederivedsomesp atialpartitionasa spatial partitiongraph (SPG). Denition14. A spatialpartitiongraph G isa labeledplanenodelesspseudograph such thatthereexistssomevalidpartitionfromwhich G canbederived. 6.3PropertiesofSpatialPartitionGraphs Intheprevioussection,wedenedthetypeofspatialpartit iongraphsandshowed howaSPGcanbederivedfromagivenspatialpartition.Howev er,wecurrentlydenea SPGasbeingvalidonlyifitcanbederivedfromavalidspatia lpartition.Givenalabeled graphintheabsenceofaspatialpartition,wecurrentlycan notdetermineifthegraphis aSPG.Inthissection,wediscussthepropertiesofSPGssuch thatwecandetermineifa SPGisvalidbyexaminingitsstructureandlabels. GivenaLPNPintheabsenceofasourcepartitionfromwhichit canbederived, wemustensurethatstructuralandlabellingpropertiesoft heLPNPareconsistentwith thepropertiesofspatialpartitions.Toachievethis,weex aminethepropertiesofspatial partitions,denedbyDenition 2 andDenition 3 ,andshowhowthesepropertiesare expressedinSPGsderivedfromspatialpartitions.Wethend enethepropertiesofSPGs andshowthatanyLPNPthatsatisesthesepropertiesisaSPG RecallthataSSPGisaPNP.ItfollowsfromTheorem 2 thatanygraphthatmodels theedgesofapartitionasgraphedgesandverticesofaparti tionasgraphvertices mustbeaPNP.Therefore,agraphcannotbeaSPGifitisnotaPN P.Thisisalready expressedindirectlybythedenitionofSPGsasLPNPs. Denition 2 formallydenesconstraintsonspatialmappingsthatspeci fythetypeof partitions.Theseconstraintsindicatethat(i)theregion sinapartitionareregularopen 76

PAGE 77

pointsets,and(ii)thebordersseparateuniquelylabeledr egionsandcarrythelabelsofall adjacentregions.Fromthesepropertiesofpartitions,wec anderivepropertiesofSPGs. By(i),weinferthatalledgesandverticesinaSPGmustbepar tofaMPC.Ifanedge isnotpartofaMPC,thentheedgedoesnotseparatetworegion s.Instead,itextends eitherintotheinteriorofaMPCorintotheunboundedfaceof theSPG,formingacut inthepolygoninducedbytheMPCortheunboundedface.Ifave rtexexiststhatisnot partofaMPC,thenitiseitheralonevertexwithnoedgeseman atingfromit,oritis partofasequenceofedgesthatarenotpartofaMPC.Inthers tcase,thevertexeither existswithintheregioninducedbyaMPCortheunboundedfac eoftheLPNP,forminga puncture.Inthesecondcase,thevertexexistsinasequence ofedgesthatisnotpartofa MPC,whichwehavealreadydeterminedtobeinvalid. Bythesecondpropertyofspatialpartitions(ii),weinfert hatedgesmustseparate uniquelylabeledMPCs.Therefore,therecannotbeanedgein anLPNPthatparticipates intwoMPCswiththesamelabel.Futhermore,everyregionina partitionmustbe labeled.ItfollowsthateveryMPCinaSPGmustbelabeled.Be causetheunbounded faceisnotexplicitlylabeledinaSPG,onespecialcaseexis ts:aMPCformingaholeina SPG(i.e.,labeledwith ? )cannotshareanedgewiththeunboundedface,asthiswould resultinanedgeseparatingtworegionswiththesamelabel. Denition 3 furtheridentiespropertiesofspatialpartitions.Accor dingtothis denition,edgesinspatialpartitionsalwayshavetwolabe ls,andverticesalwayshave threeormorelabels.RecallthatinLPNPs,theunboundedfac eofthegraphisnot explicitlylabeled.Therefore,inaSPG,alledgesmustpart icipateineitheroneortwo MPCs.Edgesincidenttotheunboundedfaceofthegraphwillp articipateinonlyone MPC.Therequirementthatverticeshavethreeormorelabels inaspatialpartition indicatesthatatavertex,atleastthreeregionsmeet.Itfo llowsthatinaSPG,each vertexhasatleastadegreeofthree.Furthermore,becauset heunboundedfaceisnot explicitlylabeled,verticesmusthaveatleasttwolabelsi naSPG(i.e.,avertexmust 77

PAGE 78

participateinatleasttwoMPCs).Wesummarizetheproperti esofSPGsandshowthat anyLPNPthatsatisesthesepropertiesisaSPG: Denition15. AnSPG G hasthefollowingproperties: ( i ) G isaplanenodelesspseudograph(Theorem 2 ) ( ii ) 8 e 2 E ( G ) [ N ( G ) ; 9 ( l;X ) 2 F ( G ) j e 2 E ( X ) [ N ( X ) (Denition 2 (i)) ( iii ) 8 v 2 V ( G ) ; 9 ( l;X ) 2 F ( G ) j v 2 V ( X ) (Denition 2 (i)) ( iv ) 8 v 2 V ( G ): degree ( v ) 3 (Denition 3 ) ( v ) 8 e 2 E ( G ) [ N ( G ): 1 jf ( l;X ) 2 F ( G ) j e 2 E ( X ) [ N ( X ) gj 2 (Denition 3 ) ( vi ) 8 ( l 1 ;X 1 ) ; ( l 2 ;X 2 ) 2 F ( G ) j l 1 = l 2 : ( @ e 1 2 E ( X 1 ) [ N ( X 1 ) ;e 2 2 E ( X 2 ) [ N ( X 2 ) j e 1 = e 2 ) (Denition 2 (ii)) ( vii ) 8 m 2 MC ( G ) ; 9 f =( l;X ) 2 F ( G ) j m = X (Denition 2 (ii)) ( viii ) 8 e 2 E ( G ) [ N ( G ) j jf ( l;X ) 2 F ( G ) j e 2 E ( X ) [ N ( X ) gj =1: l 6 = f?g (Denition 2 (ii)) Theorem3. AnyLPNPthatsatisesthepropertiesinDenition 15 isaSPG. Proof. ThepropertieslistedinDenition 15 indicatehowthepropertiesofspatial partitionsareexpressedinSPGs.FromTheorem 2 ,weknowthatavalidSPGmustbe aPNP.Denition 2 (i)statesthatallregionsinapartitionmustberegularope nsets. BecausethefacesinaSPGareanalogoustoregionsinaspatia lpartition,thismeansthat alledgesandverticesmustbelongtosomeface;otherwise,t heyformapunctureorcut insomefaceoftheSPG.Denition 15 (ii)andDenition 15 (iii)expressthisrequirement. Denition 2 (ii)statesthatbordersinapartitionbetweenregionscarr ythelabelsofboth regions.Thisimpliesthatanedgeinaspatialpartitionsep aratesregionswithdierent labels,andthateveryregioninaspatialpartitionhasalab el.Denition 15 (vi)and Denition 15 (vii)expressthisbystatingthatifanedgeparticipatesin twofacesofaSPG, thosefaceshavedierentlabels,andthateveryMPCinaSPGi salabeledfaceofthe SPG.Becausetheunboundedfaceisnotlabeled,wemustexpli citlystatethatnoedge 78

PAGE 79

thatparticipatesinacycleformingaholecanhaveonlyasin glelabel,asthisimpliesthat anedgeisseparatingtworegionswiththe ? label(Denition 15 (viii)).Denition 3 states thatedgesinapartitioncarrytworegionlabels,andthatve rticescarrythreeormore regionlabels.Becausetheunboundedfaceisnotlabeledina SPG,wecannotdirectly imposethesepropertiesonaSPG.Instead,weobservethatth enumberofregionlabelson avertexinapartitionindicatesaminimumnumberofregions thatmeetatthatvertex. Therefore,wecanexpressthispropertyinSPGtermsbystati ngthatverticesinaSPG musthavedegreeofatleastthree(Denition 15 (iv)).TheedgeconstraintfromDenition 3 canbespeciedintermsofaSPGbythepropertythatanedgemu stparticipatein exactlyoneortwofaces,indicatingthattheedgewillhavee xactlyoneortwolabels (Denition 15 (v)).Therefore,allpropertiesofpartitionsareexpresse dintermsofSPGsin Denition 15 ,andanyLPNPthatsatisesthesepropertiesisaSPG. WenowhavetheabilitytoeitherderiveavalidSPGfromaspat ialpartition,or verifythataSPGisvalidintheabsenceofaspatialpartitio nfromwhichitcanbe derived.Finally,weshowthatgivenavalidSPG,wecandirec tlyconstructavalidspatial partitionthatexactlymodelstheSPG'sspatialstructurea ndlabels.Recallthataspatial partitionisdenedbyaspatialmappingthatmapspointstol abelsandsatisescertain properties.Therefore,toconstructapartitionfromaSPG, wemustbeabletoderive aspatialmappingfromaSPG.Wecanconstructsuchamappingb asedonthelabeled MCPsofaSPG.EachMCPofaSPGinducesapolygonintheplaneth atisassociated withalabel.Eachofthesepolygonsisaspatialregion,andi sdenedbyitsboundary, whichseparatestheinteriorofthepolygonfromitsexterio r.Therefore,wecanidentify theinterior,boundary,andexteriorofsuchapolygon.Weus ethenotation R ( X )to denotethepolygoninducedintheplanebyMCP X .Apointthatfallsintotheinterior apolygoncanthereforebemappeddirectlytothatpolygon's label.Thelabelsofpoints belongingtoedgesintheSPGareslightlymorediculttohan dle.Eachpointbelonging toanedgeismappedtothelabelsofeachfaceinwhichtheedge participates.Ifanedge 79

PAGE 80

happenstobeincidenttotheunboundedface(itisanedgepar ticipatinginasingle minimumcycle),italsoismappedtothe ? label.Similarly,eachvertexismappedtothe labelsofeachcycleinwhichitparticipates.Ifavertexisi ncidenttotheunboundedface, itisalsomappedtothe ? label.Avertexisincidenttotheunboundedfaceifandonly ifitistheendpointofanedgethatisincidenttotheunbound edface.Inordertodene thismapping,werstprovideanotationtodistinguishbetw eenedgesandverticesthat areincidenttotheunboundedface,andthosethatarenot.We thenshowhowtoderivea spatialpartitionfromaSPG: Denition16. GivenaSPGG,wedistinguishtwosetsofedges:thesetcontai ningedges incidenttotheunboundedface,denoted E ? ,andthesetcontainingedgesnotincident totheunboundedface,denoted E b .Likewise,wedistinguishtwosetsofvertices:theset containingverticesincidenttotheunboundedface,denote d V ? ,andthesetcontaining verticesnotincidenttotheunboundedface,denoted V b .Thesesetsaredenedasfollows: E ? ( G )= f e 2 E ( G ) [ N ( G ) jjf ( l;X ) 2 F ( G ) j e 2 E ( X ) [ N ( X ) gj =1 g E b ( G )=( E ( G ) [ N ( G )) E ? ( G ) V ? ( G )= f v 2 V ( G ) j ( 9 e 2 E ? j v 2 V e ( e )) g V b ( G )= V ( G ) V ? ( G ) Denition17. GivenaSPGG,wecandirectlyconstructaspatialpartition oftype A asfollows: A = f l j ( l;X ) 2 F ( G ) g[f?g ( p )= 8>>>>>>>>>>>>>>>>>><>>>>>>>>>>>>>>>>>>: f l j ( l;X ) 2 F ( G ) ^ p 2 R ( X ) g if 9 ( l;X ) 2 F ( G ) j p 2 R ( X ) (1) f?g if @ ( l;X ) 2 F ( G ) j p 2 R ( X ) [ @R ( X )(2) f l j ( l;X ) 2 F ( G ) ^ p 2 @R ( X ) g if ( 9 ( l;X ) 2 F ( G ) j p 2 @R ( X )) ^ ( @ e 2 E ? ( G ) j p 2 e )(3) f l j ( l;X ) 2 F ( G ) ^ p 2 @R ( X ) g[f?g if ( 9 ( l;X ) 2 F ( G ) j p 2 @R ( X )) ^ ( 9 e 2 E ? ( G ) j p 2 e )(4) 80

PAGE 81

InDenition 17 ,thetypeofaspatialpartitionderivedfromaSPGconsistso ftheset oflabelsoffacesintheSPG.Themappingisthendenedbynd ingthelabelsofallfaces apointparticipatesin.Ifapoint p liesintheinteriorofaface(1),thenthelabelofthat pointwillbethelabeloftheface.If p doesnotlieintheinteriororboundaryofanyface (2),itmapstothelabel ? .If p liesonaboundarythatisnotincidenttotheunbounded face(3),itismappedtothesetoflabelsofallfacesthatinc lude p initsboundary.Note thatbecausefaceboundariesincludevertexpoints,thisca sehandlesthemappingof bothedgeandvertexpoints.Similarly,if p liesonafaceboundarythatisincidenttothe unboundedface(4),then p ismappedtothesetoflabelsfromallfaceswhichinclude p ,as wellasthelabel ? 81

PAGE 82

CHAPTER7 THEIMPLEMENTATIONMODELOFSPATIALPARTITIONS Atthispoint,wehaveanabstractmodelofMapAlgebrathatpr eciselydenesthe semanticsofmapsandtheiroperationsandpredicates.Furt hermore,wehaveshownhow torepresentmapsinadiscretemannersuchthattheymaintai nthepropertiesofthe abstractmodel.Inthischapter,weprovideanimplementati onmodelofMapAlgebra consistingofadatamodelformapsandalgorithmsforcomput ingmapoperations. Furthermore,weshowhowoperationsovermapscanbecombine dtoformnewmap operations.Wethendescribeaprototypeimplementationof MapAlgebraandperforma performancecomparisonoftheMapAlgebraimplementationw ithanexistingGIS. 7.1Map2D:anImplementationModelofMapAlgebra TheimplementationmodelofmapAlgebratakesintoaccountt heabstractand discretemodelsofspatialpartitions,aswellastheuservi ewofmapsindatabases presentedinChapter 5 .Becausethegoalofthisthesisistoincorporatemapsasrs t-class citizensindatabases,ourimplementationmodelisdesigne dtoimplementMapAlgebra inadatabase.Therefore,thedatamodelandalgorithmsassu metheexistenceofa databasethatcansupportatypecalled Map2D eithernativelyorthroughsomeextension mechanism.7.1.1ADataModelForRepresentingSpatialPartitions ThedatamodelfortheimplementationmodelofMapAlgebrafo llowstheideas presentedinChapter 5 foradatamodelofmapsindatabases.Recallthatthismodeli s centeredaroundtheconceptofstoringmaplabelsinatradit ionaldatabasetablesothat traditionalSQLqueriescanbeposedoverthem,whilethemap geometryisstoredina databasecolumntype.Wefollowthesameapproachinourimpl ementationmodelofMap Algebra.Inordertoexplaintheconceptsoftheimplementat ionmodelmoreclearly,we willreferthemapshowninFigure 7-1 throughoutthefollowingdiscussion. 82

PAGE 83

industrial commercial Figure7-1.Amapshowinganindustrialandcommercialzone. Thelabelportionofamapisimplementednearlyidentically totheexplanationgiven inChapter 5 .Thelabelsofamaparestoredastuplesinadatabasetable.W eimpose therestrictionthatatablecontainingmaplabelsmustcont ainacolumnnamed region id oftypeintegerthatwillbeusedtoassociatealabelwithare gioncontainedinamap geometry.Theadvantageofthisapproachisthatthelabelta blecanbeusedinstandard SQLquerieswithoutanySQLextensions.Also,labelscanbem anipulatedwithstandard SQL,andnospecialpurposelabeloperationsmustbeintrodu ced. Thegeometryportionofamapismorecomplexthanthelabelpo rtion.Ourgoalis toincorporatethegeometryportionofamapdirectlyasacol umntypeinadatabase. Therefore,wemustimplementthegeometryportionasasingl eobjectthatcanbe incorporatedintoaDBMSthroughextensionmechanismsorth roughextendingthe DBMScodeitself.Thereareseveralconsiderationsthatmus tbeaddressedinthe designofthegeometry:(i)themapgeometrymustsupportmap operationsthatwill beperformedoverit;and(ii)theconceptofregionsmustbem aintainedinthegeometry andmapregionsmustbeabletobeidentied,associatedwith labelsinalabeltable,and reconstructed. Inordertoaddresstherstconcern,wemaketheobservation thatnearlyallmap operationscanbeexpressedintermsofthe intersect and relabel operationspresentedin theabstractmodelofMapAlgebra[ 65 83 87 ].Althoughtherelabeloperationcanhave geometricconsequencesinamap,itisprimarilyanoperatio noverlabels.Theintersect operation,however,isprimarilyageometricoperationtha thasconsequencesregardingthe labelsofamap.Becausegeometricoperationstendtobemore computationallyintensive 83

PAGE 84

thanlabeloperations,wefocusthedesignofthemapgeometr yontherequirementsof theintersectoperation.InChapter 2 ,weshowedthatgeometricoperationsarecomputed optimallybyusingaplanesweepalgorithm.Thus,aplaneswe epalgorithmisanideal choiceforimplementingtheintersectoperation,andwewil ldesignourdatamodelbased ontherequirementsforaplanesweepalgorithm. Theplanesweepalgorithmrequiresaspecicinputstructur eforgeometricobjects; specically,geometricobjectsarerequiredtoberepresen tedasasequenceof halfsegments orderedin halfsegmentorder .For regions ,thisisachievedasfollows:wedenethetype halfsegment r = f ( s;d ) j s 2 segment;d 2 bool g where segment isthetypeincorporating allstraightlinesegmentsboundedbytwo points p and q ,anda point isacoordinate ( x;y ).Ahalfsegmentisahybridbetweenapointandasegmentsinc eithasfeatures ofbothgeometricstructures.Forahalfsegment h =( s;d ),if d istrue(false),the smaller(greater)endpointof s isthe dominatingpoint of h ,and h iscalleda left ( right ) halfsegment .Hence,eachsegment s ismappedtotwohalfsegments( s;true )and( s;false ). Furthermore,halfsegmentsaretypicallyannotatedwithan interior-above rag,which indicateswhethertheinterioroftheregionliesaboveorbe lowthehalfsegment.In additiontotheuseofhalfsegments,therepresentationofa regionobjectrequiresan orderrelationonhalfsegments.Let dp beafunctionwhichyieldsthedominatingpoint ofahalfsegment.Fortwodistincthalfsegments h 1 =( s 1 ;d 1 )and h 2 =( s 2 ;d 2 )witha commonendpoint p ,let betheenclosedanglesuchthat0 < 180 .Letapredicate rot ( h 1 ;h 2 )betrueif,andonlyif, h 1 canberotatedaround p through tooverlap h 2 ina counterclockwisedirection.Wedeneacompleteorderonha lfsegmentsas: h 1
PAGE 85

S S S S S S 1 2 3 4 5 6 Figure7-2.Acomplexregionobjectwitheachsegmentlabele d. Sinceasegmentcanbesubstitutedbytwohalfsegments,areg ionobjectcanbe implementedasanorderedsequence(array)ofhalfsegments .Asanexample,Figure 7-2 showsacomplexregionobject(withasinglefacecontaining ahole)whosesegmentsare labeled s i .Let h li =( s i ;true )and h ri =( s i ;false )denotetheleftandrighthalfsegmentsof asegment s i respectively.Theorderedsequenceofhalfsegmentsforthi scomplexregionis h h l1 ;h l2 ;h l6 ;h l4 ;h r4 ;h l5 ;h r2 ;h l3 ;h r5 ;h r6 ;h r3 ;h r1 i Althoughthisdenitionofhalfsegmentsissucientforcom putinggeometric operations,mapsmusttakeintoaccountthelabelsofregion sinadditiontogeometric information.Therefore,wemodifythehalfsegmentdeniti ontoincluderegionlabels insteadofaninterior-aboverag.Therefore,eachhalfsegm entwillcontaintworegion labelsrepresentedasintegers,thelabelfortheregiontha tliesabovethehalfsegment,and thelabelfortheregionthatliesbelowthehalfsegment.Thu s,wehave halfsegment = f ( s;a;b;d ) j s 2 segment;a 2 Z ;b 2 Z ;d 2 bool g .Weassumethattheregionlabels correspondtoregionsinalabeltableidentiedbya region id column,ortosomespecied valueindicatingtheexteriorofamap. Therefore,werepresentamapgeometryasasequenceoforder edhalfsegments,each labeledwiththeregionthatliesabovethehalfsegment,and theregionthatliesbelow thehalfsegment.Notethatthedenitionofspatialpartiti ongraphsdenesaSPGbyits edgesandnodelessedges,whichinturnaredenedasconnect edsequencesofstraightline segments.Thehalfsegmentsintheimplementationmodelofs patialpartitionsrepresent thesestraightlinesegmentsinaSPG.Therefore,thegeomet ryofamaprepresentedas aSPGandamaprepresentedintheimplementationmodelofspa tialpartitionsinthe 85

PAGE 86

ID: int Geom: map2D 1 1 2 region_id: intZone: str 1 2 Industrial Commercial MapTable Map1AttributeTable 12 S 2 S 5 S 4 S 1 S 3 A B Figure7-3.Twodierentviewsofamap.A)Themaprepresente dintheimplementation modelofMapAlgebra.B)Themapwithitssegmentslabeled. sameembeddingspaceareidentical.Furthermore,itisposs ible,basedonregionlabels,to reconstructanSPGgivenamaprepresentedintheimplementa tiondatamodelofMap Algebra.Thismeansthatthepropertiesofspatialpartitio nsdenedoverSPGscanbe checkedandenforcedattheimplementationlevel. AsanexampleoftheimplementationdatamodelofMapAlgebra ,considerthemap showninFigure 7-1 .Ifwehaveadatabasethatisawareofthecolumntype map2D that implementsthegeometryportionofamap,aswehaveshown,th enthemapinFigure 7-1 couldbestoredinthedatabaseasshowninFigure 7-3 A.Ifwelabelthesegmentsof themapasshowninFigure 7-3 Bandweassumearegionlabelof0fortheexterior,then thehalfsegmentsinhalfsegmentorderwouldbe:( h l1 ; 1 ; 0),( h l2 ; 0 ; 1),( h r1 ; 1 ; 0),( h l3 ; 1 ; 2), ( h l5 ; 2 ; 0),( h r2 ; 0 ; 1),( h r3 ; 1 ; 2),( h l4 ; 0 ; 2),( h r4 ; 0 ; 2),( h r5 ; 2 ; 0)where h li =( S i ;j;k;true )and h ri =( S i ;j;k;false )forsegment S i 7.1.2AlgorithmsforMapOperations InChapter 2 ,wesawthatresearcheortshaveprovidedalgorithmstocom pute spatialoperationsovermapgeometries.Inthissection,we providealgorithmsfor thethreefundamentalmapoperationsof intersect relabel ,and rene basedonthe implementationdatamodelofMapAlgebra.Wethenshowhowth eseoperationscanbe combinedtoformnewoperations.Notethatintheliterature ,theintersectoperationis frequentlyreferredtoas overlay 86

PAGE 87

A Intersection C B A C B A,C A,B Figure7-4.Theresultofthe intersect operationappliedtotwomaps. 7.1.2.1Intersect Theintersectoperationanditsvariantshavereceivedsign icantattentionin database,computationalgeometry,andGISliterature.Our implementationfollows theconceptspresentedinthesepapers,butistailoredtoou rparticulardatamodel.Recall thattheintersectoperation,asdenedintheabstractmode l,takestwomapsandreturns athirdsuchthateachpointinthethirdmapcarriesthelabel assignedtoeachidentical pointintheargumentmaps.Figure 7-4 depictstwosamplemapsandtheresultofthe intersectoperationappliedtothem. Inessence,ourintersectionalgorithmisidenticaltoatra ditionalplanesweep algorithminthatittraversestheargumentmapsinhalfsegm entorderandcomputes theintersectionsoflinesegments,andtheresultingregio nsintheresultmap.Themain dierenceinouralgorithmtotraditionalplanesweepalgor ithmsisthehandlingofregion labels.Recallthatregionsintheresultofanintersection algorithmwillcarrylabelsfrom bothargumentmaps.Therefore,wemustdeterminethelabels ofallregionsintheresult mapinadditiontocomputingthegeometricintersectionoft heargumentmaps.We achievethisintwosteps.First,astheplanesweepalgorith mprogresses,wemarkeach halfsegmentwiththelabelsofallregionswhoseinteriorsd irectlyborderthehalfsegment, orcontainthehalfsegment.Wecallthis labelaggregation .Forexample,Figure 7-5 shows twomapsrepresentedintheimplementationmodelofMapAlge bra,completewithregion 87

PAGE 88

AB r r r r C Figure7-5.Aggregatingmaplabelsinanintersectoperatio n.A)Therstargumentmap. B)Thesecondargumentmap.C)Thetheresultofaggregatingt heargument maps'labelsduringanintersectoperation. labelsonthesegments.Thethirdmapshowstheaggregatedla belsasaresultoflabel aggregationduringanintersection.Notethatsegmentstha tlieintheinteriorofaregion fromoneoftheoriginalmapswillhavethelabelofthatregio nonbothsidesofthe halfsegment. Aggregatedlabelsprovidetheinformationnecessarytoide ntifythelabelsfrom theoriginalregionsthatshouldbeappliedtoaregioninthe resultofanintersection oftwomaps.However,thehalfsegmentdenitionusedbythei mplementationmodelof MapAlgebraonlyallowstwointegerstobeusedasregionlabe ls.Therefore,inaddition tolabelaggregation,weusea labelmapping whichmapsaggregatedlabelstoanew labelvaluethatuniquelyidentiestheregion.Itisstraig htforwardtoimplementsucha mappingusinganAVLtreewiththesearchkeyconsistingofth epairoflabelsfromthe originalmaps.Therefore,eachregionintheresultmapthat consistsofanoverlapping portionofregionsfrombothargumentmapswillhaveanaggre gatelabel,andthat aggregatelabelwillbemappedtoanewregionlabelintheres ult.Astheplanesweep 88

PAGE 89

progressesduringanintersectalgorithm,theresultmapis annotatedwiththeresultofthe labelmapping,nottheaggregatedlabels. Thenalproblemthatmustbeaddressedishowtodetermineth eaggregatelabels. Astheplanesweepalgorithmprogresses,itmaintainsasort edlistofhalfsegmentscalled the statusstructure thatcontainsallhalfsegmentsthatintersectthesweeplin e.These halfsegmentsaresortedintheorderaccordingtowherethey intersectthesweepline. Ifweassumethesweeplineisvertical,thenthehalfsegment saresortedwithrespect tothe y coordinateofthepointwheretheyintersectthesweepline. Weassumethat eachhalfsegmentinthestatusstructureismarkedwitharag indicatingwhichofthe originalmapsitbelongsto.Giventhisinformation,wearea bletocomputetheaggregate labelsforahalfsegmentbasedonthehalfsegmentbelowitin thestatusstructure.For example,assumethatoneargumentmaptotheintersectopera tioniscalled A andthe other B .Whenahalfsegment h frommap A isaddedtothestatusstructure,welookat thehalfsegmentimmediatelybelowitinthestatusstructur e,halfsegment j .Notethat welookatthehalfsegmentbelowthecurrentoneduetothehal fsegmentorderingdened previously(allhalfsegmentsthatarelessthanthecurrent halfsegmentwillalreadybe presentinthestatusstructure,orwillhavebeenprocessed ).If h and j arefromdierent maps,thenwelookatthelabelfrom j fortheregionthatliesaboveit.Ifthatregion istheexterior,thenitisclearthat h doesnotintersectaregionfromtheopposingmap (again,thisisduetothehalfsegmentordering).Iftheabov elabelfor j isaregionlabel, then h liesintheinterioroftheregionboundedbyhalfsegment j .Therefore, h ismarked withthelabeloftheregionabove j forbothitsbelowandabovelabels.Ifhalfsegment h and j arefromthesamemap,thenwecopyanyaggregatedlabelsfrom j to h .Thisis becauseboth h and j lieinthesameregionfromtheopposingmap,andthus,should be aggregatedwiththatregion'slabel. Aspecialcaseoflabelaggregationoccurswhentwohalfsegm ent h and j ,respectively fromeachargumentmap,overlapalongaline.Inthiscase,th eabovelabelfromeach 89

PAGE 90

1 ; 2 3 A B Figure7-6.Theresultoftheplanesweepportionoftheinter sectalgorithmforthemaps showninFigure 7-5 .A)Thelabeledgeometry.B)Themapping. halfsegmentiscombined,andthebelowlabelfromeachhalfs egmentiscombinedtoform theaggregatelabel.Becauseaboundaryispresentfromregi onsfrombothmaps,then neither h or j lieintheinteriorofanotherregion,sonolabelwillbeaggr egatedto both theaboveandbelowlabelsofeitherhalfsegment. Theresultoftheplanesweepportionoftheintersectalgori thmwillbeanewmapin theimplementationmodelofMapAlgebraandalabelmappingt hatmapspairsoflabels fromtheoriginalmaps,tolabelsinthenewmap.Thus,givent hemapsinFigure 7-5 A andFigure 7-5 B,theresultatthispointisshowninFigure 7-6 Finally,thelabeltableforthenewmapmustbeconstructedb asedontheinformation fromthelabeltablesoftheoriginalmaps.Thenewlabeltabl econtainsallcolumnsfrom thelabeltableoftheoriginalmaps,exceptitwillcontaino nlyasingle region id column. Furthermore,eachcolumnnamewillhavetheinteger1or2app endedifitcamefromthe labeltableintherstorsecondargumentmaptotheintersec toperation,respectively. Thisensuresthatnonamingconrictsoccur. Thelaststepoftheintersectalgorithmistopopulatethene wlabeltable.First,all labelsforregionsintherstargumentmapthathaveportion sthatdidnotintersectany regionfromthesecondmapareaddedtothelabeltable.These regionscanbedetermined duringtheplanesweepandkeptinalist.Second,thesamepro cedureisdoneforregions inthesecondargumentmapthatcontainaportionthatdoesno toverlapanyregion 90

PAGE 91

SFHJPO@JEJOUEFTDSJQUJPOTUS SFHJPOPGJOUFSFTU .BQ"UUSJCVUF5BCMF SFHJPO@JEJOUEFTDSJQUJPOTUS IJHIUFNQFSBUVSFBSFB .BQ"UUSJCVUF5BCMF A B SFHJPO@JEJOUEFTDSJQUJPOTUS SFHJPOPGJOUFSFTU .BQ"UUSJCVUF5BCMF SFHJPOPGJOUFSFTUIJHIUFNQFSBUVSFBSFB IJHIUFNQFSBUVSFBSFB EFTDSJQUJPOTUS C Figure7-7.Theresultinglabeltablefromanintersectoper ation.A)Thelabeltablefor themapshowninFigure 7-5 A.B)Thelabeltableforthemapshownin Figure 7-5 B.C)Thelabeltablecomputedastheresultofanintersect operation. fromtherstargumentmap.Notethatfortheselabels,theva luesincolumnsfromthe opposingmapwillbegivendefaultoremptyvalues.Then,the mappingfromaggregate labelstonewregionlabelsisusedtoconstructthelabelsfo roverlappingregionsfromthe argumentmaps.Thus,ifthelabeltablesforthemapsshownin Figure 7-5 AandFigure 7-5 BareassumedtobethoseshowninFigure 7-7 AandFigure 7-7 B,thethelabeltable oftheirintersectionwouldbethetableshowninFigureFigu re 7-7 C.Thealgorithmsfor theseproceduresaregiveninAlgorithm 2 andAlgorithm 1 Itisknownthatasweeplinealgorithmcanrunoptimallyin O ( n lg n + k )timefor inputmapswithatotalof n segmentsand k intersections.Furthermore,ouralgorithm utilizesamappingofregionlabelsimplementedasanAVLtre e.Therefore,wemust takeintoaccountthetimecomplexityofaddingregionlabel s.Intheworstcase,every regionfromonemapcanintersecteveryregionfromtheoppos ingmap.Therefore,for twomapsrespectivelycontaining r and s regions,thecomplexityofcomputingthe regionlabelmappingis O ( rs lg rs ).However,thenumberofintersectingregionsintwo mapstendstobelow,especiallycomparedtothenumberofseg mentsinthemaps. Furthermore,geometriccongurations,inpractice,typic allydonotapproachsuchextreme 91

PAGE 92

Algorithm1 :Theplanesweepportionofthe intersect algorithm. Input :Twomaps M and P asdenedbytheimplementationmodelofMap Algebra.Anemptymapping A oflabelsfromtheoriginalmapstolabelsin theresultmap.Emptylists L M and L N toholdlabelsfromtheoriginal mapsthatexistintheresultmap. Output :Map Q Initializesweeplinestructures. while notendofsweep do 1 if h isalefthalfsegment then 2 Advancesweeplineto h h istheleft-mosthalfsegmentyettobeprocessed; 3 Find j ,thehalfsegmentbelow h inthestatusstructure; 4 if h and j arefromdierentmaps then 5 Aggregatetheaboveandbelowlabelsfor h basedon j ; 6 Updatethemapping A ifanyoverlappingregionsaredetected; 7 end 8 Updatethelist L M ifnooverlappingregionsaredetectedforalabelfrom 9 M ; Updatethelist L N ifnooverlappingregionsaredetectedforalabelfrom N ; 10 else 11 Ifoverlappingregionsexists,update h 'slabelbasedonmapping A ; 12 Add h anditscorrespondinglefthalfsegmentto Q ; 13 end 14 end 15 casesofmanyregionsoverlappingmanyotherregions.Wewil lproviderunningtimes ofanimplementationofthisalgorithmoveractualspatiald atainlatersectionsthat supporttheseclaims.Therefore,therunningtimeofthisal gorithmintheworstcaseis O ( n lg n + k + rs lg rs ),withthe n lg n + k termstypicallydominatingtherunningtime. 7.1.2.2Relabel Therelabeloperation,asdenedbytheabstractmodelforma ps,takesamapanda relabelingfunctionwhichisthenusedtoalterthelabelsof amap.Arelabelingmayhave geometricconsequences.Forinstance,relabelingaregion totheexteriorlabeleectively removesaregionfromamap.Anotherexampleisrelabelingar egionsuchthatitsnew labelisidenticaltoanadjacentregionwillmergethetwore gions,causinganyboundaries thatexistbetweenthemtodisappear. 92

PAGE 93

Algorithm2 :Thealgorithmtocomputethelabeltableforintersectingt womaps. Input :Thelabeltablesfortwomaps M L and P L .Amapping A oflabelsfromthe originalmapstolabelsintheresultmap.Lists L M and L N oflabelsfrom theoriginalmapsthatexistintheresultmap. Output :Labeltable Q L Createthelabeltable Q L ; 1 for eachregionlabelin L M do 2 Computeatuplefor Q L consistingoflabelattributesfrom L M anddefault 3 valuesforattributesfrom L N ; Insertthenewtuplein Q L ; 4 end 5 for eachregionlabelin L N do 6 Computeatuplefor Q L consistingoflabelattributesfrom L N anddefault 7 valuesforattributesfrom L M ; Insertthenewtuplein Q L ; 8 end 9 for eachentryinmapping A do 10 Themappingentryconsistsofregionlabels r M r N ,and r Q forregionlabelsin 11 M N ,and Q ,respectively; Computeatuplefor Q L consistingoflabelattributesfrom L M and L N with 12 region idsequalto r M and r N ,respectively; Insertthenewtuplewithregion id r Q in Q L ; 13 end 14 Fromanimplementationperspective,deningamethodforau sertocreatea relabelingfunctionthatcanthenbepassedtoanoperationi snon-trivial.Therefore,we approachtheproblemofrelabelingfromadierentperspect ive.Ourapproachistoallow ausertomodifyalabeltableforamap,andthenrunageneralr elabelingoperationthat determinesanygeometricimplicationsofthemodications tothelabeltable,andupdates themapgeometryaccordingly.Thisapproachdoesnotrequir eamethodofpassinga relabelingfunctiontotherelabeloperation,whilenotsac ricinganygenerality. Aswasbrierymentionedintheexamplesabove,therelabelin goperationcanhave twogeometricconsequence:(i)labelsmayberemovedfromal abeltable,whichimplies thattheregionwiththatlabelhasbeendeleted;and(ii)ala belinthelabeltablemay bealteredsuchthatitisidenticaltoanotherlabelinthela beltable,meaningthattwo regionshavebeenmergedintoasingleregion(requiringany sharedboundariesbetween 93

PAGE 94

theregionstoberemoved).Thus,ourrelabeloperationmust beabletodetectandenforce thesechangesinthemapgeometry. Therelabeloperationconsistsoftwoparts,aduplicatelab elidenticationpart, andageometricconsistencyenforcementpart.Theduplicat elabelidenticationpart identieslabelsinthelabeltablethatareidentical,butt hathavedierentregion id values.ThisisachievedbycomputingaCartesianproductof alabeltablewithitself,and thendisregardingalltuplesthatarenotidenticalexceptf ortheirregion ids.Theresultis arelationcontainingpairsofidenticallabelsthatbelong todierentregions.Thisrelation istraversed,andamappingisconstructedsuchthattheregi on idvalueofduplicatelabels aremappedtothesameregion idvalue.Furthermore,alistisconstructedofallregion id valuesthatexistinthelabeltable. Oncethemappingofduplicatelabelsandthelistofregion idsinthelabeltableare constructed,theyareusedtodeterminechangestothemapge ometry.Thisisachieved bytraversingthehalfsegmentsequenceofthemapgeometry. Foreachhalfsegment,the regionlabelfortheregionabovethehalfsegmentischecked againstthelabelmappingand labellist.Iftheregionlabelisnotinthelabellist,thent hecorrespondinglabelhasbeen removedfromthelabeltable,andtheregionshouldnolonger existinthemap.Therefore, theregionlabelforthehalfsegmentischangedtotheexteri orlabel.Iftheregionlabelis inthelabellist,thenthemappingischecked.Ifthelabelex istsinthemapping,thenit ischangedtothelabeltowhichitismapped.Thesameprocedu reisperformedforthe labeloftheregionbelowthecurrenthalfsegment.Finally, oncetheaboveandbelowlabels ofthehalfsegmenthavebeenprocessed,analcheckisperfo rmedtoensurethatthe aboveandbelowlabelsarenotidentical.Iftheselabelsare identical,thenthehalfsegment borderstworegionswithidenticallabels,andthus,isremo ved.Algorithm 3 summarizes therelabelalgorithm. Givenamapwith r regionsand n halfsegments,ittakes O ( r 2 )timetocomputethe Cartesianproduct,sinceeachregionhasasinglelabel.The mappingofregionlabels 94

PAGE 95

Algorithm3 :Therelabelalgorithm. Input :Amap M anditscorrespondinglabeltable L M Output :Map M withthegeometricchangesimpliedbyitslabeltable L M applied. ComputetheCartesianproduct L M L M ; 1 Keeponlythetuplesin L M L M thathavedierentregion idsandidenticallabels; 2 Createmapping A thatmapsregion idsforequivalentlabelstothesameregion id; 3 Createlist V ofregion idsin L M ; 4 for eachhalfsegment h in M do 5 Gettheabovelabel a of h ; 6 Getthebelowlabel b of h ; 7 if a existsinmapping A then 8 Replace a withthevaluetowhichitmaps; 9 end 10 if a doesnotexistsinlist V then 11 Replace a withtheexteriorlabel; 12 end 13 if b existsinmapping A then 14 Replace b withthevaluetowhichitmaps; 15 end 16 if b doesnotexistsinlist V then 17 Replace b withtheexteriorlabel; 18 end 19 if a = b then 20 Remove h from M ; 21 end 22 end 23 canbeimplementedusinganAVLtree,whichresultsinacompl exityof O ( r lg r ).An AVLtreecanalsobeusedtoimplementthelistofregion ids,whichthenfacilitates searchingthelistin O ( r lg r ).Finally,thehalfsegmentlistmustbetraversedonce, whichtakeslineartime O ( n ).Therefore,thetotaltimecomplexityforthisalgorithmi s O ( n + r 2 + r lg r ).Becausethenumberofregionsinmaptendstobesmallcompa redto thenumberofhalfsegments,thisalgorithmperformswellin practice.Furthermore,itis possibletocreatespecializedrelabelalgorithmsforspec ictypesofrelabelingthatare muchfaster,butthisalgorithmisgeneralinthesensethati tcancorrectamapgeometry withrespecttoanymodicationsausermakestoalabeltable .Thisturnsouttobe 95

PAGE 96

veryvaluablewhenusingrelabelinconjunctionwithothere xistingoperationsinorderto createnewoperations.7.1.2.3Rene Thereneoperation,aswasdenedpreviously,relabelsreg ionfacessuchthatevery regioninamaphasonlyasingleface.Inotherwords,anyregi onsthatconsistofmultiple facesinamapwillbealteredsuchthateachfaceisasinglere gioninthemapaftera reneoperationhasbeenperformed.Intheimplementationm odelofMapAlgebra, thisisachievedbyalteringthelabeltableofamapsuchthat twofacesofaregionwill haveuniquelabels,andeveryfaceofaregioninamapwillhav eauniqueregion id.We computethisintwosteps.First,themapgeometryismodied sothateachregionfaceis identiedbyauniqueregion id.Second,thelabeltableismodiedsothateveryregion id inthemapgeometryreferstoauniquelabelinthelabeltable Therststepoftherenealgorithmrequiresatechniquekno wnas cyclewalking Inessence,giventheleftmosthalfsegmentofacycle(i.e., aregionfaceinamap),it ispossibletondeachsuccessivehalfsegmentthatmakesup thecycleofhalfsegments eciently.First,wepresentthealgorithmtowalkthecycle sina region .Wethenextend themethodtoworkoncyclesinamap.Wethendiscussthesecon dpartoftherene operation WalkingCyclesinRegions Becausethisthissectiondealswithregions,wewillassume ahalfsegmentstructure asdenedforregions;i.e.,ahalfsegmentcontainsasegmen t,abooleanragindicatingif itisaleftorrighthalfsegment,andabooleanragindicatin giftheinterioroftheregion liesaboveorbelowthehalfsegment.Furthermore,wedevelo pthisalgorithmtodetermine the componentview ofaregion.Inessence,thealgorithmdetermineswhichcycl esina regionareoutercycles,whichareholecycles,andtowhicho utercycleeachholebelongs. Italsodeterminesifaregionisvalid.Althoughallofthese propertiesarenotrequiredfor thecyclewalkportionoftherenealgorithm,theyarenonet helessuseful,soweinclude 96

PAGE 97

them.Weassumethattheinputtoouralgorithmisasequenceo forderedhalfsegments. Iftheinputrepresentsaregion,thealgorithmreturnsther egionwithitscyclicstructure information;otherwise,thealgorithmexitswithanerrorm essageindicatingtheinput sequencedoesnotformasemanticallycorrectregion.Webeg inbyprovidingahighlevel overviewofthealgorithmandthenpresentthealgorithmand provideadiscussionofits details. Ingeneralterms,thealgorithmmustidentifyallcyclespre sentinthehalfsegment sequence,andclassifyeachcycleaseitheranoutercycleor aholecycleofaparticular face.Toaccomplishthis,eachhalfsegmentis visited oncebythealgorithm.Notethatdue tothedenitionofthetype region ,eachsegmentbelongstoexactlyonecycle.Whena halfsegmentisvisited,thealgorithmmarksthehalfsegmen tindicatingtowhichfaceand cycleitbelongs,andwhetherthatcycleisanoutercycleora holecycle.Thealgorithm doesnotaltertheinputwhenmarkinghalfsegments,rathera parallelarraytotheinput sequenceisusedtorepresentthecycleinformation.Thealg orithmvisitshalfsegmentsby steppingthroughtheinputlistsequentially. Thersthalfsegmentintheinputsequencewillalwaysbepar toftheoutercycle ofaface,duetothedenitionofcomplexregionsandthehalf segmentorderingdened previously.Therefore,itcanbevisitedandmarkedcorrect ly.Onceahalfsegmenthasbeen visited,itispossibletovisitandcorrectlymarkallother halfsegmentsinthecyclethat itbelongstoinaprocedurewhichwedenoteasthe cyclewalk .Thus,allhalfsegments thatformthecycletowhichthersthalfsegmentintheinput sequencebelongsarethen visited.Thealgorithmthenbeginssteppingthroughtherem aininghalfsegments.The nextunvisitedhalfsegmentencounteredwillbepartofanew cycle.Thealgorithmthen visitsthisnewhalfsegment.Thealgorithmcandeducewheth erthishalfsegmentisan outercycleofanewfaceoraholeinanexistingfacebyexamin ingwherethehalfsegment liesinrelationtoalreadyknowncycles.Todeterminethis, weuseaplanesweepalgorithm tostepthroughthehalfsegments.Thus,wecantakeadvantag eoftheplanesweepstatus 97

PAGE 98

structuretondwhetherornotthecurrenthalfsegmentlies intheinteriorofapreviously visitedface.Oncethenewhalfsegmentisvisited,weperfor macyclewalkfromit.Then, thealgorithmcontinuessteppingthroughtheinputlistunt ilitreachesanotherunvisited halfsegment,visitsit,andrepeatsthisprocedure.Thealg orithmisshowninAlgorithm 4 ToproperlydescribethealgorithmoutlinedinAlgorithm 4 ,weintroduceseveral notations.Thefunction info ( h )foragivenhalfsegment h returnsitscyclicinformation, thatis,its owning cycle,andifpartofahole,itsowningface.Acycle owns ahalfsegment ifthehalfsegmentispartoftheboundaryofthecycle,andaf aceownsaholeiftheholeis insidetheface.Wedenethefunction NewCycle ( h )toannotate h withauniqueidentier foranewcycle.Let f beahalfsegmentbelongingtoanoutercycleofaface.Thefun ction Owns ( h;f )annotatesthehalfsegment h toindicatethatitbelongstoaholeintheface thatowns f .Finally,weemploythefunction Visit ( p )tomarkapoint p ashavingbeen visited.Thefunction Visited ( p )isusedtoverifyispoint p wasmarkedasvisitedalready. Pointsareonlymarkedasvisitedwhenahalfsegmentwithdom inatingpoint p hasbeen visitedduringthecyclewalk.Wemarkpointsasbeingvisite dinordertoidentifythe specialcaseofaholecyclethatmeetstheoutercycleofafac eatapoint.Thefunction Visited ( h )isusedtoverifyifhalfsegment h hasbeenvisitedalready.Ahalfsegmenthas beenvisitedifithasbeenannotatedwithface/holeinforma tion.Forahalfsegment h ,we candirectlycomputeitscorrespondingright(left)halfse gment h b ,whichwecallits brother byswitchingitsbooleanragindicatingwhichendpointisdo minant.Wedenethenext halfsegmentinthecycletowhich h belongsas h + suchthatthedominatingendpointof h b isequaltothedominatingpoint dp ( h + )and h + 6 = h b and h + isthersthalfsegment encounteredwhenrotating h b clockwise(inanoutercycle)orcounter-clockwise(inahol e cycle)arounditsdominatingpoint.Theprevioushalfsegme ntinthecycleissimilarly denedas h ClassifyingOuterandHoleCycles: Byusingasweepline,thealgorithmsteps throughthehalfsegmentsequencetondthesmallestunanno tatedhalfsegment h 98

PAGE 99

Algorithm4 :Thealgorithmforderivingthecomponentviewofaregion. Input :Sequenceofunannotatedhalfsegments H Output :Sequence H withfullyannotatedhalfsegments while notendofsweep do 1 Advancesweeplineto h h istheleft-mosthalfsegmentyettobeannotated; 2 Usingsweeplinestatus,determine h aspartofanoutercycleoraholecycle; 3 NewCycle ( h ); Visit ( dp ( h )); 4 if h belongstoahole then 5 Usingsweeplinestatus,retrievehalfsegment f fromitsowningoutercycle; 6 Owns ( h;f ); 7 Setcyclewalkmodetousecounter-clockwiseadjacency; 8 else 9 Setcyclewalkmodetouseclockwiseadjacency; 10 end 11 /*Beginwalkingthecycle*/c h + ; 12 while c 6 = h do 13 if Visited ( dp ( c )) then 14 q c ; c c ; NewCycle ( c ); Owns ( c;h ); 15 while dp ( c ) 6 = dp ( q ) do 16 /*Tracebackanchoredhole*/info ( c ) info ( c ); c c ; 17 end 18 else 19 info ( c ) info ( h ); Visit ( dp ( c )); c c + ; 20 end 21 end 22 end 23 createanewcycleforthishalfsegment,andmarkitsdominat ingpointasvisited (line2-4).Atthispoint,thealgorithmneedstodeterminew hether h belongstoa holecycle(line5)oranoutercycle(line9).Ifacycleiside ntiedasaholecycle,the outercycletowhichitbelongsmustalsobeidentied(line6 -7),andthecyclemust bewalkedusingcounter-clockwiseadjacencyofhalfsegmen ts(line8).Recallthatthe planesweepalgorithmmaintainsthesweeplinestatusstruc ture,whichisaordered listof active segments,suchthatitprovidesaconsistentviewofallhalf segmentsthat currentlyintersectthesweepline,uptothecurrent event (theadditionorremovalofa halfsegment).Byexaminingthehalfsegmentdirectlybelow ahalfsegment h inthesweep 99

PAGE 100

linestatus,wecandeterminewhether h isapartofanoutercycleoraholecycleofan existingface.Inotherwords,ifhalfsegment p isdirectlybelowhalfsegment h inthesweep linestatusstructureandtheinterior-aboveragof p issetto true ,itfollowsthat h is eitherintheinteriorofthecycletowhich p belongs,or h ispartofthecycletowhich p belongs.Recallthatassoonasahalfsegmentisclassiedas beingapartofaholeorface, thecycletowhichitbelongsiswalked(Section 7.1.2.3 )andallotherhalfsegmentsinthat cyclearemarkedaccordingly(lines12-22).Therefore,ifa halfsegmentbelongstothesame cycleasanyhalfsegmentthathasbeenpreviouslyencounter edbythesweepline,itis alreadyknowntowhichfaceand/orholecycleitbelongs.Fur thermore,allhalfsegments thatarelessthanagivenhalfsegmentinhalfsegmentorderh avealreadybeenclassied. Therefore,wecandetermineifanunmarkedhalfsegmentbelo ngstoaholeoroutercycle byexaminingthehalfsegmentimmediatelybelowitintheswe eplinestatusstructure. Fromthedenitionofaface,theoutercycleofafaceofaregi onalwayscovers (encloses)allofitsholecycles.Thismeansthatthesmalle sthalfsegmentofthisfaceis alwaysapartoftheoutercycle.Thisisalsotruefortheenti reregionobjectwherethe smallesthalfsegmentintheorderedsequenceisalwaysapar toftherstoutercycleofthe rstface.Furthermore,duetotheorderrelationofhalfseg mentsandthecyclicstructure ofapolygon,thesmallesthalfsegmentofafacewillalwaysb ealefthalfsegmentwith theinteriorofthefacesituatedaboveit.Thus,whenweproc essthishalfsegment,weset itsinterior-aboveragtoindicatethisfact.Sincewehavec lassiedthiscycleasanouter cycle,wecanwalkthecycleandsettheinterior-aboveragfo rallhalfsegmentsofthis cycle.Forexample,Figure 7-8 Aillustratesthecasewherethesmallesthalfsegmentofthe sequenceisprocessedandthecycleisclassiedasanouterc ycle. Oncetherstoutercycleofafaceinaregionhasbeenprocess ed,wecontinueto processhalfsegmentsthathavenotyetbeenclassiedbased ontheplanesweepstatus structure.Figure 7-8 Bshowsanexample.Here,weadd/removevisitedhalfsegment s into/fromthesweeplinestatusinsequenceordereduptothe smallestunvisited 100

PAGE 101

h A k status B s p p k s status h ia !ia!ia ia Figure7-8.Processinghalfsegmentsinaregion.A)Process ingthesmallesthalfsegment h ofthesequence.B)Processinghalfsegment k ofacycle. halfsegment k .Thishalfsegment must bethestartofanewcyclethatwemustnow classify.Weknow k isthestartofanewcyclebecauseallhalfsegmentsofanexis tingcycle thatincludeahalfsegment j suchthat j
PAGE 102

isencounteredagain.Forexample,whenwalkingtheoutercy cleoftheregioninFigure 7-2 inclockwiseorderbeginningfrom S 1 ,thehalfsegmentswouldbeencounteredinthe order h l1 ;h r1 ;h r3 ;h l3 ;h r2 ;h l2 .Thetwomainchallengestothisportionofthealgorithmare (i)toidentifycyclescorrectlysuchthattheycorrespondt otheuniquerepresentationofa regionasstatedinthedenitionofcomplexregions,and(ii )toachievethiseciently.In thissectionweshowhowtosatisfytherstchallenge.Timec omplexityisdiscussedinthe nextsection. Whenahalfsegment h isencounteredbythealgorithmthathasnotyetbeen classied,itisclassiedasbelongingtoaholeoroutercyc leinline5.If h belongstoan outercycle,thenthecyclewalkportionofthealgorithminl ines12-22isexecuted.Dueto thehalfsegmentorderingandthedenitionofregions,thes mallestunvisitedhalfsegment intheinputsequencethattheplanesweepencountersisalwa ysalefthalfsegmentofan outercycleofafaceandtheinteriorofthatfacealwayslies abovethehalfsegment.Ifwe rotate h b clockwisearounditsdominatingpoint,itwillintersectth einterioroftheface. Thus,thersthalfsegmentencounteredwhenrotating h b clockwisearounditsdominating pointwillbepartoftheoutercycleofthesamefaces(except foraspecialcasediscussed below)andwillbe h + .Weknowthistobetruebecauseifwend h + inthisfashionand itturnsouttobepartofanotherface,thentwofaceswouldin tersect,whichisprohibited bythedenitionofcomplexregions.Itfollowsthateachsuc cessivehalfsegmentinthe outercyclecanbefoundbyrotatingthebrotherofthecurren thalfsegmentclockwise arounditsdominatingpointbecausethelocationoftheinte riorrelativetothehalfsegment canalwaysbededucedbasedontheprevioushalfsegmentenco unteredinthecyclewalk. Onespecialcaseoccurswhenwalkingoutercycles:theexist enceofaholeinaface thatmeetstheoutercycleatapoint.Whenwalkinganoutercy clethatcontainssuch ahole,thehalfsegmentsthatformtheholewillbeclassied asbeingpartoftheouter cycleusingtheprocedurejustdescribed.Inordertoremedy this,wemarkeachpoint thatisadominatingpointofahalfsegmentencounteredduri ngthecyclewalk(line20). 102

PAGE 103

Eachtimewendanewhalfsegmentthatispartofanoutercycl e,werstcheckifits dominatingpointhasbeenvisitedyet(line14).Ifithasbee nvisited,thenweknowthat wehaveencounteredthatpointbefore,andaholecyclethatm eetstheoutercyclemust havebeendiscovered.Whenthishappens,weloopbackwardso verthecycleuntilwe ndthehalfsegmentwhosedominatingpointhasbeenvisited twice(lines15-18).The halfsegmentsformingtheholearethenmarkedassuch.There mainderoftheoutercycle isthenwalked. Walkingaholeisidenticaltowalkinganoutercycle,except thatacounter-clockwise rotationfrom h b isusedtond h + .Acounter-clockwiserotationisrequiredbecausethe interiorofthefaceisintersectedby h b whenrotating h b arounditsdominatingpoint. Whenwalkingholes,thespecialcaseexiststhattwoholesma ymeetatapoint.Thus, weemploythesamestrategytodetectthiscaseaswedidwitht hespecialcaseofahole meetingaface(lines15-18). WalkingCyclesinMaps Walkingcyclesinamapissimilartowalkingcyclesinaregio n.However,thereare somedierences.First,becauseregionsinamapcanshareha lfsegmentsthatseparate them,wecannotsimplymarkahalfsegmentasbeingvisited.I nstead,wemustidentify ifwehavevisitedthehalfsegmentwhenwalkingthecyclesof theregionabovethe halfsegment,orbelowthehalfsegment.Therefore,twopara llelarraysarerequiredtostore thisinformation,onetomarktheabovesideofhalfsegments thathavebeenvisited,and theothertomarkthebelowside.Theseconddierenceisthat thepurposeoftherene algorithmistogiveeveryfaceinamapauniquelabel.Theref ore,wemustremember theregion idofeachfacewehavevisited,andchangetheregion idofanyfacethathas thesameregion idofafacethathasalreadybeenvisitedtoanew,uniqueregi on id. Weachievethisbymaintainingamappingofregion idvaluesfromtheoriginalmapto region idvaluesintherenedmap.Atthersthalfsegmentencounte redforeachcycle, wecheckthemappingtoseeiftheregion idforthenewcycleisinthemapping.Ifnot, 103

PAGE 104

thenitisthersttimethatregion idhasbeenencountered.Inthiscase,weaddthe region idtothemappingsuchthatitmapstoitself.Iftheregion idisalreadyinthe mapping,thenweaddtheoldregion idtothemappingsuchthatitmapsanewregion id x ;furthermore,asthecyclecorrespondingtothefaceisbein gwalked,theregion idfor everyhalfsegmentinthecycleischangedto x .Thesearetheonlymodicationsrequired forthecyclewalkingalgorithmpresentedabovetobeapplie dtothereneoperationof maps. ExtendingtheLabelTable Thesecondpartofthereneoperationaltersthelabeltable foramapsothatit isconsistentwiththemapgeometrycreatedinthecyclewalk ingportionoftherene algorithm.Inordertoensurethatregionlabelsremainuniq ue,thelabeltableforthemap beingrenedisalteredsothatitcontainsanadditionalcol umn,whichwewillcall ref oftypeinteger.Thiscolumnisgivenadefaultvalue,suchas 1,thatisnotusedasa region idvalue.Oncethelabeltablehasthisnewcolumn,thenthetu plescorresponding tothelabelsofthenewregions(whichpreviouslywerefaces ofregions)inthemapmust beinserted.Thisisachievedusingthelabelmappingcomput edduringthecyclewalk. Recallthatthecyclewalkportionofthealgorithmreturnsa mapping A fromregion ids belongingtothemapbeforethecyclewalkportionofthealgo rithmhastakenplace,to region idsbelongingtothemapafterthecyclewalkportionoftheal gorithmhastaken place.Therefore,foreachregion id i in A thatmapstoanewregion id j thatisnotin thelabeltable,atuplewithregion id j mustbeinsertedintothelabeltablewithidentical attributevaluesasthetuplewithregion id i ,exceptthatthe ref columnmustcontaina dierentvaluethanthetuplewithregion id i .Therefore,thevalueof j isusedinthe ref column,sinceitisunique.Onceeveryentryinthemappingha sbeenprocessed,therene operationiscomplete.Algorithm 5 andAlgorithm 6 summarizethis. Fromthediscussionofthecyclewalkportionofthealgorith m,itisclearthatthe planesweepandalteringofhalfsegmentlabelstakes O ( n lg n )timeforamapwith n 104

PAGE 105

Algorithm5 :Thecyclewalkportionoftherenealgorithm. Input :Amap M Output : M modiedaccordingtothereneoperation,andalabelmappin g A Initializesweeplinestructures; 1 while notendofsweep do 2 Getnexthalfsegment h withanunvisitedside; 3 if abovesideof h hasnotyetbeenvisited then 4 Checkmapping A forabovelabel a of h ; 5 if a isinmapping A then 6 Set a tomaptonewregion id c in A ; 7 Change a to c in h ; 8 WalkthecycleasinAlgorithm 4 ,markingtheappropriatesideof 9 halfsegmentsasbeingvisitedandchangingappropriatelab els; else 10 Set a tomapto a in A ; 11 WalkthecycleasinAlgorithm 4 ,markingtheappropriatesideof 12 halfsegmentsasbeingvisited; end 13 end 14 if belowsideof h hasnotyetbeenvisited then 15 Checkmapping A forbelowlabel b of h ; 16 if b isinmapping A then 17 Set b tomaptonewregion id c in A ; 18 Change b to c in h ; 19 WalkthecycleasinAlgorithm 4 ,markingtheappropriatesideof 20 halfsegmentsasbeingvisitedandchangingappropriatelab els.Use counter-clockwiseorderingaroundpoints.; else 21 Set b tomapto b in A ; 22 WalkthecycleasinAlgorithm 4 ,markingtheappropriatesideof 23 halfsegmentsasbeingvisited.Usecounter-clockwiseorde ringaround points.; end 24 end 25 end 26 halfsegments.Theadditionofamappingofregionlabelston ewregionlabelscanbe implementedusinganAVLtree,andthushasacomplexityof O ( r lg r )timeforamap containing r faces.Finally,theportionofthealgorithmthataltersthe labeltablemust altereachexistingtuple,plusinsertanewtupleforeachne wregionidentiedinthecycle walkportionofthealgorithm.Thusforamapcontaining r faces,thistakes O ( r )time 105

PAGE 106

Algorithm6 :Thelabeltablemodicationportionoftherenealgorithm Input :Alabeltable L M formap M andamapping A fromthecyclewalkportion oftherenealgorithm. Output :Labeltable L M modiedaccordingtothelabelmapping A Addanewcolumnnamed ref to L M withadefaultvalue; 1 for eachentry a b in A do 2 if a != b then 3 Constructtuple t identicaltothetuplewithregion id a in L M ; 4 Settheregion idof t to b ; 5 Setthe ref columnvalueof t to b ; 6 end 7 end 8 A overlay 2 C B Figure7-9.Theresultofthe overlay 2 operationappliedtotwomaps. sinceeachtupleismodiedorinsertedonce.Therefore,the timecomplexityfortherene algorithmis O ( n lg n + r lg r + r ).Sincethenumberofhalfsegmentsinamapistypically muchgreaterthanthenumberofregions,thistendstobedomi natedbyrstterm. 7.1.2.4Combiningoperationstoformnewoperations Itispossibletocombinethepreviousthreeoperationstocr eatenewoperations.For instance,acommonoperationformapsistooverlaytwomapss uchthattheresultmap onlycontainstheintersectingportionsofregionsintheor iginalmaps.Wedenotethis operations overlay 2 (todierentiateitfromtheterm overlay whichtypicallyreferstothe intersectoperationdescribedabove),andshowanexamplei nFigure 7-9 Inordertocomputethe overlay 2 ,wesimplycombinethe intersect and relabel operationsdenedpreviously.Giventwoargumentmaps, M and P ,werstcompute 106

PAGE 107

theintersectoperation,resultinginmap Q .Recallthatthelabeltableforthemap Q willhaveallcolumnsfromthelabeltablesfor M and P ;furthermore,thecolumn namescorrespondingtocolumnsthatcamefromtherstargum entmap, M ,willhave a1appended,andthecolumnnamescorrespondingtocolumnst hatcamefromthe secondargumentmap P ,willhave2appended.Inordertocomputethe overlay 2 ,we mustremoveallregionsfrom Q thatcoveranareathatiscoveredbyaregioninonlya singleargumentmap.Wecanidentifythoseregionsduetothe factthetheattributes inthelabeltableforallattributesfromasingleargumentr egionwillhaveadefault value.Therefore,wemustsimplyremovethetuplesthatsati sfythisproperty.Oncethose tuplesareremoved,therelabeloperationisexecutedover Q ,whichenforcesthegeometric consequencesofremovingtuplesfromthelabeltableof Q (i.e.,thecorrespondingregions areremoved).Aftertherelabel, Q containstheresultofthe overlay 2 operationappliedto M and P 7.2APrototypeImplementationofMapAlgebra InordertotesttheimplementationmodelofMapAlgebrapres entedintheprevious section,wehaveproducedaprototypeimplementationofthe datamodelandthe intersect,relabel,andrenealgorithms.Ourimplementat ionisinC++andusesan Oracledatabasetostorethegeometricandattributedatafo rmaps.Theimplementation followsthepresentedmodelveryclosely.WeusedOracledat abaseextensionmechanisms tocreateadatabasetype map2D ,whichholdsthemapgeometryintheformofordered halfsegments,eachannotatedwiththeIDoftheregionthatl iesaboveandbelowit.The attributesarestoredinalabeltable.However,duetolimit ationsintheextensibility mechanismsofOracle,theintersect,relabel,andreneope rationswerenotabletobe implementedinthedatabaseitself.Instead,themapgeomet rydatamustbereadfrom thedatabasebyanexternallibrarywhichrunsthealgorithm s,andthewritestheresult backtothedatabase.Althoughthisisnotoptimalinthesens ethatmapdatamustbe copiedtoandfromthedatabase,becausewewereabletotakea dvantageofdatabase 107

PAGE 108

extensionmechanismsforthemapgeometry,wearestillable tousethetransaction functionalityprovidedbytheDBMS. Recallthatahypothesiswemadetomotivatetheuseofmapsas rstclasscitizensin databaseswasthatspatialsystemswouldbeeasiertoimplem entandlesscomplex.Our implementationconrmsthisattwolevels.First,weareabl etodirectlyusefunctionality providedbydatabases.Byusingdatabaseextensionmechani smstoimplementMap Algebra,weareabletoutilizedatabasetransactions,pers istentstorage,andmulti-user access.Furthermore,weareabletousestandardSQLtoposeq ueriesoverattributedata, aswellasmaps.Furthermore,asinglemaptypeisusedtorepr esentspatialdatainthe databaseandintheviewer,sowecompletelyavoidamiddlewa relayer,andcandirectly displaytheresultsofoperationswithoutanypost-process ing.Therefore,thishypothesis hasbeenconrmedbyourimplementation.Inthefollowingse ctions,welookatthe performanceofmapoperationsinoursysteminordertotestt heproposedhypothesisthat implementingmapsasrstclasscitizensinspatialsystems increasesperformance. 7.3PerformanceComparisonofMap2DAlgorithmswithanExis tingGIS InordertotesttheeectivenessofourMapAlgebramodel,we haveconducteda performancecomparisonbetweenour PrototypeMapAlgebraImplementation (PMAI), andanexistingGIS.WehavechosentocomparePMAIagainstac ommercialGISproduct thathasexistedformanyyears,isconsideredandindustrys tandard,andthatisused worldwide.WewillrefertothissystemasGISX.GISXhasbeen optimizedthroughoutits lifecycleforperformance,andthus,isanidealcandidatet ojudgetheperformanceofour systemagainst.7.3.1MethodofComparison Thegoalofourcomparisonistotesttherelativeperformanc eofoperationsofGISX andPMAI.Therefore,wewilltakeadataset,useitasinputfo roperationsinboth systems,andcomparethetimeittakestorunthoseoperation s.Inordertomakeafair comparison,wechooseoperationsimplementedinbothsyste msandthathavethesame 108

PAGE 109

semantics.BecausemapsarenotrstclasscitizensinGISX, itisclearthatthealgorithms foroperationsinbothsystemswillbedierent,sowechoose operationsthatshould havethesameresultinbothsystemsgiventhesameinputdata .Therefore,wechooseto testthe overlay operation(whatwecallintersectinMapAlgebra),andthe intersection operation,whatwecall overlay 2 Theoverlayoperationisagoodchoicetocomparethetwosyst emsbecauseitis implementeddirectlyinbothPMAIandGISX.Furthermore,ov erlayformsthebasisof manyotheroperations,soitshouldprovideinsightintothe relativeperformanceofmap processingingeneralinbothsystems. The overlay 2 ( intersection )operationinPMAIisbuiltusingacombinationof intersectandrelabel;therefore,PMAIdoesnothaveaspeci alpurposealgorithm optimizedforthisoperation.Thus,weexpecttheperforman ceofthisalgorithmin PMAItobelessthanthatoftheoverlayalgorithm.However,a comparisonwiththe GISXimplementationshouldprovideinsightintothefeasib ilityofusingcombinationsof intersect,relabel,andrenetoimplementotheroperation s,insteadofimplementinga specialpurposealgorithmforeveryoperation. Wehavechosenthreedatasetstouseasinputforoperations, eachtakenfrom theTIGER2007shapelesprovidedbytheU.S.Census.Eachda tasetconsistsofthe countiesofthestatesofVermont,Florida,andTexas,respe ctively.Vermontwaschosenas therstdatasetbecauseitisasmallstatewithfewcounties .Floridaisamediumsized statewithaboutftycounties.Finally,Texasisalargesta tewithabouttwohundred counties.Therefore,eachdatasetrerectsadierentsizei ntermsofthenumberof halfsegmentsusedtorepresentthestate,andanincreasing numberofcounties,which formtheregionsinthemaps.Furthermore,theTIGERdataset isusefullbecauseit providesattributesforeachcounty. Inordertotesteachoperation,amapischosenfromoneofthe threedatasets.The originalmapisstored,alongwithacopyofthemapthathasbe enmovedinspaceslightly 109

PAGE 110

Figure7-10.ImagesofthePMAIdisplayingthenalresultof the overlay algorithmtest foreachofthedatasetsused. suchthatasignicantportionofthenewmapintersectstheo ldmap.Thesetwomaps arethenusedasinputtoanoperation.Thetimeittakestorun theoperationisrecorded, andtheoperationisrepeatedtwomoretimesontheinputandt heaveragerunningtime iskept.Theresultoftheoperationisthenusedasinputtoth eoperationagain,with anothercopyoftheoriginalmapthathasbeenmovedinadier entdirectionthanthe rstcopy,butthatstilloverlapsasignicantportionofth eoriginalmap.Again,the runningtimeisaveragedforthreerunsovertheseinputs,an dtheoutputisusedinthe nextiteration.Thisprocessisrepeatedvetimesforeachd ataset,andtherunningtimes arerecorded.Forreference,thenalmapgeneratedforeach datasetaftercompletingthis processvetimesusingthe overlay operationisshowninFigure 7-10 .Theseimagesare screenshotsofourPMAIusedtotestMapAlgebraconcepts.No tethatsomecountiesare excludedfromthedatasetsbecausetheregionsthatreprese ntthemintheTIGERdata lesdonotconformtothedenitionofcomplexregions.Inot herwords,theseregions includecyclesthatarenotclosedorthatcontaindanglings egments. Wehavechosentoperformtheexperimentasstatedabovebeca useforeach iterationthatanoperationisrun,thenumberofhalfsegmen tsneededtorepresentthe mapincreases,aswellasthenumberofregionsinthemap.Thu s,asthenumberof iterationsincreases,weareabletoseehowtherunningtime ofeachoperationscalesas theargumentdatasizeandcomplexityincreases.Furthermo re,becausewehavechosena 110

PAGE 111

small,medium,andlargedataset,wearealsoabletodetermi ne(intheearlyiterations) howeachoperationperformsonsmallandnon-complexdata.T herefore,theresultsof runningtheseoperationsshouldprovideageneralpictureo ftheperformanceofeach system. NotethatbecauseofthedesigndierencesofGISXandPMAI,s implytimingthe totalexecutionfromissuingthecommanduntilcommandcomp letionismisleading.This isbecausePMAIstoresmapsinadatabase,andthus,datamust betransferredacrossa networkconnectionforloadingandstorage.GISXstoresdat ainles,soitmustsimply readthedatafromdisk.Therefore,wedonotcountthetimeit takestoloadlesfor operations.ByobservingthediskactivitypatternsofGISX duringoperations,itseems thatdataisloadedbeforeanoperationbeginsexecuting.Th us,wefeelthisisareasonable decision.Furthermore,datalesareontheorderofafewmeg abytestotensofmegabytes, whichtakesanegligibleamountoftimetoloadfromdiskcomp aredtotherunningtime oftheoperationstested.TheGISXalgorithmseemstowritet heresultofoperations incrementallythroughouttherunningofanoperation.Ther efore,wewritetheresult ofoperationsinPMAItodiskandincludethatintheoverallr unningtime(wedonot includethenetworktransfertimeforwritingbacktothedat abase).Weachieveane grainedcontroloverwhichportionsofoperationsaretimed inPMAIthroughtheuse ofa stopwatch softwaremechanismthatcanbestartedandstoppedfromwith inthe PMAIsourcecode,andwhichcomputestimeontheorderofmill iseconds.TheGISX algorithmprovidesitsowntimingmechanismthatrecordsth etotaltimeofanoperation ontheorderofseconds.Thus,weareabletotimecomparablei nput/outputfunctionality betweenoperations,andthetimeittakestocomputetheresu lt. 7.3.2Results Theresultsofrunningthetestsdescribedabovearesummari zedinFigure 7-11 andFigure 7-12 .Eachgraphshowstheaveragerunningtimeforanalgorithmi nboth PMAIandGISX,andthenumberofhalfsegmentsintheresultin gmap.InFigure 7-11 111

PAGE 112

itisclearthatthePMAIalgorithmrunsmorequicklythanits counterpartinGISXin everyinstance.Furthermore,asthenumberofhalfsegments increasetheperformancegap betweenthealgorithmstendstoincreaseaswell. Recallthattherearetwomethodsofcomputingamapoverlay, thelterandrene methodsthattreateachmapasacollectionofindividualreg ions,andtheobjectmethod thattreatsamapasasingleobject.ThePMAIapproachusesth eobjectmethod; therefore,thenumberofoverlappingregionsintwoargumen tmapsdoesnotaectthe runningtimeofgeometricportionofthealgorithm.However ,inthelterandrene approach,ageometricalgorithmmustbecomputedforeveryp airofregionsthatoverlap. Inmanycases,thismeansthataregionmustbeprocessedmult ipletimes,onceforeach regionwhoseboundingboxoverlapsitsboundingbox.Giveno urmethodoftesting,it ispossiblethattheincreasednumberofregionsineachsucc essiveoverlayoperationis causingtheGISXalgorithm'sperformancedegradation.How ever,thelterandrene approachshouldperformsignicantlybetterthanthePMAIa pproachwhenfewregions overlap.Thisisbecausemostregionswillbeidentiedduri ngthelterstepandnot beincludedintherenestep.Theobjectmethod,however,in volvesallregionsintwo argumentmapsineverycase.Inotherwords,thePMAIalgorit hmdoesnotmakeuseof anylteringbasedonboundingboxes.Inordertotestthisas sumption,wecomputedthe intersectoperationbetweenthenalmapsofVermontandFlo ridathatresultfromthe experimentdescribedaboveusingthe overlay operation.Theresultingmapcontained 840294halfsegments3056regions.Furthermore,themapsof FloridaandVermontdonot intersect,andarefarenoughapartthattheirboundingboxe sdonotintersect.However, whenthisexperimentwasrun,ittookanaverage33.67second sforGISXtocomputethe result,andanaverageof12.97secondsforPMAItocomputeth eresult.Thus,thePMAI approachisagoodchoiceeveninsituationsthatfavorthel terandrenemethod.This isduetothefactthatasignicantpartoftherunningtimeof theoverlayalgorithmin 112

PAGE 113

Figure7-11.RunningtimesfortheintersectoperationinPM AIandGISX. PMAIdealswithintersectinghalfsegments.Whennohalfseg mentsintersect,eachmapis simplytraversed. InFigure 7-12 ,therunningtimeforPMAIisbrokendownintoitsconstituen tparts. Recallthe overlay 2 algorithminPMAIconsistsrstofan overlay algorithm,thena querytoremovethelabelsofthenon-intersectingportions oftheargumentmapsfrom theresultmap,thena relabel operation.Therunningtimeforeachofthesecomponents isshown.FortheVermontandFloridadatasets,thePMAIalgo rithmclearlyperforms betterthantheGISXalgorithm.However,weseethatfortheT exasdataset,theGISX algorithmperformsbetterinnearlyeverycase.Theoverlay portionofthealgorithmruns competitively,butasthecomplexityofthemapsincreasesi ntermsofthenumberof 113

PAGE 114

Figure7-12.Runningtimesforthe overlay 2 operationinPMAIandGISX. regions,thequeryandrelabelportionsofthealgorithmsbe gintoincrease.Recallthat thesealgorithmsincludeaquadraticcomponentwithrespec ttothenumberofregions inthemapsinvolved.Thus,thisisrerectedintheoverallru nningtime.Itshouldbe notedthattheGISXalgorithmismostlikelyaspecialpurpos ealgorithm,whilethePMAI algorithmisemulatedbycombiningdierentalgorithms.Th erefore,eventhoughthe performanceofthePMAIalgorithmispoorinthelargestdata set,thePMAIalgorithm performswellforsmallandmediumsizeddatasets.Thus,the approachofcreating operationsbycombiningotheroperationsisfeasibleinman ycases. Ingeneral,theseresultsshowthatconsideringmapsasrst classcitizensinspatial systemsresultsinsignicantperformancegainsforgeopro cessing.Furthermore,emulating 114

PAGE 115

operationsthroughthecombinationofotheroperations,in steadofcreatingaspecial purposealgorithmforeveryoperation,isalsofeasiblefor smallandmediumdatasets. However,itshouldbenotedthatthePMAIimplementationisr atherbasicinthatno optimizationstoreducememoryconsumptionareused.Thus, ifmoreaggressivememory managementtechniquesareused,largedatasetsmayperform betterusingthisapproach. Finally,evenincasesthatfavorlterandrenemethodsofc omputingspatialoperations, thePMAIapproachofusingmapsasrstclasscitizensstillp erformswellinoperations. ByincorporatingboundingboxrenementmethodsintoPMAI, thisperformancemaybe abletobeincreasedevenfurther. 115

PAGE 116

CHAPTER8 CONCLUSION Inthisthesis,wehaveprovidedadenitionofMapAlgebraat threelevels.Atthe abstractlevel,themodelofspatialpartitionsdenesamat hematicaltypeformapsand theprecisesemanticsofoperationsoverthem.Furthermore ,topologicalrelationships betweenmaps,asubjectthathasnotbeenexploredinthelite rature,wereidentied anddened.Usingthisdenition,wewereabletodesignaque rylanguageformaps inspatialdatabasesandshowhowitcouldbeimplementedusi nganextendedSQL.A discretemodelofmapsbasedontheabstractmodelwasthende velopedinaneortto moveMapAlgebraintoanimplementableconcept.Thismodel, basedongraphtheory, providedamechanismtoenforcemaptypevalidationatthedi scretelevelbydeningthe propertiesofmapsatthediscretelevel.Finally,attheimp lementationlevel,wedeneda datamodelformapsandalgorithmstocomputemapoperations .Wethenimplemented thesealgorithmsandperformedaperformancetestoverthei mplementationofMap Algebracomparingittoamature,commercialsystem.Theres ultsshowedthattheMap AlgebraimplementationoutperformedthecommercialGISin termsofexecutiontimes foroperationsinnearlyeverytestperformed.Thisresultv alidatestheapproachand theexecutionofMapAlgebraasacompetitortotraditionalm approcessingtechniques currentlyinuse. InChapter 1 ,weintroducedthreehypothesisabouttheeectsofintegra tingmaps asrstclasscitizensindatabases.Hypothesis 1 claimedthatintegratingmapsasrst classcitizensindatabaseswouldprovetobemoreecientth anemulatingmapsina middlewarelayer.InSection 7.3 ,weshowedthatourMapAlgebraimplementation outperformedamaturecommercialGISforoperationsimplem entedwithanalgorithm specicallytailoredtothatoperation,andinmostcasesou tperformedtheGISin operationsthatwereimplementedbycombiningotheroperat ionsintheMapAlgebra implementation. 116

PAGE 117

Hypothesis 2 inChapter 1 statedthatimplementingmapsasrstclasscitizenswould leadtoaneasierimplementationofmapoperationsandmapsy stems.Wefoundthis tobetrueinpractice.TheMapAlgebraimplementationconsi stedofasinglemapdata typethatwasimplementedasasoftwarelibrary.Thissingle librarywasthenintegrated directlyintoanextensibleDBMS,andavisualizerprogram. Byintegratingthelibrary intoaDBMS,wewereabletodirectlyutilizedatabaseservic essuchastransaction control,persistentstoragemanagement,andmulti-userac cess.Thus,noneofthese functionalitiesneededtobere-implementedinmiddleware .Becausethevisualizerprogram wasalsoawareofthemaptype,nomiddlewarelayerwasrequir edtoconvertdataformats fordisplay,orevenforoperations.Therefore,theimpleme ntationwassimpliedas comparedtoanimplementationrequiringatraditionalmidd lewarelayer. Finally,hypothesis 3 statedthatbyintegratingmapsintodatabases,wecouldach ieve newfunctionality.Wefoundthatthroughdatabaseextensio nmechanisms,itispossibleto directlyusemapsinSQLqueriesindatabases.Furthermore, notionssuchastopological relationshipscanbeimplementedandincludedinthedataba seextensionmechanismso thattheycanbeusedinSQLstatementsaswell.Furthermore, wewereabletoidentify thetypesofqueriespossibleovermapsindatabases,andsho whowanextendedSQL canbeusedtoperformthem.Theresultisthatnewfunctional itycanbeimplemented formapsindatabases.Furthermore,wedenedamapquerylan guage,MQL,whichwas denedsuchthatpeoplewithoutdatabaseexperiencecouldu sethelanguage.Thus,we havemadeheadwayintobringingmapfunctionalityindataba sestothelargerscientic community,andnotsimplydatabaseexperts. Theresultsofthisthesisshowthattheconceptspresentedi nMapAlgebraforma competitivemethodtorepresent,store,andmanagespatial data.However,MapAlgebra, aspresented,isonlyinitialworkintothelargeareaofspat ialdatahandlingintermsof maps.Forexample,thespatialpartitiondatamodelusedtod enemapsinMapAlgebra canonlyrepresentmapscontainingregionfeatures.Theref ore,mapscontainingpointand 117

PAGE 118

linefeaturescannotberepresented.Developingamapdatam odeltohandlesuchmapsis asignicantundertaking,asthecomplexityofmapsincreas esgreatlywiththeaddition ofnewfeatures.Furthermore,notionssuchasnetworkproce ssingregardingspatially embeddednetworkshasnotbeeninvestigatedintermsofMapA lgebra. Inadditiontonewdirectionsinspatialdatamodeling,MapA lgebraconceptscanalso beappliedtophysicaldatastoreagemechanismsforspatial data.Forexample,insteadof storingcollectionsofregionsinseparatetuplesofadatab asetable,amapmaybeusedto storethedata.Thiswouldallowtheperformanceadvantages ofmapprocessingalgorithms fromMapAlgebratobeutilizedbymorebasicspatialtypessu chasregions.Furthermore, usingmapstoimplementspatialdatabasejoinshasshownpro miseforbeingecient,even whenindexesarenotavailableonthedata. Inconclusion,byrethinkingthestorageandrepresentatio nofmapsinspatial databases,wehavebeenabletointroducenew,ecientmetho dsofspatialdata managementandprocessing.TheconceptsdevelopedinMapAl gebrashowpromise forimprovingmanyaspectsofspatialdatamanagement,even incaseswheretraditional spatialtypesareusedinsteadofmaps.Furthermore,therei smuchworkstilltobedonein thisarea,andMapAlgebraprovidesaplatformtoidentifyne wproblemsandimplement solutions. 118

PAGE 119

REFERENCES [1] E.G.Hoel,S.Menon,andS.Morehouse,\BuildingaRobustRel ational ImplementationofTopology,"in SSTD ,2003,pp.508{524. [2] J.Herring,\TIGRIS:ADataModelforanObject-OrientedGeo graphicInformation System," ComputersandGeosciences ,vol.18,no.4,pp.443{452,1992. [3] M.DeMers, FundamentalsofGeographicInformationSystems .JohnWileyandSons, 1990. [4] P.BurroughandR.McDonnell, PrinciplesofGeographicInformationSystems OxfordUniversityPress,1998. [5] J.Malczewski, GISandMulticriteriaDecisionAnalysis .JohnWileyandSons,1999. [6] I.Heywood,S.Cornelius,andS.Carver, IntroductiontoGeographicalInformation Systems .PrenticeHall,2002. [7] C.D.Tomlin, GeographicInformationSystemsandCartographicModellin g Prentice-Hall,1990. [8] J.K.Berry,\FundamentalOperationsinComputer-Assisted MapAnalysis," Int. JournalofGeographicalInformationSystems ,vol.1,no.2,pp.119{136,1987. [9] A.U.Frank,\OverlayProcessinginSpatialInformationSys tems,"in Proc.ofthe8th Int.Symp.onComputer-AssistedCartography,AUTOCARTO8 ,1987,pp.16{31. [10] M.Schneider, SpatialDataTypesforDatabaseSystems-FiniteResolution Geometry forGeographicInformationSystems .BerlinHeidelberg:Springer-Verlag,1997,vol. LNCS1288. [11] R.Viana,P.Magillo,E.Puppo,andP.A.Ramos,\Multi-VMap: AMulti-Scale ModelforVectorMaps," Geoinformatica ,vol.10,no.3,pp.359{394,2006. [12] W.C.Filho,L.H.deFigueiredo,M.Gattass,andP.C.Carvalh o,\ATopological DataStructureforHierarchicalPlanarSubdivisions,"in 4thSIAMConferenceon GeometricDesign ,1995. [13] A.VoisardandB.David,\MappingConceptualGeographicMod elsontoDBMSData Models,"Berkeley,CA,Tech.Rep.TR-97-005,1997. [14] R.H.Guting,\Geo-RelationalAlgebra:AModelandQueryLa nguageforGeometric DatabaseSystems,"in Int.Conf.onExtendingDatabaseTechnology(EDBT) ,1988, pp.506{527. [15] R.H.GutingandM.Schneider,\Realm-BasedSpatialDataTy pes:TheROSE Algebra," VLDBJournal ,vol.4,pp.100{143,1995. 119

PAGE 120

[16] T.Bittner,\TheQualitativeStructureofBuiltEnvironmen ts," Fundam.Inf. ,vol.46, no.1-2,pp.97{128,2001. [17] V.Tsetsos,C.Anagnostopoulos,P.Kikiras,P.Hasiotis,an dS.Hadjiefthymiades, \AHuman-CenteredSemanticNavigationSystemforIndoorEn vironments," perser vol.0,pp.146{155,2005. [18] S.Vasudevan,S.Gachter,V.Nguyen,andR.Siegwart,\Cogn itiveMapsforMobile Robots-anObjectBasedApproach," Robot.Auton.Syst. ,vol.55,no.5,pp.359{371, 2007. [19] S.Thrun,\RoboticMapping:aSurvey,"pp.1{35,2003. [20] R.O.C.TseandC.Gold,\TINMeetsCAD:ExtendingtheTINConc eptinGIS," FutureGener.Comput.Syst. ,vol.20,no.7,pp.1171{1184,2004. [21] BoundaryGraphOperatorsforNonmanifoldGeometricModeli ngTopologyRepresentations .Elsevier,1988. [22] M.Mantyla, IntroductiontoSolidModeling .NewYork,NY,USA:W.H.Freeman& Co.,1988. [23] B.G.Baumgart,\WingedEdgePolyhedronRepresentation."S tanford,CA,USA, Tech.Rep.,1972. [24] M.RaubalandM.F.Worboys,\AFormalModeloftheProcessofW ayndingin BuiltEnvironments,"in COSIT'99:ProceedingsoftheInternationalConferenceon SpatialInformationTheory:CognitiveandComputationalF oundationsofGeographic InformationScience .London,UK:Springer-Verlag,1999,pp.381{399. [25] U.-J.RuetschiandS.Timpf,\ModellingWayndinginPubli cTransport:Network SpaceandSceneSpace,"in SpatialCognition ,ser.LectureNotesinComputer Science,C.Freksa,M.Knau,B.Krieg-Bruckner,B.Nebel, andT.Barkowsky,Eds., vol.3343.Springer,2004,pp.24{41. [26] F.R.BroomeandD.B.Meixler,\TheTIGERDataBaseStructure ," Cartography andGeographicInformationSystems ,vol.17,pp.39{48,Jan1990. [27] J.Herring,\TIGRIS:TopologicallyIntegratedGeographic InformationSystems,"in 8thInternationalSymposiumonComputerAssistedCartogra phy ,1987,pp.282{291. [28] N.S.ChangandK.S.Fu,\ARelationalDatabaseSystemforIma ges,"in Pictorial InformationSystems ,N.S.ChangandK.S.Fu,Eds.Springer,1980,pp.288{321. [29] N.Roussopoulos,C.Faloutsos,andT.Sellis,\AnEcientPi ctorialDatabaseSystem forPSQL," IEEETrans.Softw.Eng. ,vol.14,no.5,pp.639{650,1988. [30] M.J.Egenhofer,\SpatialSQL:AQueryandPresentationLang uage," IEEETransactionsonKnowledgeandDataEngineering ,vol.6,no.1,pp.86{95,1994. 120

PAGE 121

[31] P.M.Aoki,\HowtoAvoidBuildingDatabladesthatKnowtheVa lueofEverything andtheCostofNothing,"1999,pp.122{133. [32] S.Banerjee,V.Krishnamurthy,andR.Murthy,\AllYourData :TheOracle ExtensibilityArchitecture,"in ComponentDatabaseSystems ,ser.MorganKaufmann SeriesinDataManagementSystems,K.R.Dittrich,Ed.Morga nKaufmann Publisher,2001,ch.3,pp.71{104. [33] J.Davis,\IBM'sDB2SpatialExtender:ManagingGeo-Spatia lInformationwithin theDBMS,"Tech.Rep.,1998. [34] D.S.Batory,J.R.Barnett,J.F.Garza,K.P.Smith,K.Tsukud a,B.C.Twichell, andT.E.Wise,\GENESIS:AnExtensibleDatabaseManagement System,"vol.14, no.11,pp.1711{1730,1988. [35] M.CareyandL.Haas,\ExtensibleDatabaseManagementSyste ms,"vol.19,no.4, pp.54{60,1990. [36] M.J.Carey,D.J.DeWitt,andS.L.Vandenberg,\ADataModela ndQuery LanguageforEXODUS,"1988,p.413423. [37] L.M.Haas,W.Chang,G.M.Lohman,J.McPherson,P.F.Wilms,G .Lapis,B.G. Lindsay,H.Pirahesh,M.J.Carey,andE.J.Shekita,\Starbu rstMid-Flight:Asthe DustClears,"vol.2,no.1,pp.143{160,1990. [38] L.A.RoweandM.Stonebraker,\ThePOSTGRESDataModel,"198 7,pp.83{96. [39] H.J.Schek,H.-B.Paul,M.H.Scholl,andG.Weikum,\TheDASD BSProject: Objectives,Experiences,andFutureProspects,"vol.2,no .1,pp.25{43,1990. [40] M.SchollandA.Voisard,\ThematicMapModeling,"in SSD'90:Proceedingsofthe rstsymposiumonDesignandimplementationoflargespatia ldatabases .NewYork, NY,USA:Springer-VerlagNewYork,Inc.,1990,pp.167{190. [41] M.McKenney,A.Pauly,R.Praing,andM.Schneider,\Ensurin gtheSemantic CorrectnessofComplexRegions,"in AdvancesinConceptualModeling-Foundations andApplications,ERWorkshops ,2007,pp.409{418. [42] A.FrankandW.Kuhn,\CellGraphs:AProvableCorrectMethod fortheStorageof Geometry,"in 2rdInt.Symp.onSpatialDataHandling ,1986,pp.411{436. [43] M.J.Egenhofer,A.Frank,andJ.P.Jackson,\ATopologicalD ataModelforSpatial Databases,"in 1stInt.Symp.ontheDesignandImplementationofLargeSpat ial Databases .Springer-Verlag,1989,pp.271{286. [44] M.J.EgenhoferandJ.Herring,\CategorizingBinaryTopolo gicalRelationsBetween Regions,Lines,andPointsinGeographicDatabases,"Natio nalCenterforGeographic InformationandAnalysis,UniversityofCalifornia,Santa Barbara,TechnicalReport, 1990. 121

PAGE 122

[45] E.ClementiniandP.DiFelice,\AModelforRepresentingTop ologicalRelationships betweenComplexGeometricFeaturesinSpatialDatabases," InformationSystems vol.90,pp.121{136,1996. [46] M.SchneiderandT.Behr,\TopologicalRelationshipsbetwe enComplexSpatial Objects," ACMTrans.onDatabaseSystems(TODS) ,vol.31,no.1,pp.39{81,2006. [47] M.F.WorboysandP.Bofakos,\ACanonicalModelforaClassof ArealSpatial Objects,"in 3rdInt.Symp.onAdvancesinSpatialDatabases .Springer-Verlag,1993, pp.36{52. [48] E.Clementini,P.DiFelice,andG.Califano,\CompositeReg ionsinTopological Queries," InformationSystems ,vol.20,pp.579{594,1995. [49] M.J.Egenhofer,E.Clementini,andP.DiFelice,\Topologic alRelationsbetween RegionswithHoles," Int.JournalofGeographicalInformationSystems ,vol.8,pp. 128{142,1994. [50] R.H.Guting,\AnIntroductiontoSpatialDatabaseSystems ," TheVLDBJournal vol.3,no.4,pp.357{399,1994. [51] Z.Huang,P.Svensson,andH.Hauska,\SolvingSpatialAnaly sisProblemswith GeoSAL,ASpatialQueryLanguage,"in Proceedingsofthe6thInt.WorkingConf. onScienticandStatisticalDatabaseManagement .Institutf.Wissenschaftliches RechnenEidgenoessischeTechnischeHochschuleZurich,1 992,pp.1{17. [52] U.LipeckandK.Neumann,\ModellingandManipulatingObjec tsinGeoscientic Databases,"in ER ,S.Spaccapietra,Ed.North-Holland,1986,pp.67{85. [53] J.L.BentleyandT.A.Ottmann,\AlgorithmsforReportingan dCounting GeometricIntersections," IEEETrans.Comput. ,vol.28,no.9,pp.643{647,1979. [54] B.ChazelleandH.Edelsbrunner,\AnOptimalAlgorithmforI ntersectingLine SegmentsinthePlane," J.ACM ,vol.39,no.1,pp.1{54,1992. [55] R.Guting,T.deRidder,andM.Schneider,\Implementation oftheROSEAlgebra: EcientAlgorithmsforRealm-BasedSpatialDataTypes,"in SSD'95:Proceedings ofthe4thInternationalSymposiumonAdvancesinSpatialDa tabases .London,UK: Springer-Verlag,1995,pp.216{239. [56] M.deBerg,M.Kreveld,M.Overmars,andO.Schwarzkopf, ComputationalGeometry:AlgorithmsandApplications .Berlin,Germany:Springer-Verlag,2000. [57] D.E.MullerandF.P.Preparata,\FindingtheIntersectiono fTwoConvex Polyhedra," Theor.Comput.Sci. ,vol.7,pp.217{236,1978. [58] J.NievergeltandF.Preparata,\Plane-sweepAlgorithmsfo rIntersectingGeometric Figures," Commun.ACM ,vol.25,no.10,pp.739{747,1982. 122

PAGE 123

[59] D.A.Randell,Z.Cui,andA.Cohn,\ASpatialLogicBasedonRe gionsand Connection,"in InternationalConferenceonPrinciplesofKnowledgeRepre sentationandReasoning ,1992,pp.165{176. [60] M.McKenney,A.Pauly,R.Praing,andM.Schneider,\Preserv ingLocalTopological Relationships,"in ACMSymp.onGeographicInformationSystems(ACMGIS) ACM,2006,pp.123{130. [61] ||,\LocalTopologicalRelationshipsforComplexRegions, "in Int.Symp.on SpatialandTemporalDatabases(SSDT) ,2007,pp.203{220. [62] H.LedouxandC.Gold,\AVoronoi-BasedMapAlgebra,"in Int.Symp.onSpatial DataHandling ,Jul2006. [63] L.D.Floriani,P.Marzano,andE..Puppo,\SpatialQueriesa ndDataModels," in InformationTheory:aTheoreticalBasisforGIS ,I.C.A.U.Frankand U.Formentini,Eds.Springer-Verlag,LectureNotesinComp uterScience,N.716, 1992,pp.113{138. [64] L.GuibasandJ.Stol,\PrimitivesfortheManipulationofG eneralSubdivisionsand theComputationofVoronoi," ACMTrans.Graph. ,vol.4,no.2,pp.74{123,1985. [65] M.ErwigandM.Schneider,\PartitionandConquer,"in 3rdInt.Conf.onSpatial InformationTheory(COSIT) .Springer-Verlag,1997,pp.389{408. [66] M.McKenneyandM.Schneider,\SpatialPartitionGraphs:AG raphTheoretic ModelofMaps,"in Int.Symp.onSpatialandTemporalDatabases(SSDT) ,2007,pp. 167{184. [67] J.Dangermond,\AClassicationofSoftwareComponentsCom monlyUsedin GeographicInformationSystems,"in IntroductoryReadingsinGeographicInformationSystems ,1990,pp.30{51. [68] H.Kriegel,T.Brinkho,andR.Schneider,\CombinationofS patialAccessMethods andComputationalGeometryinGeographicDatabaseSystems ,"in SSD'91: ProceedingsoftheSecondInternationalSymposiumonAdvan cesinSpatialDatabases London,UK:Springer-Verlag,1991,pp.5{21. [69] C.R.Valenzuela,\DataAnalysisandModeling,"in RemoteSensingandGeographicalInformationSystemsforResourceManagementinDevelop ingCountries ,1991,pp. 335{348. [70] A.Guttman,\R-trees:aDynamicIndexStructureforSpatial Searching,"in SIGMOD'84:Proceedingsofthe1984ACMSIGMODInternationalCo nferenceon ManagementofData .NewYork,NY,USA:ACM,1984,pp.47{57. [71] R.FinkelandJ.Bentley,\QuadTrees:ADataStructureforRe trievalonComposite Keys," ActaInf. ,vol.4,pp.1{9,1974. 123

PAGE 124

[72] J.Robinson,\TheK-D-B-tree:aSearchStructureforLargeM ultidimensional DynamicIndexes,"in SIGMOD'81:Proceedingsofthe1981ACMSIGMODInternationalConferenceonManagementofData .NewYork,NY,USA:ACM,1981,pp. 10{18. [73] J.Nievergelt,H.Hinterberger,andK.Sevcik,\TheGridFil e:AnAdaptable, SymmetricMultikeyFileStructure," ACMTrans.DatabaseSyst. ,vol.9,no.1,pp. 38{71,1984. [74] R.H.GutingandH.-P.Kriegel,\MultidimensionalB-tree: AnEcientDynamicFile StructureforExactMatchQueries,"in GIJahrestagung ,ser.Informatik-Fachberichte, R.Wilhelm,Ed.,vol.33.Springer,1980,pp.375{388. [75] J.Orenstein,\AComparisonofSpatialQueryProcessingTec hniquesforNativeand ParameterSpaces," SIGMODRec. ,vol.19,no.2,pp.343{352,1990. [76] J.M.PatelandD.J.DeWitt,\PartitionBasedSpatial-Merge Join," SIGMODRec. vol.25,no.2,pp.259{270,1996. [77] L.Becker,A.Giesen,K.Hinrichs,andJ.Vahrenhold,\Algor ithmsforPerforming PolygonalMapOverlayandSpatialJoinonMassiveDataSets, "in SSD'99:Proceedingsofthe6thInternationalSymposiumonAdvancesinSpati alDatabases .London, UK:Springer-Verlag,1999,pp.270{285. [78] P.vanOosterom,\'AnR-treeBasedMap-OverlayAlgorithm," in EGIS/MARI'94 Paris,1994,pp.318{327. [79] U.FinkeandK.H.Hinrichs,\OverlayingSimplyConnectedPl anarSubdivisions inLinearTime,"in SCG'95:Proceedingsoftheeleventhannualsymposiumon Computationalgeometry .NewYork,NY,USA:ACM,1995,pp.119{126. [80] U.FinkeandK.Hinrichs,\ASpatialDataModelandaTopologi calSweepAlgorithm forMapOverlay,"in SSD'93:ProceedingsoftheThirdInternationalSymposiumo n AdvancesinSpatialDatabases .London,UK:Springer-Verlag,1993,pp.162{177. [81] L.Arge,O.Procopiuc,S.Ramaswamy,T.Suel,andJ.S.Vitter ,\Scalable Sweeping-BasedSpatialJoin,"in VLDB'98:Proceedingsofthe24rdInternational ConferenceonVeryLargeDataBases .SanFrancisco,CA,USA:MorganKaufmann PublishersInc.,1998,pp.570{581. [82] H.Kriegel,T.Brinkho,andR.Schneider,\AnEcientMapOv erlayAlgorithm basedonSpatialAccessMethodsandComputationalGeometry ,"in International WorkshoponDBMSsforGeographicalApplications ,Capri,Italy,1991,pp.16{17. [83] M.McKenneyandM.Schneider,\AdvancedOperationsforMaps inSpatial Databases,"in Int.Symp.onSpatialDataHandling ,Jul2006. 124

PAGE 125

[84] ||,\TopologicalRelationshipsBetweenMapGeometries,"i n Advancesin Databases:Concepts,SystemsandApplications,13thInter nationalConference onDatabaseSystemsforAdvancedApplications ,2007. [85] J.Dugundi, Topology .AllynandBacon,1966. [86] R.B.Tilove,\SetMembershipClassication:AUniedAppro achtoGeometric IntersectionProblems," IEEETrans.onComputers ,vol.C-29,pp.874{883,1980. [87] M.ErwigandM.Schneider,\FormalizationofAdvancedMapOp erations,"in 9th Int.Symp.onSpatialDataHandling ,2000,pp.8a.3{17. 125

PAGE 126

BIOGRAPHICALSKETCH MarkMcKenneywasraisedinBeaumont,Texaswhereheattende dMonsignor KellyHighSchool.Upongraduation,MarkattendedTulaneUn iversityinNewOrleans, LouisanawherehecompletedaBSincomputersciencein2003a ndaMSincomputer sciencein2004.HethenbeganhisPh.D.studiesattheUniver sityofFlorida.Mark earnedhisPh.D.inComputerEngineeringinAugust2008,and thenjoinedtheDepartment ofComputerScienceatTexasStateUniversityasatenure-tr ackassistantprofessor. 126