UFDC Home  myUFDC Home  Help 



Full Text  
xml version 1.0 encoding UTF8 REPORT xmlns http:www.fcla.edudlsmddaitss xmlns:xsi http:www.w3.org2001XMLSchemainstance xsi:schemaLocation http:www.fcla.edudlsmddaitssdaitssReport.xsd INGEST IEID E20101220_AAAAJK INGEST_TIME 20101221T04: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 SHA1 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 Highlevel 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 21 A suninary of spatial systems and their treatment of maps. .. .. .. 26 41 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 niediumgrey and has a dashed boundary, the other is lightgrey and has a dotted boundary. Overlapping nmap interiors are darkgrey, 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 42 The final 7 valid matrices and protoypical drawings representing the possible topological relationships between maps. ...... .... . 49 LIST OF FIGURES Figure page 11 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 orer performs processing. The user interface 1... r provides user interaction mechanisms. .. 13 12 Our proposed system architecture. . ...... . 18 21 Examples of complex spatial objects. A) A complex point object. B) A complex line object. C) A complex region object. ...... .. 21 22 Sample composite region with two components presenting a holelike structure. 22 23 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 24 The 9intersection matrix for spatial objects A and B ... .. .. 24 31 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 41 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 42 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 51 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 52 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 61 A spatial partition and its corresponding SSPG. A) The refinement of the partition in Figure 31A. B) The SSPG corresponding to Figulre A. Nodeless edges are dashed. ......... ..... . 70 62 A labeled plane nodeless pseudograph for the partition in Figure :31. The edges and vertices are marked so that the sets of vertices, edges, nodeless edges, and faces can he expressed more easily. ........ .. .. 75 71 A map showing an industrial and commercial zone. ... .. .. .. 8:3 72 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 74 The result of the intersect operation applied to two maps. .. .. .. 87 75 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 76 The result of the plane sweep portion of the intersect algorithm for the maps shown in Figure 75. A) The labeled geometry. B) The mapping. .. .. .. 90 77 The resulting label table from an intersect operation. A) The label table for the map shown in Figure 75A. B) The label table for the map shown in Figure 75B. C) The label table computed as the result of an intersect operation. .. 91 78 Processing halfsegments in a region. A) Processingf the smallest halfsegfment b of the sequence. B) Processing half segment k of a cvele. .. .. .. 101 79 The result of the r ,lItr; _. operation applied to two maps.. .. .. . .. 106 710 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 711 Running times for the intersect operation in PMAI and GISX. .. .. .. .. 11:3 712 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) [18], spatial databases [9 15], robotics [1619], computer assisted design (CAD) [2023], 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 li4 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 11: 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, 2830]. 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 [:3139] 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 11. 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 [36]: a map is a collection of map 1...ris 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 11 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 [37, 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 12 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 12. 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 multiuser 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 11sc 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 [4245]. A .simple point describes an element of the Euclidean plane RW2. A .simple line is a onedimensional, continuous geometric structure embedded in RW2 with two end points. A .simple region is a twodimensional 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 [4547] illustrated in Figure 21 ([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 onedimensional 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 21. 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, "holelike" configurations can exist if two components of one region touch at a single point of their boundaries at two different locations (Figure 22). Figure 22. Sample composite region with two components presenting a holelike 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 holelike 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 23. 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, 5052]. 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 23 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 [5558]. 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 24. The 9intersection 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 Ilency, 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 9intersection 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 9intersection model is typically used to model topological relationships between spatial objects in the field of SDSs. The 9intersection model characterizes the topological relationship between two spatial objects by evaluating the nonemptiness 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 9intersection mardrixr (911\), with values filled as illustrated in Figure 24 describes the topological relationships between a pair of objects: Various models of topologfical predicates based on the 9intersection 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 9intersection 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 9intersection model. For Table 21. 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 nonthematic maps, consisting of only a map geometry. In the nonthematic 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 21. 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 [1215, 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 twodimensional 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 From 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 Ilency 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 Ilent regions, each edge also carries an edge identifier indicating which edge would be encountered next if traversingf the current region in a clockwise or counterclockwise 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 [310, 14, 15, 40, 51, 6769]. 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 nonoverlapping 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 [7075]. 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 [7678]. 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, 7982]. 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 .Iiuplle 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 ahrl.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 Ilent 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 31. 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 fl : B 2A Of f is defined as f (y) := {x E A f(x) = y}. It is important to note that fl is a total function and that fl 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 nonempty, 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 settheoretic 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 Ilent 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 31 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 41 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) := xrl(rng(r) n {X E 2A X = 1}) (regions) (ii) Lo(iT) := iTl(rng(iT) n {X E 2A X > 1}) (borders) (nt)x :=Usemixtwos 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 41. 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 Ilent 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 42 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 42. 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 Ilent 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 9intersection 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 9intersection 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...flutConstraintandDrawing, in which we begin with the total set of 512 possible 9intersection 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 41. 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 04 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 = xr0D 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 41. Finally, we summarize our results as follows: Theorem 1. Based on the 9intersection model for spatial partitions, 49 different topologi cal relationships exist between two map geometries. Proof. The argumentation is based on the Pr...fbyConstraintandDrawing method. The constraint rules, whose correctness has been proven in Lemmas 1 to 8, reduce the 512 possible 9intersection matrices to 49 matrices. The ability to draw prototypes of the corresponding 49 topological configurations in Table 41 proves that the constraint rules are complete. O Table 41. 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 mediumgrey and has a dashed boundary, the other is lightgrey and has a dotted boundary. Overlapping naap interiors are darkgrey, 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 42. 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, highlevel 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 Highlevel 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 51 depicts two sample maps that satisfies these label constraints. The label type for the map shown in Figure 51A is (.string : C'rop), and the label structure for the map shown in Figure 51B 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 51. 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 51A has a label type field_crop = (string : Crop) and a spatial mapping ar : RW2 2fieldcro. 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 51, 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 51. 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 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 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 52 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 52. 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 52. 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 52, 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 52. 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 <::11;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 nonempty 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 nonempty 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 pakeion 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 :31 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 :31, 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 61A shows the refinement of the partition in A B Figure 61. A spatial partition and its corresponding SSPG. A) The refinement of the partition in Figure 31A. B) The SSPG corresponding to Figure A. Nodeless edges are dashed. Figure 31. Figure 61B shows the graph representation of the partition in Figure 61A 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 onedimensional 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 61A). 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 fourtup~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 62. A labeled plane nodeless pseudograph for the partition in Figure 31. 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 62 depicts the LPNP for the partition shown in Figfure ,31. 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 vwsi~. 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 ahrl . 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)EFG1=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 firstclass 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 71 throughout the following discussion. Figure 71. 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 interiorabove 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 72. 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 72 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 interiorabove 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 73. 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 71. 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 71 could be stored in the database as shown in Figure 73A. If we label the segments of the map as shown in Figure 73B 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 74. 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 74 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 75 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 75. 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 76. The result of the plane sweep portion of the intersect algorithm for the maps shown in Figure 75. 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 75A and Figure 75B, the result at this point is shown in Figure 76. 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 77. The resulting label table from an intersect operation. A) The label table for the map shown in Figure 75A. B) The label table for the map shown in Figure 75B. 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 75A and Figfure 75B are assumed to be those shown in Figure 77A and Figure 77B, the the label table of their intersection would be the table shown in Figure Figure 77C. 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 leftmost 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 From an implementation perspective, definingf a method for a user to create a relabeling function that can then be passed to an operation is nontrivial. 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 ahrlw 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 counterclockwise (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 leftmost 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 counterclockwise .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 24). 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 67), and the cycle must be walked using counterclockwise .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 interiorabove 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 1222). 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. From 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 ahlis 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 pakeion, the smallest halfsegment of a face will aknli be a left halfsegment with the interior of the face situated above it. Thus, when we process this halfsegment, we set its interiorabove flag to indicate this fact. Since we have classified this cycle as an outer cycle, we can walk the cycle and set the interiorabove flag for all halfsegments of this cycle. For example, Figure 78A 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 78B 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 78. 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 interiorabove 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 interiorabove 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 interiorabove 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 72 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 1222 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 1518). 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 counterclockwise rotation from hb is used to find h A counterclockwise 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 1518). 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 counterclockwise 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 counterclockwise 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 79. 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 79. 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 multiuser 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 postprocessing. 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 710. 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 710. 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 noncomplex 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 711 and Figure 712. 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 711, 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 711. 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 712, 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 nonintersecting 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 712. 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 multiuser access. Thus, none of these functionalities needed to be reimplemented 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. 508524. [2] J. Herring, "TIGRIS: A Data Model for an ObjectOriented 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. PrenticeHall, 1990O. [8] J. K(. Berry, "Fundamental Operations in ComputerAssisted Map Analysis," Int. Journal of C~~ l,.gory.1;..al Infortuation So/;,;l~; vol. 1, no. 2, pp. 119136, 1987. [9] A. U. Frank, "Overlay Processing in Spatial Information Systems," in Proc. of the 8th Int. Symp?. on C'omp~uterA~ssisted C'ar'i',.i''i,t;, AUTOG'ARTO 8, 1987, pp. 1631. [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, llVMap: A MultiScale Model for Vector Maps," Geoinfortuatica, vol. 10, no. :3, pp. :359394, 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. TR97005, 1997. [14] R. H. Gilting, "GeoRelational 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. 506527. [15] R. H. Gilting and 31. Schneider, "RealmBased Spatial Data Types: The ROSE Algebra," V/LDB Journal, vol. 4, pp. 10014:3, 1995. [16] T. Bittner, "The Qualitative Structure of Built Environments," Fundata. Inf., vol. 46, no. 12, pp. 97128, 2001. [17] V. Tsetsos, C. Anagnostopoulos, P. K~ikiras, P. Hasiotis, and S. HT Il111. T 1symiades, "A HumanCentered Semantic ?i.<1,, li;..1, System for Indoor Environments," perser, vol. 0, pp. 146155, 2005. [18] S. Vasudevan, S. Gachter, V. Nguyen, and R. Siegwart, "Cognitive Maps for Mobile Robotsan Object Based Approach," Robot. Anton. Syst., vol. 55, no. 5, pp. :359371, 2007. [19] S. Thrun, "Robotic Mapping: a Survey," pp. 135, 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. 11711184, 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(: SpringerV. ~11 1999, pp. :381399. [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~riegBrikkner, B. N. 11. I and T. Barkowsky, Eds., vol. :334:3. Springer, 2004, pp. 2441. [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. :3948, 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. 282291. [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. 288321. [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:39650, 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. 8695, 1994. [31] P. M. Aoki, "How to Avoid Building Datablades that K~now the Value of Everything and the Cost of Nothing," 1999, pp. 122133. [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. 71104. [33] J. Davis, "IBM's DB2 Spatial Extender: Managing GeoSpatial 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. 17111730, 1988. [35] M. Carey and L. Haas, "Extensible Database Management Systems," vol. 19, no. 4, pp. 5460, 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 MidFlight: As the Dust Clears," vol. 2, no. 1, pp. 143160, 1990. [38] L. A. Rowe and M. Stonebraker, "The POSTGRES Data Model," 1987, pp. 8396. [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. 2543, 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: SpringerVerlag New York, Inc., 1990, pp. 167190. [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. 409418. [42] A. Frank 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. 411436. [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. 271286. [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. 121136, 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. 3981, 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. SpringerV. ~11 g 199:3 pp. :3652. [48] E. Clementini, P. Di Felice, and G. Califano, "Composite Regions in Topological Queries," Infortuation So/;,~i;; vol. 20, pp. 579594, 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. 128142, 1994. [50] R. H. Gilting, "An Introduction to Spatial Database Systems," The V/LDB Journal, vol. :3, no. 4, pp. :357399, 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. 117. [52] U. Lipeck and K(. Neumann, "Modelling and Manipulating Objects in Geoscientific Databases," in ER, S. Spaccapietra, Ed. NorthHolland, 1986, pp. 6785. [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. 154, 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 RealmBased Spatial Data Types," in SSD '95: Proceedings of the 4th International Symp~osium on Advances in Spertical Dettebases. London, UK(: SpringerVerlag, 1995, pp. 216239. [56] 31. de Berg, 31. K~reveld, 31. Overmars, and O. Schwarzkopf, C'ompubstional Geome i, ; Algorithms and Applications. Berlin, Germany: SpringerVerlag, 2000. [57] D. E. Muller and F. P. Preparata, "Finding the Intersection of Two Convex Polyhedra," Theor. C'omput. Sci., vol. 7, pp. 2172:36, 1978. [58] J. Nievergelt and F. Preparata, "Planesweep Algorithms for Intersecting Geometric Figures," C'ommun. AC'\/I vol. 25, no. 10, pp. 7:39747, 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. 165176. [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 HoronoiBased 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 <;; 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. 74123, 1985. [65] 31. Erwig and 31. Schneider, "Partition and Conquer," in Srd Int C'onf. on Spertial Information Theory (G'OSIT). SpringerVerlag, 1997, pp. :389408. [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. 167184. [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. 3051. [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(: SpringferVerlagf, 1991, pp. 521. [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. :335348. [70] A. Guttman, "Rtrees: 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. 4757. [71] R. Finkel and J. Ben~tlh v, "Quad Trees: A Data Structure for Retrieval on Composite K~eys," Acta Inf., vol. 4, pp. 19, 1974. [72] J. Robinson, "The K(DBtree: 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. 1018. [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. 3871, 1984. [74] R. H. Gilting and H.P. K~riegel, \1!ul a bin is!sula i1 Btree: An Efficient Dynamic File Structure for Exact Match Queries," in GI rla1,~ I 1.;9.;;. ser. InformatikFachberichte , R. Wilhelm, Ed., vol. 33. Springer, 1980, pp. 375388. [75] J. Orenstein, "A Comparison of Spatial Query Processing Techniques for Native and Parameter Spaces," SIGM~OD Rec., vol. 19, no. 2, pp. 343352, 1990. [76] J. M. Patel and D. J. DeWitt, "Partition Based SpatialMerge Join," SlIC ITOD Rec., vol. 25, no. 2, pp. 259270, 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. 270285. [78] P. van Oosterom, "'An Rtree Based MapOverlay Algorithm," in EGIS/M~ARI '94, Paris, 1994, pp. 318327. [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. 119126. [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. 162177. [81] L. Arge, O. Procopiuc, S. R Ian. i. l!ini, T. Suel, and J. S. Vitter, "Scalable SweepingBased 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. 570581. [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. 1617. [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. C29, pp. 874883, 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.317. 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 tenuretrack 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:AHighlevelQueryLanguageforMaps ....... 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 21Asummaryofspatialsystemsandtheirtreatmentofmaps. ........... 26 41Therst42validmatricesandprotoypicaldrawingsrepr esentingthepossible topologicalrelationshipsbetweenmaps.Eachdrawingshow stheinteraction oftwomaps,onemapismediumgreyandhasadashedboundary, theotheris lightgreyandhasadottedboundary.Overlappingmapinter iorsaredarkgrey, andoverlappingboundariesaredrawnasasolidline.Forref erence,thegure formatrix41showstwodisjointmapsandthegureformatrix 1showstwo equalmaps. ...................................... 48 42Thenal7validmatricesandprotoypicaldrawingsrepre sentingthepossible topologicalrelationshipsbetweenmaps. ....................... 49 6 PAGE 7 LISTOFFIGURES Figure page 11Adepictionofcurrentspatialsystemarchitecture.The datalayermanagesstorage andretrievalofdatafromalesystemordatabase.Themiddl ewarelayerperforms processing.Theuserinterfacelayerprovidesuserinterac tionmechanisms. ... 13 12Ourproposedsystemarchitecture. ......................... 18 21Examplesofcomplexspatialobjects.A)Acomplexpointo bject.B)Acomplex lineobject.C)Acomplexregionobject. ...................... 21 22Samplecompositeregionwithtwocomponentspresenting aholelikestructure. 22 23Adepictionofvariousspatialoperationsappliedtotwo regions.A)Therst argumentregion.B)Thesecondargumentregion.C)Theinter sectionofthe regions.D)Theunionoftheregions.E)Thedierenceofther egions. ..... 23 24The9intersectionmatrixforspatialobjects A and B ............... 24 31Asamplespatialpartitionwithtworegions.A)Thespati alpartitionannotated withregionlabels.B)Thespatialpartitionwithitsregion andboundarylabels. Notethatlabelsaremodeledassetsofattributesinspatial partitions. ..... 36 41Aspatialpartition withtwodisconnectedfaces,onecontainingahole.A) Theinterior( ).B)Theboundary( @ ).D)Theexterior( ).Notethatthe labelshavebeenomittedinordertoemphasizethecomponent softhespatial partition. ....................................... 39 42Theapplicationofthereneoperationtoaspatialparti tion.A)Aspatialpartition withtworegionsanditsboundaryandregionlabels.B)There sultoftherene operationonFigure A ................................ 40 51Twosamplemaps.A)Amapwithlabelsconsistingofasingl estringnamed crop .B)Amapwithlabelsconsistingofapairofintegers,indica tingtheaverage temperatureandrainfallforeachregion,named Avg Temp and Avg Rain ,respectively. ............................................. 54 52Arelationcontainingamap2Dcolumnandtheassociatedl abeltables.Thetable Map1AttributeTableisassociatedwiththemapwithIDequal to1inthetable MapTable,andthetableMap2AttributeTableisassociatedw iththemapwith IDequalto2inthetableMapTable. ........................ 61 61AspatialpartitionanditscorrespondingSSPG.A)There nementofthepartition inFigure31A.B)TheSSPGcorrespondingtoFigure A .Nodelessedgesare dashed. ........................................ 70 7 PAGE 8 62Alabeledplanenodelesspseudographforthepartitioni nFigure31.Theedges andverticesaremarkedsothatthesetsofvertices,edges,n odelessedges,and facescanbeexpressedmoreeasily. ......................... 75 71Amapshowinganindustrialandcommercialzone. ................ 83 72Acomplexregionobjectwitheachsegmentlabeled. ................ 85 73Twodierentviewsofamap.A)Themaprepresentedinthei mplementation modelofMapAlgebra.B)Themapwithitssegmentslabeled. .......... 86 74Theresultofthe intersect operationappliedtotwomaps. ............ 87 75Aggregatingmaplabelsinanintersectoperation.A)The rstargumentmap. B)Thesecondargumentmap.C)Thetheresultofaggregatingt heargument maps'labelsduringanintersectoperation. ..................... 88 76Theresultoftheplanesweepportionoftheintersectalg orithmforthemaps showninFigure75.A)Thelabeledgeometry.B)Themapping. ........ 90 77Theresultinglabeltablefromanintersectoperation.A )Thelabeltablefor themapshowninFigure75A.B)Thelabeltableforthemapsho wninFigure 75B.C)Thelabeltablecomputedastheresultofanintersec toperation. ... 91 78Processinghalfsegmentsinaregion.A)Processingthes mallesthalfsegment h ofthesequence.B)Processinghalfsegment k ofacycle. ............. 101 79Theresultofthe overlay 2 operationappliedtotwomaps. ............. 106 710ImagesofthePMAIdisplayingthenalresultofthe overlay algorithmtestfor eachofthedatasetsused. .............................. 110 711RunningtimesfortheintersectoperationinPMAIandGI SX. .......... 113 712Runningtimesforthe 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 11 :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 .JEEMFXBSFBZFS %BUBBZFS "QQMJDBUJPO1SPHSBN 1SPDFTTJOHBZFSNBQPQFSBUJPOTn .BQ$POTUSVDUJPOBZFS NBQSFQSFTFOUBUJPOn %#.4 %BUB4UPSBHF TQBUJBMQSJNJUJWFTn "1* Figure11.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 11 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 12 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 %BUBBZFS 7JTVBMJ[BUJPO1SPHSBN "1* 1SPDFTTJOHBZFSNBQPQFSBUJPOTn %#.4 %BUB4UPSBHF NBQEBUBBOECBTJDTQBUJBMEBUBn Figure12.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,andmultiuseraccess.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 isaonedimensional, continuousgeometricstructureembeddedin R 2 withtwoendpoints.A simpleregion isa twodimensionalpointsetin R 2 andtopologicallyequivalenttoacloseddisk. Additionalrequirementsofapplicationsaswellasneededc losurepropertiesof operationsledtothesecondgenerationof complexspatialdatatypes [ 45 { 47 ]illustrated inFigure 21 ([ 10 ]forasurvey).A complexpoint isanitepointcollection(e.g.,the positionsofalllighthousesinFlorida).A complexline isanarbitrary,nitecollectionof onedimensionalcurves,i.e.,aspatiallyembeddednetwor kpossiblyconsistingofseveral disjointconnectedcomponents(e.g.,theNileDelta).A complexregion permitsmultiple $ # Figure21.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,\holelike"congurationscanexistiftwocompon entsofoneregiontouchata singlepointoftheirboundariesattwodierentlocations( Figure 22 ). Figure22.Samplecompositeregionwithtwocomponentspre sentingaholelikestructure. Asimpleregionwithholescontainsonlyasingleface,with nitelymanyholes.The holesinasimpleregionwithholesareallowedtomeetatapoi nt,butcannotforma congurationthatcausestheinterioroftheregiontobedis connected.Inotherwords,a holelikestructurecannotbeformedbytheholesinasimple 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 Figure23.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 23 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 Figure24.The9intersectionmatrixforspatialobjects A and B Topologicalrelationshipsindicatequalitativeproperti esoftherelativepositionsof spatialobjectsthatarepreservedundercontinuoustransf ormationssuchastranslation, rotation,andscaling.Quantitativemeasuressuchasdista nceorsizemeasurements aredeliberatelyexcludedinfavorofmodelingnotionssuch asconnectivity,adjacency, disjointedness,inclusion,andexclusion.Attemptstomod elandrigorouslydenethe relationshipsbetweencertaintypesofspatialobjectshav eleadtothedevelopment ofthreepopularapproaches:the 9intersectionmodel [ 44 ],whichisdevelopedbased onpointsettheoryandpointsettopology,the calculusbasedmethod [ 45 ],whichis alsobasedonpointsettopology,andthe RCCmodel [ 59 ],whichutilizesspatiallogic. Becausethedenitionsofspatialobjectsarebasedontopol ogicalprinciples,and theinabilityofthecalculusbasedmethodtoidentifyacomp letesetoftopological relationships,the9intersectionmodelistypicallyused tomodeltopologicalrelationships betweenspatialobjectsintheeldofSDSs.The9intersect ionmodelcharacterizesthe topologicalrelationshipbetweentwospatialobjectsbyev aluatingthenonemptinessofthe intersectionbetweenallcombinationsoftheinterior( ),boundary( @ )andexterior( )of theobjectsinvolved.Aunique3 3matrix,termedthe 9intersectionmatrix (9IM),with valueslledasillustratedinFigure 24 describesthetopologicalrelationshipsbetweena pairofobjects: Variousmodelsoftopologicalpredicatesbasedonthe9int 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 ],theauthorsapplyanextended9intersectionmodeltopoi 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 ythe9intersectionmodel.For 25 PAGE 26 Table21.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 nonthematicmaps,consistingofonlyamapgeometry.Inthe nonthematiccase,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 21 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 isaninterestingapproachtomodellingmapsbecausetwodi 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 ckwiseorcounterclockwise 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,andthenonoverlapp 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 31 Adepictsanexamplespatialpartitionconsistingoftworeg ions. Westatedabovethateachregioninaspatialpartitionisass ociatedwithasingle attributeorlabel.Aspatialpartitionismodeledbymappin gEuclideanspacetosuch labels.Labelsthemselvesaremodeledassetsofattributes .Theregionsofthespatial partitionarethendenedasconsistingofallpointswhichc ontainanidenticallabel. Adjacentregionseachhavedierentlabelsintheirinterio r,buttheircommonboundary isassignedthelabelcontainingthelabelsofbothadjacent regions.Figure 31 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 Figure31.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 nonempty,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 ttheoretic 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 31 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 41 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 Figure41.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 42 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 Figure42.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 ],inwhichthe9intersection modelisextendedtodescribecomplexpoints,lines,andreg ions.InSection 4.1 ,we denedapointsettopologicalmodelofmapgeometriesinwhi chweidentiedtheinterior, exterior,andboundarypointsetsbelongingtomaps.Basedo nthismodel,weextendthe 9intersectionmodeltoapplytothepointsetsbelongingto 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 ProofbyConstraintandDrawing ,inwhichwebeginwiththetotalsetof 512possible9intersectionmatrices,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 41 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 41 Finally,wesummarizeourresultsasfollows: Theorem1. Basedonthe9intersectionmodelforspatialpartitions,4 9dierenttopologicalrelationshipsexistbetweentwomapgeometries. Proof. Theargumentationisbasedonthe ProofbyConstraintandDrawing method. Theconstraintrules,whosecorrectnesshasbeenproveninL emmas 1 to 8 ,reducethe 512possible9intersectionmatricesto49matrices.Theab ilitytodrawprototypesofthe corresponding49topologicalcongurationsinTable 41 provesthattheconstraintrules arecomplete. 2 47 PAGE 48 Table41.Therst42validmatricesandprotoypicaldrawin gsrepresentingthepossible topologicalrelationshipsbetweenmaps.Eachdrawingshow stheinteractionof twomaps,onemapismediumgreyandhasadashedboundary,th eotheris lightgreyandhasadottedboundary.Overlappingmapinter iorsaredarkgrey, 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 Table42.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,highlevel 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:AHighlevelQueryLanguageforMaps 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 51 depictstwosamplemapsthatsatisestheselabelconstrain ts.Thelabel typeforthemapshowninFigure 51 Ais( string : Crop ),andthelabelstructurefor themapshowninFigure 51 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 Figure51.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 51 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 51 ,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 51 .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 52 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 Figure52.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 52 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 52 ,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 52 .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 isanonemptygraph 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 yanonempty 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 31 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 31 ,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 61 Ashowstherenementofthepartitionin 69 PAGE 70 \"rn^ \#^ \"rn^ \^ \#r^ \"rnr#^ \"rnr^ \"rnr^ \"rnr^ \^ \"rnr#r^ A B Figure61.AspatialpartitionanditscorrespondingSSPG. A)Therenementofthe partitioninFigure 31 A.B)TheSSPGcorrespondingtoFigure A .Nodeless edgesaredashed. Figure 31 .Figure 61 BshowsthegraphrepresentationofthepartitioninFigure 61 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 isaborderdenedbyaonedimensionalpointsetconsisting 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 61 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 isdenedbythefourtupleLPNP =( 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 Figure62.Alabeledplanenodelesspseudographforthepar titioninFigure 31 .The edgesandverticesaremarkedsothatthesetsofvertices,ed ges,nodeless edges,andfacescanbeexpressedmoreeasily. approximationsoftheedgessurroundingeachregionin alongwiththelabelofthe correspondingfacein .Givenanedge e ,weusethenotation V e ( e )toindicatethesetof verticesthat e connects.Figure 62 depictstheLPNPforthepartitionshowninFigure 31 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 tclass 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 71 throughoutthefollowingdiscussion. 82 PAGE 83 industrial commercial Figure71.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 interiorabove 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 Figure72.Acomplexregionobjectwitheachsegmentlabele d. Sinceasegmentcanbesubstitutedbytwohalfsegments,areg ionobjectcanbe implementedasanorderedsequence(array)ofhalfsegments .Asanexample,Figure 72 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 insteadofaninterioraboverag.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 Figure73.Twodierentviewsofamap.A)Themaprepresente dintheimplementation modelofMapAlgebra.B)Themapwithitssegmentslabeled. sameembeddingspaceareidentical.Furthermore,itisposs ible,basedonregionlabels,to reconstructanSPGgivenamaprepresentedintheimplementa tiondatamodelofMap Algebra.Thismeansthatthepropertiesofspatialpartitio nsdenedoverSPGscanbe checkedandenforcedattheimplementationlevel. AsanexampleoftheimplementationdatamodelofMapAlgebra ,considerthemap showninFigure 71 .Ifwehaveadatabasethatisawareofthecolumntype map2D that implementsthegeometryportionofamap,aswehaveshown,th enthemapinFigure 71 couldbestoredinthedatabaseasshowninFigure 73 A.Ifwelabelthesegmentsof themapasshowninFigure 73 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 Figure74.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 74 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 75 shows twomapsrepresentedintheimplementationmodelofMapAlge bra,completewithregion 87 PAGE 88 AB r r r r C Figure75.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 Figure76.Theresultoftheplanesweepportionoftheinter sectalgorithmforthemaps showninFigure 75 .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 75 A andFigure 75 B,theresultatthispointisshowninFigure 76 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 Figure77.Theresultinglabeltablefromanintersectoper ation.A)Thelabeltablefor themapshowninFigure 75 A.B)Thelabeltableforthemapshownin Figure 75 B.C)Thelabeltablecomputedastheresultofanintersect operation. fromtherstargumentmap.Notethatfortheselabels,theva luesincolumnsfromthe opposingmapwillbegivendefaultoremptyvalues.Then,the mappingfromaggregate labelstonewregionlabelsisusedtoconstructthelabelsfo roverlappingregionsfromthe argumentmaps.Thus,ifthelabeltablesforthemapsshownin Figure 75 AandFigure 75 BareassumedtobethoseshowninFigure 77 AandFigure 77 B,thethelabeltable oftheirintersectionwouldbethetableshowninFigureFigu re 77 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 istheleftmosthalfsegmentyettobeprocessed; 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 snontrivial.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)orcounterclockwise(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 istheleftmosthalfsegmentyettobeannotated; 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 Setcyclewalkmodetousecounterclockwiseadjacency; 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 (line24).Atthispoint,thealgorithmneedstodeterminew hether h belongstoa holecycle(line5)oranoutercycle(line9).Ifacycleiside ntiedasaholecycle,the outercycletowhichitbelongsmustalsobeidentied(line6 7),andthecyclemust bewalkedusingcounterclockwiseadjacencyofhalfsegmen 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 linestatusstructureandtheinterioraboveragof p issetto true ,itfollowsthat h is eitherintheinteriorofthecycletowhich p belongs,or h ispartofthecycletowhich p belongs.Recallthatassoonasahalfsegmentisclassiedas beingapartofaholeorface, thecycletowhichitbelongsiswalked(Section 7.1.2.3 )andallotherhalfsegmentsinthat cyclearemarkedaccordingly(lines1222).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 itsinterioraboveragtoindicatethisfact.Sincewehavec lassiedthiscycleasanouter cycle,wecanwalkthecycleandsettheinterioraboveragfo rallhalfsegmentsofthis cycle.Forexample,Figure 78 Aillustratesthecasewherethesmallesthalfsegmentofthe sequenceisprocessedandthecycleisclassiedasanouterc ycle. Oncetherstoutercycleofafaceinaregionhasbeenprocess ed,wecontinueto processhalfsegmentsthathavenotyetbeenclassiedbased ontheplanesweepstatus structure.Figure 78 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 Figure78.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 72 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 ines1222isexecuted.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(lines1518).The halfsegmentsformingtheholearethenmarkedassuch.There mainderoftheoutercycle isthenwalked. Walkingaholeisidenticaltowalkinganoutercycle,except thatacounterclockwise rotationfrom h b isusedtond h + .Acounterclockwiserotationisrequiredbecausethe interiorofthefaceisintersectedby h b whenrotating h b arounditsdominatingpoint. Whenwalkingholes,thespecialcaseexiststhattwoholesma ymeetatapoint.Thus, weemploythesamestrategytodetectthiscaseaswedidwitht hespecialcaseofahole meetingaface(lines1518). 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 counterclockwiseorderingaroundpoints.; else 21 Set b tomapto b in A ; 22 WalkthecycleasinAlgorithm 4 ,markingtheappropriatesideof 23 halfsegmentsasbeingvisited.Usecounterclockwiseorde 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 Figure79.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 79 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,andmultiuser access.Furthermore,weareabletousestandardSQLtoposeq ueriesoverattributedata, aswellasmaps.Furthermore,asinglemaptypeisusedtorepr esentspatialdatainthe databaseandintheviewer,sowecompletelyavoidamiddlewa relayer,andcandirectly displaytheresultsofoperationswithoutanypostprocess 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 Figure710.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 710 .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) howeachoperationperformsonsmallandnoncomplexdata.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 711 andFigure 712 .Eachgraphshowstheaveragerunningtimeforanalgorithmi nboth PMAIandGISX,andthenumberofhalfsegmentsintheresultin gmap.InFigure 711 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 Figure711.RunningtimesfortheintersectoperationinPM AIandGISX. PMAIdealswithintersectinghalfsegments.Whennohalfseg mentsintersect,eachmapis simplytraversed. InFigure 712 ,therunningtimeforPMAIisbrokendownintoitsconstituen tparts. Recallthe overlay 2 algorithminPMAIconsistsrstofan overlay algorithm,thena querytoremovethelabelsofthenonintersectingportions oftheargumentmapsfrom theresultmap,thena relabel operation.Therunningtimeforeachofthesecomponents isshown.FortheVermontandFloridadatasets,thePMAIalgo rithmclearlyperforms betterthantheGISXalgorithm.However,weseethatfortheT exasdataset,theGISX algorithmperformsbetterinnearlyeverycase.Theoverlay portionofthealgorithmruns competitively,butasthecomplexityofthemapsincreasesi ntermsofthenumberof 113 PAGE 114 Figure712.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,andmultiuserac cess.Thus,noneofthese functionalitiesneededtobereimplementedinmiddleware .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:ADataModelforanObjectOrientedGeo 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 PrenticeHall,1990. [8] J.K.Berry,\FundamentalOperationsinComputerAssisted MapAnalysis," Int. JournalofGeographicalInformationSystems ,vol.1,no.2,pp.119{136,1987. [9] A.U.Frank,\OverlayProcessinginSpatialInformationSys tems,"in Proc.ofthe8th Int.Symp.onComputerAssistedCartography,AUTOCARTO8 ,1987,pp.16{31. [10] M.Schneider, SpatialDataTypesforDatabaseSystemsFiniteResolution Geometry forGeographicInformationSystems .BerlinHeidelberg:SpringerVerlag,1997,vol. LNCS1288. [11] R.Viana,P.Magillo,E.Puppo,andP.A.Ramos,\MultiVMap: AMultiScale 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.TR97005,1997. [14] R.H.Guting,\GeoRelationalAlgebra:AModelandQueryLa nguageforGeometric DatabaseSystems,"in Int.Conf.onExtendingDatabaseTechnology(EDBT) ,1988, pp.506{527. [15] R.H.GutingandM.Schneider,\RealmBasedSpatialDataTy pes:TheROSE Algebra," VLDBJournal ,vol.4,pp.100{143,1995. 119 PAGE 120 [16] T.Bittner,\TheQualitativeStructureofBuiltEnvironmen ts," Fundam.Inf. ,vol.46, no.12,pp.97{128,2001. [17] V.Tsetsos,C.Anagnostopoulos,P.Kikiras,P.Hasiotis,an dS.Hadjiefthymiades, \AHumanCenteredSemanticNavigationSystemforIndoorEn vironments," perser vol.0,pp.146{155,2005. [18] S.Vasudevan,S.Gachter,V.Nguyen,andR.Siegwart,\Cogn itiveMapsforMobile RobotsanObjectBasedApproach," 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:SpringerVerlag,1999,pp.381{399. [25] U.J.RuetschiandS.Timpf,\ModellingWayndinginPubli cTransport:Network SpaceandSceneSpace,"in SpatialCognition ,ser.LectureNotesinComputer Science,C.Freksa,M.Knau,B.KriegBruckner,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:ManagingGeoSpatia 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 rstMidFlight: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:SpringerVerlagNewYork,Inc.,1990,pp.167{190. [41] M.McKenney,A.Pauly,R.Praing,andM.Schneider,\Ensurin gtheSemantic CorrectnessofComplexRegions,"in AdvancesinConceptualModelingFoundations 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 .SpringerVerlag,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 .SpringerVerlag,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.NorthHolland,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: EcientAlgorithmsforRealmBasedSpatialDataTypes,"in SSD'95:Proceedings ofthe4thInternationalSymposiumonAdvancesinSpatialDa tabases .London,UK: SpringerVerlag,1995,pp.216{239. [56] M.deBerg,M.Kreveld,M.Overmars,andO.Schwarzkopf, ComputationalGeometry:AlgorithmsandApplications .Berlin,Germany:SpringerVerlag,2000. [57] D.E.MullerandF.P.Preparata,\FindingtheIntersectiono fTwoConvex Polyhedra," Theor.Comput.Sci. ,vol.7,pp.217{236,1978. [58] J.NievergeltandF.Preparata,\PlanesweepAlgorithmsfo 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,\AVoronoiBasedMapAlgebra,"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.SpringerVerlag,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) .SpringerVerlag,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:SpringerVerlag,1991,pp.5{21. [69] C.R.Valenzuela,\DataAnalysisandModeling,"in RemoteSensingandGeographicalInformationSystemsforResourceManagementinDevelop ingCountries ,1991,pp. 335{348. [70] A.Guttman,\Rtrees: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,\TheKDBtree: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,\MultidimensionalBtree: AnEcientDynamicFile StructureforExactMatchQueries,"in GIJahrestagung ,ser.InformatikFachberichte, 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,\PartitionBasedSpatialMerge 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:SpringerVerlag,1999,pp.270{285. [78] P.vanOosterom,\'AnRtreeBasedMapOverlayAlgorithm," 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:SpringerVerlag,1993,pp.162{177. [81] L.Arge,O.Procopiuc,S.Ramaswamy,T.Suel,andJ.S.Vitter ,\Scalable SweepingBasedSpatialJoin,"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.C29,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 ofComputerScienceatTexasStateUniversityasatenuretr ackassistantprofessor. 126 