V%ȣOΏ9??:a"\fSrğjAsKJ:nOzO=}E1-I)3(QEQEQEQEQEQEQE֝Hza<["2"pO#f8M[RL(,?g93QSZuy"lx4h`O!LŏʨXZvq& c՚]+:ǵ@+J]tQ]~[[eϸ (]6A&>ܫ~+כzmZ^(<57KsHf妬Ϧmnẁ&F!:-`b\/(tF*Bֳ~V{WxxfCnMvF=;5_,6%S>}cQQjsOO5=)Ot[W9/{^tyNg#ЄGsֿ1-4ooTZ?K Gc+oyڙoNuh^iSo5{\ܹ3Yos}$.nQ-~n,-zr~-|K4R"8a{]^;I<ȤL5"EԤP7_j>OoK;*U.at*K[fym3ii^#wcC'IIkIp$|CtĈpW¹l{9>⪦*ͯj.LfGߍԁw] |WW18>w.ӯ!VӃ :#1~ +މ=;5c__b@W@ +^]ևՃ7 n&g2I8Lw7uҭ$"&"b eZ":8)D'%{}5{;w]iu;_dLʳ4R-,2H6>½HLKܹR ~foZKZ1[oZ7Z7R¢?«'y?A}C_iG5s_~^ J5? tp]X/c'r%eܺA|4ծ-Ե+ْe1M38Ǯ `|KյOVڅu;"d56, X5kYR<̭CiطXԮ ];Oy)OcWj֩}=܅s۸QZ*<~%뺃ȶp f~B ðzb\ݳzW*y{=[ C/Ak oXCkt_s}{'y?AmCjޓ{ WRV7r. g~Q"7&+c<=,dJ1V߁=T)TR՜*N4 ^Bڥ%B+=@fE5ka}ędܤFH^i1k\Sgdk> ֤aOM\_\T)8靠㡮3ģR:jj,pk/K!t,=ϯZ6(((((((49 xn_kLk&f9sK`zx{{y8H 8b4>ÇНE|7v(z/]k7IxM}8!ycZRQ pKVr(RPEr?^}'ðh{x+ՀLW154cK@N ~~gC)rr9+c:b Жf*s^fKS7^} *{zq_@8#pF~ [VPe(nw0MW=3#kȵz晨cyPpG#W:%drMh]3HH<\]ԁ|_W HHҡb}P>k{ZErxMX@8C&qskLۙOnO^sCk7ql2XCw5VG.S~H8=(s1~cV5z %v|U2QF=NoW]ո?<`~}=ӬfԵ,=;"~Iy7K#g{ñJ?5$y` zz@-~m7mG宝Gٱ>G&K#]y1$$t>wqjstX.b̐{Wej)Dxfc:8)=$y|L`xV8ߙ~E)HkwW$J0uʟk>6Sgp~;4W+חc"=|ř9bc5> *rg {~cj1rnI#G|8v4wĿhFb><^pJLm[Dl1;Vx5IZ:1*p)إ1ZbAK(1ׅ|S&5{^ KG^5r>;XK^? s fk^8O/"J)3K]N)iL~~?5!ƾq:G_=X- i,vi2N3 |03Qas!7}kZU781M,->e;@Qz T(GK(ah(((((((Y[×j2F}o־oYYq $+]%$ v^rϭ`nax,ZEuWSܽ,g%~"MrsrY~Ҿ"Fت;8{ѰxYEfP^;WPwqbB:c?zp<7;SBfZ)dϛ; 7s^>}⍱x?Bix^#hf,*P9S{w[]GF?1Z_nG~]kk)9Sc5Ո<<6J-ϛ}xUi>ux#ţc'{ᛲq?Oo?x&mѱ'#^t)ϲbb0 F«kIVmVsv@}kҡ!ˍUTtxO̧]ORb|2yԵk܊{sPIc_?ħ:Ig)=Z~' "\M2VSSMyLs l⺿U~"C7\hz_ Rs$~? TAi<l

O*>U}+'f>7_KNs8g1^CeКÿE;{+Y\ O5|Y{/o+LVcO;7Zx-Ek&dpzbӱ+TaB0gNy 3^cT\$⫫?F33?t._Q~Nln:U/Ceb1-im WʸQM+VpafR3dé|Aү-q*I P7:y&]hX^Fbtpܩ?|WuʫxJ3ߴm"(uqA}j.+?S wV~ [B&<^U?rϜ_OH\'.;|.%pw/ZZG'1j(#0UT`Wzw}>_*9m>F?EL3"zpubzΕ$+0܉&3zڶ+jyr1QE ( ( ( ( ( ( ( (UIdC0EZm+]Y6^![ ԯsmܶ捆?+me+ZE29)B[;я*wGxsK7;5w)}gH~.Ɣx?X\ߚ}A@tQ(:ͧ|Iq(CT?v[sKG+*רqҍck<#ǈα5݈`8cXP6T5i.K!xX*p&ќZǓϘ7 *oƽ:wlຈ:Q5yIEA/2*2jAҐe}k%K$N9R2?7ýKMV!{W9\PA+c4w` Wx=Ze\X{}yXI Ү!aOÎ{]Qx)#D@9E:*Ǌ}b|Z>_k7:d$z >&VvWlR:RqJfGإd9Tm(ҝEtO}1O[xxEYt8,3vbFF )ǙrPNE8=O#V*Cc&l&cmCh<.P{ʦ&ۣY+Gxs~k5$>ӥPquўZt~Tl>Q.g> %k#ú:Kn'&{[yWQGqF}AЅ/}<;VYZa$wQg!$;_ $NKS}_{MY|w7G!"\JtRy+贾d|o/;5jz_6fHwk<ѰJ#]kAȎJ=YNu%dxRwwbEQEQEQEQEQEQEQEQEQE'fLQZ(1F)hQ@X1KEQE-Q@ 1KE3h=iPb(((1GjZ(-ʹRPbR@ 1KE7`bڒyS0(-&)P+ ڎԴP11F)h&:LRmQ@Q@(((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((Z5/tbS($`Dǂ7Tg4*-ƫ8@$x =qh(o^4[7zծ-;UR!PNVz66h)[ELrɜ/$wrǱg;_c]V4V%ѦW qN6I'VSVf&-P7h)Y3>e֮W{Nş A`w$Ŀ M\/$:DW?'%Uj !пJ$@=wG Eq(t}ou['J>pO'k??J +?St}ll<kH33]7'Uq}%ٜ;IpzТWm)}G\]D\&H"dTgg'آF7~-Y5EﭴD1+mazC#rG$Þ'tB7ȹfW!JBNz鑎xJ+Mc?\}V̊Yd`P)sԳմBP\d8*r`JQ<6\K0DF dOj;=2K--cFIziυo5l]*sӜ;=N;.dɠHA#'JOX|&IwFf8bÏJԵm7F[SP"u2ĥNbp Ǳ /9//വA.H,x$Ƥxn⸷9$l]H #כ[մgƿq+%*8%I<RAEgzy_ڭ/w c8FqTn6q+i-fYT6*H8r(ԼKokzm;䌀dcW,o;8,.;&A"6 88 ,QT-[MѭT-,`g]L)lXqj]F[}S[lgd]$LW$d Ԣxn⸷9$l]H # _gojl|sVG #a=.Ug#KimrӆhN{O?eo;%}ssgD[kjN{7yrg۹J<9PM7ÛW)!yYTȹoAd w@Ҽeq56{ rk p dFFqOR7U|CO -I1$r@eTfo <C'C?IT&UlDFp(ƛzs[M$Ue_BGyz]?ͨzj6-¥낦Kvl#*H(j?4 1s6C5ԃ*o;%5w:ύm# caViA8:t:*?ֽt>,T {s;y_]覮?J53oڞy?nۻf+s?:t=%ҵ d_JXyW,01;y_]覮?J?~u[JSQ-Y$g*/N=X ׇ<+G7P^a;H ,W #y/!E+$WO)/3!62t'Ἲ݇qb;[("T* xk>}.s$SBŶrrp8fw?Ǫ\N4-VIeb|y6nBA \#y/!E+$WO)/3!62t'Ἲ݇qb;[("T* ;ߩ$d2ݿnXgvu741$ cװJ_<=qg}ɻko+sFݝcA%wG?gX&jrL@u\ܬ2;;V?C3ǧ˩^YD[wI IT@;OHuw҈zSm+×^4JQx}]jPTnAzSm(%$B(? b/5$ ;Ib{{R)T`7$FJ*?x0 xb}&o$7FigFvX Rpv0W4'"?4pGIkZHW Ѣ&eqs\߉>ү -[I@,2:u^Wcٶ.-$r*r@ CZt³. 'pA1w߁}1Z_]%3NK3eBq1@EY+ϥj#{B\v8x3lSIkLK&xSXb\gx^*TI%K=CM+*d\/u#k >_gojl|sVG #a=.Ug#Kimrӆh'cRֆ7±'mյy-ײҐ7*W+qny5G<+ Xm,G@vxOr@<$P** ( ( ( ( ( ( ( ( (0xs(˭hnP'ɶUPۀY91)ñègRA*Cb=뼢+YqZAikvCb4\Np2I?xagҾ0M*=Ԍ êME&2laQ+3$|=rv?Gu y8$rzqE?</=$$YlrǓVïOAL{?%=|;m#{~2_q;y}aggiݬAS|b [IѾ}._Lw)S9G" (5ߊ- LO,!#v*zu]mAuK2Ⱥ%v_,s$]clQ@ѭ v4,\T$g- ^Ai$ 6ZI8r[o#8tPEP?OkY4.fG 8]Cmۜd{#Ð< d9rO^㎽k#mmⷷ8`GjQ@V<yg\ <-w 'nqf (YMK@-n'>dG܊vGNbi`}%dٷvw}3օhw4x4&0nϷs<$I<yg\ <-w 'nqf (YMK@-n'>dG܊vGNXXu~]I)<:Պ(ï^k$# vFdv]EOh.ӣ,keO5À@9BF?lQEc[FE߉`٫!sPvoXt=/:sj^ڶNɓ;InS[(?FYQK;@.i$a$f Z߅oXhvdS3'e'ʶ((((((((((uC'Iﴯ;-gObn'=3Qh.tϊ:NWfUaxgU:P*\,,`*2@[yZJd!1Ċ͎`䁞84|)}cKǭhop _trgh=ZY+ kWjzTkk{l'cr7oP__<{,[]yTI +HMq,"yNckE4? oIy6|۷ E(X`;H$PQ^'a::έ:Ș30d`ѡ[_|"xvW m?JQ.X˒>^=?#Bkwv6}cmuwVkV5̒(YZ6@W|iKB=F=畃)T:ӵIPkVi2 .Z/k1-@WڼC/5xz[7g}Q)lO̬9;prh+Ro] g ;`]JP3_:WX`M^V3(f3(~ x-wǞ g"Y3jygzcpS@/?}}}M_36xU3Q^-zΡ"i4q+q]&Tc~$A/{#_`3MYY@AB`Px+_N-Wdwq)| gk8(~WYjDélw[PϚΛ/x_ڞ8Եu4UrDo@7acj8A_§FװPMk:7<&c]{Upw٢݀Akyڨ9χ<=gM}jV4XebF r ѿ?jcғoe`k(s5׃v8ݵ%\g nA?#i~UŲ|ř&SG(㲏A\|pFZ6ೆնyAU6?61>pQ.e}?&ںܪv6NYc\`rTO'UZ+x㧈|=a-WEHP~T u&Bs5]7GMR+u[TV`;v1=(OVğ-+%bRvbH(q^]/\1r]E$RQr2sgpV71_I h!rgg$F\\Gq=9HݜH3gQ^/+|U-UuoV2Rː;NbNPTzm&MCm[Lv0ՔFP n' =qyVOv|] )[u_c[07cqC²訨(ψ>*Uex{G:{+S\euk1'(*=O e& wY֭&d;yj#(X7gs@Eq|] )[u_c[07cyޥ\,!I&2 k`TBIڋ '`30h(u[o?t]Bdz0[R@!Tpr1_*JzO!4k=QIun^AB0r2цm+o5}~0RH,o8fHN2MzAuY}hN\T:ᖯ:x]XPeY0o*TPT} ?)fݑQh x+M \K*]0#e;ʠ'ѓӒO5xOzm<7igbL01NpMy|'`?^j Z[4?d1tb8UxZm4K=,-ͼQTXmx?<KK^f%'9V8$s[?Ⱥ.K1 ~~PY/r.&u}ΤDJEqC²訫4*C2;k;tIG$O$NIx+M6w455ӫ0bUF0pw?±kCy5ilϻKɐXшV9+MOw\-µ`;0緥t?_;}COhmR]l9Fr@+b;˛8no!IxG#=k~ o- $B@WQh^ 9̗~~~#j-I+w*.qï760Nk|iyKƹ(G#^wtz]s=ΙyO$&@Oʿnn^i}FeC`qQt; ߱q?φ.au?>B@v`5&#:[iՌwvbTYH*z8$t&yUs.{0Op J"x#|^xPy,r>w|ǢO5֭9T}ªyddpr3ǴA6[0D#5 `+s|.W-^ +]mԡ(6Ia@ǿz.|?,=K0DXu~B8b;<RϞ5>xsD:xTtXn oC|͓}'i؞4; Vnݻ ]qdx|Y`Z QSݝB[:A@eFkԞ|mTKt2H@ܲӓH;EWA[זNl$|5)I$!$-b?i.ݣ$gVɒwWx9g8ݏ^x7/{ĺgu+,=s$C WiZUevv(I9$I$@>|?ck7Bx`;*16OP @Ծ;崋Po5 OsT_+-ˮp8N5x ~~4Wvr~~GwwvG&vp.~x!-][+`1o&0EcG4Q^GxZǂiT {/mݵ, Ex}%|3Xz̩WsT%*pe$'+yc P ݣIu3Jȼ$`aae(((((((_?#yhOt:̌;Aln;b(ïVh$];<W!;q((((((((((((((((((((sY{߾[HW:*X3 TcwsoWNH$u]V9<c)6e댂G)ln.'gPyb+I:s=X[x"@TP0%yO|mnǗesghZg''inv2qg55#qF+C4X^:O8}ON̵&GZ^?:*?ֽt>,T {x_槨jyEq|ҹ1f_' Ȑ^X^R h]IH< =T{h|5՞u%Mad*yv W>hx{ᾇ\yz,6 ARuQ\uC7+khqz(vr@ Yg̞u֫6 ~t!9j9=q_>xٺ"ݚFN ibgq.Ǿ=n&OuXISцrs*C5UEnIn}M4x^UWȑp<ϰPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPMe/&`߿gkl\|UkoMf"@JOP_o~_ntvQ@gHMq4O \e 08 2~O>e4'hrm$P+Ooygvglvǥpq ס&"&2lmJvHW{J(W/Yj!g{nnnE*`p 㟄_5kv-/w :R8!@Ey>Br-[Ş"4Dݩ }$CEzP=qhλk7Eۍ=9O{M:y^'c,4hq"3WQ@? Vuo?^mA妙O]C}.]g,ǀ@zV\7!{_~~h 9mT@k( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( (?PKewlkgkPKlUIOEBPS/dcommon/oracle.gifJGIF87aiyDT2F'G;Q_oKTC[3-Bq{ttsoGc4I)GvmLZ).1)! ꑈ53=Z]'yuLG*)g^!8C?-6(29K"Ĩ0Яl;U+K9^u2,@@(\ȰË$P`ǉ8x I$4H *(@͉0dа8tA DсSPv"TUH PhP"Y1bxDǕ̧_=$I/& .)+ 60D)bB~=0#'& *D+l1MGCL1&+D`.1qVG( "D2QL,p.;u. |r$p+5qBNl<TzB"\9e0u )@D,¹2@C~KU 'L6a9 /;<`P!D#Tal6XTYhn[p]݅ 7}B a&AƮe{EɲƮiEp#G}D#xTIzGFǂEc^q}) Y# (tۮNeGL*@/%UB:&k0{ &SdDnBQ^("@q #` @1B4i@ aNȅ@[\B >e007V[N(vpyFe Gb/&|aHZj@""~ӎ)t? $ EQ.սJ$C,l]A `8A o B C?8cyA @Nz|`:`~7-G|yQAqA6OzPbZ`>~#8=./edGA2nrBYR@ W h'j4p'!k00MTRNF6̙ m` (7%ꑀ;PKl-OJPKlUIOEBPS/dcommon/blafdoc.cssc@charset "utf-8"; /* Copyright 2002, 2011, Oracle and/or its affiliates. All rights reserved. Author: Robert Crews Version: 2011.8.12 */ body { font-family: Tahoma, sans-serif; /* line-height: 125%; */ color: black; background-color: white; font-size: small; } * html body { /* http://www.info.com.ph/~etan/w3pantheon/style/modifiedsbmh.html */ font-size: x-small; /* for IE5.x/win */ f\ont-size: small; /* for other IE versions */ } h1 { font-size: 165%; font-weight: bold; border-bottom: 1px solid #ddd; width: 100%; text-align: left; } h2 { font-size: 152%; font-weight: bold; text-align: left; } h3 { font-size: 139%; font-weight: bold; text-align: left; } h4 { font-size: 126%; font-weight: bold; text-align: left; } h5 { font-size: 113%; font-weight: bold; display: inline; text-align: left; } h6 { font-size: 100%; font-weight: bold; font-style: italic; display: inline; text-align: left; } a:link { color: #039; background: inherit; } a:visited { color: #72007C; background: inherit; } a:hover { text-decoration: underline; } a img, img[usemap] { border-style: none; } code, pre, samp, tt { font-family: monospace; font-size: 110%; } caption { text-align: center; font-weight: bold; width: auto; } dt { font-weight: bold; } table { font-size: small; /* for ICEBrowser */ } td { vertical-align: top; } th { font-weight: bold; text-align: left; vertical-align: bottom; } li { text-align: left; } dd { text-align: left; } ol ol { list-style-type: lower-alpha; } ol ol ol { list-style-type: lower-roman; } td p:first-child, td pre:first-child { margin-top: 0px; margin-bottom: 0px; } table.table-border { border-collapse: collapse; border-top: 1px solid #ccc; border-left: 1px solid #ccc; } table.table-border th { padding: 0.5ex 0.25em; color: black; background-color: #f7f7ea; border-right: 1px solid #ccc; border-bottom: 1px solid #ccc; } table.table-border td { padding: 0.5ex 0.25em; border-right: 1px solid #ccc; border-bottom: 1px solid #ccc; } span.gui-object, span.gui-object-action { font-weight: bold; } span.gui-object-title { } p.horizontal-rule { width: 100%; border: solid #cc9; border-width: 0px 0px 1px 0px; margin-bottom: 4ex; } div.zz-skip-header { display: none; } td.zz-nav-header-cell { text-align: left; font-size: 95%; width: 99%; color: black; background: inherit; font-weight: normal; vertical-align: top; margin-top: 0ex; padding-top: 0ex; } a.zz-nav-header-link { font-size: 95%; } td.zz-nav-button-cell { white-space: nowrap; text-align: center; width: 1%; vertical-align: top; padding-left: 4px; padding-right: 4px; margin-top: 0ex; padding-top: 0ex; } a.zz-nav-button-link { font-size: 90%; } div.zz-nav-footer-menu { width: 100%; text-align: center; margin-top: 2ex; margin-bottom: 4ex; } p.zz-legal-notice, a.zz-legal-notice-link { font-size: 85%; /* display: none; */ /* Uncomment to hide legal notice */ } /*************************************/ /* Begin DARB Formats */ /*************************************/ .bold, .codeinlinebold, .syntaxinlinebold, .term, .glossterm, .seghead, .glossaryterm, .keyword, .msg, .msgexplankw, .msgactionkw, .notep1, .xreftitlebold { font-weight: bold; } .italic, .codeinlineitalic, .syntaxinlineitalic, .variable, .xreftitleitalic { font-style: italic; } .bolditalic, .codeinlineboldital, .syntaxinlineboldital, .titleinfigure, .titleinexample, .titleintable, .titleinequation, .xreftitleboldital { font-weight: bold; font-style: italic; } .itemizedlisttitle, .orderedlisttitle, .segmentedlisttitle, .variablelisttitle { font-weight: bold; } .bridgehead, .titleinrefsubsect3 { font-weight: bold; } .titleinrefsubsect { font-size: 126%; font-weight: bold; } .titleinrefsubsect2 { font-size: 113%; font-weight: bold; } .subhead1 { display: block; font-size: 139%; font-weight: bold; } .subhead2 { display: block; font-weight: bold; } .subhead3 { font-weight: bold; } .underline { text-decoration: underline; } .superscript { vertical-align: super; } .subscript { vertical-align: sub; } .listofeft { border: none; } .betadraft, .alphabetanotice, .revenuerecognitionnotice { color: #f00; background: inherit; } .betadraftsubtitle { text-align: center; font-weight: bold; color: #f00; background: inherit; } .comment { color: #080; background: inherit; font-weight: bold; } .copyrightlogo { text-align: center; font-size: 85%; } .tocsubheader { list-style-type: none; } table.icons td { padding-left: 6px; padding-right: 6px; } .l1ix dd, dd dl.l2ix, dd dl.l3ix { margin-top: 0ex; margin-bottom: 0ex; } div.infoboxnote, div.infoboxnotewarn, div.infoboxnotealso { margin-top: 4ex; margin-right: 10%; margin-left: 10%; margin-bottom: 4ex; padding: 0.25em; border-top: 1pt solid gray; border-bottom: 1pt solid gray; } p.notep1 { margin-top: 0px; margin-bottom: 0px; } .tahiti-highlight-example { background: #ff9; text-decoration: inherit; } .tahiti-highlight-search { background: #9cf; text-decoration: inherit; } .tahiti-sidebar-heading { font-size: 110%; margin-bottom: 0px; padding-bottom: 0px; } /*************************************/ /* End DARB Formats */ /*************************************/ @media all { /* * * { line-height: 120%; } */ dd { margin-bottom: 2ex; } dl:first-child { margin-top: 2ex; } } @media print { body { font-size: 11pt; padding: 0px !important; } a:link, a:visited { color: black; background: inherit; } code, pre, samp, tt { font-size: 10pt; } #nav, #search_this_book, #comment_form, #comment_announcement, #flipNav, .noprint { display: none !important; } body#left-nav-present { overflow: visible !important; } } PKr.hcPKlUIOEBPS/dcommon/doccd_epub.jsM /* Copyright 2006, 2012, Oracle and/or its affiliates. All rights reserved. Author: Robert Crews Version: 2012.3.17 */ function addLoadEvent(func) { var oldOnload = window.onload; if (typeof(window.onload) != "function") window.onload = func; else window.onload = function() { oldOnload(); func(); } } function compactLists() { var lists = []; var ul = document.getElementsByTagName("ul"); for (var i = 0; i < ul.length; i++) lists.push(ul[i]); var ol = document.getElementsByTagName("ol"); for (var i = 0; i < ol.length; i++) lists.push(ol[i]); for (var i = 0; i < lists.length; i++) { var collapsible = true, c = []; var li = lists[i].getElementsByTagName("li"); for (var j = 0; j < li.length; j++) { var p = li[j].getElementsByTagName("p"); if (p.length > 1) collapsible = false; for (var k = 0; k < p.length; k++) { if ( getTextContent(p[k]).split(" ").length > 12 ) collapsible = false; c.push(p[k]); } } if (collapsible) { for (var j = 0; j < c.length; j++) { c[j].style.margin = "0"; } } } function getTextContent(e) { if (e.textContent) return e.textContent; if (e.innerText) return e.innerText; } } addLoadEvent(compactLists); function processIndex() { try { if (!/\/index.htm(?:|#.*)$/.test(window.location.href)) return false; } catch(e) {} var shortcut = []; lastPrefix = ""; var dd = document.getElementsByTagName("dd"); for (var i = 0; i < dd.length; i++) { if (dd[i].className != 'l1ix') continue; var prefix = getTextContent(dd[i]).substring(0, 2).toUpperCase(); if (!prefix.match(/^([A-Z0-9]{2})/)) continue; if (prefix == lastPrefix) continue; dd[i].id = prefix; var s = document.createElement("a"); s.href = "#" + prefix; s.appendChild(document.createTextNode(prefix)); shortcut.push(s); lastPrefix = prefix; } var h2 = document.getElementsByTagName("h2"); for (var i = 0; i < h2.length; i++) { var nav = document.createElement("div"); nav.style.position = "relative"; nav.style.top = "-1.5ex"; nav.style.left = "1.5em"; nav.style.width = "90%"; while (shortcut[0] && shortcut[0].toString().charAt(shortcut[0].toString().length - 2) == getTextContent(h2[i])) { nav.appendChild(shortcut.shift()); nav.appendChild(document.createTextNode("\u00A0 ")); } h2[i].parentNode.insertBefore(nav, h2[i].nextSibling); } function getTextContent(e) { if (e.textContent) return e.textContent; if (e.innerText) return e.innerText; } } addLoadEvent(processIndex); PKo"nR M PKlUIOEBPS/dcommon/cpyr.htmd Oracle Legal Notices ## Oracle Legal Notices

## Copyright Notice

Copyright © 1994-2016, Oracle and/or its affiliates. All rights reserved.

## License Restrictions Warranty/Consequential Damages Disclaimer

This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited.

## Warranty Disclaimer

The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing.

## Restricted Rights Notice

If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, then the following notice is applicable:

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.

## Hazardous Applications Notice

This software or hardware is developed for general use in a variety of information management applications. It is not developed or intended for use in any inherently dangerous applications, including applications that may create a risk of personal injury. If you use this software or hardware in dangerous applications, then you shall be responsible to take all appropriate fail-safe, backup, redundancy, and other measures to ensure its safe use. Oracle Corporation and its affiliates disclaim any liability for any damages caused by use of this software or hardware in dangerous applications.

## Trademark Notice

Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.

Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. AMD, Opteron, the AMD logo, and the AMD Opteron logo are trademarks or registered trademarks of Advanced Micro Devices. UNIX is a registered trademark of The Open Group.

## Third-Party Content, Products, and Services Disclaimer

This software or hardware and documentation may provide access to or information about content, products, and services from third parties. Oracle Corporation and its affiliates are not responsible for and expressly disclaim all warranties of any kind with respect to third-party content, products, and services unless otherwise set forth in an applicable agreement between you and Oracle. Oracle Corporation and its affiliates will not be responsible for any loss, costs, or damages incurred due to your access to or use of third-party content, products, or services, except as set forth in an applicable agreement between you and Oracle.

## Alpha and Beta Draft Documentation Notice

If this document is in preproduction status:

This documentation is in preproduction status and is intended for demonstration and preliminary use only. It may not be specific to the hardware on which you are using the software. Oracle Corporation and its affiliates are not responsible for and expressly disclaim all warranties of any kind with respect to this documentation and will not be responsible for any loss, costs, or damages incurred due to the use of this documentation.

## Private Alpha and Beta Draft Documentation Notice

If this document is in private preproduction status:

The information contained in this document is for informational sharing purposes only and should be considered in your capacity as a customer advisory board member or pursuant to your beta trial agreement only. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, and timing of any features or functionality described in this document remains at the sole discretion of Oracle.

This document in any form, software or printed matter, contains proprietary information that is the exclusive property of Oracle. Your access to and use of this confidential material is subject to the terms and conditions of your Oracle Master Agreement, Oracle License and Services Agreement, Oracle PartnerNetwork Agreement, Oracle distribution agreement, or other license agreement which has been executed by you and Oracle and with which you agree to comply. This document and information contained herein may not be disclosed, copied, reproduced, or distributed to anyone outside Oracle without prior written consent of Oracle. This document is not part of your license agreement nor can it be incorporated into any contractual agreement with Oracle or its subsidiaries or affiliates.

## Documentation Accessibility

For information about Oracle's commitment to accessibility, visit the Oracle Accessibility Program website at

`http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc`

.Access to Oracle Support

Oracle customers that have purchased support have access to electronic support through My Oracle Support. For information, visit

PKS\UKPKlUI OEBPS/loe.htmq`http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info`

or visit`http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs`

if you are hearing impaired.List of Examples PKxHPKlUIOEBPS/sdo_index_query.htm## List of Examples

- 2-1 Simple Example: Inserting, Indexing, and Querying Spatial Data
- 2-2 SDO_GEOMETRY Methods
- 2-3 SDO_GEOMETRY Constructors to Create Geometries
- 2-4 SQL Statement to Insert a Rectangle
- 2-5 SQL Statement to Insert a Polygon with a Hole
- 2-6 SQL Statement to Insert a Compound Line String
- 2-7 SQL Statement to Insert a Compound Polygon
- 2-8 SQL Statement to Insert a Point-Only Geometry
- 2-9 Query for Point-Only Geometry Based on a Coordinate Value
- 2-10 SQL Statement to Insert an Oriented Point Geometry
- 2-11 SQL Statement to Insert an Oriented Multipoint Geometry
- 2-12 SQL Statement to Insert a Geometry with a Type 0 Element
- 2-13 SQL Statements to Insert Various Geometries
- 3-1 Control File for a Bulk Load of Cola Market Geometries
- 3-2 Control File for a Bulk Load of Polygons
- 3-3 Control File for a Bulk Load of Point-Only Data
- 3-4 Procedure to Perform a Transactional Insert Operation
- 3-5 PL/SQL Block Invoking a Procedure to Insert a Geometry
- 4-1 Primary Filter with a Temporary Query Window
- 4-2 Primary Filter with a Transient Instance of the Query Window
- 4-3 Primary Filter with a Stored Query Window
- 4-4 Secondary Filter Using a Temporary Query Window
- 4-5 Secondary Filter Using a Stored Query Window
- 5-1 Geocoding, Returning Address Object and Specific Attributes
- 5-2 Geocoding from a Place Name and Country
- 5-3 Geocoding from a Place Name, Country, and Other Fields
- 6-1 Using a Geodetic MBR
- 6-2 Creating a User-Defined Geodetic Coordinate Reference System
- 6-3 Inserting a Row into the SDO_COORD_SYS Table
- 6-4 Creating a User-Defined Projected Coordinate Reference System
- 6-5 Inserting a Row into the SDO_COORD_OPS Table
- 6-6 Inserting a Row into the SDO_COORD_OP_PARAM_VALS Table
- 6-7 Simplified Example of Coordinate System Transformation
- 6-8 Output of SELECT Statements in Coordinate System Transformation Example
- 7-1 Including LRS Measure Dimension in Spatial Metadata
- 7-2 Simplified Example: Highway
- 7-3 Simplified Example: Output of SELECT Statements
- C-1 Route Request with Specified Addresses
- C-2 Route Response with Specified Addresses
- C-3 Route Request with Specified Longitude/Latitude Points
- C-4 Route Response with Specified Longitude/Latitude Points
- C-5 Route Request with Previously Geocoded Locations
- C-6 Route Response with Previously Geocoded Locations
- C-7 Batch Route Request with Specified Addresses
- C-8 Batch Route Response with Specified Addresses
- C-9 Batch Route Request with Previously Geocoded Locations
- C-10 Batch Route Response with Previously Geocoded Locations
- D-1 Finding All Cities Within a Distance of a Highway
- D-2 Finding All Highways Within a Distance of a City
- D-3 Finding the Cities Nearest to a Highway
- D-4 Finding the Cities Above a Specified Population Nearest to a Highway
- D-5 Performing Aggregate Union of All Counties in Texas
Indexing and Querying Spatial Data PKpPKlUIOEBPS/sdo_objmigr.htm$### 4 Indexing and Querying Spatial Data

After you have loaded spatial data (discussed in Chapter 3), you should create a spatial index on it to enable efficient query performance using the data. This chapter describes how to:

Create a spatial index (see Section 4.1)

Query spatial data efficiently, based on an understanding of the Oracle Spatial query model and primary and secondary filtering (see Section 4.2)

## 4.1 Creating a Spatial Index

Once data has been loaded into the spatial tables through either bulk or transactional loading, a spatial index (that is, a spatial R-tree index) must be created on the tables for efficient access to the data. For example, the following statement creates a spatial index named

`territory_idx`

using default values for all parameters:CREATE INDEX territory_idx ON territories (territory_geom) INDEXTYPE IS MDSYS.SPATIAL_INDEX;For detailed information about options for creating a spatial index, see the documentation for the CREATE INDEX statement in Chapter 10.

If the index creation does not complete for any reason, the index is invalid and must be deleted with the DROP INDEX <index_name> [FORCE] statement.

Spatial indexes can be built on two, three, or four dimensions of data. The default number of dimensions is two, but if the data has more than two dimensions, you can use the

`sdo_indx_dims`

parameter keyword to specify the number of dimensions on which to build the index. However, if a spatial index has been built on more than two dimensions of a layer, the only spatial operator that can be used against that layer is SDO_FILTER (the primary filter or index-only query), which considers all dimensions. The SDO_RELATE, SDO_NN, and SDO_WITHIN_DISTANCE operators are disabled if the index has been built on more than two dimensions.If the rollback segment is not large enough, an attempt to create a spatial index will fail. The rollback segment should be 100*n bytes, where n is the number of rows of data to be indexed. For example, if the table contains 1 million (1,000,000) rows, the rollback segment size should be 100,000,000 (100 million) bytes.

To ensure an adequate rollback segment, or if you have tried to create a spatial index and received an error that a rollback segment cannot be extended, review (or have a DBA review) the size and structure of the rollback segments. Create a public rollback segment of the appropriate size, and place that rollback segment online. In addition, ensure that any small inappropriate rollback segments are placed offline during large spatial index operations. For information about performing these operations on a rollback segment, see Oracle Database Administrator's Guide.

The system parameter SORT_AREA_SIZE affects the amount of time required to create the index. The SORT_AREA_SIZE value is the maximum amount, in bytes, of memory to use for a sort operation. The optimal value depends on the database size, but a good guideline is to make it at least 1 million bytes when you create a spatial index. To change the SORT_AREA_SIZE value, use the ALTER SESSION statement. For example, to change the value to 20 million bytes:

ALTER SESSION SET SORT_AREA_SIZE = 20000000;The tablespace specified with the

`tablespace`

keyword in the CREATE INDEX statement (or the default tablespace if the`tablespace`

keyword is not specified) is used to hold both the index data table and some transient tables that are created for internal computations. If you specify WORK_TABLESPACE as the tablespace, the transient tables are stored in the work tablespace.For large tables (over 1 million rows), a temporary tablespace may be needed to perform internal sorting operations. The recommended size for this temporary tablespace is 100*n bytes, where n is the number of rows in the table, up to a maximum requirement of 1 gigabyte of temporary tablespace.

To estimate the space that will be needed to create a spatial index, use the SDO_TUNE.ESTIMATE_RTREE_INDEX_SIZE function, described in Chapter 19.

## 4.1.1 Indexing Geodetic Data

To take full advantage of Spatial features, you must index geodetic data using a geodetic R-tree index. Geodetic data consists of geometries that have geodetic SDO_SRID values, reflecting the fact that they are based on a geodetic coordinate system (such as using longitude and latitude) as opposed to a flat or projected plane coordinate system. (Chapter 6 explains coordinate systems and related concepts.) A geodetic index is one that provides the full range of Spatial features with geodetic data. Thus, it is highly recommended that you use a geodetic index with geodetic data.

Only R-tree indexes can be geodetic indexes. Quadtree indexes cannot be geodetic indexes. If you create an R-tree or quadtree index and specify

`'geodetic=false'`

in the CREATE INDEX statement, the index is non-geodetic. The following notes and restrictions apply to non-geodetic indexes:

If you create a non-geodetic index on geodetic data, you cannot use the

`unit`

parameter with the SDO_WITHIN_DISTANCE operator or the SDO_NN_DISTANCE ancillary operator with the SDO_NN operator.If you create a non-geodetic index on projected data that has a projected SDO_SRID value, you can use the full range of Spatial features.

If you create a non-geodetic index on projected data that has a null SDO_SRID value, you cannot use the

`unit`

parameter with the SDO_WITHIN_DISTANCE operator or the SDO_NN_DISTANCE ancillary operator with the SDO_NN operator.For additional information, see the Usage Notes about the

`geodetic`

parameter for the CREATE INDEX statement in Chapter 10.## 4.1.2 Constraining Data to a Geometry Type

When you create or rebuild a spatial index, you can ensure that all geometries that are in the table or that are inserted later are of a specified geometry type. To constrain the data to a geometry type in this way, use the

`layer_gtype`

keyword in the PARAMETERS clause of the CREATE INDEX or ALTER INDEX REBUILD statement, and specify a value from the Geometry Type column of Table 2-1 in Section 2.2.1. For example, to constrain spatial data in a layer to polygons:CREATE INDEX cola_spatial_idx ON cola_markets(shape) INDEXTYPE IS MDSYS.SPATIAL_INDEX PARAMETERS ('layer_gtype=POLYGON');The geometry types in Table 2-1 are considered as a hierarchy when data is checked:

The MULTI forms include the regular form also. For example, specifying

`'layer_gtype=`

`MULTIPOINT'`

allows the layer to include both POINT and MULTIPOINT geometries.COLLECTION allows the layer to include all types of geometries.

## 4.1.3 Creating a Cross-Schema Index

You can create a spatial index on a table that is not in your schema. Assume that user B wants to create a spatial index on column GEOMETRY in table T1 under user A's schema. Follow these steps:

Connect to the database as a privileged user (for example, as SYSTEM), and execute the following statement:

GRANT create table, create sequence to B;Connect as a privileged user or as user A (or have user A connect), and execute the following statement:

GRANT select, index on A.T1 to B;Connect as user B and execute a statement such as the following:

CREATE INDEX t1_spatial_idx on A.T1(geometry) INDEXTYPE IS mdsys.spatial_index;## 4.1.4 Using Partitioned Spatial Indexes

You can create a partitioned spatial index on a partitioned table. This section describes usage considerations specific to Oracle Spatial. For a detailed explanation of partitioned tables and partitioned indexes, see Oracle Database Administrator's Guide.

A partitioned spatial index can provide the following benefits:

Reduced response times for long-running queries, because partitioning reduces disk I/O operations

Reduced response times for concurrent queries, because I/O operations run concurrently on each partition

Easier index maintenance, because of partition-level create and rebuild operations

Indexes on partitions can be rebuilt without affecting the queries on other partitions, and storage parameters for each local index can be changed independent of other partitions.

Parallel query on multiple partition searching

The degree of parallelism is the value from the DEGREE column in the row for the index in the USER_INDEXES view (that is, the value specified or defaulted for the PARALLEL keyword with the CREATE INDEX, ALTER INDEX, or ALTER INDEX REBUILD statement).

Improved query processing in multiprocessor system environments

In a multiprocessor system environment, if a spatial operator is invoked on a table with partitioned spatial index and if multiple partitions are involved in the query, multiple processors can be used to evaluate the query. The number of processors used is determined by the degree of parallelism and the number of partitions used in evaluating the query.

The following restrictions apply to spatial index partitioning:

The partition key for spatial tables must be a scalar value, and must not be a spatial column.

Only range partitioning is supported on the underlying table. Hash and composite partitioning are not currently supported for partitioned spatial indexes.

To create a partitioned spatial index, you must specify the LOCAL keyword. For example:

CREATE INDEX counties_idx ON counties(geometry) INDEXTYPE IS MDSYS.SPATIAL_INDEX LOCAL;In this example, the default values are used for the number and placement of index partitions, namely:

Index partitioning is based on the underlying table partitioning. For each table partition, a corresponding index partition is created.

Each index partition is placed in the default tablespace.

If you do specify parameters for individual partitions, the following considerations apply:

The storage characteristics for each partition can be the same or different for each partition. If they are different, it may enable parallel I/O (if the tablespaces are on different disks) and may improve performance.

The

`sdo_indx_dims`

value must be the same for all partitions.The

`layer_gtype`

parameter value (see Section 4.1.2) used for each partition may be different.To override the default partitioning values, use a CREATE INDEX statement with the following general format:

CREATE INDEX <indexname> ON <table>(<column>) INDEXTYPE IS MDSYS.SPATIAL_INDEX [PARAMETERS ('<spatial-params>, <storage-params>')] LOCAL [( PARTITION <index_partition> PARAMETERS ('<spatial-params>, <storage-params>') [, PARTITION <index_partition> PARAMETERS ('<spatial-params>, <storage-params>')] )]Queries can operate on partitioned tables to perform the query on only one partition. For example:

SELECT * FROM counties PARTITION(p1) WHERE ...<some-spatial-predicate>;Querying on a selected partition may speed up the query and also improve overall throughput when multiple queries operate on different partitions concurrently.

When queries use a partitioned spatial index, the semantics (meaning or behavior) of spatial operators and functions is the same with partitioned and nonpartitioned indexes, except in the case of SDO_NN (nearest neighbor). With SDO_NN, the requested number of geometries is returned for each partition that is affected by the query. For example, if you request the 5 closest restaurants to a point and the spatial index has 4 partitions, SDO_NN returns up to 20 (5*4) geometries. In this case, you must use the ROWNUM pseudocolumn (here,

`WHERE ROWNUM <=5`

) to return the 5 closest restaurants. See the description of the SDO_NN operator in Chapter 11 for more information.## 4.1.5 Exchanging Partitions Including Indexes

You can use the ALTER TABLE statement with the EXCHANGE PARTITION ... INCLUDING INDEXES clause to exchange a spatial table partition and its index partition with a corresponding table and its index. For information about exchanging partitions, see the description of the ALTER TABLE statement in Oracle Database SQL Reference.

This feature can help you to operate more efficiently in a number of situations, such as:

Bringing data into a partitioned table and avoiding the cost of index re-creation.

Managing and creating partitioned indexes. For example, the data could be divided into multiple tables. The index for each table could be built one after the other to minimize the memory and tablespace resources needed during index creation. Alternately, the indexes could be created in parallel in multiple sessions. The tables (along with the indexes) could then be exchanged with the partitions of the original data table.

Managing offline insert operations. New data can be stored in a temporary table and periodically exchanged with a new partition (for example, in a database with historical data).

To exchange partitions including indexes with spatial data and indexes, the two spatial indexes (one on the partition, the other on the table) must be of compatible types. Specifically:

Both indexes must have the same dimensionality (

`sdo_indx_dims`

value).Both indexes must be either geodetic or non-geodetic. (Geodetic and non-geodetic indexes are explained in Section 4.1.1.)

If the indexes are not compatible, an error is raised. The table data is exchanged, but the indexes are not exchanged and the indexes are marked as failed. To use the indexes, you must rebuild them.

## 4.1.6 Export and Import Considerations with Spatial Indexes and Data

If you use the Export utility to export tables with spatial data, the behavior of the operation depends on whether or not the spatial data has been spatially indexed:

If the spatial data has not been spatially indexed, the table data is exported. However, you must update the USER_SDO_GEOM_METADATA view with the appropriate information on the target system.

If the spatial data has been spatially indexed, the table data is exported, the appropriate information is inserted into the USER_SDO_GEOM_METADATA view on the target system, and the spatial index is built on the target system. However, if the insertion into the USER_SDO_GEOM_METADATA view fails (for example, if there is already a USER_SDO_GEOM_METADATA entry for the spatial layer), the spatial index is not built.

If you use the Import utility to import data that has been spatially indexed, the following considerations apply:

If the index on the exported data was created with a

`TABLESPACE`

clause and if the specified tablespace does not exist in the database at import time, the index is not built. (This is different from the behavior with other Oracle indexes, where the index is created in the user's default tablespace if the tablespace specified for the original index does not exist at import time.)If the import operation must be done by a privileged database user, and if the

`FROMUSER`

and`TOUSER`

format is used, the`TOUSER`

user must be granted the CREATE TABLE and CREATE SEQUENCE privileges before the import operation, as shown in the following example:sqlplus system/<password> SQL> grant CREATE TABLE, CREATE SEQUENCE to CHRIS; SQL> exit; imp system/<password> file=spatl_data.dmp fromuser=SCOTT touser=CHRISFor information about using the Export and Import utilities, see Oracle Database Utilities.

## 4.1.7 Distributed Transactions and Spatial Index Consistency

In a distributed transaction, different branches of the transaction can execute in different sessions. The branches can detach from their current session and migrate to another within the transaction scope. To maintain the consistency of Spatial indexes in distributed transactions, you must follow the usage guidelines in this section.

When the first insert, update, or delete operation on a spatial table (one with a spatial index) is performed in a distributed transaction, all subsequent insert, update, or delete operations on the table, as well as any prepare to commit operation (the first branch to prepare a commit), in the transaction should happen in the same session as the first operation. The branches performing these subsequent operations will first have to connect to the session in which the first operation was performed.

For more information about distributed transactions, see Oracle Database Administrator's Guide.

## 4.2 Querying Spatial Data

This section describes how the structures of a Spatial layer are used to resolve spatial queries and spatial joins.

Spatial uses a two-tier query model with primary and secondary filter operations to resolve spatial queries and spatial joins, as explained in Section 1.6. The term two-tier indicates that two distinct operations are performed to resolve queries. If both operations are performed, the exact result set is returned.

You cannot append a database link (dblink) name to the name of a spatial table in a query if a spatial index is defined on that table.

If a spatial index is created in a database that was created using the UTF8 character set, spatial queries that use the spatial index will fail if the system parameter

`NLS_LENGTH_SEMANTICS`

is set to`CHAR`

. For spatial queries to succeed in this case, the`NLS_LENGTH_SEMANTICS`

parameter must be set to`BYTE`

(its default value).## 4.2.1 Spatial Query

In a spatial R-tree index, each geometry is represented by its minimum bounding rectangle (MBR), as explained in Section 1.7.1. Consider the following layer containing several objects in Figure 4-1. Each object is labeled with its geometry name (geom_1 for the line string, geom_2 for the four-sided polygon, geom_3 for the triangular polygon, and geom_4 for the ellipse), and the MBR around each object is represented by a dashed line.

A typical spatial query is to request all objects that lie within a query window, that is, a defined fence or window. A dynamic query window refers to a rectangular area that is not defined in the database, but that must be defined before it is used. Figure 4-2 shows the same geometries as in Figure 4-1, but adds a query window represented by the heavy dotted-line box.

In Figure 4-2, the query window covers parts of geometries geom_1 and geom_2, as well as part of the MBR for geom_3 but none of the actual geom_3 geometry. The query window does not cover any part of the geom_4 geometry or its MBR.

## 4.2.1.1 Primary Filter Operator

The SDO_FILTER operator, described in Chapter 11, implements the primary filter portion of the two-step process involved in the Oracle Spatial query processing model. The primary filter uses the index data to determine only if a set of candidate object pairs may interact. Specifically, the primary filter checks to see if the MBRs of the candidate objects interact, not whether the objects themselves interact. The SDO_FILTER operator syntax is as follows:

SDO_FILTER(geometry1 SDO_GEOMETRY, geometry2 SDO_GEOMETRY, param VARCHAR2)In the preceding syntax:

`geometry1`

is a column of type SDO_GEOMETRY in a table. This column must be spatially indexed.

`geometry2`

is an object of type SDO_GEOMETRY. This object may or may not come from a table. If it comes from a table, it may or may not be spatially indexed.

`param`

is an optional string of type VARCHAR2. It can specify either or both of the`min_resolution`

and`max_resolution`

keywords.The following examples perform a primary filter operation only (with no secondary filter operation). They will return all the geometries shown in Figure 4-2 that have an MBR that interacts with the query window. The result of the following examples are geometries geom_1, geom_2, and geom_3.

Example 4-1 performs a primary filter operation without inserting the query window into a table. The window will be indexed in memory and performance will be very good.

Example 4-1 Primary Filter with a Temporary Query Window

SELECT A.Feature_ID FROM TARGET A WHERE sdo_filter(A.shape, SDO_geometry(2003,NULL,NULL, SDO_elem_info_array(1,1003,3), SDO_ordinate_array(x1,y1, x2,y2)) ) = 'TRUE';In Example 4-1,

`(x1,y1)`

and`(x2,y2)`

are the lower-left and upper-right corners of the query window.In Example 4-2, a transient instance of type SDO_GEOMETRY was constructed for the query window instead of specifying the window parameters in the query itself.

Example 4-2 Primary Filter with a Transient Instance of the Query Window

SELECT A.Feature_ID FROM TARGET A WHERE sdo_filter(A.shape, :theWindow) = 'TRUE';Example 4-3 assumes the query window was inserted into a table called WINDOWS, with an ID of WINS_1.

Example 4-3 Primary Filter with a Stored Query Window

SELECT A.Feature_ID FROM TARGET A, WINDOWS B WHERE B.ID = 'WINS_1' AND sdo_filter(A.shape, B.shape) = 'TRUE';If the B.SHAPE column is not spatially indexed, the SDO_FILTER operator indexes the query window in memory and performance is very good.

## 4.2.1.2 Primary and Secondary Filter Operator

The SDO_RELATE operator, described in Chapter 11, performs both the primary and secondary filter stages when processing a query. The secondary filter ensures that only candidate objects that actually interact are selected. This operator can be used only if a spatial index has been created on two dimensions of data. The syntax of the SDO_RELATE operator is as follows:

SDO_RELATE(geometry1 SDO_GEOMETRY, geometry2 SDO_GEOMETRY, param VARCHAR2)In the preceding syntax:

`geometry1`

is a column of type SDO_GEOMETRY in a table. This column must be spatially indexed.

`geometry2`

is an object of type SDO_GEOMETRY. This object may or may not come from a table. If it comes from a table, it may or may not be spatially indexed.

`param`

is a quoted string with the`mask`

keyword and a valid mask value, and optionally either or both of the`min_resolution`

and`max_resolution`

keywords, as explained in the documentation for the SDO_RELATE operator in Chapter 11.The following examples perform both primary and secondary filter operations. They return all the geometries in Figure 4-2 that lie within or overlap the query window. The result of these examples is objects geom_1 and geom_2.

Example 4-4 performs both primary and secondary filter operations without inserting the query window into a table. The window will be indexed in memory and performance will be very good.

Example 4-4 Secondary Filter Using a Temporary Query Window

SELECT A.Feature_ID FROM TARGET A WHERE sdo_relate(A.shape, SDO_geometry(2003,NULL,NULL, SDO_elem_info_array(1,1003,3), SDO_ordinate_array(x1,y1, x2,y2)), 'mask=anyinteract') = 'TRUE';In Example 4-4,

`(x1,y1)`

and`(x2,y2)`

are the lower-left and upper-right corners of the query window.Example 4-5 assumes the query window was inserted into a table called WINDOWS, with an ID value of WINS_1.

Example 4-5 Secondary Filter Using a Stored Query Window

SELECT A.Feature_ID FROM TARGET A, WINDOWS B WHERE B.ID = 'WINS_1' AND sdo_relate(A.shape, B.shape, 'mask=anyinteract') = 'TRUE';If the( B.SHAPE column is not spatially indexed, the SDO_RELATE operator indexes the query window in memory and performance is very good.

## 4.2.1.3 Within-Distance Operator

The SDO_WITHIN_DISTANCE operator, described in Chapter 11, is used to determine the set of objects in a table that are within n distance units from a reference object. This operator can be used only if a spatial index has been created on two dimensions of data. The reference object may be a transient or persistent instance of SDO_GEOMETRY (such as a temporary query window or a permanent geometry stored in the database). The syntax of the operator is as follows:

SDO_WITHIN_DISTANCE(geometry1 SDO_GEOMETRY, aGeom SDO_GEOMETRY, params VARCHAR2);In the preceding syntax:

`geometry1`

is a column of type SDO_GEOMETRY in a table. This column must be spatially indexed.

`aGeom`

is an instance of type SDO_GEOMETRY.

`params`

is a quoted string of keyword value pairs that determines the behavior of the operator. See the SDO_WITHIN_DISTANCE operator in Chapter 11 for a list of parameters.The following example selects any objects within 1.35 distance units from the query window:

SELECT A.Feature_ID FROM TARGET A WHERE SDO_WITHIN_DISTANCE( A.shape, :theWindow, 'distance=1.35') = 'TRUE';The distance units are based on the geometry coordinate system in use. If you are using a geodetic coordinate system, the units are meters. If no coordinate system is used, the units are the same as for the stored data.

The SDO_WITHIN_DISTANCE operator is not suitable for performing spatial joins. That is, a query such as Find all parks that are within 10 distance units from coastlines will not be processed as an index-based spatial join of the COASTLINES and PARKS tables. Instead, it will be processed as a nested loop query in which each COASTLINES instance is in turn a reference object that is buffered, indexed, and evaluated against the PARKS table. Thus, the SDO_WITHIN_DISTANCE operation is performed n times if there are n rows in the COASTLINES table.

For non-geodetic data, there is an efficient way to accomplish a spatial join that involves buffering all geometries of a layer. This method does not use the SDO_WITHIN_DISTANCE operator. First, create a new table COSINE_BUFS as follows:

CREATE TABLE cosine_bufs UNRECOVERABLE AS SELECT SDO_BUFFER (A.SHAPE, B.DIMINFO, 1.35) FROM COSINE A, USER_SDO_GEOM_METADATA B WHERE TABLE_NAME='COSINES' AND COLUMN_NAME='SHAPE';Next, create a spatial index on the SHAPE column of COSINE_BUFS. Then you can perform the following query:

SELECT /*+ ordered */ a.gid, b.gid FROM TABLE(SDO_JOIN('PARKS', 'SHAPE', 'COSINE_BUFS', 'SHAPE', 'mask=ANYINTERACT')) c, parks a, cosine_bufs b WHERE c.rowid1 = a.rowid AND c.rowid2 = b.rowid;## 4.2.1.4 Nearest Neighbor Operator

The SDO_NN operator, described in Chapter 11, is used to identify the nearest neighbors for a geometry. This operator can be used only if a spatial index has been created on two dimensions of data. The syntax of the operator is as follows:

SDO_NN(geometry1 SDO_GEOMETRY, geometry2 SDO_GEOMETRY, param VARCHAR2 [, number NUMBER]);In the preceding syntax:

`geometry1`

is a column of type SDO_GEOMETRY in a table. This column must be spatially indexed.

`geometry2`

is an instance of type SDO_GEOMETRY.

`param`

is a quoted string of keyword-value pairs that can determine the behavior of the operator, such as how many nearest neighbor geometries are returned. See the SDO_NN operator in Chapter 11 for information about this parameter.

`number`

is the same number used in the call to SDO_NN_DISTANCE. Use this only if the SDO_NN_DISTANCE ancillary operator is included in the call to SDO_NN. See the SDO_NN operator in Chapter 11 for information about this parameter.The following example finds the two objects from the SHAPE column in the COLA_MARKETS table that are closest to a specified point (10,7). (Note the use of the optimizer hint in the SELECT statement, as explained in the Usage Notes for the SDO_NN operator in Chapter 11.)

SELECT /*+ INDEX(cola_markets cola_spatial_idx) */ c.mkt_id, c.name FROM cola_markets c WHERE SDO_NN(c.shape, SDO_geometry(2001, NULL, SDO_point_type(10,7,NULL), NULL, NULL), 'sdo_num_res=2') = 'TRUE';## 4.2.1.5 Spatial Functions

Spatial also supplies functions for determining relationships between geometries, finding information about single geometries, changing geometries, and combining geometries. These functions all take into account two dimensions of source data. If the output value of these functions is a geometry, the resulting geometry will have the same dimensionality as the input geometry, but only the first two dimensions will accurately reflect the result of the operation.

## 4.2.2 Spatial Join

A spatial join is the same as a regular join except that the predicate involves a spatial operator. In Spatial, a spatial join takes place when you compare all geometries of one layer to all geometries of another layer. This is unlike a query window, which compares a single geometry to all geometries of a layer.

Spatial joins can be used to answer questions such as Which highways cross national parks?

The following table structures illustrate how the join would be accomplished for this example:

PARKS( GID VARCHAR2(32), SHAPE SDO_GEOMETRY) HIGHWAYS( GID VARCHAR2(32), SHAPE SDO_GEOMETRY)To perform a spatial join, use the SDO_JOIN operator, which is described in Chapter 11. The following spatial join query, to list the GID column values of highways and parks where a highway interacts with a park, performs a primary filter operation only (

`'mask=FILTER'`

), and thus it returns only approximate results:SELECT /*+ ordered */ a.gid, b.gid FROM TABLE(SDO_JOIN('PARKS', 'SHAPE', 'HIGHWAYS', 'SHAPE', 'mask=FILTER')) c, parks a, highways b WHERE c.rowid1 = a.rowid AND c.rowid2 = b.rowid;The following spatial join query requests the same information as in the preceding example, but it performs both primary and secondary filter operations (

`'mask=ANYINTERACT'`

), and thus it returns exact results:SELECT /*+ ordered */ a.gid, b.gid FROM TABLE(SDO_JOIN('PARKS', 'SHAPE', 'HIGHWAYS', 'SHAPE', 'mask=ANYINTERACT')) c, parks a, highways b WHERE c.rowid1 = a.rowid AND c.rowid2 = b.rowid;## 4.2.3 Cross-Schema Operator Invocation

You can invoke spatial operators on an indexed table that is not in your schema. Assume that user A has a spatial table T1 (with index table IDX_TAB1) with a spatial index defined, that user B has a spatial table T2 (with index table IDX_TAB2) with a spatial index defined, and that user C wants to invoke operators on tables in one or both of the other schemas.

If user C wants to invoke an operator only on T1, user C must perform the following steps:

Connect as user A and execute the following statements:

GRANT select on T1 to C; GRANT select on idx_tab1 to C;Connect as user C and execute a statement such as the following:

SELECT a.gid FROM T1 a WHERE sdo_filter(a.geometry, :theGeometry) = 'TRUE';If user C wants to invoke an operator on both T1 and T2, user C must perform the following steps:

Connect as user A and execute the following statements:

GRANT select on T1 to C; GRANT select on idx_tab1 to C;Connect as user B and execute the following statements:

GRANT select on T2 to C; GRANT select on idx_tab2 to C;Connect as user C and execute a statement such as the following:

SELECT a.gid FROM T1 a, T2 b WHERE b.gid = 5 AND sdo_filter(a.geometry, b.geometry) = 'TRUE';SDO_MIGRATE Package (Upgrading) PK$$PKlUIOEBPS/blafdoc.cssj@charset "utf-8"; /* blafdoc.css Release 4.5 Copyright 2002, 2005, Oracle. All rights reserved. */ body, p, table, td, th, ol, ul, a, dl, dt, dd, blockquote, caption { font-family: Arial, Helvetica, sans-serif; line-height: 1.25; color: black; background-color: white; /* Fahrner Method. See Zeldman. Working with Web Standards. pp. 323-5. */ font-size: x-small; voice-family: "\"}\""; voice-family: inherit; font-size: small; } html > body { font-size: small; } a { text-decoration: underline; } a:link { color: #630; background-color: white; } a:visited { color: #963; background-color: white; } a:hover { color: #f60; background-color: white; } a:active { color: #f60; background-color: white; } a.glossary-link { border-bottom: 1px dotted; text-decoration: none; } h1, h2, h3, h4 { font-family: Arial, Helvetica, sans-serif; color: #369; background-color: white; } h1 { font-size: 1.6em; font-weight: bold; border: solid #cc9; border-width: 0px 0px 1px 0px; width: 100%; } h2 { font-size: 1.3em; font-weight: bold; } h3 { font-size: 1.1em; font-weight: bold; } h4 { font-size: 1em; font-weight: bold; } pre, code { font-family: "Courier New", Courier, monospace; font-size: 1em; } code { color: #369; background-color: white; } code *.code-comment { color: black; background-color: white; } a:link code { color: #630; background-color: white; } a:visited code { color: #963; background-color: white; } a:hover code { color: #f60; background-color: white; } a:active code { color: #f60; background-color: white; } caption { text-align: center; font-weight: bold; width: auto; } dt { font-weight: bold; } td { vertical-align: top; } th { font-weight: bold; text-align: left; vertical-align: bottom; color: #369; background-color: white; } table.table-border { border: 1px solid #cc9; } table.table-border td, table.table-border th { padding: 2px 4px 2px 4px; color: black; background-color: white; border: 1px solid #cc9; } table.table-border th.table-header-border-left, table.table-border th.table-header-border-middle, table.table-border th.table-header-border-right { color: #369; background-color: #cc9; } table.table-border th.table-header-border-left { border-left: 1px solid #cc9; border-right: 1px solid white; color: black; background-color: #cc9; } table.table-border th.table-header-border-middle { border-left: 1px solid white; border-right: 1px solid white; color: black; background-color: #cc9; } table.table-border th.table-header-border-right { border-left: 1px solid white; border-right: 1px solid #cc9; color: black; background-color: #cc9; } span.gui-object, span.gui-object-action { font-weight: bold; } span.gui-object-title { } p.horizontal-rule { width: 100%; border: solid #cc9; border-width: 0px 0px 1px 0px; margin-bottom: 4ex; } div.zz-skip-header { margin-bottom: 0px; margin-top: -2px; padding: 0px; text-align: center; line-height: 1px; } div.zz-skip-header a:link, div.zz-skip-header a:visited, div.zz-skip-header a:hover, div.zz-skip-header a:active { color: white; background-color: white; text-decoration: none; font-size: 0.2ex; line-height: 1px; } td.zz-nav-header-cell { text-align: left; font-size: 0.95em; width: 99%; color: black; background-color: white; font-weight: normal; vertical-align: top; margin-top: 0ex; padding-top: 0ex; } a.zz-nav-header-link { font-size: 0.95em; } td.zz-nav-button-cell { white-space: nowrap; text-align: center; width: 1%; vertical-align: top; padding-left: 4px; padding-right: 4px; margin-top: 0ex; padding-top: 0ex; } a.zz-nav-button-link { font-size: 0.9em; } div.zz-nav-footer-menu { width: 100%; text-align: center; margin-top: 2ex; margin-bottom: 4ex; } p.zz-legal-notice, a.zz-legal-notice-link { font-size: 0.85em; /* display: none; */ /* Uncomment to hide legal notice */ } /*************************************/ /* Begin DARB Formats */ /*************************************/ h5, h6 { font-family: Arial, Helvetica, sans-serif; color: #369; background-color: white; font-size: 0.95em; font-weight: bold; } h6 { font-weight: normal; } td li p { display: inline; } /* lose the h1 underscore */ /* h1 { border-width : 0px 0px 0px 0px; } */ /* Increase contrast between visited and unvisited links. */ /* a:visited { color: #a30; background-color: white; } */ .bold, .codeinlinebold, .syntaxinlinebold, .term, .glossterm, .glossaryterm, .keyword, .msg, .msgexplankw, .msgactionkw, .notep1 { font-weight: bold; } .italic, .codeinlineitalic, .syntaxinlineitalic, .variable { font-style: italic; } .bolditalic, .codeinlineboldital, .syntaxinlineboldital, .titleinfigure, .titleinexample, .titleintable, .titleinequation { font-weight: bold; font-style: italic; } .bridgehead, .titleinrefsubsect, .subhead1, .subhead2, .subhead3 { font-family: Arial, Helvetica, sans-serif; color: #369; background-color: white; font-weight: bold; } .titleinrefsubsect, .subhead1 { font-size: 1.1em; } .subhead2 { font-size: 1.0em; } .subhead3 { font-size: 0.95em; display: inline; } .underline { text-decoration: underline; } .superscript { vertical-align: super; } .subscript { vertical-align: sub; } .listofeft { border: none; } .betadraft { color: #f00; background-color: white; } .betadraftsubtitle { text-align: center; font-weight: bold; color: #f00; background-color: white; } .comment { color: #080; background-color: white; font-weight: bold; } .copyrightlogo { text-align: center; font-size: 0.85em; border-style: none; } .tocsubheader { list-style-type: none; } /*************************************/ /* End DARB Formats */ /*************************************/ @media all { * { background-color: transparent; line-height: 1.2; } body { color: black; background-color: white; } /* dd { margin-bottom: 2ex; } dl:first-child { margin-top: 2ex; } */ } @media print { body, p, table, td, th, ol, ul, a, dl, dt, dd, blockquote, caption { font-family: "Times New Roman", Times, serif; font-size: 11pt; } h1, h2, h3, h4, h5, h6, th, thead td { font-family: Arial, Helvetica, serif; color: black; background-color: white; } div.zz-skip-header { display: none; } code, a:link, a:visited, a:hover, a:active { color: black; background-color: white; text-decoration: none; } } PKri$PKlUIOEBPS/sdo_exten.htmd9## 17 SDO_MIGRATE Package (Upgrading)

The SDO_MIGRATE.TO_CURRENT subprogram described in this chapter has both procedure and function interfaces. As a procedure, it lets you upgrade spatial geometry tables from previous releases of Spatial; and as a function, it lets you upgrade a single SDO_GEOMETRY object.

SDO_MIGRATE.TO_CURRENT is the only procedure that you should use for upgrading tables. Do not use the SDO_MIGRATE.TO_81X, SDO_MIGRATE.FROM_815_TO_81X, or SDO_MIGRATE.TO_734 procedures, which were documented in previous Spatial releases but are no longer supported.

## SDO_MIGRATE.TO_CURRENT

Format (Any Object-Relational Model Implementation to Current)

SDO_MIGRATE.TO_CURRENT(

tabname IN VARCHAR2

[, column_name IN VARCHAR2]);

or

SDO_MIGRATE.TO_CURRENT(

tabname IN VARCHAR2,

column_name IN VARCHAR2

[, commit_int IN NUMBER]);

Format (Single Object-Relational Model Geometry to Current)

SDO_MIGRATE.TO_CURRENT(

geom IN SDO_GEOMETRY,

dim IN SDO_DIM_ARRAY

) RETURN SDO_GEOMETRY;

Format (Any Relational Model Implementation to Current)

SDO_MIGRATE.TO_CURRENT(

layer IN VARCHAR2,

newtabname IN VARCHAR2,

gidcolumn IN VARCHAR2,

geocolname IN VARCHAR2,

layer_gtype IN VARCHAR2,

updateflag IN VARCHAR2);

Description

Upgrades data from a previous Spatial release to the current release. As a procedure, TO_CURRENT upgrades an entire layer (all geometries in a column); as a function, TO_CURRENT upgrades a single geometry object, which must be of type SDO_GEOMETRY.

For upgrading a layer, the procedure format depends on whether you are upgrading from the Spatial relational model (release 8.1.5 or earlier) or object-relational model (release 8.1.6 or later). See the Usage Notes for the model that applies to you.

You should use this procedure for any spatial layer upgrade. Do not use the SDO_MIGRATE.TO_81X, SDO_MIGRATE.FROM_815_TO_81X, or SDO_MIGRATE.TO_734 procedures, which were documented in previous Spatial releases but are no longer supported.

Parameters

- tabname
Table with geometry objects.

- column_name
Column in

`tabname`

that contains geometry objects. If`column_name`

is not specified or is specified as null, the column containing geometry objects is upgraded.- commit_int
Number of geometries to upgrade before Spatial performs an internal commit operation. If

`commit_int`

is not specified, no internal commit operations are performed during the upgrade.If you specify a

`commit_int`

value, you can use a smaller rollback segment than would otherwise be needed.- geom
Single geometry object to be upgraded to the current release.

- dim
Dimensional information array for the geometry object to be upgraded. The SDO_DIM_ARRAY type is explained in Section 2.6.3.

- layer
Name of the layer to be upgraded.

- newtabname
Name of the new table to which you are upgrading the data.

- gidcolumn
Name of the column in which to store the GID from the old table.

- geocolname
Name of the column in the new table where the geometry objects will be inserted.

- layer_gtype
One of the following values: POINT or NOTPOINT (default).

If the layer you are upgrading is composed solely of point data, set this parameter to POINT for optimal performance; otherwise, set this parameter to NOTPOINT. If you set the value to POINT and the layer contains any nonpoint geometries, the upgrade might produce invalid data.

- updateflag
One of the following values: UPDATE or INSERT (default).

If you are upgrading the layer into an existing populated attribute table, set this parameter to UPDATE; otherwise, set this parameter to INSERT.

Usage Notes for Object-Relational Model Layer and Single Geometry Upgrade

The specified geometry or all geometry objects in the specified layer are upgraded so that their SDO_GTYPE and SDO_ETYPE values are in the format of the current release:

SDO_GTYPE values of 4 digits are created, using the format (dltt) shown in Table 2-1 in Section 2.2.1.

SDO_ETYPE values are as discussed in Section 2.2.4.

Geometries are ordered so that exterior rings are followed by their interior rings, and coordinates are saved in the correct rotation (counterclockwise for exterior rings, and clockwise for interior rings).

Usage Notes for Relational Model Upgrade

Consider the following when using this procedure:

The new table must be created before you call this procedure.

If the data to be upgraded is geodetic, the tolerance value (SDO_TOLERANCE column value in the <layername>_SDODIM table or view) must be expressed in decimal degrees (for example, 0.00000005).

The procedure converts geometries from the relational model to the object-relational model.

A commit operation is performed by this procedure.

If any of the upgrade steps fails, nothing is upgraded for the layer.

`layer`

is the underlying layer name, without the _SDOGEOM suffix.The old SDO_GID is stored in

`gidcolumn`

.SDO_GTYPE values of 4 digits are created, using the format (dltt) shown in Table 2-1 in Section 2.2.1.

SDO_ETYPE values are created, using the values discussed in Section 2.2.4.

The procedure orders geometries so that exterior rings are followed by their interior rings, and it saves coordinates in the correct rotation (counterclockwise for exterior rings, and clockwise for interior rings).

Examples

The following example changes the definitions of geometry objects in the ROADS table from the release 8.1.5 or later format to the format of the current release.

EXECUTE SDO_MIGRATE.TO_CURRENT('ROADS');Extending Spatial Indexing Capabilities PK8i9d9PKlUIOEBPS/sdo_geocode_concepts.htm## 9 Extending Spatial Indexing Capabilities

This chapter shows how to create and use spatial indexes on objects other than a geometry column. In other chapters, the focus is on indexing and querying spatial data that is stored in a single column of type SDO_GEOMETRY. This chapter shows how to:

Embed an SDO_GEOMETRY object in a user-defined object type, and index the geometry attribute of that type (see Section 9.1)

Create and use a function-based index where the function returns an SDO_GEOMETRY object (see Section 9.2)

The techniques in this chapter are intended for experienced and knowledgeable application developers. You should be familiar with the Spatial concepts and techniques described in other chapters. You should also be familiar with, or able to learn about, relevant Oracle database features, such as user-defined data types and function-based indexing.

## 9.1 SDO_GEOMETRY Objects in User-Defined Type Definitions

The SDO_GEOMETRY type can be embedded in a user-defined data type definition. The procedure is very similar to that for using the SDO_GEOMETRY type for a spatial data column:

Create the user-defined data type.

Create a table with a column based on that data type.

Insert data into the table.

Update the USER_SDO_GEOM_METADATA view.

Create the spatial index on the geometry attribute.

Perform queries on the data.

For example, assume that you want to follow the cola markets scenario in the simplified example in Section 2.1, but want to incorporate the market name attribute and the geometry attribute in a single type. First, create the user-defined data type, as in the following example that creates an object type named MARKET_TYPE:

CREATE OR REPLACE TYPE market_type AS OBJECT (name VARCHAR2(32), shape SDO_GEOMETRY); /Create a table that includes a column based on the user-defined type. The following example creates a table named COLA_MARKETS_2 that will contain the same information as the COLA_MARKETS table used in the example in Section 2.1.

CREATE TABLE cola_markets_2 ( mkt_id NUMBER PRIMARY KEY, market MARKET_TYPE);Insert data into the table, using the object type name as a constructor. For example:

INSERT INTO cola_markets_2 VALUES( 1, MARKET_TYPE('cola_a', SDO_GEOMETRY( 2003, -- two-dimensional polygon NULL, NULL, SDO_ELEM_INFO_ARRAY(1,1003,3), -- one rectangle (1003 = exterior) SDO_ORDINATE_ARRAY(1,1, 5,7) -- only 2 points needed to -- define rectangle (lower left and upper right) ) ) );Update the USER_SDO_GEOM_METADATA view, using dot-notation to specify the column name and spatial attribute. The following example specifies MARKET.SHAPE as the COLUMN_NAME (explained in Section 2.6.2) in the metadata view.

INSERT INTO user_sdo_geom_metadata (TABLE_NAME, COLUMN_NAME, DIMINFO, SRID) VALUES ( 'cola_markets_2', 'market.shape', SDO_DIM_ARRAY( -- 20X20 grid SDO_DIM_ELEMENT('X', 0, 20, 0.005), SDO_DIM_ELEMENT('Y', 0, 20, 0.005) ), NULL -- SRID );Create the spatial index, specifying the column name and spatial attribute using dot-notation. For example.

CREATE INDEX cola_spatial_idx_2 ON cola_markets_2(market.shape) INDEXTYPE IS MDSYS.SPATIAL_INDEX;Perform queries on the data, using dot-notation to refer to attributes of the user-defined type. The following simple query returns information associated with the cola market named

`cola_a`

.SELECT c.mkt_id, c.market.name, c.market.shape FROM cola_markets_2 c WHERE c.market.name = 'cola_a';The following query returns information associated with all geometries that have any spatial interaction with a specified query window, namely, the rectangle with lower-left coordinates (4,6) and upper-right coordinates (8,8).

SELECT c.mkt_id, c.market.name, c.market.shape FROM cola_markets_2 c WHERE SDO_RELATE(c.market.shape, SDO_GEOMETRY(2003, NULL, NULL, SDO_ELEM_INFO_ARRAY(1,1003,3), SDO_ORDINATE_ARRAY(4,6, 8,8)), 'mask=anyinteract' = 'TRUE';## 9.2 SDO_GEOMETRY Objects in Function-Based Indexes

A function-based spatial index facilitates queries that use locational information (of type SDO_GEOMETRY) returned by a function or expression. In this case, the spatial index is created based on the precomputed values returned by the function or expression.

If you are not already familiar with function-based indexes, see the following for detailed explanations of their benefits, options, and requirements, as well as usage examples:

The procedure for using an SDO_GEOMETRY object in a function-based index is as follows:

Create the function that returns an SDO_GEOMETRY object.

The function must be declared as DETERMINISTIC.

If the spatial data table does not already exist, create it, and insert data into the table.

Update the USER_SDO_GEOM_METADATA view.

Create the spatial index.

For a function-based spatial index, the number of parameters must not exceed 32.

Perform queries on the data.

The rest of this section describes two examples of using function-based indexes. In both examples, a function is created that returns an SDO_GEOMETRY object, and a spatial index is created on that function. In the first example, the input parameters to the function are a standard Oracle data type (NUMBER). In the second example, the input to the function is a user-defined object type.

## 9.2.1 Example: Function with Standard Types

In the following example, the input parameters to the function used for the function-based index are standard numeric values (longitude and latitude).

Assume that you want to create a function that returns the longitude and latitude of a point and to use that function in a spatial index. First, create the function, as in the following example that creates a function named GET_LONG_LAT_PT:

-- Create a function to return a point geometry (SDO_GTYPE = 2001) with -- input of 2 numbers: longitude and latitude (SDO_SRID = 8307, for -- "Longitude / Latitude (WGS 84)", probably the most widely used -- coordinate system, and the one used for GPS devices. -- Specify DETERMINISTIC for the function. create or replace function get_long_lat_pt(longitude in number, latitude in number) return SDO_GEOMETRY deterministic is begin return sdo_geometry(2001, 8307, sdo_point_type(longitude, latitude, NULL),NULL, NULL); end; /If the spatial data table does not already exist, create the table and add data to it, as in the following example that creates a table named LONG_LAT_TABLE:

create table LONG_LAT_TABLE (longitude number, latitude number, name varchar2(32)); insert into LONG_LAT_TABLE values (10,10, 'Place1'); insert into LONG_LAT_TABLE values (20,20, 'Place2'); insert into LONG_LAT_TABLE values (30,30, 'Place3');Update the USER_SDO_GEOM_METADATA view, using dot-notation to specify the schema name and function name. The following example specifies SCOTT.GET_LONG_LAT_PT(LONGITUDE,LATITUDE) as the COLUMN_NAME (explained in Section 2.6.2) in the metadata view.

-- Set up the metadata entry for this table. -- The column name sets up the function on top -- of the two columns used in this function, -- along with the owner of the function. insert into user_sdo_geom_metadata values('LONG_LAT_TABLE', 'scott.get_long_lat_pt(longitude,latitude)', sdo_dim_array( sdo_dim_element('Longitude', -180, 180, 0.005), sdo_dim_element('Latitude', -90, 90, 0.005)), 8307);Create the spatial index, specifying the function name with parameters. For example:

create index LONG_LAT_TABLE_IDX on LONG_LAT_TABLE(get_long_lat_pt(longitude,latitude)) indextype is mdsys.spatial_index;Perform queries on the data. In the following example, the two queries accomplish the same thing; however, the first query does not use a user-defined function (instead using a constructor to specify the point), whereas the second query uses the function to specify the point.

-- First query: call sdo_filter with an SDO_GEOMETRY constructor select name from LONG_LAT_TABLE a where sdo_filter(get_long_lat_pt(a.longitude,a.latitude), sdo_geometry(2001, 8307, sdo_point_type(10,10,NULL), NULL, NULL) )='TRUE'; -- Second query: call sdo_filter with the function that returns an sdo_geometry select name from LONG_LAT_TABLE a where sdo_filter(get_long_lat_pt(a.longitude,a.latitude), get_long_lat_pt(10,10) )='TRUE';## 9.2.2 Example: Function with a User-Defined Object Type

In the following example, the input parameter to the function used for the function-based index is an object of a user-defined type that includes the longitude and latitude.

Assume that you want to create a function that returns the longitude and latitude of a point and to create a spatial index on that function. First, create the user-defined data type, as in the following example that creates an object type named LONG_LAT and its member function GetGeometry:

create type long_lat as object ( longitude number, latitude number, member function GetGeometry(SELF in long_lat) RETURN SDO_GEOMETRY DETERMINISTIC) / create or replace type body long_lat as member function GetGeometry(self in long_lat) return SDO_GEOMETRY is begin return sdo_geometry(2001, 8307, sdo_point_type(longitude, latitude, NULL), NULL,NULL); end; end; /If the spatial data table does not already exist, create the table and add data to it, as in the following example that creates a table named TEST_LONG_LAT:

create table test_long_lat (location long_lat, name varchar2(32)); insert into test_long_lat values (long_lat(10,10), 'Place1'); insert into test_long_lat values (long_lat(20,20), 'Place2'); insert into test_long_lat values (long_lat(30,30), 'Place3');Update the USER_SDO_GEOM_METADATA view, using dot-notation to specify the schema name, table name, and function name and parameter value. The following example specifies SCOTT.LONG_LAT.GetGeometry(LOCATION) as the COLUMN_NAME (explained in Section 2.6.2) in the metadata view.

insert into user_sdo_geom_metadata values('test_long_lat', 'scott.long_lat.GetGeometry(location)', sdo_dim_array( sdo_dim_element('Longitude', -180, 180, 0.005), sdo_dim_element('Latitude', -90, 90, 0.005)), 8307);Create the spatial index, specifying the column name and function name using dot-notation. For example:

create index test_long_lat_idx on test_long_lat(location.GetGeometry()) indextype is mdsys.spatial_index;Perform queries on the data. The following query performs a primary filter operation, asking for the names of geometries that are likely to interact spatially with point (10,10).

SELECT a.name FROM test_long_lat a WHERE SDO_FILTER(a.location.GetGeometry(), SDO_GEOMETRY(2001, 8307, SDO_POINT_TYPE(10,10,NULL), NULL, NULL) ) = 'TRUE';Geocoding Address Data PK`i[GPKlUIOEBPS/rt_mbr.gif>GIF89a6???333fff̙%%%222```"""sss;;;{{{!!!)))...nnn]]]TTTbbbꌌKKK***777CCC&&&wwwYYY666eee\\\:::iii鐐jjjaaavvvXXXPPPDDDȩHHH,6 ÛΩ## 5 Geocoding Address Data

Geocoding is the process of associating spatial locations (longitude and latitude coordinates) with postal addresses. This chapter includes the following major sections:

## 5.1 Concepts for Geocoding

This section describes concepts that you must understand before you use the Spatial geocoding capabilities.

## 5.1.1 Address Representation

Addresses to be geocoded can be represented either as formatted addresses or unformatted addresses.

A formatted address is described by a set of attributes for various parts of the address, which can include some or all of those shown in Table 5-1.

Table 5-1 Attributes for Formal Address Representation

Address Attribute Description Name

Place name (optional).

Intersecting street

Intersecting street name (optional).

Street

Street address, including the house or building number, street name, street type (Street, Road, Blvd, and so on), and possibly other information.

In the current release, the first four characters of the street name must match a street name in the geocoding data for there to be a potential street name match.

Settlement

The lowest-level administrative area to which the address belongs. In most cases it is the city. In some European countries, the settlement can be an area within a large city, in which case the large city is the municipality.

Municipality

The administrative area above settlement. Municipality is not used for United States addresses. In European countries where cities contain settlements, the municipality is the city.

Region

The administrative area above municipality (if applicable), or above settlement if municipality does not apply. In the United States, the region is the state; in some other countries, the region is the province.

Postal code

Postal code (optional if administrative area information is provided). In the United States, the postal code is the 5-digit ZIP code.

Postal add-on code

String appended to the postal code. In the United States, the postal add-on code is typically the last four numbers of a 9-digit ZIP code specified in "5-4" format.

Country

The country name or ISO country code.

Formatted addresses are specified using the SDO_GEO_ADDR data type, which is described in Section 5.2.1.

An unformatted address is described using lines with information in the postal address format for the relevant country. The address lines must contain information essential for geocoding, and they might also contain information that is not needed for geocoding (something that is common in unprocessed postal addresses). An unformatted address is stored as an array of strings. For example, an address might consist of the following strings: '22 Monument Square' and 'Concord, MA 01742'.

Unformatted addresses are specified using the SDO_KEYWORDARRAY data type, which is described in Section 5.2.3.

## 5.1.2 Match Modes

The match mode for a geocoding operation determines how closely the attributes of an input address must match the data being used for the geocoding. Input addresses can include different ways of representing the same thing (such as Street and the abbreviation St), and they can include minor errors (such as the wrong postal code, even though the street address and city are correct and the street address is unique within the city).

You can require an exact match between the input address and the data used for geocoding, or you can relax the requirements for some attributes so that geocoding can be performed despite certain discrepancies or errors in the input addresses. Table 5-2 lists the match modes and their meanings. Use a value from this table with the

`MatchMode`

attribute of the SDO_GEO_ADDR data type (described in Section 5.2.1) and for the`match_mode`

parameter of a geocoding function or procedure.Table 5-2 Match Modes for Geocoding Operations

Match Mode Description EXACT

All attributes of the input address must match the data used for geocoding. However, if the house or building number, base name (street name), street type, street prefix, and street suffix do not all match the geocoding data, a location in the first match found in the following is returned: postal code, city or town (settlement) within the state, and state. For example, if the street name is incorrect but a valid postal code is specified, a location in the postal code is returned.

RELAX_STREET_TYPE

The street type can be different from the data used for geocoding. For example, if Main St is in the data used for geocoding, Main Street would also match that, as would Main Blvd if there was no Main Blvd and no other street type named Main in the relevant area.

RELAX_POI_NAME

The name of the point of interest does not have to match the data used for geocoding. For example, if Jones State Park is in the data used for geocoding, Jones State Pk and Jones Park would also match as long as there were no ambiguities or other matches in the data.

RELAX_HOUSE_NUMBER

The house or building number and street type can be different from the data used for geocoding. For example, if 123 Main St is in the data used for geocoding, 123 Main Lane and 124 Main St would also match as long as there were no ambiguities or other matches in the data.

RELAX_BASE_NAME

The base name of the street, the house or building number, and the street type can be different from the data used for geocoding. For example, if Pleasant Valley is the base name of a street in the data used for geocoding, Pleasant Vale would also match as long as there were no ambiguities or other matches in the data.

RELAX_POSTAL_CODE

The postal code (if provided), base name, house or building number, and street type can be different from the data used for geocoding.

RELAX_BUILTUP_AREA

The address can be outside the city specified as long as it is within the same county. Also includes the characteristics of RELAX_POSTAL_CODE.

RELAX_ALL

Equivalent to RELAX_BUILTUP_AREA.

DEFAULT

Equivalent to RELAX_BASE_NAME.

## 5.1.3 Match Codes

The match code is a number indicating which input address attributes matched the data used for geocoding. The match code is stored in the

`MatchCode`

attribute of the output SDO_GEO_ADDR object (described in Section 5.2.1).Table 5-3 lists the possible match code values.

Table 5-3 Match Codes for Geocoding Operations

Match Code Description 1

Exact match: the city name, postal code, street base name, street type (and suffix or prefix or both, if applicable), and house or building number match the data used for geocoding.

2

The city name, postal code, street base name, and house or building number match the data used for geocoding, but the street type, suffix, or prefix does not match.

3

The city name, postal code, and street base name match the data used for geocoding, but the house or building number does not match.

4

The city name and postal code match the data used for geocoding, but the street address does not match.

10

The city name matches the data used for geocoding, but the postal code does not match.

11

The postal code matches the data used for geocoding, but the city name does not match.

## 5.1.4 Error Messages for Output Geocoded Addresses

For an output geocoded address, the

`ErrorMessage`

attribute of the SDO_GEO_ADDR object (described in Section 5.2.1) contains a string that indicates which address attributes have been matched against the data used for geocoding. Before the geocoding operation begins, the string is set to the value`???????????281C??`

; and the value is modified to reflect which attributes have been matched.Table 5-4 lists the character positions in the string and the address attribute corresponding to each position. It also lists the character value that the position is set to if the attribute is matched.

Table 5-4 Geocoded Address Error Message Interpretation

Position Attribute Value If Matched 1-4

(Reserved for future use)

????

5

House or building number

#

6

Street prefix

E

7

Street base name

N

8

Street suffix

U

9

Street type

T

10

Secondary unit

S

11

Built-up area or city

B

14

Region

1

15

Country

C

16

Postal code

P

17

Postal add-on code

A

## 5.2 Data Types for Geocoding

This section describes the data types specific to geocoding functions and procedures.

## 5.2.1 SDO_GEO_ADDR Type

The SDO_GEO_ADDR object type is used to describe an address. When a geocoded address is output by an SDO_GCDR function or procedure, it is stored as an object of type SDO_GEO_ADDR.

Table 5-5 lists the attributes of the SDO_GEO_ADDR type. Not all attributes will be relevant in any given case. The attributes used for a returned geocoded address depend on the geographical context of the input address, especially the country.

Table 5-5 SDO_GEO_ADDR Type Attributes

Attribute Data Type Description Id

NUMBER

(Not used.)

AddressLines

SDO_KEYWORDARRAY

Address lines. (The SDO_KEYWORDARRAY type is described in Section 5.2.3.)

PlaceName

VARCHAR2(200)

Point of interest (POI) name. Example: CALIFORNIA PACIFIC MEDICAL CTR

StreetName

VARCHAR2(200)

Street name, including street type. Example: MAIN ST

IntersectStreet

VARCHAR2(200)

Intersecting street.

SecUnit

VARCHAR2(200)

Secondary unit, such as an apartment number or building number.

Settlement

VARCHAR2(200)

Lowest-level administrative area to which the address belongs. (See Table 5-1.)

Municipality

VARCHAR2(200)

Administrative area above settlement. (See Table 5-1.)

Region

VARCHAR2(200)

Administrative area above municipality (if applicable), or above settlement if municipality does not apply. (See Table 5-1.)

Country

VARCHAR2(100)

Country name or ISO country code.

PostalCode

VARCHAR2(20)

Postal code (optional if administrative area information is provided). In the United States, the postal code is the 5-digit ZIP code.

PostalAddOnCode

VARCHAR2(20)

String appended to the postal code. In the United States, the postal add-on code is typically the last four numbers of a 9-digit ZIP code specified in "5-4" format.

FullPostalCode

VARCHAR2(20)

Full postal code, including the postal code and postal add-on code.

POBox

VARCHAR2(100)

Post Office box number.

HouseNumber

VARCHAR2(100)

House or building number. Example: 123 in 123 MAIN ST

BaseName

VARCHAR2(200)

Base name of the street. Example: MAIN in 123 MAIN ST

StreetType

VARCHAR2(20)

Type of the street. Example: ST in 123 MAIN ST

StreetTypeBefore

VARCHAR2(1)

(Not used.)

StreetTypeAttached

VARCHAR2(1)

(Not used.)

StreetPrefix

VARCHAR2(20)

Prefix for the street. Example: S in 123 S MAIN ST

StreetSuffix

VARCHAR2(20)

Suffix for the street. Example: NE in 123 MAIN ST NE

Side

VARCHAR2(1)

Side of the street (

`L`

for left or`R`

for right) that the house is on when you are traveling along the road segment following its orientation (that is, from its start node toward its end node). The house numbers may be increasing or decreasing.Percent

NUMBER

Number from 0 to 1 (multiply by 100 to get a percentage value) indicating how far along the street you are when traveling following the road segment orientation.

EdgeID

NUMBER

Edge ID of the road segment.

ErrorMessage

VARCHAR2(20)

Error message (see Section 5.1.4).

MatchCode

NUMBER

Match code (see Section 5.1.3).

MatchMode

VARCHAR2(30)

Match mode (see Section 5.1.2).

Longitude

NUMBER

Longitude coordinate value.

Latitude

NUMBER

Latitude coordinate value.

You can return the entire SDO_GEO_ADDR object, or you can specify an attribute using standard "dot" notation. Example 5-1 contains statements that geocode the address of the San Francisco City Hall; the first statement returns the entire SDO_GEO_ADDR object, and the remaining statements return some specific attributes.

Example 5-1 Geocoding, Returning Address Object and Specific Attributes

SELECT SDO_GCDR.GEOCODE('SCOTT', SDO_KEYWORDARRAY('1 Carlton B Goodlett Pl', 'San Francisco, CA 94102'), 'US', 'RELAX_BASE_NAME') FROM DUAL; SDO_GCDR.GEOCODE('CJMURRAY',SDO_KEYWORDARRAY('1CARLTONBGOODLETTPL','SANFRANCISCO -------------------------------------------------------------------------------- SDO_GEO_ADDR(0, SDO_KEYWORDARRAY(), NULL, 'CARLTON B GOODLETT PL', NULL, NULL, ' SAN FRANCISCO', NULL, 'CA', 'US', '94102', NULL, '94102', NULL, '1', 'CARLTON B GOODLETT', 'PL', 'F', 'F', NULL, NULL, 'L', .01, 23614360, 'nul?#ENUT?B281CP?', 1, 'DEFAULT', -122.41815, 37.7784183) SELECT SDO_GCDR.GEOCODE('SCOTT', SDO_KEYWORDARRAY('1 Carlton B Goodlett Pl', 'San Francisco, CA 94102'), 'US', 'RELAX_BASE_NAME').StreetType FROM DUAL; SDO_GCDR.GEOCODE('SCOTT',SDO_KEYWORDARRAY('1CARLTONBGOODLETTPL','SANFRANCISCO -------------------------------------------------------------------------------- PL SELECT SDO_GCDR.GEOCODE('SCOTT', SDO_KEYWORDARRAY('1 Carlton B Goodlett Pl', 'San Francisco, CA 94102'), 'US', 'RELAX_BASE_NAME').Side RROM DUAL; S - L SELECT SDO_GCDR.GEOCODE('SCOTT', SDO_KEYWORDARRAY('1 Carlton B Goodlett Pl', 'San Francisco, CA 94102'), 'US', 'RELAX_BASE_NAME').Percent FROM DUAL; SDO_GCDR.GEOCODE('SCOTT',SDO_KEYWORDARRAY('1CARLTONBGOODLETTPL','SANFRANCISCO -------------------------------------------------------------------------------- .01 SELECT SDO_GCDR.GEOCODE('SCOTT', SDO_KEYWORDARRAY('1 Carlton B Goodlett Pl', 'San Francisco, CA 94102'), 'US', 'RELAX_BASE_NAME').EdgeID FROM DUAL; SDO_GCDR.GEOCODE('SCOTT',SDO_KEYWORDARRAY('1CARLTONBGOODLETTPL','SANFRANCISCO -------------------------------------------------------------------------------- 23614360 SELECT SDO_GCDR.GEOCODE('SCOTT', SDO_KEYWORDARRAY('1 Carlton B Goodlett Pl', 'San Francisco, CA 94102'), 'US', 'RELAX_BASE_NAME').MatchCode FROM DUAL; SDO_GCDR.GEOCODE('SCOTT',SDO_KEYWORDARRAY('1CARLTONBGOODLETTPL','SANFRANCISCO -------------------------------------------------------------------------------- 1## 5.2.2 SDO_ADDR_ARRAY Type

The SDO_ADDR_ARRAY type is a VARRAY of SDO_GEO_ADDR objects (described in Section 5.2.1) used to store geocoded address results. Multiple address objects can be returned when multiple addresses are matched as a result of a geocoding operation.

The SDO_ADDR_ARRAY type is defined as follows:

CREATE TYPE sdo_addr_array AS VARRAY(1000) OF sdo_geo_addr;## 5.2.3 SDO_KEYWORDARRAY Type

The SDO_KEYWORDARRAY type is a VARRAY of VARCHAR2 strings used to store address lines for unformatted addresses. (Formatted and unformatted addresses are described in Section 5.1.1.)

The SDO_KEYWORDARRAY type is defined as follows:

CREATE TYPE sdo_keywordarray AS VARRAY(10000) OF VARCHAR2(9000);## 5.3 Using the Geocoding Capabilities

To use the Oracle Spatial geocoding capabilities, you must use data provided by a geocoding vendor, and the data must be in the format supported by the Oracle Spatial geocoding feature. For information about getting and loading this data, go to the Spatial page of the Oracle Technology Network (OTN):

`http://www.oracle.com/technology/products/spatial/`

Find the link for geocoding, and follow the instructions.

To geocode an address using the geocoding data, use the SDO_GCDR PL/SQL package subprograms, which are documented in Chapter 14:

The SDO_GCDR.GEOCODE function geocodes an unformatted address to return an SDO_GEO_ADDR object.

The SDO_GCDR.GEOCODE_ADDR function geocodes an input address using attributes in an SDO_GEO_ADDR object, and returns the first matched address as an SDO_GEO_ADDR object.

The SDO_GCDR.GEOCODE_ADDR_ALL function geocodes an input address using attributes in an SDO_GEO_ADDR object, and returns matching addresses as an SDO_ADDR_ARRAY object.

The SDO_GCDR.GEOCODE_AS_GEOMETRY function geocodes an unformatted address to return an SDO_GEOMETRY object.

The SDO_GCDR.GEOCODE_ALL function geocodes all addresses associated with an unformatted address and returns the result as an SDO_ADDR_ARRAY object (an array of address objects).

The SDO_GCDR.REVERSE_GEOCODE function reverse geocodes a location, specified by its spatial geometry object and country, and returns the result as an SDO_GEO_ADDR object.

## 5.4 Geocoding from a Place Name

If you know a place name (point of interest) but not its locality details, you can create a PL/SQL function to construct an SDO_GEO_ADDR object from

`placename`

and`country`

input parameters, as shown in Example 5-2, which creates a function named`create_addr_from_placename`

. The SELECT statement in this example uses the SDO_GCDR.GEOCODE_ADDR function to geocode the address constructed using the`create_addr_from_placename`

function.Example 5-2 Geocoding from a Place Name and Country

create or replace function create_addr_from_placename( placename varchar2, country varchar2) return sdo_geo_addr as addr sdo_geo_addr ; begin addr := sdo_geo_addr() ; addr.country := country ; addr.placename := placename ; addr.matchmode := 'default' ; return addr ; end; / SELECT sdo_gcdr.geocode_addr('SCOTT', create_addr_from_placename('CALIFORNIA PACIFIC MEDICAL CTR', 'US')) FROM DUAL;If you know at least some of the locality information, such as settlement, region, and postal code, you can get better performance if you can provide such information. Example 5-3 provides an alternate version of the

`create_addr_from_placename`

function that accepts additional parameters. To call this version of the function, specify actual values for the placename and country parameters, and specify an actual value or a null value for each of the other input parameters.Example 5-3 Geocoding from a Place Name, Country, and Other Fields

create or replace function create_addr_from_placename( placename varchar2, city varchar2, state varchar2, postalcode varchar2, country varchar2) return sdo_geo_addr as addr sdo_geo_addr ; begin addr := sdo_geo_addr() ; addr.settlement := city ; addr.region := state ; addr.postalcode := postalcode ; addr.country := country ; addr.placename := placename ; addr.matchmode := 'default' ; return addr ; end; / SELECT sdo_gcdr.geocode_addr('SCOTT', create_addr_from_placename('CALIFORNIA PACIFIC MEDICAL CTR', 'san francisco', 'ca', null, 'US')) FROM DUAL;## 5.5 Data Structures for Geocoding

Oracle uses the following tables for geocoding:

GC_PARSER_PROFILES

GC_PARSER_PROFILEAFS

GC_COUNTRY_PROFILE

GC_AREA_<suffix>

GC_POSTAL_CODE_<suffix>

GC_ROAD_SEGMENT_<suffix>

GC_ROAD_<suffix>

GC_POI_<suffix>

GC_INTERSECTION_<suffix>

The GC_PARSER_PROFILES and GC_PARSER_PROFILEAFS tables store address format definitions of all supported counties. These tables are used by the internal address parser in parsing postal addresses into addressing fields. The data for these two tables is provided by Oracle. The remaining tables store geocoding data provided by data vendors.

Each user that owns the tables containing geocoding data (that is, each user that can be specified with the

`username`

parameter in a call to an SDO_GCDR subprogram) must have one GC_PARSER_PROFILES table, one GC_PARSER_PROFILEAFS table, and one GC_COUNTRY_PROFILE table. Each such user can have multiple sets of the other tables (GC_xxx_<suffix>). Each set of tables whose names end with the same suffix stores geocoding data of a country. For example, the following set of tables can be used to store geocoding data of the United States:

GC_AREA_US

GC_POSTAL_CODE_US

GC_ROAD_SEGMENT_US

GC_ROAD_US

GC_POI_US

GC_INTERSECTION_US

Geocoding data of one country cannot be stored in more than one set of those tables. The table suffix is defined by data venders and is specified in the GC_TABLE_SUFFIX column in the GC_COUNTRY_PROFILE table (described in Section 5.5.2).

The following sections describe the vendor-supplied tables that store geocoding data, in alphabetical order by table name.

## 5.5.1 GC_AREA_<suffix> Table

The GC_AREA_<suffix> table (for example, CG_AREA_US) stores administration area information for the country associated with the table name suffix. This table contains one row for each administration area, and it contains the columns shown in Table 5-6.

Table 5-6 GC_AREA_<suffix> Table

Column Name Data Type Description AREA_ID

NUMBER(10)

Area ID number. (Required)

AREA_NAME

VARCHAR2(64)

Area name. (Required)

LANG_CODE

VARCHAR2(3)

3-letter ISO national language code for the language associated with the area. (Required)

ADMIN_LEVEL

NUMBER(1)

Administration hierarchy level for the area. (Required)

LEVEL1_AREA_ID

NUMBER(10)

ID of the level-1 area to which the area belongs. In the administration hierarchy, the level-1 area is the country. (Required)

LEVEL2_AREA_ID

NUMBER(10)

ID of the level-2 area to which the area belongs, if applicable. You must specify an area ID for each level in the administration hierarchy to which this area belongs. (Optional)

LEVEL3_AREA_ID

NUMBER(10)

ID of the level-3 area to which the area belongs, if applicable. You must specify an area ID for each level in the administration hierarchy to which this area belongs. (Optional)

LEVEL4_AREA_ID

NUMBER(10)

ID of the level-4 area to which the area belongs, if applicable. You must specify an area ID for each level in the administration hierarchy to which this area belongs. (Optional)

LEVEL5_AREA_ID

NUMBER(10)

ID of the level-5 area to which the area belongs, if applicable. You must specify an area ID for each level in the administration hierarchy to which this area belongs. (Optional)

LEVEL6_AREA_ID

NUMBER(10)

ID of the level-6 area to which the area belongs, if applicable. You must specify an area ID for each level in the administration hierarchy to which this area belongs. (Optional)

LEVEL7_AREA_ID

NUMBER(10)

ID of the level-7 area to which the area belongs, if applicable. You must specify an area ID for each level in the administration hierarchy to which this area belongs. (Optional)

CENTER_LONG

NUMBER

Longitude value of the center of the area. The center is set to the closest road segment to the center longitude and latitude values. Oracle recommends that these two attributes be set properly. If these values are not set, the longitude and latitude coordinates of the geocoded result of an area will be (0,0). (Optional)

CENTER_LAT

NUMBER

Latitude value of the center of the area. (See the explanation for the CENTER_LONG column.) (Optional)

ROAD_SEGMENT_ID

NUMBER(10)

ID of the road segment to which the area center is set. This value must be set correctly if the geocoder is intended to work with the Oracle Spatial routing engine (described in Appendix C); otherwise, it can be set to any nonzero value, but it cannot be null. (Required)

POSTAL_CODE

VARCHAR2(16)

Postal code for the center of the area. Oracle recommends that this attribute be set correctly. If this value is null, the postal code attribute of the geocoded result of an area will be null. (Optional)

COUNTRY_CODE_2

VARCHAR2(2)

2- letter ISO country code of the country to which the area belongs. (Required)

PARTITION_ID

NUMBER

Partition key used for partitioning geocoder data by geographic boundaries. If the data is not partitioned, set the value to 1. (Required)

REAL_NAME

VARCHAR2(64)

The real name of the area, as spelled using the local language. This column is useful for area names that are not in English. For example, the German name of city

`MUNICH`

is`MÜNCHEN`

. It is allowed to be spelled as`MUNCHEN`

, but its REAL_NAME value should be`MÜNCHEN`

. In the area table for Germany, areas with name`MÜNCHEN`

and`MUNCHEN`

both refer to the same area, and they both have the same real name`MÜNCHEN`

. If the area name does not have any non-English characters, set REAL_NAME to be the same as AREA_NAME. (Required)IS_ALIAS

VARCHAR2(1)

Contains

`T`

if this area is an alias of another area that is an officially recognized administrative area; contains`F`

if this area is not an alias of another area that is an officially recognized administrative area. For example, Manhattan is not an officially recognized administrative area, but it is used by the public to refer to a part of New York City. In this case,`Manhattan`

is an alias of`New York City`

. (Required)NUM_STREETS

NUMBER

The number of streets inside this area. (Optional)

## 5.5.2 GC_COUNTRY_PROFILE Table

The GC_COUNTRY_PROFILE table stores country profile information used by the geocoder. This table contains one row for each supported country, and it contains the columns shown in Table 5-7.

Table 5-7 GC_COUNTRY_PROFILE Table

Column Name Data Type Description COUNTRY_NAME

VARCHAR2(60)

Country name. (Required)

COUNTRY_CODE_3

VARCHAR2(3)

3- letter ISO country code. (Required)

COUNTRY_CODE_2

VARCHAR2(2)

2- letter ISO country code. (Required)

LANG_CODE_1

VARCHAR2(3)

3-letter ISO national language code. Some country might have multiple national languages, in which case LANG_CODE_2 and perhaps other columns should contain values. (Required)

LANG_CODE_2

VARCHAR2(3)

3-letter ISO national language code. (Optional)

LANG_CODE_3

VARCHAR2(3)

3-letter ISO national language code. (Optional)

LANG_CODE_4

VARCHAR2(3)

3-letter ISO national language code. (Optional)

NUMBER_ADMIN_LEVELS

NUMBER(1)

Number of administration hierarchy levels. A country can have up to 7 administration area levels, numbered from 1 to 7. The top level area (country) is level 1. For the United States, the administration hierarchy is as follows: level 1 = country, level 2 = state, level 3 = county, level 4 = city. (Required)

SETTLEMENT_LEVEL

NUMBER(1)

Administration hierarchy level for a settlement, which is the lowest area level used in addressing. In the United States, this is the city level. (Required)

MUNICIPALITY_LEVEL

NUMBER(1)

Administration hierarchy level for a municipality, which is the second-lowest area level used in addressing. In the United States, this is the county level. (Optional)

REGION_LEVEL

NUMBER(1)

Administration hierarchy level for the region level used in addressing. (Optional)

SETTLEMENT_IS_OPTIONAL

VARCHAR2(1)

Contains

`T`

if settlement information is required in the address data; contains`F`

if settlement information is not required in the address data. (Required)MUNICIPALITY_IS_OPTIONAL

VARCHAR2(1)

Contains

`T`

if municipality information is required in the address data; contains`F`

if municipality information is not required in the address data. (Required)REGION_IS_OPTIONAL

VARCHAR2(1)

Contains

`T`

if region information is required in the address data; contains`F`

if region information is not required in the address data. (Required)POSTCODE_IN_SETTLEMENT

VARCHAR(1)

Contains

`T`

if each postal code must be completely within a settlement area; contains`F`

if a postal code can include area from multiple settlements. (Required)SETTLEMENT_AS_CITY

VARCHAR(1)

Contains

`T`

if a city name can identify both a municipality and a settlement; contains`F`

if a city name can identify only a settlement. For example, in the United Kingdom, London can be both the name of a municipality area and the name of a settlement area, which is inside the municipality of London. This is common in large cities in some European countries, such as the UK and Belgium. (Required)CACHED_ADMIN_AREA_LEVEL

NUMBER

(Reserved for future use.)

GC_TABLE_SUFFIX

VARCHAR2(5)

Table name suffix identifying the country. For example, if the value of GC_TABLE_SUFFIX is

`US`

, the names of tables with geocoding data for this country end with`_US`

(for example, CG_AREA_US). (Required)CENTER_LONG

NUMBER

Longitude value of the center of the area. (Optional)

CENTER_LAT

NUMBER

Latitude value of the center of the area. (Optional)

SEPARATE_PREFIX

VARCHAR2(1)

Contains

`T`

if the street name prefix is a separate word from the street name; contains`F`

if the street name prefix is in the same word with the street name. For example, in an American street address of`123 N Main St`

, the prefix is`N`

, and it is separate from the street name, which is`Main`

. (Optional; not currently used by Oracle)SEPARATE_SUFFIX

VARCHAR2(1)

Contains

`T`

if the street name suffix is a separate word from the street name; contains`F`

if the street name suffix is in the same word with the street name. For example, in an American street address of`123 Main St NW`

, the suffix is`NW`

, and it is separate from the street name, which is`Main`

, and from the street type, which is`St`

. (Optional; not currently used by Oracle)SEPARATE_STYPE

VARCHAR2(1)

Contains

`T`

if the street type is a separate word from the street name; contains`F`

if the street type is in the same word with the street name. For example, in a German street address of`123 Beethovenstrass`

, the type is`strass`

, and it is in the same word with the street name, which is`Beethoven`

. (Optional; not currently used by Oracle)AREA_ID

NUMBER

Not currently used by Oracle. (Optional)

VERSION

VARCHAR2(10)

Version of the data. The first version should be

`1.0`

. (Required)## 5.5.3 GC_INTERSECTION_<suffix> Table

The GC_INTERSECTION_<suffix> table (for example, GC_INTERSECTION_US) stores road intersection information. An intersection is typically associated with multiple roads. Each row represents an intersection and two different roads that intersect with each other at this intersection. This table contains the columns shown in Table 5-8.

Table 5-8 GC_INTERSECTION_<suffix> Table

Column Name Data Type Description ROAD_ID_1

NUMBER

ID number of the first road on which the intersection is located. (Required)

ROAD_SEGMENT_ID_1

NUMBER

ID number of the road segment on the first road on which the intersection is located. (Required)

ROAD_ID_2

NUMBER

ID number of the second road on which the intersection is located. (Required)

ROAD_SEGMENT_ID_2

NUMBER

ID number of the road segment on the second road on which the intersection is located. (Required)

INTS_LONG

NUMBER

Longitude coordinate value of the intersection. (Required)

INTS_LAT

NUMBER

Latitude coordinate value of the intersection. (Required)

HOUSE_NUMBER

NUMBER

The leading numerical part of the house number at the intersection. (See the explanation of house numbers after Table 5-12 in Section 5.5.7.) (Required)

HOUSE_NUMBER_2

VARCHAR2(10)

The second part of the house number at the intersection. (See the explanation of house numbers after Table 5-12 in Section 5.5.7.) (Required)

SIDE

VARCHAR2(1)

Side of the street on which the house at the intersection is located. Possible values:

`L`

(left) or`R`

(right). (Required)COUNTRY_CODE_2

VARCHAR2(2)

2- letter ISO country code of the country to which the house at the intersection belongs. (Required)

PARTITION_ID

NUMBER

Partition key used for partitioning geocoder data by geographic boundaries. If the data is not partitioned, set the value to 1. (Required)

## 5.5.4 GC_POI_<suffix> Table

The GC_POI_<suffix> table (for example, GC_POI_US) stores point of interest (POI) information for the country associated with the table name suffix. This table contains one or more rows for each point of interest. (For example, it can contain multiple rows for a POI if the POI is associated with multiple settlements.) The GC_POI_<suffix> table contains the columns shown in Table 5-9.

Table 5-9 GC_POI_<suffix> Table

Column Name Data Type Description POI_ID

NUMBER

ID number of the POI. (Required)

POI_NAME

VARCHAR2(64)

Name of the POI. (Required)

LANG_CODE

VARCHAR2(3)

3-letter ISO national language code for the language for the POI name. (Required)

FEATURE_CODE

NUMBER

Feature code for the POI, if the data vendor classifies POIs by category. (Optional)

HOUSE_NUMBER

VARCHAR2(10)

House number of the POI; may contain non-numeric characters. (Required)

STREET_NAME

VARCHAR2(80)

Street name of the POI. (Required)

SETTLEMENT_ID

NUMBER(10)

ID number of the settlement to which the POI belongs. (Required if the POI is associated with a settlement)

MUNICIPALITY_ID

NUMBER(10)

ID number of the municipality to which the POI belongs. (Required if the POI is associated with a municipality)

REGION_ID

NUMBER(10)

ID number of the region to which the POI belongs. (Required if the POI is associated with a region)

SETTLEMENT_NAME

VARCHAR2(64)

Name of the settlement to which the POI belongs. (Required if the POI is associated with a settlement)

MUNICIPALITY_NAME

VARCHAR2(64)

Name of the municipality to which the POI belongs. (Required if the POI is associated with a municipality)

REGION_NAME

VARCHAR2(64)

Name of the region to which the postal code belongs. (Required if the POI is associated with a region)

POSTAL_CODE

VARCHAR2(16)

Name of the postal code of the POI. (Required)

VANITY_CITY

VARCHAR2(35)

Name of the city popularly associated with the POI, if it is different from the actual city containing the POI. For example, the London Heathrow Airport is actually located in a town named Hayes, which is part of greater London, but people tend to associate the airport only with London. In this case, the VANITY_CITY value is

`London`

. (Optional)ROAD_SEGMENT_ID

NUMBER

ID of the road segment on which the POI is located. (Required)

SIDE

VARCHAR2(1)

Side of the street on which the POI is located. Possible values:

`L`

(left) or`R`

(right). (Required)PERCENT

NUMBER

Percentage value at which POI is located on the road. It is computed by dividing the distance from the street segment start point to the POI by the length of the street segment. (Required)

TELEPONE_NUMBER

VARCHAR2(20)

Telephone number of the POI. (Optional)

LOC_LONG

NUMBER

Longitude coordinate value of the POI. (Required)

LOC_LAT

NUMBER

Latitude coordinate value of the POI. (Required)

COUNTRY_CODE_2

VARCHAR2(2)

2- letter ISO country code of the country to which the POI belongs. (Required)

PARTITION_ID

NUMBER

Partition key used for partitioning geocoder data by geographic boundaries. If the data is not partitioned, set the value to 1. (Required)

## 5.5.5 GC_POSTAL_CODE_<suffix> Table

The GC_POSTAL_CODE_<suffix> table (for example, GC_POSTAL_CODE_US) stores postal code information for the country associated with the table name suffix. This table contains one or more rows for each postal code. (For example, it can contain multiple rows for a postal code if the postal code is associated with multiple settlements.) The GC_POSTAL_CODE_<suffix> table contains the columns shown in Table 5-10.

Table 5-10 GC_POSTAL_CODE_<suffix> Table

Column Name Data Type Description POSTAL_CODE

VARCHAR2(16)

Postal code. (Required)

SETTLEMENT_NAME

VARCHAR2(64)

Name of the settlement to which the postal code belongs. (Required if the postal code is associated with a settlement)

MUNICIPALITY_NAME

VARCHAR2(64)

Name of the municipality to which the postal code belongs. (Required if the postal code is associated with a municipality)

REGION_NAME

VARCHAR2(64)

Name of the region to which the postal code belongs. (Required if the postal code is associated with a region)

LANG_CODE

VARCHAR2(3)

3-letter ISO national language code for the language associated with the area. (Required)

SETTLEMENT_ID

NUMBER(10)

ID number of the settlement to which the postal code belongs. (Required if the postal code is associated with a settlement)

MUNICIPALITY_ID

NUMBER(10)

ID number of the municipality to which the postal code belongs. (Required if the postal code is associated with a municipality)

REGION_ID

NUMBER(10)

ID number of the region to which the postal code belongs. (Required if the postal code is associated with a region)

CENTER_LONG

NUMBER

Longitude value of the center of the area. The center is set to the closest road segment to the center longitude and latitude values. Oracle recommends that these two attributes be set properly. If these values are not set, the longitude and latitude coordinates of the geocoded result of an area will be (0,0). (Optional)

CENTER_LAT

NUMBER

Latitude value of the center of the area. (See the explanation for the CENTER_LONG column.) (Optional)

ROAD_SEGMENT_ID

NUMBER(10)

ID of the road segment to which the area center is set. This value must be set correctly if the geocoder is intended to work with the Oracle Spatial routing engine (described in Appendix C); otherwise, it can be set to any nonzero value, but it cannot be null. (Required)

COUNTRY_CODE_2

VARCHAR2(2)

2- letter ISO country code of the country to which the area belongs. (Required)

PARTITION_ID

NUMBER

NUM_STREETS

NUMBER

The number of streets inside this area. (Optional)

## 5.5.6 GC_ROAD_<suffix> Table

The GC_ROAD_<suffix> table (for example, GC_ROAD_US) stores road information for the country associated with the table name suffix. A road is a collection of road segments with the same name in the same settlement area; a road segment (defined in the GC_ROAD_SEGMENT_<suffix> table) is the segment of the road between two continuous intersections. The GC_ROAD_<suffix> table contains one or more rows for each road. (For example, it can contain multiple rows for a road if the road is associated with multiple settlements.) The GC_ROAD_<suffix> table contains the columns shown in Table 5-11.

Table 5-11 GC_ROAD_<suffix> Table

Column Name Data Type Description ROAD_ID

NUMBER

ID number of the road. (Required)

SETTLEMENT_ID

NUMBER(10)

ID number of the settlement to which the road belongs. (Required if the road is associated with a settlement)

MUNICIPALITY_ID

NUMBER(10)

ID number of the municipality to which the road belongs. (Required if the road is associated with a municipality)

PARENT_AREA_ID

NUMBER(10)

ID number of the parent area of the municipality to which the road belongs. (Required if the road is associated with a parent area)

LANG_CODE

VARCHAR2(3)

3-letter ISO national language code for the language for the road name. (Required)

NAME

VARCHAR2(64)

Name of the road, including the type (if any), the prefix (if any), and the suffix (if any). For example,

`N Main St`

as NAME, with`Main`

as BASE_NAME. (Required)BASE_NAME

VARCHAR2(64)

Name of the roaGZd, excluding the type (if any), the prefix (if any), and the suffix (if any). For example,

`N Main St`

as NAME, with`Main`

as BASE_NAME. (Required)PREFIX

VARCHAR2(32)

Prefix of the road name. For example,

`N Main St`

as NAME, with`N`

as PREFIX. (Required if the road name has a prefix)SUFFIX

VARCHAR2(32)

Suffix of the road name. For example,

`Main St NW`

as NAME, with`NW`

as SUFFIX. (Required if the road name has a suffix)STYPE_BEFORE

VARCHAR2(32)

Street type that precedes the base name. For example,

`Avenue Victor Hugo`

as NAME, with`Avenue`

as STYPE_BEFORE and`Victor Hugo`

as BASE_NAME. (Required if the road type precedes the base name)STYPE_AFTER

VARCHAR2(32)

Street type that follows the base name. For example,

`Main St`

as NAME, with`St`

as STYPE_AFTER and`Main`

as BASE_NAME. (Required if the road type follows the base name)STYPE_ATTACHED

VARCHAR2(1)

Contains

`T`

if the street type is in the same word with the street name; contains`F`

if the street type is a separate word from the street name. For example, in a German street address of`123 Beethovenstrass`

, the street type is`strass`

, and it is in the same word with the street name, which is`Beethoven`

. (Required)START_HN

NUMBER(5)

(Should be set to the same value as CENTER_HN; not currently used by Oracle)

CENTER_HN

NUMBER(5)

Leading numerical part of the center house number. The center house number is the left side house number at the start point of the center road segment, which is located in the center of the whole road. (See the explanation of house numbers after Table 5-12 in Section 5.5.7.) (Required)

END_HN

NUMBER(5)

(Should be set to the same value as CENTER_HN; not currently used by Oracle)

START_HN_SIDE

VARCHAR2(1)

(Should be set to the same value as CENTER_HN_SIDE; not currently used by Oracle)

CENTER_HN_SIDE

VARCHAR2(1)

Side of the road of the center house number:

`L`

for left or`R`

for right. The center house number is the left side house number at the start point of the center road segment, which is located in the center of the whole road. (See the explanation of house numbers after Table 5-12 in Section 5.5.7.) (Required)END_HN_SIDE

VARCHAR2(1)

(Should be set to the same value as CENTER_HN_SIDE; not currently used by Oracle)

START_LONG

NUMBER

(Should be set to the same value as CENTER_LONG; not currently used by Oracle)

START_LAT

NUMBER

(Should be set to the same value as CENTER_LAT; not currently used by Oracle)

CENTER_LONG

NUMBER

Longitude value of the center house number. The center house number is the left side house number at the start point of the center road segment, which is located in the center of the whole road. (See the explanation of house numbers after Table 5-12 in Section 5.5.7.) (Required)

CENTER_LAT

NUMBER

Latitude value of the center house number. (See also the explanation of the CENTER_LONG column.) (Required)

END_LONG

NUMBER

(Should be set to the same value as CENTER_LONG; not currently used by Oracle)

END_LAT

NUMBER

(Should be set to the same value as CENTER_LAT; not currently used by Oracle)

START_ROAD_SEG_ID

NUMBER(5)

(Should be set to the same value as CENTER_ROAD_SEG_ID; not currently used by Oracle)

CENTER_ROAD_SEG_ID

NUMBER(5)

ID number of the road segment at the center point of the road. (Required)

END_ROAD_SEG_ID

NUMBER(5)

(Should be set to the same value as CENTER_ROAD_SEG_ID; not currently used by Oracle)

POSTAL_CODE

VARCHAR2(16)

Postal code for the road. (Required)

COUNTRY_CODE_2

VARCHAR2(2)

2- letter ISO country code of the country to which the road belongs. (Required)

PARTITION_ID

NUMBER

CENTER_HN2

VARCHAR2(10)

The second part of the center house number. (See the explanation of house numbers after Table 5-12 in Section 5.5.7.) (Required)

## 5.5.7 GC_ROAD_SEGMENT_<suffix> Table

The GC_ROAD_SEGMENT_<suffix> table (for example, GC_ROAD_SEGMENT_US) stores road segment information for the country associated with the table name suffix. A road segment is the segment of the road between two continuous intersections, while a road (defined in the GC_ROAD_<suffix> table) is a collection of road segments with the same name in the same settlement area. The GC_ROAD_SEGMENT_<suffix> table contains one row for each road segment, and it contains the columns shown in Table 5-12.

Table 5-12 GC_ROAD_SEGMENT_<suffix> Table

Column Name Data Type Description ROAD_SEGMENT_ID

NUMBER

ID number of the road segment. (Required)

ROAD_ID

NUMBER

ID number of the road containing this road segment. (Required)

L_ADDR_FORMAT

VARCHAR2(1)

Left side address format. Specify

`N`

if there are one or more house numbers on the left side of the road segment; leave null if there is no house number on the left side of the road segment. (Required)R_ADDR_FORMAT

VARCHAR2(1)

Right side address format. Specify

`N`

if there are one or more house numbers on the right side of the road segment; leave null if there is no house number on the right side of the road segment. (Required)L_ADDR_SCHEME

VARCHAR2(1)

Numbering scheme for house numbers on the left side of the road segment:

`O`

(all odd numbers),`E`

(all even numbers), or`M`

(mixture of odd and even numbers). (Required)R_ADDR_SCHEME

VARCHAR2(1)

Numbering scheme for house numbers on the right side of the road segment:

`O`

(all odd numbers),`E`

(all even numbers), or`M`

(mixture of odd and even numbers). (Required)START_HN

NUMBER(5)

The lowest house number on this road segment. (Required)

END_HN

NUMBER(5)

The highest house number on this road segment. (Required)

L_START_HN

NUMBER(5)

The leading numerical part of the left side starting house number. (See the explanation of house numbers after this table.) (Required)

L_END_HN

NUMBER(5)

The leading numerical part of the left side ending house number. (See the explanation of house numbers after this table.) (Required)

R_START_HN

NUMBER(5)

The leading numerical part of the right side starting house number. (See the explanation of house numbers after this table.) (Required)

R_END_HN

NUMBER(5)

The leading numerical part of the right side ending house number. (See the explanation of house numbers after this table.) (Required)

POSTAL_CODE

VARCHAR2(16)

Postal code for the road segment. If the left side and right side of the road segment belong to two different postal codes, create two rows for the road segment with identical values in all columns except for POSTAL_CODE. (Required)

GEOMETRY

SDO_GEOMETRY

Spatial geometry object representing the road segment. (Required)

COUNTRY_CODE_2

VARCHAR2(2)

2- letter ISO country code of the country to which the road segment belongs. (Required)

PARTITION_ID

NUMBER

L_START_HN2

VARCHAR2(10)

The second part of the left side starting house number. (See the explanation of house numbers after this table.) (Required if the left side starting house number has a second part)

L_END_HN2

VARCHAR2(10)

The second part of the left side ending house number. (See the explanation of house numbers after this table.) (Required if the left side ending house number has a second part)

R_START_HN2

VARCHAR2(10)

The second part of the right side starting house number. (See the explanation of house numbers after this table.) (Required if the right side starting house number has a second part)

R_END_HN2

VARCHAR2(10)

The second part of the right side ending house number. (See the explanation of house numbers after this table.) (Required if the right side ending house number has a second part)

The starting house number is the house number at the starting point of the street segment, which is the first shape point of the road segment geometry (GEOMETRY column). The ending house number is the house number at the ending point of the street segment, which is the last shape point of the road segment geometry. The left and right side starting house numbers do not have to be lower than the left and right ending house numbers.

A house number is divided into two parts: the leading numerical part and the second part, which is the rest of the house number. The leading numerical part is the numerical part of the house number that starts from the beginning of the whole house number string and ends just before the first non-numeric character (if any). If the house number contains any non-numeric characters, the second part of the house number is the part from the first non-numeric character through the last character. For example, if the house number is

`123`

, the leading numerical part is`123`

and the second part is null; however, if the house number is`123A23`

, the leading numerical part is`123`

and the second part is`A23`

.,VKzU`@ xZ$TYpB|nc,3G4$?PU4_@)D3>0 , `5&@Cل` 5_ Mc(.RCcV[ \@7"S/vCרGw5uK)>0堷!ݟ8y2.; 8":?/p5+ -Ko90cpD=sފPkߴ|'B@ ]& G!0Z`)P]b~S#AWh}כ_ áA=[[aG:P+~0>WgJC}B&lkg&k;PKwC>PKlUIOEBPS/sdointer.gif?GIF89aDDDwwwUUU̙fff333""",` dihlp tmxpH,rK2ШtZ{իvf/xL3z7|Nn^~fGK1+[:S"O64QH|P;{¿uLvT̿̀}۹wrojgb>qjГ1G?*ZLF<~ Ld?u @d2cF$8A@s';XsXҼY0Hੂ4@; (X @hNyH$$T8:*jzR/6[L2 juZ M[l`"1g^ ztpGOOFjnuoi<@h4Hk]G VTӾGΝ=VmRrIV^%Yf[xn~7]Q4^|!WBeE!%%Eni@H('g(XC ,#}Vn0z #bQ"\[o 98.9r9g̘٥fZF~lNR)\ gWߝ8\g2siZ^@:\5Zϣ"hJdz襚x) >ʩb꧱j8rk>A:+;"q:,δ,Z7- Linear Referencing System PKgPKlUIOEBPS/linear.gif!GIF87a]]]勋̲ؐ;;;TTTPPPCCCXXX&&&YYYHHH???fff"""www{{{UUU777666DDD...***ٜ%%%222xxxGGG!!!nnnvvvLLLeeesssKKKjjj)))bbbaaa333\\\---iiirrr˾```SSS|}|:::zzz >>>WWWooo,Ŏʥ̈́ ӆ. @]cCJm 2h0C>"AFhg %F`DZ+=9赈F8" )TXa IIP/X,p @^IԪSe*;ݻ@`@l I3TlAb-ʾ| ϠCb"@,ر=^Μ"1## 7 Linear Referencing System

Linear referencing is a natural and convenient means to associate attributes or events to locations or portions of a linear feature. It has been widely used in transportation applications (such as for highways, railroads, and transit routes) and utilities applications (such as for gas and oil pipelines). The major advantage of linear referencing is its capability of locating attributes and events along a linear feature with only one parameter (usually known as measure) instead of two (such as longitude/latitude or x/y in Cartesian space). Sections of a linear feature can be referenced and created dynamically by indicating the start and end locations along the feature without explicitly storing them.

The linear referencing system (LRS) application programming interface (API) in Oracle Spatial provides server-side LRS capabilities at the cartographic level. The linear measure information is directly integrated into the Oracle Spatial geometry structure. The Oracle Spatial LRS API provides support for dynamic segmentation, and it serves as a groundwork for third-party or middle-tier application development for virtually any linear referencing methods and models in any coordinate system.

For an example of LRS, see Section 7.7. However, you may want to read the rest of this chapter first, to understand the concepts that the example illustrates.

For reference information about LRS functions and procedures, see Chapter 16.

If you have LRS data from a previous release of Spatial, see Section A.1 for information about upgrading LRS data.

This chapter contains the following major sections:

## 7.1 Terms and Concepts

This section explains important terms and concepts related to linear referencing support in Oracle Spatial.

## 7.1.1 Geometric Segments (LRS Segments)

Geometric segments are basic LRS elements in Oracle Spatial. A geometric segment can be any of the following:

Line string: an ordered, nonbranching, and continuous geometry (for example, a simple road)

Multiline string: nonconnected line strings (for example, a highway with a gap caused by a lake or a bypass road)

Polygon (for example, a racetrack or a scenic tour route that starts and ends at the same point)

A geometric segment must contain at least start and end measures for its start and end points. Measures of points of interest (such as highway exits) on the geometric segments can also be assigned. These measures are either assigned by users or derived from existing geometric segments. Figure 7-1 shows a geometric segment with four line segments and one arc. Points on the geometric segment are represented by triplets (x, y, m), where x and y describe the location and m denotes the measure (with each measure value underlined in Figure 7-1).

## 7.1.2 Shape Points

Shape points are points that are specified when an LRS segment is constructed, and that are assigned measure information. In Oracle Spatial, a line segment is represented by its start and end points, and an arc is represented by three points: start, middle, and end points of the arc. You must specify these points as shape points, but you can also specify other points as shape points if you need measure information stored for these points (for example, an exit in the middle of a straight part of the highway).

Thus, shape points can serve one or both of the following purposes: to indicate the direction of the segment (for example, a turn or curve), and to identify a point of interest for which measure information is to be stored.

Shape points might not directly relate to mileposts or reference posts in LRS; they are used as internal reference points. The measure information of shape points is automatically populated when you define the LRS segment using the SDO_LRS.DEFINE_GEOM_SEGMENT procedure, which is described in Chapter 16.

## 7.1.3 Direction of a Geometric Segment

The direction of a geometric segment is indicated from the start point of the geometric segment to the end point. The direction is determined by the order of the vertices (from start point to end point) in the geometry definition. Measures of points on a geometric segment always either increase or decrease along the direction of the geometric segment.

## 7.1.4 Measure (Linear Measure)

The measure of a point along a geometric segment is the linear distance (in the measure dimension) to the point measured from the start point (for increasing values) or end point (for decreasing values) of the geometric segment. The measure information does not necessarily have to be of the same scale as the distance. However, the linear mapping relationship between measure and distance is always preserved.

Some LRS functions use offset instead of measure to represent measured distance along linear features. Although some other linear referencing systems might use offset to mean what the Oracle Spatial LRS refers to as measure, offset has a different meaning in Oracle Spatial from measure, as explained in Section 7.1.5.

## 7.1.5 Offset

The offset of a point along a geometric segment is the perpendicular distance between the point and the geometric segment. Offsets are positive if the points are on the left side along the segment direction and are negative if they are on the right side. Points are on a geometric segment if their offsets to the segment are zero.

The unit of measurement for an offset is the same as for the coordinate system associated with the geometric segment. For geodetic data, the default unit of measurement is meters.

Figure 7-2 shows how a point can be located along a geometric segment with measure and offset information. By assigning an offset together with a measure, it is possible to locate not only points that are on the geometric segment, but also points that are perpendicular to the geometric segment.

## 7.1.6 Measure Populating

Any unassigned measures of a geometric segment are automatically populated based upon their distance distribution. This is done before any LRS operations for geometric segments with unknown measures (NULL in Oracle Spatial). The resulting geometric segments from any LRS operations return the measure information associated with geometric segments. The measure of a point on the geometric segment can be obtained based upon a linear mapping relationship between its previous and next known measures or locations. See the algorithm representation in Figure 7-3 and the example in Figure 7-4.

Measures are evenly spaced between assigned measures. However, the assigned measures for points of interest on a geometric segment do not need to be evenly spaced. This could eliminate the problem of error accumulation and account for inaccuracy of data source.

Moreover, the assigned measures do not even need to reflect actual distances (for example, they can reflect estimated driving time); they can be any valid values within the measure range. Figure 7-5 shows the measure population that results when assigned measure values are not proportional and reflect widely varying gaps.

In all cases, measure populating is done in an incremental fashion along the segment direction. This improves the performance of current and subsequent LRS operations.

## 7.1.7 Measure Range of a Geometric Segment

The start and end measures of a geometric segment define the linear measure range of the geometric segment. Any valid LRS measures of a geometric segment must fall within its linear measure range.

## 7.1.8 Projection

The projection of a point along a geometric segment is the point on the geometric segment with the minimum distance to the specified point. The measure information of the resulting point is also returned in the point geometry.

## 7.1.9 LRS Point

LRS points are points with linear measure information along a geometric segment. A valid LRS point is a point geometry with measure information.

All LRS point data must be stored in the SDO_ELEM_INFO_ARRAY and SDO_ORDINATE_ARRAY, and cannot be stored in the SDO_POINT field in the SDO_GEOMETRY definition of the point.

## 7.1.10 Linear Features

Linear features are any spatial objects that can be treated as a logical set of linear segments. Examples of linear features are highways in transportation applications and pipelines in utility industry applications. The relationship of linear features, geometric segments, and LRS points is shown in Figure 7-6, where a single linear feature consists of three geometric segments, and three LRS points are shown on the first segment.

## 7.1.11 Measures with Multiline Strings and Polygons with Holes

With a multiline string or polygon with hole LRS geometry, the SDO_LRS.DEFINE_GEOM_SEGMENT procedure and SDO_LRS.CONVERT_TO_LRS_GEOM function by default assign the same measure value to the end point of one segment and the start point (separated by a gap) of the next segment, although you can later assign different measure values to points. Thus, by default there will duplicate measure values in different segments for such geometries. In such cases, LRS subprograms use the first point with a specified measure, except when doing so would result in an invalid geometry.

For example, assume that in a multiline string LRS geometry, the first segment is from measures 0 through 100 and the second segment is from measures 100 through 150. If you use the SDO_LRS.LOCATE_PT function to find the point at measure 100, the returned point will be at measure 100 in the first segment. If you use the SDO_LRS.CLIP_GEOM_SEGMENT, SDO_LRS.DYNAMIC_SEGMENT, or SDO_LRS.OFFSET_GEOM_SEGMENT function to return the geometry object between measures 75 and 125, the result is a multiline string geometry consisting of two segments. If you use the same function to return the geometry object between measures 100 and 125, the point at measure 100 in the first segment is ignored, and the result is a line string along the second segment from measures 100 through 125.

## 7.2 LRS Data Model

The Oracle Spatial LRS data model incorporates measure information into its geometry representation at the point level. The measure information is directly integrated into the Oracle Spatial model. To accomplish this, an additional measure dimension must be added to the Oracle Spatial metadata.

Oracle Spatial LRS support affects the Spatial metadata and data (the geometries). Example 7-1 shows how a measure dimension can be added to two-dimensional geometries in the Spatial metadata. The measure dimension must be the last element of the SDO_DIM_ARRAY in a spatial object definition (shown in bold in Example 7-1).

Example 7-1 Including LRS Measure Dimension in Spatial Metadata

`INSERT INTO user_sdo_geom_metadata (TABLE_NAME, COLUMN_NAME, DIMINFO, SRID) VALUES( 'LRS_ROUTES', 'GEOMETRY', SDO_DIM_ARRAY ( SDO_DIM_ELEMENT('X', 0, 20, 0.005), SDO_DIM_ELEMENT('Y', 0, 20, 0.005), SDO_DIM_ELEMENT('M', 0, 100, 0.005)), NULL);`

After adding the new measure dimension, geometries with measure information such as geometric segments and LRS points can be represented. An example of creating a geometric segment with three line segments is shown in Figure 7-7.

In Figure 7-7, the geometric segment has the following definition (with measure values underlined):

SDO_GEOMETRY(3302, NULL, NULL, SDO_ELEM_INFO_ARRAY(1,2,1), SDO_ORDINATE_ARRAY(5,10,0, 20,5,NULL, 35,10,NULL, 55,10,100))Whenever a geometric segment is defined, its start and end measures must be defined or derived from some existing geometric segment. The unsigned measures of all shape points on a geometric segment will be automatically populated.

The LRS API works with geometries in formats of Oracle Spatial before release 8.1.6, but the resulting geometries will be converted to the Oracle Spatial release 8.1.6 or later format, specifically with 4-digit SDO_GTYPE and SDO_ETYPE values. For example, in Oracle Spatial release 8.1.6 and later, the geometry type (SDO_GTYPE) of a spatial object includes the number of dimensions of the object as the first digit of the SDO_GTYPE value. Thus, the SDO_GTYPE value of a point is 1 in the format before release 8.1.6 but 2001 in the release 8.1.6 format (the number of dimensions of the point is 2). However, an LRS point (which includes measure information) has three dimensions, and thus the SDO_GTYPE of any point geometry used with an LRS function must be 3301.

## 7.3 Indexing of LRS Data

If LRS data has four dimensions (three plus the M dimension) and if you need to index all three non-measure dimensions, you must use a spatial R-tree index to index the data, and you must specify PARAMETERS('sdo_indx_dims=3') in the CREATE INDEX statement to ensure that the first three dimensions are indexed. Note, however, that if you specify an

`sdo_indx_dims`

value of 3 or higher, the only Spatial operator that can be used on the indexed geometries is SDO_FILTER; the other operators described in Chapter 11 cannot be used. (The default value for the`sdo_indx_dims`

keyword is 2, which would cause only the first two dimensions to be indexed.) For example, if the dimensions are X, Y, Z, and M, specify`sdo_indx_dims=3`

to index the X, Y, and Z dimensions, but not the measure (M) dimension. Do not include the measure dimension in a spatial index, because this causes additional processing overhead and produces no benefit.Information about the CREATE INDEX statement and its parameters and keywords is in Chapter 10.

## 7.4 3D Formats of LRS Functions

Most LRS functions have formats that end in _3D: for example, DEFINE_GEOM_SEGMENT_3D, CLIP_GEOM_SEGMENT_3D, FIND_MEASURE_3D, and LOCATE_PT_3D. If a function has a 3D format, it is identified in the Usage Notes for the function in Chapter 16.

The 3D formats are supported only for line string and multiline string geometries. The 3D formats should be used only when the geometry object has four dimensions and the fourth dimension is the measure (for example, X, Y, Z, and M), and only when you want the function to consider the first three dimensions (for example, X, Y, and Z). If the standard format of a function (that is, without the _3D) is used on a geometry with four dimensions, the function considers only the first two dimensions (for example, X and Y).

For example, the following format considers the X, Y, and Z dimensions of the specified GEOM object in performing the clip operation:

SELECT SDO_LRS.CLIP_GEOM_SEGMENT_3D(a.geom, m.diminfo, 5, 10) FROM routes r, user_sdo_geom_metadata m WHERE m.table_name = 'ROUTES' AND m.column_name = 'GEOM' AND r.route_id = 1;However, the following format considers only the X and Y dimensions, and ignores the Z dimension, of the specified GEOM object in performing the clip operation:

SELECT SDO_LRS.CLIP_GEOM_SEGMENT(a.geom, m.diminfo, 5, 10) FROM routes r, user_sdo_geom_metadata m WHERE m.table_name = 'ROUTES' AND m.column_name = 'GEOM' AND r.route_id = 1;The parameters for the standard and 3D formats of any function are the same, and the Usage Notes apply to both formats.

The 3D formats are not supported with the following:

Geodetic data

Polygons, arcs, or circles

## 7.5 LRS Operations

This section describes several linear referencing operations supported by the Oracle Spatial LRS API.

## 7.5.1 Defining a Geometric Segment

There are two ways to create a geometric segment with measure information:

Construct a geometric segment and assign measures explicitly.

Define a geometric segment with specified start and end, and any other measures, in an ascending or descending order. Measures of shape points with unknown (unassigned) measures (null values) in the geometric segment will be automatically populated according to their locations and distance distribution.

Figure 7-8 shows different ways of defining a geometric segment:

An LRS segment must be defined (or must already exist) before any LRS operations can proceed. That is, the start, end, and any other assigned measures must be present to derive the location from a specified measure. The measure information of intermediate shape points will automatically be populated if measure values are not assigned.

## 7.5.2 Redefining a Geometric Segment

You can redefine a geometric segment to replace the existing measures of all shape points between the start and end point with automatically calculated measures. Redefining a segment can be useful if errors have been made in one or more explicit measure assignments, and you want to start over with proportionally assigned measures.

Figure 7-9 shows the redefinition of a segment where the existing (before) assigned measure values are not proportional and reflect widely varying gaps.

After the segment redefinition in Figure 7-9, the populated measures reflect proportional distances along the segment.

## 7.5.3 Clipping a Geometric Segment

You can clip a geometric segment to create a new geometric segment out of an existing geometric segment, as shown in Figure 7-10, part a.

In Figure 7-10, part a, a segment is created from part of a larger segment. The new segment has its own start and end points, and the direction is the same as in the original larger segment.

## 7.5.4 Splitting a Geometric Segment

You can create two new geometric segments by splitting a geometric segment, as shown in Figure 7-10, part b. The direction of each new segment is the same as in the original segment.

Note:

In Figure 7-10 and several figures that follow, small gaps between segments are used in illustrations of segment splitting and concatenation. Each gap simply reinforces the fact that two different segments are involved. However, the two segments (such as segment 1 and segment 2 in Figure 7-10, parts b and c) are actually connected. The tolerance (see Section 1.5.5) is considered in determining whether or not segments are connected.## 7.5.5 Concatenating Geometric Segments

You can create a new geometric segment by concatenating two geometric segments, as shown in Figure 7-10, part c. The geometric segments do not need to be spatially connected, although they are connected in the illustration in Figure 7-10, part c. (If the segments are not spatially connected, the concatenated result is a multiline string.) The measures of the second geometric segment are shifted so that the end measure of the first segment is the same as the start measure of the second segment. The direction of the segment resulting from the concatenation is the same as in the two original segments.

Measure assignments for the clipping, splitting, and concatenating operations in Figure 7-10 are shown in Figure 7-11. Measure information and segment direction are preserved in a consistent manner. The assignment is done automatically when the operations have completed.

The direction of the geometric segment resulting from concatenation is always the direction of the first segment (

`geom_segment1`

in the call to the SDO_LRS.CONCATENATE_GEOM_SEGMENTS function), as shown in Figure 7-12.In addition to explicitly concatenating two connected segments using the SDO_LRS.CONCATENATE_GEOM_SEGMENTS function, you can perform aggregate concatenation: that is, you can concatenate all connected geometric segments in a column (layer) using the SDO_AGGR_LRS_CONCAT spatial aggregate function. (See the description and example of the SDO_AGGR_LRS_CONCAT spatial aggregate function in Chapter 12.)

## 7.5.6 Scaling a Geometric Segment

You can create a new geometric segment by performing a linear scaling operation on a geometric segment. Figure 7-13 shows the mapping relationship for geometric segment scaling.

In general, scaling a geometric segment only involves rearranging measures of the newly created geometric segment. However, if the scaling factor is negative, the order of the shape points needs to be reversed so that measures will increase along the geometric segment's direction (which is defined by the order of the shape points).

A scale operation can perform any combination of the following operations:

Translating (shifting) measure information. (For example, add the same value to Ms and Me to get M's and M'e.)

Reversing measure information. (Let M's = Me, M'e = Ms, and Mshift = 0.)

Performing simple scaling of measure information. (Let Mshift = 0.)

For examples of these operations, see the Usage Notes and Examples for the SDO_LRS.TRANSLATE_MEASURE, SDO_LRS.REVERSE_GEOMETRY, and SDO_LRS.REDEFINE_GEOM_SEGMENT subprograms in Chapter 16.

## 7.5.7 Offsetting a Geometric Segment

You can create a new geometric segment by performing an offsetting operation on a geometric segment. Figure 7-14 shows the mapping relationship for geometric segment offsetting.

In the offsetting operation shown in Figure 7-14, the resulting geometric segment is offset by 5 units from the specified start and end measures of the original segment.

For more information, see the Usage Notes and Examples for the SDO_LRS.OFFSET_GEOM_SEGMENT function in Chapter 16.

## 7.5.8 Locating a Point on a Geometric Segment

You can find the position of a point described by a measure and an offset on a geometric segment (see Figure 7-15).

There is always a unique location with a specific measure on a geometric segment. Ambiguity arises when offsets are given and the points described by the measures fall on shape points of the geometric segment (see Figure 7-16).

As shown in Figure 7-16, an offset arc of a shape point on a geometric segment is an arc on which all points have the same minimum distance to the shape point. As a result, all points on the offset arc are represented by the same (measure, offset) pair. To resolve this one-to-many mapping problem, the middle point on the offset arc is returned.

## 7.5.9 Projecting a Point onto a Geometric Segment

You can find the projection point of a point with respect to a geometric segment. The point to be projected can be on or off the segment. If the point is on the segment, the point and its projection point are the same.

Projection is a reverse operation of the point-locating operation shown in Figure 7-15. Similar to a point-locating operation, all points on the offset arc of a shape point will have the same projection point (that is, the shape point itself), measure, and offset (see Figure 7-16). If there are multiple projection points for a point, the first one from the start point is returned (Projection Point 1 in both illustrations in Figure 7-17).

## 7.5.10 Converting LRS Geometries

You can convert geometries from standard line string format to LRS format, and the reverse. The main use of conversion functions will probably occur if you have a large amount of existing line string data, in which case conversion is a convenient alternative to creating all of the LRS segments manually. However, if you need to convert LRS segments to standard line strings for certain applications, that capability is provided also.

Functions are provided to convert:

Individual line strings or points

For conversion from standard format to LRS format, a measure dimension (named M by default) is added, and measure information is provided for each point. For conversion from LRS format to standard format, the measure dimension and information are removed. In both cases, the dimensional information (DIMINFO) metadata in the USER_SDO_GEOM_METADATA view is not affected.

Layers (all geometries in a column)

For conversion from standard format to LRS format, a measure dimension (named M by default) is added, but no measure information is provided for each point. For conversion from LRS format to standard format, the measure dimension and information are removed. In both cases, the dimensional information (DIMINFO) metadata in the USER_SDO_GEOM_METADATA view is modified as needed.

Dimensional information (DIMINFO)

The dimensional information (DIMINFO) metadata in the USER_SDO_GEOM_METADATA view is modified as needed. For example, converting a standard dimensional array with X and Y dimensions (SDO_DIM_ELEMENT) to an LRS dimensional array causes an M dimension (SDO_DIM_ELEMENT) to be added.

Figure 7-18 shows the addition of measure information when a standard line string is converted to an LRS line string (using the SDO_LRS.CONVERT_TO_LRS_GEOM function). The measure dimension values are underlined in Figure 7-18.

For conversions of point geometries, the SDO_POINT attribute (described in Section 2.2.3) in the returned geometry is affected as follows:

If a standard point is converted to an LRS point, the SDO_POINT attribute information in the input geometry is used to set the SDO_ELEM_INFO and SDO_ORDINATES attributes (described in Section 2.2.4 and Section 2.2.5) in the resulting geometry, and the SDO_POINT attribute in the resulting geometry is set to null.

If an LRS point is converted to a standard point, the information in the SDO_ELEM_INFO and SDO_ORDINATES attributes (described in Section 2.2.4 and Section 2.2.5) in the input geometry is used to set the SDO_POINT attribute information in the resulting geometry, and the SDO_ELEM_INFO and SDO_ORDINATES attributes in the resulting geometry are set to null.

The conversion functions are listed in Table 16-3 in Chapter 16. See also the reference information in Chapter 16 about each conversion function.

## 7.6 Tolerance Values with LRS Functions

Many LRS functions require that you specify a tolerance value or one or more dimensional arrays. Thus, you can control whether to specify a single tolerance value for all non-measure dimensions or to use the tolerance associated with each non-measure dimension in the dimensional array or arrays. The tolerance is applied only to the geometry portion of the data, not to the measure dimension. The tolerance value for geodetic data is in meters, and for non-geodetic data it is in the unit of measurement associated with the data. (For a detailed discussion of tolerance, see Section 1.5.5.)

Be sure that the tolerance value used is appropriate to the data and your purpose. If the results of LRS functions seem imprecise or incorrect, you may need to specify a smaller tolerance value.

For clip operations (see Section 7.5.3) and offset operations (see Section 7.5.7), if the returned segment has any shape points within the tolerance value of the input geometric segment from what would otherwise be the start point or end point of the returned segment, the shape point is used as the start point or end point of the returned segment. This is done to ensure that the resulting geometry does not contain any redundant vertices, which would cause the geometry to be invalid. For example, assume that the tolerance associated with the geometric segment (non-geodetic data) in Figure 7-19 is 0.5.

If you request a clip operation to return the segment between measure values 0 (the start point) and 61.5 in Figure 7-19, and if the distance between the points associated with measure values 61.5 and 61.257 is less than the 0.5 tolerance value, the end point of the returned segment is (35, 10, 61.257).

## 7.7 Example of LRS Functions

This section presents a simplified example that uses LRS functions. It refers to concepts that are explained in this chapter and uses functions documented in Chapter 16.

This example uses the road that is illustrated in Figure 7-20.

In Figure 7-20, the highway (Route 1) starts at point 2,2 and ends at point 5,14, follows the path shown, and has six entrance-exit points (Exit 1 through Exit 6). For simplicity, each unit on the graph represents one unit of measure, and thus the measure from start to end is 27 (the segment from Exit 5 to Exit 6 being the hypotenuse of a 3-4-5 right triangle).

Each row in Table 7-1 lists an actual highway-related feature and the LRS feature that corresponds to it or that can be used to represent it.

Table 7-1 Highway Features and LRS Counterparts

Highway Feature LRS Feature Named route, road, or street

LRS segment, or linear feature (logical set of segments)

Mile or kilometer marker

Measure

Accident reporting and location tracking

SDO_LRS.LOCATE_PT function

Construction zone (portion of a road)

SDO_LRS.CLIP_GEOM_SEGMENT function

Road extension (adding at the beginning or end) or combination (designating or renaming two roads that meet as one road)

SDO_LRS.CONCATENATE_GEOM_SEGMENTS function

Road reconstruction or splitting (resulting in two named roads from one named road)

SDO_LRS.SPLIT_GEOM_SEGMENT procedure

Finding the closest point on the road to a point off the road (such as a building)

SDO_LRS.PROJECT_PT function

Guard rail or fence alongside a road

SDO_LRS.OFFSET_GEOM_SEGMENT function

Example 7-2 does the following:

Creates a table to hold the segment depicted in Figure 7-20

Inserts the definition of the highway depicted in Figure 7-20 into the table

Inserts the necessary metadata into the USER_SDO_GEOM_METADATA view

Uses PL/SQL and SQL statements to define the segment and perform operations on it

Example 7-3 includes the output of the SELECT statements in Example 7-2.

Example 7-2 Simplified Example: Highway

-- Create a table for routes (highways). CREATE TABLE lrs_routes ( route_id NUMBER PRIMARY KEY, route_name VARCHAR2(32), route_geometry SDO_GEOMETRY); -- Populate table with just one route for this example. INSERT INTO lrs_routes VALUES( 1, 'Route1', SDO_GEOMETRY( 3302, -- line string, 3 dimensions: X,Y,M NULL, NULL, SDO_ELEM_INFO_ARRAY(1,2,1), -- one line string, straight segments SDO_ORDINATE_ARRAY( 2,2,0, -- Start point - Exit1; 0 is measure from start. 2,4,2, -- Exit2; 2 is measure from start. 8,4,8, -- Exit3; 8 is measure from start. 12,4,12, -- Exit4; 12 is measure from start. 12,10,NULL, -- Not an exit; measure automatically calculated and filled. 8,10,22, -- Exit5; 22 is measure from start. 5,14,27) -- End point (Exit6); 27 is measure from start. ) ); -- Update the Spatial metadata. INSERT INTO user_sdo_geom_metadata (TABLE_NAME, COLUMN_NAME, DIMINFO, SRID) VALUES ( 'lrs_routes', 'route_geometry', SDO_DIM_ARRAY( -- 20X20 grid SDO_DIM_ELEMENT('X', 0, 20, 0.005), SDO_DIM_ELEMENT('Y', 0, 20, 0.005), SDO_DIM_ELEMENT('M', 0, 20, 0.005) -- Measure dimension ), NULL -- SRID ); -- Create the spatial index. CREATE INDEX lrs_routes_idx ON lrs_routes(route_geometry) INDEXTYPE IS MDSYS.SPATIAL_INDEX; -- Test the LRS procedures. DECLARE geom_segment SDO_GEOMETRY; line_string SDO_GEOMETRY; dim_array SDO_DIM_ARRAY; result_geom_1 SDO_GEOMETRY; result_geom_2 SDO_GEOMETRY; result_geom_3 SDO_GEOMETRY; BEGIN SELECT a.route_geometry into geom_segment FROM lrs_routes a WHERE a.route_name = 'Route1'; SELECT m.diminfo into dim_array from user_sdo_geom_metadata m WHERE m.table_name = 'LRS_ROUTES' AND m.column_name = 'ROUTE_GEOMETRY'; -- Define the LRS segment for Route1. This will populate any null measures. -- No need to specify start and end measures, because they are already defined -- in the geometry. SDO_LRS.DEFINE_GEOM_SEGMENT (geom_segment, dim_array); SELECT a.route_geometry INTO line_string FROM lrs_routes a WHERE a.route_name = 'Route1'; -- Split Route1 into two segments. SDO_LRS.SPLIT_GEOM_SEGMENT(line_string,dim_array,5,result_geom_1,result_geom_2); -- Concatenate the segments that were just split. result_geom_3 := SDO_LRS.CONCATENATE_GEOM_SEGMENTS(result_geom_1, dim_array, result_geom_2, dim_array); -- Update and insert geometries into table, to display later. UPDATE lrs_routes a SET a.route_geometry = geom_segment WHERE a.route_id = 1; INSERT INTO lrs_routes VALUES( 11, 'result_geom_1', result_geom_1 ); INSERT INTO lrs_routes VALUES( 12, 'result_geom_2', result_geom_2 ); INSERT INTO lrs_routes VALUES( 13, 'result_geom_3', result_geom_3 ); END; / -- First, display the data in the LRS table. SELECT route_id, route_name, route_geometry FROM lrs_routes; -- Are result_geom_1 and result_geom2 connected? SELECT SDO_LRS.CONNECTED_GEOM_SEGMENTS(a.route_geometry, b.route_geometry, 0.005) FROM lrs_routes a, lrs_routes b WHERE a.route_id = 11 AND b.route_id = 12; -- Is the Route1 segment valid? SELECT SDO_LRS.VALID_GEOM_SEGMENT(route_geometry) FROM lrs_routes WHERE route_id = 1; -- Is 50 a valid measure on Route1? (Should return FALSE; highest Route1 measure is 27.) SELECT SDO_LRS.VALID_MEASURE(route_geometry, 50) FROM lrs_routes WHERE route_id = 1; -- Is the Route1 segment defined? SELECT SDO_LRS.IS_GEOM_SEGMENT_DEFINED(route_geometry) FROM lrs_routes WHERE route_id = 1; -- How long is Route1? SELECT SDO_LRS.GEOM_SEGMENT_LENGTH(route_geometry) FROM lrs_routes WHERE route_id = 1; -- What is the start measure of Route1? SELECT SDO_LRS.GEOM_SEGMENT_START_MEASURE(route_geometry) FROM lrs_routes WHERE route_id = 1; -- What is the end measure of Route1? SELECT SDO_LRS.GEOM_SEGMENT_END_MEASURE(route_geometry) FROM lrs_routes WHERE route_id = 1; -- What is the start point of Route1? SELECT SDO_LRS.GEOM_SEGMENT_START_PT(route_geometry) FROM lrs_routes WHERE route_id = 1; -- What is the end point of Route1? SELECT SDO_LRS.GEOM_SEGMENT_END_PT(route_geometry) FROM lrs_routes WHERE route_id = 1; -- Translate (shift measure values) (+10). -- First, display the original segment; then, translate. SELECT a.route_geometry FROM lrs_routes a WHERE a.route_id = 1; SELECT SDO_LRS.TRANSLATE_MEASURE(a.route_geometry, m.diminfo, 10) FROM lrs_routes a, user_sdo_geom_metadata m WHERE m.table_name = 'LRS_ROUTES' AND m.column_name = 'ROUTE_GEOMETRY' AND a.route_id = 1; -- Redefine geometric segment to "convert" miles to kilometers DECLARE geom_segment SDO_GEOMETRY; dim_array SDO_DIM_ARRAY; BEGIN SELECT a.route_geometry into geom_segment FROM lrs_routes a WHERE a.route_name = 'Route1'; SELECT m.diminfo into dim_array from user_sdo_geom_metadata m WHERE m.table_name = 'LRS_ROUTES' AND m.column_name = 'ROUTE_GEOMETRY'; -- "Convert" mile measures to kilometers (27 * 1.609 = 43.443). SDO_LRS.REDEFINE_GEOM_SEGMENT (geom_segment, dim_array, 0, -- Zero starting measure: LRS segment starts at start of route. 43.443); -- End of LRS segment. 27 miles = 43.443 kilometers. -- Update and insert geometries into table, to display later. UPDATE lrs_routes a SET a.route_geometry = geom_segment WHERE a.route_id = 1; END;/ -- Display the redefined segment, with all measures "converted." SELECT a.route_geometry FROM lrs_routes a WHERE a.route_id = 1; -- Clip a piece of Route1. SELECT SDO_LRS.CLIP_GEOM_SEGMENT(route_geometry, 5, 10) FROM lrs_routes WHERE route_id = 1; -- Point (9,3,NULL) is off the road; should return (9,4,9). SELECT SDO_LRS.PROJECT_PT(route_geometry, SDO_GEOMETRY(3301, NULL, NULL, SDO_ELEM_INFO_ARRAY(1, 1, 1), SDO_ORDINATE_ARRAY(9, 3, NULL)) ) FROM lrs_routes WHERE route_id = 1; -- Return the measure of the projected point. SELECT SDO_LRS.GET_MEASURE( SDO_LRS.PROJECT_PT(a.route_geometry, m.diminfo, SDO_GEOMETRY(3301, NULL, NULL, SDO_ELEM_INFO_ARRAY(1, 1, 1), SDO_ORDINATE_ARRAY(9, 3, NULL)) ), m.diminfo ) FROM lrs_routes a, user_sdo_geom_metadata m WHERE m.table_name = 'LRS_ROUTES' AND m.column_name = 'ROUTE_GEOMETRY' AND a.route_id = 1; -- Is point (9,3,NULL) a valid LRS point? (Should return TRUE.) SELECT SDO_LRS.VALID_LRS_PT( SDO_GEOMETRY(3301, NULL, NULL, SDO_ELEM_INFO_ARRAY(1, 1, 1), SDO_ORDINATE_ARRAY(9, 3, NULL)), m.diminfo) FROM lrs_routes a, user_sdo_geom_metadata m WHERE m.table_name = 'LRS_ROUTES' AND m.column_name = 'ROUTE_GEOMETRY' AND a.route_id = 1; -- Locate the point on Route1 at measure 9, offset 0. SELECT SDO_LRS.LOCATE_PT(route_geometry, 9, 0) FROM lrs_routes WHERE route_id = 1;Example 7-3 shows the output of the SELECT statements in Example 7-2.

Example 7-3 Simplified Example: Output of SELECT Statements

SQL> -- First, display the data in the LRS table. SQL> SELECT route_id, route_name, route_geometry FROM lrs_routes; ROUTE_ID ROUTE_NAME ---------- -------------------------------- ROUTE_GEOMETRY(SDO_GTYPE, SDO_SRID, SDO_POINT(X, Y, Z), SDO_ELEM_INFO, SDO_ORDIN -------------------------------------------------------------------------------- 1 Route1 SDO_GEOMETRY(3302, NULL, NULL, SDO_ELEM_INFO_ARRAY(1, 2, 1), SDO_ORDINATE_ARRAY( 2, 2, 0, 2, 4, 2, 8, 4, 8, 12, 4, 12, 12, 10, 18, 8, 10, 22, 5, 14, 27)) 11 result_geom_1 SDO_GEOMETRY(3302, NULL, NULL, SDO_ELEM_INFO_ARRAY(1, 2, 1), SDO_ORDINATE_ARRAY( 2, 2, 0, 2, 4, 2, 5, 4, 5)) 12 result_geom_2 ROUTE_ID ROUTE_NAME ---------- -------------------------------- ROUTE_GEOMETRY(SDO_GTYPE, SDO_SRID, SDO_POINT(X, Y, Z), SDO_ELEM_INFO, SDO_ORDIN -------------------------------------------------------------------------------- SDO_GEOMETRY(3302, NULL, NULL, SDO_ELEM_INFO_ARRAY(1, 2, 1), SDO_ORDINATE_ARRAY( 5, 4, 5, 8, 4, 8, 12, 4, 12, 12, 10, 18, 8, 10, 22, 5, 14, 27)) 13 result_geom_3 SDO_GEOMETRY(3302, NULL, NULL, SDO_ELEM_INFO_ARRAY(1, 2, 1), SDO_ORDINATE_ARRAY( 2, 2, 0, 2, 4, 2, 5, 4, 5, 8, 4, 8, 12, 4, 12, 12, 10, 18, 8, 10, 22, 5, 14, 27) ) SQL> -- Are result_geom_1 and result_geom2 connected? SQL> SELECT SDO_LRS.CONNECTED_GEOM_SEGMENTS(a.route_geometry, 2 b.route_geometry, 0.005) 3 FROM lrs_routes a, lrs_routes b 4 WHERE a.route_id = 11 AND b.route_id = 12; SDO_LRS.CONNECTED_GEOM_SEGMENTS(A.ROUTE_GEOMETRY,B.ROUTE_GEOMETRY,0.005) -------------------------------------------------------------------------------- TRUE SQL> -- Is the Route1 segment valid? SQL> SELECT SDO_LRS.VALID_GEOM_SEGMENT(route_geometry) 2 FROM lrs_routes WHERE route_id = 1; SDO_LRS.VALID_GEOM_SEGMENT(ROUTE_GEOMETRY) -------------------------------------------------------------------------------- TRUE SQL> -- Is 50 a valid measure on Route1? (Should return FALSE; highest Route1 measure is 27.) SQL> SELECT SDO_LRS.VALID_MEASURE(route_geometry, 50) 2 FROM lrs_routes WHERE route_id = 1; SDO_LRS.VALID_MEASURE(ROUTE_GEOMETRY,50) -------------------------------------------------------------------------------- FALSE SQL> -- Is the Route1 segment defined? SQL> SELECT SDO_LRS.IS_GEOM_SEGMENT_DEFINED(route_geometry) 2 FROM lrs_routes WHERE route_id = 1; SDO_LRS.IS_GEOM_SEGMENT_DEFINED(ROUTE_GEOMETRY) -------------------------------------------------------------------------------- TRUE SQL> -- How long is Route1? SQL> SELECT SDO_LRS.GEOM_SEGMENT_LENGTH(route_geometry) 2 FROM lrs_routes WHERE route_id = 1; SDO_LRS.GEOM_SEGMENT_LENGTH(ROUTE_GEOMETRY) ------------------------------------------- 27 SQL> -- What is the start measure of Route1? SQL> SELECT SDO_LRS.GEOM_SEGMENT_START_MEASURE(route_geometry) 2 FROM lrs_routes WHERE route_id = 1; SDO_LRS.GEOM_SEGMENT_START_MEASURE(ROUTE_GEOMETRY) -------------------------------------------------- 0 SQL> -- What is the end measure of Route1? SQL> SELECT SDO_LRS.GEOM_SEGMENT_END_MEASURE(route_geometry) 2 FROM lrs_routes WHERE route_id = 1; SDO_LRS.GEOM_SEGMENT_END_MEASURE(ROUTE_GEOMETRY) ------------------------------------------------ 27 SQL> -- What is the start point of Route1? SQL> SELECT SDO_LRS.GEOM_SEGMENT_START_PT(route_geometry) 2 FROM lrs_routes WHERE route_id = 1; SDO_LRS.GEOM_SEGMENT_START_PT(ROUTE_GEOMETRY)(SDO_GTYPE, SDO_SRID, SDO_POINT(X, -------------------------------------------------------------------------------- SDO_GEOMETRY(3301, NULL, NULL, SDO_ELEM_INFO_ARRAY(1, 1, 1), SDO_ORDINATE_ARRAY( 2, 2, 0)) SQL> -- What is the end point of Route1? SQL> SELECT SDO_LRS.GEOM_SEGMENT_END_PT(route_geometry) 2 FROM lrs_routes WHERE route_id = 1; SDO_LRS.GEOM_SEGMENT_END_PT(ROUTE_GEOMETRY)(SDO_GTYPE, SDO_SRID, SDO_POINT(X, Y, -------------------------------------------------------------------------------- SDO_GEOMETRY(3301, NULL, NULL, SDO_ELEM_INFO_ARRAY(1, 1, 1), SDO_ORDINATE_ARRAY( 5, 14, 27)) SQL> -- Translate (shift measure values) (+10). SQL> -- First, display the original segment; then, translate. SQL> SELECT a.route_geometry FROM lrs_routes a WHERE a.route_id = 1; ROUTE_GEOMETRY(SDO_GTYPE, SDO_SRID, SDO_POINT(X, Y, Z), SDO_ELEM_INFO, SDO_ORDIN -------------------------------------------------------------------------------- SDO_GEOMETRY(3302, NULL, NULL, SDO_ELEM_INFO_ARRAY(1, 2, 1), SDO_ORDINATE_ARRAY( 2, 2, 0, 2, 4, 2, 8, 4, 8, 12, 4, 12, 12, 10, 18, 8, 10, 22, 5, 14, 27)) SQL> SELECT SDO_LRS.TRANSLATE_MEASURE(a.route_geometry, m.diminfo, 10) 2 FROM lrs_routes a, user_sdo_geom_metadata m 3 WHERE m.table_name = 'LRS_ROUTES' AND m.column_name = 'ROUTE_GEOMETRY' 4 AND a.route_id = 1; SDO_LRS.TRANSLATE_MEASURE(A.ROUTE_GEOMETRY,M.DIMINFO,10)(SDO_GTYPE, SDO_SRID, SD -------------------------------------------------------------------------------- SDO_GEOMETRY(3302, NULL, NULL, SDO_ELEM_INFO_ARRAY(1, 2, 1), SDO_ORDINATE_ARRAY( 2, 2, 10, 2, 4, 12, 8, 4, 18, 12, 4, 22, 12, 10, 28, 8, 10, 32, 5, 14, 37)) SQL> -- Redefine geometric segment to "convert" miles to kilometers SQL> DECLARE 2 geom_segment SDO_GEOMETRY; 3 dim_array SDO_DIM_ARRAY; 4 5 BEGIN 6 7 SELECT a.route_geometry into geom_segment FROM lrs_routes a 8 WHERE a.route_name = 'Route1'; 9 SELECT m.diminfo into dim_array from 10 user_sdo_geom_metadata m 11 WHERE m.table_name = 'LRS_ROUTES' AND m.column_name = 'ROUTE_GEOMETRY'; 12 13 -- "Convert" mile measures to kilometers (27 * 1.609 = 43.443). 14 SDO_LRS.REDEFINE_GEOM_SEGMENT (geom_segment, 15 dim_array, 16 0, -- Zero starting measure: LRS segment starts at start of route. 17 43.443); -- End of LRS segment. 27 miles = 43.443 kilometers. 18 19 -- Update and insert geometries into table, to display later. 20 UPDATE lrs_routes a SET a.route_geometry = geom_segment 21 WHERE a.route_id = 1; 22 23 END; 24 / PL/SQL procedure successfully completed. SQL> -- Display the redefined segment, with all measures "converted." SQL> SELECT a.route_geometry FROM lrs_routes a WHERE a.route_id = 1; ROUTE_GEOMETRY(SDO_GTYPE, SDO_SRID, SDO_POINT(X, Y, Z), SDO_ELEM_INFO, SDO_ORDIN -------------------------------------------------------------------------------- SDO_GEOMETRY(3302, NULL, NULL, SDO_ELEM_INFO_ARRAY(1, 2, 1), SDO_ORDINATE_ARRAY( 2, 2, 0, 2, 4, 3.218, 8, 4, 12.872, 12, 4, 19.308, 12, 10, 28.962, 8, 10, 35.398 , 5, 14, 43.443)) SQL> -- Clip a piece of Route1. SQL> SELECT SDO_LRS.CLIP_GEOM_SEGMENT(route_geometry, 5, 10) 2 FROM lrs_routes WHERE route_id = 1; SDO_LRS.CLIP_GEOM_SEGMENT(ROUTE_GEOMETRY,5,10)(SDO_GTYPE, SDO_SRID, SDO_POINT(X, -------------------------------------------------------------------------------- SDO_GEOMETRY(3302, NULL, NULL, SDO_ELEM_INFO_ARRAY(1, 2, 1), SDO_ORDINATE_ARRAY( 5, 4, 5, 8, 4, 8, 10, 4, 10)) SQL> -- Point (9,3,NULL) is off the road; should return (9,4,9). SQL> SELECT SDO_LRS.PROJECT_PT(route_geometry, 2 SDO_GEOMETRY(3301, NULL, NULL, 3 SDO_ELEM_INFO_ARRAY(1, 1, 1), 4 SDO_ORDINATE_ARRAY(9, 3, NULL)) ) 5 FROM lrs_routes WHERE route_id = 1; SDO_LRS.PROJECT_PT(ROUTE_GEOMETRY,SDO_GEOMETRY(3301,NULL,NULL,SDO_EL -------------------------------------------------------------------------------- SDO_GEOMETRY(3301, NULL, NULL, SDO_ELEM_INFO_ARRAY(1, 1, 1), SDO_ORDINATE_ARRAY( 9, 4, 9)) SQL> -- Return the measure of the projected point. SQL> SELECT SDO_LRS.GET_MEASURE( 2 SDO_LRS.PROJECT_PT(a.route_geometry, m.diminfo, 3 SDO_GEOMETRY(3301, NULL, NULL, 4 SDO_ELEM_INFO_ARRAY(1, 1, 1), 5 SDO_ORDINATE_ARRAY(9, 3, NULL)) ), 6 m.diminfo ) 7 FROM lrs_routes a, user_sdo_geom_metadata m 8 WHERE m.table_name = 'LRS_ROUTES' AND m.column_name = 'ROUTE_GEOMETRY' 9 AND a.route_id = 1; SDO_LRS.GET_MEASURE(SDO_LRS.PROJECT_PT(A.ROUTE_GEOMETRY,M.DIMINFO,SDO_GEOM -------------------------------------------------------------------------------- 9 SQL> -- Is point (9,3,NULL) a valid LRS point? (Should return TRUE.) SQL> SELECT SDO_LRS.VALID_LRS_PT( 2 SDO_GEOMETRY(3301, NULL, NULL, 3 SDO_ELEM_INFO_ARRAY(1, 1, 1), 4 SDO_ORDINATE_ARRAY(9, 3, NULL)), 5 m.diminfo) 6 FROM lrs_routes a, user_sdo_geom_metadata m 7 WHERE m.table_name = 'LRS_ROUTES' AND m.column_name = 'ROUTE_GEOMETRY' 8 AND a.route_id = 1; SDO_LRS.VALID_LRS_PT(SDO_GEOMETRY(3301,NULL,NULL,SDO_ELEM_INFO_ARRAY ------------------------------------------------------------------------------ TRUE SQL> -- Locate the point on Route1 at measure 9, offset 0. SQL> SELECT SDO_LRS.LOCATE_PT(route_geometry, 9, 0) 2 FROM lrs_routes WHERE route_id = 1; SDO_LRS.LOCATE_PT(ROUTE_GEOMETRY,9,0)(SDO_GTYPE, SDO_SRID, SDO_POINT(X, Y, Z), S -------------------------------------------------------------------------------- SDO_GEOMETRY(3301, NULL, NULL, SDO_ELEM_INFO_ARRAY(1, 1, 1), SDO_ORDINATE_ARRAY( 9, 4, 9))B*@ ,ʋʙ;/ξ 9(C#( $G!Dd!AG0 $pPAH ͙ ه~u ($h("0.<#R `?1x`I@tILf09e@^iDIȧH hVX%r?A!` "Ҏ!Me2rt^`s"@!`I '@Ω $JHmxӛ2: AA" URB01x3Ț, DTJPb cD2%"D[Xi"FJ0~BC@C3&:._dObNLm#C1/:$ `Mh*FH w|eP1c LոՄ(A?K$"mK= na$)x";ͥ" 98p8(Ŵ.~QTb dH!\1#2e'DB]#-@!kHiL~&Ni(?9Z|F\RQD![x25N}A\{^H CCD#dʒG5$H Lѓ/{cl%' qZD= pЃXL@P/4%1%b a6Y΅qWk"(w P9!$$ 4NbD-&+{3I7ռ&ix5vHP2}M k!|PleQ7L5N9S_zXi3$@\ "GVF< AmJ_9Ɩ(0!ӧ@vHqf!~ F3(mЭ 3ڱkT0*$E:CZ^Q<<td39 sK}dVq8M`K8HzᦂO5 `z&C8|'+N-v%^=Ep5> F- P.ΣQMpAb[f + ªJO94 v P5% mN.&JNz`P[k p@*:}煰P1 g0u,m4;=|09h:g<%JS\$ q@ 귓;B`W|.S3&.@-jʦnZPhXQ>~bSܷ@SmHx"$+C5$ 0`#P UX b~V`>BKU0k7-PrѠ*p>N6jW!Op=#no!TNE`be!M_ z#|nf2g`pEOPb.?:Lajz_7Dӧ@33˰g,Xa3V nZĩ~X@K*)F Jr$A>}hӽ]]&L):zDa (CZ|;me0@P:XL" S5n%>KQ'&8h@&8x 0( ֶ}!vnGKh(P'6TGTQTd#.A肎,XJP`Q8gТeFոSh#ǣ( %-ݠ1=T2Ԇ9hP juz<`ӥ%"p",A@# -9(Prb0K}"" (`@)H|`M5$Gb( Tn#Anp@$qD@^хA#F 8$xт) pa \\@$$ feΥF P%EEfH q ̵(78 40Bڶ0nt|f-ڋsr89lH?qĠ 9HqCqir'C +r*C md+L)@;sϨd@Ltѧ PAUtN? uCROMuV_uZou^ vbMvfvjvn wrMwvߍwzw~ xN8ԁ;PKNPKlUIOEBPS/sdo_aggr.htmQx Spatial Aggregate Functions PK݄&QQPKlUIOEBPS/query_window.gifGIF89a???yyy<<<Ã̤ر"""ٝfffCCCXXX&&&YYYjjjnnn>>>ddd%%%DDD...GGG;;;{{{ssswww!!!HHHbbbvvvKKKrrrPPPTTT222LLL---\\\]]]UUUaaa777iii***$$$MMMQQQqqq444'''˪mmm333888 )))000}}}@@@eee,,,uuuEEEhhhIII###+++AAA```,@ (xpaB *qC/Rh1ǎ +8rɄ\ɲ˗0cʜI͛-?S'ɟ'} 'ѡ;$0iPJJիXjɴ逧[ÊKٳRxmJ۷7KZm;W/߿_vmo[ #^7+3U%c[2ϠCӨS}Yk_flٔoFM۴ݡuسKO03NloճkKvȿe3x+Vaw?_>yzt_Va JXFᄽe!v^(j⇏vhT) } @4$5ިd\]\M-VyZwlYEZR&w]RE&Q^FdXYfeY4YY条XxnD'hĈ1٧{U{VNJ(fghӖf5j2j&&Yfi]k2hڊ \tB+*l˺T{WҤ+KnjPNV]חckWR[U:%Zo{@4kUlVuaV͒[յZ | 3%oZ6DrO%a GV*SZ|vtT5E]r5QX0v\V,=횝3#jSrL㚊ض2NF}99xOmBy` tT[Wo1)_~i^Ŷ @@JH@X1]pek$ @|zrepAl$$P "06q9p(H p\f{Z VP-(a.mX`t3BЂ 2AiD7h lPT 8'D @]+ʀ=q HЦ(%;@ !AX!܇@CH #l@## 12 Spatial Aggregate Functions

This chapter contains reference and usage information for the spatial aggregate functions, which are listed in Table 12-1.

Table 12-1 Spatial Aggregate Functions

Method Description Returns a geometry object that is the centroid ("center of gravity") of the specified geometry objects.

Returns a geometry that concatenates the specified line or multiline geometries.

Returns a geometry object that is the convex hull of the specified geometry objects.

Returns an LRS geometry object that concatenates specified LRS geometry objects.

Returns the minimum bounding rectangle of the specified geometries.

Returns a geometry object that is the topological union (OR operation) of the specified geometry objects.

See the usage information about spatial aggregate functions in Section 1.10.

Most of these aggregate functions accept a parameter of type SDOAGGRTYPE, which is described in Section 1.10.1.

## SDO_AGGR_CENTROID

Format

SDO_AGGR_CENTROID(

AggregateGeometry SDOAGGRTYPE

) RETURN SDO_GEOMETRY;

Description

Returns a geometry object that is the centroid ("center of gravity") of the specified geometry objects.

Parameters

- AggregateGeometry
An object of type SDOAGGRTYPE (see Section 1.10.1) that specifies the geometry column and dimensional array.

Usage Notes

The behavior of the function depends on whether the geometry objects are all polygons, all points, or a mixture of polygons and points:

If the geometry objects are all polygons, the centroid of all the objects is returned.

If the geometry objects are all points, the centroid of all the objects is returned.

If the geometry objects are a mixture of polygons and points (specifically, if they include at least one polygon and at least one point), any points are ignored, and the centroid of all the polygons is returned.

The result is weighted by the area of each polygon in the geometry objects. If the geometry objects are a mixture of polygons and points, the points are not used in the calculation of the centroid. If the geometry objects are all points, the points have equal weight.

See also the information about the SDO_GEOM.SDO_CENTROID function in Chapter 15.

Examples

The following example returns the centroid of the geometry objects in the COLA_MARKETS table. (The example uses the definitions and data from Section 2.1.)

SELECT SDO_AGGR_CENTROID(SDOAGGRTYPE(shape, 0.005)) FROM cola_markets; SDO_AGGR_CENTROID(SDOAGGRTYPE(SHAPE,0.005))(SDO_GTYPE, SDO_SRID, SDO_POINT -------------------------------------------------------------------------------- SDO_GEOMETRY(2001, NULL, SDO_POINT_TYPE(5.21295938, 5.00744233, NULL), NULL, NUL L)

## SDO_AGGR_CONCAT_LINES

Format

SDO_AGGR_CONCAT_LINES(

geom SDO_GEOMETRY

) RETURN SDO_GEOMETRY;

Description

Returns a geometry that concatenates the specified line or multiline geometries.

Parameters

- geom
Geometry objects.

Usage Notes

Each input geometry must be a two-dimensional line or multiline geometry (that is, the SDO_GTYPE value must be 2002 or 2006). This function is not supported for LRS geometries. To perform an aggregate concatenation of LRS geometric segments, use the SDO_AGGR_LRS_CONCAT spatial aggregate function.

The input geometries must be line strings whose vertices are connected by straight line segments. Circular arcs and compound line strings are not supported.

If any input geometry is a multiline geometry, the elements of the geometry must be disjoint. If they are not disjoint, this function may return incorrect results.

The topological relationship between the geometries in each pair of geometries to be concatenated must be DISJOINT or TOUCH; and if the relationship is TOUCH, the geometries must intersect only at two end points.

You can use the SDO_UTIL.CONCAT_LINES function (described in Chapter 20) to concatenate two line or multiline geometries.

An exception is raised if any input geometries are not line or multiline geometries, or if not all input geometries are based on the same coordinate system.

Examples

The following example inserts two line geometries in the COLA_MARKETS table, and then returns the aggregate concatenation of these geometries. (The example uses the data definitions from Section 2.1.)

-- First, insert two line geometries. INSERT INTO cola_markets VALUES(1001, 'line_1', SDO_GEOMETRY(2002, NULL, NULL, SDO_ELEM_INFO_ARRAY(1,2,1), SDO_ORDINATE_ARRAY(1,1, 5,1))); INSERT INTO cola_markets VALUES(1002, 'line_2', SDO_GEOMETRY(2002, NULL, NULL, SDO_ELEM_INFO_ARRAY(1,2,1), SDO_ORDINATE_ARRAY(5,1, 8,1))); -- Perform aggregate concatenation of all line geometries in layer. SELECT SDO_AGGR_CONCAT_LINES(c.shape) FROM cola_markets c WHERE c.mkt_id > 1000; SDO_AGGR_CONCAT_LINES(C.SHAPE)(SDO_GTYPE, SDO_SRID, SDO_POINT(X, Y, Z), SDO_ELEM -------------------------------------------------------------------------------- SDO_GEOMETRY(2002, NULL, NULL, SDO_ELEM_INFO_ARRAY(1, 2, 1), SDO_ORDINATE_ARRAY( 1, 1, 5, 1, 8, 1))

## SDO_AGGR_CONVEXHULL

Format

SDO_AGGR_CONVEXHULL(

AggregateGeometry SDOAGGRTYPE

) RETURN SDO_GEOMETRY;

Description

Returns a geometry object that is the convex hull of the specified geometry objects.

Parameters

- AggregateGeometry
An object of type SDOAGGRTYPE (see Section 1.10.1) that specifies the geometry column and dimensional array.

Usage Notes

See also the information about the SDO_GEOM.SDO_CONVEXHULL function in Chapter 15.

Examples

The following example returns the convex hull of the geometry objects in the COLA_MARKETS table. (The example uses the definitions and data from Section 2.1.)

SELECT SDO_AGGR_CONVEXHULL(SDOAGGRTYPE(shape, 0.005)) FROM cola_markets; SDO_AGGR_CONVEXHULL(SDOAGGRTYPE(SHAPE,0.005))(SDO_GTYPE, SDO_SRID, SDO_POI -------------------------------------------------------------------------------- SDO_GEOMETRY(2003, NULL, NULL, SDO_ELEM_INFO_ARRAY(1, 1003, 1), SDO_ORDINATE_ARR AY(8, 1, 10, 7, 10, 11, 8, 11, 6, 11, 1, 7, 1, 1, 8, 1))

## SDO_AGGR_LRS_CONCAT

Format

SDO_AGGR_LRS_CONCAT(

AggregateGeometry SDOAGGRTYPE

) RETURN SDO_GEOMETRY;

Description

Returns an LRS geometry that concatenates specified LRS geometries.

Parameters

- AggregateGeometry
An object of type SDOAGGRTYPE (see Section 1.10.1) that specifies the geometry column and dimensional array.

Usage Notes

This function performs an aggregate concatenation of any number of LRS geometries. If you want to control the order in which the geometries are concatenated, you must use a subquery with the NO_MERGE optimizer hint and the ORDER BY clause. (See the examples.)

The direction of the resulting segment is the same as the direction of the first geometry in the concatenation.

A 3D format of this function (SDO_AGGR_LRS_CONCAT_3D) is available. For information about 3D formats of LRS functions, see Section 7.4.)

For information about the Spatial linear referencing system, see Chapter 7.

Examples

The following example adds an LRS geometry to the LRS_ROUTES table, and then performs two queries that concatenate the LRS geometries in the table. The first query does not control the order of concatenation, and the second query controls the order of concatenation. Notice the difference in direction of the two segments: the segment resulting from the second query has decreasing measure values because the first segment in the concatenation (

`Route0`

) has decreasing measure values. (This example uses the definitions from the example in Section 7.7.)-- Add a segment with route_id less than 1 (here, zero). INSERT INTO lrs_routes VALUES( 0, 'Route0', SDO_GEOMETRY( 3302, -- Line string; 3 dimensions (X,Y,M); 3rd is measure dimension. NULL, NULL, SDO_ELEM_INFO_ARRAY(1,2,1), -- One line string, straight segments SDO_ORDINATE_ARRAY( 5,14,5, -- Starting point - 5 is measure from start. 10,14,0) -- Ending point - 0 measure (decreasing measure) ) ); 1 row created. -- Concatenate all routes (no ordering specified). SELECT SDO_AGGR_LRS_CONCAT(SDOAGGRTYPE(route_geometry, 0.005)) FROM lrs_routes; SDO_AGGR_LRS_CONCAT(SDOAGGRTYPE(ROUTE_GEOMETRY,0.005))(SDO_GTYPE, SDO_SRID -------------------------------------------------------------------------------- SDO_GEOMETRY(3302, NULL, NULL, SDO_ELEM_INFO_ARRAY(1, 2, 1), SDO_ORDINATE_ARRAY( 2, 2, 0, 2, 4, 2, 8, 4, 8, 12, 4, 12, 12, 10, 18, 8, 10, 22, 5, 14, 27, 10, 14, 32)) -- Aggregate concatenation using subquery for ordering. SELECT SDO_AGGR_LRS_CONCAT(SDOAGGRTYPE(route_geometry, 0.005)) FROM ( SELECT /*+ NO_MERGE */ route_geometry FROM lrs_routes ORDER BY route_id); SDO_AGGR_LRS_CONCAT(SDOAGGRTYPE(ROUTE_GEOMETRY,0.005))(SDO_GTYPE, SDO_SRID -------------------------------------------------------------------------------- SDO_GEOMETRY(3302, NULL, NULL, SDO_ELEM_INFO_ARRAY(1, 2, 1), SDO_ORDINATE_ARRAY( 2, 2, 32, 2, 4, 30, 8, 4, 24, 12, 4, 20, 12, 10, 14, 8, 10, 10, 5, 14, 5, 10, 14 , 0))

## SDO_AGGR_MBR

Format

SDO_AGGR_MBR(

geom SDO_GEOMETRY

) RETURN SDO_GEOMETRY;

Description

Returns the minimum bounding rectangle (MBR) of the specified geometries, that is, a single rectangle that minimally encloses the geometries.

Parameters

- geom
Geometry objects.

Usage Notes

All input geometries must have 4-digit SDO_GTYPE values (explained in Section 2.2.1).

This function does not return an MBR geometry if a proper MBR cannot be constructed. Specifically:

If the input geometries are all null, the function returns a null geometry.

If all data in the input geometries is on a single point, the function returns the point.

If all data in the input geometries consists of points on a straight line, the function returns a two-point line.

The SDO_TUNE.EXTENT_OF function, documented in Chapter 19, also returns the MBR of geometries. The SDO_TUNE.EXTENT_OF function has better performance than the SDO_AGGR_MBR function if the data is non-geodetic and if a spatial index is defined on the geometry column; however, the SDO_TUNE.EXTENT_OF function is limited to two-dimensional geometries, whereas the SDO_AGGR_MBR function is not. In addition, the SDO_TUNE.EXTENT_OF function computes the extent for all geometries in a table; by contrast, the SDO_AGGR_MBR function can operate on subsets of rows.

Examples

The following example returns the minimum bounding rectangle of the geometry objects in the COLA_MARKETS table. (The example uses the definitions and data from Section 2.1.)

SELECT SDO_AGGR_MBR(shape) FROM cola_markets; SDO_AGGR_MBR(C.SHAPE)(SDO_GTYPE, SDO_SRID, SDO_POINT(X, Y, Z), SDO_ELEM_INFO, SD -------------------------------------------------------------------------------- SDO_GEOMETRY(2003, NULL, NULL, SDO_ELEM_INFO_ARRAY(1, 1003, 3), SDO_ORDINATE_ARR AY(1, 1, 10, 11))

## SDO_AGGR_UNION

Format

SDO_AGGR_UNION(

AggregateGeometry SDOAGGRTYPE

) RETURN SDO_GEOMETRY;

Description

Returns a geometry object that is the topological union (OR operation) of the specified geometry objects.

Parameters

- AggregateGeometry
Usage Notes

Do not use SDO_AGGR_UNION to merge line string or multiline string geometries; instead, use the SDO_AGGR_CONCAT_LINES spatial aggregate function.

See also the information about the SDO_GEOM.SDO_UNION function in Chapter 15.

Examples

The following example returns the union of the first three geometry objects in the COLA_MARKETS table (that is, all except

`cola_d`

). (The example uses the definitions and data from Section 2.1.)SELECT SDO_AGGR_UNION( SDOAGGRTYPE(c.shape, 0.005)) FROM cola_markets c WHERE c.name < 'cola_d'; SDO_AGGR_UNION(SDOAGGRTYPE(C.SHAPE,0.005))(SDO_GTYPE, SDO_SRID, SDO_POINT( -------------------------------------------------------------------------------- SDO_GEOMETRY(2007, NULL, NULL, SDO_ELEM_INFO_ARRAY(1, 1003, 2, 11, 1003, 1), SDO _ORDINATE_ARRAY(8, 11, 6, 9, 8, 7, 10, 9, 8, 11, 1, 7, 1, 1, 5, 1, 8, 1, 8, 6, 5 , 7, 1, 7))See also the more complex SDO_AGGR_UNION example in Section D.4.

+gK׳|kh-RZ4eKm[uKq+;]``L:W82UIfr51724)nUp |mLB`řTvAvXY] CM0Y--2^*'X *i=jb^Vng>JO_lF|Um47ヿNu}XNK^WNuq}?,bEYG !@R 3v(^Zpgo.z(|`GU{|SD%1vlo+z2_U @5^AgAy2w~B\AN$DNYx4S7b+ah6Å照kX2i8Ն²twx(`CAu8|ǇW@U/w+XȈ7=d%؈}t_jA^$ԅoXyշv+6gt5wsrP:`Q&I~aPT4xjxbX80:/Z[PHS[f)-npǌ4vm1:c@P0cPNp6K0k0pk7hQg,w4"8pG]hg(rD w)P">yBy0x/WNs,v"! \Y[G/03v0ooitb1\rPgy4u.HLaa0WBtHi0_ߒ 0 9 @Qk 1C Bx%M9uG4ɗB peP ` mК;Y2@x98xy؎X}@,RHw0s I 3 _ٛ5)[ {P{8tCC_ y#iy i6o7cPd8wo ڡy9|2B`8n<9@ICY sJɔf ~7- 4@TPawWod$`f\jYlyn GI0.i5Ö1:P0x4xWc4z9g t39qJz`8Z7Asp4,ڧڛzJBE5ƚ Id`BR7e8y%6ws$SsڪZi%j`DI`詞qq*7zri.!8KʪaZzzcFhc,1pjB *oŨ?A*7:ʣ> 8.QsrK؆*yӥ_zY)!&鯽X7*Ȩ2Wt҇V` yL '`Ӊ4ƺr僪A5+=1G|ٲ,XB;r5*Ź<ˈ?}PKRK-3`k/z1k8]貈aaˡiYJy9g:[;H0.!Ǚ#ǡizJ1stK2#$F+{Y멼eh+_$%h˸Fx73q4U+~`O):غ*Cek+B;k]G@+6Qv˝bHخkW돞S :tW2ۏim'};s6Ȃ!G%۷4ZSK]ED4;pvxePQ p6lkznscw-.|00}v*tڴɨ`<8N>U(K;~3'I$L|zD\%'§Bl$xG ƴ%\5;1Ƣp|},YtBɂLMw26.Wbů'#Z٢Hmq3ȜhMcĪfI}!7gz阑)i;sE+I&Y-YPC @Pk6:y-ڞɩZ2Sv/}4zht j߶!;ڣ?JwA W+{.7A}}~`w7 NtZl~,Dmq-4^'+>*:$SW}HoCN\^`GZ^\f]c;PK @ PKlUIOEBPS/sdo_objindex.htm SQL Statements for Indexing Spatial Data PK;G[{PKlUIOEBPS/spatial_mining.gif&'GIF89aXPPPYYYfff;;;]]]***퐐"""333bbbLLL...sssCCC܈777???GGG!!!UUUTTTĮHHHٌnnn%%%222:::&&&{{{DDDjjj黻SSSvvv˿ooowwwXXXeeeaaarrr\\\666)))ф iiiKKK---xxxzzz```^^^澾,X ͚ ƂȾމٹ8d:`p`@ A#q`@e$ ~x(Id8q)T ѣVpŢp8bx!s]ͺMpp3۠3@ E)S ǐ DR 5l4ᐟ$S%!^8pA[qC;Aۮ`a-~emwN.Fp\m/]!DL""`cַW~L## 10 SQL Statements for Indexing Spatial Data

This chapter describes the SQL statements used when working with the spatial object data type. The statements are listed in Table 10-1.

Table 10-1 Spatial Index Creation and Usage Statements

Statement Description Alters specific parameters for a spatial index.

Rebuilds a spatial index or a specified partition of a partitioned index.

Changes the name of a spatial index or a partition of a spatial index.

Creates a spatial index on a column of type SDO_GEOMETRY.

Deletes a spatial index.

This chapter focuses on using these SQL statements with spatial indexes. For complete reference information about any statement, see Oracle Database SQL Reference.

Bold italic text is often used in the Keywords and Parameters sections in this chapter to identify a grouping of keywords, followed by specific keywords in the group. For example, INDEX_PARAMS identifies the start of a group of index-related keywords.

## ALTER INDEX

Purpose

Alters specific parameters for a spatial index.

Syntax

ALTER INDEX [schema.]index PARAMETERS ('index_params [physical_storage_params]' )

[{ NOPARALLEL | PARALLEL [ integer ] }] ;

Keywords and Parameters

Value Description INDEX_PARAMS Changes the characteristics of the spatial index. sdo_indx_dims Specifies the number of dimensions to be indexed. For example, a value of 2 causes the first two dimensions to be indexed. Must be less than or equal to the number of actual dimensions (number of SDO_DIM_ELEMENT instances in the dimensional array that describes the geometry objects in the column). If the value is 3 or higher, the only Spatial operator that can be used on the indexed geometries is SDO_FILTER; the other operators described in Chapter 11 cannot be used. Data type is NUMBER. Default = 2. sdo_rtr_pctfree Specifies the minimum percentage of slots in each index tree node to be left empty when the index is created. Slots that are left empty can be filled later when new data is inserted into the table. The value can range from 0 to 50. The default value is best for most applications; however, a value of 0 is recommended if no updates will be performed to the geometry column. Data type is NUMBER. Default = 10. PHYSICAL_STORAGE_PARAMS Determines the storage parameters used for altering the spatial index data table. A spatial index data table is a standard Oracle table with a prescribed format. Not all physical storage parameters that are allowed in the STORAGE clause of a CREATE TABLE statement are supported. The following is a list of the supported subset. tablespace Specifies the tablespace in which the index data table is created. This parameter is the same as TABLESPACE in the STORAGE clause of a CREATE TABLE statement. initial Is the same as INITIAL in the STORAGE clause of a CREATE TABLE statement. next Is the same as NEXT in the STORAGE clause of a CREATE TABLE statement. minextents Is the same as MINEXTENTS in the STORAGE clause of a CREATE TABLE statement. maxextents Is the same as MAXEXTENTS in the STORAGE clause of a CREATE TABLE statement. pctincrease Is the same as PCTINCREASE in the STORAGE clause of a CREATE TABLE statement. { NOPARALLEL | PARALLEL [ integer ] } Controls whether serial (NOPARALLEL) execution or parallel (PARALLEL) execution is used for subsequent queries and DML operations that use the index. For parallel execution you can specify an integer value of degree of parallelism. See the Usage Notes for the CREATE INDEX statement for guidelines and restrictions that apply to the use of the PARALLEL keyword. Default = NOPARALLEL. (If PARALLEL is specified without an integer value, the Oracle database calculates the optimum degree of parallelism.) Prerequisites

You must have EXECUTE privileges on the index type and its implementation type.

The spatial index to be altered is not marked in-progress.

Usage Notes

Use this statement to change the parameters of an existing index.

See the Usage Notes for the CREATE INDEX statement for usage information about many of the other available parameters.

Examples

The following example modifies the tablespace for partition IP2 of the spatial index named BGI.

ALTER INDEX bgi MODIFY PARTITION ip2 PARAMETERS ('tablespace=TBS_3');Related Topics

ALTER TABLE (clauses for partition maintenance) in Oracle Database SQL Reference

## ALTER INDEX REBUILD

Syntax

ALTER INDEX [schema.]index REBUILD

[PARAMETERS ('rebuild_params [physical_storage_params]' ) ]

[{ NOPARALLEL | PARALLEL [ integer ] }] ;

or

ALTER INDEX [schema.]index REBUILD ONLINE

[PARAMETERS ('rebuild_params [physical_storage_params]' ) ]

[{ NOPARALLEL | PARALLEL [ integer ] }] ;

or

ALTER INDEX [schema.]index REBUILD PARTITION partition

[PARAMETERS ('rebuild_params [physical_storage_params]' ) ];

Purpose

Rebuilds a spatial index or a specified partition of a partitioned index.

Keywords and Parameters

Value Description REBUILD_PARAMS Specifies in a command string the index parameters to use in rebuilding the spatial index. index_status=cleanup For an online rebuild operation (ALTER INDEX REBUILD ONLINE), performs cleanup operations on tables associated with the older version of the index. layer_gtype Checks to ensure that all geometries are of a specified geometry type. The value must be from the Geometry Type column of Table 2-1 in Section 2.2.1 (except that UNKNOWN_GEOMETRY is not allowed). In addition, specifying POINT allows for optimized processing of point data. Data type is VARCHAR2. sdo_dml_batch_size Specifies the number of index updates to be processed in each batch of updates after a commit operation. The default value is 1000. For example, if you insert 3500 rows into the spatial table and then perform a commit operation, the updates to the spatial index table are performed in four batches of insert operations (1000, 1000, 1000, and 500). See the Usage Notes for the CREATE INDEX statement for more information. Data type is NUMBER. Default = 1000. sdo_indx_dims Specifies the number of dimensions to be indexed. For example, a value of 2 causes the first two dimensions to be indexed. Must be less than or equal to the number of actual dimensions (number of SDO_DIM_ELEMENT instances in the dimensional array that describes the geometry objects in the column). If the value is 3 or higher, the only Spatial operator that can be used on the indexed geometries is SDO_FILTER; the other operators described in Chapter 11 cannot be used. Data type is NUMBER. Default = 2. sdo_rtr_pctfree Specifies the minimum percentage of slots in each index tree node to be left empty when the index is created. Slots that are left empty can be filled later when new data is inserted into the table. The value can range from 0 to 50. Data type is NUMBER. Default = 10. PHYSICAL_STORAGE_PARAMS Determines the storage parameters used for rebuilding the spatial index data table. A spatial index data table is a regular Oracle table with a prescribed format. Not all physical storage parameters that are allowed in the STORAGE clause of a CREATE TABLE statement are supported. The following is a list of the supported subset. tablespace Specifies the tablespace in which the index data table is created. Same as TABLESPACE in the STORAGE clause of a CREATE TABLE statement. initial Is the same as INITIAL in the STORAGE clause of a CREATE TABLE statement. next Is the same as NEXT in the STORAGE clause of a CREATE TABLE statement. minextents Is the same as MINEXTENTS in the STORAGE clause of a CREATE TABLE statement. maxextents Is the same as MAXEXTENTS in the STORAGE clause of a CREATE TABLE statement. pctincrease Is the same as PCTINCREASE in the STORAGE clause of a CREATE TABLE statement. { NOPARALLEL | PARALLEL [ integer ] } Controls whether serial (NOPARALLEL) execution or parallel (PARALLEL) execution is used for the rebuilding of the index and for subsequent queries and DML operations that use the index. For parallel execution you can specify an integer value of degree of parallelism. See the Usage Notes for the CREATE INDEX statement for guidelines and restrictions that apply to the use of the PARALLEL keyword. Default = NOPARALLEL. (If PARALLEL is specified without an integer value, the Oracle database calculates the optimum degree of parallelism.) Prerequisites

You must have EXECUTE privileges on the index type and its implementation type.

The spatial index to be altered is not marked in-progress.

Usage Notes

An ALTER INDEX REBUILD 'rebuild_params' statement rebuilds the index using supplied parameters. Spatial index creation involves creating and inserting index data, for each row in the underlying table column being spatially indexed, into a table with a prescribed format. All rows in the underlying table are processed before the insertion of index data is committed, and this requires adequate rollback segment space.

The ONLINE keyword rebuilds the index without blocking the index; that is, queries can use the spatial index while it is being rebuilt. However, after all queries issued during the rebuild operation have completed, you must clean up the old index information (in the MDRT tables) by entering a SQL statement in the following form:

ALTER INDEX [schema.]index REBUILD ONLINE PARAMETERS ('index_status=cleanup');The following limitations apply to the use of the ONLINE keyword:

Only query operations are permitted while the index is being rebuilt. Insert, update, and delete operations that would affect the index are blocked while the index is being rebuilt.

You cannot use the ONLINE keyword for a rebuild operation if the index was created using the

`'sdo_non_leaf_tbl=TRUE'`

parameter.You cannot use the ONLINE keyword for a partitioned spatial index.

The ALTER INDEX REBUILD statement does not use any previous parameters from the index creation. All parameters should be specified for the index you want to rebuild.

For more information about using the

`layer_gtype`

keyword to constrain data in a layer to a geometry type, see Section 4.1.2.With a partitioned spatial index, you must use a separate ALTER INDEX REBUILD statement for each partition to be rebuilt.

See also the Usage Notes for the CREATE INDEX statement for usage information about many of the available parameters and about the use of the PARALLEL keyword.

Examples

The following example rebuilds OLDINDEX and specifies the tablespace in which to create the index data table.

ALTER INDEX oldindex REBUILD PARAMETERS('tablespace=TBS_3');Related Topics

ALTER TABLE and ALTER INDEX (clauses for partition maintenance) in Oracle Database SQL Reference

## ALTER INDEX RENAME TO

Syntax

ALTER INDEX [schema.]index RENAME TO <new_index_name>;

ALTER INDEX [schema.]index PARTITION partition RENAME TO <new_partition_name>;

Purpose

Changes the name of a spatial index or a partition of a spatial index.

Keywords and Parameters

Value Description new_index_name Specifies the new name of the index. new_partition_name Specifies the new name of the partition. Prerequisites

You must have EXECUTE privileges on the index type and its implementation type.

The spatial index to be altered is not marked in-progress.

Usage Notes

None.

Examples

The following example renames OLDINDEX to NEWINDEX.

ALTER INDEX oldindex RENAME TO newindex;Related Topics

## CREATE INDEX

Syntax

CREATE INDEX [schema.]index ON [schema.]table (column)

INDEXTYPE IS MDSYS.SPATIAL_INDEX

[PARAMETERS ('index_params [physical_storage_params]' )]

[{ NOPARALLEL | PARALLEL [ integer ] }];

Purpose

Creates a spatial index on a column of type SDO_GEOMETRY.

Keywords and Parameters

Value Description INDEX_PARAMS Determines the characteristics of the spatial index. geodetic `'geodetic=FALSE'`

allows a non-geodetic index to be built on geodetic data, but with restrictions. (FALSE is the only acceptable value for this keyword.) See the Usage Notes for more information. Data type is VARCHAR2.layer_gtype Checks to ensure that all geometries are of a specified geometry type. The value must be from the Geometry Type column of Table 2-1 in Section 2.2.1 (except that UNKNOWN_GEOMETRY is not allowed). In addition, specifying POINT allows for optimized processing of point data. Data type is VARCHAR2. sdo_dml_batch_size Specifies the number of index updates to be processed in each batch of updates after a commit operation. The default value is 1000. For example, if you insert 3500 rows into the spatial table and then perform a commit operation, the updates to the spatial index table are performed in four batches of insert operations (1000, 1000, 1000, and 500). See the Usage Notes for more information. Data type is NUMBER. Default = 1000. sdo_indx_dims Specifies the number of dimensions to be indexed. For example, a value of 2 causes the first two dimensions to be indexed. Must be less than or equal to the number of actual dimensions (number of SDO_DIM_ELEMENT instances in the dimensional array that describes the geometry objects in the column). If the value is 3 or higher, the only Spatial operator that can be used on the indexed geometries is SDO_FILTER; the other operators described in Chapter 11 cannot be used. Data type is NUMBER. Default = 2. sdo_non_leaf_tbl `'sdo_non_leaf_tbl=TRUE'`

creates a separate index table (with a name in the form MDNT_...$) for nonleaf nodes of the index, in addition to creating an index table (with a name in the form MDRT_...$) for leaf nodes.`'sdo_non_leaf_tbl=FALSE'`

creates a single table (with a name in the form MDRT_...$) for both leaf nodes and nonleaf nodes of the index. See the Usage Notes for more information. Data type is VARCHAR2. Default = FALSEsdo_rtr_pctfree Specifies the minimum percentage of slots in each index tree node to be left empty when the index is created. Slots that are left empty can be filled later when new data is inserted into the table. The value can range from 0 to 50. Data type is NUMBER. Default = 10. PHYSICAL_STORAGE_PARAMS Determines the storage parameters used for creating the spatial index data table. A spatial index data table is a regular Oracle table with a prescribed format. Not all physical storage parameters that are allowed in the STORAGE clause of a CREATE TABLE statement are supported. The following is a list of the supported subset. tablespace Specifies the tablespace in which the index data table is created. Same as TABLESPACE in the STORAGE clause of a CREATE TABLE statement. initial Is the same as INITIAL in the STORAGE clause of a CREATE TABLE statement. next Is the same as NEXT in the STORAGE clause of a CREATE TABLE statement. minextents Is the same as MINEXTENTS in the STORAGE clause of a CREATE TABLE statement. maxextents Is the same as MAXEXTENTS in the STORAGE clause of a CREATE TABLE statement. pctincrease Is the same as PCTINCREASE in the STORAGE clause of a CREATE TABLE statement. work_tablespace Specifies the tablespace for temporary tables used in creating the index. (Applies only to creating spatial R-tree indexes, and not to other types of indexes.) { NOPARALLEL | PARALLEL [ integer ] } Controls whether serial (NOPARALLEL) execut'Tion or parallel (PARALLEL) execution is used for the creation of the index and for subsequent queries and DML operations that use the index. For parallel execution you can specify an integer value of degree of parallelism. See the Usage Notes for more information about parallel index creation. Default = NOPARALLEL. (If PARALLEL is specified without an integer value, the Oracle database calculates the optimum degree of parallelism.) Prerequisites

All current SQL CREATE INDEX prerequisites apply.

You must have EXECUTE privilege on the index type and its implementation type.

The USER_SDO_GEOM_METADATA view must contain an entry with the dimensions and coordinate boundary information for the table column to be spatially indexed.

Usage Notes

For information about spatial indexes, see Section 1.7.

Before you create a spatial index, be sure that the rollback segment size and the SORT_AREA_SIZE parameter value are adequate, as described in Section 4.1.

If an R-tree index is used on linear referencing system (LRS) data and if the LRS data has four dimensions (three plus the M dimension), the

`sdo_indx_dims`

parameter must be used and must specify 3 (the number of dimensions minus one), to avoid the default`sdo_indx_dims`

value of 2, which would index only the X and Y dimensions. For example, if the dimensions are X, Y, Z, and M, specify`sdo_indx_dims=3`

to index the X, Y, and Z dimensions, but not the measure (M) dimension. (The LRS data model, including the measure dimension, is explained in Section 7.2.)A partitioned spatial index can be created on a partitioned table. See Section 4.1.4 for more information about partitioned spatial indexes, including benefits and restrictions.

A spatial index cannot be created on an index-organized table.

You can specify the PARALLEL keyword to cause the index creation to be parallelized. For example:

CREATE INDEX cola_spatial_idx ON cola_markets(shape) INDEXTYPE IS MDSYS.SPATIAL_INDEX PARALLEL;For information about using the PARALLEL keyword, see the description of the

`parallel_clause`

in the section on the CREATE INDEX statement in Oracle Database SQL Reference. In addition, the following notes apply to the use of the PARALLEL keyword for creating or rebuilding (using the ALTER INDEX REBUILD statement) spatial indexes:

The performance cost and benefits from parallel execution for creating or rebuilding an index depend on system resources and load. If the CPUs or disk controllers are already heavily loaded, you should not specify the PARALLEL keyword.

Specifying PARALLEL for creating or rebuilding an index on tables with simple geometries, such as point data, usually results in less performance improvement than on tables with complex geometries.

Other options available for regular indexes (such as ASC and DESC) are not applicable for spatial indexes.

Spatial index creation involves creating and inserting index data, for each row in the underlying table column being spatially indexed, into a table with a prescribed format. All rows in the underlying table are processed before the insertion of index data is committed, and this requires adequate rollback segment space.

If a tablespace name is provided in the parameters clause, the user (underlying table owner) must have appropriate privileges for that tablespace.

For more information about using the

`layer_gtype`

keyword to constrain data in a layer to a geometry type, see Section 4.1.2.The

`'geodetic=FALSE'`

parameter is not recommended, because much of the Oracle Spatial geodetic support will be disabled. This parameter should only be used if you cannot yet reindex the data. (For more information about geodetic and non-geodetic indexes, see Section 4.1.1.)Moreover, if you specify

`'geodetic=FALSE'`

, ensure that the tolerance value stored in the USER_SDO_GEOM_METADATA view is what would be used for Cartesian data. That is, do not use meters for the units of the tolerance value, but instead use the number of decimal places in the data followed by a 5 (for example, 0.00005). This tolerance value will be used for spatial operators. When you use spatial functions that require a tolerance value with this data, use the function format that lets you specify a tolerance value, and specify the tolerance value in meters.The

`sdo_dml_batch_size`

parameter can improve application performance, because Spatial can preallocate system resources to perform multiple index updates more efficiently than successive single index updates; however, to gain the performance benefit, you must not perform commit operations after each insert operation or at intervals less than or equal to the`sdo_dml_batch_size`

value. You should not specify a value greater than 10000 (ten thousand), because the cost of the additional memory and other resources required will probably outweigh any marginal performance increase resulting from such a value.Specifying

`'sdo_non_leaf_tbl=TRUE'`

can help query performance with large data sets if the entire R-tree table may not fit in the KEEP buffer pool. In this case, you must also cause Oracle to buffer the MDNT_...$ table in the KEEP buffer pool, for example, by using ALTER TABLE and specifying STORAGE (BUFFER_POOL KEEP). For partitioned indexes, the same`sdo_non_leaf_tbl`

value must be used for all partitions. Any physical storage parameters, except for`tablespace`

, are applied only to the MDRT_...$ table. The MDNT_...$ table uses only the`tablespace`

parameter, if specified, and default values for all other physical storage parameters.If you are creating a function-based spatial index, the number of parameters must not exceed 32. For information about using function-based spatial indexes, see Section 9.2.

To determine if a CREATE INDEX statement for a spatial index has failed, check to see if the DOMIDX_OPSTATUS column in the USER_INDEXES view is set to FAILED. This is different from the case of regular indexes, where you check to see if the STATUS column in the USER_INDEXES view is set to FAILED.

If the CREATE INDEX statement fails because of an invalid geometry, the ROWID of the failed geometry is returned in an error message along with the reason for the failure.

If the CREATE INDEX statement fails for any reason, then the DROP INDEX statement must be used to clean up the partially built index and associated metadata. If DROP INDEX does not work, add the FORCE parameter and try again.

Examples

The following example creates a spatial R-tree index named COLA_SPATIAL_IDX.

CREATE INDEX cola_spatial_idx ON cola_markets(shape) INDEXTYPE IS MDSYS.SPATIAL_INDEX;Related Topics

## DROP INDEX

Syntax

DROP INDEX [schema.]index [FORCE];

Purpose

Deletes a spatial index.

Keywords and Parameters

Value Description FORCE Causes the spatial index to be deleted from the system tables even if the index is marked in-progress or some other error condition occurs. Prerequisites

You must have EXECUTE privileges on the index type and its implementation type.

Usage Notes

Use DROP INDEX indexname FORCE to clean up after a failure in the CREATE INDEX statement.

Examples

The following example deletes a spatial index named OLDINDEX and forces the deletion to be performed even if the index is marked in-process or an error occurs.

DROP INDEX oldindex FORCE;Related Topics

Dqa.@2,UmG9l@s#dhB(c`iK P(pL@@MP9Meɧ| ¨C>@vbf!18jj̀#*iNs뭸뮝 6gH"r"08!b-#(뷠 0ElRO<e =9P0<2 rl$7bE& D04`# }RXB @)0*$ʖdA2P+!d1hA"!2,VH4 0A,,VBNnwK 0l"`\Я!]v?EC,C!Np`3!CB ] &,Aѵ@^zIbpAx J,@(xPÖa\1.hX7r6~]v`\ĳ(Ё ExF܀ӣ CPlpv. /pG]4-fQ@/PL@xC1g @Q *ui[PA TXB"6N`EB@UzABU C ,Bz]Q !A0Ά҂q@B\Ѻڥ08z8$* P@`o\B2b0`tC\.R%Ǫ9 1.p-=@,cu1C,`T:Bⴄ1$ VqYLxF%/Z3Kn|ߋZVo/k^V55_Q _J"XúIq*|/2E_0!PX?p#L!j*cغx0P.s-i[F6Y k1iPհʸj8!`L@hہuH(A >Hy<}\2T%[_@7o_LiL3!BPJ5@z1B ҵ5G'D1c5! `]4!j1 FrƆ(Ii$ p2N`7'"xYLIO'uQO>Z!@qtsׁu{C <[PԢ)9U+ͷ7^؎W3yrqq[:|]E^[g饅z]źk'L:Wh)J˺pw*aܝj5A;q:w'x*^v?E3e5|EJ^g|S~pmkѓU&łXǃ7`N8Bx|SXP %`G E%H5VXa$>#%=D"eT:hwvz ǄUGv|`XsqwmXS` STԷXH' X rT xh~z8 }}X_xT|y N@%PՋ"w8(hߨx(}zǎ莾XX {`ᅆRX)|苿ѐyxG<&6 2bRT+ ˘R3'bpNN(Di,&i9S//P0,V!Z&Vb76 QyN: |(2"C2r0i 00Io5ňȄ@4F4J4O5peOelLSa lJ,dodjVQs8i/QJ# t9S9p93g#b:g{CbfB,;qfnSS|c02%[YF`hٳ=C>>eii(f0G0L=h#WRؔ?4q5)eBs:y5_/p\ Qv ꠦU~aA jvFBYB Y00SCD(V>vا#9s¹Y::gi::<@&WjpT7>V~BR4Ut8E @qZKmĨ483Ap)BYk=ZaeD(9BCؚ[hXDM'D-p0PipdqMr 'ApoORڑrUTTVHdӶԭgtۧp([ qP (PV$ItQ,嶫o4o\ ݦJJd> =O .P[+] 'wQŰV4TNzwqD'Nǰ-0jk!!obaW;v!^5kՕ-XјTN*~uti𪻲i9xֹTp q~;0[xU ;a/Muc'Ѕ+&Z*ֲP9, bȽE:@12L I & HQQ @,ǝۗ5g +Y l{XG[E* PU&^` 읖G(g8p]5P7BثelyZ)ǚeP,S`jt*zg`@n@gMl4`)/N`y 7<YP٬ͅ+ E :??暪cTr40@P`0!|NJʳǨl͙?}|BB&=YX,.ƘafJkcJR%(Lٽa Ǡ?\q<ν80' EY]\oˮP{/ !T5,F(h0ϋɓPB`nlҽ N @D.Oq4|ͻ$/cSYBC@&C(E-Ԃ< l̈́L5m4B0:nak$mhi> *@QσH 2 89#YkK0j \ `fɛLء~qh{u~eh ؖK ڥۢ{OՊPې]SڮB(Э_ ݩЍX ˑܾ8p,y-͓ bަH_-hzNEvTm~ݸکPߗuL|ڭw|+|`Cwn1Wh:ݻ^~x{(^.`جH-8'ل[-"n`JT6,^BCwTy8_0>-h]n#АK=n൶- n`wݺP lW. %] }QNw簫9n徔x3(}莞9XSHʆP̀GN{Y O|pЅ[r7@;`nyjdZ:Os.RUU(KNUޞ~VuzsXu.R>1RWL"raz^5/P/!"Z9V +OO1컇`'3Q37s5EVJi. `ice@eR*z1~弎V88l;1gfЃ|fB T0`:/pgvxY}s=cCl?$@DVCfBb *?K`ii@II(8o?$AC,C.C/$k<F(:-DLD0l#GtdŁ"T/l0ۺ{ow:HӴ0pKd:K@ .mn&S` 2RRLP8/P00"5PNNGKcNO"G5ѡ"ؾ뎋 ^*dtQÅ=D41ŋ*҈?K=iA(TK+)#FӁm,TPI?-4шEnBSϛyuRU1 2A%P![;R BA (q[pIEl-Pz_iTy^J$qYDb \HC4| @ҧS%YA9P#.J͛ dEWys&IB^ h>%@S85 0 Ban88b)3Rep(p`3P$@ %lB1JS9 !ތ=Y A99VLEL\ U'PSC3 '4c Wniŝ&PDzٍސi4e@#.Ba~v Ԑk2Gp nEdOX@ZÒ< O= /'Kv>xn`D"@!At H^7 (:`ΨO2/` 3uB?PPBP/+T!r8v س"zn` @vа3?A\Ѐ\b8"EVA | bjQ)\h8F`Lx,7M n`d@ tO[Д@)ҀA(e pM|@SC<d:*P\hΨ, U,1 fYKeR+$@&0y(8EeN2i&; J5)Nl zԻeJ; 0R At L yB&]g^C%q ְ,GE P(9_ںB2Q@QgPDEdoT]GH\ve@\rΝ0,)Ak=a|X4"Sg ]i, yw#KL쐉(yVv申|\^603-t.cpL:xsռ扝KMBЈNhB'Mi;+Ҙδ1 ɑqPӣ.P-T_է6uejкƷF kmRHɵ=Mb{[&v}l6bnm0[ڶ l#ںvmqC&ͽt[qHlx+yV>h?ߪԾo{|o+\^vqKMU\O\! rbQ*4_pA\-w93r}l\R ss:;5n~i'̵".c{z.md%9v\2^v}{=m'0ߎldetG'Ae?;~~//6<%<#w7YX1FhA`ӃkWֻ^Ѡ}z;h=wG1n^W >Nyc=!1辳o~ww(}kx~#"/ǫ I>O<~} ~~-$oiCaM'L|}QBzxFs`7/!vvwxhsfP u28H 8msaw,#G Rr礄Y=nT/VXs!X#^3^|W{Qh7usP @ qo7?.\```Їbps0s] 10rf&<0 "=0J@vHh^㈏zFaOmc1&@9x3Ȁ @W0D((%Y(l2#s6aS,PPA<2*@vs?3'Xt`B-s0P!H<2p鸎(X戎 ȍH6/f6:N`#107E5b2P9$pX!Up(XSݷr9f!-B&C6:iCXCI Tqs6`C$MpFc`g+@4I x8MЊOa@5𢠹=B6x$bpC80 tS*EQYyJk T8H.J U鹠.0PӇ`1F3 ~J:ʧFSwi(zg*h6 9T!͒nR -a畫J'f{7ǞVg!]FVP.ʬm88WXokj;n8)I"l&JIȆ@:$#ϡzS*P" ,xp]X L-_(!KK'+˲k;1u9)'uLwj.{P'hDXnhiGz)xiW{HZ;!}_{7f;#g{nZ>yf|AkpAnėڱSX~槅~뱀Gh@9AR6[#qgiV˃xۺ{& ho;kqzwx=5`x w:jkQi˂ƋkF6*ڻka;;PKO&&PKlUIOEBPS/sdo_cs_concepts.htm Coordinate Systems (Spatial Reference Systems) PKJPKlUIOEBPS/sdo_objload.htm)p## 6 Coordinate Systems (Spatial Reference Systems)

This chapter describes in greater detail the Oracle Spatial coordinate system support, which was introduced in Section 1.5.4. You can store and manipulate SDO_GEOMETRY objects in a variety of coordinate systems.

For reference information about coordinate system transformation functions and procedures in the MDSYS.SDO_CS package, see Chapter 13.

This chapter contains the following major sections:

Section 6.8, "Creating a User-Defined Coordinate Reference System"

Section 6.9, "Notes and Restrictions with Coordinate Systems Support"

## 6.1 Terms and Concepts

This section explains important terms and concepts related to coordinate system support in Oracle Spatial.

## 6.1.1 Coordinate System (Spatial Reference System)

A coordinate system (also called a spatial reference system) is a means of assigning coordinates to a location and establishing relationships between sets of such coordinates. It enables the interpretation of a set of coordinates as a representation of a position in a real world space.

The term coordinate reference system has the same meaning as coordinate system for Spatial, and the terms are used interchangeably. European Petroleum Survey Group (EPSG) specifications and documentation typically use the term coordinate reference system. (EPSG has its own meaning for the term coordinate system, as noted in Section 6.6.11.)

## 6.1.2 Cartesian Coordinates

Cartesian coordinates are coordinates that measure the position of a point from a defined origin along axes that are perpendicular in the represented two-dimensional or three-dimensional space.

## 6.1.3 Geodetic Coordinates (Geographic Coordinates)

Geodetic coordinates (sometimes called geographic coordinates) are angular coordinates (longitude and latitude), closely related to spherical polar coordinates, and are defined relative to a particular Earth geodetic datum (described in Section 6.1.6). For more information about geodetic coordinate support, see Section 6.2.

## 6.1.4 Projected Coordinates

Projected coordinates are planar Cartesian coordinates that result from performing a mathematical mapping from a point on the Earth's surface to a plane. There are many such mathematical mappings, each used for a particular purpose.

## 6.1.5 Local Coordinates

Local coordinates are Cartesian coordinates in a non-Earth (non-georeferenced) coordinate system. Section 6.3 describes local coordinate support in Spatial.

## 6.1.6 Geodetic Datum

A geodetic datum (or datum) is a means of shifting and rotating an ellipsoid to represent the figure of the Earth, usually as an oblate spheroid, that approximates the surface of the Earth locally or globally, and is the reference for the system of geodetic coordinates.

Each geodetic coordinate system is based on a datum.

## 6.1.7 Transformation

Transformation is the conversion of coordinates from one coordinate system to another coordinate system.

If the coordinate system is georeferenced, transformation can involve datum transformation: the conversion of geodetic coordinates from one geodetic datum to another geodetic datum, usually involving changes in the shape, orientation, and center position of the reference ellipsoid.

## 6.2 Geodetic Coordinate Support

Effective with Oracle9i, Spatial provides a rational and complete treatment of geodetic coordinates. Before Oracle9i, Spatial computations were based solely on flat (Cartesian) coordinates, regardless of the coordinate system specified for the layer of geometries. Consequently, computations for data in geodetic coordinate systems were inaccurate, because they always treated the coordinates as if they were on a flat surface, and they did not consider the curvature of the surface.

Effective with release 9.2, ellipsoidal surface computations consider the curvatures of the Earth in the specified geodetic coordinate system and return correct, accurate results. In other words, Spatial queries return the right answers all the time.

## 6.2.1 Geodesy and Two-Dimensional Geometry

A two-dimensional geometry is a surface geometry, but the important question is: What is the surface? A flat surface (plane) is accurately represented by Cartesian coordinates. However, Cartesian coordinates are not adequate for representing the surface of a solid. A commonly used surface for spatial geometry is the surface of the Earth, and the laws of geometry there are different than they are in a plane. For example, on the Earth's surface there are no parallel lines: lines are geodesics, and all geodesics intersect. Thus, closed curved surface problems cannot be done accurately with Cartesian geometry.

Spatial provides accurate results regardless of the coordinate system or the size of the area involved, without requiring that the data be projected to a flat surface. The results are accurate regardless of where on the Earth's surface the query is focused, even in "special" areas such as the poles. Thus, you can store coordinates in any datum and projections that you choose, and you can perform accurate queries regardless of the coordinate system.

## 6.2.2 Choosing a Geodetic or Projected Coordinate System

For applications that deal with the Earth's surface, the data can be represented using a geodetic coordinate system or a projected plane coordinate system. In deciding which approach to take with the data, consider any needs related to accuracy and performance:

Accuracy

For many spatial applications, the area is sufficiently small to allow adequate computations on Cartesian coordinates in a local projection. For example, the New Hampshire State Plane local projection provides adequate accuracy for most spatial applications that use data for that state.

However, Cartesian computations on a plane projection will never give accurate results for a large area such as Canada or Scandinavia. For example, a query asking if Stockholm, Sweden and Helsinki, Finland are within a specified distance may return an incorrect result if the specified distance is close to the actual measured distance. Computations involving large areas or requiring very precise accuracy must account for the curvature of the Earth's surface.

Performance

Spherical computations use more computing resources than Cartesian computations. Some operations using geodetic coordinates may take longer to complete than the same operations using Cartesian coordinates.

## 6.2.3 Geodetic MBRs

To create a query window for certain operations on geodetic data, use an MBR (minimum bounding rectangle) by specifying an SDO_ETYPE value of 1003 or 2003 and an SDO_INTERPRETATION value of 3, as described in Table 2-2 in Section 2.2.4. A geodetic MBR can be used with the following operators: SDO_FILTER, SDO_RELATE with the

`ANYINTERACT`

mask, SDO_ANYINTERACT, and SDO_WITHIN_DISTANCE.Example 6-1 requests the names of all cola markets that are likely to interact spatially with a geodetic MBR.

Example 6-1 Using a Geodetic MBR

SELECT c.name FROM cola_markets_cs c WHERE SDO_FILTER(c.shape, SDO_GEOMETRY( 2003, 8307, -- SRID for WGS 84 longitude/latitude NULL, SDO_ELEM_INFO_ARRAY(1,1003,3), SDO_ORDINATE_ARRAY(6,5, 10,10)) ) = 'TRUE';Example 6-1 produces the following output (assuming the data as defined in Example 6-7 in Section 6.11):

NAME -------------------------------- cola_c cola_b cola_dThe following considerations apply to the use of geodetic MBRs:

Do not use a geodetic MBR with spatial objects stored in the database. Use it only to construct a query window.

The lower-left Y coordinate (minY) must be less than the upper-right Y coordinate (maxY). If the lower-left X coordinate (minX) is greater than the upper-right X coordinate (maxX), the window is assumed to cross the date line meridian (that is, the meridian "opposite" the prime meridian, or both 180 and -180 longitude). For example, an MBR of (-10,10, -100, 20) with longitude/latitude data goes three-fourths of the way around the Earth (crossing the date line meridian), and goes from latitude lines 10 to 20.

When Spatial constructs the MBR internally for the query, lines along latitude lines are densified by adding points at one-degree intervals. This might affect results for objects within a few meters of the edge of the MBR (especially objects in the middle latitudes in both hemispheres).

The following additional examples show special or unusual cases, to illustrate how a geodetic MBR is interpreted with longitude/latitude data:

(10,0, -110,20) crosses the date line meridian and goes most of the way around the world, and goes from the equator to latitude 20.

(10,-90, 40,90) is a band from the South Pole to the North Pole between longitudes 10 and 40.

(10,-90, 40,50) is a band from the South Pole to latitude 50 between longitudes 10 and 40.

(-180,-10, 180,5) is a band that wraps the equator from 10 degrees south to 5 degrees north.

(-180,-90, 180,90) is the whole Earth.

(-180,-90, 180,50) is the whole Earth below latitude 50.

(-180,50, 180,90) is the whole Earth above latitude 50.

## 6.2.4 Other Considerations and Requirements with Geodetic Data

The following geometries are not permitted if a geodetic coordinate system is used:

Circles

Circular arcs

Geodetic coordinate system support is provided only for geometries that consist of points or geodesics (lines on the ellipsoid). If you have geometries containing circles or circular arcs in a projected coordinate system, you can densify them using the SDO_GEOM.SDO_ARC_DENSIFY function (documented in Chapter 15) before transforming them to geodetic coordinates, and then perform Spatial operations on the resulting geometries.

The following size limits apply with geodetic data:

No polygon element can have an area larger than one-half the surface of the Earth.

In a line, the distance between two adjacent coordinates cannot be greater than or equal to one-half the perimeter (a great circle) of the Earth.

If you need to work with larger elements, first break these elements into multiple smaller elements and work with them. For example, you cannot create a geometry representing the entire ocean surface of the Earth; however, you can create multiple geometries, each representing part of the overall ocean surface. To work with a line string that is greater than or equal to one-half the perimeter of the Earth, you can add one or more intermediate points on the line so that all adjacent coordinates are less than one-half the perimeter of the Earth.

To take full advantage of Spatial features, you must index geodetic data layers using a geodetic R-tree index. (You can create a non-geodetic R-tree or quadtree index on geodetic data by specifying

`'geodetic=FALSE'`

in the PARAMETERS clause of the CREATE INDEX statement; however, this is not recommended. See the Usage Notes for the CREATE INDEX statement in Chapter 10 for more information.) In addition, for Spatial release 9.0.1 and later you must delete (DROP INDEX) and re-create all spatial indexes on geodetic data from a release before 9.0.1.Tolerance is specified as meters for geodetic layers. If you use tolerance values that are typical for non-geodetic data, these values are interpreted as meters for geodetic data. For example, if you specify a tolerance value of 0.05 for geodetic data, this is interpreted as precise to 5 centimeters. If this value is more precise than your applications need, performance may be affected because of the internal computational steps taken to implement the specified precision. (For more information about tolerance, see Section 1.5.5.)

For geodetic layers, you must specify the dimensional extents in the index metadata as -180,180 for longitude and -90,90 for latitude. The following statement (from Example 6-7 in Section 6.11) specifies these extents (with a 10-meter tolerance value in each dimension) for a geodetic data layer:

INSERT INTO user_sdo_geom_metadata (TABLE_NAME, COLUMN_NAME, DIMINFO, SRID) VALUES ( 'cola_markets_cs', 'shape', SDO_DIM_ARRAY( SDO_DIM_ELEMENT('Longitude', -180, 180, 10), -- 10 meters tolerance SDO_DIM_ELEMENT('Latitude', -90, 90, 10) -- 10 meters tolerance ), 8307 -- SRID for 'Longitude / Latitude (WGS 84)' coordinate system );See Section 6.9 for additional notes and restrictions relating to geodetic data.

## 6.3 Local Coordinate Support

Spatial provides a level of support for local coordinate systems. Local coordinate systems are often used in CAD systems, and they can also be used in local surveys where the relationship between the surveyed site and the rest of the world is not important.

Several local coordinate systems are predefined and included with Spatial in the SDO_COORD_REF_SYS table (described in Section 6.6.9). These supplied local coordinate systems, whose names start with Non-Earth, define non-Earth Cartesian coordinate systems based on different units of measurement (Meter, Millimeter, Inch, and so on).

In the current release, you cannot perform coordinate system transformation between local and Earth-based coordinate systems; and when transforming a geometry or layer of geometries between local coordinate systems, you can only to convert coordinates in a local coordinate system from one unit of measurement to another (for example, inches to millimeters). However, you can perform all other Spatial operations (for example, using SDO_RELATE, SDO_WITHIN_DISTANCE, and other operators) with local coordinate systems.

## 6.4 EPSG Model and Spatial

Effective with Oracle Database 10g release 2 (10.2), the Oracle Spatial coordinate system support is based on, but is not always identical to, the European Petroleum Survey Group (EPSG) data model and data set (described in detail at

`http://www.epsg.org`

). This approach provides the benefits of standardization, expanded support, and flexibility:

The EPSG model is a comprehensive and widely accepted standard for data representation, so users familiar with it can more easily understand Spatial storage and operations.

Support is provided for more coordinate systems and their associated datums, ellipsoids, and projections. For example, some of the EPSG geographic and projected coordinate systems had no counterpart among coordinate systems supported for previous Spatial releases. Their addition results in an expanded set of supported coordinate systems.

Data transformations are more flexible. Instead of there being only one possible Oracle-defined transformation path between a given source and target coordinate system, you can specify alternative paths to be used for a specific area of applicability (that is, use case) or as the systemwide default.

The rest of this section describes this flexibility.

For data transformations (that is, transforming data from one coordinate system to another), you can now control which transformation rules are to be applied. In previous releases, and in the current release by default, Spatial performs transformations based only on the specified source and target coordinate systems, using predetermined intermediate transformation steps. The assumption behind that default approach is that there is a single correct or preferable transformation chain.

By default, then, Spatial applies certain transformation methods for each supported transformation between specific pairs of source and target coordinate systems. For example, there are over 500 supported transformations from specific coordinate systems to the WGS 84 (longitude/latitude) coordinate system, which has the EPSG SRID value of 4326. As one example, for a transformation from SRID 4605 to SRID 4326, Spatial can use the transformation method with the COORD_OP_ID value 1445, as indicated in the SDO_COORD_OPS table (described in Section 6.6.8), which contains one row for each transformation operation between coordinate systems.

However, you can override the default transformation by specifying a different method (from the set of Oracle-supplied methods) for the transformation for any given source and target SRID combination. You can specify a transformation as the new systemwide default, or you can associate the transformation with a named use case that can be specified when transforming a layer of spatial geometries. (A use case is simply a name given to a usage scenario or area of applicability, such as Project XYZ or Mike's Favorite Transformations; there is no relationship between use cases and database users or schemas.)

To specify a transformation as either the systemwide default or associated with a use case, use the SDO_CS.ADD_PREFERENCE_FOR_OP procedure. To remove a previously specified preference, use the SDO_CS.REVOKE_PREFERENCE_FOR_OP procedure.

When it performs a coordinate system transformation, Spatial follows these general steps to determine the specific transformation to use:

If a use case has been specified, the transformation associated with that use case is applied.

If no use case has been specified and if a user-defined systemwide transformation has been created for the specified source and target coordinate system pair, that transformation is applied.

If no use case has been specified and if no user-defined transformation exists for the specified source and target coordinate system pair, the behavior depends on whether or not EPSG rules have been created, such as by the SDO_CS.CREATE_OBVIOUS_EPSG_RULES procedure:

If the EPSG rules have been created and if an EPSG rule is defined for this transformation, the EPSG transformation is applied.

If the EPSG rules have not been created, or if they have been created but no EPSG rule is defined for this transformation, the Oracle Spatial default transformation is applied.

## 6.5 TFM_PLAN Object Type

The object type TFM_PLAN is used is by several SDO_CS package subprograms to specify a transformation plan. For example, to create a concatenated operation that consists of two operations specified by a parameter of type TFM_PLAN, use the SDO_CS.CREATE_CONCATENATED_OP procedure.

Oracle Spatial defines the object type TFM_PLAN as:

CREATE TYPE tfm_plan AS OBJECT ( THE_PLAN SDO_TFM_CHAIN);The SDO_TFM_CHAIN type is defined as

`VARRAY(1048576) OF NUMBER`

.Within the SDO_TFM_CHAIN array:

The first element specifies the SRID of the source coordinate system.

Each pair of elements after the first element specifies an operation ID and the SRID of a target coordinate system.

## 6.6 Coordinate Systems Data Structures

The coordinate systems functions and procedures use information provided in the tables and views supplied with Oracle Spatial. The tables and views are part of the MDSYS schema; however, public synonyms are defined, so you do not need to specify MDSYS. before the table or view name. The definitions and data in these tables and views are based on the EPSG data model and data set, as explained in Section 6.4.

The coordinate system tables fit into several general categories:

Coordinate system general information: SDO_COORD_SYS, SDO_COORD_REF_SYS

Elements or aspects of a coordinate system definition: SDO_DATUMS, SDO_ELLIPSOIDS, SDO_PRIME_MERIDIANS

Datum transformation support: SDO_COORD_OPS, SDO_COORD_OP_METHODS, SDO_COORD_OP_PARAM_USE, SDO_COORD_OP_PARAM_VALS, SDO_COORD_OP_PARAMS, SDO_COORD_OP_PATHS, SDO_PREFERRED_OPS_SYSTEM, SDO_PREFERRED_OPS_USER

Others related to coordinate system definition: SDO_COORD_AXES, SDO_COORD_AXIS_NAMES, SDO_UNITS_OF_MEASURE

Several views are provided that are identical to or subsets of coordinate system tables:

SDO_COORD_REF_SYSTEM, which contains the same columns as the SDO_COORD_REF_SYS table. Use the SDO_COORD_REF_SYSTEM view instead of the COORD_REF_SYS table for any insert, update, or delete operations.

Subsets of SDO_DATUMS, selected according to the value in the DATUM_TYPE column: SDO_DATUM_ENGINEERING, SDO_DATUM_GEODETIC, SDO_DATUM_VERTICAL.

Subsets of SDO_COORD_REF_SYS, selected according to the value in the COORD_REF_SYS_KIND column: SDO_CRS_COMPOUND, SDO_CRS_ENGINEERING, SDO_CRS_GEOCENTRIC, SDO_CRS_GEOGRAPHIC2D, SDO_CRS_GEOGRAPHIC3D, SDO_CRS_PROJECTED, SDO_CRS_VERTICAL.

The rest of this section explains these tables and views, in alphabetical order. (Many column descriptions are adapted or taken from EPSG descriptions.)

In addition to the tables and views in this section, Spatial provides several legacy tables whose definitions and data match those of certain Spatial system tables used in previous releases. Section 6.7 describes the legacy tables.

Note:

You should not modify or delete any Oracle-supplied information in any of the tables or views that are used for coordinate system support.If you want to create a user-defined coordinate system, see Section 6.8.

## 6.6.1 SDO_COORD_AXES Table

The SDO_COORD_AXES table contains one row for each coordinate system axis definition. This table contains the columns shown in Table 6-1.

Table 6-1 SDO_COORD_AXES Table

Column Name Data Type Description COORD_SYS_ID

NUMBER(10)

ID number of the coordinate system to which this axis applies.

COORD_AXIS_NAME_ID

NUMBER(10)

ID number of a coordinate system axis name. Matches a value in the COORD_AXIS_NAME_ID column of the SDO_COORD_AXIS_NAMES table (described in Section 6.6.2). Example:

`9901`

(for`Geodetic latitude`

)COORD_AXIS_ORIENTATION

VARCHAR2(24)

The direction of orientation for the coordinate system axis. Example:

`east`

COORD_AXIS_ABBREVIATION

VARCHAR2(24)

The abbreviation for the coordinate system axis orientation. Example:

`E`

UOM_ID

NUMBER(10)

ID number of the unit of measurement associated with the axis. Matches a value in the UOM_ID column of the SDO_UNITS_OF_MEASURE table (described in Section 6.6.27).

ORDER

NUMBER(10)

Position of this axis within the coordinate system (1, 2, or 3).

## 6.6.2 SDO_COORD_AXIS_NAMES Table

The SDO_COORD_AXIS_NAMES table contains one row for each axis that can be used in a coordinate system definition. This table contains the columns shown in Table 6-2.

## 6.6.3 SDO_COORD_OP_METHODS Table

The SDO_COORD_OP_METHODS table contains one row for each coordinate systems transformation method. This table contains the columns shown in Table 6-3.

Table 6-3 SDO_COORD_OP_METHODS Table

Column Name Data Type Description COORD_OP_METHOD_ID

NUMBER(10)

ID number of the coordinate system transformation method. Example:

`9613`

COORD_OP_METHOD_NAME

VARCHAR2(50)

Name of the method. Example:

`NADCON`

REVERSE_OP

NUMBER(1)

Contains

`1`

if reversal of the transformation (from the current target coordinate system to the source coordinate system) can be achieved by reversing the sign of each parameter value; contains`0`

if a separate operation must be defined for reversal of the transformation.INFORMATION_SOURCE

VARCHAR2(254)

Origin of this information. Example:

`US Coast and geodetic Survey - http://www.ngs.noaa.gov`

DATA_SOURCE

VARCHAR2(40)

Organization providing the data for this record. Example:

`EPSG`

## 6.6.4 SDO_COORD_OP_PARAM_USE Table

The SDO_COORD_OP_PARAM_USE table contains one row for each combination of transformation method and transformation operation parameter that is available for use. This table contains the columns shown in Table 6-4.

Table 6-4 SDO_COORD_OP_PARAM_USE Table

Column Name Data Type Description COORD_OP_METHOD_ID

NUMBER(10)

ID number of the coordinate system transformation method. Matches a value in the COORD_OP_METHOD_ID column of the COORD_OP_METHODS table (described in Section 6.6.3).

PARAMETER_ID

NUMBER(10)

ID number of the parameter for transformation operations. Matches a value in the PARAMETER_ID column of the SDO_COORD_OP_PARAMS table (described in Section 6.6.6).

SORT_ORDER

NUMBER(5)

A number indicating the position of this parameter in the sequence of parameters for this method. Example:

`2`

for the second parameterPARAM_SIGN_REVERSAL

VARCHAR2(3)

`Yes`

if reversal of the transformation (from the current target coordinate system to the source coordinate system) can be achieved by reversing the sign of each parameter value;`No`

if a separate operation must be defined for reversal of the transformation.## 6.6.5 SDO_COORD_OP_PARAM_VALS Table

The SDO_COORD_OP_PARAM_VALS table contains information about parameter values for each coordinate system transformation method. This table contains the columns shown in Table 6-5.

Table 6-5 SDO_COORD_OP_PARAM_VALS Table

Column Name Data Type Description COORD_OP_ID

NUMBER(10)

ID number of the coordinate transformation operation. Matches a value in the COORD_OP_ID column of the SDO_COORD_OPS table (described in Section 6.6.8).

COORD_OP_METHOD_ID

NUMBER(10)

Coordinate operation method ID. Must match a COORD_OP_METHOD_ID value in the SDO_COORD_OP_METHODS table (see Section 6.6.3).

PARAMETER_ID

NUMBER(10)

ID number of the parameter for transformation operations. Matches a value in the PARAMETER_ID column of the SDO_COORD_OP_PARAMS table (described in Section 6.6.6).

PARAMETER_VALUE

FLOAT(49)

Value of the parameter for this operation.

PARAM_VALUE_FILE_REF

VARCHAR2(254)

Name of the file containing the value data, if a single value for the parameter is not sufficient.

UOM_ID

NUMBER(10)

ID number of the unit of measurement associated with the operation. Matches a value in the UOM_ID column of the SDO_UNITS_OF_MEASURE table (described in Section 6.6.27).

## 6.6.6 SDO_COORD_OP_PARAMS Table

The SDO_COORD_OP_PARAMS table contains one row for each available parameter for transformation operations. This table contains the columns shown in Table 6-6.

Table 6-6 SDO_COORD_OP_PARAMS Table

Column Name Data Type Description PARAMETER_ID

NUMBER(10)

ID number of the parameter. Example:

`8608`

PARAMETER_NAME

VARCHAR2(80)

Name of the operation. Example:

`X-axis rotation`

INFORMATION_SOURCE

VARCHAR2(254)

Origin of this information. Example:

`EPSG guidance note number 7.`

DATA_SOURCE

VARCHAR2(40)

Organization providing the data for this record. Example:

`EPSG`

## 6.6.7 SDO_COORD_OP_PATHS Table

The SDO_COORD_OP_PATHS table contains one row for each atomic step in a concatenated operation. This table contains the columns shown in Table 6-7.

Table 6-7 SDO_COORD_OP_PATHS Table

Column Name Data Type Description CONCAT_OPERATION_ID

NUMBER(10)

ID number of the concatenation operation. Must match a COORD_OP_ID value in the SDO_COORD_OPS table (described in Section 6.6.8) for which the COORD_OP_TYPE value is

`CONCATENATION`

.SINGLE_OPERATION_ID

NUMBER(10)

ID number of the single coordinate operation for this step (atomic operation) in a concatenated operation. Must match a COORD_OP_ID value in the SDO_COORD_OPS table (described in Section 6.6.8).

SINGLE_OP_SOURCE_ID

NUMBER(10)

ID number of source coordinate reference system for the single coordinate operation for this step. Must match an SRID value in the SDO_COORD_REF_SYS table (described in Section 6.6.9).

SINGLE_OP_TARGET_ID

NUMBER(10)

ID number of target coordinate reference system for the single coordinate operation for this step. Must match an SRID value in the SDO_COORD_REF_SYS table (described in Section 6.6.9).

OP_PATH_STEP

NUMBER(5)

Sequence number of this step (atomic operation) within this concatenated operation.

## 6.6.8 SDO_COORD_OPS Table

The SDO_COORD_OPS table contains one row for each transformation operation between coordinate systems. This table contains the columns shown in Table 6-8.

Table 6-8 SDO_COORD_OPS Table

Column Name Data Type Description COORD_OP_ID

NUMBER(10)

ID number of the coordinate transformation operation. Example:

`101`

COORD_OP_NAME

VARCHAR2(80)

Name of the operation. Example:

`ED50 to WGS 84 (14)`

COORD_OP_TYPE

VARCHAR2(24)

Type of operation. One of the following:

`CONCATENATED OPERATION`

,`CONVERSION`

, or`TRANSFORMATION`

SOURCE_SRID

NUMBER(10)

SRID of the coordinate system from which to perform the transformation. Example:

`4230`

TARGET_SRID

NUMBER(10)

SRID of the coordinate system into which to perform the transformation. Example:

`4326`

COORD_TFM_VERSION

VARCHAR2(24)

Name assigned by EPSG to the coordinate transformation. Example:

`5Nat-NSea90`

COORD_OP_VARIANT

NUMBER(5)

A variant of the more generic method specified in COORD_OP_METHOD_ID. Example:

`14`

COORD_OP_METHOD_ID

NUMBER(10)

Coordinate operation method ID. Must match a COORD_OP_METHOD_ID value in the SDO_COORD_OP_METHODS table (see Section 6.6.3). Several operations can use a method. Example:

`9617`

UOM_ID_SOURCE_OFFSETS

NUMBER(10)

ID number of the unit of measurement for offsets in the source coordinate system. Matches a value in the UOM_ID column of the SDO_UNITS_OF_MEASURE table (described in Section 6.6.27).

UOM_ID_TARGET_OFFSETS

NUMBER(10)

ID number of the unit of measurement for offsets in the target coordinate system. Matches a value in the UOM_ID column of the SDO_UNITS_OF_MEASURE table (described in Section 6.6.27).

INFORMATION_SOURCE

VARCHAR2(254)

Origin of this information. Example:

`Institut de Geomatica; Barcelona`

DATA_SOURCE

VARCHAR2(40)

Organization providing the data for this record. Example:

`EPSG`

SHOW_OPERATION

NUMBER(3)

(Currently not used.)

IS_LEGACY

VARCHAR2(5)

TRUE if the operation was included in Oracle Spatial before release 10.2; FALSE if the operation is new in Oracle Spatial release 10.2.

LEGACY_CODE

NUMBER(10)

For any EPSG coordinate transformation operation that has a semantically identical legacy (in Oracle Spatial before release 10.2) counterpart, the COORD_OP_ID value of the legacy coordinate transformation operation.

REVERSE_OP

NUMBER(1)

Contains

`1`

if reversal of the transformation (from the current target coordinate system to the source coordinate system) is defined as achievable by reversing the sign of each parameter value; contains`0`

if a separate operation must be defined for reversal of the transformation. If REVERSE_OP contains`1`

, the operations that are actually implemented are indicated by the values for IS_IMPLEMENTED_FORWARD and IS_IMPLEMENTED_REVERSE.IS_IMPLEMENTED_FORWARD

NUMBER(1)

Contains

`1`

if the forward operation is implemented; contains`0`

if the forward operation is not implemented.IS_IMPLEMENTED_REVERSE

NUMBER(1)

Contains

`1`

if the reverse operation is implemented; contains`0`

if the reverse operation is not implemented.## 6.6.9 SDO_COORD_REF_SYS Table

The SDO_COORD_REF_SYS table contains one row for each coordinate reference system. This table contains the columns shown in Table 6-9. (The SDO_COORD_REF_SYS table is roughly patterned after the EPSG Coordinate Reference System table.)

Note:

If you need to perform an insert, update, or delete operation, you must perform it on the SDO_COORD_REF_SYSTEM view, which contains the same columns as the SDO_COORD_REF_SYS table. The SDO_COORD_REF_SYSTEM view is described in Section 6.6.10.Table 6-9 SDO_COORD_REF_SYS Table

Column Name Data Type Description SRID

NUMBER(10)

ID number of the coordinate reference system. Example:

`8307`

COORD_REF_SYS_NAME

VARCHAR2(80)

Name of the coordinate reference system. Example:

`Longitude / Latitude (WGS 84)`

COORD_REF_SYS_KIND

VARCHAR2(24)

Category for the coordinate system. Example:

`GEOGRAPHIC2D`

COORD_SYS_ID

NUMBER(10)

ID number of the coordinate system used for the coordinate reference system. Must match a COORD_SYS_ID value in the SDO_COORD_SYS table (see Section 6.6.11).

DATUM_ID

NUMBER(10)

ID number of the datum used for the coordinate reference system. Null for a projected coordinate system. For a geodetic coordinate system, must match a DATUM_ID value in the SDO_DATUMS table (see Section 6.6.22). Example:

`10115`

GEOG_CRS_DATUM_ID

NUMBER(10)

ID number of the datum used for the coordinate reference system. For a projected coordinate system, must match the DATUM_ID value (in the SDO_DATUMS table, described in Section 6.6.22) of the geodetic coordinate system on which the projected coordinate system is based. For a geodetic coordinate system, must match the DATUM_ID value. Example:

`10115`

SOURCE_GEOG_SRID

NUMBER(10)

For a projected coordinate reference system, the ID number for the associated geodetic coordinate system.

PROJECTION_CONV_ID

NUMBER(10)

For a projected coordinate reference system, the COORD_OP_ID value of the conversion operation used to convert the projected coordinated system to and from the source geographic coordinate system.

CMPD_HORIZ_SRID

NUMBER(10)

(EPSG-assigned value; not used by Oracle Spatial. The EPSG description is: "For compound CRS only, the code of the horizontal component of the Compound CRS.")

CMPD_VERT_SRID

NUMBER(10)

(EPSG-assigned value; not used by Oracle Spatial. The EPSG description is: "For compound CRS only, the code of the vertical component of the Compound CRS.")

INFORMATION_SOURCE

VARCHAR2(254)

Provider of the definition for the coordinate system (

`Oracle`

for all rows supplied by Oracle).DATA_SOURCE

VARCHAR2(40)

Organization that supplied the data for this record (if not Oracle).

IS_LEGACY

VARCHAR2(5)

`TRUE`

if the coordinate system definition was included in Oracle Spatial before release 10.2;`FALSE`

if the coordinate system definition is new in Oracle Spatial release 10.2.LEGACY_CODE

NUMBER(10)

For any EPSG coordinate reference system that has a semantically identical legacy (in Oracle Spatial before release 10.2) counterpart, the SRID value of the legacy coordinate system.

LEGACY_WKTEXT

VARCHAR2(2046)

If IS_LEGACY is

`TRUE`

, contains the well-known text description of the coordinate system. Example:`GEOGCS [ "Longitude / Latitude (WGS 84)", DATUM ["WGS 84", SPHEROID ["WGS 84", 6378137, 298.257223563]], PRIMEM [ "Greenwich", 0.000000 ], UNIT ["Decimal Degree", 0.01745329251994330]]`

LEGACY_CS_BOUNDS

SDO_GEOMETRY

For a legacy coordinate system, the dimensional boundary (if any).

IS_VALID

VARCHAR2(5)

`TRUE`

if the EPSG record for the coordinate reference system is completely defined;`FALSE`

if the EPSG record for the coordinate reference system is not completely defined.SUPPORTS_SDO_GEOMETRY

VARCHAR2(5)

`TRUE`

if the COORD_REF_SYS_KIND column contains`ENGINEERING`

,`GEOGRAPHIC2D`

, or`PROJECTED CRS`

;`FALSE`

if the COORD_REF_SYS_KIND column contains any other value.See also the information about the following views that are defined based on the value of the COORD_REF_SYS_KIND column:

SDO_CRS_COMPOUND (Section 6.6.12)

SDO_CRS_ENGINEERING (Section 6.6.13)

SDO_CRS_GEOCENTRIC (Section 6.6.14)

SDO_CRS_GEOGRAPHIC2D (Section 6.6.15)

SDO_CRS_GEOGRAPHIC3D (Section 6.6.16)

SDO_CRS_PROJECTED (Section 6.6.17)

SDO_CRS_VERTICAL (Section 6.6.18)

## 6.6.10 SDO_COORD_REF_SYSTEM View

The SDO_COORD_REF_SYSTEM view contains the same columns as the SDO_COORD_REF_SYS table, which is described in Section 6.6.9. However, the SDO_COORD_REF_SYSTEM view has a trigger defined on it, so that any insert, update, or delete operations performed on the view cause all relevant Spatial system tables to have the appropriate operations performed on them.

Therefore, if you need to perform an insert, update, or delete operation, you must perform it on the SDO_COORD_REF_SYSTEM view, not the SDO_COORD_REF_SYS table.

## 6.6.11 SDO_COORD_SYS Table

The SDO_COORD_SYS table contains rows with information about coordinate systems. This table contains the columns shown in Table 6-10. (The SDO_COORD_SYS table is roughly patterned after the EPSG Coordinate System table, where a coordinate system is described as "a pair of reusable axes.")

Table 6-10 SDO_COORD_SYS Table

Column Name Data Type Description COORD_SYS_ID

NUMBER(10)

ID number of the coordinate system. Example:

`6405`

COORD_SYS_NAME

VARCHAR2(254)

Name of the coordinate system. Example:

`Ellipsoidal 2D CS. Axes: latitude, longitude. Orientations: north, east. UoM: dec deg`

COORD_SYS_TYPE

VARCHAR2(24)

Type of coordinate system. Example:

`ellipsoidal`

DIMENSION

NUMBER(5)

Number of dimensions represented by the coordinate system.

INFORMATION_SOURCE

VARCHAR2(254)

Origin of this information.

DATA_SOURCE

VARCHAR2(40)

Organization providing the data for this record.

## 6.6.12 SDO_CRS_COMPOUND View

The SDO_CRS_COMPOUND view contains selected information from the SDO_COORD_REF_SYS table (described in Section 6.6.9) where the COORD_REF_SYS_KIND column value is

`COMPOUND`

. This view contains the columns shown in Table 6-11.Table 6-11 SDO_CRS_COMPOUND View

Column Name Data Type Description SRID

NUMBER(10)

ID number of the coordinate reference system.

COORD_REF_SYS_NAME

VARCHAR2(80)

Name of the coordinate reference system.

CMPD_HORIZ_SRID

NUMBER(10)

(EPSG-assigned value; not used by Oracle Spatial. The EPSG description is: "For compound CRS only, the code of the horizontal component of the Compound CRS.")

CMPD_VERT_SRID

NUMBER(10)

(EPSG-assigned value; not used by Oracle Spatial. The EPSG description is: "For compound CRS only, the code of the vertical component of the Compound CRS.")

INFORMATION_SOURCE

VARCHAR2(254)

Provider of the definition for the coordinate system (

`Oracle`

for all rows supplied by Oracle).DATA_SOURCE

VARCHAR2(40)

Organization that supplied the data for this record (if not Oracle).

## 6.6.13 SDO_CRS_ENGINEERING View

The SDO_CRS_ENGINEERING view contains selected information from the SDO_COORD_REF_SYS table (described in Section 6.6.9) where the COORD_REF_SYS_KIND column value is

`ENGINEERING`

. This view contains the columns shown in Table 6-12.Table 6-12 SDO_CRS_ENGINEERING View

Column Name Data Type Description SRID

NUMBER(10)

ID number of the coordinate reference system.

COORD_REF_SYS_NAME

VARCHAR2(80)

Name of the coordinate reference system.

COORD_SYS_ID

NUMBER(10)

ID number of the coordinate system used for the coordinate reference system. Must match a COORD_SYS_ID value in the SDO_COORD_SYS table (see Section 6.6.11).

DATUM_ID

NUMBER(10)

ID number of the datum used for the coordinate reference system. Must match a DATUM_ID value in the SDO_DATUMS table (see Section 6.6.22). Example:

`10115`

INFORMATION_SOURCE

VARCHAR2(254)

Provider of the definition for the coordinate system (

`Oracle`

for all rows supplied by Oracle).DATA_SOURCE

VARCHAR2(40)

Organization that supplied the data for this record (if not Oracle).

## 6.6.14 SDO_CRS_GEOCENTRIC View

The SDO_CRS_GEOCENTRIC view contains selected information from the SDO_COORD_REF_SYS table (described in Section 6.6.9) where the COORD_REF_SYS_KIND column value is

`GEOCENTRIC`

. This view contains the columns shown in Table 6-13.Table 6-13 SDO_CRS_GEOCENTRIC View

Column Name Data Type Description SRID

NUMBER(10)

ID number of the coordinate reference system.

COORD_REF_SYS_NAME

VARCHAR2(80)

Name of the coordinate reference system.

COORD_SYS_ID

NUMBER(10)

ID number of the coordinate system used for the coordinate reference system. Must match a COORD_SYS_ID value in the SDO_COORD_SYS table (see Section 6.6.11).

DATUM_ID

NUMBER(10)

ID number of the datum used for the coordinate reference system. Must match a DATUM_ID value in the SDO_DATUMS table (see Section 6.6.22). Example:

`10115`

INFORMATION_SOURCE

VARCHAR2(254)

Provider of the definition for the coordinate system (

`Oracle`

for all rows supplied by Oracle).DATA_SOURCE

VARCHAR2(40)

Organization that supplied the data for this record (if not Oracle).

## 6.6.15 SDO_CRS_GEOGRAPHIC2D View

The SDO_CRS_GEOGRAPHIC2D view contains selected information from the SDO_COORD_REF_SYS table (described in Section 6.6.9) where the COORD_REF_SYS_KIND column value is

`GEOGRAPHIC2D`

. This view contains the columns shown in Table 6-14.Table 6-14 SDO_CRS_GEOGRAPHIC2D View

Column Name Data Type Description SRID

NUMBER(10)

ID number of the coordinate reference system.

COORD_REF_SYS_NAME

VARCHAR2(80)

Name of the coordinate reference system.

COORD_SYS_ID

NUMBER(10)

DATUM_ID

NUMBER(10)

ID number of the datum used for the coordinate reference system. Must match a DATUM_ID value in the SDO_DATUMS table (see Section 6.6.22). Example:

`10115`

INFORMATION_SOURCE

VARCHAR2(254)

Provider of the definition for the coordinate system (

`Oracle`

for all rows supplied by Oracle).DATA_SOURCE

VARCHAR2(40)

Organization that supplied the data for this record (if not Oracle).

## 6.6.16 SDO_CRS_GEOGRAPHIC3D View

The SDO_CRS_GEOGRAPHIC3D view contains selected information from the SDO_COORD_REF_SYS table (described in Section 6.6.9) where the COORD_REF_SYS_KIND column value is

`GEOGRAPHIC3D`

. This view contains the columns shown in Table 6-15.Table 6-15 SDO_CRS_GEOGRAPHIC3D View

Column Name Data Type Description SRID

NUMBER(10)

ID number of the coordinate reference system.

COORD_REF_SYS_NAME

VARCHAR2(80)

Name of the coordinate reference system.

COORD_SYS_ID

NUMBER(10)

DATUM_ID

NUMBER(10)

`10115`

INFORMATION_SOURCE

VARCHAR2(254)

Provider of the definition for the coordinate system (

`Oracle`

for all rows supplied by Oracle).DATA_SOURCE

VARCHAR2(40)

Organization that supplied the data for this record (if not Oracle).

## 6.6.17 SDO_CRS_PROJECTED View

The SDO_CRS_PROJECTED view contains selected information from the SDO_COORD_REF_SYS table (described in Section 6.6.9) where the COORD_REF_SYS_KIND column value is

`PROJECTED`

. This view contains the columns shown in Table 6-16.Table 6-16 SDO_CRS_PROJECTED View

Column Name Data Type Description SRID

NUMBER(10)

ID number of the coordinate reference system.

COORD_REF_SYS_NAME

VARCHAR2(80)

Name of the coordinate reference system.

COORD_SYS_ID

NUMBER(10)

SOURCE_GEOG_SRID

NUMBER(10)

ID number for the associated geodetic coordinate system.

PROJECTION_CONV_ID

NUMBER(10)

COORD_OP_ID value of the conversion operation used to convert the projected coordinated system to and from the source geographic coordinate system.

INFORMATION_SOURCE

VARCHAR2(254)

Provider of the definition for the coordinate system (

`Oracle`

for all rows supplied by Oracle).DATA_SOURCE

VARCHAR2(40)

Organization that supplied the data for this record (if not Oracle).

## 6.6.18 SDO_CRS_VERTICAL View

The SDO_CRS_VERTICAL view contains selected information from the SDO_COORD_REF_SYS table (described in Section 6.6.9) where the COORD_REF_SYS_KIND column value is

VERTICAL. This view contains the columns shown in Table 6-17. Table 6-17 SDO_CRS_VERTICAL View

Column Name Data Type Description SRID

NUMBER(10)

ID number of the coordinate reference system.

COORD_REF_SYS_NAME

VARCHAR2(80)

Name of the coordinate reference system.

COORD_SYS_ID

NUMBER(10)

DATUM_ID

NUMBER(10)

`10115`

INFORMATION_SOURCE

VARCHAR2(254)

Provider of the definition for the coordinate system (

`Oracle`

for all rows supplied by Oracle).DATA_SOURCE

VARCHAR2(40)

Organization that supplied the data for this record (if not Oracle).

## 6.6.19 SDO_DATUM_ENGINEERING View

The SDO_DATUM_ENGINEERING view contains selected information from the SDO_DATUMS table (described in Section 6.6.22) where the DATUM_TYPE column value is

`ENGINEERING`

. This view contains the columns shown in Table 6-18.Table 6-18 SDO_DATUM_ENGINEERING View

Column Name Data Type Description DATUM_ID

NUMBER(10)

ID number of the datum.

DATUM_NAME

VARCHAR2(80)

Name of the datum.

ELLIPSOID_ID

NUMBER(10)

ID number of the ellipsoid used in the datum definition. Must match an ELLIPSOID_ID value in the SDO_ELLIPSOIDS table (see Section 6.6.23). Example:

`8045`

PRIME_MERIDIAN_ID

NUMBER(10)

ID number of the prime meridian used in the datum definition. Must match a PRIME_MERIDIAN_ID value in the SDO_PRIME_MERIDIANS table (see Section 6.6.26). Example:

`8950`

INFORMATION_SOURCE

VARCHAR2(254)

Provider of the definition of the datum. Example:

`Ordnance Survey of Great Britain.`

SHIFT_X

NUMBER

Number of meters to shift the ellipsoid center relative to the center of the WGS 84 ellipsoid on the x-axis.

SHIFT_Y

NUMBER

Number of meters to shift the ellipsoid center relative to the center of the WGS 84 ellipsoid on the y-axis.

SHIFT_Z

NUMBER

Number of meters to shift the ellipsoid center relative to the center of the WGS 84 ellipsoid on the z-axis.

ROTATE_X

NUMBER

Number of arc-seconds of rotation about the x-axis.

ROTATE_Y

NUMBER

Number of arc-seconds of rotation about the y-axis.

ROTATE_Z

NUMBER

Number of arc-seconds of rotation about the z-axis.

SCALE_ADJUST

NUMBER

A value to be used in adjusting the X, Y, and Z values after any shifting and rotation, according to the formula: 1.0 + (SCALE_ADJUST * 10

^{-6})## 6.6.20 SDO_DATUM_GEODETIC View

The SDO_DATUM_GEODETIC view contains selected information from the SDO_DATUMS table (described in Section 6.6.22) where the DATUM_TYPE column value is

`GEODETIC`

. This view contains the columns shown in Table 6-19.Table 6-19 SDO_DATUM_GEODETIC View

Column Name Data Type Description DATUM_ID

NUMBER(10)

ID number of the datum.

DATUM_NAME

VARCHAR2(80)

Name of the datum.

ELLIPSOID_ID

NUMBER(10)

ID number of the ellipsoid used in the datum definition. Must match an ELLIPSOID_ID value in the SDO_ELLIPSOIDS table (see Section 6.6.23). Example:

`8045`

PRIME_MERIDIAN_ID

NUMBER(10)

ID number of the prime meridian used in the datum definition. Must match a PRIME_MERIDIAN_ID value in the SDO_PRIME_MERIDIANS table (see Section 6.6.26). Example:

`8950`

INFORMATION_SOURCE

VARCHAR2(254)

Provider of the definition of the datum. Example:

`Ordnance Survey of Great Britain.`

SHIFT_X

NUMBER

Number of meters to shift the ellipsoid center relative to the center of the WGS 84 ellipsoid on the x-axis.

SHIFT_Y

NUMBER

Number of meters to shift the ellipsoid center relative to the center of the WGS 84 ellipsoid on the y-axis.

SHIFT_Z

NUMBER

Number of meters to shift the ellipsoid center relative to the center of the WGS 84 ellipsoid on the z-axis.

ROTATE_X

NUMBER

Number of arc-seconds of rotation about the x-axis.

ROTATE_Y

NUMBER

Number of arc-seconds of rotation about the y-axis.

ROTATE_Z

NUMBER

Number of arc-seconds of rotation about the z-axis.

SCALE_ADJUST

NUMBER

A value to be used in adjusting the X, Y, and Z values after any shifting and rotation, according to the formula: 1.0 + (SCALE_ADJUST * 10

^{-6})## 6.6.21 SDO_DATUM_VERTICAL View

The SDO_DATUM_VERTICAL view contains selected information from the SDO_DATUMS table (described in Section 6.6.22) where the DATUM_TYPE column value is

`VERTICAL`

. This view contains the columns shown in Table 6-20.Table 6-20 SDO_DATUM_VERTICAL View

Column Name Data Type Description DATUM_ID

NUMBER(10)

ID number of the datum.

DATUM_NAME

VARCHAR2(80)

Name of the datum.

ELLIPSOID_ID

NUMBER(10)

ID number of the ellipsoid used in the datum definition. Must match an ELLIPSOID_ID value in the SDO_ELLIPSOIDS table (see Section 6.6.23). Example:

`8045`

PRIME_MERIDIAN_ID

NUMBER(10)

ID number of the prime meridian used in the datum definition. Must match a PRIME_MERIDIAN_ID value in the SDO_PRIME_MERIDIANS table (see Section 6.6.26). Example:

`8950`

INFORMATION_SOURCE

VARCHAR2(254)

Provider of the definition of the datum. Example:

`Ordnance Survey of Great Britain.`

SHIFT_X

NUMBER

Number of meters to shift the ellipsoid center relative to the center of the WGS 84 ellipsoid on the x-axis.

SHIFT_Y

NUMBER

Number of meters to shift the ellipsoid center relative to the center of the WGS 84 ellipsoid on the y-axis.

SHIFT_Z

NUMBER

Number of meters to shift the ellipsoid center relative to the center of the WGS 84 ellipsoid on the z-axis.

ROTATE_X

NUMBER

Number of arc-seconds of rotation about the x-axis.

ROTATE_Y

NUMBER

Number of arc-seconds of rotation about the y-axis.

ROTATE_Z

NUMBER

Number of arc-seconds of rotation about the z-axis.

SCALE_ADJUST

NUMBER

A value to be used in adjusting the X, Y, and Z values after any shifting and rotation, according to the formula: 1.0 + (SCALE_ADJUST * 10

^{-6})## 6.6.22 SDO_DATUMS Table

The SDO_DATUMS table contains one row for each datum. This table contains the columns shown in Table 6-21.

Table 6-21 SDO_DATUMS Table

Column Name Data Type Description DATUM_ID

NUMBER(10)

ID number of the datum. Example:

`10115`

DATUM_NAME

VARCHAR2(80)

Name of the datum. Example:

`WGS 84`

DATUM_TYPE

VARCHAR2(24)

Type of the datum. Example:

`GEODETIC`

ELLIPSOID_ID

NUMBER(10)

`8045`

PRIME_MERIDIAN_ID

NUMBER(10)

`8950`

INFORMATION_SOURCE

VARCHAR2(254)

Provider of the definition of the datum. Example:

`Ordnance Survey of Great Britain.`

DATA_SOURCE

VARCHAR2(40)

Organization that supplied the data for this record (if not Oracle). Example:

`EPSG`

SHIFT_X

NUMBER

SHIFT_Y

NUMBER

SHIFT_Z

NUMBER

ROTATE_X

NUMBER

Number of arc-seconds of rotation about the x-axis.

ROTATE_Y

NUMBER

Number of arc-seconds of rotation about the y-axis.

ROTATE_Z

NUMBER

Number of arc-seconds of rotation about the z-axis.

SCALE_ADJUST

NUMBER

^{-6})IS_LEGACY

VARCHAR2(5)

`TRUE`

if the datum definition was included in Oracle Spatial before release 10.2;`FALSE`

if the datum definition is new in Oracle Spatial release 10.2.LEGACY_CODE

NUMBER(10)

For any EPSG datum that has a semantically identical legacy (in Oracle Spatial before release 10.2) counterpart, the DATUM_ID value of the legacy datum.

See also the information about the following views that are defined based on the value of the DATUM_TYPE column: SDO_DATUM_ENGINEERING (Section 6.6.19), SDO_DATUM_GEODETIC (Section 6.6.20), and SDO_DATUM_VERTICAL (Section 6.6.21).

## 6.6.23 SDO_ELLIPSOIDS Table

The SDO_ELLIPSOIDS table contains one row for each ellipsoid. This table contains the columns shown in Table 6-22.

Table 6-22 SDO_ELLIPSOIDS Table

<tr align="left" valign="top">

Column Name Data Type Description ELLIPSOID_ID

NUMBER(10)

ID number of the ellipsoid (spheroid). Example:

`8045`

ELLIPSOID_NAME

VARCHAR2(80)

Name of the ellipsoid. Example:

`WGS 84`

NUMBER

Radius in meters along the semi-major axis (one-half of the long axis of the ellipsoid).

UOM_ID

NUMBER

ID number of the unit of measurement for the ellipsoid. Matches a value in the UOM_ID column of the SDO_UNITS_OF_MEASURE table (described in Section 6.6.27). Example:

`9001`

NUMBER

Inverse flattening of the ellipsoid. That is,

`1/f`

, where`f = (a-b)/a`

, and`a`

is the semi-major axis and`b`

is the semi-minor axis.NUMBER

Radius in meters along the semi-minor axis (one-half of the short axis of the ellipsoid).

INFORMATION_SOURCE

VARCHAR2(254)

Origin of this information. Example:

`Kort og Matrikelstyrelsen (KMS), Copenhagen.`

DATA_SOURCE

VARCHAR2(40)

Organization that supplied the data for this record (if not Oracle). Example:

`EPSG`

IS_LEGACY

VARCHAR2(5)

`TRUE`

if the ellipsoid definition was included in Oracle Spatial before release 10.2;`FALSE`

if the ellipsoid definition is new in Oracle Spatial release 10.2.LEGACY_CODE

NUMBER

For any EPSG ellipsoid that has a semantically identical legacy (in Oracle Spatial before release 10.2) counterpart, the ELLIPSOID_ID value of the legacy ellipsoid.

## 6.6.24 SDO_PREFERRED_OPS_SYSTEM Table

The SDO_PREFERRED_OPS_SYSTEM table contains one row for each specification of the user-defined default preferred coordinate transformation operation for a source and target SRID combination. If you insert a row into the SDO_PREFERRED_OPS_SYSTEM table, you are overriding the Oracle default operation for transformations between the specified source and target coordinate systems. The SDO_CS.CREATE_OBVIOUS_EPSG_RULES procedure inserts many rows into this table. The SDO_CS.DELETE_ALL_EPSG_RULES procedure deletes all rows from this table if the

`use_case`

parameter is null. This table contains the columns shown in Table 6-23.Table 6-23 SDO_PREFERRED_OPS_SYSTEM Table

Column Name Data Type Description SOURCE_SRID

NUMBER(10)

ID number of the coordinate system (spatial reference system) from which to perform coordinate transformation, using the operation specified by COORD_OP_ID as the default preferred method for transforming to the specified target SRID.

COORD_OP_ID

NUMBER(10)

ID number of the coordinate transformation operation. Matches a value in the COORD_OP_ID column of the SDO_COORD_OPS table (described in Section 6.6.8).

TARGET_SRID

NUMBER(10)

ID number of coordinate system (spatial reference system) into which to perform coordinate transformation using the operation specified by COORD_OP_ID.

## 6.6.25 SDO_PREFERRED_OPS_USER Table

The SDO_PREFERRED_OPS_USER table contains one row for each specification of a user-defined source and target SRID and coordinate transformation operation. If you insert a row into the SDO_PREFERRED_OPS_USER table, you create a custom transformation between the source and target coordinate systems, and you can specify the name (the USE_CASE column value) of the transformation operation as the

`use_case`

parameter value with several SDO_CS functions and procedures. If you specify a use case with the SDO_CS.DELETE_ALL_EPSG_RULES procedure, rows associated with that use case are deleted from this table. This table contains the columns shown in Table 6-24.Table 6-24 SDO_PREFERRED_OPS_USER Table

Column Name Data Type Description USE_CASE

VARCHAR2(32)

Name of this specification of a source and target SRID and coordinate transformation operation.

SOURCE_SRID

NUMBER(10)

ID number of the coordinate system (spatial reference system) from which to perform the transformation.

COORD_OP_ID

NUMBER(10)

ID number of the coordinate transformation operation. Matches a value in the COORD_OP_ID column of the SDO_COORD_OPS table (described in Section 6.6.8).

TARGET_SRID

NUMBER(10)

ID number of the coordinate system (spatial reference system) into which to perform the transformation.

## 6.6.26 SDO_PRIME_MERIDIANS Table

The SDO_PRIME_MERIDIANS table contains one row for each prime meridian that can be used in a datum specification. This table contains the columns shown in Table 6-25.

Table 6-25 SDO_PRIME_MERIDIANS Table

Column Name Data Type Description PRIME_MERIDIAN_ID

NUMBER(10)

ID number of the prime meridian. Example:

`8907`

PRIME_MERIDIAN_NAME

VARCHAR2(80)

Name of the prime meridian. Example:

`Bern`

GREENWICH_LONGITUDE

FLOAT(49)

Longitude of the prime meridian as an offset from the Greenwich meridian. Example:

`7.26225`

UOM_ID

NUMBER(10)

ID number of the unit of measurement for the prime meridian. Matches a value in the UOM_ID column of the SDO_UNITS_OF_MEASURE table (described in Section 6.6.27). Example:

`9110`

for sexagesimal degreeINFORMATION_SOURCE

VARCHAR2(254)

Origin of this information. Example:

`Bundesamt fur Landestopographie`

DATA_SOURCE

VARCHAR2(40)

Organization that supplied the data for this record (if not Oracle). Example:

`EPSG`

## 6.6.27 SDO_UNITS_OF_MEASURE Table

The SDO_UNITS_OF_MEASURE table contains one row for each unit of measurement. This table contains the columns shown in Table 6-26.

Table 6-26 SDO_UNITS_OF_MEASURE Table

Column Name Data Type Description UOM_ID

NUMBER(10)

ID number of the unit of measurement. Example:

`10032`

UNIT_OF_MEAS_NAME

VARCHAR2(80)

Name of the unit of measurement. Example:

`METER`

SHORT_NAME

VARCHAR2(80)

Short name (if any) of the unit of measurement.

UNIT_OF_MEAS_TYPE

VARCHAR2(80)

Type of measure for which the unit is used:

`angle`

for angle unit,`area`

for area unit, or`length`

for distance unit.TARGET_UOM_ID

NUMBER(10)

ID number of a target unit of measurement. Corresponds to the TARGET_UOM_CODE column in the EPSG Unit of Measure table, which has the following description: "Other UOM of the same type into which the current UOM can be converted using the formula (POSC); POSC factors A and D always equal zero for EPSG supplied units of measure."

FACTOR_B

NUMBER

Corresponds to the FACTOR_B column in the EPSG Unit of Measure table, which has the following description: "A quantity in the target UOM (y) is obtained from a quantity in the current UOM (x) through the conversion: y = (B/C).x"

FACTOR_C

NUMBER

Corresponds to the FACTOR_C column in the EPSG Unit of Measure table.

INFORMATION_SOURCE

VARCHAR2(254)

Origin of this information. Example:

`ISO 1000.`

DATA_SOURCE

VARCHAR2(40)

Organization providing the data for this record. Example:

`EPSG`

IS_LEGACY

VARCHAR2(5)

TRUE if the unit of measurement definition was included in Oracle Spatial before release 10.2; FALSE if the unit of measurement definition is new in Oracle Spatial release 10.2.

LEGACY_CODE

NUMBER(10)

For any EPSG unit of measure that has a semantically identical legacy (in Oracle Spatial before release 10.2) counterpart, the UOM_ID value of the legacy unit of measure.

## 6.7 Legacy Tables and Views

In previous releases of Spatial, the coordinate systems functions and procedures used information provided in the following tables, some of which have new names or are now views instead of tables:

MDSYS.CS_SRS (see Section 6.7.1) defined the valid coordinate systems. It associates each coordinate system with its well-known text description, which is in conformance with the standard published by the Open Geospatial Consortium (

`http://www.opengeospatial.org`

).MDSYS.SDO_ANGLE_UNITS (see Section 6.7.2) defines the valid angle units.

MDSYS.SDO_AREA_UNITS (see Section 6.7.3) defines the valid area units.

MDSYS.SDO_DIST_UNITS (see Section 6.7.5) defines the valid distance units.

MDSYS.SDO_DATUMS_OLD_FORMAT and MDSYS.SDO_DATUMS_OLD_SNAPSHOT (see Section 6.7.4) are based on the MDSYS.SDO_DATUMS table before release 10.2, which defined valid datums.

MDSYS.SDO_ELLIPSOIDS_OLD_FORMAT and MDSYS.SDO_ELLIPSOIDS_OLD_SNAPSHOT (see Section 6.7.6) are based on the MDSYS.SDO_ELLIPSOIDS table before release 10.2, which defined valid ellipsoids.

MDSYS.SDO_PROJECTIONS_OLD_FORMAT and MDSYS.SDO_PROJECTIONS_OLD_SNAPSHOT (see Section 6.7.7) are based on the MDSYS.SDO_PROJECTIONS table before release 10.2, which defined the valid map projections.

Note:

You should not modify or delete any Oracle-supplied information in these legacy tables.If you refer to a legacy table in a SQL statement, you must include the MDSYS. before the table name.

## 6.7.1 MDSYS.CS_SRS Table

The MDSYS.CS_SRS reference table contains over 4000 rows, one for each valid coordinate system. This table contains the columns shown in Table 6-27.

Table 6-27 MDSYS.CS_SRS Table

Column Name Data Type Description CS_NAME

VARCHAR2(68)

A well-known name, often mnemonic, by which a user can refer to the coordinate system.

SRID

NUMBER(38)

The unique ID number (Spatial Reference ID) for a coordinate system. Currently, SRID values 1-999999 are reserved for use by Oracle Spatial, and values 1000000 (1 million) and higher are available for user-defined coordinate systems.

AUTH_SRID

NUMBER(38)

An optional ID number that can be used to indicate how the entry was derived; it might be a foreign key into another coordinate table, for example.

AUTH_NAME

VARCHAR2(256)

An authority name for the coordinate system. Contains

`Oracle`

in the supplied table. Users can specify any value in any rows that they add.WKTEXT

VARCHAR2(2046)

The well-known text (WKT) description of the SRS, as defined by the Open Geospatial Consortium. For more information, see Section 6.7.1.1.

CS_BOUNDS

SDO_GEOMETRY

An optional SDO_GEOMETRY object that is a polygon with WGS 84 longitude and latitude vertices, representing the spheroidal polygon description of the zone of validity for a projected coordinate system. Must be null for a geographic or non-Earth coordinate system. Is null in all supplied rows.

## 6.7.1.1 Well-Known Text (WKT)

The WKTEXT column of the MDSYS.CS_SRS table contains the well-known text (WKT) description of the SRS, as defined by the Open Geospatial Consortium. The following is the WKT EBNF syntax.

<coordinate system> ::= <horz cs> | <local cs> <horz cs> ::= <geographic cs> | <projected cs> <projected cs> ::= PROJCS [ "<name>", <geographic cs>, <projection>, {<parameter>,}* <linear unit> ] <projection> ::= PROJECTION [ "<name>" ] <parameter> ::= PARAMETER [ "<name>", <number> ] <geographic cs> ::= GEOGCS [ "<name>", <datum>, <prime meridian>, <angular unit> ] <datum> ::= DATUM [ "<name>", <spheroid> {, <shift-x>, <shift-y>, <shift-z> , <rot-x>, <rot-y>, <rot-z>, <scale_adjust>} ] <spheroid> ::= SPHEROID ["<name>", <semi major axis>, <inverse flattening> ] <prime meridian> ::= PRIMEM ["<name>", <longitude> ] <longitude> ::= <number> <semi-major axis> ::= <number> <inverse flattening> ::= <number> <angular unit> ::= <unit> <linear unit> ::= <unit> <unit> ::= UNIT [ "<name>", <conversion factor> ] <local cs> ::= LOCAL_CS [ "<name>", <local datum>, <linear unit>, <axis> {, <axis>}* ] <local datum> ::= LOCAL_DATUM [ "<name>", <datum type> {, <shift-x>, <shift-y>, <shift-z> , <rot-x>, <rot-y>, <rot-z>, <scale_adjust>} ] <datum type> ::= <number> <axis> ::= AXIS [ "<name>", NORTH | SOUTH | EAST | WEST | UP | DOWN | OTHER ]Each

`<parameter>`

specification is one of the following:

`Standard_Parallel_1`

(in decimal degrees)

`Standard_Parallel_2`

(in decimal degrees)

`Central_Meridian`

(in decimal degrees)

`Latitude_of_Origin`

(in decimal degrees)

`Azimuth`

(in decimal degrees)

`False_Easting`

(in the unit of the coordinate system; for example, meters)

`False_Northing`

(in the unit of the coordinate system; for example, meters)

`Perspective_Point_Height`

(in the unit of the coordinate system; for example, meters)

`Landsat_Number`

(must be 1, 2, 3, 4, or 5)

`Path_Number`

`Scale_Factor`

The default value for each

`<parameter>`

specification is 0 (zero). That is, if a specification is needed for a projection but no value is specified in the WKT, Spatial uses a value of 0.The prime meridian (

`PRIMEM`

) is specified in decimal degrees of longitude.An example of the WKT for a geodetic (geographic) coordinate system is:

'GEOGCS [ "Longitude / Latitude (Old Hawaiian)", DATUM ["Old Hawaiian", SPHEROID ["Clarke 1866", 6378206.400000, 294.978698]], PRIMEM [ "Greenwich", 0.000000 ], UNIT ["Decimal Degree", 0.01745329251994330]]'The WKT definition of the coordinate system is hierarchically nested. The Old Hawaiian geographic coordinate system (GEOGCS) is composed of a named datum (DATUM), a prime meridian (PRIMEM), and a unit definition (UNIT). The datum is in turn composed of a named spheroid and its parameters of semi-major axis and inverse flattening.

An example of the WKT for a projected coordinate system (a Wyoming State Plane) is:

'PROJCS["Wyoming 4901, Eastern Zone (1983, meters)", GEOGCS [ "GRS 80", DATUM ["GRS 80", SPHEROID ["GRS 80", 6378137.000000, 298.257222]], PRIMEM [ "Greenwich", 0.000000 ], UNIT ["Decimal Degree", 0.01745329251994330]], PROJECTION ["Transverse Mercator"], PARAMETER ["Scale_Factor", 0.999938], PARAMETER ["Central_Meridian", -105.166667], PARAMETER ["Latitude_Of_Origin", 40.500000], PARAMETER ["False_Easting", 200000.000000], UNIT ["Meter", 1.000000000000]]'The projected coordinate system contains a nested geographic coordinate system as its basis, as well as parameters that control the projection.

Oracle Spatial supports all common geodetic datums and map projections.

An example of the WKT for a local coordinate system is:

LOCAL_CS [ "Non-Earth (Meter)", LOCAL_DATUM ["Local Datum", 0], UNIT ["Meter", 1.0], AXIS ["X", EAST], AXIS["Y", NORTH]]For more information about local coordinate systems, see Section 6.3.

You can use the SDO_CS.VALIDATE_WKT function, described in Chapter 13, to validate the WKT of any coordinate system defined in the MDSYS.CS_SRS table.

## 6.7.1.2 Procedures for Updating the Well-Known Text

If you insert or delete a row in the SDO_COORD_REF_SYSTEM view (described in Section 6.6.10), Spatial automatically updates the WKTEXT column in the MDSYS.CS_SRS table. (The format of the WKTEXT column is described in Section 6.7.1.1.) However, if you update an existing row in the SDO_COORD_REF_SYSTEM view, the well-known text (WKT) value is not automatically updated.

In addition, information relating to coordinate reference systems is also stored in several other system tables, including SDO_DATUMS (described in Section 6.6.22), SDO_ELLIPSOIDS (described in Section 6.6.23), and SDO_PRIME_MERIDIANS (described in Section 6.6.26). If you add, delete, or modify information in these tables, the WKTEXT values in the MDSYS.CS_SRS table are not automatically updated. For example, if you update an ellipsoid flattening value in the SDO_ELLIPSOIDS table, the well-known text string for the associated coordinate system is not updated.

However, you can manually update the WKTEXT values in the in the MDSYS.CS_SRS table by using any of several procedures whose names start with UPDATE_WKTS_FOR (for example, SDO_CS.UPDATE_WKTS_FOR_ALL_EPSG_CRS and SDO_CS.UPDATE_WKTS_FOR_EPSG_DATUM). If the display of SERVEROUTPUT information is enabled, these procedures display a message identifying the SRID value for each row in the MDSYS.CS_SRS table whose WKTEXT value is being updated. These procedures are described in Chapter 13.

## 6.7.2 MDSYS.SDO_ANGLE_UNITS View

The MDSYS.SDO_ANGLE_UNITS reference view contains one row for each valid angle UNIT specification in the well-known text (WKT) description in the coordinate system definition. The WKT is described in Section 6.7.1.1.

The MDSYS.SDO_ANGLE_UNITS view is based on the SDO_UNITS_OF MEASURE table (described in Section 6.6.27), and it contains the columns shown in Table 6-28.

Table 6-28 MDSYS.SDO_ANGLE_UNITS View

Column Name Data Type Description</th> SDO_UNIT

VARCHAR2(32)

Name of the angle unit (often a shortened form of the UNIT_NAME value). Use the SDO_UNIT value with the

`from_unit`

and`to_unit`

parameters of the SDO_UTIL.CONVERT_UNIT function.VARCHAR2(100)

Name of the angle unit. Specify a value from this column in the UNIT specification of the WKT for any user-defined coordinate system. Examples:

`Decimal Degree, Radian, Decimal Second, Decimal Minute, Gon, Grad`

.NUMBER

The ratio of the specified unit to one radian. For example, the ratio of

`Decimal Degree`

to`Radian`

is 0.017453293.## 6.7.3 MDSYS.SDO_AREA_UNITS View

The MDSYS.SDO_AREA_UNITS reference view contains one row for each valid area UNIT specification in the well-known text (WKT) description in the coordinate system definition. The WKT is described in Section 6.7.1.1.

The MDSYS.SDO_AREA_UNITS view is based on the SDO_UNITS_OF MEASURE table (described in Section 6.6.27), and it contains the columns shown in Table 6-29.

Table 6-29 SDO_AREA_UNITS View

Column Name Data Type Purpose VARCHAR2

Values are taken from the SHORT_NAME column of the SDO_UNITS_OF MEASURE table.

VARCHAR2

Values are taken from the UNIT_OF_MEAS_NAME column of the SDO_UNITS_OF MEASURE table.

NUMBER

Ratio of the unit to 1 square meter. For example, the conversion factor for a square meter is 1.0, and the conversion factor for a square mile is 2589988.

## 6.7.4 MDSYS.SDO_DATUMS_OLD_FORMAT and SDO_DATUMS_OLD_SNAPSHOT Tables

The MDSYS.SDO_DATUMS_OLD_FORMAT and MDSYS.SDO_DATUMS_OLD_SNAPSHOT reference tables contain one row for each valid DATUM specification in the well-known text (WKT) description in the coordinate system definition. (The WKT is described in Section 6.7.1.1.)

MDSYS.SDO_DATUMS_OLD_FORMAT contains the new data in the old format (that is, EPSG-based datum specifications in a table using the format from before release 10.2).

MDSYS.SDO_DATUMS_OLD_SNAPSHOT contains the old data in the old format (that is, datum specifications and table format from before release 10.2).

These tables contain the columns shown in Table 6-30.

Table 6-30 MDSYS.SDO_DATUMS_OLD_FORMAT and SDO_DATUMS_OLD_SNAPSHOT Tables

Column Name Data Type Description NAME

VARCHAR2(80) for OLD_FORMAT

VARCHAR2(64) for OLD_SNAPSHOT

Name of the datum. Specify a value (Oracle-supplied or user-defined) from this column in the DATUM specification of the WKT for any user-defined coordinate system. Examples:

`Adindan, Afgooye, Ain el Abd 1970, Anna 1 Astro 1965, Arc 1950, Arc 1960, Ascension Island 1958.`

SHIFT_X

NUMBER

SHIFT_Y

NUMBER

SHIFT_Z

NUMBER

ROTATE_X

NUMBER

Number of arc-seconds of rotation about the x-axis.

ROTATE_Y

NUMBER

Number of arc-seconds of rotation about the y-axis.

ROTATE_Z

NUMBER

Number of arc-seconds of rotation about the z-axis.

SCALE_ADJUST

NUMBER

^{-6})The following are the names (in tabular format) of the datums in these tables:

Adindan Afgooye Ain el Abd 1970 Anna 1 Astro 1965 Arc 1950 Arc 1960 Ascension Island 1958 Astro B4 Sorol Atoll Astro Beacon E Astro DOS 71/4 Astronomic Station 1952 Australian Geodetic 1966 Australian Geodetic 1984 Belgium Hayford Bellevue (IGN) Bermuda 1957 Bogota Observatory CH 1903 (Switzerland) Campo Inchauspe Canton Astro 1966 Cape Cape Canaveral Carthage Chatham 1971 Chua Astro Corrego Alegre DHDN (Potsdam/Rauenberg) DOS 1968 Djakarta (Batavia) Easter Island 1967 European 1950 European 1979 European 1987 GRS 67 GRS 80 GUX 1 Astro Gandajika Base Geodetic Datum 1949 Guam 1963 Hito XVIII 1963 Hjorsey 1955 Hong Kong 1963 Hu-Tzu-Shan ISTS 073 Astro 1969 Indian (Bangladesh, etc.) Indian (Thailand/Vietnam) Ireland 1965 Johnston Island 1961 Kandawala Kerguelen Island Kertau 1948 L.C. 5 Astro Liberia 1964 Lisboa (DLx) Luzon (Mindanao Island) Luzon (Philippines) Mahe 1971 Marco Astro Massawa Melrica 1973 (D73) Merchich Midway Astro 1961 Minna NAD 27 (Alaska) NAD 27 (Bahamas) NAD 27 (Canada) NAD 27 (Canal Zone) NAD 27 (Caribbean) NAD 27 (Central America) NAD 27 (Continental US) NAD 27 (Cuba) NAD 27 (Greenland) NAD 27 (Mexico) NAD 27 (Michigan) NAD 27 (San Salvador) NAD 83 NTF (Greenwich meridian) NTF (Paris meridian) NWGL 10 Nahrwan (Masirah Island) Nahrwan (Saudi Arabia) Nahrwan (Un. Arab Emirates) Naparima, BWI Netherlands Bessel Observatorio 1966 Old Egyptian Old Hawaiian Oman Ordinance Survey Great Brit Pico de las Nieves Pitcairn Astro 1967 Provisional South American Puerto Rico Pulkovo 1942 Qatar National Qornoq RT 90 (Sweden) Reunion Rome 1940 Santo (DOS) Sao Braz Sapper Hill 1943 Schwarzeck South American 1969 South Asia Southeast Base Southwest Base Timbalai 1948 Tokyo Tristan Astro 1968 Viti Levu 1916 WGS 60 WGS 66 WGS 72 WGS 84 Wake-Eniwetok 1960 Yacare Zanderij ## 6.7.5 MDSYS.SDO_DIST_UNITS View

The MDSYS.SDO_DIST_UNITS reference view contains one row for each valid distance UNIT specification in the well-known text (WKT) description in the coordinate system definition. The WKT is described in Section 6.7.1.1.

The MDSYS.SDO_DIST_UNITS view is based on the SDO_UNITS_OF MEASURE table (described in Section 6.6.27), and it contains the columns shown in Table 6-31.

Table 6-31 MDSYS.SDO_DIST_UNITS View

Column Name Data Type Description VARCHAR2

Values are taken from the SHORT_NAME column of the SDO_UNITS_OF MEASURE table.

VARCHAR2

Values are taken from the UNIT_OF_MEAS_NAME column of the SDO_UNITS_OF MEASURE table.

NUMBER

Ratio of the unit to 1 meter. For example, the conversion factor for a meter is 1.0, and the conversion factor for a mile is 1609.344.

## 6.7.6 MDSYS.SDO_ELLIPSOIDS_OLD_FORMAT and SDO_ELLIPSOIDS_OLD_SNAPSHOT Tables

The MDSYS.SDO_ELLIPSOIDS_OLD_FORMAT and MDSYS.SDO_ELLIPSOIDS_OLD_SNAPSHOT reference tables contain one row for each valid SPHEROID specification in the well-known text (WKT) description in the coordinate system definition. (The WKT is described in Section 6.7.1.1.)

MDSYS.SDO_ELLIPSOIDS_OLD_FORMAT contains the new data in the old format (that is, EPSG-based ellipsoid specifications in a table using the format from before release 10.2).

MDSYS.SDO_ELLIPSOIDS_OLD_SNAPSHOT contains the old data in the old format (that is, ellipsoid specifications and table format from before release 10.2).

These tables contain the columns shown in Table 6-32.

Table 6-32 MDSYS.SDO_ELLIPSOIDS_OLD_FORMAT and SDO_ELLIPSOIDS_OLD_SNAPSHOT Tables

Column Name Data Type Description NAME

VARCHAR2(80) for OLD_FORMAT

VARCHAR2(64) for OLD_SNAPSHOT

Name of the ellipsoid (spheroid). Specify a value from this column in the SPHEROID specification of the WKT for any user-defined coordinate system. Examples:

`Clarke 1866, WGS 72, Australian, Krassovsky, International 1924.`

NUMBER

Radius in meters along the semi-major axis (one-half of the long axis of the ellipsoid).

NUMBER

Inverse flattening of the ellipsoid. That is,

`1/f`

, where`f = (a-b)/a`

, and`a`

is the semi-major axis and`b`

is the semi-minor axis.The following are the names (in tabular format) of the ellipsoids in these tables:

Airy 1830 Airy 1830 (Ireland 1965) Australian Bessel 1841 Bessel 1841 (NGO 1948) Bessel 1841 (Schwarzeck) Clarke 1858 Clarke 1866 Clarke 1866 (Michigan) Clarke 1880 Clarke 1880 (Arc 1950) Clarke 1880 (IGN) Clarke 1880 (Jamaica) Clarke 1880 (Merchich) Clarke 1880 (Palestine) Everest Everest (Kalianpur) Everest (Kertau) Everest (Timbalai) Fischer 1960 (Mercury) Fischer 1960 (South Asia) Fischer 1968 GRS 67 GRS 80 Hayford Helmert 1906 Hough IAG 75 Indonesian International 1924 Krassovsky MERIT 83 NWL 10D NWL 9D New International 1967 OSU86F OSU91A Plessis 1817 South American 1969 Sphere (6370997m) Struve 1860 WGS 60 WGS 66 WGS 72 WGS 84 Walbeck War Office ## 6.7.7 MDSYS.SDO_PROJECTIONS_OLD_FORMAT and SDO_PROJECTIONS_OLD_SNAPSHOT Tables

The MDSYS.SDO_PROJECTIONS_OLD_FORMAT and MDSYS.SDO_PROJECTIONS_OLD_SNAPSHOT reference tables contain one row for each valid PROJECTION specification in the well-known text (WKT) description in the coordinate system definition. (The WKT is described in Section 6.7.1.1.)

MDSYS.SDO_PROJECTIONS_OLD_FORMAT contains the new data in the old format (that is, EPSG-based projection specifications in a table using the format from before release 10.2).

MDSYS.SDO_PROJECTIONS_OLD_SNAPSHOT contains the old data in the old format (that is, projection specifications and table format from before release 10.2).

These tables contains the column shown in Table 6-33.

Table 6-33 MDSYS.SDO_PROJECTIONS_OLD_FORMAT and SDO_PROJECTIONS_OLD_SNAPSHOT Tables

Column Name Data Type Description NAME

VARCHAR2(80) for OLD_FORMAT

VARCHAR2(64) for OLD_SNAPSHOT

Name of the map projection. Specify a value from this column in the PROJECTION specification of the WKT for any user-defined coordinate system. Examples:

`Geographic (Lat/Long), Universal Transverse Mercator, State Plane Coordinates, Albers Conical Equal Area.`

The following are the names (in tabular format) of the projections in these tables:

Alaska Conformal Albers Conical Equal Area Azimuthal Equidistant Bonne Cassini Cylindrical Equal Area Eckert IV Eckert VI Equidistant Conic Equirectangular Gall General Vertical Near-Side Perspective Geographic (Lat/Long) Gnomonic Hammer Hotine Oblique Mercator Interrupted Goode Homolosine Interrupted Mollweide Lambert Azimuthal Equal Area Lambert Conformal Conic Lambert Conformal Conic (Belgium 1972) Mercator Miller Cylindrical Mollweide New Zealand Map Grid Oblated Equal Area Orthographic Polar Stereographic Polyconic Robinson Sinusoidal Space Oblique Mercator State Plane Coordinates Stereographic Swiss Oblique Mercator Transverse Mercator Transverse Mercator Danish System 34 Jylland-Fyn Transverse Mercator Danish System 45 Bornholm Transverse Mercator Finnish KKJ Transverse Mercator Sjaelland Universal Transverse Mercator Van der Grinten Wagner IV Wagner VII ## 6.8 Creating a User-Defined Coordinate Reference System

If the coordinate systems supplied by Oracle are not sufficient for your needs, you can create user-defined coordinate reference systems.

Note:

As mentioned in Section 6.1.1, the terms coordinate system and coordinate reference system (CRS) are often used interchangeably, although coordinate reference systems must be Earth-based.The exact steps for creating a user-defined CRS depend on whether it is geodetic or projected. In both cases, supply information about the coordinate system (coordinate axes, axis names, unit of measurement, and so on). For a geodetic CRS, supply information about the datum (ellipsoid, prime meridian, and so on), as explained in Section 6.8.1. For a projected CRS, supply information about the source (geodetic) CRS and the projection (operation and parameters), as explained in Section 6.8.2.

For any user-defined coordinate system, the SRID value should be 1000000 (1 million) or higher.

## 6.8.1 Creating a Geodetic CRS

If the necessary unit of measurement, coordinate axes, SDO_COORD_SYS table row, ellipsoid, prime meridian, and datum are already defined, insert a row into the SDO_COORD_REF_SYSTEM view (described in Section 6.6.10) to define the new geodetic CRS.

Example 6-2 inserts the definition for a hypothetical geodetic CRS named

`My Own NAD27`

(which, except for its SRID and name, is the same as the`NAD27`

CRS supplied by Oracle).Example 6-2 Creating a User-Defined Geodetic Coordinate Reference System

INSERT INTO SDO_COORD_REF_SYSTEM ( SRID, COORD_REF_SYS_NAME, COORD_REF_SYS_KIND, COORD_SYS_ID, DATUM_ID, GEOG_CRS_DATUM_ID, SOURCE_GEOG_SRID, PROJECTION_CONV_ID, CMPD_HORIZ_SRID, CMPD_VERT_SRID, INFORMATION_SOURCE, DATA_SOURCE, IS_LEGACY, LEGACY_CODE, LEGACY_WKTEXT, LEGACY_CS_BOUNDS, IS_VALID, SUPPORTS_SDO_GEOMETRY) VALUES ( 9994267, 'My Own NAD27', 'GEOGRAPHIC2D', 6422, 6267, 6267, NULL, NULL, NULL, NULL, NULL, 'EPSG', 'FALSE', NULL, NULL, NULL, 'TRUE', 'TRUE');If the necessary information for the definition does not already exist, follow these steps, as needed, to define the information before you insert the row into the SDO_COORD_REF_SYSTEM view:

If the unit of measurement is not already defined in the SDO_UNITS_OF_MEASURE table (described in Section 6.6.27), insert a row into that table to define the new unit of measurement.

If the coordinate axes are not already defined in the SDO_COORD_AXES table (described in Section 6.6.1), insert one row into that table for each new coordinate axis.

If an appropriate entry for the coordinate system does not already exist in the SDO_COORD_SYS table (described in Section 6.6.11), insert a row into that table. Example 6-3 inserts the definition for a fictitious coordinate system.

Example 6-3 Inserting a Row into the SDO_COORD_SYS Table

INSERT INTO SDO_COORD_SYS ( COORD_SYS_ID, COORD_SYS_NAME, COORD_SYS_TYPE, DIMENSION, INFORMATION_SOURCE, DATA_SOURCE) VALUES ( 9876543, 'My custom CS. Axes: lat, long. Orientations: north, east. UoM: deg', 'ellipsoidal', 2, 'Myself', 'Myself');If the ellipsoid is not already defined in the SDO_ELLIPSOIDS table (described in Section 6.6.23), insert a row into that table to define the new ellipsoid.

If the prime meridian is not already defined in the SDO_PRIME_MERIDIANS table (described in Section 6.6.26), insert a row into that table to define the new prime meridian.

If the datum is not already defined in the SDO_DATUMS table (described in Section 6.6.22), insert a row into that table to define the new datum.

## 6.8.2 Creating a Projected CRS

If the necessary unit of measurement, coordinate axes, SDO_COORD_SYS table row, source coordinate system, projection operation, and projection parameters are already defined, insert a row into the SDO_COORD_REF_SYSTEM view (described in Section 6.6.10) to define the new projected CRS.

Example 6-4 inserts the definition for a hypothetical projected CRS named

`My Own NAD27 / Cuba Norte`

(which, except for its SRID and name, is the same as the`NAD27 / Cuba Norte`

CRS supplied by Oracle).Example 6-4 Creating a User-Defined Projected Coordinate Reference System

INSERT INTO SDO_COORD_REF_SYSTEM ( SRID, COORD_REF_SYS_NAME, COORD_REF_SYS_KIND, COORD_SYS_ID, DATUM_ID, GEOG_CRS_DATUM_ID, SOURCE_GEOG_SRID, PROJECTION_CONV_ID, CMPD_HORIZ_SRID, CMPD_VERT_SRID, INFORMATION_SOURCE, DATA_SOURCE, IS_LEGACY, LEGACY_CODE, LEGACY_WKTEXT, LEGACY_CS_BOUNDS, IS_VALID, SUPPORTS_SDO_GEOMETRY) VALUES ( 9992085, 'My Own NAD27 / Cuba Norte', 'PROJECTED', 4532, NULL, 6267, 4267, 18061, NULL, NULL, 'Institut Cubano di Hidrografia (ICH)', 'EPSG', 'FALSE', NULL, NULL, NULL, 'TRUE', 'TRUE');If the necessary information for the definition does not already exist, follow these steps, as needed, to define the information before you insert the row into the SDO_COORD_REF_SYSTEM view:

If the unit of measurement is not already defined in the SDO_UNITS_OF_MEASURE table (described in Section 6.6.27), insert a row into that table to define the new unit of measurement.

If the coordinate axes are not already defined in the SDO_COORD_AXES table (described in Section 6.6.1), insert one row into that table for each new coordinate axis.

If an appropriate entry for the coordinate system does not already exist in SDO_COORD_SYS table (described in Section 6.6.11), insert a row into that table. (See Example 6-3 in Section 6.8.1).

If the projection operation is not already defined in the SDO_COORD_OPS table (described in Section 6.6.8), insert a row into that table to define the new projection operation. Example 6-5 shows the statement used to insert information about coordinate operation ID 18061, which is supplied by Oracle.

Example 6-5 Inserting a Row into the SDO_COORD_OPS Table

INSERT INTO SDO_COORD_OPS ( COORD_OP_ID, COORD_OP_NAME, COORD_OP_TYPE, SOURCE_SRID, TARGET_SRID, COORD_TFM_VERSION, COORD_OP_VARIANT, COORD_OP_METHOD_ID, UOM_ID_SOURCE_OFFSETS, UOM_ID_TARGET_OFFSETS, INFORMATION_SOURCE, DATA_SOURCE, SHOW_OPERATION, IS_LEGACY, LEGACY_CODE, REVERSE_OP, IS_IMPLEMENTED_FORWARD, IS_IMPLEMENTED_REVERSE) VALUES ( 18061, 'Cuba Norte', 'CONVERSION', NULL, NULL, NULL, NULL, 9801, NULL, NULL, NULL, 'EPSG', 1, 'FALSE', NULL, 1, 1, 1);If the parameters for the projection operation are not already defined in the SDO_COORD_OP_PARAM_VALS table (described in Section 6.6.5), insert one row into that table for each new parameter. Example 6-6 shows the statement used to insert information about parameters with ID values 8801, 8802, 8805, 8806, and 8807, which are supplied by Oracle.

Example 6-6 Inserting a Row into the SDO_COORD_OP_PARAM_VALS Table

INSERT INTO SDO_COORD_OP_PARAM_VALS ( COORD_OP_ID, COORD_OP_METHOD_ID, PARAMETER_ID, PARAMETER_VALUE, PARAM_VALUE_FILE_REF, UOM_ID) VALUES ( 18061, 9801, 8801, 22.21, NULL, 9110); INSERT INTO SDO_COORD_OP_PARAM_VALS ( COORD_OP_ID, COORD_OP_METHOD_ID, PARAMETER_ID, PARAMETER_VALUE, PARAM_VALUE_FILE_REF, UOM_ID) VALUES ( 18061, 9801, 8802, -81, NULL, 9110); INSERT INTO SDO_COORD_OP_PARAM_VALS ( COORD_OP_ID, COORD_OP_METHOD_ID, PARAMETER_ID, PARAMETER_VALUE, PARAM_VALUE_FILE_REF, UOM_ID) VALUES ( 18061, 9801, 8805, .99993602, NULL, 9201); INSERT INTO SDO_COORD_OP_PARAM_VALS ( COORD_OP_ID, COORD_OP_METHOD_ID, PARAMETER_ID, PARAMETER_VALUE, PARAM_VALUE_FILE_REF, UOM_ID) VALUES ( 18061, 9801, 8806, 500000, NULL, 9001); INSERT INTO SDO_COORD_OP_PARAM_VALS ( COORD_OP_ID, COORD_OP_METHOD_ID, PARAMETER_ID, PARAMETER_VALUE, PARAM_VALUE_FILE_REF, UOM_ID) VALUES ( 18061, 9801, 8807, 280296.016, NULL, 9001);## 6.9 Notes and Restrictions with Coordinate Systems Support

The following notes and restrictions apply to coordinate systems support in the current release of Oracle Spatial.

If you have geodetic data, see Section 6.2 for additional considerations, guidelines, and restrictions.

## 6.9.1 Different Coordinate Systems for Geometries with Operators and Functions

For Spatial operators (described in Chapter 11) that take two geometries as input parameters, if the geometries are based on different coordinate systems, the query window (the second geometry) is transformed to the coordinate system of the first geometry before the operation is performed. This transformation is a temporary internal operation performed by Spatial; it does not affect any stored query-window geometry.

For SDO_GEOM package geometry functions (described in Chapter 15) that take two geometries as input parameters, both geometries must be based on the same coordinate system.

## 6.9.2 3D LRS Functions Not Supported with Geodetic Data

In the current release, the 3D formats of LRS functions (explained in Section 7.4) are not supported with geodetic data.

## 6.9.3 Functions Supported by Approximations with Geodetic Data

In the current release, the following functions are supported by approximations with geodetic data:

When these functions are used on data with geodetic coordinates, they internally perform the operations in an implicitly generated local-tangent-plane Cartesian coordinate system and then transform the results to the geodetic coordinate system. For SDO_GEOM.SDO_BUFFER, generated arcs are approximated by line segments before the back-transform.

## 6.9.4 Unknown CRS and NaC Coordinate Reference Systems

The following coordinate reference systems are provided for Oracle internal use and for other possible special uses:

`unknown CRS`

(SRID 999999) means that the coordinate system is unknown, and its space could be geodetic or Cartesian. Contrast this with specifying a null coordinate reference system, which indicates an unknown coordinate system with a Cartesian space.

`NaC`

(SRID 999998) means Not-a-CRS. Its name is patterned after the`NaN`

(Not-a-Number) value in Java. It is intended for potential use with nonspatial geometries.The following restrictions apply to geometries based on the

`unknown CRS`

and`NaC`

coordinate reference systems:

You cannot perform coordinate system transformations on these geometries.

Operations that require a coordinate system will return a null value when performed on these geometries. These operations include finding the area or perimeter of a geometry, creating a buffer, densifying an arc, and computing the aggregate centroid.

## 6.10 U.S. National Grid Support

The U.S. National Grid is a point coordinate representation using a single alphanumeric coordinate (for example, 18SUJ2348316806479498). This approach contrasts with the use of numeric coordinates to represent the location of a point, as is done with Oracle Spatial and EPSG. A good description of the U.S. National Grid is available at

`http://www.ngs.noaa.gov/TOOLS/usng.html`

.To support the U.S. National Grid in Spatial, the SDO_GEOMETRY type cannot be used because it is based on numeric coordinates. Instead, a point in U.S. National Grid format is represented as a single string of type VARCHAR2. To allow conversion between the SDO_GEOMETRY format and the U.S. National grid format, the SDO_CS package (documented in Chapter 13) contains the following functions:

## 6.11 Example of Coordinate System Transformation

This section presents a simplified example that uses coordinate system transformation functions and procedures. It refers to concepts that are explained in this chapter and uses functions documented in Chapter 13.

Example 6-7 uses mostly the same geometry data (cola markets) as in Section 2.1, except that instead of null SDO_SRID values, the SDO_SRID value 8307 is used. That is, the geometries are defined as using the coordinate system whose SRID is 8307 and whose well-known name is "Longitude / Latitude (WGS 84)". This is probably the most widely used coordinate system, and it is the one used for global positioning system (GPS) devices. The geometries are then transformed using the coordinate system whose SRID is 8199 and whose well-known name is "Longitude / Latitude (Arc 1950)".

Example 6-7 uses the geometries illustrated in Figure 2-1 in Section 2.1, except that

`cola_d`

is a rectangle (here, a square) instead of a circle, because arcs are not supported with geodetic coordinate systems.Example 6-7 does the following:

Creates a table (COLA_MARKETS_CS) to hold the spatial data

Inserts rows for four areas of interest (

`cola_a`

,`cola_b`

,`cola_c`

,`cola_d`

), using the SDO_SRID value 8307Updates the USER_SDO_GEOM_METADATA view to reflect the dimension of the areas, using the SDO_SRID value 8307

Creates a spatial index (COLA_SPATIAL_IDX_CS)

Performs some transformation operations (single geometry and entire layer)

Example 6-8 includes the output of the SELECT statements in Example 6-7.

Example 6-7 Simplified Example of Coordinate System Transformation

-- Create a table for cola (soft drink) markets in a -- given geography (such as city or state). CREATE TABLE cola_markets_cs ( mkt_id NUMBER PRIMARY KEY, name VARCHAR2(32), shape SDO_GEOMETRY); -- The next INSERT statement creates an area of interest for -- Cola A. This area happens to be a rectangle. -- The area could represent any user-defined criterion: for -- example, where Cola A is the preferred drink, where -- Cola A is under competitive pressure, where Cola A -- has strong growth potential, and so on. INSERT INTO cola_markets_cs VALUES( 1, 'cola_a', SDO_GEOMETRY( 2003, -- two-dimensional polygon 8307, -- SRID for 'Longitude / Latitude (WGS 84)' coordinate system NULL, SDO_ELEM_INFO_ARRAY(1,1003,1), -- polygon SDO_ORDINATE_ARRAY(1,1, 5,1, 5,7, 1,7, 1,1) -- All vertices must -- be defined for rectangle with geodetic data. ) ); -- The next two INSERT statements create areas of interest for -- Cola B and Cola C. These areas are simple polygons (but not -- rectangles). INSERT INTO cola_markets_cs VALUES( 2, 'cola_b', SDO_GEOMETRY( 2003, -- two-dimensional polygon 8307, NULL, SDO_ELEM_INFO_ARRAY(1,1003,1), -- one polygon (exterior polygon ring) SDO_ORDINATE_ARRAY(5,1, 8,1, 8,6, 5,7, 5,1) ) ); INSERT INTO cola_markets_cs VALUES( 3, 'cola_c', SDO_GEOMETRY( 2003, -- two-dimensional polygon 8307, NULL, SDO_ELEM_INFO_ARRAY(1,1003,1), --one polygon (exterior polygon ring) SDO_ORDINATE_ARRAY(3,3, 6,3, 6,5, 4,5, 3,3) ) ); -- Insert a rectangle (here, square) instead of a circle as in the original, -- because arcs are not supported with geodetic coordinate systems. INSERT INTO cola_markets_cs VALUES( 4, 'cola_d', SDO_GEOMETRY( 2003, -- two-dimensional polygon 8307, -- SRID for 'Longitude / Latitude (WGS 84)' coordinate system NULL, SDO_ELEM_INFO_ARRAY(1,1003,1), -- polygon SDO_ORDINATE_ARRAY(10,9, 11,9, 11,10, 10,10, 10,9) -- All vertices must -- be defined for rectangle with geodetic data. ) ); --------------------------------------------------------------------------- -- UPDATE METADATA VIEW -- --------------------------------------------------------------------------- -- Update the USER_SDO_GEOM_METADATA view. This is required -- before the Spatial index can be created. Do this only once for each -- layer (table-column combination; here: cola_markets_cs and shape). INSERT INTO user_sdo_geom_metadata (TABLE_NAME, COLUMN_NAME, DIMINFO, SRID) VALUES ( 'cola_markets_cs', 'shape', SDO_DIM_ARRAY( SDO_DIM_ELEMENT('Longitude', -180, 180, 10), -- 10 meters tolerance SDO_DIM_ELEMENT('Latitude', -90, 90, 10) -- 10 meters tolerance ), 8307 -- SRID for 'Longitude / Latitude (WGS 84)' coordinate system ); ------------------------------------------------------------------- -- CREATE THE SPATIAL INDEX -- ------------------------------------------------------------------- CREATE INDEX cola_spatial_idx_cs ON cola_markets_cs(shape) INDEXTYPE IS MDSYS.SPATIAL_INDEX; ------------------------------------------------------------------- -- TEST COORDINATE SYSTEM TRANSFORMATION -- ------------------------------------------------------------------- -- Return the transformation of cola_c using to_srid 8199 -- ('Longitude / Latitude (Arc 1950)') SELECT c.name, SDO_CS.TRANSFORM(c.shape, m.diminfo, 8199) FROM cola_markets_cs c, user_sdo_geom_metadata m WHERE m.table_name = 'COLA_MARKETS_CS' AND m.column_name = 'SHAPE' AND c.name = 'cola_c'; -- Same as preceding, but using to_srname parameter. SELECT c.name, SDO_CS.TRANSFORM(c.shape, m.diminfo, 'Longitude / Latitude (Arc 1950)') FROM cola_markets_cs c, user_sdo_geom_metadata m WHERE m.table_name = 'COLA_MARKETS_CS' AND m.column_name = 'SHAPE' AND c.name = 'cola_c'; -- Transform the entire SHAPE layer and put results in the table -- named cola_markets_cs_8199, which the procedure will create. CALL SDO_CS.TRANSFORM_LAYER('COLA_MARKETS_CS','SHAPE','COLA_MARKETS_CS_8199',8199); -- Select all from the old (existing) table. SELECT * from cola_markets_cs; -- Select all from the new (layer transformed) table. SELECT * from cola_markets_cs_8199; -- Show metadata for the new (layer transformed) table. DESCRIBE cola_markets_cs_8199; -- Use a geodetic MBR with SDO_FILTER. SELECT c.name FROM cola_markets_cs c WHERE SDO_FILTER(c.shape, SDO_GEOMETRY( 2003, 8307, -- SRID for WGS 84 longitude/latitude NULL, SDO_ELEM_INFO_ARRAY(1,1003,3), SDO_ORDINATE_ARRAY(6,5, 10,10)) ) = 'TRUE';Example 6-8 shows the output of the SELECT statements in Example 6-7. Notice the slight differences between the coordinates in the original geometries (SRID 8307) and the transformed coordinates (SRID 8199) -- for example, (1, 1, 5, 1, 5, 7, 1, 7, 1, 1) and (1.00078604, 1.00274579, 5.00069354, 1.00274488, 5.0006986, 7.00323528, 1.00079179, 7.00324162, 1.00078604, 1.00274579) for

`cola_a`

.Example 6-8 Output of SELECT Statements in Coordinate System Transformation Example

SQL> -- Return the transformation of cola_c using to_srid 8199 SQL> -- ('Longitude / Latitude (Arc 1950)') SQL> SELECT c.name, SDO_CS.TRANSFORM(c.shape, m.diminfo, 8199) 2 FROM cola_markets_cs c, user_sdo_geom_metadata m 3 WHERE m.table_name = 'COLA_MARKETS_CS' AND m.column_name = 'SHAPE' 4 AND c.name = 'cola_c'; NAME -------------------------------- SDO_CS.TRANSFORM(C.SHAPE,M.DIMINFO,8199)(SDO_GTYPE, SDO_SRID, SDO_POINT(X, Y, Z) -------------------------------------------------------------------------------- cola_c SDO_GEOMETRY(2003, 8199, NULL, SDO_ELEM_INFO_ARRAY(1, 1003, 1), SDO_ORDINATE_ARR AY(3.00074114, 3.00291482, 6.00067068, 3.00291287, 6.0006723, 5.00307625, 4.0007 1961, 5.00307838, 3.00074114, 3.00291482)) SQL> SQL> -- Same as preceding, but using to_srname parameter. SQL> SELECT c.name, SDO_CS.TRANSFORM(c.shape, m.diminfo, 'Longitude / Latitude (Arc 1950)') 2 FROM cola_markets_cs c, user_sdo_geom_metadata m 3 WHERE m.table_name = 'COLA_MARKETS_CS' AND m.column_name = 'SHAPE' 4 AND c.name = 'cola_c'; NAME -------------------------------- SDO_CS.TRANSFORM(C.SHAPE,M.DIMINFO,'LONGITUDE/LATITUDE(ARC1950)')(SDO_GTYPE, SDO -------------------------------------------------------------------------------- cola_c SDO_GEOMETRY(2003, 8199, NULL, SDO_ELEM_INFO_ARRAY(1, 1003, 1), SDO_ORDINATE_ARR AY(3.00074114, 3.00291482, 6.00067068, 3.00291287, 6.0006723, 5.00307625, 4.0007 1961, 5.00307838, 3.00074114, 3.00291482)) SQL> SQL> -- Transform the entire SHAPE layer and put results in the table SQL> -- named cola_markets_cs_8199, which the procedure will create. SQL> CALL SDO_CS.TRANSFORM_LAYER('COLA_MARKETS_CS','SHAPE','COLA_MARKETS_CS_8199',8199); Call completed. SQL> SQL> -- Select all from the old (existing) table. SQL> SELECT * from cola_markets_cs; MKT_ID NAME ---------- -------------------------------- SHAPE(SDO_GTYPE, SDO_SRID, SDO_POINT(X, Y, Z), SDO_ELEM_INFO, SDO_ORDINATES) -------------------------------------------------------------------------------- 1 cola_a SDO_GEOMETRY(2003, 8307, NULL, SDO_ELEM_INFO_ARRAY(1, 1003, 1), SDO_ORDINATE_ARR AY(1, 1, 5, 1, 5, 7, 1, 7, 1, 1)) 2 cola_b SDO_GEOMETRY(2003, 8307, NULL, SDO_ELEM_INFO_ARRAY(1, 1003, 1), SDO_ORDINATE_ARR AY(5, 1, 8, 1, 8, 6, 5, 7, 5, 1)) 3 cola_c MKT_ID NAME ---------- -------------------------------- SHAPE(SDO_GTYPE, SDO_SRID, SDO_POINT(X, Y, Z), SDO_ELEM_INFO, SDO_ORDINATES) -------------------------------------------------------------------------------- SDO_GEOMETRY(2003, 8307, NULL, SDO_ELEM_INFO_ARRAY(1, 1003, 1), SDO_ORDINATE_ARR AY(3, 3, 6, 3, 6, 5, 4, 5, 3, 3)) 4 cola_d SDO_GEOMETRY(2003, 8307, NULL, SDO_ELEM_INFO_ARRAY(1, 1003, 1), SDO_ORDINATE_ARR AY(10, 9, 11, 9, 11, 10, 10, 10, 10, 9)) SQL> SQL> -- Select all from the new (layer transformed) table. SQL> SELECT * from cola_markets_cs_8199; SDO_ROWID ------------------ GEOMETRY(SDO_GTYPE, SDO_SRID, SDO_POINT(X, Y, Z), SDO_ELEM_INFO, SDO_ORDINATES) -------------------------------------------------------------------------------- AAABZzAABAAAOa6AAA SDO_GEOMETRY(2003, 8199, NULL, SDO_ELEM_INFO_ARRAY(1, 1003, 1), SDO_ORDINATE_ARR AY(1.00078604, 1.00274579, 5.00069354, 1.00274488, 5.0006986, 7.00323528, 1.0007 9179, 7.00324162, 1.00078604, 1.00274579)) AAABZzAABAAAOa6AAB SDO_GEOMETRY(2003, 8199, NULL, SDO_ELEM_INFO_ARRAY(1, 1003, 1), SDO_ORDINATE_ARR AY(5.00069354, 1.00274488, 8.00062191, 1.00274427, 8.00062522, 6.00315345, 5.000 6986, 7.00323528, 5.00069354, 1.00274488)) SDO_ROWID ------------------ GEOMETRY(SDO_GTYPE, SDO_SRID, SDO_POINT(X, Y, Z), SDO_ELEM_INFO, SDO_ORDINATES) -------------------------------------------------------------------------------- AAABZzAABAAAOa6AAC SDO_GEOMETRY(2003, 8199, NULL, SDO_ELEM_INFO_ARRAY(1, 1003, 1), SDO_ORDINATE_ARR AY(3.00074114, 3.00291482, 6.00067068, 3.00291287, 6.0006723, 5.00307625, 4.0007 1961, 5.00307838, 3.00074114, 3.00291482)) AAABZzAABAAAOa6AAD SDO_GEOMETRY(2003, 8199, NULL, SDO_ELEM_INFO_ARRAY(1, 1003, 1), SDO_ORDINATE_ARR AY(10.0005802, 9.00337775, 11.0005553, 9.00337621, 11.0005569, 10.0034478, 10.00 SDO_ROWID ------------------ GEOMETRY(SDO_GTYPE, SDO_SRID, SDO_POINT(X, Y, Z), SDO_ELEM_INFO, SDO_ORDINATES) -------------------------------------------------------------------------------- 05819, 10.0034495, 10.0005802, 9.00337775)) SQL> SQL> -- Show metadata for the new (layer transformed) table. SQL> DESCRIBE cola_markets_cs_8199; Name Null? Type ----------------------------------------- -------- ---------------------------- SDO_ROWID ROWID GEOMETRY SDO_GEOMETRY SQL> SQL> -- Use a geodetic MBR with SDO_FILTER SQL> SELECT c.name FROM cola_markets_cs c WHERE 2 SDO_FILTER(c.shape, 3 SDO_GEOMETRY( 4 2003, 5 8307, -- SRID for WGS 84 longitude/latitude 6 NULL, 7 SDO_ELEM_INFO_ARRAY(1,1003,3), 8 SDO_ORDINATE_ARRAY(6,5, 10,10)) 9 ) = 'TRUE'; NAME -------------------------------- cola_c cola_b cola_dLoading Spatial Data PK-))PKlUIOEBPS/sdo_cs_ref.htm## 3 Loading Spatial Data

This chapter describes how to load spatial data into a database, including storing the data in a table with a column of type SDO_GEOMETRY. After you have loaded spatial data, you can create a spatial index for it and perform queries on it, as described in Chapter 4.

The process of loading data can be classified into two categories:

Bulk loading of data (see Section 3.1)

This process is used to load large volumes of data into the database and uses the SQL*Loader utility to load the data.

Transactional insert operations (see Section 3.2)

This process is typically used to insert relatively small amounts of data into the database using the INSERT statement in SQL.

## 3.1 Bulk Loading

Bulk loading can import large amounts of data into an Oracle database. Bulk loading is accomplished with the SQL*Loader utility. (For information about SQL*Loader, see Oracle Database Utilities.)

## 3.1.1 Bulk Loading SDO_GEOMETRY Objects

Example 3-1 is the SQL*Loader control file for loading four geometries. When this control file is used with SQL*Loader, it loads the same cola market geometries that are inserted using SQL statements in Example 2-1 in Section 2.1.

Example 3-1 Control File for a Bulk Load of Cola Market Geometries

LOAD DATA INFILE * TRUNCATE CONTINUEIF NEXT(1:1) = '#' INTO TABLE COLA_MARKETS FIELDS TERMINATED BY '|' TRAILING NULLCOLS ( mkt_id INTEGER EXTERNAL, name CHAR, shape COLUMN OBJECT ( SDO_GTYPE INTEGER EXTERNAL, SDO_ELEM_INFO VARRAY TERMINATED BY '|/' (elements FLOAT EXTERNAL), SDO_ORDINATES VARRAY TERMINATED BY '|/' (ordinates FLOAT EXTERNAL) ) ) begindata 1|cola_a| #2003|1|1003|3|/ #1|1|5|7|/ 2|cola_b| #2003|1|1003|1|/ #5|1|8|1|8|6|5|7|5|1|/ 3|cola_c| #2003|1|1003|1|/ #3|3|6|3|6|5|4|5|3|3|/ 4|cola_d| #2003|1|1003|4|/ #8|7|10|9|8|11|/Notes on Example 3-1:

The

`EXTERNAL`

keyword in the definition`mkt_id INTEGER EXTERNAL`

means that each value to be inserted into the MKT_ID column (1, 2, 3, and 4 in this example) is an integer in human-readable form, not binary format.In the data after

`begindata`

, each MKT_ID value is preceded by one space, because the`CONTINUEIF NEXT(1:1) = '#'`

specification causes the first position of each data line to be ignored unless it is the number sign (#) continuation character.Example 3-2 assumes that a table named POLY_4PT was created as follows:

CREATE TABLE POLY_4PT (GID VARCHAR2(32), GEOMETRY SDO_GEOMETRY);Assume that the ASCII data consists of a file with delimited columns and separate rows fixed by the limits of the table with the following format:

geometry rows: GID, GEOMETRYThe coordinates in the GEOMETRY column represent polygons. Example 3-2 shows the control file for loading the data.

Example 3-2 Control File for a Bulk Load of Polygons

LOAD DATA INFILE * TRUNCATE CONTINUEIF NEXT(1:1) = '#' INTO TABLE POLY_4PT FIELDS TERMINATED BY '|' TRAILING NULLCOLS ( GID INTEGER EXTERNAL, GEOMETRY COLUMN OBJECT ( SDO_GTYPE INTEGER EXTERNAL, SDO_ELEM_INFO VARRAY TERMINATED BY '|/' (elements FLOAT EXTERNAL), SDO_ORDINATES VARRAY TERMINATED BY '|/' (ordinates FLOAT EXTERNAL) ) ) begindata 1|2003|1|1003|1|/ #-122.4215|37.7862|-122.422|37.7869|-122.421|37.789|-122.42|37.7866| #-122.4215|37.7862|/ 2|2003|1|1003|1|/ #-122.4019|37.8052|-122.4027|37.8055|-122.4031|37.806|-122.4012|37.8052| #-122.4019|37.8052|/ 3|2003|1|1003|1|/ #-122.426|37.803|-122.4242|37.8053|-122.42355|37.8044|-122.4235|37.8025| #-122.426|37.803|/## 3.1.2 Bulk Loading Point-Only Data in SDO_GEOMETRY Objects

Example 3-3 shows a control file for loading a table with point data.

Example 3-3 Control File for a Bulk Load of Point-Only Data

LOAD DATA INFILE * TRUNCATE CONTINUEIF NEXT(1:1) = '#' INTO TABLE POINT FIELDS TERMINATED BY '|' TRAILING NULLCOLS ( GID INTEGER EXTERNAL, GEOMETRY COLUMN OBJECT ( SDO_GTYPE INTEGER EXTERNAL, SDO_POINT COLUMN OBJECT (X FLOAT EXTERNAL, Y FLOAT EXTERNAL) ) ) BEGINDATA 1| 2001| -122.4215| 37.7862| 2| 2001| -122.4019| 37.8052| 3| 2001| -122.426| 37.803| 4| 2001| -122.4171| 37.8034| 5| 2001| -122.416151| 37.8027228|## 3.2 Transactional Insert Operations Using SQL

Oracle Spatial uses standard Oracle tables that can be accessed or loaded with standard SQL syntax. This section contains examples of transactional insertions into columns of type SDO_GEOMETRY. This process is typically used to add relatively small amounts of data into the database.

The INSERT statement in Oracle SQL has a limit of 999 arguments. Therefore, you cannot create a variable-length array of more than 999 elements using the SDO_GEOMETRY constructor inside a transactional INSERT statement; however, you can insert a geometry using a host variable, and the host variable can be built using the SDO_GEOMETRY constructor with more than 999 values in the SDO_ORDINATE_ARRAY specification. (The host variable is an OCI, PL/SQL, or Java program variable.)

To perform transactional insertions of geometries, you can create a procedure to insert a geometry, and then invoke that procedure on each geometry to be inserted. Example 3-4 creates a procedure to perform the insert operation.

Example 3-4 Procedure to Perform a Transactional Insert Operation

CREATE OR REPLACE PROCEDURE INSERT_GEOM(GEOM SDO_GEOMETRY) IS BEGIN INSERT INTO TEST_1 VALUES (GEOM); COMMIT; END; /Using the procedure created in Example 3-4, you can insert data by using a PL/SQL block, such as the one in Example 3-5, which loads a geometry into the variable named

`geom`

and then invokes the INSERT_GEOM procedure to insert that geometry.Example 3-5 PL/SQL Block Invoking a Procedure to Insert a Geometry

DECLARE geom SDO_geometry := SDO_geometry (2003, null, null, SDO_elem_info_array (1,1003,3), SDO_ordinate_array (-109,37,-102,40)); BEGIN INSERT_GEOM(geom); COMMIT; END; /For additional examples with various geometry types, see the following:

Rectangle: Example 2-4 in Section 2.5.1

Polygon with a hole: Example 2-5 in Section 2.5.2

Compound line string: Example 2-6 in Section 2.5.3

Compound polygon: Example 2-7 in Section 2.5.4

Point: Example 2-8 and Example 2-9 in Section 2.5.5

Oriented point: Example 2-10 in Section 2.5.6

Type 0 (zero) element: Example 2-12 in Section 2.5.7

SDO_CS Package (Coordinate System Transformation) PK+ޓr^PKlUIOEBPS/sdo_prtusage.htm## 13 SDO_CS Package (Coordinate System Transformation)

The MDSYS.SDO_CS package contains subprograms for working with coordinate systems. You can perform explicit coordinate transformations on a single geometry or an entire layer of geometries (that is, all geometries in a specified column in a table).

To use the subprograms in this chapter, you must understand the conceptual information about coordinate systems in Section 1.5.4 and Chapter 6.

Table 13-1 lists the coordinate system transformation subprograms.

Table 13-1 Subprograms for Coordinate System Transformation

Subprogram Description Adds a preference for an operation between a source coordinate system and a target coordinate system.

Converts a NADCON (North American Datum Conversion) grid in ASCII format to an Oracle Spatial XML representation.

Converts an NTv2 (National Transformation Version 2) grid in ASCII format to an Oracle Spatial XML representation.

Converts an Oracle Spatial XML representation of a NADCON (North American Datum Conversion) grid to NADCON ASCII format.

Converts an Oracle Spatial XML representation of an NTv2 (National Transformation Version 2) grid to NTv2 ASCII format.

Creates a concatenated operation.

SDO_CS.CREATE_OBVIOUS_EPSG_RULES

Creates a basic set of EPSG rules to be applied in certain transformations.

SDO_CS.CREATE_PREF_CONCATENATED_OP

Creates a concatenated operation, associating it with a transformation plan and making it preferred either systemwide or for a specified use case.

Deletes the basic set of EPSG rules to be applied in certain transformations.

Deletes a concatenated operation.

Returns the query chain, based on the system rule set, to be used in transformations from one coordinate reference system to another coordinate reference system.

SDO_CS.DETERMINE_DEFAULT_CHAIN

Returns the default chain of SRID values in transformations from one coordinate reference system to another coordinate reference system.

Returns the SRID values of geodetic (geographic) coordinate reference systems that have the same well-known text (WKT) numeric values as the coordinate reference system with the specified reference SRID value.

Returns the SRID values of projected coordinate reference systems that have the same well-known text (WKT) numeric values as the coordinate reference system with the specified reference SRID value.

SDO_CS.FROM_OGC_SIMPLEFEATURE_SRS

Converts a well-known text string from the Open Geospatial Consortium simple feature format without the

`TOWGS84`

keyword to the format that includes the`TOWGS84`

keyword.SDO_CS.MAP_EPSG_SRID_TO_ORACLE

Returns the ORacle Spatial SRID values corresponding to the specified EPSG SRID value.

SDO_CS.MAP_ORACLE_SRID_TO_EPSG

Returns the EPSG SRID value corresponding to the specified Oracle Spatial SRID value.

SDO_CS.REVOKE_PREFERENCE_FOR_OP

Revokes a preference for an operation between a source coordinate system and a target coordinate system.

SDO_CS.TO_OGC_SIMPLEFEATURE_SRS

Converts a well-known text string from the Open Geospatial Consortium simple feature format that includes the

`TOWGS84`

keyword to the format without the`TOWGS84`

keyword.Transforms a geometry representation using a coordinate system (specified by SRID or name).

Transforms an entire layer of geometries (that is, all geometries in a specified column in a table).

SDO_CS.UPDATE_WKTS_FOR_ALL_EPSG_CRS

Updates the well-known text (WKT) description for all EPSG coordinate reference systems.

SDO_CS.UPDATE_WKTS_FOR_EPSG_CRS

Updates the well-known text (WKT) description for the EPSG coordinate reference system associated with a specified SRID.

SDO_CS.UPDATE_WKTS_FOR_EPSG_DATUM

Updates the well-known text (WKT) description for all EPSG coordinate reference systems associated with a specified datum.

SDO_CS.UPDATE_WKTS_FOR_EPSG_ELLIPS

Updates the well-known text (WKT) description for all EPSG coordinate reference systems associated with a specified ellipsoid.

SDO_CS.UPDATE_WKTS_FOR_EPSG_OP

Updates the well-known text (WKT) description for all EPSG coordinate reference systems associated with a specified coordinate transformation operation.

SDO_CS.UPDATE_WKTS_FOR_EPSG_PARAM

Updates the well-known text (WKT) description for all EPSG coordinate reference systems associated with a specified coordinate transformation operation and parameter for transformation operations.

SDO_CS.UPDATE_WKTS_FOR_EPSG_PM

Updates the well-known text (WKT) description for all EPSG coordinate reference systems associated with a specified prime meridian.

Validates the well-known text (WKT) description associated with a specified SRID.

SDO_CS.VIEWPORT_TRANSFORM (deprecated)

Transforms an optimized rectangle into a valid polygon for use with Spatial operators and functions.

The rest of this chapter provides reference information on the subprograms, listed in alphabetical order.

## SDO_CS.ADD_PREFERENCE_FOR_OP

Format

SDO_CS.ADD_PREFERENCE_FOR_OP(

op_id IN NUMBER,

source_crs IN NUMBER DEFAULT NULL,

target_crs IN NUMBER DEFAULT NULL,

use_case IN VARCHAR2 DEFAULT NULL);

Description

Adds a preference for an operation between a source coordinate system and a target coordinate system.

Parameters

- op_id
ID number of the operation. Must be a value in the COORD_OP_ID column of the SDO_COORD_OPS table (described in Section 6.6.8).

- source_crs
The SRID of the source coordinate reference system. Must be null or a value in the SRID column of the SDO_COORD_REF_SYS table (described in Section 6.6.9).

- target_crs
The SRID of the target coordinate reference system. Must be null or a value in the SRID column of the SDO_COORD_REF_SYS table (described in Section 6.6.9).

- use_case
Name of the use case to be associated with this preference. Must be null or a value from the USE_CASE column of the SDO_PREFERRED_OPS_USER table (described in Section 6.6.25).

Usage Notes

If

`use_case`

is null, the transformation plan associated with the operation is a systemwide preference, and a row is added (or two rows are added if a reverse operation exists) to the SDO_PREFERRED_OPS_SYSTEM table (described in Section 6.6.24). If`use_case`

is not null, the transformation plan associated with the operation is a preference associated with the specified use case, and a row is added (or two rows are added if a reverse operation exists) to the SDO_PREFERRED_OPS_USER table (described in Section 6.6.25).To create a concatenated operation and make it preferred either systemwide or for a specified use case, you can use the SDO_CS.CREATE_PREF_CONCATENATED_OP convenience procedure.

To revoke a preference for an operation between a source coordinate system and a target coordinate system, use the SDO_CS.REVOKE_PREFERENCE_FOR_OP procedure.

Examples

The following example adds a preference for operation 19977 to be used in transformations from SRID 4301 to SRID 4326 when use case use_case_B is specified for the transformation.

EXECUTE SDO_CS.ADD_PREFERENCE_FOR_OP(19977, 4301, 4326, 'use_case_B');

## SDO_CS.CONVERT_NADCON_TO_XML

Format

SDO_CS.CONVERT_NADCON_TO_XML(

laa_clob IN CLOB,

loa_clob IN CLOB,

xml_grid OUT XMLTYPE );

Description

Converts a NADCON (North American Datum Conversion) grid in ASCII format to an Oracle Spatial XML representation.

Parameters

- laa_clob
Latitude values of the NADCON grid in a CLOB object.

- loa_clob
Longitude values of the NADCON grid in a CLOB object.

- xml_grid
Output XML document containing the Oracle Spatial XML representation of the NADCON grid.

Usage Notes

To convert an Oracle Spatial XML representation to a NADCON grid, use the SDO_CS.CONVERT_XML_TO_NADCON procedure.

Examples

The following example converts a NADCON grid in ASCII format to an Oracle Spatial XML representation, converts the resulting XML representation back to a NADCON ASCII representation, and displays the resulting ASCII representation. (Only part of the output is shown.)

set lines 32000 set long 2000000000 DECLARE laa CLOB; loa CLOB; xml XMLTYPE; laa_file BFILE; loa_file BFILE; BEGIN laa_file := BFILENAME('MY_WORK_DIR', 'samplenadcon.laa'); loa_file := BFILENAME('MY_WORK_DIR', 'samplenadcon.loa'); DBMS_LOB.OPEN(laa_file, DBMS_LOB.LOB_READONLY); DBMS_LOB.OPEN(loa_file, DBMS_LOB.LOB_READONLY); DBMS_LOB.CREATETEMPORARY(laa, TRUE, DBMS_LOB.SESSION); DBMS_LOB.CREATETEMPORARY(loa, TRUE, DBMS_LOB.SESSION); DBMS_LOB.OPEN(laa, DBMS_LOB.LOB_READWRITE); DBMS_LOB.OPEN(loa, DBMS_LOB.LOB_READWRITE); DBMS_LOB.LOADFROMFILE(laa, laa_file, DBMS_LOB.LOBMAXSIZE); DBMS_LOB.LOADFROMFILE(loa, loa_file, DBMS_LOB.LOBMAXSIZE); DBMS_LOB.CLOSE(laa); DBMS_LOB.CLOSE(loa); DBMS_LOB.CLOSE(laa_file); DBMS_LOB.CLOSE(loa_file); SDO_CS.convert_NADCON_to_XML(laa, loa, xml); SDO_CS.convert_XML_to_NADCON(xml, laa, loa); DBMS_OUTPUT.PUT_LINE(SUBSTR(laa, 1, 32000)); DBMS_OUTPUT.PUT_LINE(SUBSTR(loa, 1, 32000)); END; / NADCON EXTRACTED REGION NADGRD 33 49 1 -107.00000 .25000 25.00000 .25000 .00000 .006731 .006444 .006208 .006036 .005935 .005904 .005932 .006002 .006092 .006174 .006218 .006198 .006087 .005867 .005522 .005045 .004432 .003688 .002818 .001836 .000759 -.000385 -.001559 -.002704 . . . NADCON EXTRACTED REGION NADGRD 33 49 1 -107.00000 .25000 25.00000 .25000 .00000 .008509 .007147 .005756 .004331 .002879 .001410 -.000060 -.001507 -.002904 -.004222 -.005431 -.006498 -.007395 -.008095 -.008579 -.008832 -.008848 -.008632 -.008200 -.007577 -.006800 -.005911 -.004957 -.003974 . . .

## SDO_CS.CONVERT_NTV2_TO_XML

Format

SDO_CS.CONVERT_NTV2_TO_XML(

ntv2_clob IN CLOB,

xml_grid OUT XMLTYPE );

Description

Converts an NTv2 (National Transformation Version 2) grid in ASCII format to an Oracle Spatial XML representation.

Parameters

- ntv2_clob
NTv2 grid values in a CLOB object.

- xml_grid
Output XML document containing the Oracle Spatial XML representation of the NTv2 grid.

Usage Notes

To convert an Oracle Spatial XML representation to an NTv2 grid, use the SDO_CS.CONVERT_XML_TO_NTV2 procedure.

Examples

The following example converts an NTv2 grid in ASCII format to an Oracle Spatial XML representation, converts the resulting XML representation back to an NTv2 ASCII representation, and displays the resulting ASCII representation. (Only part of the output is shown.)

set lines 32000 set long 2000000000 DECLARE ntv2 CLOB; xml XMLTYPE; ntv2_file BFILE; BEGIN ntv2_file := BFILENAME('MY_WORK_DIR', 'samplentv2.gsa'); DBMS_LOB.OPEN(ntv2_file, DBMS_LOB.LOB_READONLY); DBMS_LOB.CREATETEMPORARY(ntv2, TRUE, DBMS_LOB.SESSION); DBMS_LOB.OPEN(ntv2, DBMS_LOB.LOB_READWRITE); DBMS_LOB.LOADFROMFILE(ntv2, ntv2_file, DBMS_LOB.LOBMAXSIZE); DBMS_LOB.CLOSE(ntv2); DBMS_LOB.CLOSE(ntv2_file); SDO_CS.convert_NTv2_to_XML(ntv2, xml); SDO_CS.convert_XML_to_NTv2(xml, ntv2); DBMS_OUTPUT.PUT_LINE(SUBSTR(ntv2, 1, 32000)); END; / NUM_OREC 11 NUM_SREC 11 NUM_FILE 2 GS_TYPE SECONDS VERSION NTv2.0 DATUM_F NAD27 DATUM_T NAD83 MAJOR_F 6378206.400 MINOR_F 6356583.800 MAJOR_T 6378137.000 MINOR_T 6356752.314 SUB_NAMEALbanff PARENT NONE CREATED 95-06-29 UPDATED 95-07-04 S_LAT 183900.000000 N_LAT 184500.000000 E_LONG 415800.000000 W_LONG 416100.000000 LAT_INC 30.000000 LONG_INC 30.000000 GS_COUNT 231 0.084020 3.737300 0.005000 0.008000 0.083029 3.738740 0.017000 0.011000 0.082038 3.740180 0.029000 0.015000 . . .

## SDO_CS.CONVERT_XML_TO_NADCON

Format

SDO_CS.CONVERT_XML_TO_NADCON(

xml_grid IN XMLTYPE,

laa_clob OUT CLOB,

loa_clob OUT CLOB);

Description

Converts an Oracle Spatial XML representation of a NADCON (North American Datum Conversion) grid to NADCON ASCII format.

Parameters

- xml_grid
XML document containing the Oracle Spatial XML representation of the NADCON grid.

- laa_clob
Output CLOB object containing the latitude values of the NADCON grid.

- loa_clob
Output CLOB object containing the longitude values of the NADCON grid.

Usage Notes

To convert a NADCON grid in ASCII format to an Oracle Spatial XML representation, use the SDO_CS.CONVERT_NADCON_TO_XML procedure.

Examples

The following example converts a NADCON grid in ASCII format to an Oracle Spatial XML representation, converts the resulting XML representation back to a NADCON ASCII representation, and displays the resulting ASCII representation. (Only part of the output is shown.)

set lines 32000 set long 2000000000 DECLARE laa CLOB; loa CLOB; xml XMLTYPE; laa_file BFILE; loa_file BFILE; BEGIN laa_file := BFILENAME('MY_WORK_DIR', 'samplenadcon.laa'); loa_file := BFILENAME('MY_WORK_DIR', 'samplenadcon.loa'); DBMS_LOB.OPEN(laa_file, DBMS_LOB.LOB_READONLY); DBMS_LOB.OPEN(loa_file, DBMS_LOB.LOB_READONLY); DBMS_LOB.CREATETEMPORARY(laa, TRUE, DBMS_LOB.SESSION); DBMS_LOB.CREATETEMPORARY(loa, TRUE, DBMS_LOB.SESSION); DBMS_LOB.OPEN(laa, DBMS_LOB.LOB_READWRITE); DBMS_LOB.OPEN(loa, DBMS_LOB.LOB_READWRITE); DBMS_LOB.LOADFROMFILE(laa, laa_file, DBMS_LOB.LOBMAXSIZE); DBMS_LOB.LOADFROMFILE(loa, loa_file, DBMS_LOB.LOBMAXSIZE); DBMS_LOB.CLOSE(laa); DBMS_LOB.CLOSE(loa); DBMS_LOB.CLOSE(laa_file); DBMS_LOB.CLOSE(loa_file); SDO_CS.convert_NADCON_to_XML(laa, loa, xml); SDO_CS.convert_XML_to_NADCON(xml, laa, loa); DBMS_OUTPUT.PUT_LINE(SUBSTR(laa, 1, 32000)); DBMS_OUTPUT.PUT_LINE(SUBSTR(loa, 1, 32000)); END; / NADCON EXTRACTED REGION NADGRD 33 49 1 -107.00000 .25000 25.00000 .25000 .00000 .006731 .006444 .006208 .006036 .005935 .005904 .005932 .006002 .006092 .006174 .006218 .006198 .006087 .005867 .005522 .005045 .004432 .003688 .002818 .001836 .000759 -.000385 -.001559 -.002704 . . . NADCON EXTRACTED REGION NADGRD 33 49 1 -107.00000 .25000 25.00000 .25000 .00000 .008509 .007147 .005756 .004331 .002879 .001410 -.000060 -.001507 -.002904 -.004222 -.005431 -.006498 -.007395 -.008095 -.008579 -.008832 -.008848 -.008632 -.008200 -.007577 -.006800 -.005911 -.004957 -.003974 . . .

## SDO_CS.CONVERT_XML_TO_NTV2

Format

SDO_CS.CONVERT_XML_TO_NTV2(

xml_grid IN XMLTYPE,

ntv2_clob OUT CLOB);

Description

Converts an Oracle Spatial XML representation of an NTv2 (National Transformation Version 2) grid to NTv2 ASCII format.

Parameters

- xml_grid
XML document containing the Oracle Spatial XML representation of the NTv2 grid.

- ntv2_clob
Output CLOB object containing the values for the NTv2 grid.

Usage Notes

To convert an NTv2 grid in ASCII format to an Oracle Spatial XML representation, use the SDO_CS.CONVERT_NTV2_TO_XML procedure.

Examples

The following example converts an NTv2 grid in ASCII format to an Oracle Spatial XML representation, converts the resulting XML representation back to an NTv2 ASCII representation, and displays the resulting ASCII representation. (Only part of the output is shown.)

set lines 32000 set long 2000000000 DECLARE ntv2 CLOB; xml XMLTYPE; ntv2_file BFILE; BEGIN ntv2_file := BFILENAME('MY_WORK_DIR', 'samplentv2.gsa'); DBMS_LOB.OPEN(ntv2_file, DBMS_LOB.LOB_READONLY); DBMS_LOB.CREATETEMPORARY(ntv2, TRUE, DBMS_LOB.SESSION); DBMS_LOB.OPEN(ntv2, DBMS_LOB.LOB_READWRITE); DBMS_LOB.LOADFROMFILE(ntv2, ntv2_file, DBMS_LOB.LOBMAXSIZE); DBMS_LOB.CLOSE(ntv2); DBMS_LOB.CLOSE(ntv2_file); SDO_CS.convert_NTv2_to_XML(ntv2, xml); SDO_CS.convert_XML_to_NTv2(xml, ntv2); DBMS_OUTPUT.PUT_LINE(SUBSTR(ntv2, 1, 32000)); END; / NUM_OREC 11 NUM_SREC 11 NUM_FILE 2 GS_TYPE SECONDS VERSION NTv2.0 DATUM_F NAD27 DATUM_T NAD83 MAJOR_F 6378206.400 MINOR_F 6356583.800 MAJOR_T 6378137.000 MINOR_T 6356752.314 SUB_NAMEALbanff PARENT NONE CREATED 95-06-29 UPDATED 95-07-04 S_LAT 183900.000000 N_LAT 184500.000000 E_LONG 415800.000000 W_LONG 416100.000000 LAT_INC 30.000000 LONG_INC 30.000000 GS_COUNT 231 0.084020 3.737300 0.005000 0.008000 0.083029 3.738740 0.017000 0.011000 0.082038 3.740180 0.029000 0.015000 . . .

## SDO_CS.CREATE_CONCATENATED_OP

Format

SDO_CS.CREATE_CONCATENATED_OP(

op_id IN NUMBER,

op_name IN VARCHAR2,

use_plan IN TFM_PLAN);

Description

Creates a concatenated operation.

Parameters

- op_id
ID number of the concatenated operation.

- op_name
Name to be associated with the concatenated operation.

- use_plan
Transformation plan. The TFM_PLAN object type is explained in Section 6.5.

Usage Notes

A concatenated operation is the concatenation (chaining) of two or more atomic operations.

To create a concatenated operation and make it preferred either systemwide or for a specified use case, you can use the SDO_CS.CREATE_PREF_CONCATENATED_OP convenience procedure.

Examples

The following example creates a concatenation operation with the operation ID 2999 and the name

`CONCATENATED_OPERATION_2999`

.DECLARE BEGIN SDO_CS.CREATE_CONCATENATED_OP( 2999, 'CONCATENATED_OPERATION_2999', TFM_PLAN(SDO_TFM_CHAIN(4242, 19910, 24200, 1000000000, 24200))); END; /

## SDO_CS.CREATE_OBVIOUS_EPSG_RULES

Format

SDO_CS.CREATE_OBVIOUS_EPSG_RULES(

use_case IN VARCHAR2 DEFAULT NULL);

Description

Creates a basic set of EPSG rules to be applied in certain transformations.

Parameters

- use_case
Name of the use case to be associated with the application of the EPSG rules that are created. Must be a value from the USE_CASE column of the SDO_PREFERRED_OPS_USER table (described in Section 6.6.25).

Usage Notes

This procedure creates rules to implement the main EPSG-defined transformations between specific coordinate reference systems. For transformations between some coordinate reference systems, EPSG has specified rules that should be applied. For any given transformation from one coordinate reference system to another, the EPSG rule might be different from the default Oracle Spatial rule. If you execute this procedure, the EPSG rules are applied in any such cases. If you do not execute this procedure, the default Spatial rules are used in such cases.

This procedure inserts many rows into the SDO_PREFERRED_OPS_SYSTEM table (see Section 6.6.24).

To delete the EPSG rules created by this procedure, and thus cause the default Spatial rules to be used in all cases, use the SDO_CS.DELETE_ALL_EPSG_RULES procedure.

Examples

The following example creates a basic set of EPSG rules to be applied in certain transformations.

EXECUTE SDO_CS.CREATE_OBVIOUS_EPSG_RULES;

## SDO_CS.CREATE_PREF_CONCATENATED_OP

Format

SDO_CS.CREATE_PREF_CONCATENATED_OP(

op_id IN NUMBER,

op_name IN VARCHAR2,

use_plan IN TFM_PLAN,

use_case IN VARCHAR2 DEFAULT NULL);

Description

Creates a concatenated operation, associating it with a transformation plan and making it preferred either systemwide or for a specified use case.

Parameters

- op_id
ID number of the concatenated operation to be created.

- op_name
Name to be associated with the concatenated operation.

- use_plan
Transformation plan. The TFM_PLAN object type is explained in Section 6.5.

- use_case
Use case to which this preferred concatenated operation applies. Must be a null or a value from the USE_CASE column of the SDO_PREFERRED_OPS_USER table (described in Section 6.6.25).

Usage Notes

This convenience procedure combines the operations of the SDO_CS.CREATE_CONCATENATED_OP and SDO_CS.ADD_PREFERENCE_FOR_OP procedures.

A concatenated operation is the concatenation (chaining) of two or more atomic operations.

If

`use_case`

is null, the transformation plan associated with the operation is a systemwide preference, and a row is added (or two rows are added if a reverse operation exists) to the SDO_PREFERRED_OPS_SYSTEM table (described in Section 6.6.24). If`use_case`

is not null, the transformation plan associated with the operation is a preference associated with the specified use case, and a row is added (or two rows are added if a reverse operation exists) to the SDO_PREFERRED_OPS_USER table (described in Section 6.6.25).To create a concatenation without making it preferred either systemwide or for a specified use case, use the SDO_CS.CREATE_CONCATENATED_OP procedure

To delete a concatenated operation, use the SDO_CS.DELETE_OP procedure.

Examples

The following example creates a concatenation operation with the operation ID 300 and the name

`MY_CONCATENATION_OPERATION`

, and causes Spatial to use the specified transformation plan in all cases (because`use_case`

is null) when this operation is used.DECLARE BEGIN SDO_CS.CREATE_PREF_CONCATENATED_OP( 300, 'MY_CONCATENATED_OPERATION', TFM_PLAN(SDO_TFM_CHAIN(4242, 19910, 24200, 1000000000, 24200)), NULL); END; /

## SDO_CS.DELETE_ALL_EPSG_RULES

Format

SDO_CS.DELETE_ALL_EPSG_RULES(

use_case IN VARCHAR2 DEFAULT NULL);

Description

Deletes the basic set of EPSG rules to be applied in certain transformations.

Parameters

- use_case
Name of the use case to be associated with the application of the EPSG rules that are created. Must match the value that was used for the

`use_case`

parameter value (either null or a specified value) when the SDO_CS.CREATE_OBVIOUS_EPSG_RULES procedure was called.Usage Notes

This procedure deletes the EPSG rules that were previously created by the SDO_CS.CREATE_OBVIOUS_EPSG_RULES procedure, and thus causes the default Spatial rules to be used in all cases. (See the Usage Notes for the SDO_CS.CREATE_OBVIOUS_EPSG_RULES procedure for more information.)

If

`use_case`

is null, this procedure deletes all rows from the SDO_PREFERRED_OPS_SYSTEM table (see Section 6.6.24). If`use_case`

is not null, this procedure deletes the rows associated with the specified use case from the SDO_PREFERRED_OPS_USER table (see Section 6.6.25).Examples

The following example deletes the basic set of EPSG rules to be applied in certain transformations.

EXECUTE SDO_CS.DELETE_ALL_EPSG_RULES;

## SDO_CS.DELETE_OP

Format

SDO_CS.DELETE_OP(

op_id IN NUMBER);

Description

Deletes a concatenated operation.

Parameters

- op_id
ID number of the operation to be deleted.

Usage Notes

To create a concatenated operation and make it preferred systemwide or only for a specified use case, use the SDO_CS.CREATE_CONCATENATED_OP procedure.

Examples

The following example deletes the operation with the ID number 300.

EXECUTE SDO_CS.DELETE_OP(300);

## SDO_CS.DETERMINE_CHAIN

Format

SDO_CS.DETERMINE_CHAIN(

transient_rule_set IN SDO_TRANSIENT_RULE_SET,

use_case IN VARCHAR2,

source_srid IN NUMBER,

target_srid IN NUMBER) RETURN TFM_PLAN;

Description

Returns the query chain, based on the system rule set, to be used in transformations from one coordinate reference system to another coordinate reference system.

Parameters

- transient_rule_set
Rule set to be used for the transformation. If you specify a null value, the Oracle system rule set is used.

- use_case
Use case for which to determine the query chain. Must be a null value or a value from the USE_CASE column of the SDO_PREFERRED_OPS_USER table (described in Section 6.6.25).

- source_srid
The SRID of the source coordinate reference system. Must be a value in the SRID column of the SDO_COORD_REF_SYS table (described in Section 6.6.9).

- target_srid
The SRID of the target coordinate reference system. Must be a value in the SRID column of the SDO_COORD_REF_SYS table (described in Section 6.6.9).

Usage Notes

This function returns an object of type TFM_PLAN, which is explained in Section 6.5.

The

`transient_rule_set`

parameter is of type SDO_TRANSIENT_RULE_SET, which has the following definition:CREATE TYPE sdo_transient_rule_set AS OBJECT ( source_srid NUMBER, target_srid NUMBER, tfm NUMBER);Examples

The following example returns the query chain based on the system rule set.

SELECT MDSYS.SDO_CS.DETERMINE_CHAIN(NULL, NULL, 4804, 4257) FROM DUAL; MDSYS.SDO_CS.DETERMINE_CHAIN(NULL,NULL,4804,4257)(THE_PLAN) -------------------------------------------------------------------------------- TFM_PLAN(SDO_TFM_CHAIN(4804, -2, 4257))The next example creates a preferred concatenated operation (with operation ID 300) with a specified chain for transformations from SRID 4804 to SRID 4257, and then calls the DETERMINE_CHAIN function, returning a different result. (The operation created in this example is not meaningful or useful, and it was created only for illustration.)

CALL SDO_CS.CREATE_PREF_CONCATENATED_OP( 300, 'CONCATENATED OPERATION', TFM_PLAN( SDO_TFM_CHAIN( 4804, 1000000001, 4804, 1000000002, 4804, 1000000001, 4804, 1000000001, 4804, 1000000002, 4804, 1000000002, 4804, 1000000001, 4804, 1000000001, 4804, 1000000001, 4804, 1000000002, 4804, 1000000002, 4804, 1000000002, 4257)), NULL); SELECT MDSYS.SDO_CS.DETERMINE_CHAIN(NULL, NULL, 4804, 4257) FROM DUAL; MDSYS.SDO_CS.DETERMINE_CHAIN(NULL,NULL,4804,4257)(THE_PLAN) -------------------------------------------------------------------------------- TFM_PLAN(SDO_TFM_CHAIN(4804, 300, 4257))

## SDO_CS.DETERMINE_DEFAULT_CHAIN

Format

SDO_CS.DETERMINE_DEFAULT_CHAIN(

source_srid IN NUMBER,

target_srid IN NUMBER) RETURN SDO_SRID_CHAIN;

Description

Returns the default chain of SRID values in transformations from one coordinate reference system to another coordinate reference system.

Parameters

- source_srid
The SRID of the source coordinate reference system. Must be a value in the SRID column of the SDO_COORD_REF_SYS table (described in Section 6.6.9).

- target_srid
The SRID of the target coordinate reference system. Must be a value in the SRID column of the SDO_COORD_REF_SYS table (described in Section 6.6.9).

Usage Notes

This function returns an object of type SDO_SRID_CHAIN, which is defined as

`VARRAY(1048576) OF NUMBER`

.Examples

The following example returns the default chain of SRID values in transformations from SRID 4804 to SRID 4257.

SELECT MDSYS.SDO_CS.DETERMINE_DEFAULT_CHAIN(4804, 4257) FROM DUAL; MDSYS.SDO_CS.DETERMINE_DEFAULT_CHAIN(4804,4257) -------------------------------------------------------------------------------- SDO_SRID_CHAIN(NULL, 4804, 4257, NULL)

## SDO_CS.FIND_GEOG_CRS

Format

SDO_CS.FIND_GEOG_CRS(

reference_srid IN NUMBER,

is_legacy IN VARCHAR2,

max_rel_num_difference IN NUMBER DEFAULT 0.000001) RETURN SDO_SRID_LIST;

Description

Returns the SRID values of geodetic (geographic) coordinate reference systems that have the same well-known text (WKT) numeric values as the coordinate reference system with the specified reference SRID value.

Parameters

- reference_srid
The SRID of the coordinate reference system for which to find all other geodetic coordinate reference systems that have the same WKT numeric values. Must be a value in the SRID column of the SDO_COORD_REF_SYS table (described in Section 6.6.9).

- is_legacy

`TRUE`

limits the results to geodetic coordinate reference systems for which the IS_LEGACY column value is`TRUE`

in the SDO_COORD_REF_SYS table (described in Section 6.6.9);`FALSE`

limits the results to geodetic coordinate reference systems for which the IS_LEGACY column value is`FALSE`

in the SDO_COORD_REF_SYS table. If you specify a null value for this parameter, the IS_LEGACY column value in the SDO_COORD_REF_SYS table is ignored in determining the results.- max_rel_num_difference
A numeric value indicating how closely WKT values must match in order for a projected coordinate reference system to be considered a match. The default value is 0.000001. The value for each numeric WKT item is compared with its corresponding value in the WKT for the reference SRID or in the specified list of parameters to this function; and if the difference in all cases is less than or equal to the

`max_rel_num_difference`

value, the SRID for that coordinate reference system is included in the results.Usage Notes

This function returns an object of type SDO_SRID_LIST, which is defined as

`VARRAY(1048576) OF NUMBER`

.The well-known text (WKT) format is described in Section 6.7.1.1.

Examples

The following examples show the effect of the

`is_legacy`

parameter value on the results. The first example returns the SRID values of all geodetic legacy coordinate reference systems that have the same WKT numeric values as the coordinate reference system with the SRID value of 8307.SELECT SDO_CS.FIND_GEOG_CRS( 8307, 'TRUE') FROM DUAL; SDO_CS.FIND_GEOG_CRS(8307,'TRUE') -------------------------------------------------------------------------------- SDO_SRID_LIST(8192, 8265, 8307, 8311, 8320, 524288, 2000002, 2000006, 2000012, 2 000015, 2000023, 2000028)The next example returns the SRID values of all geodetic non-legacy coordinate reference systems that have the same WKT numeric values as the coordinate reference system with the SRID value of 8307.

SELECT SDO_CS.FIND_GEOG_CRS( 8307, 'FALSE') FROM DUAL; SDO_CS.FIND_GEOG_CRS(8307,'FALSE') -------------------------------------------------------------------------------- SDO_SRID_LIST(4019, 4030, 4031, 4032, 4033, 4041, 4121, 4122, 4126, 4130, 4133, 4140, 4141, 4148, 4151, 4152, 4163, 4166, 4167, 4170, 4171, 4172, 4173, 4176, 41 80, 4189, 4190, 4258, 4269, 4283, 4318, 4319, 4326, 4610, 4612, 4617, 4619, 4624 , 4627, 4640, 4659, 4661, 4667, 4669, 4670)The next example returns the SRID values of all geodetic coordinate reference systems (legacy and non-legacy) that have the same WKT numeric values as the coordinate reference system with the SRID value of 8307.

SELECT SDO_CS.FIND_GEOG_CRS( 8307, NULL) FROM DUAL; SDO_CS.FIND_GEOG_CRS(8307,NULL) -------------------------------------------------------------------------------- SDO_SRID_LIST(4019, 4030, 4031, 4032, 4033, 4041, 4121, 4122, 4126, 4130, 4133, 4140, 4141, 4148, 4151, 4152, 4163, 4166, 4167, 4170, 4171, 4172, 4173, 4176, 41 80, 4189, 4190, 4258, 4269, 4283, 4318, 4319, 4326, 4610, 4612, 4617, 4619, 4624 , 4627, 4640, 4659, 4661, 4667, 4669, 4670, 8192, 8265, 8307, 8311, 8320, 524288 , 2000002, 2000006, 2000012, 2000015, 2000023, 2000028)

## SDO_CS.FIND_PROJ_CRS

Format

SDO_CS.FIND_PROJ_CRS(

reference_srid IN NUMBER,

is_legacy IN VARCHAR2,

max_rel_num_difference IN NUMBER DEFAULT 0.000001) RETURN SDO_SRID_LIST;

Description

Returns the SRID values of projected coordinate reference systems that have the same well-known text (WKT) numeric values as the coordinate reference system with the specified reference SRID value.

Parameters

- reference_srid
The SRID of the coordinate reference system for which to find all other projected coordinate reference systems that have the same WKT numeric values. Must be a value in the SRID column of the SDO_COORD_REF_SYS table (described in Section 6.6.9).

- is_legacy

`TRUE`

limits the results to projected coordinate reference systems for which the IS_LEGACY column value is`TRUE`

in the SDO_COORD_REF_SYS table (described in Section 6.6.9);`FALSE`

limits the results to projected coordinate reference systems for which the IS_LEGACY column value is`FALSE`

in the SDO_COORD_REF_SYS table. If you specify a null value for this parameter, the IS_LEGACY column value in the SDO_COORD_REF_SYS table is ignored in determining the results.- max_rel_num_difference
A numeric value indicating how closely WKT values must match in order for a coordinate reference system to be considered a match. The default value is 0.000001. The value for each numeric WKT item is compared with its corresponding value in the WKT for the reference SRID or in the specified list of parameters to this function; and if the difference in all cases is less than or equal to the

`max_rel_num_difference`

value, the SRID for that coordinate reference system is included in the results.Usage Notes

This function returns an object of type SDO_SRID_LIST, which is defined as

`VARRAY(1048576) OF NUMBER`

.The well-known text (WKT) format is described in Section 6.7.1.1.

Examples

The following examples show the effect of the

`is_legacy`

parameter value on the results. The first example returns the SRID values of all projected legacy coordinate reference systems that have the same WKT numeric values as the coordinate reference system with the SRID value of 2007. The returned result list is empty, because there are no legacy projected legacy coordinate reference systems that meet the search criteria.SELECT SDO_CS.FIND_PROJ_CRS( 2007, 'TRUE') FROM DUAL; SDO_CS.FIND_PROJ_CRS(2007,'TRUE') -------------------------------------------------------------------------------- SDO_SRID_LIST()The next example returns the SRID values of all projected non-legacy coordinate reference systems that have the same WKT numeric values as the coordinate reference system with the SRID value of 2007.

SELECT SDO_CS.FIND_PROJ_CRS( 2007, 'FALSE') FROM DUAL; SDO_CS.FIND_PROJ_CRS(2007,'FALSE') -------------------------------------------------------------------------------- SDO_SRID_LIST(2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 21291)The next example returns the SRID values of all projected coordinate reference systems (legacy and non-legacy) that have the same WKT numeric values as the coordinate reference system with the SRID value of 2007. The returned result list is the same as for the preceding example.

SELECT SDO_CS.FIND_PROJ_CRS( 2007, NULL) FROM DUAL; SDO_CS.FIND_PROJ_CRS(2007,NULL) -------------------------------------------------------------------------------- SDO_SRID_LIST(2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 21291)

## SDO_CS.FROM_OGC_SIMPLEFEATURE_SRS

Format

SDO_CS.FROM_OGC_SIMPLEFEATURE_SRS(

wkt IN VARCHAR2) RETURN VARCHAR2;

Description

Converts a well-known text string from the Open Geospatial Consortium simple feature format without the

`TOWGS84`

keyword to the format that includes the`TOWGS84`

keyword.Parameters

- wkt
Well-known text string.

Usage Notes

To convert a well-known text string from the Open Geospatial Consortium simple feature format that includes the

`TOWGS84`

keyword to the format without the`TOWGS84`

keyword, use the SDO_CS.TO_OGC_SIMPLEFEATURE_SRS function.Examples

The following example converts a well-known text string from the Open Geospatial Consortium simple feature format without the

`TOWGS84`

keyword to the format that includes the`TOWGS84`

keyword.SELECT sdo_cs.from_OGC_SimpleFeature_SRS('GEOGCS [ "Longitude / Latitude (DHDN)", DATUM ["", SPHEROID ["Bessel 1841", 6377397.155, 299.1528128], 582.000000, 105.000000, 414.000000, -1.040000, -0.350000, 3.080000, 8.300000 ], PRIMEM [ "Greenwich", 0.000000 ], UNIT ["Decimal Degree", 0.01745329251994330]]') FROM DUAL; MDSYS.SDO_CS.FROM_OGC_SIMPLEFEATURE_SRS('GEOGCS["LONGITUDE/LATITUDE(DHDN)",DATUM -------------------------------------------------------------------------------- GEOGCS [ "Longitude / Latitude (DHDN)", DATUM ["", SPHEROID ["Bessel 1841", 6377 397.155, 299.1528128], TOWGS84[ 582.000000, 105.000000, 414.000000, -1.040000, - 0.350000, 3.080000, 8.300000]], PRIMEM [ "Greenwich", 0.000000 ], UNIT ["Decimal Degree", 0.01745329251994330]]

## SDO_CS.FROM_USNG

Format

SDO_CS.FROM_USNG(

usng IN VARCHAR2,

srid IN NUMBER,

datum IN VARCHAR2 DEFAULT 'NAD83') RETURN SDO_GEOMETRY;

Description

Converts a point represented in U.S. National Grid format to a spatial point geometry object.

Parameters

- usng
Well-known text string.

- srid
The SRID of the coordinate system to be used for the conversion (that is, the SRID to be used in the returned geometry). Must be a value in the SRID column of the SDO_COORD_REF_SYS table (described in Section 6.6.9).

- datum
The name of the datum on which the U.S. National Grid coordinate for the point is based. Must be either a value in the DATUM_NAME column of the SDO_DATUMS table (described in Section 6.6.22) or null. The default value is

`NAD83`

.Usage Notes

For information about Oracle Spatial support for the U.S. National Grid, see Section 6.10.

To convert a spatial point geometry to a point represented in U.S. National Grid format, use the SDO_CS.TO_USNG function.

Examples

The following example converts a a point represented in U.S. National Grid format to a spatial geometry point object with longitude/latitude coordinates.

-- Convert US National Grid point to SDO_GEMETRY point using SRID 4326 -- (WGS 84, longitude/latitude). SELECT SDO_CS.FROM_USNG( '18SUJ2348316806479498', 4326) FROM DUAL; WGS84(SDO_GTYPE, SDO_SRID, SDO_POINT(X, Y, Z), SDO_ELEM_INFO, SDO_ORDINATES) -------------------------------------------------------------------------------- SDO_GEOMETRY(2001, 4326, SDO_POINT_TYPE(-77.03524, 38.8894673, NULL), NULL, NULL)

## SDO_CS.MAP_EPSG_SRID_TO_ORACLE

Format

SDO_CS.MAP_EPSG_SRID_TO_ORACLE(

epsg_srid IN NUMBER) RETURN NUMBER;

Description

Returns the Oracle Spatial SRID value corresponding to the specified EPSG SRID value.

Parameters

- epsg_srid
The SRID of the EPSG coordinate reference system, as indicated in the COORD_REF_SYS_CODE field in the EPSG Coordinate Reference System table.

Usage Notes

This function returns a value that matches a value in the SRID column of the SDO_COORD_REF_SYS table (see Section 6.6.9).

To return the EPSG SRID value corresponding to the specified Oracle Spatial SRID value, use the SDO_CS.MAP_ORACLE_SRID_TO_EPSG function.

Examples

The following example returns the Oracle Spatial SRID value corresponding to EPSG SRID 23038.

SELECT SDO_CS.MAP_EPSG_SRID_TO_ORACLE(23038) FROM DUAL; SDO_CS.MAP_EPSG_SRID_TO_ORACLE(23038) ------------------------------------- 82361

## SDO_CS.MAP_ORACLE_SRID_TO_EPSG

Format

SDO_CS.MAP_ORACLE_SRID_TO_EPSG(

legacy_srid IN NUMBER) RETURN NUMBER;

Description

Returns the EPSG SRID value corresponding to the specified Oracle Spatial SRID value.

Parameters

- legacy_srid
Oracle Spatial SRID value. Must match a value in the LEGACY_CODE column of the SDO_COORD_REF_SYS table (see Section 6.6.9).

Usage Notes

This function returns the SRID of an EPSG coordinate reference system. The EPSG SRID value for a coordinate reference system is indicated in the COORD_REF_SYS_CODE field in the EPSG Coordinate Reference System table.

To return the Oracle Spatial SRID value corresponding to a specified EPSG SRID value, use the SDO_CS.MAP_EPSG_SRID_TO_ORACLE function.

Examples

The following example returns the EPSG SRID value corresponding to Oracle Spatial SRID 82361.

SELECT SDO_CS.MAP_ORACLE_SRID_TO_EPSG(82361) FROM DUAL; SDO_CS.MAP_ORACLE_SRID_TO_EPSG(82361) ------------------------------------- 23038

## SDO_CS.REVOKE_PREFERENCE_FOR_OP

Format

SDO_CS.REVOKE_PREFERENCE_FOR_OP(

op_id IN NUMBER,

source_crs IN NUMBER DEFAULT NULL,

target_crs IN NUMBER DEFAULT NULL,

use_case IN VARCHAR2 DEFAULT NULL);

Description

Revokes a preference for an operation between a source coordinate system and a target coordinate system.

Parameters

- op_id
ID number of the operation. Must match an

`op_id`

value that was specified in a call to the SDO_CS.ADD_PREFERENCE_FOR_OP procedure.- source_crs
The SRID of the source coordinate reference system. Must match the

`source_crs`

value in a`source_crs`

,`target_crs`

, and`use_case`

combination that was specified in a call to the SDO_CS.ADD_PREFERENCE_FOR_OP procedure.- target_crs
The SRID of the target coordinate reference system. Must match the

`target_crs`

value in a`source_crs`

,`target_crs`

, and`use_case`

combination that was specified in a call to the SDO_CS.ADD_PREFERENCE_FOR_OP procedure.- use_case
Name of the use case associated with the preference. Must match the

`use_case`

value in a`source_crs`

,`target_crs`

, and`use_case`

combination that was specified in a call to the SDO_CS.ADD_PREFERENCE_FOR_OP procedure.Usage Notes

This procedure reverses the effect of the SDO_CS.ADD_PREFERENCE_FOR_OP procedure.

If

`use_case`

is null, this procedure deletes one or more rows from the SDO_PREFERRED_OPS_SYSTEM table (described in Section 6.6.24). If`use_case`

is not null, this procedure deletes one or more rows from the SDO_PREFERRED_OPS_USER table (described in Section 6.6.25).Examples

The following example revokes a preference for operation ID 19777 to be used in transformations from SRID 4301 to SRID 4326 when use case

`use_case_B`

is specified for the transformation.EXECUTE SDO_CS.REVOKE_PREFERENCE_FOR_OP(19977, 4301, 4326, 'use_case_B');

## SDO_CS.TO_OGC_SIMPLEFEATURE_SRS

Format

SDO_CS.TO_OGC_SIMPLEFEATURE_SRS(

wkt IN VARCHAR2) RETURN VARCHAR2;

Description

Converts a well-known text string from the Open Geospatial Consortium simple feature format that includes the

`TOWGS84`

keyword to the format without the`TOWGS84`

keyword.Parameters

- wkt
Well-known text string.

Usage Notes

To convert a well-known text string from the Open Geospatial Consortium simple feature format without the

`TOWGS84`

keyword to the format that includes the`TOWGS84`

keyword, use the SDO_CS.FROM_OGC_SIMPLEFEATURE_SRS procedure.Examples

The following example converts a well-known text string from the Open Geospatial Consortium simple feature format that includes the

`TOWGS84`

keyword to the format without the`TOWGS84`

keyword.SELECT sdo_cs.to_OGC_SimpleFeature_SRS('GEOGCS [ "Longitude / Latitude (DHDN)", DATUM ["", SPHEROID ["Bessel 1841", 6377397.155, 299.1528128], TOWGS84 [582.000000, 105.000000, 414.000000, -1.040000, -0.350000, 3.080000, 8.300000] ], PRIMEM [ "Greenwich", 0.000000 ], UNIT ["Decimal Degree", 0.01745329251994330]]') FROM DUAL; MDSYS.SDO_CS.TO_OGC_SIMPLEFEATURE_SRS('GEOGCS["LONGITUDE/LATITUDE(DHDN)",DATUM[" -------------------------------------------------------------------------------- GEOGCS [ "Longitude / Latitude (DHDN)", DATUM ["", SPHEROID ["Bessel 1841", 6377 397.155, 299.1528128], 582.000000, 105.000000, 414.000000, -1.040000, -0.350000, 3.080000, 8.300000 ], PRIMEM [ "Greenwich", 0.000000 ], UNIT ["Decimal Degree", 0.01745329251994330]]

## SDO_CS.TO_USNG

Format

SDO_CS.TO_USNG(

geom IN SDO_GEOMETRY,

accuracy_in_meters IN NUMBER,

datum IN VARCHAR2 DEFAULT 'NAD83') RETURN VARCHAR2;

Description

Converts a spatial point geometry object to a point represented in U.S. National Grid format.

Parameters

- geom
Point geometry whose representation is to be converted to a point represented in U.S. National Grid format. The input geometry must have a valid non-null SRID, that is, a value in the SRID column of the SDO_COORD_REF_SYS table (described in Section 6.6.9).

- accuracy_in_meters
Accuracy of the point location in meters. Should be 1 raised to a negative or positive power of 10 (for example, 0.001, 0.01, 0.1, 1, 10, 100, or 1000). Any other specified values are adjusted internally by Spatial, and the result might not be what you expect.

- datum
The name of the datum on which the U.S. National Grid coordinate for the point is to be based. Must be either

`NAD83`

or`NAD27`

. The default value is`NAD83`

.Usage Notes

For information about Oracle Spatial support for the U.S. National Grid, see Section 6.10.

The

`accuracy_in_meters`

value affects the number of digits used to represent the accuracy in the returned U.S. National Grid string. For example, if you specify 0.000001, the string will contain many digits; however, depending on the source of the data, the digits might not accurately reflect geographical reality. Consider the following scenarios. If you create a U.S. National Grid string from a UTM geometry, you can get perfect accuracy, because no inherently inaccurate transformation is involved. However, transforming from a Lambert projection to the U.S. National Grid format involves an inverse Lambert projection and a forward UTM projection, each of which has some inherent inaccuracy. If you request the resulting U.S. National Grid string with 1 millimeter (0.001) accuracy, the string will contain all the digits, but the millimeter-level digit will probably be geographically inaccurate.To convert a a point represented in U.S. National Grid format to a spatial point geometry, use the SDO_CS.FROM_USNG function.

Examples

The following example converts a spatial geometry point object with longitude/latitude coordinates to a point represented in U.S. National Grid format using an accuracy of 0.001 meter (1 millimeter).

-- Convert longitude/latitude (WGS 84) point to US National Grid. SELECT SDO_CS.TO_USNG( SDO_GEOMETRY(2001, 4326, SDO_POINT_TYPE(-77.0352402158258, 38.8894673086544, NULL), NULL, NULL), 0.001) FROM DUAL; SDO_CS.TO_USNG(SDO_GEOMETRY(2001,4326,SDO_POINT_TYPE(-77.0352402158258,38.889467 -------------------------------------------------------------------------------- 18SUJ2348316806479498

## SDO_CS.TRANSFORM

Format

SDO_CS.TRANSFORM(

geom IN SDO_GEOMETRY,

to_srid IN NUMBER

) RETURN SDO_GEOMETRY;

or

SDO_CS.TRANSFORM(

geom IN SDO_GEOMETRY,

tolerance IN NUMBER,

to_srid IN NUMBER

) RETURN SDO_GEOMETRY;

or

SDO_CS.TRANSFORM(

geom IN SDO_GEOMETRY,

dim IN SDO_DIM_ARRAY,

to_srid IN NUMBER

) RETURN SDO_GEOMETRY;

or

SDO_CS.TRANSFORM(

geom IN SDO_GEOMETRY,

to_srname IN VARCHAR2

) RETURN SDO_GEOMETRY;

or

SDO_CS.TRANSFORM(

geom IN SDO_GEOMETRY,

tolerance IN NUMBER,

to_srname IN VARCHAR2

) RETURN SDO_GEOMETRY;

or

SDO_CS.TRANSFORM(

geom IN SDO_GEOMETRY,

dim IN SDO_DIM_ARRAY,

to_srname IN VARCHAR2

) RETURN SDO_GEOMETRY;

Description

Transforms a geometry representation using a coordinate system (specified by SRID or name).

Parameters

- geom
Geometry whose representation is to be transformed using another coordinate system. The input geometry must have a valid non-null SRID, that is, a value in the SRID column of the SDO_COORD_REF_SYS table (described in Section 6.6.9).

- tolerance
Tolerance value (see Section 1.5.5).

- dim
Dimensional information array corresponding to

`geom`

, usually selected from one of the xxx_SDO_GEOM_METADATA views (described in Section 2.6).- to_srid
The SRID of the coordinate system to be used for the transformation. It must be a value in the SRID column of the SDO_COORD_REF_SYS table (described in Section 6.6.9).

- to_srname
The name of the coordinate system to be used for the transformation. It must be a value (specified exactly) in the COORD_REF_SYS_NAME column of the SDO_COORD_REF_SYS table (described in Section 6.6.9).

Usage Notes

Transformation can be done only between two different georeferenced coordinate systems or between two different local coordinate systems.

An exception is raised if

`geom`

,`to_srid`

, or`to_srname`

is invalid. For`geom`

to be valid for this function, its definition must include an SRID value matching a value in the SRID column of the SDO_COORD_REF_SYS table (described in Section 6.6.9).Examples

The following example transforms the

`cola_c`

geometry to a representation that uses SRID value 8199. (This example uses the definitions from the example in Section 6.11.)-- Return the transformation of cola_c using to_srid 8199 -- ('Longitude / Latitude (Arc 1950)') SELECT c.name, SDO_CS.TRANSFORM(c.shape, m.diminfo, 8199) FROM cola_markets_cs c, user_sdo_geom_metadata m WHERE m.table_name = 'COLA_MARKETS_CS' AND m.column_name = 'SHAPE' AND c.name = 'cola_c'; NAME -------------------------------- SDO_CS.TRANSFORM(C.SHAPE,M.DIMINFO,8199)(SDO_GTYPE, SDO_SRID, SDO_POINT(X, Y, Z) -------------------------------------------------------------------------------- cola_c SDO_GEOMETRY(2003, 8199, NULL, SDO_ELEM_INFO_ARRAY(1, 1003, 1), SDO_ORDINATE_ARR AY(3.00074114, 3.00291482, 6.00067068, 3.00291287, 6.0006723, 5.00307625, 4.0007 1961, 5.00307838, 3.00074114, 3.00291482)) -- Same as preceding, but using to_srname parameter. SELECT c.name, SDO_CS.TRANSFORM(c.shape, m.diminfo, 'Longitude / Latitude (Arc 1950)') FROM cola_markets_cs c, user_sdo_geom_metadata m WHERE m.table_name = 'COLA_MARKETS_CS' AND m.column_name = 'SHAPE' AND c.name = 'cola_c'; NAME -------------------------------- SDO_CS.TRANSFORM(C.SHAPE,M.DIMINFO,'LONGITUDE/LATITUDE(ARC1950)')(SDO_GTYPE, SDO -------------------------------------------------------------------------------- cola_c SDO_GEOMETRY(2003, 8199, NULL, SDO_ELEM_INFO_ARRAY(1, 1003, 1), SDO_ORDINATE_ARR AY(3.00074114, 3.00291482, 6.00067068, 3.00291287, 6.0006723, 5.00307625, 4.0007 1961, 5.00307838, 3.00074114, 3.00291482))

## SDO_CS.TRANSFORM_LAYER

Format

SDO_CS.TRANSFORM_LAYER(

table_in IN VARCHAR2,

column_in IN VARCHAR2,

table_out IN VARCHAR2,

to_srid IN NUMBER);

or

SDO_CS.TRANSFORM_LAYER(

table_in IN VARCHAR2,

column_in IN VARCHAR2,

table_out IN VARCHAR2,

use_plan IN TFM_PLAN);

or

SDO_CS.TRANSFORM_LAYER(

table_in IN VARCHAR2,

column_in IN VARCHAR2,

table_out IN VARCHAR2,

use_case IN VARCHAR2,

to_srid IN NUMBER);

Description

Transforms an entire layer of geometries (that is, all geometries in a specified column in a table).

Parameters

- table_in
Table containing the layer (

`column_in`

) whose geometries are to be transformed.- column_in
Column in

`table_in`

that contains the geometries to be transformed.- table_out
Table that will be created and that will contain the results of the transformation. See the Usage Notes for information about the format of this table.

- to_srid
The SRID of the coordinate system to be used for the transformation.

`to_srid`

must be a value in the SRID column of the SDO_COORD_REF_SYS table (described in Section 6.6.9).- use_plan
Transformation plan. The TFM_PLAN object type is explained in Section 6.5.

- use_case
Name of the use case whose transformation rules are to be applied in performing the transformation. Use cases are explained in Section 6.4.

Usage Notes

Transformation can be done only between two different georeferenced coordinate systems or between two different local coordinate systems.

An exception is raised if any of the following occurs:

`table_in`

does not exist, or`column_in`

does not exist in the table.The geometries in

`column_in`

have a null or invalid SDO_SRID value.

`table_out`

already exists.

`to_srid`

is invalid.The

`table_out`

table is created by the procedure and is filled with one row for each transformed geometry. This table has the columns shown in Table 13-2.Table 13-2 Table to Hold Transformed Layer

Column Name Data Type Description SDO_ROWID

ROWID

Oracle ROWID (row address identifier). For more information about the ROWID data type, see Oracle Database SQL Reference.

GEOMETRY

SDO_GEOMETRY

Geometry object with coordinate values in the specified (

`to_srid`

parameter) coordinate system.Examples

The following example transforms the geometries in the

`shape`

column in the COLA_MARKETS_CS table to a representation that uses SRID value 8199. The transformed geometries are stored in the newly created table named COLA_MARKETS_CS_8199. (This example uses the definitions from the example in Section 6.11.)-- Transform the entire SHAPE layer and put results in the table -- named cola_markets_cs_8199, which the procedure will create. CALL SDO_CS.TRANSFORM_LAYER('COLA_MARKETS_CS','SHAPE','COLA_MARKETS_CS_8199',8199);Example 6-8 in Section 6.11 includes a display of the geometry object coordinates in both tables (COLA_MARKETS_CS and COLA_MARKETS_CS_8199).

## SDO_CS.UPDATE_WKTS_FOR_ALL_EPSG_CRS

Format

SDO_CS.UPDATE_WKTS_FOR_ALL_EPSG_CRS();

Description

Updates the well-known text (WKT) description for all EPSG coordinate reference systems.

Parameters

None.

Usage Notes

For information about using procedures to update well-known text (WKT) description, see Section 6.7.1.2.

Examples

The following example updates the WKT description for all EPSG coordinate reference systems.

EXECUTE SDO_CS.UPDATE_WKTS_FOR_ALL_EPSG_CRS; Updating SRID 4001... Updating SRID 4002... Updating SRID 4003... . . . Updating SRID 69036405... Updating SRID 69046405...

## SDO_CS.UPDATE_WKTS_FOR_EPSG_CRS

Format

SDO_CS.UPDATE_WKTS_FOR_EPSG_CRS(

srid IN NUMBER);

Description

Updates the well-known text (WKT) description for the EPSG coordinate reference system associated with a specified SRID.

Parameters

- srid
The SRID of the coordinate system whose well-known text (WKT) description is to be updated. An entry for the specified value must exist in the SDO_COORD_REF_SYS table (described in Section 6.6.9).

Usage Notes

For information about using procedures to update well-known text (WKT) description, see Section 6.7.1.2.

Examples

The following example updates the WKT description for the EPSG coordinate reference system associated with SRID 8307.

EXECUTE SDO_CS.UPDATE_WKTS_FOR_EPSG_CRS(8307);

## SDO_CS.UPDATE_WKTS_FOR_EPSG_DATUM

Format

SDO_CS.UPDATE_WKTS_FOR_EPSG_DATUM(

datum_id IN NUMBER);

Description

Updates the well-known text (WKT) description for all EPSG coordinate reference systems associated with a specified datum.

Parameters

- datum_id
The ID of the datum. Must match a value in the DATUM_ID column of the SDO_DATUMS table (described in Section 6.6.22).

Usage Notes

For information about using procedures to update well-known text (WKT) description, see Section 6.7.1.2.

Examples

The following example updates the WKT description for all EPSG coordinate reference systems associated with datum 5100.

EXECUTE SDO_CS.UPDATE_WKTS_FOR_EPSG_DATUM(5100); Updating SRID 5714... Updating SRID 5715...

## SDO_CS.UPDATE_WKTS_FOR_EPSG_ELLIPS

Format

SDO_CS.UPDATE_WKTS_FOR_EPSG_ELLIPS(

ellipsoid_id IN NUMBER);

Description

Updates the well-known text (WKT) description for all EPSG coordinate reference systems associated with a specified ellipsoid.

Parameters

- ellipsoid_id
The ID of the ellipsoid. Must match a value in the ELLIPSOID_ID column of the SDO_ELLIPSOIDS table (described in Section 6.6.23).

Usage Notes

Examples

The following example updates the WKT description for all EPSG coordinate reference systems associated with ellipsoid 7100.

EXECUTE SDO_CS.UPDATE_WKTS_FOR_EPSG_ELLIPS(7001); Updating SRID 4001... Updating SRID 4188... Updating SRID 29901... Updating SRID 61886405... Updating SRID 4277... Updating SRID 27700... Updating SRID 62776405... Updating SRID 4278... Updating SRID 62786405... Updating SRID 4279... Updating SRID 62796405...

## SDO_CS.UPDATE_WKTS_FOR_EPSG_OP

Format

SDO_CS.UPDATE_WKTS_FOR_EPSG_OP(

coord_op_id IN NUMBER);

Description

Updates the well-known text (WKT) description for all EPSG coordinate reference systems associated with a specified coordinate transformation operation.

Parameters

- coord_op_id
The ID of the SRID of the coordinate transformation operation. Must match a value in the COORD_OP_ID column of the SDO_COORD_OP_PARAM_VALS table (described in Section 6.6.5).

Usage Notes

Examples

The following example updates the WKT description for all EPSG coordinate reference systems associated with coordinate transformation operation 2000067.

EXECUTE SDO_CS.UPDATE_WKTS_FOR_EPSG_OP(2000067); Updating SRID 20000671...

## SDO_CS.UPDATE_WKTS_FOR_EPSG_PARAM

Format

SDO_CS.UPDATE_WKTS_FOR_EPSG_PARAM(

coord_op_id IN NUMBER,

parameter_id IN NUMBER);

Description

Updates the well-known text (WKT) description for all EPSG coordinate reference systems associated with a specified coordinate transformation operation and parameter for transformation operations.

Parameters

- coord_op_id
The ID of the SRID of the coordinate transformation operation. Must match a value in the COORD_OP_ID column of the SDO_COORD_OP_PARAM_VALS table (described in Section 6.6.5).

- parameter_id
The ID of the SRID of the parameter for transformation operations. Must match a value in the PARAMETER_ID column of the SDO_COORD_OP_PARAM_VALS table (described in Section 6.6.5) where the COORD_OP_ID column value is equal to the

`coord_op_id`

parameter value.Usage Notes

Examples

The following example updates the WKT description for all EPSG coordinate reference systems associated with coordinate transformation operation 9601 and parameter 8602.

EXECUTE SDO_CS.UPDATE_WKTS_FOR_EPSG_PARAM(9601, 8602);

## SDO_CS.UPDATE_WKTS_FOR_EPSG_PM

Format

SDO_CS.UPDATE_WKTS_FOR_EPSG_PM(

prime_meridian_id IN NUMBER);

Description

Updates the well-known text (WKT) description for all EPSG coordinate reference systems associated with a specified prime meridian.

Parameters

- prime_meridian_id
The ID of the prime meridian. Must match a value in the PRIME_MERIDIAN_ID column in the SDO_PRIME_MERIDIANS table (described in Section 6.6.26).

Usage Notes

Examples

The following example updates the WKT description for all EPSG coordinate reference systems associated with prime meridian 8902.

EXECUTE SDO_CS.UPDATE_WKTS_FOR_EPSG_PM(8902); Updating SRID 4803... Updating SRID 20790... Updating SRID 20791... Updating SRID 68036405... Updating SRID 4904... Updating SRID 2963... Updating SRID 69046405...

## SDO_CS.VALIDATE_WKT

Format

SDO_CS.VALIDATE_WKT(

srid IN NUMBER

) RETURN VARCHAR2;

Description

Validates the well-known text (WKT) description associated with a specified SRID.

Parameters

- srid
The SRID of the coordinate system whose well-known text (WKT) description is to be validated. An entry for the specified value must exist in the SDO_COORD_REF_SYS table (described in Section 6.6.9).

Usage Notes

This function returns the string 'TRUE' if the WKT description is valid. If the WKT description is invalid, this function returns a string in the format 'FALSE (<position-number>)', where <position-number> is the number of the character position in the WKT description where the first error occurs.

The WKT description is checked to see if it satisfies the requirements described in Section 6.7.1.1.

Examples

The following example validates the WKT description of the coordinate system associated with SRID 81989000. The res^ults show that the cause of the invalidity (or the first cause of the invalidity) starts at character position 181 in the WKT description. (SRID 81989000 is not associated with any established coordinate system. Rather, it is for a deliberately invalid coordinate system that was inserted into a test version of the MDSYS.CS_SRS table, and it is not included in the MDSYS.CS_SRS table that is shipped with Oracle Spatial.)

SELECT SDO_CS.VALIDATE_WKT(81989000) FROM DUAL; SDO_CS.VALIDATE_WKT(81989000) -------------------------------------------------------------------------------- FALSE (181)

## SDO_CS.VIEWPORT_TRANSFORM

Format

SDO_CS.VIEWPORT_TRANSFORM(

geom IN SDO_GEOMETRY,

to_srid IN NUMBER

) RETURN SDO_GEOMETRY;

Description

Transforms an optimized rectangle into a valid polygon for use with Spatial operators and functions.

Note:

This function is deprecated, and will not be supported in future releases of Spatial. Instead, use a geodetic MBR to specify the query window, as explained in Section 6.2.3.Parameters

- geom
Geometry whose representation is to be transformed from an optimized rectangle to a valid polygon. The input geometry must have an SRID value of 0 (zero), as explained in the Usage Notes.

- to_srid
The SRID of the coordinate system to be used for the transformation (that is, the SRID to be used in the returned geometry).

`to_srid`

must be either a value in the SRID column of the SDO_COORD_REF_SYS table (described in Section 6.6.9) or NULL.Usage Notes

The geometry passed in must be an optimized rectangle.

If

`to_srid`

is a geodetic SRID, a geometry (not an optimized rectangle) is returned that conforms to the Oracle Spatial requirements for a geodetic geometry (for example, each polygon element's area must be less than one-half the surface area of the Earth).If

`to_srid`

is not a geodetic SRID, an optimized rectangle is returned in which the SRID is set to`to_srid`

.Visualizer applications that work on geodetic data usually treat the longitude and latitude space as a regular Cartesian coordinate system. Fetching the data corresponding to a viewport is usually done with the help of an SDO_FILTER or SDO_GEOM.RELATE operation where the viewport (with an optimized rectangle representation) is sent as the window query. Before release 10.1, this optimized rectangle type could not be used in geodetic space, and therefore this type of viewport query could not be sent to the database. The VIEWPORT_TRANSFORM function was created to provide a workaround to this previous restriction.

The viewport rectangles should be constructed with the SRID value as 0 and input to the function to generate a corresponding valid geodetic polygon. This geodetic polygon can then be used in the SDO_FILTER or SDO_GEOM.RELATE call as the window object.

An SRID value of 0 should only be specified when calling the VIEWPORT_TRANSFORM function. It is not valid in any other context in Spatial.

This function should be used only when the display space is equirectangular (a rectangle), and the data displayed is geodetic.

Examples

The following example specifies the viewport as the whole Earth represented by an optimized rectangle. It returns the names of all four cola markets. (This example uses the definitions from the example in Section 6.11.)

SELECT c.name FROM cola_markets_cs c WHERE SDO_FILTER(c.shape, SDO_CS.VIEWPORT_TRANSFORM( SDO_GEOMETRY( 2003, 0, -- SRID = 0 (special case) NULL, SDO_ELEM_INFO_ARRAY(1,1003,3), SDO_ORDINATE_ARRAY(-180,-90,180,90)), 8307)) = 'TRUE'; NAME -------------------------------- cola_a cola_c cola_b cola_dIf the optimizer does not generate an optimal plan and performance is not as you expect, you can try the following alternative version of the query.

SELECT c.name FROM cola_markets_cs c, (SELECT SDO_CS.VIEWPORT_TRANSFORM( SDO_GEOMETRY(2003, 0, NULL, SDO_ELEM_INFO_ARRAY(1,1003,3), SDO_ORDINATE_ARRAY(-180,-90,180,90)), 8307) window_geom FROM DUAL) WHERE SDO_FILTER(c.shape, window_geom) = 'TRUE'; NAME -------------------------------- cola_a cola_c cola_b cola_dConceptual and Usage Information PKȼPKlUIOEBPS/lrs_tol.gifwGIF89aX=LLLԿ؇Ð嘘픔???%%%TTT\\\...{{{&&&!!!zzz"""fff222;;;HHH666)))YYYnnnjjjwwwGGG鏏^^^ܺDDD]]]:::bbbsssKKKvvvrrrUUU***777PPPCCCXXXaaa333dddeeeiii|}|SSS,X= Ȭ ɯʺ AD_C `P 4dh#H+Q!N<@ FpĥP`EOI5Icҥ#(<(a)%|I]Е!d͖`+)`$t-.Ѩ!I$\CwKȑ'[ E^f_[u74Zem C At ՠ;pnpu5x0PEP!yA ńp@ (װe>]z׳'v Ҁ0D` "^LX g aD^YvtW+DJ)%P'&`H" &bR**YS2 2L7@[M8_R-d@ҥ `JPOPw10Q[M!H ?b ME qYӕdy(n)Hwy"vVޘ_f'Q|@TtTV*f)J>hs bEcQvM*z'\OQj*Jk+[챳kNg~0QT8HpL/!n ʻb ԐE0hAoSL(2 <^HL;O,[ZY<Ƅẖ w1 ,gB'@L\uc {2 XD"l@@-,0х-|Rxbޝw,+ [6Vc͛xSNb6)7F"dv(?$CBzH0oI"6JRw&deމL.$觯(7R~$WȾpoJ؎X G$`!:'H Z00' 1!(L(P0PC Pw@CPcam(P $G*ZXbD("B-^QH@LQ{ 6%"a1ؑk!## Part I

## Conceptual and Usage Information

This document has three parts:

Part I provides conceptual and usage information about Oracle Spatial.

Part II provides reference information about Oracle Spatial operators, functions, and procedures.

Part III provides supplementary information (appendixes and a glossary).

Part I is organized for efficient learning about Oracle Spatial. It covers basic concepts and techniques first, and proceeds to more advanced material (such as coordinate systems, the linear referencing system, geocoding, and extending spatial indexing). Part I contains the following chapters:

ḚІBH&p"uTable of Contents PK UKPKlUIOEBPS/query_mbrs.gifGIF89a???yyy<<<Ã̤ر"""fffCCCXXX&&&YYYjjjnnn>>>...GGG;;;{{{www!!!HHHbbbTTT222LLL%%%---\\\UUU777sss렠$$$aaa000}}}DDD @@@eeeiii,,,888uuuqqqmmmEEE]]]hhhPPPIII###+++QQQAAA```,@ (xpaB *qC/Rh1ǎ +8rɄ\ɲ˗0cʜI͛-?S'ɟ'} 'ѡ;$0iPJJիXjɴ逧[ÊKٳRxmJ۷7KZm;W/߿_vmo[ #^7+3U%c[2ϠCӨS}Yk_flٔoFM۴ݡuسKO03NloճkKvȿe3xϛ zߋ-5|->59vXuf_7uU2UDEa9_3ч(_,v6X 8i1(7ڈ:B/X׆ HdKJFY>FR2V!%gRׅrYՈefc(ӂvʙ "'Y+F5MZ߄dpV(iyZpYh5hJ"JjԩP *xiX=ZZ!UFƊUY KmҴfŶynזGnN$ Vfrz7/ƔYqL.llֹlǵŤMl/Uʄ.br⥬r< CҬ[jm%(+_*+Ͳiѿ@@JH@X1]p6+g r2\@, tAA|B#@B !MZZ4~pBA(@ 1Ж(4 _zӋS 0 ,AgҞ~_C @2`PCA@=z!u}X_0lЁFowւF.[㟵`IB@>@mz[RL5\!VH)oKpʧ- 2X! Kz0y^A A6pȦbSj/ŉ IB*x6MY&ɤ,=YNz\ HR)%L$UY%DGegIK:R!uc#}2 [&}!.bLt c,dxLaEMf5m4aifUMc9%dLtaY:NV5)rjE|a)9'ACO~GCΈ˛כn^fŞEuC08ǂѓh*%:]pZԣ4NEc+^*hLYU## Contents

## List of Examples

## List of Figures

## List of Tables

## Preface

## What's New in Oracle Spatial?

- Coordinate System Support Based on EPSG Model
- New SDO_GEOMETRY Methods and Constructors
- New min_resolution and max_resolution Keywords
- New sdo_dml_batch_size Parameter
- New Geocoding Subprograms
- New Utility Subprograms
- U.S. National Grid Support
- Unknown and NaC Coordinate Reference Systems
- Spatial Routing Engine
- LRS_INTERSECTION Function
## Part I Conceptual and Usage Information

## 1 Spatial Concepts

- 1.1 What Is Oracle Spatial?
- 1.2 Object-Relational Model
- 1.3 Introduction to Spatial Data
- 1.4 Geometry Types
- 1.5 Data Model
- 1.6 Query Model
- 1.7 Indexing of Spatial Data
- 1.8 Spatial Relationships and Filtering
- 1.9 Spatial Operators, Procedures, and Functions
- 1.10 Spatial Aggregate Functions
- 1.11 Geocoding
- 1.12 Spatial Java Application Programming Interface
- 1.13 MDDATA Schema
- 1.14 Performance and Tuning Information
- 1.15 Open Geospatial Consortium (OGC) Conformance
- 1.16 Spatial Release (Version) Number
- 1.17 Spatial Application Hardware Requirement Considerations
- 1.18 Spatial Error Messages
- 1.19 Spatial Examples
- 1.20 README File for Spatial and Related Features
## 2 Spatial Data Types and Metadata

- 2.1 Simple Example: Inserting, Indexing, and Querying Spatial Data
- 2.2 SDO_GEOMETRY Object Type
- 2.3 SDO_GEOMETRY Methods
- 2.4 SDO_GEOMETRY Constructors
- 2.5 Geometry Examples
- 2.6 Geometry Metadata Views
- 2.7 Spatial Index-Related Structures
- 2.8 Unit of Measurement Support
## 3 Loading Spatial Data

## 4 Indexing and Querying Spatial Data

- 4.1 Creating a Spatial Index

- 4.1.1 Indexing Geodetic Data
- 4.1.2 Constraining Data to a Geometry Type
- 4.1.3 Creating a Cross-Schema Index
- 4.1.4 Using Partitioned Spatial Indexes
- 4.1.5 Exchanging Partitions Including Indexes
- 4.1.6 Export and Import Considerations with Spatial Indexes and Data
- 4.1.7 Distributed Transactions and Spatial Index Consistency
- 4.2 Querying Spatial Data
## 5 Geocoding Address Data

- 5.1 Concepts for Geocoding
- 5.2 Data Types for Geocoding
- 5.3 Using the Geocoding Capabilities
- 5.4 Geocoding from a Place Name
- 5.5 Data Structures for Geocoding
## 6 Coordinate Systems (Spatial Reference Systems)

- 6.1 Terms and Concepts
- 6.2 Geodetic Coordinate Support
- 6.3 Local Coordinate Support
- 6.4 EPSG Model and Spatial
- 6.5 TFM_PLAN Object Type
- 6.6 Coordinate Systems Data Structures

- 6.6.1 SDO_COORD_AXES Table
- 6.6.2 SDO_COORD_AXIS_NAMES Table
- 6.6.3 SDO_COORD_OP_METHODS Table
- 6.6.4 SDO_COORD_OP_PARAM_USE Table
- 6.6.5 SDO_COORD_OP_PARAM_VALS Table
- 6.6.6 SDO_COORD_OP_PARAMS Table
- 6.6.7 SDO_COORD_OP_PATHS Table
- 6.6.8 SDO_COORD_OPS Table
- 6.6.9 SDO_COORD_REF_SYS Table
- 6.6.10 SDO_COORD_REF_SYSTEM View
- 6.6.11 SDO_COORD_SYS Table
- 6.6.12 SDO_CRS_COMPOUND View
- 6.6.13 SDO_CRS_ENGINEERING View
- 6.6.14 SDO_CRS_GEOCENTRIC View
- 6.6.15 SDO_CRS_GEOGRAPHIC2D View
- 6.6.16 SDO_CRS_GEOGRAPHIC3D View
- 6.6.17 SDO_CRS_PROJECTED View
- 6.6.18 SDO_CRS_VERTICAL View
- 6.6.19 SDO_DATUM_ENGINEERING View
- 6.6.20 SDO_DATUM_GEODETIC View
- 6.6.21 SDO_DATUM_VERTICAL View
- 6.6.22 SDO_DATUMS Table
- 6.6.23 SDO_ELLIPSOIDS Table
- 6.6.24 SDO_PREFERRED_OPS_SYSTEM Table
- 6.6.25 SDO_PREFERRED_OPS_USER Table
- 6.6.26 SDO_PRIME_MERIDIANS Table
- 6.6.27 SDO_UNITS_OF_MEASURE Table
- 6.7 Legacy Tables and Views

- 6.7.1 MDSYS.CS_SRS Table
- 6.7.2 MDSYS.SDO_ANGLE_UNITS View
- 6.7.3 MDSYS.SDO_AREA_UNITS View
- 6.7.4 MDSYS.SDO_DATUMS_OLD_FORMAT and SDO_DATUMS_OLD_SNAPSHOT Tables
- 6.7.5 MDSYS.SDO_DIST_UNITS View
- 6.7.6 MDSYS.SDO_ELLIPSOIDS_OLD_FORMAT and SDO_ELLIPSOIDS_OLD_SNAPSHOT Tables
- 6.7.7 MDSYS.SDO_PROJECTIONS_OLD_FORMAT and SDO_PROJECTIONS_OLD_SNAPSHOT Tables
- 6.8 Creating a User-Defined Coordinate Reference System
- 6.9 Notes and Restrictions with Coordinate Systems Support
- 6.10 U.S. National Grid Support
- 6.11 Example of Coordinate System Transformation
## 7 Linear Referencing System

- 7.1 Terms and Concepts

- 7.1.1 Geometric Segments (LRS Segments)
- 7.1.2 Shape Points
- 7.1.3 Direction of a Geometric Segment
- 7.1.4 Measure (Linear Measure)
- 7.1.5 Offset
- 7.1.6 Measure Populating
- 7.1.7 Measure Range of a Geometric Segment
- 7.1.8 Projection
- 7.1.9 LRS Point
- 7.1.10 Linear Features
- 7.1.11 Measures with Multiline Strings and Polygons with Holes
- 7.2 LRS Data Model
- 7.3 Indexing of LRS Data
- 7.4 3D Formats of LRS Functions
- 7.5 LRS Operations

- 7.5.1 Defining a Geometric Segment
- 7.5.2 Redefining a Geometric Segment
- 7.5.3 Clipping a Geometric Segment
- 7.5.4 Splitting a Geometric Segment
- 7.5.5 Concatenating Geometric Segments
- 7.5.6 Scaling a Geometric Segment
- 7.5.7 Offsetting a Geometric Segment
- 7.5.8 Locating a Point on a Geometric Segment
- 7.5.9 Projecting a Point onto a Geometric Segment
- 7.5.10 Converting LRS Geometries
- 7.6 Tolerance Values with LRS Functions
- 7.7 Example of LRS Functions
## 8 Spatial Analysis and Mining

- 8.1 Spatial Information and Data Mining Applications
- 8.2 Spatial Binning for Detection of Regional Patterns
- 8.3 Materializing Spatial Correlation
- 8.4 Colocation Mining
- 8.5 Spatial Clustering
- 8.6 Location Prospecting
## 9 Extending Spatial Indexing Capabilities

- 9.1 SDO_GEOMETRY Objects in User-Defined Type Definitions
- 9.2 SDO_GEOMETRY Objects in Function-Based Indexes
## Part II Reference Information

## 10 SQL Statements for Indexing Spatial Data

## 11 Spatial Operators

- SDO_ANYINTERACT
- SDO_CONTAINS
- SDO_COVEREDBY
- SDO_COVERS
- SDO_EQUAL
- SDO_FILTER
- SDO_INSIDE
- SDO_JOIN
- SDO_NN
- SDO_NN_DISTANCE
- SDO_ON
- SDO_OVERLAPBDYDISJOINT
- SDO_OVERLAPBDYINTERSECT
- SDO_OVERLAPS
- SDO_RELATE
- SDO_TOUCH
- SDO_WITHIN_DISTANCE
## 12 Spatial Aggregate Functions

- SDO_AGGR_CENTROID
- SDO_AGGR_CONCAT_LINES
- SDO_AGGR_CONVEXHULL
- SDO_AGGR_LRS_CONCAT
- SDO_AGGR_MBR
- SDO_AGGR_UNION
## 13 SDO_CS Package (Coordinate System Transformation)

- SDO_CS.ADD_PREFERENCE_FOR_OP
- SDO_CS.CONVERT_NADCON_TO_XML
- SDO_CS.CONVERT_NTV2_TO_XML
- SDO_CS.CONVERT_XML_TO_NADCON
- SDO_CS.CONVERT_XML_TO_NTV2
- SDO_CS.CREATE_CONCATENATED_OP
- SDO_CS.CREATE_OBVIOUS_EPSG_RULES
- SDO_CS.CREATE_PREF_CONCATENATED_OP
- SDO_CS.DELETE_ALL_EPSG_RULES
- SDO_CS.DELETE_OP
- SDO_CS.DETERMINE_CHAIN
- SDO_CS.DETERMINE_DEFAULT_CHAIN
- SDO_CS.FIND_GEOG_CRS
- SDO_CS.FIND_PROJ_CRS
- SDO_CS.FROM_OGC_SIMPLEFEATURE_SRS
- SDO_CS.FROM_USNG
- SDO_CS.MAP_EPSG_SRID_TO_ORACLE
- SDO_CS.MAP_ORACLE_SRID_TO_EPSG
- SDO_CS.REVOKE_PREFERENCE_FOR_OP
- SDO_CS.TO_OGC_SIMPLEFEATURE_SRS
- SDO_CS.TO_USNG
- SDO_CS.TRANSFORM
- SDO_CS.TRANSFORM_LAYER
- SDO_CS.UPDATE_WKTS_FOR_ALL_EPSG_CRS
- SDO_CS.UPDATE_WKTS_FOR_EPSG_CRS
- SDO_CS.UPDATE_WKTS_FOR_EPSG_DATUM
- SDO_CS.UPDATE_WKTS_FOR_EPSG_ELLIPS
- SDO_CS.UPDATE_WKTS_FOR_EPSG_OP
- SDO_CS.UPDATE_WKTS_FOR_EPSG_PARAM
- SDO_CS.UPDATE_WKTS_K5FOR_EPSG_PM
- SDO_CS.VALIDATE_WKT
- SDO_CS.VIEWPORT_TRANSFORM
## 14 SDO_GCDR Package (Geocoding)

- SDO_GCDR.GEOCODE
- SDO_GCDR.GEOCODE_ADDR
- SDO_GCDR.GEOCODE_ADDR_ALL
- SDO_GCDR.GEOCODE_ALL
- SDO_GCDR.GEOCODE_AS_GEOMETRY
- SDO_GCDR.REVERSE_GEOCODE
## 15 SDO_GEOM Package (Geometry)

- SDO_GEOM.RELATE
- SDO_GEOM.SDO_ARC_DENSIFY
- SDO_GEOM.SDO_AREA
- SDO_GEOM.SDO_BUFFER
- SDO_GEOM.SDO_CENTROID
- SDO_GEOM.SDO_CONVEXHULL
- SDO_GEOM.SDO_DIFFERENCE
- SDO_GEOM.SDO_DISTANCE
- SDO_GEOM.SDO_INTERSECTION
- SDO_GEOM.SDO_LENGTH
- SDO_GEOM.SDO_MAX_MBR_ORDINATE
- SDO_GEOM.SDO_MBR
- SDO_GEOM.SDO_MIN_MBR_ORDINATE
- SDO_GEOM.SDO_POINTONSURFACE
- SDO_GEOM.SDO_UNION
- SDO_GEOM.SDO_XOR
- SDO_GEOM.VALIDATE_GEOMETRY_WITH_CONTEXT
- SDO_GEOM.VALIDATE_LAYER_WITH_CONTEXT
- SDO_GEOM.WITHIN_DISTANCE
## 16 SDO_LRS Package (Linear Referencing System)

- SDO_LRS.CLIP_GEOM_SEGMENT
- SDO_LRS.CONCATENATE_GEOM_SEGMENTS
- SDO_LRS.CONNECTED_GEOM_SEGMENTS
- SDO_LRS.CONVERT_TO_LRS_DIM_ARRAY
- SDO_LRS.CONVERT_TO_LRS_GEOM
- SDO_LRS.CONVERT_TO_LRS_LAYER
- SDO_LRS.CONVERT_TO_STD_DIM_ARRAY
- SDO_LRS.CONVERT_TO_STD_GEOM
- SDO_LRS.CONVERT_TO_STD_LAYER
- SDO_LRS.DEFINE_GEOM_SEGMENT
- SDO_LRS.DYNAMIC_SEGMENT
- SDO_LRS.FIND_LRS_DIM_POS
- SDO_LRS.FIND_MEASURE
- SDO_LRS.FIND_OFFSET
- SDO_LRS.GEOM_SEGMENT_END_MEASURE
- SDO_LRS.GEOM_SEGMENT_END_PT
- SDO_LRS.GEOM_SEGMENT_LENGTH
- SDO_LRS.GEOM_SEGMENT_START_MEASURE
- SDO_LRS.GEOM_SEGMENT_START_PT
- SDO_LRS.GET_MEASURE
- SDO_LRS.GET_NEXT_SHAPE_PT
- SDO_LRS.GET_NEXT_SHAPE_PT_MEASURE
- SDO_LRS.GET_PREV_SHAPE_PT
- SDO_LRS.GET_PREV_SHAPE_PT_MEASURE
- SDO_LRS.IS_GEOM_SEGMENT_DEFINED
- SDO_LRS.IS_MEASURE_DECREASING
- SDO_LRS.IS_MEASURE_INCREASING
- SDO_LRS.IS_SHAPE_PT_MEASURE
- SDO_LRS.LOCATE_PT
- SDO_LRS.LRS_INTERSECTION
- SDO_LRS.MEASURE_RANGE
- SDO_LRS.MEASURE_TO_PERCENTAGE
- SDO_LRS.OFFSET_GEOM_SEGMENT
- SDO_LRS.PERCENTAGE_TO_MEASURE
- SDO_LRS.PROJECT_PT
- SDO_LRS.REDEFINE_GEOM_SEGMENT
- SDO_LRS.RESET_MEASURE
- SDO_LRS.REVERSE_GEOMETRY
- SDO_LRS.REVERSE_MEASURE
- SDO_LRS.SET_PT_MEASURE
- SDO_LRS.SPLIT_GEOM_SEGMENT
- SDO_LRS.TRANSLATE_MEASURE
- SDO_LRS.VALID_GEOM_SEGMENT
- SDO_LRS.VALID_LRS_PT
- SDO_LRS.VALID_MEASURE
- SDO_LRS.VALIDATE_LRS_GEOMETRY
## 17 SDO_MIGRATE Package (Upgrading)

## 18 SDO_SAM Package (Spatial Analysis and Mining)

- SDO_SAM.AGGREGATES_FOR_GEOMETRY
- SDO_SAM.AGGREGATES_FOR_LAYER
- SDO_SAM.BIN_GEOMETRY
- SDO_SAM.BIN_LAYER
- SDO_SAM.COLOCATED_REFERENCE_FEATURES
- SDO_SAM.SIMPLIFY_GEOMETRY
- SDO_SAM.SIMPLIFY_LAYER
- SDO_SAM.SPATIAL_CLUSTERS
- SDO_SAM.TILED_AGGREGATES
- SDO_SAM.TILED_BINS
## 19 SDO_TUNE Package (Tuning)

- SDO_TUNE.AVERAGE_MBR
- SDO_TUNE.ESTIMATE_RTREE_INDEX_SIZE
- SDO_TUNE.EXTENT_OF
- SDO_TUNE.MIX_INFO
- SDO_TUNE.QUALITY_DEGRADATION
## 20 SDO_UTIL Package (Utility)

- SDO_UTIL.APPEND
- SDO_UTIL.CIRCLE_POLYGON
- SDO_UTIL.CONCAT_LINES
- SDO_UTIL.CONVERT_UNIT
- SDO_UTIL.ELLIPSE_POLYGON
- SDO_UTIL.EXTRACT
- SDO_UTIL.FROM_WKBGEOMETRY
- SDO_UTIL.FROM_WKTGEOMETRY
- SDO_UTIL.GETNUMELEM
- SDO_UTIL.GETNUMVERTICES
- SDO_UTIL.GETVERTICES
- SDO_UTIL.INITIALIZE_INDEXES_FOR_TTS
- SDO_UTIL.POINT_AT_BEARING
- SDO_UTIL.POLYGONTOLINE
- SDO_UTIL.PREPARE_FOR_TTS
- SDO_UTIL.RECTIFY_GEOMETRY
- SDO_UTIL.REMOVE_DUPLICATE_VERTICES
- SDO_UTIL.REVERSE_LINESTRING
- SDO_UTIL.SIMPLIFY
- SDO_UTIL.TO_GMLGEOMETRY
- SDO_UTIL.TO_WKBGEOMETRY
- SDO_UTIL.TO_WKTGEOMETRY
- SDO_UTIL.VALIDATE_WKBGEOMETRY
- SDO_UTIL.VALIDATE_WKTGEOMETRY
## Part III Supplementary Information

## A Installation, Compatibility, and Upgrade

## B Oracle Locator

## C Routing Engine

- C.1 Deploying and Configuring the Routing Engine
- C.2 Routing Engine XML API
- C.3 Data Structures Used by the Routing Engine
## D Complex Spatial Queries: Examples

- D.1 Tables Used in the Examples
- D.2 SDO_WITHIN_DISTANCE Examples
- D.3 SDO_NN Examples
- D.4 SDO_AGGR_UNION Example
## Glossary

## Index

bwo2M%b(G oz/_kۚ)`xR v+mrא>&*xFK{by]\PC q5'ŘMq 2MՆcE%j1! 8F8BPcDyԖ!,Y#$A K`Bw%|aL7' |R=P(L PxPLY "j4c5,dAJ-$Al`B EhI$ǘ'4QJ[56`1!SU(@ʐ&6Yh8å52aG,YBoqtU.}Fم22e4,}/+ٴU2e#8S^+d p@r8 rpkc3+q[ ?:<:ks0P:$'pA!(-jIV;y27=B: rx[/0A`pA}hu iȂ⳰21ƙ @jSf5^Yza~9g=VC2cڙΆmmmg{ms䤷B qPBfм1p; r\XCGk' GQp:'rr7uwxQwz/T|VaitBGtFtqtLtPph120qslCwvww|w'xGFE2Cjp_nzz{{wS)10n2bjJ|7}էKקR4.'Z+?[g1Wmn3BHi6by$^-BmMN~/%T'xSo_x"fX~ԥHV/,g'Ep_Debha8Vq+JK'BPŊ3[&fqV%3qV\,6GcqVW*%b^Ĩ4Z5-l0(&52'S1 _ha`!NxaH&H_IxKuZSO/u+?&W4HfcP^p1(.)N1:Z$Y}^ts(PLXx]QNEՎnQ0!AsL/ J12DlXYElHQ&RHz-~AIqqKlEmc4FYsRɧ7vcSv$ `~ْ!i;Fs8e,4DqY{4;)`.E| 2@Y^Ny_֚)(㸓zQr*#l9'qőwWȩTYO;)Q9(!,YY rB& x)M9`9y( 5xFoYkyLɞ4nԕ'FzhBtɜ84RɡuŘYV"*VrG2T X* :mKzbafjUy Su/TyGqP|0w媒B_us0(jj1]gbv~h~gfh.K'Qy6jvjjyFkZ,~pZ2ʫ@Qg6mvmGmr&ncw@u:}}p pgpJ3i1g 'r%gr(rgx]D' ܥCWtGtKtt-[BIp}]V02xwyw})98xA˱mUzK/LhzQ(A^[)#G}4\fu$ 2uhikf_5ˡg굁NZ(~DzyL!$F˜+pv['+QK;Q;*g먹GMQ;+?;PK]nPKlUIOEBPS/sdodiff.gif GIF89a~~~333WWW???rrrfffKKK$$$DDDUUUwww""",` dihlp tmxpH,Ȥrl:tJ~ϬvzQxl~:&8zNg[nxzek=|Mql:c1,e~TWs};µ"ǺnŷO6Ѭ\WFAHC0`9Z&+ T9|љ+1_:zKȑ$_926,[&̙ؼ3mP@y@dR| O`A h͊ h%0@CEJEXU@48ipU\o5 DSe>ٌȱ{ 3 2C`Zssc=v}׀_Â {z6m`mbE(;4qH5bٵ6A`o ʌ?f fT >JHaD@{E@ x` sm|7v-zŠ,琕+ܰ^me,NMN)|kҋL^oROߪꯟ~`DO})|B;PKxUPKlUIOEBPS/sdo_lrs_ref.htm SDO_LRS Package (Linear Referencing System) PKkp)PKlUIOEBPS/scaling.gifGIF89aCCCGGGTTTfffvvvLLL???]]]aaaeee鋋PPPYYY;;;DDDXXX&&&Ĝ\\\jjj)))îwwwԲUUUsss{{{...nnnHHHrrr!!!"""333%%%666bbbȠiii***777---WWW^^^222xxxzzzKKKooo:::```SSS|}|, ąφ ɜ ؛xeаڄ Az堃@pBPE8($,bǲKb;A#:DB M4p!D8M9{ @ !PZpQnZ˷p㮊I0^}3Ӂ2k?e2w7^Z5H!pˡ̌^<ӨZͺװaӝ-ab":qf4z@?z>+qSܺy@܂R؊!2HuS_*̞oVU>+"APr0GswF !%KG0@8!hMͧC(9@)6PAͅА FH9$LԀ`y`L/B ЂhLDr!t,<(i-Z8FKtPDR, M(P@ Nl"6DQHDBH>H08 xk;h(DEr3ꮼ$0"%K6PőfJcVbEU[k,l'7G,Wlg#/@9b$,q),846aAԀE(sD4)2P@0T$1^-RpiQIЊك>Ta3hY(UtQ5Oᝄ YY'WR$ A fKeUW ~>dN: U_p`vIn *cr [@T60@09e^@Q`._U 0etW0T>C/H[B8`Bb|6;Envs :ZKXĊ <'x9BЂ|@!B6\ 19AG?UЄPϊ@%K"aH*kJ&쀆 Ѡ0fM" Q( !0D@,-\K`(IJ@h-o>JJX Mhc418ai|D/r thAEP%2PB `B,Dm`RT#z-Jqꅩ"t C.@)XA)(r@`e%6 kZD y 8(dp# JN1H GE`E2QQ\OIls $'+0 /PpU`$BS4. 10 t8@ hn'sH`\JS KV@-j* aO{kY<`DAUB#ˌYX\7,nJZ,+"Vu .Lx`(@m#SBom/(PҢ~\A1UN2~MqK'4ӛنQBY0:"FBԔ%G-B4'lX{|B,D>*@X"lt~OMr}DBA10(SpS엿ڴK<30yLdES9x8z($ؘ=}P@n&f_XfH] @ŌcR7y"*{5 hHjHbsc h/= _tQdϻ S(="!t"vATn >i6?@@_0 Ӹ04hԎ@ jX-.4" ^DfJYPC0]E Caz id8{6`PPX}f1~_`6?pd H8Q)ƛxLۋ0G600Tix@%|/PV_50-pC `gsK8 a\D=0Eq#DMfz4kX8 `U?[b@z%M## 16 SDO_LRS Package (Linear Referencing System)

The MDSYS.SDO_LRS package contains subprograms that create, modify, query, and convert linear referencing elements. These subprograms do not change the state of the database. Most LRS subprograms are functions.

To use the subprograms in this chapter, you must understand the linear referencing system (LRS) concepts and techniques described in Chapter 7.

Table 16-1 lists subprograms related to creating and editing geometric segments.

Table 16-1 Subprograms for Creating and Editing Geometric Segments

Subprogram Description Defines a geometric segment.

Populates the measures of all shape points of a geometric segment based on the start and end measures, overriding any previously assigned measures between the start point and end point.

Clips a geometric segment (synonym of SDO_LRS.DYNAMIC_SEGMENT).

Clips a geometric segment (synonym of SDO_LRS.CLIP_GEOM_SEGMENT).

SDO_LRS.CONCATENATE_GEOM_SEGMENTS

Concatenates two geometric segments into one segment.

Returns an LRS geometry object that is the topological intersection (AND operation) of two geometry objects where one or both are LRS geometries.

Returns the geometric segment at a specified offset from a geometric segment.

Splits a geometric segment into two segments.

Sets all measures of a geometric segment, including the start and end measures, to null values, overriding any previously assigned measures.

Sets the measure value of a specified point.

Returns a new geometric segment by reversing the measure values, but not the direction, of the original geometric segment.

Returns a new geometric segment by translating the original geometric segment (that is, shifting the start and end measures by a specified value).

Returns a new geometric segment by reversing the measure values and the direction of the original geometric segment.

Table 16-2 lists subprograms related to querying geometric segments.

Table 16-2 Subprograms for Querying and Validating Geometric Segments

Subprogram Description Checks if a geometric segment is valid.

Checks if an LRS point is valid.

Checks if a measure falls within the measure range of a geometric segment.

SDO_LRS.CONNECTED_GEOM_SEGMENTS

Checks if two geometric segments are spatially connected.

Returns the length of a geometric segment.

Returns the start point of a geometric segment.

Returns the end point of a geometric segment.

SDO_LRS.GEOM_SEGMENT_START_MEASURE

Returns the start measure of a geometric segment.

SDO_LRS.GEOM_SEGMENT_END_MEASURE

Returns the end measure of a geometric segment.

Returns the measure of an LRS point.

Returns the next shape point on a geometric segment after a specified measure value or LRS point.

SDO_LRS.GET_NEXT_SHAPE_PT_MEASURE

Returns the measure value of the next shape point on a geometric segment after a specified measure value or LRS point.

Returns the previous shape point on a geometric segment before a specified measure value or LRS point.

SDO_LRS.GET_PREV_SHAPE_PT_MEASURE

Returns the measure value of the previous shape point on a geometric segment before a specified measure value or LRS point.

SDO_LRS.IS_GEOM_SEGMENT_DEFINED

Checks if an LRS segment is defined correctly.

Checks if the measure values along an LRS segment are decreasing (that is, descending in numerical value).

Checks if the measure values along an LRS segment are increasing (that is, ascending in numerical value).

Checks if a specified measure value is associated with a shape point on a geometric segment.

Returns the measure range of a geometric segment, that is, the difference between the start measure and end measure.

Returns the percentage (0 to 100) that a specified measure is of the measure range of a geometric segment.

Returns the measure value of a specified percentage (0 to 100) of the measure range of a geometric segment.

Returns the point located at a specified distance from the start of a geometric segment.

Returns the projection point of a specified point. The projection point is on the geometric segment.

Returns the position of the measure dimension within the SDO_DIM_ARRAY structure for a specified SDO_GEOMETRY column.

Returns the measure of the closest point on a segment to a specified projection point.

Returns the signed offset (shortest distance) from a point to a geometric segment.

Checks if an LRS geometry is valid.

Table 16-3 lists subprograms related to converting geometric segments.

Table 16-3 Subprograms for Converting Geometric Segments

Subprogram Description SDO_LRS.CONVERT_TO_LRS_DIM_ARRAY

Converts a standard dimensional array to an LRS dimensional array by creating a measure dimension.

Converts a standard SDO_GEOMETRY line string to an LRS geometric segment by adding measure information.

Converts all geometry objects in a column of type SDO_GEOMETRY from standard line string geometries without measure information to LRS geometric segments with measure information, and updates the metadata.

SDO_LRS.CONVERT_TO_STD_DIM_ARRAY

Converts an LRS dimensional array to a standard dimensional array by removing the measure dimension.

Converts an LRS geometric segment to a standard SDO_GEOMETRY line string by removing measure information.

Converts all geometry objects in a column of type SDO_GEOMETRY from LRS geometric segments with measure information to standard line string geometries without measure information, and updates the metadata.

For more information about conversion subprograms, see Section 7.5.10.

The rest of this chapter provides reference information on the subprograms, listed in alphabetical order.

## SDO_LRS.CLIP_GEOM_SEGMENT

Format

SDO_LRS.CLIP_GEOM_SEGMENT(

geom_segment IN SDO_GEOMETRY,

start_measure IN NUMBER,

end_measure IN NUMBER,

tolerance IN NUMBER DEFAULT 1.0e-8

) RETURN SDO_GEOMETRY;

or

SDO_LRS.CLIP_GEOM_SEGMENT(

geom_segment IN SDO_GEOMETRY,

dim_array IN SDO_DIM_ARRAY,

start_measure IN NUMBER,

end_measure IN NUMBER

) RETURN SDO_GEOMETRY;

Description

Returns the geometry object resulting from a clip operation on a geometric segment.

Note:

SDO_LRS.CLIP_GEOM_SEGMENT and SDO_LRS.DYNAMIC_SEGMENT are synonyms: both functions have the same parameters, behavior, and return value.Parameters

- geom_segment
Cartographic representation of a linear feature.

- dim_array
Dimensional information array corresponding to

`geom_segment`

, usually selected from one of the xxx_SDO_GEOM_METADATA views (described in Section 2.6).- start_measure
Start measure of the geometric segment.

- end_measure
End measure of the geometric segment.

- tolerance
Tolerance value (see Section 1.5.5 and Section 7.6). The default value is 0.00000001.

Usage Notes

An exception is raised if

`geom_segment`

,`start_measure`

, or`end_measure`

is invalid.

`start_measure`

and`end_measure`

can be any points on the geometric segment. They do not have to be in any specific order. For example,`start_measure`

and`end_measure`

can be 5 and 10, respectively, or 10 and 5, respectively.The direction and measures of the resulting geometric segment are preserved (that is, they reflect the original segment).

The _3D format of this function (SDO_LRS.CLIP_GEOM_SEGMENT_3D) is available. For information about _3D formats of LRS functions, see Section 7.4.

For more information about clipping geometric segments, see Section 7.5.3.

Examples

The following example clips the geometric segment representing Route 1, returning the segment from measures 5 through 10. This segment might represent a construction zone. (This example uses the definitions from the example in Section 7.7.)

SELECT SDO_LRS.CLIP_GEOM_SEGMENT(route_geometry, 5, 10) FROM lrs_routes WHERE route_id = 1; SDO_LRS.CLIP_GEOM_SEGMENT(ROUTE_GEOMETRY,5,10)(SDO_GTYPE, SDO_SRID, SDO_POINT(X, -------------------------------------------------------------------------------- SDO_GEOMETRY(3302, NULL, NULL, SDO_ELEM_INFO_ARRAY(1, 2, 1), SDO_ORDINATE_ARRAY( 5, 4, 5, 8, 4, 8, 10, 4, 10))

## SDO_LRS.CONCATENATE_GEOM_SEGMENTS

Format

SDO_LRS.CONCATENATE_GEOM_SEGMENTS(

geom_segment_1 IN SDO_GEOMETRY,

geom_segment_2 IN SDO_GEOMETRY,

tolerance IN NUMBER DEFAULT 1.0e-8

) RETURN SDO_GEOMETRY;

or

SDO_LRS.CONCATENATE_GEOM_SEGMENTS(

geom_segment_1 IN SDO_GEOMETRY,

dim_array_1 IN SDO_DIM_ARRAY,

geom_segment_2 IN SDO_GEOMETRY,

dim_array_2 IN SDO_DIM_ARRAY

) RETURN SDO_GEOMETRY;

Description

Returns the geometry object resulting from the concatenation of two geometric segments.

Parameters

- geom_segment_1
First geometric segment to be concatenated.

- dim_array_1
Dimensional information array corresponding to

`geom_segment_1`

, usually selected from one of the xxx_SDO_GEOM_METADATA views (described in Section 2.6).- geom_segment_2
Second geometric segment to be concatenated.

- dim_array_2
Dimensional information array corresponding to

`geom_segment_2`

, usually selected from one of the xxx_SDO_GEOM_METADATA views (described in Section 2.6).- tolerance
Tolerance value (see Section 1.5.5 and Section 7.6). The default value is 0.00000001.

Usage Notes

An exception is raised if

`geom_segment_1`

or`geom_segment_2`

has an invalid geometry type or dimensionality, or if`geom_segment_1`

and`geom_segment_2`

are based on different coordinate systems.The direction of the first geometric segment is preserved, and all measures of the second segment are shifted so that its start measure is the same as the end measure of the first segment.

The geometry type of

`geom_segment_1`

and`geom_segment_2`

must be line or multiline. Neither can be a polygon.The _3D format of this function (SDO_LRS.CONCATENATE_GEOM_SEGMENTS_3D) is available. For information about _3D formats of LRS functions, see Section 7.4.

For more information about concatenating geometric segments, see Section 7.5.5.

Examples

The following example defines the geometric segment, splits it into two segments, then concatenates those segments. (This example uses the definitions from the example in Section 7.7. The definitions of

`result_geom_1`

,`result_geom_2`

, and`result_geom_3`

are displayed in Example 7-3.)DECLARE geom_segment SDO_GEOMETRY; line_string SDO_GEOMETRY; dim_array SDO_DIM_ARRAY; result_geom_1 SDO_GEOMETRY; result_geom_2 SDO_GEOMETRY; result_geom_3 SDO_GEOMETRY; BEGIN SELECT a.route_geometry into geom_segment FROM lrs_routes a WHERE a.route_name = 'Route1'; SELECT m.diminfo into dim_array from user_sdo_geom_metadata m WHERE m.table_name = 'LRS_ROUTES' AND m.column_name = 'ROUTE_GEOMETRY'; -- Define the LRS segment for Route1. SDO_LRS.DEFINE_GEOM_SEGMENT (geom_segment, dim_array, 0, -- Zero starting measure: LRS segment starts at start of route. 27); -- End of LRS segment is at measure 27. SELECT a.route_geometry INTO line_string FROM lrs_routes a WHERE a.route_name = 'Route1'; -- Split Route1 into two segments. SDO_LRS.SPLIT_GEOM_SEGMENT(line_string,dim_array,5,result_geom_1,result_geom_2); -- Concatenate the segments that were just split. result_geom_3 := SDO_LRS.CONCATENATE_GEOM_SEGMENTS(result_geom_1, dim_array, result_geom_2, dim_array); -- Insert geometries into table, to display later. INSERT INTO lrs_routes VALUES( 11, 'result_geom_1', result_geom_1 ); INSERT INTO lrs_routes VALUES( 12, 'result_geom_2', result_geom_2 ); INSERT INTO lrs_routes VALUES( 13, 'result_geom_3', result_geom_3 ); END; /

## SDO_LRS.CONNECTED_GEOM_SEGMENTS

Format

SDO_LRS.CONNECTED_GEOM_SEGMENTS(

geom_segment_1 IN SDO_GEOMETRY,

geom_segment_2 IN SDO_GEOMETRY,

tolerance IN NUMBER DEFAULT 1.0e-8

) RETURN VARCHAR2;

or

SDO_LRS.CONNECTED_GEOM_SEGMENTS(

geom_segment_1 IN SDO_GEOMETRY,

dim_array_1 IN SDO_DIM_ARRAY,

geom_segment_2 IN SDO_GEOMETRY,

dim_array_2 IN SDO_DIM_ARRAY

) RETURN VARCHAR2;

Description

Checks if two geometric segments are spatially connected.

Parameters

- geom_segment_1
First of two geometric segments to be checked.

- dim_array_1
Dimensional information array corresponding to

`geom_segment_1`

, usually selected from one of the xxx_SDO_GEOM_METADATA views (described in Section 2.6).- geom_segment_2
Second of two geometric segments to be checked.

- dim_array_2
Dimensional information array corresponding to

`geom_segment_2`

, usually selected from one of the xxx_SDO_GEOM_METADATA views (described in Section 2.6).- tolerance
Tolerance value (see Section 1.5.5 and Section 7.6). The default value is 0.00000001.

Usage Notes

This function returns TRUE if the geometric segments are spatially connected and FALSE if the geometric segments are not spatially connected.

An exception is raised if

`geom_segment_1`

or`geom_segment_2`

has an invalid geometry type or dimensionality, or if`geom_segment_1`

and`geom_segment_2`

are based on different coordinate systems.The _3D format of this function (SDO_LRS.CONNECTED_GEOM_SEGMENTS_3D) is available. For information about _3D formats of LRS functions, see Section 7.4.

Examples

The following example checks if two geometric segments (results of a previous split operation) are spatially connected.

-- Are result_geom_1 and result_geom2 connected? SELECT SDO_LRS.CONNECTED_GEOM_SEGMENTS(a.route_geometry, b.route_geometry, 0.005) FROM lrs_routes a, lrs_routes b WHERE a.route_id = 11 AND b.route_id = 12; SDO_LRS.CONNECTED_GEOM_SEGMENTS(A.ROUTE_GEOMETRY,B.ROUTE_GEOMETRY,0.005) -------------------------------------------------------------------------------- TRUE

## SDO_LRS.CONVERT_TO_LRS_DIM_ARRAY

Format

SDO_LRS.CONVERT_TO_LRS_DIM_ARRAY(

dim_array IN SDO_DIM_ARRAY

[, lower_bound IN NUMBER,

upper_bound IN NUMBER,

tolerance IN NUMBER]

) RETURN SDO_DIM_ARRAY;

or

SDO_LRS.CONVERT_TO_LRS_DIM_ARRAY(

dim_array IN SDO_DIM_ARRAY,

dim_name IN VARCHAR2

[, lower_bound IN NUMBER,

upper_bound IN NUMBER,

tolerance IN NUMBER]

) RETURN SDO_DIM_ARRAY;

or

SDO_LRS.CONVERT_TO_LRS_DIM_ARRAY(

dim_array IN SDO_DIM_ARRAY,

dim_name IN VARCHAR2,

dim_pos IN INTEGER

[, lower_bound IN NUMBER,

upper_bound IN NUMBER,

tolerance IN NUMBER]

) RETURN SDO_DIM_ARRAY;

Description

Converts a standard dimensional array to an LRS dimensional array by creating a measure dimension.

Parameters

- dim_array
Dimensional information array corresponding to the layer (column of geometries) to be converted, usually selected from one of the xxx_SDO_GEOM_METADATA views (described in Section 2.6).

- dim_name
Name of the measure dimension (

`M`

, if not otherwise specified).- dim_pos
Position of the measure dimension (the last SDO_DIM_ELEMENT object position in the SDO_DIM_ARRAY, if not otherwise specified).

- lower_bound
Lower bound (SDO_LB value in the SDO_DIM_ELEMENT definition) of the ordinate in the measure dimension.

- upper_bound
Upper bound (SDO_UB value in the SDO_DIM_ELEMENT definition) of the ordinate in the measure dimension.

- tolerance
Tolerance value (see Section 1.5.5 and Section 7.6). The default value is 0.00000001.

Usage Notes

This function converts a standard dimensional array to an LRS dimensional array by creating a measure dimension. Specifically, it adds an SDO_DIM_ELEMENT object at the end of the current SDO_DIM_ELEMENT objects in the SDO_DIM_ARRAY for the dimensional array (unless another

`dim_pos`

is specified), and sets the SDO_DIMNAME value in this added SDO_DIM_ELEMENT to M (unless another`dim_name`

is specified). It sets the other values in the added SDO_DIM_ELEMENT according to the values of the`upper_bound`

,`lower_bound`

, and`tolerance`

parameter values.If

`dim_array`

already contains dimensional information, the`dim_array`

is returned.The _3D format of this function (SDO_LRS.CONVERT_TO_LRS_DIM_ARRAY_3D) is available. For information about _3D formats of LRS functions, see Section 7.4.

For more information about conversion functions, see Section 7.5.10.

Examples

The following example converts the dimensional array for the LRS_ROUTES table to LRS format. (This example uses the definitions from the example in Section 7.7.)

SELECT SDO_LRS.CONVERT_TO_LRS_DIM_ARRAY(m.diminfo) FROM user_sdo_geom_metadata m WHERE m.table_name = 'LRS_ROUTES' AND m.column_name = 'ROUTE_GEOMETRY'; SDO_LRS.CONVERT_TO_LRS_DIM_ARRAY(M.DIMINFO)(SDO_DIMNAME, SDO_LB, SDO_UB, SDO_TOL -------------------------------------------------------------------------------- SDO_DIM_ARRAY(SDO_DIM_ELEMENT('X', 0, 20, .005), SDO_DIM_ELEMENT('Y', 0, 20, .00 5), SDO_DIM_ELEMENT('M', 0, 20, .005))

## SDO_LRS.CONVERT_TO_LRS_GEOM

Format

SDO_LRS.CONVERT_TO_LRS_GEOM(

standard_geom IN SDO_GEOMETRY

[, start_measure IN NUMBER,

end_measure IN NUMBER]

) RETURN SDO_GEOMETRY;

or

SDO_LRS.CONVERT_TO_LRS_GEOM(

standard_geom IN SDO_GEOMETRY,

dim_array IN SDO_DIM_ARRAY

[, start_measure IN NUMBER,

end_measure IN NUMBER]

) RETURN SDO_GEOMETRY;

or

SDO_LRS.CONVERT_TO_LRS_GEOM(

standard_geom IN SDO_GEOMETRY,

m_pos IN INTEGER

[, start_measure IN NUMBER,

end_measure IN NUMBER]

) RETURN SDO_GEOMETRY;

Description

Converts a standard SDO_GEOMETRY line string to an LRS geometric segment by adding measure information.

Parameters

- standard_geom
Line string geometry that does not contain measure information.

- dim_array
Dimensional information array corresponding to

`standard_geom`

, usually selected from one of the xxx_SDO_GEOM_METADATA views (described in Section 2.6).- m_pos
Position of the measure dimension. If specified, must be 3 or 4. By default, the measure dimension is the last dimension in the SDO_DIM_ARRAY.

- start_measure
Distance measured from the start point of a geometric segment to the start point of the linear feature. The default is 0.

- end_measure
Distance measured from the end point of a geometric segment to the start point of the linear feature. The default is the cartographic length (for example, 75 if the cartographic length is 75 and the unit of measure is miles).

Usage Notes

This function returns an LRS geometric segment with measure information, with measure information provided for all shape points.

An exception is raised if

`standard_geom`

has an invalid geometry type or dimensionality, if`m_pos`

is less than 3 or greater than 4, or if`start_measure`

or`end_measure`

is out of range.The _3D format of this function (SDO_LRS.CONVERT_TO_LRS_GEOM_3D) is available; however, the

`m_pos`

parameter is not available for SDO_LRS.CONVERT_TO_LRS_GEOM_3D. For information about _3D formats of LRS functions, see Section 7.4.For more information about conversion functions, see Section 7.5.10.

Examples

The following example converts the geometric segment representing Route 1 to LRS format. (This example uses the definitions from the example in Section 7.7.)

SELECT SDO_LRS.CONVERT_TO_LRS_GEOM(a.route_geometry, m.diminfo) FROM lrs_routes a, user_sdo_geom_metadata m WHERE m.table_name = 'LRS_ROUTES' AND m.column_name = 'ROUTE_GEOMETRY' AND a.route_id = 1; SDO_LRS.CONVERT_TO_LRS_GEOM(A.ROUTE_GEOMETRY,M.DIMINFO)(SDO_GTYPE, SDO_SRID, SDO -------------------------------------------------------------------------------- SDO_GEOMETRY(3002, NULL, NULL, SDO_ELEM_INFO_ARRAY(1, 2, 1), SDO_ORDINATE_ARRAY( 2, 2, 0, 2, 4, 2, 8, 4, 8, 12, 4, 12, 12, 10, NULL, 8, 10, 22, 5, 14, 27))

## SDO_LRS.CONVERT_TO_LRS_LAYER

Format

SDO_LRS.CONVERT_TO_LRS_LAYER(

table_name IN VARCHAR2,

column_name IN VARCHAR2

[, lower_bound IN NUMBER,

upper_bound IN NUMBER,

tolerance IN NUMBER]

) RETURN VARCHAR2;

or

SDO_LRS.CONVERT_TO_LRS_LAYER(

table_name IN VARCHAR2,

column_name IN VARCHAR2,

dim_name IN VARCHAR2,

dim_pos IN INTEGER

[, lower_bound IN NUMBER,

upper_bound IN NUMBER,

tolerance IN NUMBER]

) RETURN VARCHAR2;

Description

Converts all geometry objects in a column of type SDO_GEOMETRY (that is, converts a layer) from standard line string geometries without measure information to LRS geometric segments with measure information, and updates the metadata in the USER_SDO_GEOM_METADATA view.

Parameters

- table_name
Table containing the column with the SDO_GEOMETRY objects.

- column_name
Column in

`table_name`

containing the SDO_GEOMETRY objects.- dim_name
Name of the measure dimension. If this parameter is null,

`M`

is assumed.- dim_pos
Position of the measure dimension within the SDO_DIM_ARRAY structure for the specified SDO_GEOMETRY column. If this parameter is null, the number corresponding to the last position is assumed.

- lower_bound
Lower bound (SDO_LB value in the SDO_DIM_ELEMENT definition) of the ordinate in the measure dimension.

- upper_bound
Upper bound (SDO_UB value in the SDO_DIM_ELEMENT definition) of the ordinate in the measure dimension.

- tolerance
Tolerance value (see Section 1.5.5 and Section 7.6). The default value is 0.00000001.

Usage Notes

This function returns TRUE if the conversion was successful or if the layer already contains measure information, and the function returns an exception if the conversion was not successful.

An exception is raised if the existing dimensional information for the table is invalid.

The measure values are assigned based on a start measure of zero and an end measure of the cartographic length.

If a spatial index already exists on

`column_name`

, you must delete (drop) the index before converting the layer and create a new index after converting the layer. For information about deleting and creating indexes, see the DROP INDEX and CREATE INDEX statements in Chapter 10.The _3D format of this function (SDO_LRS.CONVERT_TO_LRS_LAYER_3D) is available. For information about _3D formats of LRS functions, see Section 7.4.

For more information about conversion functions, see Section 7.5.10.

Examples

The following example converts the geometric segments in the ROUTE_GEOMETRY column of the LRS_ROUTES table to LRS format. (This example uses the definitions from the example in Section 7.7.) The SELECT statement shows that dimensional information has been added (that is,

`SDO_DIM_ELEMENT('M', NULL, NULL, NULL)`

is included in the definition).BEGIN IF (SDO_LRS.CONVERT_TO_LRS_LAYER('LRS_ROUTES', 'ROUTE_GEOMETRY') = 'TRUE') THEN DBMS_OUTPUT.PUT_LINE('Conversion from STD_LAYER to LRS_LAYER succeeded.'); ELSE DBMS_OUTPUT.PUT_LINE('Conversion from STD_LAYER to LRS_LAYER failed.'); END IF; END; . / Conversion from STD_LAYER to LRS_LAYER succeeded. PL/SQL procedure successfully completed. SQL> SELECT diminfo FROM user_sdo_geom_metadata WHERE table_name = 'LRS_ROUTES' AND column_name = 'ROUTE_GEOMETRY'; DIMINFO(SDO_DIMNAME, SDO_LB, SDO_UB, SDO_TOLERANCE) -------------------------------------------------------------------------------- SDO_DIM_ARRAY(SDO_DIM_ELEMENT('X', 0, 20, .005), SDO_DIM_ELEMENT('Y', 0, 20, .00 5), SDO_DIM_ELEMENT('M', NULL, NULL, NULL))

## SDO_LRS.CONVERT_TO_STD_DIM_ARRAY

Format

SDO_LRS.CONVERT_TO_STD_DIM_ARRAY(

dim_array IN SDO_DIM_ARRAY

[, m_pos IN INTEGER]

) RETURN SDO_DIM_ARRAY;

Description

Converts an LRS dimensional array to a standard dimensional array by removing the measure dimension.

Parameters

- dim_array
Dimensional information array corresponding to the layer (column of geometries) to be converted, usually selected from one of the xxx_SDO_GEOM_METADATA views (described in Section 2.6).

- m_pos
Position of the measure dimension. If specified, must be 3 or 4. By default, the measure dimension is the last dimension in the SDO_DIM_ARRAY.

Usage Notes

This function converts an LRS dimensional array to a standard dimensional array by removing the measure dimension. Specifically, it removes the SDO_DIM_ELEMENT object at the end of the current SDO_DIM_ELEMENT objects in the SDO_DIM_ARRAY for the

`dim_array`

.An exception is raised if

`m_pos`

is invalid (less than 3 or greater than 4).If

`dim_array`

is already a standard dimensional array (that is, does not contain dimensional information), the`dim_array`

is returned.The _3D format of this function (SDO_LRS.CONVERT_TO_STD_DIM_ARRAY_3D) is available. For information about _3D formats of LRS functions, see Section 7.4.

For more information about conversion functions, see Section 7.5.10.

Examples

The following example converts the dimensional array for the LRS_ROUTES table to standard format. (This example uses the definitions from the example in Section 7.7.)

SELECT SDO_LRS.CONVERT_TO_STD_DIM_ARRAY(m.diminfo) FROM user_sdo_geom_metadata m WHERE m.table_name = 'LRS_ROUTES' AND m.column_name = 'ROUTE_GEOMETRY'; SDO_LRS.CONVERT_TO_STD_DIM_ARRAY(M.DIMINFO)(SDO_DIMNAME, SDO_LB, SDO_UB, SDO_TOL -------------------------------------------------------------------------------- SDO_DIM_ARRAY(SDO_DIM_ELEMENT('X', 0, 20, .005), SDO_DIM_ELEMENT('Y', 0, 20, .00 5))

## SDO_LRS.CONVERT_TO_STD_GEOM

Format

SDO_LRS.CONVERT_TO_STD_GEOM(

lrs _geom IN SDO_GEOMETRY

[, dim_array IN SDO_DIM_ARRAY]

) RETURN SDO_GEOMETRY;

Description

Converts an LRS geometric segment to a standard SDO_GEOMETRY line string by removing measure information.

Parameters

- lrs_geom
LRS geometry that contains measure information.

- dim_array
Dimensional information array corresponding to

`lrs_geom`

, usually selected from one of the xxx_SDO_GEOM_METADATA views (described in Section 2.6).Usage Notes

This function returns an SDO_GEOMETRY object in which all measure information is removed.

The _3D format of this function (SDO_LRS.CONVERT_TO_STD_GEOM_3D) is available. For information about _3D formats of LRS functions, see Section 7.4.

For more information about conversion functions, see Section 7.5.10.

Examples

The following example converts the geometric segment representing Route 1 to standard format. (This example uses the definitions from the example in Section 7.7.)

SELECT SDO_LRS.CONVERT_TO_STD_GEOM(a.route_geometry, m.diminfo) FROM lrs_routes a, user_sdo_geom_metadata m WHERE m.table_name = 'LRS_ROUTES' AND m.column_name = 'ROUTE_GEOMETRY' AND a.route_id = 1; SDO_LRS.CONVERT_TO_STD_GEOM(A.ROUTE_GEOMETRY,M.DIMINFO)(SDO_GTYPE, SDO_SRID, SDO -------------------------------------------------------------------------------- SDO_GEOMETRY(2002, NULL, NULL, SDO_ELEM_INFO_ARRAY(1, 2, 1), SDO_ORDINATE_ARRAY( 2, 2, 2, 4, 8, 4, 12, 4, 12, 10, 8, 10, 5, 14))

## SDO_LRS.CONVERT_TO_STD_LAYER

Format

SDO_LRS.CONVERT_TO_STD_LAYER(

table_name IN VARCHAR2,

column_name IN VARCHAR2

) RETURN VARCHAR2;

Description

Converts all geometry objects in a column of type SDO_GEOMETRY (that is, converts a layer) from LRS geometric segments with measure information to standard line string geometries without measure information, and updates the metadata in the USER_SDO_GEOM_METADATA view.

Parameters

- table_name
Table containing the column with the SDO_GEOMETRY objects.

- column_name
Column in

`table_name`

containing the SDO_GEOMETRY objects.Usage Notes

This function returns TRUE if the conversion was successful or if the layer already is a standard layer (that is, contains geometries without measure information), and the function returns an exception if the conversion was not successful.

If a spatial index already exists on

`column_name`

, you must delete (drop) the index before converting the layer and create a new index after converting the layer. For information about deleting and creating indexes, see the DROP INDEX and CREATE INDEX statements in Chapter 10.The _3D format of this function (SDO_LRS.CONVERT_TO_STD_LAYER_3D) is available. For information about _3D formats of LRS functions, see Section 7.4.

For more information about conversion functions, see Section 7.5.10.

Examples

The following example converts the geometric segments in the ROUTE_GEOMETRY column of the LRS_ROUTES table to standard format. (This example uses the definitions from the example in Section 7.7.) The SELECT statement shows that dimensional information has been removed (that is, no

`SDO_DIM_ELEMENT('M', NULL, NULL, NULL)`

is included in the definition).BEGIN IF (SDO_LRS.CONVERT_TO_STD_LAYER('LRS_ROUTES', 'ROUTE_GEOMETRY') = 'TRUE') THEN DBMS_OUTPUT.PUT_LINE('Conversion from LRS_LAYER to STD_LAYER succeeded.'); ELSE DBMS_OUTPUT.PUT_LINE('Conversion from LRS_LAYER to STD_LAYER failed.'); END IF; END; . / Conversion from LRS_LAYER to STD_LAYER succeeded. PL/SQL procedure successfully completed. SELECT diminfo FROM user_sdo_geom_metadata WHERE table_name = 'LRS_ROUTES' AND column_name = 'ROUTE_GEOMETRY'; DIMINFO(SDO_DIMNAME, SDO_LB, SDO_UB, SDO_TOLERANCE) -------------------------------------------------------------------------------- SDO_DIM_ARRAY(SDO_DIM_ELEMENT('X', 0, 20, .005), SDO_DIM_ELEMENT('Y', 0, 20, .00 5))

## SDO_LRS.DEFINE_GEOM_SEGMENT

Format

SDO_LRS.DEFINE_GEOM_SEGMENT(

geom_segment IN OUT SDO_GEOMETRY

[, start_measure IN NUMBER,

end_measure IN NUMBER]);

or

SDO_LRS.DEFINE_GEOM_SEGMENT(

geom_segment IN OUT SDO_GEOMETRY,

dim_array IN SDO_DIM_ARRAY

[, start_measure IN NUMBER,

end_measure IN NUMBER]);

Description

Defines a geometric segment by assigning start and end measures to a geometric segment, and assigns values to any null measures.

Parameters

- geom_segment
Cartographic representation of a linear feature.

- dim_array
Dimensional information array corresponding to

`geom_segment`

, usually selected from one of the xxx_SDO_GEOM_METADATA views (described in Section 2.6).- start_measure
Distance measured from the start point of a geometric segment to the start point of the linear feature. The default is the existing value (if any) in the measure dimension; otherwise, the default is 0.

- end_measure
Distance measured from the end point of a geometric segment to the start point of the linear feature. The default is the existing value (if any) in the measure dimension; otherwise, the default is the cartographic length of the segment.

Usage Notes

An exception is raised if

`geom_segment`

has an invalid geometry type or dimensionality, or if`start_measure`

or`end_measure`

is out of range.All unassigned measures of the geometric segment will be populated automatically.

To store the resulting geometric segment (

`geom_segment`

) in the database, you must execute an UPDATE or INSERT statement, as appropriate.The _3D format of this procedure (SDO_LRS.DEFINE_GEOM_SEGMENT_3D) is available. For information about _3D formats of LRS functions and procedures, see Section 7.4.

For more information about defining a geometric segment, see Section 7.5.1.

Examples

The following example defines the geometric segment, splits it into two segments, then concatenates those segments. (This example uses the definitions from the example in Section 7.7. The definitions of

`result_geom_1`

,`result_geom_2`

, and`result_geom_3`

are displayed in Example 7-3.)DECLARE geom_segment SDO_GEOMETRY; line_string SDO_GEOMETRY; dim_array SDO_DIM_ARRAY; result_geom_1 SDO_GEOMETRY; result_geom_2 SDO_GEOMETRY; result_geom_3 SDO_GEOMETRY; BEGIN SELECT a.route_geometry into geom_segment FROM lrs_routes a WHERE a.route_name = 'Route1'; SELECT m.diminfo into dim_array from user_sdo_geom_metadata m WHERE m.table_name = 'LRS_ROUTES' AND m.column_name = 'ROUTE_GEOMETRY'; -- Define the LRS segment for Route1. This will populate any null measures. SDO_LRS.DEFINE_GEOM_SEGMENT (geom_segment, dim_array, 0, -- Zero starting measure: LRS segment starts at start of route. 27); -- End of LRS segment is at measure 27. SELECT a.route_geometry INTO line_string FROM lrs_routes a WHERE a.route_name = 'Route1'; -- Split Route1 into two segments. SDO_LRS.SPLIT_GEOM_SEGMENT(line_string,dim_array,5,result_geom_1,result_geom_2); -- Concatenate the segments that were just split. result_geom_3 := SDO_LRS.CONCATENATE_GEOM_SEGMENTS(result_geom_1, dim_array, result_geom_2, dim_array); -- Update and insert geometries into table, to display later. UPDATE lrs_routes a SET a.route_geometry = geom_segment WHERE a.route_id = 1; INSERT INTO lrs_routes VALUES( 11, 'result_geom_1', result_geom_1 ); INSERT INTO lrs_routes VALUES( 12, 'result_geom_2', result_geom_2 ); INSERT INTO lrs_routes VALUES( 13, 'result_geom_3', result_geom_3 ); END; /

## SDO_LRS.DYNAMIC_SEGMENT

Format

SDO_LRS.DYNAMIC_SEGMENT(

geom_segment IN SDO_GEOMETRY,

start_measure IN NUMBER,

end_measure IN NUMBER,

tolerance IN NUMBER DEFAULT 1.0e-8

) RETURN SDO_GEOMETRY;

or

SDO_LRS.DYNAMIC_SEGMENT(

geom_segment IN SDO_GEOMETRY,

dim_array IN SDO_DIM_ARRAY,

start_measure IN NUMBER,

end_measure IN NUMBER

) RETURN SDO_GEOMETRY;

Description

Returns the geometry object resulting from a clip operation on a geometric segment.

Note:

SDO_LRS.CLIP_GEOM_SEGMENT and SDO_LRS.DYNAMIC_SEGMENT are synonyms: both functions have the same parameters, behavior, and return value.Parameters

- geom_segment
Cartographic representation of a linear feature.

- dim_array
Dimensional information array corresponding to

`geom_segment`

, usually selected from one of the xxx_SDO_GEOM_METADATA views (described in Section 2.6).- start_measure
Start measure of the geometric segment.

- end_measure
End measure of the geometric segment.

- tolerance
Tolerance value (see Section 1.5.5 and Section 7.6). The default value is 0.00000001.

Usage Notes

An exception is raised if

`geom_segment`

,`start_measure`

, or`end_measure`

is invalid.The direction and measures of the resulting geometric segment are preserved.

For more information about clipping a geometric segment, see Section 7.5.3.

Examples

The following example clips the geometric segment representing Route 1, returning the segment from measures 5 through 10. This segment might represent a construction zone. (This example uses the definitions from the example in Section 7.7.)

SELECT SDO_LRS.DYNAMIC_SEGMENT(route_geometry, 5, 10) FROM lrs_routes WHERE route_id = 1; SDO_LRS.DYNAMIC_SEGMENT(ROUTE_GEOMETRY,5,10)(SDO_GTYPE, SDO_SRID, SDO_POINT(X, Y -------------------------------------------------------------------------------- SDO_GEOMETRY(3302, NULL, NULL, SDO_ELEM_INFO_ARRAY(1, 2, 1), SDO_ORDINATE_ARRAY( 5, 4, 5, 8, 4, 8, 10, 4, 10))

## SDO_LRS.FIND_LRS_DIM_POS

Format

SDO_LRS.FIND_LRS_DIM_POS(

table_name IN VARCHAR2,

column_name IN VARCHAR2

) RETURN INTEGER;

Description

Returns the position of the measure dimension within the SDO_DIM_ARRAY structure for a specified SDO_GEOMETRY column.

Parameters

- table_name
Table containing the column with the SDO_GEOMETRY objects.

- column_name
Column in

`table_name`

containing the SDO_GEOMETRY objects.Usage Notes

None.

Examples

The following example returns the position of the measure dimension within the SDO_DIM_ARRAY structure for geometries in the ROUTE_GEOMETRY column of the LRS_ROUTES table. (This example uses the definitions from the example in Section 7.7.)

SELECT SDO_LRS.FIND_LRS_DIM_POS('LRS_ROUTES', 'ROUTE_GEOMETRY') FROM DUAL; SDO_LRS.FIND_LRS_DIM_POS('LRS_ROUTES','ROUTE_GEOMETRY') ------------------------------------------------------- 3

## SDO_LRS.FIND_MEASURE

Format

SDO_LRS.FIND_MEASURE(

geom_segment IN SDO_GEOMETRY,

point IN SDO_GEOMETRY

) RETURN NUMBER;

or

SDO_LRS.FIND_MEASURE(

geom_segment IN SDO_GEOMETRY,

dim_array IN SDO_DIM_ARRAY,

point IN SDO_GEOMETRY

) RETURN NUMBER;

Description

Returns the measure of the closest point on a segment to a specified projection point.

Parameters

- geom_segment
Cartographic representation of a linear feature. This function returns the measure of the point on this segment that is closest to the projection point.

- dim_array
`geom_segment`

, usually selected from one of the xxx_SDO_GEOM_METADATA views (described in Section 2.6).- point
Projection point. This function returns the measure of the point on

`geom_segment`

that is closest to the projection point.Usage Notes

This function returns the measure of the point on

`geom_segment`

that is closest to the projection point. For example, if the projection point represents a shopping mall, the function could be used to find how far from the start of the highway is the point on the highway that is closest to the shopping mall.An exception is raised if

`geom_segment`

has an invalid geometry type or dimensionality, or if`geom_segment`

and`point`

are based on different coordinate systems.The _3D format of this function (SDO_LRS.FIND_MEASURE_3D) is available. For information about _3D formats of LRS functions, see Section 7.4.

Examples

The following example finds the measure for the point on the geometric segment representing Route 1 that is closest to the point (10, 7). (This example uses the definitions from the example in Section 7.7.)

-- Find measure for point on segment closest to 10,7. -- Should return 15 (for point 12,7). SELECT SDO_LRS.FIND_MEASURE(a.route_geometry, m.diminfo, SDO_GEOMETRY(3001, NULL, NULL, SDO_ELEM_INFO_ARRAY(1, 1, 1), SDO_ORDINATE_ARRAY(10, 7, NULL)) ) FROM lrs_routes a, user_sdo_geom_metadata m WHERE m.table_name = 'LRS_ROUTES' AND m.column_name = 'ROUTE_GEOMETRY' AND a.route_id = 1; SDO_LRS.FIND_MEASURE(A.ROUTE_GEOMETRY,M.DIMINFO,SDO_GEOMETRY(3001,NULL,NUL -------------------------------------------------------------------------------- 15

## SDO_LRS.FIND_OFFSET

Format

SDO_LRS.FIND_OFFSET(

geom_segment IN SDO_GEOMETRY,

point IN SDO_GEOMETRY,

tolerance IN NUMBER DEFAULT 1.0e-8

) RETURN NUMBER;

or

SDO_LRS.FIND_OFFSET(

geom_segment IN SDO_GEOMETRY,

dim_array IN SDO_DIM_ARRAY,

point IN SDO_GEOMETRY

[, point_dim_array IN SDO_GEOMETRY]

) RETURN NUMBER;

Description

Returns the signed offset (shortest distance) from a point to a geometric segment.

Parameters

- geom_segment
Geometric segment to be checked for distance from

`point`

.- point
Point whose shortest distance from

`geom_segment`

is to be returned.- tolerance
Tolerance value (see Section 1.5.5 and Section 7.6). The default value is 0.00000001.

- dim_array
`geom_segment`

, usually selected from one of the xxx_SDO_GEOM_METADATA views (described in Section 2.6).- point_dim_array
Dimensional information array corresponding to

`point`

, usually selected from one of the xxx_SDO_GEOM_METADATA views (described in Section 2.6).Usage Notes

This function calls the SDO_LRS.PROJECT_PT function format that includes the

`offset`

output parameter: it passes in the geometric segment and point information, and it returns the SDO_LRS.PROJECT_PT`offset`

parameter value. Thus, to find the offset of a point from a geometric segment, you can use either this function or the SDO_LRS.PROJECT_PT function with the`offset`

parameter.An exception is raised if

`geom_segment`

or`point`

has an invalid geometry type or dimensionality, or if`geom_segment`

and`point`

are based on different coordinate systems.For more information about offsets to a geometric segment, see Section 7.1.5.

Examples

The following example returns the offset of point (9,3,NULL) from the geometric segment representing Route 1. (This example uses the definitions from the example in Section 7.7.) As you can see from Figure 7-20 in Section 7.7, the point at (9,3,NULL) is on the right side along the segment, and therefore the offset has a negative value, as explained in Section 7.1.5. The point at (9,3.NULL) is one distance unit away from the point at (9,4,NULL), which is on the segment.

-- Find the offset of point (9,3,NULL) from the road; should return -1. SELECT SDO_LRS.FIND_OFFSET(route_geometry, SDO_GEOMETRY(3301, NULL, NULL, SDO_ELEM_INFO_ARRAY(1, 1, 1), SDO_ORDINATE_ARRAY(9, 3, NULL)) ) FROM lrs_routes WHERE route_id = 1; SDO_LRS.FIND_OFFSET(ROUTE_GEOMETRY,SDO_GEOMETRY(3301,NULL,NULL,SDO_ELEM_INFO_ARR -------------------------------------------------------------------------------- -1

## SDO_LRS.GEOM_SEGMENT_END_MEASURE

Format

SDO_LRS.GEOM_SEGMENT_END_MEASURE(

geom_segment IN SDO_GEOMETRY

[, dim_array IN SDO_DIM_ARRAY]

) RETURN NUMBER;

Description

Returns the end measure of a geometric segment.

Parameters

- geom_segment
Geometric segment whose end measure is to be returned.

- dim_array
`geom_segment`

, usually selected from one of the xxx_SDO_GEOM_METADATA views (described in Section 2.6).Usage Notes

This function returns the end measure of

`geom_segment`

.An exception is raised if

`geom_segment`

has an invalid geometry type or dimensionality.The _3D format of this function (SDO_LRS.GEOM_SEGMENT_END_MEASURE_3D) is available. For information about _3D formats of LRS functions, see Section 7.4.

Examples

The following example returns the end measure of the geometric segment representing Route 1. (This example uses the definitions from the example in Section 7.7.)

SELECT SDO_LRS.GEOM_SEGMENT_END_MEASURE(route_geometry) FROM lrs_routes WHERE route_id = 1; SDO_LRS.GEOM_SEGMENT_END_MEASURE(ROUTE_GEOMETRY) ------------------------------------------------ 27

## SDO_LRS.GEOM_SEGMENT_END_PT

Format

SDO_LRS.GEOM_SEGMENT_END_PT(

geom_segment IN SDO_GEOMETRY

[, dim_array IN SDO_DIM_ARRAY]

) RETURN SDO_GEOMETRY;

Description

Returns the end point of a geometric segment.

Parameters

- geom_segment
Geometric segment whose end point is to be returned.

- dim_array
`geom_segment`

, usually selected from one of the xxx_SDO_GEOM_METADATA views (described in Section 2.6).Usage Notes

This function returns the end point of

`geom_segment`

.An exception is raised if

`geom_segment`

has an invalid geometry type or dimensionality.The _3D format of this function (SDO_LRS.GEOM_SEGMENT_END_PT_3D) is available. For information about _3D formats of LRS functions, see Section 7.4.

Examples

The following example returns the end point of the geometric segment representing Route 1. (This example uses the definitions from the example in Section 7.7.)

SELECT SDO_LRS.GEOM_SEGMENT_END_PT(route_geometry) FROM lrs_routes WHERE route_id = 1; SDO_LRS.GEOM_SEGMENT_END_PT(ROUTE_GEOMETRY)(SDO_GTYPE, SDO_SRID, SDO_POINT(X, Y, -------------------------------------------------------------------------------- SDO_GEOMETRY(3301, NULL, NULL, SDO_ELEM_INFO_ARRAY(1, 1, 1), SDO_ORDINATE_ARRAY( 5, 14, 27))

## SDO_LRS.GEOM_SEGMENT_LENGTH

Format

SDO_LRS.GEOM_SEGMENT_LENGTH(

geom_segment IN SDO_GEOMETRY

[, dim_array IN SDO_DIM_ARRAY]

) RETURN NUMBER;

Description

Returns the length of a geometric segment.

Parameters

- geom_segment
Geometric segment whose length is to be calculated.

- dim_array
`geom_segment`

, usually selected from one of the xxx_SDO_GEOM_METADATA views (described in Section 2.6).Usage Notes

This function returns the length of

`geom_segment`

. The length is the geometric length, which is not the same as the total of the measure unit values. To determine how long a segment is in terms of measure units, subtract the result of an SDO_LRS.GEOM_SEGMENT_START_MEASURE operation from the result of an SDO_LRS.GEOM_SEGMENT_END_MEASURE operation.An exception is raised if

`geom_segment`

has an invalid geometry type or dimensionality.The _3D format of this function (SDO_LRS.GEOM_SEGMENT_LENGTH_3D) is available. For information about _3D formats of LRS functions, see Section 7.4.

Examples

The following example returns the length of the geometric segment representing Route 1. (This example uses the definitions from the example in Section 7.7.)

SELECT SDO_LRS.GEOM_SEGMENT_LENGTH(route_geometry) FROM lrs_routes WHERE route_id = 1; SDO_LRS.GEOM_SEGMENT_LENGTH(ROUTE_GEOMETRY) ------------------------------------------- 27

## SDO_LRS.GEOM_SEGMENT_START_MEASURE

Format

SDO_LRS.GEOM_SEGMENT_START_MEASURE(

geom_segment IN SDO_GEOMETRY

[, dim_array IN SDO_DIM_ARRAY]

) RETURN NUMBER;

Description

Returns the start measure of a geometric segment.

Parameters

- geom_segment
Geometric segment whose start measure is to be returned.

- dim_array
`geom_segment`

, usually selected from one of the xxx_SDO_GEOM_METADATA views (described in Section 2.6).Usage Notes

This function returns the start measure of

`geom_segment`

.An exception is raised if

`geom_segment`

has an invalid geometry type or dimensionality.The _3D format of this function (SDO_LRS.GEOM_SEGMENT_START_MEASURE_3D) is available. For information about _3D formats of LRS functions, see Section 7.4.

Examples

The following example returns the start measure of the geometric segment representing Route 1. (This example uses the definitions from the example in Section 7.7.)

SELECT SDO_LRS.GEOM_SEGMENT_START_MEASURE(route_geometry) FROM lrs_routes WHERE route_id = 1; SDO_LRS.GEOM_SEGMENT_START_MEASURE(ROUTE_GEOMETRY) -------------------------------------------------- 0

## SDO_LRS.GEOM_SEGMENT_START_PT

Format

SDO_LRS.GEOM_SEGMENT_START_PT(

geom_segment IN SDO_GEOMETRY

[, dim_array IN SDO_DIM_ARRAY]

) RETURN SDO_GEOMETRY;

Description

Returns the start point of a geometric segment.

Parameters

- geom_segment
Geometric segment whose start point is to be returned.

- dim_array
`geom_segment`

, usually selected from one of the xxx_SDO_GEOM_METADATA views (described in Section 2.6).Usage Notes

This function returns the start point of

`geom_segment`

.An exception is raised if

`geom_segment`

has an invalid geometry type or dimensionality.The _3D format of this function (SDO_LRS.GEOM_SEGMENT_START_PT_3D) is available. For information about _3D formats of LRS functions, see Section 7.4.

Examples

The following example returns the start point of the geometric segment representing Route 1. (This example uses the definitions from the example in Section 7.7.)

SELECT SDO_LRS.GEOM_SEGMENT_START_PT(route_geometry) FROM lrs_routes WHERE route_id = 1; SDO_LRS.GEOM_SEGMENT_START_PT(ROUTE_GEOMETRY)(SDO_GTYPE, SDO_SRID, SDO_POINT(X, -------------------------------------------------------------------------------- SDO_GEOMETRY(3301, NULL, NULL, SDO_ELEM_INFO_ARRAY(1, 1, 1), SDO_ORDINATE_ARRAY( 2, 2, 0))

## SDO_LRS.GET_MEASURE

Format

SDO_LRS.GET_MEASURE(

point IN SDO_GEOMETRY

[, dim_array IN SDO_DIM_ARRAY]

) RETURN NUMBER;

Description

Returns the measure of an LRS point.

Parameters

- point
Point whose measure is to be returned.

- dim_array
Dimensional information array corresponding to

`point`

, usually selected from one of the xxx_SDO_GEOM_METADATA views (described in Section 2.6).Usage Notes

This function returns the measure of an LRS point.

If

`point`

is not valid, an "invalid LRS point" exception is raised.Contrast this function with SDO_LRS.PROJECT_PT, which accepts as input a point that is not necessarily on the geometric segment, but which returns a point that is on the geometric segment, as opposed to a measure value. As the following example shows, the SDO_LRS.GET_MEASURE function can be used to return the measure of the projected point returned by SDO_LRS.PROJECT_PT.

The _3D format of this function (SDO_LRS.GET_MEASURE_3D) is available. For information about _3D formats of LRS functions, see Section 7.4.

Examples

The following example returns the measure of a projected point. In this case, the point resulting from the projection is 9 units from the start of the segment.

SELECT SDO_LRS.GET_MEASURE( SDO_LRS.PROJECT_PT(a.route_geometry, m.diminfo, SDO_GEOMETRY(3001, NULL, NULL, SDO_ELEM_INFO_ARRAY(1, 1, 1), SDO_ORDINATE_ARRAY(9, 3, NULL)) ), m.diminfo ) FROM lrs_routes a, user_sdo_geom_metadata m WHERE m.table_name = 'LRS_ROUTES' AND m.column_name = 'ROUTE_GEOMETRY' AND a.route_id = 1; SDO_LRS.GET_MEASURE(SDO_LRS.PROJECT_PT(A.ROUTE_GEOMETRY,M.DIMINFO,SDO_GEOM -------------------------------------------------------------------------------- 9

## SDO_LRS.GET_NEXT_SHAPE_PT

Format

SDO_LRS.GET_NEXT_SHAPE_PT(

geom_segment IN SDO_GEOMETRY,

measure IN NUMBER

) RETURN SDO_GEOMETRY;

or

SDO_LRS.GET_NEXT_SHAPE_PT(

geom_segment IN SDO_GEOMETRY,

dim_array IN SDO_DIM_ARRAY,

measure IN NUMBER

) RETURN SDO_GEOMETRY;

or

SDO_LRS.GET_NEXT_SHAPE_PT(

geom_segment IN SDO_GEOMETRY,

point IN SDO_GEOMETRY

) RETURN SDO_GEOMETRY;

or

SDO_LRS.GET_NEXT_SHAPE_PT(

geom_segment IN SDO_GEOMETRY,

dim_array IN SDO_DIM_ARRAY,

point IN SDO_GEOMETRY

) RETURN SDO_GEOMETRY;

Description

Returns the next shape point on a geometric segment after a specified measure value or LRS point.

Parameters

- geom_segment
Geometric segment.

- measure
Measure value on the geometric segment for which to return the next shape point.

- point
Point for which to return the next shape point. If

`point`

is not on`geom_segment`

, the point on the geometric segment closest to the specified point is computed, and the next shape point after that point is returned.- dim_array
`geom_segment`

, usually selected from one of the xxx_SDO_GEOM_METADATA views (described in Section 2.6).Usage Notes

If

`measure`

or`point`

identifies the end point of the geometric segment, a null value is returned.An exception is raised if

`measure`

is not a valid value for`geom_segment`

or if`point`

is not a valid LRS point.Contrast this function with SDO_LRS.GET_PREV_SHAPE_PT, which returns the previous shape point on a geometric segment before a specified measure value or LRS point.

The _3D format of this function (SDO_LRS.GET_NEXT_SHAPE_PT_3D) is available. For information about _3D formats of LRS functions, see Section 7.4.

Examples

The following example returns the next shape point after measure 14 on the geometric segment representing Route 1. (This example uses the definitions from the example in Section 7.7.)

SELECT SDO_LRS.GET_NEXT_SHAPE_PT(a.route_geometry, 14) FROM lrs_routes a WHERE a.route_id = 1; SDO_LRS.GET_NEXT_SHAPE_PT(A.ROUTE_GEOMETRY,14)(SDO_GTYPE, SDO_SRID, SDO_POINT(X, -------------------------------------------------------------------------------- SDO_GEOMETRY(3301, NULL, NULL, SDO_ELEM_INFO_ARRAY(1, 1, 1), SDO_ORDINATE_ARRAY( 12, 10, 18))

## SDO_LRS.GET_NEXT_SHAPE_PT_MEASURE

Format

SDO_LRS.GET_NEXT_SHAPE_PT_MEASURE(

geom_segment IN SDO_GEOMETRY,

measure IN NUMBER

) RETURN NUMBER;

or

SDO_LRS.GET_NEXT_SHAPE_PT_MEASURE(

geom_segment IN SDO_GEOMETRY,

dim_array IN SDO_DIM_ARRAY,

measure IN NUMBER

) RETURN NUMBER;

or

SDO_LRS.GET_NEXT_SHAPE_PT_MEASURE(

geom_segment IN SDO_GEOMETRY,

point IN SDO_GEOMETRY

) RETURN NUMBER;

or

SDO_LRS.GET_NEXT_SHAPE_PT_MEASURE(

geom_segment IN SDO_GEOMETRY,

dim_array IN SDO_DIM_ARRAY,

point IN SDO_GEOMETRY

) RETURN NUMBER;

Description

Returns the measure value of the next shape point on a geometric segment after a specified measure value or LRS point.

Parameters

- geom_segment
Geometric segment.

- measure
Measure value on the geometric segment for which to return the measure value of the next shape point.

- point
Point for which to return the measure value of the next shape point. If

`point`

is not on`geom_segment`

, the point on the geometric segment closest to the specified point is computed, and the measure value of the next shape point after that point is returned.- dim_array
`geom_segment`

, usually selected from one of the xxx_SDO_GEOM_METADATA views (described in Section 2.6).Usage Notes

If

`measure`

or`point`

identifies the end point of the geometric segment, a null value is returned.An exception is raised if

`measure`

is not a valid value for`geom_segment`

or if`point`

is not a valid LRS point.Contrast this function with SDO_LRS.GET_PREV_SHAPE_PT_MEASURE, which returns the measure value of the previous shape point on a geometric segment before a specified measure value or LRS point.

The _3D format of this function (SDO_LRS.GET_NEXT_SHAPE_PT_MEASURE_3D) is available. For information about _3D formats of LRS functions, see Section 7.4.

Examples

The following example returns the measure value of the next shape point after measure 14 on the geometric segment representing Route 1. (This example uses the definitions from the example in Section 7.7.)

SELECT SDO_LRS.GET_NEXT_SHAPE_PT_MEASURE(a.route_geometry, 14) FROM lrs_routes a WHERE a.route_id = 1; SDO_LRS.GET_NEXT_SHAPE_PT_MEASURE(A.ROUTE_GEOMETRY,14) ------------------------------------------------------ 18

## SDO_LRS.GET_PREV_SHAPE_PT

Format

SDO_LRS.GET_PREV_SHAPE_PT(

geom_segment IN SDO_GEOMETRY,

measure IN NUMBER

) RETURN SDO_GEOMETRY;

or

SDO_LRS.GET_PREV_SHAPE_PT(

geom_segment IN SDO_GEOMETRY,

dim_array IN SDO_DIM_ARRAY,

measure IN NUMBER

) RETURN SDO_GEOMETRY;

or

SDO_LRS.GET_PREV_SHAPE_PT(

geom_segment IN SDO_GEOMETRY,

point IN SDO_GEOMETRY

) RETURN SDO_GEOMETRY;

or

SDO_LRS.GET_PREV_SHAPE_PT(

geom_segment IN SDO_GEOMETRY,

dim_array IN SDO_DIM_ARRAY,

point IN SDO_GEOMETRY

) RETURN SDO_GEOMETRY;

Description

Returns the previous shape point on a geometric segment before a specified measure value or LRS point.

Parameters

- geom_segment
Geometric segment.

- measure
Measure value on the geometric segment for which to return the previous shape point.

- point
Point for which to return the previous shape point. If

`point`

is not on`geom_segment`

, the point on the geometric segment closest to the specified point is computed, and the closest shape point before that point is returned.- dim_array
Dimensional information array corresponding to

`geom_segment`

, usually selected from one of the xxx_SDO_GEOM_METADATA views (described in Section 2.6).Usage Notes

If

`measure`

or`point`

identifies the start point of the geometric segment, a null value is returned.An exception is raised if

`measure`

is not a valid value for`geom_segment`

or if`point`

is not a valid LRS point.Contrast this function with SDO_LRS.GET_NEXT_SHAPE_PT, which returns the next shape point on a geometric segment after a specified measure value or LRS point.

The _3D format of this function (SDO_LRS.GET_PREV_SHAPE_PT_3D) is available. For information about _3D formats of LRS functions, see Section 7.4.

Examples

The following example returns the closest shape point to measure 14 and before measure 14 on the geometric segment representing Route 1. (This example uses the definitions from the example in Section 7.7.)

SELECT SDO_LRS.GET_PREV_SHAPE_PT(a.route_geometry, 14) FROM lrs_routes a WHERE a.route_id = 1; SDO_LRS.GET_PREV_SHAPE_PT(A.ROUTE_GEOMETRY,14)(SDO_GTYPE, SDO_SRID, SDO_POINT(X, -------------------------------------------------------------------------------- SDO_GEOMETRY(3301, NULL, NULL, SDO_ELEM_INFO_ARRAY(1, 1, 1), SDO_ORDINATE_ARRAY( 12, 4, 12))

## SDO_LRS.GET_PREV_SHAPE_PT_MEASURE

Format

SDO_LRS.GET_PREV_SHAPE_PT_MEASURE(

geom_segment IN SDO_GEOMETRY,

measure IN NUMBER

) RETURN NUMBER;

or

SDO_LRS.GET_PREV_SHAPE_PT_MEASURE(

geom_segment IN SDO_GEOMETRY,

dim_array IN SDO_DIM_ARRAY,

measure IN NUMBER

) RETURN NUMBER;

or

SDO_LRS.GET_PREV_SHAPE_PT_MEASURE(

geom_segment IN SDO_GEOMETRY,

point IN SDO_GEOMETRY

) RETURN NUMBER;

or

SDO_LRS.GET_PREV_SHAPE_PT_MEASURE(

geom_segment IN SDO_GEOMETRY,

dim_array IN SDO_DIM_ARRAY,

point IN SDO_GEOMETRY

) RETURN NUMBER;

Description

Returns the measure value of the previous shape point on a geometric segment before a specified measure value or LRS point.

Parameters

- geom_segment
Geometric segment.

- measure
Measure value on the geometric segment for which to return the measure value of the previous shape point.

- point
Point for which to return the measure value of the previous shape point. If

`point`

is not on`geom_segment`

, the point on the geometric segment closest to the specified point is computed, and the measure value of the closest shape point before that point is returned.- dim_array
`geom_segment`

, usually selected from one of the xxx_SDO_GEOM_METADATA views (described in Section 2.6).Usage Notes

If

`measure`

or`point`

identifies the start point of the geometric segment, a null value is returned.`measure`

is not a valid value for`geom_segment`

or if`point`

is not a valid LRS point.Contrast this function with SDO_LRS.GET_NEXT_SHAPE_PT_MEASURE, which returns the measure value of the next shape point on a geometric segment after a specified measure value or LRS point.

The _3D format of this function (SDO_LRS.GET_PREV_SHAPE_PT_MEASURE_3D) is available. For information about _3D formats of LRS functions, see Section 7.4.

Examples

The following example returns the measure value of the closest shape point to measure 14 and before measure 14 on the geometric segment representing Route 1. (This example uses the definitions from the example in Section 7.7.)

SELECT SDO_LRS.GET_PREV_SHAPE_PT_MEASURE(a.route_geometry, 14) FROM lrs_routes a WHERE a.route_id = 1; SDO_LRS.GET_PREV_SHAPE_PT_MEASURE(A.ROUTE_GEOMETRY,14) ------------------------------------------------------ 12

## SDO_LRS.IS_GEOM_SEGMENT_DEFINED

Format

SDO_LRS.IS_GEOM_SEGMENT_DEFINED(

geom_segment IN SDO_GEOMETRY

[, dim_array IN SDO_DIM_ARRAY]

) RETURN VARCHAR2;

Description

Checks if an LRS segment is defined correctly.

Parameters

- geom_segment
Geometric segment to be checked.

- dim_array
`geom_segment`

, usually selected from one of the xxx_SDO_GEOM_METADATA views (described in Section 2.6).Usage Notes

This function returns TRUE if

`geom_segment`

is defined correctly and FALSE if`geom_segment`

is not defined correctly.The start and end measures of

`geom_segment`

must be defined (cannot be null), and any measures assigned must be in an ascending or descending order along the segment direction.The _3D format of this function (SDO_LRS.IS_GEOM_SEGMENT_DEFINED_3D) is available. For information about _3D formats of LRS functions, see Section 7.4.

See also the SDO_LRS.VALID_GEOM_SEGMENT function.

Examples

The following example checks if the geometric segment representing Route 1 is defined. (This example uses the definitions from the example in Section 7.7.)

SELECT SDO_LRS.IS_GEOM_SEGMENT_DEFINED(route_geometry) FROM lrs_routes WHERE route_id = 1; SDO_LRS.IS_GEOM_SEGMENT_DEFINED(ROUTE_GEOMETRY) -------------------------------------------------------------------------------- TRUE

## SDO_LRS.IS_MEASURE_DECREASING

Format

SDO_LRS.IS_MEASURE_DECREASING(

geom_segment IN SDO_GEOMETRY

[, dim_array IN SDO_DIM_ARRAY]

) RETURN VARCHAR2;

Description

Checks if the measure values along an LRS segment are decreasing (that is, descending in numerical value).

Parameters

- geom_segment
Geometric segment to be checked.

- dim_array
`geom_segment`

, usually selected from one of the xxx_SDO_GEOM_METADATA views (described in Section 2.6).Usage Notes

This function returns TRUE if the measure values along an LRS segment are decreasing and FALSE if the measure values along an LRS segment are not decreasing.

The start and end measures of

`geom_segment`

must be defined (cannot be null).The _3D format of this function (SDO_LRS.IS_MEASURE_DECREASING_3D) is available. For information about _3D formats of LRS functions, see Section 7.4.

See also the SDO_LRS.IS_MEASURE_INCREASING function.

Examples

The following example checks if the measure values along the geometric segment representing Route 1 are decreasing. (This example uses the definitions from the example in Section 7.7.)

SELECT SDO_LRS.IS_MEASURE_DECREASING(a.route_geometry, m.diminfo) FROM lrs_routes a, user_sdo_geom_metadata m WHERE m.table_name = 'LRS_ROUTES' AND m.column_name = 'ROUTE_GEOMETRY' AND a.route_id = 1; SDO_LRS.IS_MEASURE_DECREASING(A.ROUTE_GEOMETRY,M.DIMINFO) -------------------------------------------------------------------------------- FALSE

## SDO_LRS.IS_MEASURE_INCREASING

Format

SDO_LRS.IS_MEASURE_INCREASING(

geom_segment IN SDO_GEOMETRY

[, dim_array IN SDO_DIM_ARRAY]

) RETURN VARCHAR2;

Description

Checks if the measure values along an LRS segment are increasing (that is, ascending in numerical value).

Parameters

- geom_segment
Geometric segment to be checked.

- dim_array
`geom_segment`

, usually selected from one of the xxx_SDO_GEOM_METADATA views (described in Section 2.6).Usage Notes

This function returns TRUE if the measure values along an LRS segment are increasing and FALSE if the measure values along an LRS segment are not increasing.

The start and end measures of

`geom_segment`

must be defined (cannot be null).The _3D format of this function (SDO_LRS.IS_MEASURE_INCREASING_3D) is available. For information about _3D formats of LRS functions, see Section 7.4.

See also the SDO_LRS.IS_MEASURE_DECREASING function.

Examples

The following example checks if the measure values along the geometric segment representing Route 1 are increasing. (This example uses the definitions from the example in Section 7.7.)

SELECT SDO_LRS.IS_MEASURE_INCREASING(a.route_geometry, m.diminfo) FROM lrs_routes a, user_sdo_geom_metadata m WHERE m.table_name = 'LRS_ROUTES' AND m.column_name = 'ROUTE_GEOMETRY' AND a.route_id = 1; SDO_LRS.IS_MEASURE_INCREASING(A.ROUTE_GEOMETRY,M.DIMINFO) -------------------------------------------------------------------------------- TRUE

## SDO_LRS.IS_SHAPE_PT_MEASURE

Format

SDO_LRS.IS_SHAPE_PT_MEASURE(

geom_segment IN SDO_GEOMETRY,

measure IN NUMBER

) RETURN VARCHAR2;

or

SDO_LRS.IS_SHAPE_PT_MEASURE(

geom_segment IN SDO_GEOMETRY,

dim_array IN SDO_DIM_ARRAY,

measure IN NUMBER

) RETURN VARCHAR2;

Description

Checks if a specified measure value is associated with a shape point on a geometric segment.

Parameters

- geom_segment
Geometric segment to be checked.

- measure
Measure value on the geometric segment to check if it is a shape point.

- dim_array
`geom_segment`

, usually selected from one of the xxx_SDO_GEOM_METADATA views (described in Section 2.6).Usage Notes

This function returns TRUE if the specified measure value is associated with a shape point and FALSE if the measure value is not associated with a shape point.

An exception is raised if

`measure`

is not a valid value for`geom_segment`

.The _3D format of this function (SDO_LRS.IS_SHAPE_PT_MEASURE_3D) is available. For information about _3D formats of LRS functions, see Section 7.4.

Examples

The following example checks if measure 14 on the geometric segment representing Route 1 is a shape point. (This example uses the definitions from the example in Section 7.7.)

SELECT SDO_LRS.IS_SHAPE_PT_MEASURE(a.route_geometry, 14) FROM lrs_routes a WHERE a.route_id = 1; SDO_LRS.IS_SHAPE_PT_MEASURE(A.ROUTE_GEOMETRY,14) -------------------------------------------------------------------------------- FALSE

## SDO_LRS.LOCATE_PT

Format

SDO_LRS.LOCATE_PT(

geom_segment IN SDO_GEOMETRY,

measure IN NUMBER

[, offset IN NUMBER

) RETURN SDO_GEOMETRY;

or

SDO_LRS.LOCATE_PT(

geom_segment IN SDO_GEOMETRY,

dim_array IN SDO_DIM_ARRAY,

measure IN NUMBER

[, offset IN NUMBER]

) RETURN SDO_GEOMETRY;

Description

Returns the point located at a specified distance from the start of a geometric segment.

Parameters

- geom_segment
Geometric segment to be checked to see if it falls within the measure range of

`measure`

.- dim_array
`geom_segment`

, usually selected from one of the xxx_SDO_GEOM_METADATA views (described in Section 2.6).- measure
Distance to measure from the start point of

`geom_segment`

.- offset
Distance to measure perpendicularly from the point that is located at

`measure`

units from the start point of`geom_segment`

. The default is 0 (that is, the point is on`geom_segment`

).Usage Notes

This function returns the referenced point. For example, on a highway, the point might represent the location of an accident.

The unit of measurement for

`offset`

is the same as for the coordinate system associated with`geom_segment`

. For geodetic data, the default unit of measurement is meters.With geodetic data using the WGS 84 coordinate system, this function can be used to return the longitude and latitude coordinates of any point on or offset from the segment.

An exception is raised if

`geom_segment`

has an invalid geometry type or dimensionality, or if the location is out of range.The _3D format of this function (SDO_LRS.LOCATE_PT_3D) is available; however, the

`offset`

parameter is not available for SDO_LRS.LOCATE_PT_3D. For information about _3D formats of LRS functions, see Section 7.4.For more information about locating a point on a geometric segment, see Section 7.5.8.

Examples

The following example creates a table for automobile accident data, inserts a record for an accident at the point at measure 9 and on (that is, offset 0) the geometric segment representing Route 1, and displays the data. (The accident table is deliberately oversimplified. This example also uses the route definition from the example in Section 7.7.)

-- Create a table for accidents. CREATE TABLE accidents ( accident_id NUMBER PRIMARY KEY, route_id NUMBER, accident_geometry SDO_GEOMETRY); -- Insert an accident record. DECLARE geom_segment SDO_GEOMETRY; BEGIN SELECT SDO_LRS.LOCATE_PT(a.route_geometry, 9, 0) into geom_segment FROM lrs_routes a WHERE a.route_name = 'Route1'; INSERT INTO accidents VALUES(1, 1, geom_segment); END; / SELECT * from accidents; ACCIDENT_ID ROUTE_ID ----------- ---------- ACCIDENT_GEOMETRY(SDO_GTYPE, SDO_SRID, SDO_POINT(X, Y, Z), SDO_ELEM_INFO, SDO_OR -------------------------------------------------------------------------------- 1 1 SDO_GEOMETRY(3301, NULL, NULL, SDO_ELEM_INFO_ARRAY(1, 1, 1), SDO_ORDINATE_ARRAY( 9, 4, 9))

## SDO_LRS.LRS_INTERSECTION

Format

SDO_LRS.LRS_INTERSECTION(

geom_1 IN SDO_GEOMETRY,

dim_array_1 IN SDO_DIM_ARRAY,

geom_2 IN SDO_GEOMETRY,

dim_array_2 IN SDO_DIM_ARRAY

) RETURN SDO_GEOMETRY;

or

SDO_LRS.LRS_INTERSECTION(

geom_1 IN SDO_GEOMETRY,

geom_2 IN SDO_GEOMETRY,

tolerance IN NUMBER

) RETURN SDO_GEOMETRY;

Description

Returns an LRS geometry object that is the topological intersection (AND operation) of two geometry objects where one or both are LRS geometries.

Parameters

- geom_1
Geometry object.

- dim_array_1
Dimensional information array corresponding to

`geom_1`

, usually selected from one of the xxx_SDO_GEOM_METADATA views (described in Section 2.6).- geom_2
Geometry object.

- dim_array_2
Dimensional information array corresponding to

`geom_2`

, usually selected from one of the xxx_SDO_GEOM_METADATA views (described in Section 2.6).- tolerance
Tolerance value (see Section 1.5.5).

Usage Notes

Note:

This function is new with Oracle Spatial release 10.2.0.3.This function performs essentially the same intersection operation as the SDO_GEOM.SDO_INTERSECTION function (described in Chapter 15), except that SDO_LRS.LRS_INTERSECTION is designed to return a valid LRS geometry (point, line string, or multiline string) where one or both of the geometry-related input parameters are LRS geometries. (If neither input geometry is an LRS geometry, this function operates the same as the SDO_GEOM.SDO_INTERSECTION function.).

The returned geometry is an LRS line string, multiline string, or point geometry that includes measure dimension information. The measure values reflect those in the first LRS geometry specified as an input parameter.

The first LRS geometry specified as an input parameter must not be a polygon; it must be a line string, multiline string, or point.

If an LRS line string (geometric segment) intersects a line string (LRS or standard), the result is an LRS point; if an LRS line string intersects a polygon, the result is an LRS line string.

If the function format with

`tolerance`

is used, all geometry objects must be defined using 4-digit SDO_GTYPE values (explained in Section 2.2.1).An exception is raised if

`geom_1`

and`geom_2`

are based on different coordinate systems.Examples

The following example shows an LRS geometric segment (illustrated in Figure 7-20 in Section 7.7) intersected by a vertical line from (8,2) to (8,6). The result is an LRS point geometry, in which the measure value (8) reflects the measure for that point (designated as Exit 3 in Figure 7-20) in the

`geom_1`

geometry. (This example uses the definitions from the example in Section 7.7.)-- Intersection of LRS segment and standard line segment SELECT SDO_LRS.LRS_INTERSECTION(route_geometry, SDO_GEOMETRY(2002, NULL, NULL, SDO_ELEM_INFO_ARRAY(1,2,1), SDO_ORDINATE_ARRAY(8,2, 8,6)), 0.005) FROM lrs_routes WHERE route_id = 1; SDO_LRS.LRS_INTERSECTION(ROUTE_GEOMETRY,SDO_GEOMETRY(2002,NULL,NULL,SDO_ELEM_INF -------------------------------------------------------------------------------- SDO_GEOMETRY(3301, NULL, NULL, SDO_ELEM_INFO_ARRAY(1, 1, 1), SDO_ORDINATE_ARRAY( 8, 4, 8))The following example shows an LRS geometric segment (illustrated in Figure 7-20 in Section 7.7) intersected by a vertical line from (12,2) to (12,6). The result is an LRS line string geometry, in which the measure values (12 and 14) reflect measures for points (the first of which is designated as Exit 4 in Figure 7-20) in the

`geom_1`

geometry. (This example uses the definitions from the example in Section 7.7.)SELECT SDO_LRS.LRS_INTERSECTION(route_geometry, SDO_GEOMETRY(2002, NULL, NULL, SDO_ELEM_INFO_ARRAY(1,2,1), SDO_ORDINATE_ARRAY(12,2, 12,6)), 0.005) FROM lrs_routes WHERE route_id = 1; SDO_LRS.LRS_INTERSECTION(ROUTE_GEOMETRY,SDO_GEOMETRY(2002,NULL,NULL,SDO_ELEM_INF -------------------------------------------------------------------------------- SDO_GEOMETRY(3302, NULL, NULL, SDO_ELEM_INFO_ARRAY(1, 2, 1), SDO_ORDINATE_ARRAY( 12, 4, 12, 12, 6, 14))

## SDO_LRS.MEASURE_RANGE

Format

SDO_LRS.MEASURE_RANGE(

geom_segment IN SDO_GEOMETRY

[, dim_array IN SDO_DIM_ARRAY]

) RETURN NUMBER;

Description

Returns the measure range of a geometric segment, that is, the difference between the start measure and end measure.

Parameters

- geom_segment
Cartographic representation of a linear feature.

- dim_array
`geom_segment`

, usually selected from one of the xxx_SDO_GEOM_METADATA views (described in Section 2.6).Usage Notes

This function subtracts the start measure of

`geom_segment`

from the end measure of`geom_segment`

.The _3D format of this function (SDO_LRS.MEASURE_RANGE_3D) is available. For information about _3D formats of LRS functions, see Section 7.4.

Examples

The following example returns the measure range of the geometric segment representing Route 1. (This example uses the definitions from the example in Section 7.7.)

SELECT SDO_LRS.MEASURE_RANGE(route_geometry) FROM lrs_routes WHERE route_id = 1; SDO_LRS.MEASURE_RANGE(ROUTE_GEOMETRY) ------------------------------------- 27

## SDO_LRS.MEASURE_TO_PERCENTAGE

Format

SDO_LRS.MEASURE_TO_PERCENTAGE(

geom_segment IN SDO_GEOMETRY,

measure IN NUMBER

) RETURN NUMBER;

or

SDO_LRS.MEASURE_TO_PERCENTAGE(

geom_segment IN SDO_GEOMETRY,

dim_array IN SDO_DIM_ARRAY,

measure IN NUMBER

) RETURN NUMBER;

Description

Returns the percentage (0 to 100) that a specified measure is of the measure range of a geometric segment.

Parameters

- geom_segment
Cartographic representation of a linear feature.

- dim_array
`geom_segment`

, usually selected from one of the xxx_SDO_GEOM_METADATA views (described in Section 2.6).- measure
Measure value. This function returns the percentage that this measure value is of the measure range.

Usage Notes

This function returns a number (0 to 100) that is the percentage of the measure range that the specified measure represents. (The measure range is the end measure minus the start measure.) For example, if the measure range of

`geom_segment`

is 50 and`measure`

is 20, the function returns 40 (because 20/50 = 40%).This function performs the reverse of the SDO_LRS.PERCENTAGE_TO_MEASURE function, which returns the measure that corresponds to a percentage value.

An exception is raised if

`geom_segment`

or`measure`

is invalid.Examples

The following example returns the percentage that 5 is of the measure range of the geometric segment representing Route 1. (This example uses the definitions from the example in Section 7.7.) The measure range of this segment is 27, and 5 is approximately 18.5 percent of 27.

SELECT SDO_LRS.MEASURE_TO_PERCENTAGE(a.route_geometry, m.diminfo, 5) FROM lrs_routes a, user_sdo_geom_metadata m WHERE m.table_name = 'LRS_ROUTES' AND m.column_name = 'ROUTE_GEOMETRY' AND a.route_id = 1; SDO_LRS.MEASURE_TO_PERCENTAGE(A.ROUTE_GEOMETRY,M.DIMINFO,5) ----------------------------------------------------------- 18.5185185

## SDO_LRS.OFFSET_GEOM_SEGMENT

Format

SDO_LRS.OFFSET_GEOM_SEGMENT(

geom_segment IN SDO_GEOMETRY,

start_measure IN NUMBER,

end_measure IN NUMBER,

offset IN NUMBER,

tolerance IN NUMBER DEFAULT 1.0e-8

[, unit IN VARCHAR2]

) RETURN SDO_GEOMETRY;

or

SDO_LRS.OFFSET_GEOM_SEGMENT(

geom_segment IN SDO_GEOMETRY,

dim_array IN SDO_DIM_ARRAY,

start_measure IN NUMBER,

end_measure IN NUMBER,

offset IN NUMBER

[, unit IN VARCHAR2]

) RETURN SDO_GEOMETRY;

Description

Returns the geometric segment at a specified offset from a geometric segment.

Parameters

- geom_segment
Cartographic representation of a linear feature.

- dim_array
`geom_segment`

, usually selected from one of the xxx_SDO_GEOM_METADATA views (described in Section 2.6).- start_measure
Start measure of

`geom_segment`

at which to start the offset operation.- end_measure
End measure of

`geom_segment`

at which to start the offset operation.- offset
Distance to measure perpendicularly from the points along

`geom_segment`

. Positive offset values are to the left of`geom_segment`

; negative offset values are to the right of`geom_segment`

.- tolerance
Tolerance value (see Section 1.5.5 and Section 7.6). The default value is 0.00000001.

- unit
Unit of measurement specification: a quoted string with one or both of the following keywords:

`unit`

and an SDO_UNIT value from the MDSYS.SDO_DIST_UNITS table. See Section 2.8 for more information about unit of measurement specification.

`arc_tolerance`

and an arc tolerance value. See the Usage Notes for the SDO_GEOM.SDO_ARC_DENSIFY function in Chapter 15 for more information about the`arc_tolerance`

keyword.For example: 'unit=km arc_tolerance=0.05'

If the input geometry is geodetic data, this parameter is required, and

`arc_tolerance`

must be specified. If the input geometry is Cartesian or projected data,`arc_tolerance`

has no effect and should not be specified.If this parameter is not specified for a Cartesian or projected geometry, or if the

`arc_tolerance`

keyword is specified for a geodetic geometry but the`unit`

keyword is not specified, the unit of measurement associated with the data is assumed.Usage Notes

`start_measure`

and`end_measure`

can be any points on the geometric segment. They do not have to be in any specific order. For example,`start_measure`

and`end_measure`

can be 5 and 10, respectively, or 10 and 5, respectively.The direction and measures of the resulting geometric segment are preserved (that is, they reflect the original segment).

The geometry type of

`geom_segment`

must be line or multiline. For example, it cannot be a polygon.An exception is raised if

`geom_segment`

,`start_measure`

, or`end_measure`

is invalid.Examples

The following example returns the geometric segment 2 distance units to the left (positive offset 2) of the segment from measures 5 through 10 of Route 1. Note in SDO_ORDINATE_ARRAY of the returned segment that the Y values (6) are 2 greater than the Y values (4) of the relevant part of the original segment. (This example uses the definitions from the example in Section 7.7.)

-- Create a segment offset 2 to the left from measures 5 through 10. -- First, display the original segment; then, offset. SELECT a.route_geometry FROM lrs_routes a WHERE a.route_id = 1; ROUTE_GEOMETRY(SDO_GTYPE, SDO_SRID, SDO_POINT(X, Y, Z), SDO_ELEM_INFO, SDO_ORDIN -------------------------------------------------------------------------------- SDO_GEOMETRY(3302, NULL, NULL, SDO_ELEM_INFO_ARRAY(1, 2, 1), SDO_ORDINATE_ARRAY( 2, 2, 0, 2, 4, 2, 8, 4, 8, 12, 4, 12, 12, 10, 18, 8, 10, 22, 5, 14, 27)) SELECT SDO_LRS.OFFSET_GEOM_SEGMENT(a.route_geometry, m.diminfo, 5, 10, 2) FROM lrs_routes a, user_sdo_geom_metadata m WHERE m.table_name = 'LRS_ROUTES' AND m.column_name = 'ROUTE_GEOMETRY' AND a.route_id = 1; SDO_LRS.OFFSET_GEOM_SEGMENT(A.ROUTE_GEOMETRY,M.DIMINFO,5,10,2)(SDO_GTYPE, SDO_SR -------------------------------------------------------------------------------- SDO_GEOMETRY(3302, NULL, NULL, SDO_ELEM_INFO_ARRAY(1, 2, 1), SDO_ORDINATE_ARRAY( 5, 6, 5, 10, 6, 10))

## SDO_LRS.PERCENTAGE_TO_MEASURE

Format

SDO_LRS.PERCENTAGE_TO_MEASURE(

geom_segment IN SDO_GEOMETRY,

percentage IN NUMBER

) RETURN NUMBER;

or

SDO_LRS.PERCENTAGE_TO_MEASURE(

geom_segment IN SDO_GEOMETRY,

dim_array IN SDO_DIM_ARRAY,

percentage IN NUMBER

) RETURN NUMBER;

Description

Returns the measure value of a specified percentage (0 to 100) of the measure range of a geometric segment.

Parameters

- geom_segment
Cartographic representation of a linear feature.

- dim_array
`geom_segment`

, usually selected from one of the xxx_SDO_GEOM_METADATA views (described in Section 2.6).- percentage
Percentage value. Must be from 0 to 100. This function returns the measure value corresponding to this percentage of the measure range.

Usage Notes

This function returns the measure value corresponding to the specified percentage of the measure range. (The measure range is the end measure minus the start measure.) For example, if the measure range of

`geom_segment`

is 50 and`percentage`

is 40, the function returns 20 (because 40% of 50 = 20).This function performs the reverse of the SDO_LRS.MEASURE_TO_PERCENTAGE function, which returns the percentage value that corresponds to a measure.

An exception is raised if

`geom_segment`

has an invalid geometry type or dimensionality, or if`percentage`

is less than 0 or greater than 100.Examples

The following example returns the measure that is 50 percent of the measure range of the geometric segment representing Route 1. (This example uses the definitions from the example in Section 7.7.) The measure range of this segment is 27, and 50 percent of 27 is 13.5.

SELECT SDO_LRS.PERCENTAGE_TO_MEASURE(a.route_geometry, m.diminfo, 50) FROM lrs_routes a, user_sdo_geom_metadata m WHERE m.table_name = 'LRS_ROUTES' AND m.column_name = 'ROUTE_GEOMETRY' AND a.route_id = 1; SDO_LRS.PERCENTAGE_TO_MEASURE(A.ROUTE_GEOMETRY,M.DIMINFO,50) ------------------------------------------------------------ 13.5

## SDO_LRS.PROJECT_PT

Format

SDO_LRS.PROJECT_PT(

geom_segment IN SDO_GEOMETRY,

point IN SDO_GEOMETRY,

tolerance IN NUMBER DEFAULT 1.0e-8

[, offset OUT NUMBER]

) RETURN SDO_GEOMETRY;

or

SDO_LRS.PROJECT_PT(

geom_segment IN SDO_GEOMETRY,

dim_array IN SDO_DIM_ARRAY,

point IN SDO_GEOMETRY

[, point_dim_array IN SDO_DIM_ARRAY]

) RETURN SDO_GEOMETRY;

or

SDO_LRS.PROJECT_PT(

geom_segment IN SDO_GEOMETRY,

dim_array IN SDO_DIM_ARRAY,

point IN SDO_GEOMETRY,

point_dim_array IN SDO_DIM_ARRAY

[, offset OUT NUMBER]

) RETURN SDO_GEOMETRY;

Description

Returns the projection point of a specified point. The projection point is on the geometric segment.

Parameters

- geom_segment
Geometric segment to be checked.

- dim_array
`geom_segment`

, usually selected from one of the xxx_SDO_GEOM_METADATA views (described in Section 2.6).- point
Point to be projected.

- tolerance
Tolerance value (see Section 1.5.5 and Section 7.6). The default value is 0.00000001.

- point_dim_array
Dimensional information array corresponding to

`point`

, usually selected from one of the xxx_SDO_GEOM_METADATA views (described in Section 2.6).- offset
Offset (shortest distance) from the point to the geometric segment.

Usage Notes

This function returns the projection point (including its measure) of a specified point (

`point`

). The projection point is on the geometric segment.If multiple projection points exist, the first projection point encountered from the start point is returned.

If you specify the output parameter

`offset`

, the function stores the signed offset (shortest distance) from the point to the geometric segment. For more information about the offset to a geometric segment, see Section 7.1.5.An exception is raised if

`geom_segment`

or`point`

has an invalid geometry type or dimensionality, or if`geom_segment`

and`point`

are based on different coordinate systems.The _3D format of this function (SDO_LRS.PROJECT_PT_3D) is available. For information about _3D formats of LRS functions, see Section 7.4.

For more information about projecting a point onto a geometric segment, see Section 7.5.9.

Examples

The following example returns the point (9,4,9) on the geometric segment representing Route 1 that is closest to the specified point (9,3,NULL). (This example uses the definitions from the example in Section 7.7.)

-- Point 9,3,NULL is off the road; should return 9,4,9. SELECT SDO_LRS.PROJECT_PT(route_geometry, SDO_GEOMETRY(3301, NULL, NULL, SDO_ELEM_INFO_ARRAY(1, 1, 1), SDO_ORDINATE_ARRAY(9, 3, NULL)) ) FROM lrs_routes WHERE route_id = 1; SDO_LRS.PROJECT_PT(ROUTE_GEOMETRY,SDO_GEOMETRY(3301,NULL,NULL,SDO_EL -------------------------------------------------------------------------------- SDO_GEOMETRY(3301, NULL, NULL, SDO_ELEM_INFO_ARRAY(1, 1, 1), SDO_ORDINATE_ARRAY( 9, 4, 9))

## SDO_LRS.REDEFINE_GEOM_SEGMENT

Format

SDO_LRS.REDEFINE_GEOM_SEGMENT(

geom_segment IN OUT SDO_GEOMETRY

[, start_measure IN NUMBER,

end_measure IN NUMBER]);

or

SDO_LRS.REDEFINE_GEOM_SEGMENT(

geom_segment IN OUT SDO_GEOMETRY,

dim_array IN SDO_DIM_ARRAY

[, start_measure IN NUMBER,

end_measure IN NUMBER]);

Description

Populates the measures of all shape points based on the start and end measures of a geometric segment, overriding any previously assigned measures between the start point and end point.

Parameters

- geom_segment
Cartographic representation of a linear feature.

- dim_array
`geom_segment`

, usually selected from one of the xxx_SDO_GEOM_METADATA views (described in Section 2.6).- start_measure
Distance measured from the start point of a geometric segment to the start point of the linear feature. The default is the existing value (if any) in the measure dimension; otherwise, the default is 0.

- end_measure
Distance measured from the end point of a geometric segment to the start point of the linear feature. The default is the existing value (if any) in the measure dimension; otherwise, the default is the cartographic length of the segment.

Usage Notes

An exception is raised if

`geom_segment`

has an invalid geometry type or dimensionality, or if`start_measure`

or`end_measure`

is out of range.The _3D format of this procedure (SDO_LRS.REDEFINE_GEOM_SEGMENT_3D) is available. For information about _3D formats of LRS functions and procedures, see Section 7.4.

For more information about redefining a geometric segment, see Section 7.5.2.

Examples

The following example redefines a geometric segment, effectively converting miles to kilometers in the measure values. (This example uses the definitions from the example in Section 7.7.)

-- First, display the original segment; then, redefine. SELECT a.route_geometry FROM lrs_routes a WHERE a.route_id = 1; ROUTE_GEOMETRY(SDO_GTYPE, SDO_SRID, SDO_POINT(X, Y, Z), SDO_ELEM_INFO, SDO_ORDIN -------------------------------------------------------------------------------- SDO_GEOMETRY(3302, NULL, NULL, SDO_ELEM_INFO_ARRAY(1, 2, 1), SDO_ORDINATE_ARRAY( 2, 2, 0, 2, 4, 2, 8, 4, 8, 12, 4, 12, 12, 10, 18, 8, 10, 22, 5, 14, 27)) -- Redefine geometric segment to "convert" miles to kilometers. DECLARE geom_segment SDO_GEOMETRY; dim_array SDO_DIM_ARRAY; BEGIN SELECT a.route_geometry into geom_segment FROM lrs_routes a WHERE a.route_name = 'Route1'; SELECT m.diminfo into dim_array from user_sdo_geom_metadata m WHERE m.table_name = 'LRS_ROUTES' AND m.column_name = 'ROUTE_GEOMETRY'; -- "Convert" mile measures to kilometers (27 * 1.609 = 43.443). SDO_LRS.REDEFINE_GEOM_SEGMENT (geom_segment, dim_array, 0, -- Zero starting measure: LRS segment starts at start of route. 43.443); -- End of LRS segment. 27 miles = 43.443 kilometers. -- Update and insert geometries into table, to display later. UPDATE lrs_routes a SET a.route_geometry = geom_segment WHERE a.route_id = 1; END; / PL/SQL procedure successfully completed. -- Display the redefined segment, with all measures "converted." SELECT a.route_geometry FROM lrs_routes a WHERE a.route_id = 1; ROUTE_GEOMETRY(SDO_GTYPE, SDO_SRID, SDO_POINT(X, Y, Z), SDO_ELEM_INFO, SDO_ORDIN -------------------------------------------------------------------------------- SDO_GEOMETRY(3302, NULL, NULL, SDO_ELEM_INFO_ARRAY(1, 2, 1), SDO_ORDINATE_ARRAY( 2, 2, 0, 2, 4, 3.218, 8, 4, 12.872, 12, 4, 19.308, 12, 10, 28.962, 8, 10, 35.398 , 5, 14, 43.443))

## SDO_LRS.RESET_MEASURE

Format

SDO_LRS.RESET_MEASURE(

geom_segment IN OUT SDO_GEOMETRY

[, dim_array IN SDO_DIM_ARRAY]);

Description

Sets all measures of a geometric segment, including the start and end measures, to null values, overriding any previously assigned measures.

Parameters

- geom_segment
Cartographic representation of a linear feature.

- dim_array
`geom_segment`

, usually selected from one of the xxx_SDO_GEOM_METADATA views (described in Section 2.6).Usage Notes

An exception is raised if

`geom_segment`

has an invalid geometry type or dimensionality.Examples

The following example sets all measures of a geometric segment to null values. (This example uses the definitions from the example in Section 7.7.)

-- First, display the original segment; then, redefine. SELECT a.route_geometry FROM lrs_routes a WHERE a.route_id = 1; ROUTE_GEOMETRY(SDO_GTYPE, SDO_SRID, SDO_POINT(X, Y, Z), SDO_ELEM_INFO, SDO_ORDIN -------------------------------------------------------------------------------- SDO_GEOMETRY(3302, NULL, NULL, SDO_ELEM_INFO_ARRAY(1, 2, 1), SDO_ORDINATE_ARRAY( 2, 2, 0, 2, 4, 2, 8, 4, 8, 12, 4, 12, 12, 10, 18, 8, 10, 22, 5, 14, 27)) -- Reset geometric segment measures. DECLARE geom_segment SDO_GEOMETRY; BEGIN SELECT a.route_geometry into geom_segment FROM lrs_routes a WHERE a.route_name = 'Route1'; SDO_LRS.RESET_MEASURE (geom_segment); -- Update and insert geometries into table, to display later. UPDATE lrs_routes a SET a.route_geometry = geom_segment WHERE a.route_id = 1; END; / PL/SQL procedure successfully completed. -- Display the segment, with all measures set to null. SELECT a.route_geometry FROM lrs_routes a WHERE a.route_id = 1; ROUTE_GEOMETRY(SDO_GTYPE, SDO_SRID, SDO_POINT(X, Y, Z), SDO_ELEM_INFO, SDO_ORDIN -------------------------------------------------------------------------------- SDO_GEOMETRY(3302, NULL, NULL, SDO_ELEM_INFO_ARRAY(1, 2, 1), SDO_ORDINATE_ARRAY( 2, 2, NULL, 2, 4, NULL, 8, 4, NULL, 12, 4, NULL, 12, 10, NULL, 8, 10, NULL, 5, 1 4, NULL))

## SDO_LRS.REVERSE_GEOMETRY

Format

SDO_LRS.REVERSE_GEOMETRY(

geom IN SDO_GEOMETRY

[, dim_array IN SDO_DIM_ARRAY]

) RETURN SDO_GEOMETRY;

Description

Returns a new geometric segment by reversing the measure values and the direction of the original geometric segment.

Parameters

- geom
Cartographic representation of a linear feature.

- dim_array
Dimensional information array corresponding to

`geom`

, usually selected from one of the xxx_SDO_GEOM_METADATA views (described in Section 2.6).Usage Notes

This function:

Reverses the measure values of

`geom`

That is, the start measure of

`geom`

is the end measure of the returned geometric segment, the end measure of`geom`

is the start measure of the returned geometric segment, and all other measures are adjusted accordingly.Reverses the direction of

`geom`

Compare this function with SDO_LRS.REVERSE_MEASURE, which reverses only the measure values (not the direction) of a geometric segment.

To reverse the vertices of a non-LRS line string geometry, use the SDO_UTIL.REVERSE_LINESTRING function, which is described in Chapter 20.

An exception is raised if

`geom`

has an invalid geometry type or dimensionality. The geometry type must be a line or multiline, and the dimensionality must be 3 (two dimensions plus the measure dimension).The _3D format of this function (SDO_LRS.REVERSE_GEOMETRY_3D) is available. For information about _3D formats of LRS functions, see Section 7.4.

Examples

The following example reverses the measure values and the direction of the geometric segment representing Route 1. (This example uses the definitions from the example in Section 7.7.)

-- Reverse direction and measures (for example, to prepare for -- concatenating with another road). -- First, display the original segment; then, reverse. SELECT a.route_geometry FROM lrs_routes a WHERE a.route_id = 1; ROUTE_GEOMETRY(SDO_GTYPE, SDO_SRID, SDO_POINT(X, Y, Z), SDO_ELEM_INFO, SDO_ORDIN -------------------------------------------------------------------------------- SDO_GEOMETRY(3302, NULL, NULL, SDO_ELEM_INFO_ARRAY(1, 2, 1), SDO_ORDINATE_ARRAY( 2, 2, 0, 2, 4, 2, 8, 4, 8, 12, 4, 12, 12, 10, 18, 8, 10, 22, 5, 14, 27)) SELECT SDO_LRS.REVERSE_GEOMETRY(a.route_geometry, m.diminfo) FROM lrs_routes a, user_sdo_geom_metadata m WHERE m.table_name = 'LRS_ROUTES' AND m.column_name = 'ROUTE_GEOMETRY' AND a.route_id = 1; SDO_LRS.REVERSE_GEOMETRY(A.ROUTE_GEOMETRY,M.DIMINFO)(SDO_GTYPE, SDO_SRID, SDO_PO -------------------------------------------------------------------------------- SDO_GEOMETRY(3302, NULL, NULL, SDO_ELEM_INFO_ARRAY(1, 2, 1), SDO_ORDINATE_ARRAY( 5, 14, 27, 8, 10, 22, 12, 10, 18, 12, 4, 12, 8, 4, 8, 2, 4, 2, 2, 2, 0))Note in the returned segment that the M values (measures) now go in descending order from 27 to 0, and the segment start and end points have the opposite X and Y values as in the original segment (5,14 and 2,2 here, as opposed to 2,2 and 5,14 in the original).

## SDO_LRS.REVERSE_MEASURE

Format

SDO_LRS.REVERSE_MEASURE(

geom_segment IN SDO_GEOMETRY

[, dim_array IN SDO_DIM_ARRAY]

) RETURN SDO_GEOMETRY;

Description

Returns a new geometric segment by reversing the measure values, but not the direction, of the original geometric segment.

Parameters

- geom_segment
Cartographic representation of a linear feature.

- dim_array
`geom_segment`

, usually selected from one of the xxx_SDO_GEOM_METADATA views (described in Section 2.6).Usage Notes

This function:

Reverses the measure values of

`geom_segment`

That is, the start measure of

`geom_segment`

is the end measure of the returned geometric segment, the end measure of`geom_segment`

is the start measure of the returned geometric segment, and all other measures are adjusted accordingly.Does not affect the direction of

`geom_segment`

Compare this function with SDO_LRS.REVERSE_GEOMETRY, which reverses both the direction and the measure values of a geometric segment.

An exception is raised if

`geom_segment`

has an invalid geometry type or dimensionality.The _3D format of this function (SDO_LRS.REVERSE_MEASURE_3D) is available. For information about _3D formats of LRS functions, see Section 7.4.

Note:

The behavior of the SDO_LRS.REVERSE_MEASURE function changed after release 8.1.7. In release 8.1.7, REVERSE_MEASURE reversed both the measures and the segment direction. However, if you want to have this same behavior with subsequent releases, you must use the SDO_LRS.REVERSE_GEOMETRY function.Examples

The following example reverses the measure values of the geometric segment representing Route 1, but does not affect the direction. (This example uses the definitions from the example in Section 7.7.)

-- First, display the original segment; then, reverse. SELECT a.route_geometry FROM lrs_routes a WHERE a.route_id = 1; ROUTE_GEOMETRY(SDO_GTYPE, SDO_SRID, SDO_POINT(X, Y, Z), SDO_ELEM_INFO, SDO_ORDIN -------------------------------------------------------------------------------- SDO_GEOMETRY(3302, NULL, NULL, SDO_ELEM_INFO_ARRAY(1, 2, 1), SDO_ORDINATE_ARRAY( 2, 2, 0, 2, 4, 2, 8, 4, 8, 12, 4, 12, 12, 10, 18, 8, 10, 22, 5, 14, 27)) SELECT SDO_LRS.REVERSE_MEASURE(a.route_geometry, m.diminfo) FROM lrs_routes a, user_sdo_geom_metadata m WHERE m.table_name = 'LRS_ROUTES' AND m.column_name = 'ROUTE_GEOMETRY' AND a.route_id = 1; SDO_LRS.REVERSE_MEASURE(A.ROUTE_GEOMETRY,M.DIMINFO)(SDO_GTYPE, SDO_SRID, SDO_POI -------------------------------------------------------------------------------- SDO_GEOMETRY(3302, NULL, NULL, SDO_ELEM_INFO_ARRAY(1, 2, 1), SDO_ORDINATE_ARRAY( 2, 2, 27, 2, 4, 25, 8, 4, 19, 12, 4, 15, 12, 10, 9, 8, 10, 5, 5, 14, 0))Note in the returned segment that the M values (measures) now go in descending order from 27 to 0, but the segment start and end points have the same X and Y values as in the original segment (2,2 and 5,14).

## SDO_LRS.SET_PT_MEASURE

Format

SDO_LRS.SET_PT_MEASURE(

geom_segment IN OUT SDO_GEOMETRY,

point IN SDO_GEOMETRY,

measure IN NUMBER) RETURN VARCHAR2;

or

SDO_LRS.SET_PT_MEASURE(

geom_segment IN OUT SDO_GEOMETRY,

dim_array IN SDO_DIM_ARRAY,

point IN SDO_GEOMETRY,

pt_dim_array IN SDO_DIM_ARRAY,

measure IN NUMBER) RETURN VARCHAR2;

or

SDO_LRS.SET_PT_MEASURE(

point IN OUT SDO_GEOMETRY,

measure IN NUMBER) RETURN VARCHAR2;

or

SDO_LRS.SET_PT_MEASURE(

point IN OUT SDO_GEOMETRY,

dim_array IN SDO_DIM_ARRAY,

measure IN NUMBER) RETURN VARCHAR2;

Description

Sets the measure value of a specified point.

Parameters

- geom_segment
Geometric segment containing the point.

- dim_array
Dimensional information array corresponding to

`geom_segment`

(in the second format) or`point`

(in the fourth format), usually selected from one of the xxx_SDO_GEOM_METADATA views (described in Section 2.6).- point
Point for which the measure value is to be set.

- pt_dim_array
Dimensional information array corresponding to

`point`

(in the second format), usually selected from one of the xxx_SDO_GEOM_METADATA views (described in Section 2.6).- measure
Measure value to be assigned to the specified point.

Usage Notes

The function returns TRUE if the measure value was successfully set, and FALSE if the measure value was not set.

If both

`geom_segment`

and`point`

are specified, the behavior of the procedure depends on whether or not`point`

is a shape point on`geom_segment`

:

If

`point`

is a shape point on`geom_segment`

, the measure value of`point`

is set.If

`point`

is not a shape point on`geom_segment`

, the shape point on`geom_segment`

that is nearest to`point`

is found, and the measure value of that shape point is set.The _3D format of this function (SDO_LRS.SET_PT_MEASURE_3D) is available; however, only the formats that include the

`geom_segment`

parameter are available for SDO_LRS.SET_PT_MEASURE_3D. For information about _3D formats of LRS functions, see Section 7.4.An exception is raised if

`geomK_segment`

or`point`

is invalid.Examples

The following example sets the measure value of point (8,10) to 20. (This example uses the definitions from the example in Section 7.7.)

-- Set the measure value of point 8,10 to 20 (originally 22). DECLARE geom_segment SDO_GEOMETRY; dim_array SDO_DIM_ARRAY; result VARCHAR2(32); BEGIN SELECT a.route_geometry into geom_segment FROM lrs_routes a WHERE a.route_name = 'Route1'; SELECT m.diminfo into dim_array from user_sdo_geom_metadata m WHERE m.table_name = 'LRS_ROUTES' AND m.column_name = 'ROUTE_GEOMETRY'; -- Set the measure value of point 8,10 to 20 (originally 22). result := SDO_LRS.SET_PT_MEASURE (geom_segment, SDO_GEOMETRY(3301, NULL, NULL, SDO_ELEM_INFO_ARRAY(1, 1, 1), SDO_ORDINATE_ARRAY(8, 10, 22)), 20); -- Display the result. DBMS_OUTPUT.PUT_LINE('Returned value = ' || result); END; / Returned value = TRUE PL/SQL procedure successfully completed.

## SDO_LRS.SPLIT_GEOM_SEGMENT

Format

SDO_LRS.SPLIT_GEOM_SEGMENT(

geom_segment IN SDO_GEOMETRY,

split_measure IN NUMBER,

segment_1 OUT SDO_GEOMETRY,

segment_2 OUT SDO_GEOMETRY);

or

SDO_LRS.SPLIT_GEOM_SEGMENT(

geom_segment IN SDO_GEOMETRY,

dim_array IN SDO_DIM_ARRAY,

split_measure IN NUMBER,

segment_1 OUT SDO_GEOMETRY,

segment_2 OUT SDO_GEOMETRY);

Description

Splits a geometric segment into two geometric segments.

Parameters

- geom_segment
Geometric segment to be split.

- dim_array
`geom_segment`

, usually selected from one of the xxx_SDO_GEOM_METADATA views (described in Section 2.6).- split_measure
Distance measured from the start point of a geometric segment to the split point.

- segment_1
First geometric segment: from the start point of

`geom_segment`

to the split point.- segment_2
Second geometric segment: from the split point to the end point of

`geom_segment`

.Usage Notes

An exception is raised if

`geom_segment`

or`split_measure`

is invalid.The directions and measures of the resulting geometric segments are preserved.

The _3D format of this procedure (SDO_LRS.SPLIT_GEOM_SEGMENT_3D) is available. For information about _3D formats of LRS functions and procedures, see Section 7.4.

For more information about splitting a geometric segment, see Section 7.5.4.

Examples

The following example defines the geometric segment, splits it into two segments, then concatenates those segments. (This example uses the definitions from the example in Section 7.7. The definitions of

`result_geom_1`

,`result_geom_2`

, and`result_geom_3`

are displayed in Example 7-3.)DECLARE geom_segment SDO_GEOMETRY; line_string SDO_GEOMETRY; dim_array SDO_DIM_ARRAY; result_geom_1 SDO_GEOMETRY; result_geom_2 SDO_GEOMETRY; result_geom_3 SDO_GEOMETRY; BEGIN SELECT a.route_geometry into geom_segment FROM lrs_routes a WHERE a.route_name = 'Route1'; SELECT m.diminfo into dim_array from user_sdo_geom_metadata m WHERE m.table_name = 'LRS_ROUTES' AND m.column_name = 'ROUTE_GEOMETRY'; -- Define the LRS segment for Route1. SDO_LRS.DEFINE_GEOM_SEGMENT (geom_segment, dim_array, 0, -- Zero starting measure: LRS segment starts at start of route. 27); -- End of LRS segment is at measure 27. SELECT a.route_geometry INTO line_string FROM lrs_routes a WHERE a.route_name = 'Route1'; -- Split Route1 into two segments. SDO_LRS.SPLIT_GEOM_SEGMENT(line_string,dim_array,5,result_geom_1,result_geom_2); -- Concatenate the segments that were just split. result_geom_3 := SDO_LRS.CONCATENATE_GEOM_SEGMENTS(result_geom_1, dim_array, result_geom_2, dim_array); -- Insert geometries into table, to display later. INSERT INTO lrs_routes VALUES( 11, 'result_geom_1', result_geom_1 ); INSERT INTO lrs_routes VALUES( 12, 'result_geom_2', result_geom_2 ); INSERT INTO lrs_routes VALUES( 13, 'result_geom_3', result_geom_3 ); END; /

## SDO_LRS.TRANSLATE_MEASURE

Format

SDO_LRS.TRANSLATE_MEASURE(

geom_segment IN SDO_GEOMETRY,

translate_m IN NUMBER

) RETURN SDO_GEOMETRY;

or

SDO_LRS.TRANSLATE_MEASURE(

geom_segment IN SDO_GEOMETRY,

dim_array IN SDO_DIM_ARRAY,

translate_m IN NUMBER

) RETURN SDO_GEOMETRY;

Description

Returns a new geometric segment by translating the original geometric segment (that is, shifting the start and end measures by a specified value).

Parameters

- geom_segment
Cartographic representation of a linear feature.

- dim_array
`geom_segment`

, usually selected from one of the xxx_SDO_GEOM_METADATA views (described in Section 2.6).- translate_m
Distance measured from the start point of a geometric segment to the start point of the linear feature.

Usage Notes

This function adds

`translate_m`

to the start and end measures of`geom_segment`

. For example, if`geom_segment`

has a start measure of 50 and an end measure of 100, and if`translate_m`

is 10, the returned geometric segment has a start measure of 60 and an end measure of 110, as shown in Figure 16-1.An exception is raised if

`geom_segment`

has an invalid geometry type or dimensionality.The _3D format of this function (SDO_LRS.TRANSLATE_MEASURE_3D) is available. For information about _3D formats of LRS functions, see Section 7.4.

Examples

The following example translates (shifts) by 10 the geometric segment representing Route 1. (This example uses the definitions from the example in Section 7.7.)

SELECT SDO_LRS.TRANSLATE_MEASURE(a.route_geometry, m.diminfo, 10) FROM lrs_routes a, user_sdo_geom_metadata m WHERE m.table_name = 'LRS_ROUTES' AND m.column_name = 'ROUTE_GEOMETRY' AND a.route_id = 1; SDO_LRS.TRANSLATE_MEASURE(A.ROUTE_GEOMETRY,M.DIMINFO,10)(SDO_GTYPE, SDO_SRID, SD -------------------------------------------------------------------------------- SDO_GEOMETRY(3002, NULL, NULL, SDO_ELEM_INFO_ARRAY(1, 2, 1), SDO_ORDINATE_ARRAY( 2, 2, 10, 2, 4, 12, 8, 4, 18, 12, 4, 22, 12, 10, 28, 8, 10, 32, 5, 14, 37))

## SDO_LRS.VALID_GEOM_SEGMENT

Format

SDO_LRS.VALID_GEOM_SEGMENT(

geom_segment IN SDO_GEOMETRY

[, dim_array IN SDO_DIM_ARRAY]

) RETURN VARCHAR2;

Description

Checks if a geometry object is a valid geometric segment.

Parameters

- geom_segment
Geometric segment to be checked for validity.

- dim_array
`geom_segment`

, usually selected from one of the xxx_SDO_GEOM_METADATA views (described in Section 2.6).Usage Notes

This function returns TRUE if

`geom_segment`

is valid and FALSE if`geom_segment`

is not valid.Measure information is assumed to be stored in the last element of the SDO_DIM_ARRAY in the Oracle Spatial metadata.

This function only checks for geometry type and number of dimensions of the geometric segment. To further validate measure information, use the SDO_LRS.IS_GEOM_SEGMENT_DEFINED function.

The _3D format of this function (SDO_LRS.VALID_GEOM_SEGMENT_3D) is available. For information about _3D formats of LRS functions, see Section 7.4.

Examples

The following example checks if the geometric segment representing Route 1 is valid. (This example uses the definitions from the example in Section 7.7.)

SELECT SDO_LRS.VALID_GEOM_SEGMENT(route_geometry) FROM lrs_routes WHERE route_id = 1; SDO_LRS.VALID_GEOM_SEGMENT(ROUTE_GEOMETRY) -------------------------------------------------------------------------------- TRUE

## SDO_LRS.VALID_LRS_PT

Format

SDO_LRS.VALID_LRS_PT(

point IN SDO_GEOMETRY

[, dim_array IN SDO_DIM_ARRAY]

) RETURN VARCHAR2;

Description

Checks if an LRS point is valid.

Parameters

- point
Point to be checked for validity.

- dim_array
`point`

, usually selected from one of the xxx_SDO_GEOM_METADATA views (described in Section 2.6).Usage Notes

This function returns TRUE if

`point`

is valid and FALSE if`point`

is not valid.This function checks if

`point`

is a point with measure information, and it checks for the geometry type and number of dimensions for the point geometry.All LRS point data must be stored in the SDO_ELEM_INFO_ARRAY and SDO_ORDINATE_ARRAY, and cannot be stored in the SDO_POINT field in the SDO_GEOMETRY definition of the point.

The _3D format of this function (SDO_LRS.VALID_LRS_PT_3D) is available. For information about _3D formats of LRS functions, see Section 7.4.

Examples

The following example checks if point (9,3,NULL) is a valid LRS point. (This example uses the definitions from the example in Section 7.7.)

SELECT SDO_LRS.VALID_LRS_PT( SDO_GEOMETRY(3301, NULL, NULL, SDO_ELEM_INFO_ARRAY(1, 1, 1), SDO_ORDINATE_ARRAY(9, 3, NULL)), m.diminfo) FROM lrs_routes a, user_sdo_geom_metadata m WHERE m.table_name = 'LRS_ROUTES' AND m.column_name = 'ROUTE_GEOMETRY' AND a.route_id = 1; SDO_LRS.VALID_LRS_PT(SDO_GEOMETRY(3301,NULL,NULL,SDO_ELEM_INFO_ARRAY(1,1,1),SDO_ -------------------------------------------------------------------------------- TRUE

## SDO_LRS.VALID_MEASURE

Format

SDO_LRS.VALID_MEASURE(

geom_segment IN SDO_GEOMETRY,

measure IN NUMBER

) RETURN VARCHAR2;

or

SDO_LRS.VALID_MEASURE(

geom_segment IN SDO_GEOMETRY,

dim_array IN SDO_DIM_ARRAY,

measure IN NUMBER

) RETURN VARCHAR2;

Description

Checks if a measure falls within the measure range of a geometric segment.

Parameters

- geom_segment
Geometric segment to be checked to see if

`measure`

falls within its measure range.- dim_array
`geom_segment`

, usually selected from one of the xxx_SDO_GEOM_METADATA views (described in Section 2.6).- measure
Measure value to be checked to see if it falls within the measure range of

`geom_segment`

.Usage Notes

This function returns TRUE if

`measure`

falls within the measure range of`geom_segment`

and FALSE if`measure`

does not fall within the measure range of`geom_segment`

.An exception is raised if

`geom_segment`

has an invalid geometry type or dimensionality.The _3D format of this function (SDO_LRS.VALID_MEASURE_3D) is available. For information about _3D formats of LRS functions, see Section 7.4.

Examples

The following example checks if 50 is a valid measure on the Route 1 segment. The function returns FALSE because the measure range for that segment is 0 to 27. For example, if the route is 27 miles long with mile markers at 1-mile intervals, there is no 50-mile marker because the last marker is the 27-mile marker. (This example uses the definitions from the example in Section 7.7.)

SELECT SDO_LRS.VALID_MEASURE(route_geometry, 50) FROM lrs_routes WHERE route_id = 1; SDO_LRS.VALID_MEASURE(ROUTE_GEOMETRY,50) -------------------------------------------------------------------------------- FALSE

## SDO_LRS.VALIDATE_LRS_GEOMETRY

Format

SDO_LRS.VALIDATE_LRS_GEOMETRY(

geom_segment IN SDO_GEOMETRY

[, dim_array IN SDO_DIM_ARRAY]

) RETURN VARCHAR2;

Description

Checks if an LRS geometry is valid.

Parameters

- geom_segment
Geometric segment to be checked.

- dim_array
`geom_segment`

, usually selected from one of the xxx_SDO_GEOM_METADATA views (described in Section 2.6).Usage Notes

This function returns TRUE if

`geom_segment`

is valid and one of the following errors if`geom_segment`

is not valid:

ORA-13331 (invalid LRS segment)

ORA-13335 (measure information not defined)

The _3D format of this function (SDO_LRS.VALIDATE_LRS_GEOMETRY_3D) is available. For information about _3D formats of LRS functions, see Section 7.4.

Examples

The following example checks if the Route 1 segment is a valid LRS geometry. (This example uses the definitions from the example in Section 7.7.)

SELECT SDO_LRS.VALIDATE_LRS_GEOMETRY(a.route_geometry, m.diminfo) FROM lrs_routes a, user_sdo_geom_metadata m WHERE m.table_name = 'LRS_ROUTES' AND m.column_name = 'ROUTE_GEOMETRY' AND a.route_id = 1; SDO_LRS.VALIDATE_LRS_GEOMETRY(A.ROUTE_GEOMETRY,M.DIMINFO) -------------------------------------------------------------------------------- TRUEyz;:`3T6FWMchp{wRywR?@RPxY;PEp?0Z@clPk !lp0VA#ΠA./sƷEh10mDt-']3V| {0o"֎ʀEč F"3_'2|P|mt3qf vb&bh" 3oV@:y.}7h3y"G(I*5v /O)+ x(+9Ɏ] 2q5pBb1Q%Ep wI`=u5vm" U9uguAVH^ &m !\{P)fN!@%Mz$ɐ r4Q0K8G&pU68'vpАnW&$p-1 2cMKx9C0U7 `x`2iy9X.$8+B {{p2( Jc@1R g1C!t4vQ`5FB4V0qP*wOmBp%KY$Q9@}a-r &LS? LHv524p=P$tX"/Vrt!hrQ["霈@xwZ0T@4 a2㵛 :)]7C ȨJ0/P@X@C0HP`4@SŞ0ѪУhz &B9_M//P;`8@7G0Y W%A@PjP4 |)䇒q 㔀"n)|` cˎmzI*rr J% {3ZS˵fE9O;zQjWI1NU[yK+ =dgj?Ep/<{)pжM n!t[1pP9 ӨSx R4w$g>,k\Sϰj "o#!ɸ0YkA0/!j !Ky{8]+mj<ٓ@:Z؛{[{OJJ;sK+{/Y a% e2oɱp;Ka&1ȢKK@G@b`btL<OvL٨3xFL W_5.g1F2B \aP\q+$;~[4Q @ȗ}P0O]3+'ԂSvEhO x\$ك|ƧE k5iI8R<[8.ʃްh`Eߌ״ {pePXZ \3z10k ? 4m0++#3OmoK@pB &M/|܌E[4Z1|IrZO +ZRr؟O1 R;Pɩ̸ۭ҄ ۽a*\Cas1H"t3j$qǏ:I2Ȓ(S>;يxΡX)%+ 8x&n&䓧S`MU]` (A:!! Áx,`*/j!*8 iEMEB t%$hF+8y$E$N%4#B%S! * pZ@ xMB6n&3aѝE:< A/NqUZ!A DyvX ! Z@N`DC^}uA (!APD( a`\3vNSb^s Tâ ^I0Ey$;!`$ 0QH:~ ,j= hEy_ |JsB Єt\(0Qt&&p(h@Xp@F(".,GLjk!eWꫭpk&lJPYLP $B"C-̄\dkε,}PP m"T$F@자ITNb! @i@K-blp}KƩ.K8{Q9xCTĨ̲ rA8 #ձ ,(s 16^tt gST=3nӄ]K@,L Pqa PwM) ypN#9ww8hx9 9Ta'ܢ}Q4bmGD\QP #0B6=}MD @h~:CTNͧۄ K:^PPo! |s7 Preface PKث](X(PKlUIOEBPS/sdo_route_server.htm## Preface

Oracle Spatial User's Guide and Reference provides usage and reference information for indexing and storing spatial data and for developing spatial applications using Oracle Spatial and Oracle Locator.

Oracle Spatial requires the Enterprise Edition of Oracle Database 10g. It is a foundation for the deployment of enterprise-wide spatial information systems, and Web-based and wireless location-based applications requiring complex spatial data management. Oracle Locator is a feature of the Standard and Enterprise Editions of Oracle Database 10g. It offers a subset of Oracle Spatial capabilities (see Appendix B for a list of Locator features) typically required to support Internet and wireless service applications and partner-based geographic information system (GIS) solutions.

The Standard and Enterprise Editions of Oracle Database 10g have the same basic features. However, several advanced features, such as extended data types, are available only with the Enterprise Edition, and some of these features are optional. For example, to use Oracle Database 10g table partitioning, you must have the Enterprise Edition and the Partitioning Option.

For information about the differences between Oracle Database 10g Standard Edition and Oracle Database 10g Enterprise Edition and the features and options that are available to you, see Oracle Database New Features.

Note:

The relational geometry model of Oracle Spatial is no longer supported, effective with Oracle release 9.2. Only the object-relational model is supported.## Audience

This guide is intended for anyone who needs to store spatial data in an Oracle database.

## Documentation Accessibility

Our goal is to make Oracle products, services, and supporting documentation accessible, with good usability, to the disabled community. To that end, our documentation includes features that make information available to users of assistive technology. This documentation is available in HTML format, and contains markup to facilitate access by the disabled community. Accessibility standards will continue to evolve over time, and Oracle is actively engaged with other market-leading technology vendors to address technical obstacles so that our documentation can be accessible to all of our customers. For more information, visit the Oracle Accessibility Program Web site at

`http://www.oracle.com/accessibility/`

Accessibility of Code Examples in Documentation

Screen readers may not always correctly read the code examples in this document. The conventions for writing code require that closing braces should appear on an otherwise empty line; however, some screen readers may not always read a line of text that consists solely of a bracket or brace.

Accessibility of Links to External Web Sites in Documentation

This documentation may contain links to Web sites of other companies or organizations that Oracle does not own or control. Oracle neither evaluates nor makes any representations regarding the accessibility of these Web sites.

TTY Access to Oracle Support Services

Oracle provides dedicated Text Telephone (TTY) access to Oracle Support Services within the United States of America 24 hours a day, seven days a week. For TTY support, call 800.446.2398.

## Related Documents

For more information, see the following documents:

Oracle Database Application Developer's Guide - Fundamentals

Oracle Database Error Messages - Spatial messages are in the range of 13000 to 13499.

Oracle error message documentation is only available in HTML. If you only have access to the Oracle Documentation CD, you can browse the error messages by range. Once you find the specific range, use your browser's "find in page" feature to locate the specific message. When connected to the Internet, you can search for a specific error message using the error message search feature of the Oracle online documentation.

Printed documentation is available for sale in the Oracle Store at

`http://oraclestore.oracle.com/`

To download free release notes, installation documentation, white papers, or other collateral, go to the Oracle Technology Network (OTN). You must register online before using OTN; registration is free and can be done at

`http://www.oracle.com/technology/membership`

If you already have a user name and password for OTN, then you can go directly to the documentation section of the OTN Web site at

`http://www.oracle.com/technology/documentation`

## Conventions

The following text conventions are used in this document:

Convention Meaning boldface Boldface type indicates graphical user interface elements associated with an action, or terms defined in text or the glossary. italic Italic type indicates book titles, emphasis, or placeholder variables for which you supply particular values. `monospace`

Monospace type indicates commands within a paragraph, URLs, code in examples, text that appears on the screen, or text that you enter. Routing Engine ## C Routing Engine

The Spatial routing engine enables you to host an XML-based Web service that provides the following features:

For an individual route request (a start location and an end location): route information (driving distances, estimated driving times, and directions) between the two locations

For a batch route request (multiple routes, with the same start location but different end locations): route information (driving distance and estimated driving time) for each route

For any request, the start and end locations are identified by addresses, geocoded results, or longitude/latitude coordinates.

The routing engine is implemented as a Java 2 Enterprise Edition (J2EE) Web application that you can deploy in either an Oracle Application Server or standalone Oracle Application Server Containers for J2EE (OC4J) environment.

Figure C-1 shows the basic flow of action with the routing engine: a client locates a remote routing engine instance, sends a route request, and processes the route response returned by the routing engine instance.

This chapter contains the following major sections:

## C.1 Deploying and Configuring the Routing Engine

To enable the routine engine to process routing requests and to generate responses, you must deploy the

`routeserver.ear`

file using OC4J or the Oracle Application Server. This section describes the basic steps.

Add the following element inside the <web-site> element in your http-web-site.xml or default-web-site.xml file of OC4J:

<web-app application="routeserver" name="web" load-on-startup="true" root="/routeserver" max-inactivity-time="no shutdown" shared="false" />Use the Oracle Application Server console to deploy the

`routeserver.ear`

file, or add the following element inside the`<application-server>`

element in the`server.xml`

file of OC4J (replace`<ROUTE_SERVER_HOME>`

accordingly):<application name="routeserver" path="<ROUTE_SERVER_HOME>/routeserver.ear" auto-start="true" />Add the following element inside the <application-server> element in the server.xml file of OC4J:

<max-http-connections value="10" />It is important to limit the number of concurrent requests that the Oracle Route Server can process at any given time to prevent

`java.lang.OutOfMemoryError`

errors.Start OC4J using the following command options:

-server -Xms<HEAP_SIZE> -Xmx<HEAP_SIZE> -XX:NewSize=<YOUNG_GENERATION_SIZE> -XX:MaxNewSize=<YOUNG_GENERATION_SIZE> -Dsun.rmi.dgc.server.gcInterval=3600000 -Dsun.rmi.dgc.client.gcInterval=3600000 -verbose:gc (optional)

`<HEAP_SIZE>`

must be at least 512 MB, and has a recommended size of at least 1024 MB (1 GB). Make sure that this memory is physical memory and not virtual memory.

`<YOUNG_GENERATION_SIZE>`

should be one-fourth (25%) of the`<HEAP_SIZE>`

value.-verbose:gc will print all minor and major Java garbage collections. Monitoring these statistics could be useful for memory resource planning. If you find that garbage collections are occurring frequently or are lasting several seconds, you probably need to allocate more physical memory to the Java VM.

Note:

The amount of memory the Java VM will need depends mostly on two parameters: the`<max-http-connections value="..." />`

element in the`<application-server>`

element in`server.xml`

, and the`partition_cache_size_limit`

parameter in`web.xml`

.The following command is an example that starts OC4J. Note that the -config flag is an OC4J command line parameter, not a VM option.

c:\jdk1.4.2\bin\java -server -Xms1024m -Xmx1024m -XX:NewSize=256m -XX:MaxNewSize=256m -Dsun.rmi.dgc.server.gcInterval=3600000 -Dsun.rmi.dgc.client.gcInterval=3600000 -verbose:gc -jar c:\oc4j\j2ee\home\oc4j.jar -config c:\oc4j\j2ee\home\config\server.xmlVerify your deployment by visiting the URL in the following format:

http://<hostname>:<port>/routeserverYou should see a welcome page. You should also see a message in the console window in which you started OC4J indicating that the Oracle Route Server was successfully initialized.

If you do not see a welcome message, the route server is probably not configured properly to run in your environment. In this case, edit the

`<ROUTE_SERVER_HOME>/routeserver/web/WEB-INF/web.xml`

file to reflect your environment and your preferences. (The`web.xml`

file is inside the`routeserver.ear`

file, and it will not be visible until OC4J expands it into the route server directory structure under`<ROUTE_SERVER_HOME>`

.) When you are finished editing, restart OC4J and verify your deployment.Consult the supplied examples. The page

`http://<hostname>:<port>/routeserver/`

has links at the bottom in a section named Test Samples. These examples demonstrate various capabilities of the Oracle Route Server. This is the best way to learn the XML API, which is described in Section C.2.## C.2 Routing Engine XML API

This section explains how to submit route requests in XML format to the routing engine, and it describes the XML document type definitions (DTDs) for the route requests (input) and responses (output). XML is widely used for transmitting structured documents using the HTTP protocol. If an HTTP request (GET or POST method) is used, it is assumed the request has a parameter named

`xml_request`

whose value is a string containing the XML document for the request.A request to the routing engine servlet has the following format:

http://hostname:port/route-server-servlet-path?xml_request=xml-requestIn this format:

hostname is the network path of the server on which the routing engine is running.

port is the port on which the application server listens.

route-server-servlet-path is the routing engine servlet path (for example,

`routeserver/servlet/RouteServerServlet`

).xml-request is the URL-encoded XML request submitted using the HTML GET or POST method.

The input XML is required for all requests. The output will be an XML document.

In an input route (as opposed to batch route) request, you must specify a route ID, and you can specify one or more of the following attributes:

`route_preference`

:`fastest`

or`shortest`

(default). (Note that for batch route requests, the default is`fastest`

.)

`road_preference`

:`highway`

(default) or`local`

`return_hierarchical_directions`

(whether to return hierarchical directions):`true`

or`false`

(default)

`return_driving_directions`

(whether to return driving directions):`true`

(default) or`false`

`return_route_geometry`

(whether to return the line string coordinates for the route):`true`

or`false`

(default)

`return_detailed_geometry`

:`true`

(default; returns detailed geometries) or`false`

(returns generalized geometries)

`distance_unit`

:`kilometer`

,`mile`

(default), or`meter`

`time_unit`

:`hour`

,`minute`

(default), or`second`

`pre_geocoded_locations`

(whether the start and end locations are input locations (address specifications or points) or previously geocoded locations):`true`

(previously geocoded locations) or`false`

(default; input locations)In an input batch route request, you must specify a request ID, a start location, and one or more end locations. Each location must have an ID attribute. You can also specify one or more of the following attributes for the batch route request:

`route_preference`

:`fastest`

(default) or`shortest`

. (Note that for individual route requests, the default is`shortest`

.)

`road_preference`

:`highway`

(default) or`local`

`distance_unit`

:`kilometer`

,`mile`

(default), or`meter`

`time_unit`

:`hour`

,`minute`

(default), or`second`

`sort_by_distance`

(whether to sort the returned routes in ascending order by distance of the end location from the start location:`true`

or`false`

(default)

`cutoff_distance`

(returning only routes where the end location is less than or equal to a specified number of distance units from the start location): (number; default = no limit)

`pre_geocoded_locations`

(whether the start and end locations are input locations (address specifications or points) or previously geocoded locations):`true`

(previously geocoded locations) or`false`

(default; input locations)This section contains the following subsections:

## C.2.1 Route Request and Response Examples

This section contains XML examples of route requests and the responses generated by those requests. One request uses specified addresses, another uses points specified by longitude and latitude coordinates, and another uses previously geocoded locations. For reference information about the available elements and attributes, see Section C.2.2 for requests and Section C.2.3 for responses.

Example C-1 shows a request for the fastest route, preferably using highways, between two offices at specified addresses (in Waltham, Massachusetts and Nashua, New Hampshire), with driving directions for each segment, and using miles for distances and minutes for times.

Example C-1 Route Request with Specified Addresses

<?xml version="1.0" standalone="yes"?> <route_request id="8" route_preference="fastest" road_preference="highway" return_driving_directions="true" distance_unit="mile" time_unit="minute"> <start_location> <input_location id="1"> <input_address> <us_form1 street="1000 Winter St" lastline="Waltham, MA" /> </input_address> </input_location></start_location> <end_location> <input_location id="2"> <input_address> <us_form1 street="1 Oracle Dr" lastline="Nashua, NH" /> </input_address> </input_location> </end_location> </route_request>Example C-2 shows the response generated by the request in Example C-1. (The output is reformatted for readability.)

Example C-2 Route Response with Specified Addresses

<?xml version="1.0" ?> <route_response> <route id="8" step_count="14" distance="30.28667355371901" distance_unit="mile" time="35.02037760416667" time_unit="minute"> <segment sequence="1" instruction="Start out on WINTER ST (Going South)" distance="1.2041612436793172"/> <segment sequence="2" instruction="Stay STRAIGHT to go onto TOTTEN POND RD (Going East)" distance="0.08879983757738225"/> <segment sequence="3" instruction="Turn LEFT onto WYMAN ST (Going North)" distance="0.24681569656886923"/> <segment sequence="4" instruction="Take I-95 N RAMP toward PEABODY" distance="0.23440010735937208"/> <segment sequence="5" instruction="Merge onto I-95/RT-128 (Going North)" distance="6.002288440990454"/> <segment sequence="6" instruction="Continue on I-95/RT-128" distance="0.0"/> <segment sequence="7" instruction="Stay STRAIGHT to go onto 32B/32A (Going East)" distance="0.15052764594854906"/> <segment sequence="8" instruction="Take EXIT 32A toward LOWELL" distance="0.032767910543403965"/> <segment sequence="9" instruction="Stay STRAIGHT to go onto RAMP (Going East)" distance="0.27877937515534706"/> <segment sequence="10" instruction="Turn LEFT onto US-3 (Going Northwest)" distance="20.66104112133381"/> <segment sequence="11" instruction="Stay STRAIGHT to go onto FREDERICK E EVERETT TPKE/US-3 (Going Northwest)" distance="0.00588619663828994"/> <segment sequence="12" instruction="Take EXIT 1 toward SO NASHUA" distance="0.5504892461007892"/> <segment sequence="13" instruction="Turn LEFT onto SPIT BROOK RD (Going West)" distance="0.5032054891878457"/> <segment sequence="14" instruction="Turn RIGHT onto ORACLE DR (Going North)" distance="0.3275097635011146"/> </route> </route_response>Example C-3 shows a request for the fastest route, preferably using highways, between two locations specified as longitude/latitude points, with driving directions for each segment, and using meters for distances and seconds for times. (The points are associated with two locations in San Francisco, California: the World Trade Center and 100 Flower Street.)

Example C-3 Route Request with Specified Longitude/Latitude Points

<?xml version="1.0" standalone="yes"?> <route_request id="8" route_preference="shortest" road_preference="highway" return_driving_directions="true" distance_unit="meter" time_unit="second" return_route_geometry="true" > <start_location> <input_location id="1" longitude="-122.39382" latitude="37.79518" /> </start_location> <end_location> <input_location id="2" longitude="-122.4054826" latitude="37.7423566" /> </end_location> </route_request>Example C-4 shows the response generated by the request in Example C-3. (The output is reformatted for readability.)

Example C-4 Route Response with Specified Longitude/Latitude Points

<route_response> <route id="8" step_count="13" distance="7261.4423828125" distance_unit="meter" time="441.9170837402344" time_unit="second"> <route_geometry> <LineString> <coordinates> -122.39381999996483,37.79517999996185 -122.39382,37.79518 -122.39458,37.79598 -122.39469,37.796 -122.39474,37.796 -122.39479,37.79599 -122.39483,37.79591 -122.39483,37.79579 -122.39462,37.79539 -122.39424,37.79488 -122.39338,37.79434 -122.39311,37.79413 -122.39275,37.79384 -122.39258,37.79368 -122.39171,37.79297 -122.39145,37.79273 -122.39127,37.79248 -122.3912,37.79235 -122.39107,37.79208 -122.39098,37.79185 -122.39088,37.79161 -122.39075,37.79138 -122.39048,37.79105 -122.3901,37.79079 -122.38918,37.79001 -122.38877,37.78968 -122.38857,37.78948 -122.38939,37.78882 -122.39024,37.78815 -122.39113,37.78745 -122.39192,37.7868 -122.39284,37.78606 -122.39372,37.78535 -122.39406,37.78507 -122.39511,37.78426 -122.39565,37.78383 -122.39621,37.78337 -122.39728,37.78252 -122.39824,37.78177 -122.39955,37.78075 -122.39963,37.78032 -122.3997,37.78011 -122.39984,37.77991 -122.40071,37.77899 -122.40085,37.77888 -122.40129,37.77855 -122.40182,37.77815 -122.40245,37.77776 -122.40302,37.77737 -122.40375,37.77695 -122.40433,37.77657 -122.40529,37.77592 -122.40581,37.7755 -122.40605,37.77524 -122.4063,37.77493 -122.40656,37.7744 -122.40671,37.7739 -122.40683,37.77312 -122.40671,37.77264 -122.4066,37.77216 -122.40634,37.77151 -122.40594,37.77074 -122.40573,37.77022 -122.4055,37.76958 -122.40547,37.76913 -122.40541,37.76843 -122.40542,37.76791 -122.40547,37.76743 -122.40541,37.76715 -122.40526,37.76579 -122.4051,37.7645 -122.40513,37.76404 -122.40519,37.76356 -122.40544,37.7629 -122.40561,37.76257 -122.40586,37.76218 -122.40619,37.76161 -122.40636,37.7612 -122.40648,37.76063 -122.40642,37.75996 -122.40633,37.75965 -122.4061,37.75918 -122.40574,37.75875 -122.40543,37.75846 -122.4045,37.75778 -122.40402,37.75735 -122.4038,37.75712 -122.40365,37.75688 -122.40344,37.75645 -122.4033,37.75588 -122.40326,37.75537 -122.40316,37.75437 -122.40304,37.75256 -122.40376,37.7502 -122.40384,37.74976 -122.40396,37.74969 -122.40454,37.74947 -122.40468,37.74933 -122.40474,37.74921 -122.40471,37.74902 -122.4045,37.74873 -122.40417,37.74839 -122.404,37.7482 -122.40378,37.74799 -122.40376,37.74781 -122.40428,37.74623 -122.40428,37.74598 -122.40417,37.74557 -122.40419,37.74483 -122.40431,37.74423 -122.40443,37.74396 -122.40468,37.74353 -122.40509,37.74294 -122.40472,37.74274 -122.40512,37.7422 -122.40548260000706,37.74235680000305 </coordinates> </LineString> </route_geometry> <segment sequence="1" instruction="Start out on THE EMBARCADERO (Going Northwest)" distance="5.246016371529549E-6"/> <segment sequence="2" instruction="Stay STRAIGHT to go onto THE EMBARCADERO/WORLD TRADE CTR/FERRY PLZ/FERRY BLDG (Going Northwest)" distance="111.19815063476562"/> <segment sequence="3" instruction="Turn LEFT onto RAMP (Going Southwest)" distance="41.756561279296875"/> <segment sequence="4" instruction="Turn LEFT onto THE EMBARCADERO (Going Southeast)" distance="905.924072265625"/> <segment sequence="5" instruction="Turn RIGHT onto HARRISON ST (Going Southwest)" distance="1369.1490478515625"/> <segment sequence="6" instruction="Take I-80 W RAMP toward SAN JOSE" distance="225.425048828125"/> <segment sequence="7" instruction="Turn SLIGHT RIGHT onto I-80/JAMES LICK SKWY (Going Southwest)" distance="1528.181396484375"/> <segment sequence="8" instruction="Stay STRAIGHT to go onto US-101/JAMES LICK FWY (Going South)" distance="1765.10498046875"/> <segment sequence="9" instruction="Turn SLIGHT RIGHT onto RAMP (Going South)" distance="481.18505859375"/> <segment sequence="10" instruction="Turn LEFT onto BAY SHORE BLVD (Going Southeast)" distance="688.142578125"/> <segment sequence="11" instruction="Turn LEFT onto OAKDALE AVE (Going Southeast)" distance="39.44921875"/> <segment sequence="12" instruction="Turn RIGHT onto PATTERSON ST (Going Southwest)" distance="69.53564453125"/> <segment sequence="13" instruction="Turn RIGHT onto FLOWER ST (Going Northwest)" distance="36.39051818847656"/> </route> </route_response>Example C-5 shows a request for the route, with driving directions, where the start and end locations are previously geocoded locations that are about one-half mile apart in Boston, Massachusetts.

Example C-5 Route Request with Previously Geocoded Locations

<?xml version="1.0" standalone="yes"?> <route_request id="8" route_preference="shortest" road_preference="highway" return_driving_directions="true" distance_unit="mile" time_unit="minute" pre_geocoded_locations="true"> <start_location> <pre_geocoded_location id="1"> <edge_id>22161661</edge_id> <percent>.5</percent> <side>L</side> </pre_geocoded_location> </start_location> <end_location> <pre_geocoded_location id="2"> <edge_id>22104391</edge_id> <percent>.5</percent> <side>R</side> </pre_geocoded_location> </end_location> </route_request>Example C-6 shows the response to the request in Example C-5. (The output is reformatted for readability.)

Example C-6 Route Response with Previously Geocoded Locations

<?xml version="1.0" ?> <route_response> <route id="8" step_count="5" distance="0.5848966065287509" distance_unit="mile" time="1.1866167704264323" time_unit="minute"> <segment sequence="1" instruction="Start out on HUNTINGTON AVE (Going Southeast)" distance="0.005477076104790563" /> <segment sequence="2" instruction="Turn LEFT onto AVENUE OF THE ARTS/HUNTINGTON AVE/RT-9 (Going Northeast)" distance="0.006677015642704102" /> <segment sequence="3" instruction="Turn RIGHT onto PUBLIC ALLEY 405 (Going Southeast)" distance="0.05267257088346108" /> <segment sequence="4" instruction="Turn RIGHT onto ST BOTOLPH ST (Going Southwest)" distance="0.010097520017923165" /> <segment sequence="5" instruction="Turn RIGHT onto MASSACHUSETTS AVE (Going Northwest)" distance="0.5099724250650759" /> </route> </route_response>## C.2.2 Route Request DTD

The following is the complete DTD for a route request. The main elements and attributes of the DTD are explained in sections that follow.

<?xml version="1.0" encoding="UTF-8"?> <!-- geocoder.dtd includes gmlfeature.dtd. These define the ELEMENTS input_address and those in Feature, FeatureMember, and FeatureCollection that are used in geoFeature, geoFeatureCollection, and geoFeatureMember. --> <!ENTITY % GEOCODERDTD SYSTEM "geocoder.dtd"> %GEOCODERDTD; <!-- input_location element is defined in geocoder.dtd. GeometryClasses is defined in gmlgeometry.dtd. --> <!ELEMENT route_request (start_location, end_location)> <!ATTLIST route_request vendor CDATA "Oracle" id CDATA #REQUIRED route_preference (FASTEST|SHORTEST) #IMPLIED road_preference (HIGHWAY|LOCAL) #IMPLIED return_driving_directions (TRUE|FALSE) #IMPLIED return_hierarchival_driving_directions (TRUE|FALSE) #IMPLIED return_route_geometry (TRUE|FALSE) #IMPLIED return_detailed_geometries (TRUE|FALSE) #IMPLIED return_segment_geometry (TRUE|FALSE) #IMPLIED language CDATA #IMPLIED distance_unit (KM|MILE|METER) #IMPLIED time_unit (HOUR|MINUTE|SECOND) #IMPLIED> <!-- Following are alternatives for specifying the location. Use input_location when you want to represent a location with a street address. Use longitude_latitude_location when you want to specify a location by longitude and latitude coordinates. If you have already geocoded the location, you can use information from the geocoder response to construct a pre_geocoded_location element. The geocoder returns: - An edge_id (integer that is the road segment identifier) - A side ('L' or 'R' – left or right side) - A percent (floating-point number 0.0 to 1.0 representing the fraction of the length from the start of the road segment to this location. --> <!ELEMENT pre_geocoded_location (edge_id, percent, side)> <!ATTLIST pre_geocoded_location id CDATA #REQUIRED> <!ELEMENT longitude_latitude_location (longitude, latitude)> <!ELEMENT start_location (input_location|pre_geocoded_location|longitude_latitude_location)&g