Codering van een polyhedron
Literatuur
De polyhedron wordt gedefinieerd met sdo_gtype d008
(d=3 voor 3D of d=4 voor 4D). (In analogie met het 2D-
model wordt de multigeometrie variant gecodeerd met
sdo_gtype=d009. Deze wordt hier verder buiten beschou
wing gelaten).
De meer gedetailleerde codering van het polyhedron
wordt gerealiseerd door de elementtypen sdo_etype. Het
voorstel is om sdo_etype=xxx6 te gebruiken voor een
grenselement, xxx=100 kan daarbij gebruikt worden voor
een buitenring van een buitenvlak en xxx=200 voor de bui
tenring van een binnenvlak (voorbeeld 5d).
De binnenringen van buitenvlakken (voorbeeld 5c) code
ren we met etype=1106. Binnenringen van binnenvlakken
worden op dezelfde wijze gecodeerd met etype=2106.
De sdo_interpretationcode vertelt nu hoe de coördinaten
in de coördinatenlijst geïnterpreteerd moeten worden.
Voor de polyhedron stellen we de volgende sdo_interpre-
tation codes voor: 3 voor 3D-blokken (vergelijk met de
rechthoek in 2D), en 1 voor polyhedrons met platte vlak
ken (vergelijk met de polygoon met rechte lijnsegmenten
in 2D). De voorgestelde nummers voor gtype, etype en de
interpretatiecode zien er misschien wat vreemd uit, maar
deze zijn in analogie met het geometriemodel in 2D, waar
bij we de bolvormige en cilindrische delen voor dit mo
ment overslaan.
Het vullen van de coördinatenlijst (sdo_ordinate_array) is
niet triviaal. Om te voorkomen dat coördinaten van twee
aangrenzende vlakken dubbel worden genoemd, begint
de lijst eerst met het noemen van alle voorkomende coör
dinaten, die impliciet genummerd zijn van 1 tot N. Het
startpunt van elk vlak is gegeven in de sdo_elem_info_ar-
ray. Een vlak wordt gespecificeerd door het noemen van
alle puntnummers. Deze codering zorgt voor een interne
topologie van de 3D-primitieve.
Nu het meest eenvoudige voorbeeld van fig. 5a: de tetrahe
dron met de volgende vier coördinaten: 1=(0,0,0), 2=(1,0,0),
3=(0,1,0) en 4=(0,0,1):
insert into geom3d (shape, TAG) values
mdsysSD0_GE0METRY(3008NULL, NULL,
-- polyhedron, zonder ref. point en srid
mdsysSD0_ELEM_INE0_ARRAY 13,1006,1
- - eerste platte vlak begint op offset 13,
- - eerste 13 posities zijn gebruikt voor de coördinaten
16,1006,1, 19,1006,1, 22,1006,1),
- - de ander vlakken op 16,19 en 33
mdsysSD0_0RDINATE_ARRAY (0,0,0,
- - coördinaat triplet van punt 1
1,0,0, 0,1,0, 0,0,1, -- en van punt 2,3 en 4
1,2,3, 1,2,4, 1,3,4, 2,3,4)),
- - de vlakken referenties naar de punten
1- - TAG van voorbeeld 1
De coördinaten van het blok in fig. 5b zijn: 1=(0,0,0),
2=(5,0,0), 3=(5,5,0), 4=(0,5,0), 5=(0,0,5), 6=(5,0,5), 7=(5,5,5) en
8=(0,5,5). Het coderen in Oracle ziet er als volgt uit:
insert into geom3d (shape, TAG) values
mdsys.SDO_GEOMETRY(3008, NULL, NULL,
mdsysSD0_ELEM_INE0_ARRAY (251006,1
- eerste vlak op offset 25
29,1006,1, 33,1006,1, 37,1006,1, 41,1006,1,
45,1006,1),
mdsysSD0_0RDINATE_ARRAY (0,0,0,
- - coördinaten triplet van punt 1
5,0,0, 5,5,0, 0,5,0, 0,0,5, 5,0,5, 5,5,5, 0,5,5,
1.2.3.4, 5,6,7,8,4,3,7,8,
- - onder, boven, rechter vlak
1.2.6.5, 1,4,8,5, 2,3,7,6)),
- - linker, achter en voor vlak
vestigde rechten (en beperkingen en belemmeringen) die
kenbaar zijn uit de Openbare Registers en de kadastrale re
gistratie te visualiseren. In dit artikel hebben we beschre
ven hoe beschikbare geo-informatie in 2D gecombineerd
lean worden met 3D geo-informatie om aan deze informa
tiebehoefte te voldoen. We hebben ook een uitbreiding van
het huidige geometrische datamodel in DBMSs voorgesteld
om de ondersteuning van 3D volume-objecten mogelijk te
maken. Volledig 3D-support in DBMSs zal echter nog wel
even op zich laten wachten. In de tussentijd zijn we bezig
om binnen de huidige technieken de mogelijkheid te im
plementeren om 3D geo-objecten te beheren in het DBMS
en deze te combineren met de bestaande 2D-data (de perce
len). Op deze manier kunnen verschillende vragen worden
beantwoord en gevisualiseerd: 'tot welke hoogte en diepte
geldt het opstalrecht op dit perceel', 'wordt de ondergrond
van dit perceel ook doorsneden door de pijpleiding', 'welke
percelen zijn belast met een beperking in het recht van
eigendom ten gevolge van een tunnel' en 'hoe is deze be
perking gedefinieerd in 3D' worden beantwoord en gevisu
aliseerd. Dit alles moet op termijn voor een meer duurzame
oplossing zorgen in een wereld met een toenemende druk
op het ruimtegebruik. De registratie
wordt eenvoudiger en eenduidiger,
maar ook meer toegankelijk en in
zichtelijk omdat deze beter aansluit
bij de werkelijkheid.
[1] Stoter, J. E., M.A. Salzmann, P.J.M.
van Oosterom en P. van der Molen,
Op naar een 3D-Kadaster? Registratie
van multi-functioneel ruimtegebruik.
Geodesia 2002 no. 3, p. 88-93.
[2] OGC, OpenGIS Simple Features Specifi
cation for SQL. Revision 1.1. OpenGIS
Project Document 99-049.
[3] Oracle, Oracle Spatial User's Guide
and Reference Release 9.0.1 Part
Number A88805-01. Juni 2001.
GEODESIA 2002-7/8
