Geoportaal Onroerend Erfgoed: alles samen!

Onroerend Erfgoed heeft al sinds 2013 een geoportaal. Het is sindsdien flink gegroeid en veranderd, maar de basisdoelstellingen en de architectuur zijn grotendeels hetzelfde gebleven.

Het geoportaal van Onroerend Erfgoed in 2014

Onze eerste en belangrijkste vereiste was iets dat makkelijk te gebruiken is voor een breed publiek. We merkten dat andere geoportalen vaak vooral GIS-professionals bedienden, en zo eigenlijk een online desktop-GIS bouwden: veelzijdig en krachtig voor wie al met GIS werkt, maar ontoegankelijk voor iedereen anders. Wij wilden een ervaring dichter bij Google Maps, specifiek toegespitst op mensen die informatie over cultureel erfgoed in Vlaanderen zoeken. We wilden ook dat het geoportaal aanvoelde als onderdeel van onze online informatiesystemen, niet als een aparte geodata-silo, en bouwden daarom rapporten die teruglinken naar onze online bronnen via hun persistente URI's. Die URI's zitten als metadata in al onze geografische data, en koppelen elke feature terug aan de authentieke bron waar de ruwe data (inclusief geodata) leeft — zo kan je altijd doorklikken naar de volledige set attributen en alles wat we over een resource weten.

Het geoportaal van Onroerend Erfgoed in 2019

Een tweede vereiste kwam voort uit de data zelf. Onroerend Erfgoed maakt en publiceert geodata over onroerend erfgoed, maar geen andere geodata, en dat wilden we niet apart gaan doen voor het geoportaal — dus steunen we sterk op publiek beschikbare webservices. Informatie Vlaanderen (vroeger AGIV) is al sinds het begin onze partner voor achtergrondkaarten en niet-erfgoedlagen, en we namen ook lagen op van andere partijen, zoals Mercator of buitenlandse instanties (bv. de Nederlandse Rijksdienst voor het Cultureel Erfgoed). Informatie Vlaanderen levert ook alfanumerieke diensten om kaarten te navigeren: de CRAB-dienst met alle adresgegevens in Vlaanderen, de CAPAKEY-dienst met kadastrale percelen, en een geolocatiedienst voor vrije-tekst adreszoekopdrachten. We wilden deze diensten gebruiken zonder hun data volledig te kopiëren, zoals tien jaar eerder misschien wel gebeurd was — we bewaren er zo weinig mogelijk van, hoogstens een cache hier en daar, zodat wat we tonen altijd overeenkomt met de bron.

Tot slot wilden we, vanuit technisch oogpunt, met open source software werken (kostenefficiënt, en een goede match met onze stack) en een portaal dat eenvoudig te onderhouden is, maar toch fijn configureerbaar — eenvoudige zaken (een nieuwe databron toevoegen) moeten eenvoudig zijn, moeilijke zaken (bepaalde requests optimaliseren) moeten mogelijk zijn. Die filosofie werkt goed: een vrij lichte codebase bedient onze bezoekers al jaren.

Softwarearchitectuur van het geoportaal

Waar bracht dat ons? Zoals elke moderne toepassing bestaat het geoportaal uit een back- en een frontend. De frontend is het grootste deel van de code (ongeveer 98% JavaScript, HTML en CSS): de kaartlay-out, UI/UX en algemene presentatie. Omdat die code al enkele jaren geleden geschreven werd, draait ze nog op een ouder JavaScript-framework, Dojo, met OpenLayers (en PROJ4) voor de kaartinterface, en HTML/CSS gebouwd op de Vlaamse huisstijl met het Zurb Foundation-framework. De frontend communiceert uitsluitend via services, met onze eigen geoportaal-backend of met andere webservices.

Die andere services zijn grotendeels INSPIRE-conforme WMS-, WMTS- en WFS-diensten, gehost door verschillende partijen:

• Informatie Vlaanderen host een groot aantal referentiedatasets — achtergrondkaarten, luchtfoto's, historische kaarten, adresgegevens, kadastrale percelen — via de officiële Vlaamse INSPIRE-node.
• Mercator is een INSPIRE-subnode voor datasets binnen het beleidsdomein Omgeving, een cluster van Vlaamse overheidsentiteiten rond thema's als milieu, vervuiling, energie, erfgoed en ruimtelijke ordening. Onroerend Erfgoed publiceert zijn eigen INSPIRE-conforme erfgoeddata via deze subnode.
• Terwijl eindgebruikers onze lagen doorgaans via Mercator ophalen, draaien we voor ons eigen geoportaal een eigen Geoserver-instantie, wat ons meer controle geeft over de presentatie en toelaat om een aantal interne of enkel-geauthenticeerde lagen niet te publiceren.
• We namen ook Nederlandse INSPIRE-erfgoedlagen op van onze collega's bij de Rijksdienst voor het Cultureel Erfgoed — erfgoed houdt zich niet aan politieke grenzen, dus is het nuttig voor onze gebruikers om ook over de grens te kijken, en een gepubliceerde WMS-dienst van een andere partij is makkelijk te integreren.

We gebruiken ook een paar niet-INSPIRE-lagen: OpenStreetMap als degelijke algemene achtergrondkaart, de NGI-topografische kaart voor wie daarin geïnteresseerd is, en, vooral voor de fun, de Pelagios-kaart van het Romeinse Rijk.

De backend van het geoportaal is een eenvoudige Python-toepassing gebouwd op het Pyramid-framework. Naast het serveren van de statische bestanden voor de frontend, is haar voornaamste taak het proxyen van een aantal locatiediensten van Informatie Vlaanderen:

• Geolocatie, die adressen suggereert op basis van vrije tekst en coördinaten teruggeeft — een snelle manier om op de kaart te navigeren.
• CRAB, een uitgebreidere dienst met volledige adresgegevens (gemeenten, straten, huisnummers en hun locatie). We gebruiken deze dienst in vrijwel al onze systemen om binnenkomende data te valideren; in het geoportaal dient ze als navigatiehulp, waarmee gebruikers van provincie naar gemeente, straat en adres kunnen doorklikken.
• CAPAKEY, een REST-service met perceelgegevens (gemeenten, kadastrale afdelingen, secties en perceelnummers), die op een gelijkaardige manier gebruikers door het Belgische kadastersysteem naar een specifiek perceel leidt.

Deze drie diensten zijn vandaag vrij en open beschikbaar, waardoor het proxyen ervan minder vanzelfsprekend lijkt dan toen we in 2013 begonnen:

• Aanvankelijk waren zowel CRAB als CAPAKEY SOAP-diensten, moeilijk of onmogelijk rechtstreeks vanuit browser-JS aan te spreken. CAPAKEY is intussen overgeschakeld naar REST, maar CRAB is nog steeds SOAP. Beide vereisten in het begin ook authenticatie, waardoor we via een proxy de inloggegevens konden afschermen.
• Het bespaart ons gedoe met CORS-headers — we gebruiken CORS al veel, maar alles goed op elkaar afgestemd krijgen kan lastig zijn, en de geolocatiedienst ondersteunt CORS helemaal niet, wat ons anders zou dwingen tot iets als JSON-P.
• Het beschermt ons tegen wijzigingen aan de bovenliggende API's: omdat onze toepassingen altijd onze eigen proxies aanspreken, moet enkel de proxy een upstream-wijziging (zoals de overstap van CAPAKEY van SOAP naar REST) opvolgen, waardoor de impact op onze systemen minimaal en beperkt blijft.
• De proxies voor CRAB en CAPAKEY dienen ook als cache, wat het aantal oproepen naar de bovenliggende diensten sterk vermindert.
• We breidden deze diensten op een paar punten uit voor onze eigen noden — met een lijst van Vlaamse provincies (die noch CRAB noch CAPAKEY bevat), en met een lijst van landcodes voor adresvalidatie.

Heb je zelf Vlaamse adres- of perceelgegevens nodig en werk je met Python, gebruik dan gerust onze CRABpy-bibliotheek; werk je met Pyramid, dan vereenvoudigt CRABpy_pyramid de integratie en voegt het een reeks kant-en-klare JSON-views toe.

De andere grote backend-component is een open source project genaamd Mapproxy, dat een tijdlang het lastigste aspect van het bouwen van het geoportaal oploste: omgaan met niet-publiek toegankelijke ruimtelijke data. Ons belangrijkste voorbeeld is een databank van archeologische vindplaatsen die, om verschillende redenen, niet publiek is — de data maakt geen deel uit van INSPIRE, maar heeft wel WMS/WFS-diensten op onze eigen Geoserver, beveiligd met gebruikersnaam en wachtwoord. Deze dienst rechtstreeks in onze frontend opnemen zou die inloggegevens blootstellen aan clients; Mapproxy lost dit op door de dienst te proxyen op onze geoportaal-server en zelf authenticatie en autorisatie af te handelen, waardoor we dezelfde Pyramid-authenticatie- en autorisatiebeleidsregels die we in al onze webtoepassingen gebruiken, kunnen vertalen naar regels over wie welke GIS-lagen mag zien.

Naast dit veiligheidsgerelateerde proxyen, routeren we ook WMS GetFeatureInfo-requests via Mapproxy om CORS-problemen te vermijden, en overwegen we op termijn ook de cachingfunctionaliteit ervan te gebruiken, al deden we dat tot nu toe nog niet.

Al bij al is ons geoportaal een belangrijk platform gebleken, gebruikt door zo'n 12.000 mensen per maand in vrij intensieve sessies, en toch goedkoop om te bouwen en te onderhouden — het portaal zelf vraagt weinig middelen, want het zware werk gebeurt door onderliggende diensten die ook voor andere toepassingen en processen gebruikt worden. Interesse in onze opzet? Bekijk het geoportaal, onze bibliotheken op GitHub, lees meer berichten met de tag geoportaal, of stuur ons een mail naar ict@onroerenderfgoed.be.