de opdeling in kaartbladen staat de ontwikkeling van een
objectgericht basisbestand in de weg. Immers, objecten
houden niet op bij de scheiding tussen twee kaartbladen.
Daarnaast zijn nog de volgende opmerkingen te maken:
Gemeentewerken Rotterdam heeft in het bestek [2] de
volgende eis gesteld:
"Men moet altijd in staat zijn om op elk gewenst moment de
gegevens vanuit de basisregistratie aan bet Distributieknoop
punt te kunnen leveren. Hiervoor geldt dat het te leveren ge
bied een consistent beeld moet zijn. Er mag geen informatie
weggevallen zijn omdat dit in bewerking is. Wanneer er een
verwerkingsproces op het te leveren gebied uitgevoerd wordt
dan behoort de 'oude' situatie geleverd te worden en niet de in
bewerking zijnde gegevens". Dit betekent dus dat als een
operator een gebied aan het bijwerken is, dit gebied pas
wordt vrijgegeven als de wijzigingen allemaal zijn uitge
voerd. Zolang dat niet is gebeurd, wordt enkel de oude
situatie geleverd.
In Rotterdam wordt een Verzamelkaart Leidingen bijge
houden. Dit bestand wordt opgeslagen in een relationele
database en bevat van elke leiding in Rotterdam een aantal
specifieke kenmerken. De structuur van deze database is in
vereenvoudigde vorm weergegeven in fig. 1 [5]. Nu is door
een klant de vraag gesteld: wat is de totale lengte van alle
Shell-leidingen in het havengebied van Rotterdam tezamen?
Deze vraag is te beantwoorden, maar op een zeer omslach
tige en ingewikkelde wijze. Er dient een uitgebreide query te
worden ontworpen, die gebruikmaakt van zes tabellen.
Hiervoor is een specialist nodig. Indien hij in staat is om een
juiste query te ontwerpen, moet hij ook nog veel geduld
hebben voordat hij het antwoord krijgt.
Beheerders van geometrische databases vinden het een be
perking dat men afhankelijk is van de leverancier van soft
warepakketten om bij de zo belangrijke basisgegevens te
kunnen. Men heeft altijd een bepaalde applicatie nodig om
de gegevens te kunnen raadplegen of te muteren. Zo is het
voor een gebruiker van AutoCAD niet mogelijk om Micro-
Station-bestanden zonder conversie te bekijken. De enige
mogelijkheid is een conversie van een MicroStation-
designfile naar AutoCAD-dwg file. Deze conversie kost tijd
en kan verlies van data betekenen. Daarnaast zal de con
versie telkens opnieuw moeten gebeuren als de brongege-
vens wijzigen. Zo heeft dg DIALOG Topografie ongeveer
twintig bestandsformaten waarnaartoe gegevens kunnen
worden geconverteerd.
Bovenstaande opmerkingen zijn al langer bekend en zijn
voor een groot deel ook al opgelost door geometrische ge
gevens op te slaan in relationele databases. Zo was ook de
situatie bij Gemeentewerken Rotterdam. De complete ba-
Fig. 1.
Relationele data
base met ruimte
lijke objecten (zie
het kader hier
naast).
TRS track-
section (leidingen-
geometrie).
GGO generiek
grafisch object.
Fig. 2.
Op verkenning
in het archief.
sisregistratie is opgeslagen in een Ora
cle 6 database met een omvang van 2.5
gigabyte. Deze relationele database is
bladrand-onafhankelijk en is met alge
meen geaccepteerde software te bena
deren (bijvoorbeeld SQL). Het grote
knelpunt van opslag van geometrie in
een relationele database is de perfor
mance. De omvang van een topogra
fisch basisbestand van een gemiddelde
gemeente of provincie is vele malen
groter dan welke administratieve data
base in diezelfde organisatie dan ook.
Denk hierbij maar eens aan de verhou
ding tussen het aantal inwoners en het
aantal unieke coördinaten in het topo
grafisch basisbestand. Zo zijn er in
Rotterdam 1,7 miljoen objecten en
7,7 miljoen punten. Daarnaast is een
relationele database niet geschikt om
bevragingen met een ruimtelijk karak
ter toe te passen. Daar moet door een
ondersteunende applicatie een speci
fieke code voor worden geprogram
meerd.
452
2000-10
GEODESIA
Continue raadpleegbaarheid
Relationele database met ruimtelijke objecten
Gesloten dataformaten
Relationele databases
KRN TSPI KRN GIT I KRN DIP
KRNPIT rn KRN_TRS
KRN LCK OBJ
KRN UIP I KRN UIT
ggo_txt||ggo_str|
GGO PMK
GGO EST!GGO PST
GGOS1DI GGO GR
|^js^_typeJ jusR_SPiNFoj |su^txt||priv_^jerJ RDAM
