In een GML-bestand is bij iedere geometrie te achterhalen
in welk ruimtelijk referentiesysteem de coördinaten be
schreven zijn. Dit gebeurt door te verwijzen naar de code
die het referentiestelsel heeft in de EPSG-database
(www.epsg.org/Geodetic.html). Omdat alle coördinaten
binnen TOPIONL alleen een X- en een Y-coördinaat hebben,
wordt het EPSG-coördinaat referentiesysteem met de code
28992 gebruikt waarin de RD-coördinaten in meters wor
den uitgedrukt. Voor RD+NAP is nog geen EPSG-code be
schikbaar: EPSG-code 7408 is hiervoor niet geschikt, omdat
in dit referentiesysteem de coördinaten in lengte- en breed
tegraden worden uitgedrukt, en niet in meters. Momenteel
worden alle hoogtes binnen TOPIONL als los attribuut door
gegeven.
Door de tijd heen ontstaan objecten, veranderen ze en ver
dwijnen ze weer. Als een object verandert (bijvoorbeeld de
wijziging van een attribuut) ontstaat er een nieuwe versie
van dat object. Bij levering wordt een nieuwe versie van dat
object geleverd. De attributen versieBeginTijd en versie
EindTijd van de verschillende versies geven aan in welke pe
riode welke versie van het object geldig is.
Zolang een object nog actueel is, is de objectEindTijd van dat
object niet ingevuld. Zodra het object niet meer bestaat
wordt een versie van dat object geleverd waarin de object
EindTijd is ingevuld. Dit betekent in feite dat het object ver-
Fig. 2. De TOPI ONL
wijderd kan worden. Soms verandert een object zo ingrij- lijst voor TypeLand-
pend dat er eigenlijk sprake is van een nieuw object. Voor
TOPIONL zijn exacte regels beschreven wanneer dit het ge
val is. In dit geval zal het oude object verwijderd en een
nieuw object opgevoerd worden. Door bij het nieuwe object
de relatie 'ontstaanUit' in te vullen, lean verwezen worden
uit welke objecten het nieuwe object ontstaan is. Bij lever
ing in GML kan handig gebruik gemaakt worden van deze
temporele attributen: de meest voor de hand liggende vorm
is een momentopname op een bepaald tijdstip. Uit de data
base worden de dan geldende objecten geselecteerd op basis
van de obj ectBegintij d en objectEindtijd. De tweede moge
lijkheid is een 'was-wordt'-levering over een bepaalde perio
de. Alleen de vervallen en nieuwe objecten (geselecteerd op
basis van hun temporele attributen) worden in de levering
meegenomen en omgezet naar GML. Bij deze leveringsvorm
speelt ook de vraag of eventuele tussenversies van objecten
geleverd moeten worden. (Deze zijn te achterhalen via de
temporele attributen op versieniveau.) De laatste smaak is
een totaallevering over een hele periode, dat wil zeggen: alle
objecten die aan het begin van de periode bestonden, aange
vuld met alle in de periode vervallen en nieuwe objecten (in
clusief de eventuele tussenversies). Hoewel er dus drie (of
zelfs vier) smaken van levering te onderkennen zijn, passen
deze allemaal in hetzelfde GML TOPIONL-Schema, en hier
voor hoeven dus geen schema/model varianten ontwikkeld
te worden. TDKadaster onderzoekt aan welke vormen van le
veringen de meeste behoefte is. Dit zal zeker de traditionele
levering van een momentopname zijn maar, zeer waar
schijnlijk (met de meer continue bijhouding van de gege
vens), zal er ook een 'was-wordt'-product komen.
gebruik is een
uitbreiding van
die van NEN3610.
Voor veel attributen wordt binnen
TOPIONL gebruikt gemaakt van lijsten
met mogelijke waardes. Voor een
groot deel zijn deze lijsten gebaseerd
op de lijsten zoals gepubliceerd in de
NEN3610:2005. In deze nationale
norm zijn alleen waardes opgenomen
die algemeen geldend zijn voor meer
dere sectoren binnen Nederland.
Binnen het sectormodel (TOPIONL)
kunnen deze lijsten uitgebreid wor
den met de voor die sector specifieke
waardes. Deze mogen echter niet in
tegenspraak zijn met al bestaande
waardes. Zie bijvoorbeeld de lijsten
voor TypeLandgebruilc van NEN3610:
2005 en TOPIONL in fig. 2. In een GML-
document bestaat de mogelijkheid bij
iedere waarde te vertellen wie verant
woordelijk is voor de definitie van die
waarde. Dit gebeurt door aan een attri
buut een CodeSpace toe te voegen. Zo
zal het typeLandgebruilc van een ter
rein er zo uitzien in GML:
<toplOnl TypeLandgebruilc
codeSpace="http://www.ravi.nl/nen36
10">heide</topl0nl:typeLandgebruilc>
-5 nu mural mi»
TypaLorrdtfibfiik
LfMfttaiJft
«gnfetec*
hos
tafi tul
ha Mi
Aan de NEN3610 codeSpace is nu me
teen te zien dat hier heide, zoals gede
finieerd door NEN3610:2005, wordt be
doeld terwijl een als volgt gecodeerde
fruitkwelcerij van TOPIONL is:
<toplOnl TypeLandgebruilc
codeSpace="http://www.tdlcadaster.nl/
top 10 nl>frui tlcwelcerij top 1 Onltype
Landgebruilc>
Oolc is het mogelijk in de codeSpace
rechtstreeks te verwijzen naar de defi
nitie van een begrip. Je kunt een GML-
document maken met begripsdefini-
ito*»
itfjcLaitijrtiiufti
baaaflihtÉBB, s^ffitfralnu
bwrnliwfciit
b ta jyiiMri
hi>s: hr.rt-15
■tadtfurtar
düdHlEAiMf
fiiri|cwFfc-ufc
hrida
arijdaartf
ITPlrifl
jpacrtiurtkaaim
zni'J
GEO-INFO 2005-11
«•y-tihnj
IMST
l-n j nznlrl'
-Pm tiii'1:
.1 nn I-ui?
lu-ifiH/iJI-l
Imi
M riariiFini
Inn (pt4Tïif|
til I J
n> i m a
mfciir
Ruimtelijke Referentiestelsels en 3D
Volgen van objecten door de tijd en was-
wordt leveringen
Coderingen