Kadastrale gegevens
normaliter slechts één of enkele resul
taten teruggeven.
GIS frontend
Een belangrijk vereiste is dat de geo
grafische queiytool een open karakter
heeft, dus niet gebaseerd op een speci
fiek gegevensformaat van een GIS-leve-
rancier. Dit komt overeen met de doel
stellingen waarop het OpenGIS Con
sortium is gebaseerd [4] [11]. Echter, de
queiytool-ontwikkelingen bij het Ka
daster zijn ruim vijf jaar geleden be
gonnen, dus vóór de tijd dat OpenGIS-
standaarden en -producten beschik
baar waren. De ontwikkelingen zijn
echter gebaseerd op hetzelfde principe
en naar verwachting zal de overgang
naar OpenGIS-producten niet al te
moeilijk zijn.
Op dit moment wordt de open DBMS-
benadering door de meeste GIS-pakket-
ten nog niet ondersteund. De traditio
nele benadering gaat ervan uit dat geo
metrische gegevens moeten worden
ingelezen in het specifieke formaat
van de GIS-leverancier. GIS-pakketten
hebben vaak de mogelijkheid een ex
tern DBMS te benaderen. Gewoonlijk
betekent dit dat de geometrische infor
matie lokaal moet worden opgeslagen,
maar met behulp van een sleutel kun
nen de overeenkomstige administra
tieve gegevens in het externe DBMS
worden gevonden. Dit is niet goed ge
noeg, omdat de totale integratie van
geometrische en administratieve gege
vens gebaseerd dient te zijn op de
meest efficiënte en consistente data-
management-architectuur. Een geo
grafische querytool moet functioneren
als een ffontend naar de DBMS back
end en helpt de gebruiker vragen te
stellen door middel van een gebruiks
vriendelijke interface. De querytool ge
nereert ANSI SQL op een dynamische
manier en verwerkt de antwoorden
van het DBMS. GEO++ is een GIS-pakket
dat ontworpen is om deze taken uit te
voeren. Daarom kan GEO++ worden
omschreven als een generieke geogra
fische querytool voor relationele
DBMS's met ruimtelijke extensies [11],
De generieke geografische querytool
wordt geïllustreerd aan de hand van
voorbeelden uit een kadastraal sys
teem. Voor een beter begrip wordt het
gegevensmodel van het Nederlandse Kadaster geïntro
duceerd. De geografische datasets bestaan uit grootschalige
topografische gegevens en de kadastrale kaarten per pro
vincie van Nederland. Aan de kadastrale kaarten zijn de
administratieve gegevens gekoppeld, die ook per provincie
gerangschikt zijn, maar opgeslagen in een centraal main
frame. De relatie tussen de percelen op de kadastrale kaart
en de administratieve gegevens wordt door landelijk unie
ke kadastrale aanduidingen (perceelnummers) gelegd. De
kadastrale kaarten zijn gebaseerd op een topologisch ge
structureerd model en het manipuleren van vlak-kenmer-
ken in een dergelijk model vraagt om navigatie waarbij ge
bruikgemaakt wordt van topologie-referenties naar de
grenzen. Het is interessant op te merken dat topologie de
visualisatie versnelt in vergelijking met een representatie
zonder topologie, omdat in dit geval alle coördinaten twee
keer van het DBMS naar de applicatie worden overgebracht.
Sinds de introductie in 1997 bevatten de topografische
kaarten en de kadastrale kaarten de volledige historische
gegevens. Dit is niet het geval bij de administratieve ge
gevens.
De grootschalige topografische en kadastrale kaarten wor
den door het LKI-systeem (Landmeetkundig Kartografisch
Informatiesysteem) onderhouden. Dit systeem slaat de ge
gevens op in een Ingres DBMS, waarbij gebruikgemaakt
wordt van de OME/SOL (Object Management Extension/
Spatial Object Library) [2]. Juridische en andere aan de per
celen gerelateerde administratieve gegevens worden door
AKR (Automatisering Kadastrale Registratie) onderhouden,
waarbij de gegevens in een IDMS DBMS op een IBM-main-
frame worden opgeslagen.
Fig. 2.
Het hart van het
administratieve
gegevensmodel:
object, subject en
recht.
l l subject: natuurlijk persoon
Object j| Subject I niet-natuurlijk persoon
object: geheel perceel
recht I deelperceel
appartementsrecht
De geografische querytool beschikt over een eigen DBMS,
dat een kopie bevat van alle geometrische en administratie
ve gegevens uit de bronbestanden. Daarom is een goed be
grip van deze twee gegevensmodellen - als casestudy - van
belang. De gegevensmodellen bevatten structuren en con
cepten, die ook in veel andere toepassingen voorkomen, bij
voorbeeld metrische, topologische en landmeetkundige in
formatie (datum, nauwkeurigheid, aard van de meting) bin
nen de geometrische gegevens en hiërarchieën, nm-rela-
ties, generalisatie/specialisatiestructuren binnen de admi
nistratieve gegevens. Deze structuren en hun semantiek
zijn relatief gezien moeilijk te benaderen in een generieke
geografische querytool-omgeving. Zij dienen echter te wor
den opgenomen in een geografische querytool, die accepta
bel is voor gebruikers die bekend zijn met dit model.
Geometrisch model
Aangezien er al uitgebreid over het geometrisch model is
gepubliceerd [9] [10] [13], wordt hier volstaan met een korte
GEODESIA 2001-4
