relatie 'is onderdeel van' en in an
dere gevallen 'is een instantie van'.
Helaas is dit nooit aangegeven en
vaak lastig te achterhalen.
van de (beschikbare) attributenlijs-
ten is ook niet duidelijk op welk
niveau deze moeten worden gekop
peld aan objecten. Ook deze ondui
delijkheid kan uiteraard niet wor
den vertaald naar het UML-model.
Een ander knelpunt blijkt in deze
fase juist minder ingewikkeld dan
verwacht: de aansluiting van de Pro
Rail-objectenstructuur op NEN3610.
Het 'spoorse' gedeelte van NEN3610 is
namelijk dermate algemeen van opzet
dat zonder al te veel moeite een oplos
sing wordt gevonden (fig. 1).
Voor het vastleggen van de UML, wordt
gebruik gemaakt van het softwarepak
ket Enterprise Architect. Dit pakket is
voldoende gebruiksvriendelijk en be
schikt bovendien over de mogelijkheid
om de UML te exporteren naar een
formaat dat kan worden omgezet naar
een GML-schema.
Na export van het UML-gegevensmodel naar GML kan wor
den begonnen met de ontwikkeling van het exportscript.
Tijdens de ontwikkeling van dit script lcomen nog enkele
knelpunten naar voren die hoofdzakelijk te maken hebben
met de onbekendheid van de projectmedewerkers met XML-
syntax.
Omdat GML tekst-gebaseerd is, zijn de opties voor de te kie
zen scripttaal of exportsoftware feitelijk oneindig. Binnen
de organisatie is echter het pakket FME beschikbaar dat spe
cifiek voor dit doel is gemaakt. De keuze is daarom snel ge
maakt 0111 met deze software te gaan experimenteren. Met
succes, zo blijkt al snel.
De FME-conversiesoftware beschikt over de mogelijkheid
om databasetabellen te 'mappen' op velden van een zelf
te bepalen GML-schema. Dit mappen gebeurt in een grafi
sche omgeving waardoor het converteren zelf hoofdzake
lijk een kwestie van 'point click' is. Ook in deze fase van
het pilotproject lcomen echter de nodige knelpunten bo
ven. Ook nu weer moeten ze hoofdzakelijk worden gevat
onder de noemer 'kennisontwikkeling'. En ook nu weer
blijkt het doorzettingsvermogen van de pilotmedewerkers
te zegevieren, ditmaal over gecompliceerde XML-syntax-
lcwesties.
Problemen met syntax komen gelukkig snel naar voren zodra
XML gevalideerd wordt: met verschillende online- en offline-
tools lean worden gecontroleerd of de XML-data en het XML-
schema consistent zijn.
Nadat het gegevensmodel bekend is,
wordt gestart met het inrichten van
een Spatial database. Gelukkig staat de
pilot er ook op dit vlak niet alleen voor.
Op het moment dat de GML-pilot van
start gaat, is er tevens een ander pro
ject waarop kan worden aangesloten:
'De Objectgerichte Basisbeheerkaart'.
Dit project werkt aan een Spatial da
tabase met daarin een objectgerichte
gegevensstructuur gevuld met basis
objecten van de spoorinfrastructuur.
Deze gegevens worden door het pro
ject geconverteerd vanuit bestaande
CAD-bestanden.
Na een kort onderzoek wordt beslo
ten dat deze Spatial database over vol-
XML-standaard
GML-schema
doende mogelijkheden beschikt om, naast de 'basisobjec
ten', ook ingericht te worden voor het meer omvangrijke
gegevensmodel dat de pilot heeft ontwikkeld. Uiteraard
wordt hiervoor een aparte omgeving binnen de database
ingericht.
Vervolgens wordt de testdatabase gevuld met fictieve gege
vens: een paar honderd meter spoor in een mooie boog.
Voor de ontwikkeling van het GML-schema wordt gebruik ge
maakt van het open source Java-programma 'ShapeChange'
(kader) dat tijdens de pilot beschikbaar is
in versie 0.3. Vanuit de UML-ont-
werpsoftware kan een bestand
worden geëxporteerd (voor
de liefhebbers: een XML-
bestand van het UML-
ontwerp) dat Shape
Change 'begrijpt' en
kan converteren naar
een GML-schema.
Fig. 2. Samenhang
tussen XML, GML en
de Prorail-implemen
tatie.
Bij de ontwikkeling van
het schema is een belang
rijk uitgangspunt dat zoveel
mogelijk van bestaande standaar
den wordt uitgegaan. Zo kan dus al
worden begonnen met het standaard GML-schema. Voor het
inrichten van de infrastructuur lean ook gekeken worden
naar NEN3610.
Stap 4: ontwikkeling GML-exportscript
Stap 2: inrichten van de database
Stap 3: ontwikkelen van het GML-schema
GEO-INFO 2007-7/8
