In Emmen werd op 26 januari 2006 de 4e GML-estafette gehouden, en ik was er bij en keek ernaar. Een half dozijn softwareleveranciers uit de GIS-wereld kwamen er bijeen om te testen of zij onderling gegevens konden uitwisselen op basis van GML, en het TOP10NL/GML-schema. Mijn conclusie: men heeft het technisch voor elkaar om gegevens uit te wisselen, maar de gebruiksvriendelijkheid van de software op dit punt laat te wensen over.

Wat is een GML-estafette?
GML (Geography Markup Language) is een afgeleide van XML (WikiPedia) met als doel het opslaan en vooral uitwisselen van geografische informatie. De GML-estafette lijkt op het “fluister een geheim-spelletje” dat je vast wel eens op de lagere school gespeeld hebt. Fluister een geheim door aan je buurman – herhaal 20 keer – en vergelijk het eindresultaat met waar je mee begonnen bent. Lachen geblazen.

De GML-estafette gaat als volgt:

• De organisatie heeft een GML-bestand ontworpen over een bepaald onderwerp.
• Dit bestand wordt één voor één in de softwarepakketten van alle deelnemende bedrijven ingeladen – bekeken – een beetje veranderd en vervolgens weer opgeslagen.
• De uitkomst van het ene bedrijf is weer de input voor het volgende bedrijf. Wanneer GML-interpretaties verschillen, kan de output van softwarepakket A niet leesbaar zijn voor softwarepakket B, of verkeerd worden geïnterpreteerd.

Ga naar de site van de organisatie: GDMC. De volledige resultaten qua GML-bestanden vind je hier.

De grote vragen zijn dus:

• Kunnen de leveranciers elkaars output lezen?
• Wat blijft er aan het einde over?
• Komen we de dag door zonder error, software crashes en blue screens of death?

 De eerste drie GML-estafettes zijn niet succesvol geëindigd, dus het is een klein beetje spannend. Het afgelopen jaar zijn echter een aantal aanvullende standaards ontwikkeld: Top10NL als GML-schema en een nieuwe NEN3610, waardoor de verwachtingen hooggespannen zijn.

Welke bedrijven nemen eraan deel?

• AutoCad
• Bentley
• CadCorp
• ESRI
• Intergraph
• Ionic
• Snowflake

Het verslag

Na 2 uur rijden kom ik, zonder de verwachtte files, aan in het verre en koude Emmen. TomTom Navigator heeft me wederom zonder problemen precies bij mijn bestemming afgeleverd: De topografische dienst van het Kadaster te Emmen. Ik ben hier om de 4e jaarlijkse “GML-relay” bij te wonen.Het gebouw lijkt wel erg groot te zijn voor zo’n lokaal kadaster. Hoeveel mensen werken hier eigenlijk? 

9:30
Eenmaal binnengekomen eerst koffie en een plakje cake – da’s dan weer niet erg innovatief. Hopelijk wordt het nog beter vandaag.

9:40
De eerste ProRail-collegae komen binnen. We praten kort over Rijkswaterstaat. T. raadt me het blad Geonieuws aan en een RWS-casus daarin.. B, die ik al eerder een vrij saaie lezing over metadata zag geven, loopt even bij de tafel langs en zegt dat het “erg leuk gaat worden “. Hij was gister bij de voorbereidingen betrokken. Ik vraag me af hoe "leuk" iets als een GML-estafette eigenlijk kan zijn - maar ik zet me voor de zekerheid alvast schrap...

10:30
We beginnen. Er blijken een aantal buitenlanders in de zaal te zijn (deelnemers aan de estafette), waardoor men heeft gekozen de hele dag koud, gevoelloos steenkolen Engels te praten. Er wordt een volgorde getrokken waarin de bedrijven deel gaan nemen aan de estafette.

10:50
Ene Nico Bakker vertelt vervolgens van alles over TOP10NL en hoe men bij het kadaster is gemigreerd van CAD- en kaartgebaseerd werken, naar Unieke objecten en een Seamless Database. De naam FME Software wordt meerdere malen genoemd. Het coolste is een foto van een kerel die met een stereobril achter een speciaal scherm zit om in 3D objecten in de database te bewerken. Meer over TOP10NL lees je hier. Verder veel en ingewikkelde informatie over gebruikte standaarden, software-architectuur, databases en ik moet helaas afhaken.

11: 20
De eerste deelnemer: Ionic ontvangt de stick met het bestand. Live op het presentatiescherm haalt hij het bestand van de gegeugenstick. Het Top10NL-schema staat al op z’n PC. Nu luisteren we naar nog moeilijker verstaanbaar Engels, dit keer met een Frans accent. Het GML-bestand wordt ingeladen in een GML-plugin (de “GML Transactional Provider”).

Dit gebeurt door het toevoegen van de bestandsnamen van het GML-bestand en het schema in een bestand met code. Dit zal de plug-in zijn, waarvoor dus nog geen gebruiksinterface beschikbaar is. Er wordt iets gestart, een DOS command box verschijnt op de achtergrond. Een ander scherm wordt geopend, er komt wat XML voorbij. Weer een ander programma “Style Editor” wordt geopend, die weer contact maakt met de “feature server”.

11.32
Ik sta op het punt om wederom af te haken, en begin me af te vragen of ik hier wel op m'n plek zit. Gelukkig zie ik om me heen dat ik niet de enige ben. Het programma Style Editor heb ik nu al vijf keer zien starten. Eindelijk nu een plaatje: een kaartje van een deel van de kadastergegevens. Nu wordt er nog een programma opgestart “XML request”. Ik ben de draad kwijt. Deze meneer gaat een gebouw verwijderen uit de kaart, door de feature ID te onthouden en in een ander programma in te voeren. Daarna zal hij weer een nieuw gebouw toevoegen.

11:35
In een ander programma zien we nu een ander soort kaartje, maar het is dezelfde info op een andere manier weergegeven. Via een ingewikkeld proces wordt nu een gebouw weggehaald en een nieuwe toegevoegd. De meneer achter de microfoon verklapt dat hij een en ander al heeft voorbereid. De lettertjes zijn wat klein op het presentatiescherm, maar het lijkt erop dat hij het handmatig in de XML wijzigingen aan brengt. Vaag.

11:45
Via een nieuwe serie ingewikkelde handelingen, is deze meneer er in geslaagd zijn gewijzigde XML-bestand op te slaan en klaar te zetten voor de volgende deelenemer. De uitkomst van de eerste deelnemer wordt gevalideerd met XML-spy. De MC meldt ons zachtjes dat ze iets in het XML-bestand moeten veranderen omdat de eerste deelnemer een attribute-value heeft gebruikt die niet is toegestaan. Geen idee waarom de software van Ionic dat toestond…het schema is toch duidelijk?

11:50
Bentley begint. Het bestand moet eerst worden ingeladen in Microstation, en daarvoor gebruikt men FME voor conversie naar een Microstation Design File – de GML wordt dus niet Native bewerkt zoals bij de vorige deelnemer (60 seconden). We zien een opdrachtscherm de verwerking uitvoeren. Vervolgens wordt Microstation gestart om het bestand te bekijken. Er verschijnt een error box. “oops, wait a second”.

11:55
Microstation wordt opnieuw opgestart (V8, Geographics). Wordt het toch nog spannend? Nee, dit keer gaat het wel goed. We zien de kaart, met het door Ionic verwijderde, en weer toegevoegde gebouw. “Let’s do something a little more advanced”, exclameert deze meneer, en hij haalt even een paar rasterfiles op als achtergrond: de lokatie klopt want het kaartje past er precies op: we zijn in Rotterdam. Hij plaatst een nieuwe fabriek door met de hand een paar hoeken te plaatsen, en kopieert de features van een ander fabrieksgebouw. Hij wil een nieuwe status toevoegen “in aanleg” maar weet niet of dat is toegestaan binnen het schema. ( Waarom is het schema geen onderdeel van de edit-regels? )

12:00
Sneller dan de voorganger wordt het bestand nu weer via FME geëxporteerd. Dit kost ongeveer 40 seconden.

12:02
M’n euforie over de snelheid van de verwerking slaat om in teleurstelling zodra ik begrijp dat de Bentley-meneer zijn tijdwinst wil gebruiken voor een Powerpoint over de visie van Bentley! Bwraaah. Wel cool: Microstation kan exporteren naar KML – ook een XML subset die gebruikt wordt door Google Earth. Zo kun je je gegevens bekijken op een Google Earth Map.

12:15
Blijkbaar is de validatie dit keer goed gegaan, want zonder verdere berichten begint nu ESRI. Hun pakket heet ArcGis. “we have done zero modifications to ESRI software”, zegt een net iets te glad verkoperstype die een praatje houdt terwijl een ontwikkelaar de software klaar zet. Ook zegt hij: “Interesting discussion: who needs GML when you have KML?”. Bestanden worden na een paar minuten ingeladen, en moeten geconverteerd worden naar het Native ArcGis-formaat. Ook hier geen native bewerking. Ik hoor een ingewikkeld verhaal over éénmalig editen van feature-classes waarvan ik niet begrijp.

12.20
We zien het kaartje met de nieuwe gebouwen.. Er wordt een nieuw gebouw toegevoegd, waarvoor een ID nodig is “kan iemand vertellen hoe een ID eruit ziet?”. De verkoper legt uit dat de reden voor deze vraag is dat men “zero modifications” als uitgangspunt heeft genomen. Het is eenvoudig het schema in te lezen als edit regels, met drop-down boxes et cetera. Als ik hem was had ik dat ook gedaan – en ik vermoed dat er een andere reden is om dat niet te doen. Het toevoegen van features is hier wat ingewikkelder.

12.25
Het bestand wordt weer teruggeconverteerd. Snel klaar, maar ook ESRI vult de tijdwinst helaas ook aan met verkooppraatjes. Validatie levert in dit geval een probleem op met een datum/tijd-notatie. Het wordt met de hand aangepast. Toch weer een vreemde zaak om dit niet bij de export te valideren.

12:30
Lunch. Lekkere broodjes en gelukkig niet al te zakelijke gesprekken.

13.30
We gaan weer verder. Wilco Quak van de TU Delft ontwikkelde mee aan NEN3610 en begint met vertellen over GML, NEN3610, UML en Top10NL. Een interessant en redelijk te volgen verhaal, maar helaas teveel om op te noemen.
Nen3610 specifications

• Nationwide unique identifiers
• Temporal model useful for change only updates
• Fully described in UML
• GML application schema is automatically derived from the UML model
• The model is not complete by itself; it is a starting point for sectors that should make a sector model (such as Top10NL)
• One base class “GeoObject’ and about a dozen subclasses GML -> GML schema NEN3610 -> Sector Model Temporal attributes can be used for incremental updates Almost all attributes are optional Subclasses Road Water Railroad Terrain – area with specific landuse Building Construction – bridges Et cetera

Je maakt een sector model door de “most applicable class” in NEN3610 te pakken en uit te breiden. Om een UML-schema om te zetten naar GML gebruikt Quak het Java Programma Shape Change.

Extension by subclass is beter dan extension bij pattern. Extension bij subclass: consequences for xml schema: Resulting gml lives in two namespaces: nen3610 en Top10NL. Sector model includes the definition of the base model and only describes the changes Automatic translation from uml is tricky. Nen3610 is omgezet naar GML als nen3610.xsd GML: no support for multi-lingual names! (wilco added “nl” attribute to encode language of geographic names)

14.05
Cadcorp gaat beginnen aan de conversie met hun product “mapmodeller”. Importeert het door de vorige deelnemer opgeleverde bestand (inclusief de wijzigen). Met een parser wordt het bestand ook gevalideerd op GML. Sneller dan de andere deelnemers, zie we hier een kaartje – maar zonder stijlen. Alles ziet er kaler uit en de wegen zijn verdwenen. We zien wel de toegevoegde huisjes. Er wordt een nieuw huisje toegevoegd, de attributes worden automatisch overgenomen van een ander huisje.

Ook cadcorp maakt gebruik van hun standaard omgeving, dus geen handige customizing. De aanmaakdatum en tijd worden wel automatisch toegevoegd. Om de styling nog eens goed te bekijken, wordt het bestand nogmaals ingeladen. Er is echter een probleem met de namen van styles, waardoor een en ander niet helemaal goed werkt.

14.10
Alweer klaar, tijd voor verkooppraatjes. Opzoeken: Open Geospatial Consortium (OGC) Gratis product: map browser via website te downloaden “We are file format whores.” Een grote lijst importeerbare en exporteerbare file-formats. “We don’t use FME”. Een CEO die nogal Engeland gericht is. Wel een techie. “I don’t think these files will be edited”. Hmmmm.

14.35
De validatie is weer zonder problemen verlopen. Nu is Snowflake aan de beurt, opnieuw een Engels bedrijf. Deze meneer begint met uitleggen dat hij vier softwareproducten gebruikt. Het GML-bestand wordt eerst geconverteerd naar een Oracle Database, Bewerkt met een product dat heet Map Info, en weer geëxporteerd. De importer geeft voor de verandering live logging informatie: “usually our product would be used to import millions of features at a time.”

Binnen vijf minuten hebben we het kaartje op het beeld met de wijzigingen van de andere deelnemers. Een nieuw gebouwtje wordt toegevoegd: het snowflake hoofdkantoor in Nederland, attributen worden toegevoegd. De wijzigingen worden opgeslagen in de Oracle Database. Tijd om te exporteren: een programmatje om relationele database-gegevens om te zetten naar XML. Van tevoren zijn wel database elementen gemapt op de TOP10NL-onderdelen.

14.45
Het gewijzigde bestand wordt op de stick-gezet. Nu begint het verkoopverhaal: op de site van Snowflake is een binnenkort gratis “general purpose GML viewer” te downloaden. In de viewer bekijken we het nieuwe bestand, volgens de Top10NL-stijlspecificaties. Ook relevant: de importeer-software Go-loader is ook gebruikt om de Oracle-database in te richten op basis van het XML-schema van Top10NL.

15.20
We gaan weer verder, nu met Intergraph. Net als Snowflake importeert Intergraph de gegevens naar een Oracle Database, alwaar de bewerkingen worden uitgevoerd. Om warm te worden laat de Intergraph meneer wat Nederlandse GML-gegevens die hij van Internet heeft gehaald, waaronder een kaartje van Amsterdam. Een slimme zet: eerst wat verkoopverhaaltjes. Na vijf minuten zijn we klaar om het estafette-bestand te importeren.

De eerste stap is weer het importeren in de Oracle Database. Na ongeveer een minuut zien we een plaatje. Dan de visualization rules aanpassen: water wordt blauw, gebouwen zwart. We zien de nieuwe gebouwen van de eerdere deelnemers weer correct staan. Voor de verandering wordt de geometrie van één van de nieuwe gebouwen aangepast, waarna een nieuw gebouw in de database wordt gezet.

Nu weer een probleempje: attributes toevoegen gaat niet goed want de database accepteert niet alle gegevens vanwege validatie, maar het invulscherm biedt geen soelaas. De presentator doet er wat onhandig over, verontschuldigt zich en krijgt wat hulp uit het publiek.

Na een tijdje kunnen we verder. Vanuit achter roept iemand “Engels!” – de presentator praat al 10 minuten Nederlands maar niemand had het door. Ondertussen begin ik me aardig te verbazen over het feit dat m’n laptopbatterij het nog steeds uithoudt, maar dat terzijde.

15.42
Tijd voor de export, wat binnen 1 minuut klaar is. Daarna de standaard powerpoint sheets...hoewel. Deze meneer is wat technisch en minder goed in het scheiden van hoofdzaken en bijzaken waardoor de sheets lang en ingewikkeld zijn .

15.53
Presentatie voorbij. Tijd voor de laatste deelnemer. De validatie loopt falikant mis: Intergraph heeft niet geëxporteerd in het Top10NL-schema, maar voldoet wel aan de GML-standaard. Tegen een onaandachtig publiek probeert de presentator nog te vertellen dat de ontwikkelaars van Intergraph erg goed zijn en dat dit ‘morgen’ opgelost is, maar dat is 24 uur te laat.

16.00
Als laatste is AutoDesk aan de beurt. “De USB-stick doet het niet” Het originele bestand is staat nog op deze PC, dus gebruikt Autodesk deze. Op eenvoudige wijze wordt het bestand in AutoCad Map ingeladen, gewijzigd en weer opgeslagen. Bij de validatie blijkt ook het bestand van Autodesk weer enkele foutjes te bevatten in de attributen, die niet gevalideerd worden tegen het gevraagde schema.

16.10
Nu gaat het echt in razend tempo, want de dag is bijna om, maar de eerste deelnemer moet nu nog het door Intergraph gewijzigde bestand inlezen, maar moet dat dus doen met het GML-schema van Intergraph. Dit is niet meteen duidelijk en een ingewikkelde technische discussie volgt. Ik besluit naar huis te gaan. Ik heb genoeg gezien.

Ten Slotte
Eén conclusie is duidelijk: alle leveranciers hebben hard gewerkt om software geschikt te maken voor het inlezen en opslaan van GML-bestanden en -schema's. Het lijkt grotendeels te werken, zelfs terwijl de meeste leveranciers hun software zonder aanpassingen demonstreren.

De andere conclusie die zich opdringt is de volgende: hoewel GML-import en -export lijkt te werken, is het voor de meeste leveranciers géén hoofdactiviteit. De user interfaces zijn er niet op ingericht en makkelijk werkt het dus niet: zelfs de slimme demonstratiejongens en -meisjes hebben er nog moeite mee. Niet alle leveranciers gebruiken de voorgeschreven visualisatie, en vrijwel niet één gebruikt het schema om nieuwe gegevens tijdens de INVOER te valideren, bijvoorbeeld middels picklists. Dit staat toch duidelijk in het schema gespecificeerd... Teveel zaken waarvan je zou verwachten dat ze automatisch gebeuren (validatie van gegevens, juiste weergave, toevoegen van attributes)  eisen veel  tijd en aandacht.