ons huidige prototype worden de gren
zen benaderd via hun 'object_id',
waarop een b-tree index is gedefi
nieerd. Voor snelle toegang tot om
vangrijke hoeveelheden gegevens in
de grenzen tabel ('lki_boundaiy') moet
deze laatste ook ruimtelijk worden ge
clusterd, omdat bij het creëren van
een polygoon de bijbehorende grenzen
ruimtelijk sterk gerelateerd zijn. Een
ruimtelijke index is niet noodzakelijk
voor dit doel, omdat de grenzen op ba
sis van hun 'object_id' worden ontslo
ten. Indien echter de grenzen ook
ruimtelijk worden geselecteerd, bij
voorbeeld door middel van een recht
hoek overlap query, dan is een ruimte
lijke index, een r-tree, wel nuttig en dit
is in het prototype dan ook zo gedaan.
De hierboven gedefinieerde functie
'return_polygon' kan nu als volgt wor
den gebruikt om een view te defi
niëren:
create view lki_parcel_pgn_vw as
select municip, osection, parcel,
oarea,
return_polygon(object_id) shape
from lki_parcel;
Fig. 4 toont een voorbeeld van het ge
bruik van deze functie om topologi
sche data te visualiseren in een viewer
die niets van dit topologische model
weet (Quick GIS van Wilko Quak). Zo
als eerder aangegeven zijn op dit mo
ment de tabel- en attribuutnamen nog
hard gecodeerd in de functie 'return_
polygon'. Men zou zich overigens kun
nen afvragen wat de rol is van de
'from'-clausule in deze situatie, behal
ve het geldig maken van het SQL-state
ment. Het antwoord is dat de 'from'-
clausule feitelijk zorgt voor de iteratie
over de 'object_id's' uit de 'lki_parcel'-
tabel.
Een functie-gebaseerde ruimtelijke in
dex is gecreëerd om voor optimale per
formance van deze view te zorgen in
geval van ruimtelijke selectie. Sinds
versie 9i zijn in Oracle functie-geba
seerde indexen beschikbaar, dat wil
zeggen een index die wordt gecreëerd
op de resultaatwaarde van een functie.
Dit in tegenstelling tot een normale in
dex, die op een vast attribuut wordt ge
definieerd. In dit geval wordt dus de
ruimtelijke index gecreëerd op basis
van de voorberekende resultaatwaar-
'my
metrie. Dit hangt dan weer af van het soort topologie. Het
standaardiseren van de topologie-structuur-informatie
maakt het mogelijk 0111 de functionaliteit (binnen een
DBMS) te implementeren. Er zijn verschillende soorten
topologische functionaliteit die gerealiseerd zouden moe
ten worden. In eerste instantie zullen we ons concentreren
op de 'brug' tussen topologie en geometrie door het im
plementeren van een functie die geometrische primitieven
realiseert (materialiseert) op basis van topologische primi
tieven en de bijbehorende structuur.
Fig. 3.
Hoofdkantoor
Oracle in Redwood
Shores nabij San
Francisco (foto
Pieter Meijer,
RWS/MD).
Implementatie in Oracle 9i
Het Oracle 9i spatial DBMS zal worden gebruikt om het
topologie structuurmanagement voorstel uit te proberen.
Er zal worden beschreven hoe het relationele model is uit
gebreid (PL/SQL, stored procedures) om topologische struc
turen te ondersteunen. De interface is op dit moment hard
gecodeerd (vaste tabel- en attribuutnamen) in de volgende
PL/SQL-functie, die een topologische primitieve omzet naar
een geometrische primitieve:
CREATE OR REPLACE FUNCTION returnjpolygon
(i_object_id kadtest.lki_parcel.object_id%type)
RETURN mdsys.sdo_geometry
IS
body of the function
polygon:=mdsys.sdo_geometry(2003, NULL, NULL,
mdsysSDO_ELEM_INFO_ARRAY 11003,1
list_coordinates);
return polygon;
END return_polygon;
Deze functie gebruikt de tabel 'lkijxmndary' om de coördi
naten te verkrijgen die nodig zijn voor het realiseren van de
polygoon die hoort bij het face in de Tki_parcel'-tabel. In
GEODESIA 2003-2
