Flanders Heritage Geoportal: All Together Now!

Flanders Heritage has run a geoportal since 2013. It's grown and changed a lot since then, but its basic goals and architecture have stayed largely the same.

The Flanders Heritage geoportal in 2014

Our first and main requirement was something easy to use for a large user base. We'd noticed that other geoportals tended to cater to GIS professionals, often building what amounted to an online desktop GIS — versatile and powerful for people who already know GIS, but inaccessible to everyone else. We wanted an experience closer to Google Maps, tailored specifically to people looking for cultural heritage information in Flanders. We also wanted the geoportal to feel like part of our online information systems, not a separate geodata silo, so we built reports that link back to our online sources through their persistent URIs. Those URIs live as metadata in all our geographical data, tying every feature back to the authentic source application the raw data (geodata included) lives in — so you can always follow the link to see the full set of attributes and everything we know about a resource.

The Flanders Heritage geoportal in 2019

A second requirement came from the data itself. Flanders Heritage creates and publishes geodata about immovable heritage, but not other kinds of geodata, and we didn't want to start doing so just for the geoportal — so we lean heavily on publicly available webservices instead. Informatie Vlaanderen (formerly AGIV) has always been our partner for basemaps and non-heritage layers, and we've pulled in other layers too, from bodies like Mercator or other countries' agencies (e.g. the Dutch Cultural Heritage Agency). Informatie Vlaanderen also provides alphanumeric services that help navigate maps: the CRAB service enumerating Flemish address data, the CAPAKEY service for cadastral parcel data, and a geolocation service for free-text address search. We wanted to use these services, not copy their data wholesale, as might have happened a decade earlier — we store as little as possible from them, a cache here and there at most, so what we show users always matches the source.

Finally, from a technical standpoint, we wanted open source software (cost-efficient, and a good fit for our stack) and a portal that's simple to maintain while still configurable in detail — easy things (adding a data source) should be easy, hard things (optimising specific requests) should be doable. That philosophy has served us well: a fairly light codebase has kept serving our visitors for years.

Software architecture of the Flanders Heritage Geoportal

So where did those design considerations land us? Like any modern application, the geoportal has a back- and a frontend. The frontend is the bulk of the code (roughly 98% JavaScript, HTML and CSS) — the map layout, UI/UX and general presentation. Since it was written several years ago, it still runs on an older JavaScript framework, Dojo, with OpenLayers (and PROJ4) for mapping, and HTML/CSS built on the Flemish government's corporate style using the Zurb Foundation framework. The frontend talks exclusively through services, either to our own geoportal backend or to other webservices.

Those other services are mostly INSPIRE-compliant WMS, WMTS and WFS services hosted across a few parties:

• Informatie Vlaanderen hosts a large number of reference datasets — basemaps, aerial photography, historic maps, address data, cadastral parcels — through the official Flemish INSPIRE node.
• Mercator is an INSPIRE subnode hosting datasets for the Environment policy domain, a cluster of Flemish Government entities covering topics like Environment, Pollution, Energy, Heritage and Spatial Planning. Flanders Heritage publishes its own INSPIRE-compliant heritage data through this subnode.
• While end users typically harvest our layers via Mercator, for our own geoportal we run our own Geoserver instance, giving us more control over presentation and letting us keep a few internal or authenticated-only layers unpublished.
• We've also included Dutch INSPIRE heritage layers from our colleagues at the Cultural Heritage Agency — heritage doesn't respect political borders, so it's useful for our users to see across them, and consuming another party's published WMS is easy.

We also use a few non-INSPIRE layers: OpenStreetMap as a solid general basemap, the NGI topographical map for those interested, and, mostly for fun, the Pelagios map of the Roman World.

The geoportal backend is a simple Python application built on the Pyramid framework. Besides serving the frontend's static files, its main job is proxying a few location services from Informatie Vlaanderen:

• Geolocation, suggesting addresses from free-text input and returning coordinates — a quick way to navigate the map.
• CRAB, a more exhaustive service with full address data (municipalities, streets, house numbers and their locations). We use it across most of our systems to validate incoming data; in the geoportal it's a navigational aid, letting users drill down from province to municipality to street to address.
• CAPAKEY, a REST service with parcel data (municipalities, cadastral divisions, sections and parcel numbers), similarly used to guide users through the Belgian cadastral system to a specific parcel.

These three services are now freely and openly available, so proxying them might seem less necessary than it did when we started in 2013:

• Early on, both CRAB and CAPAKEY were SOAP services, hard or impossible to call directly from browser JS. CAPAKEY has since moved to REST, but CRAB is still SOAP. Both also originally required authentication, so proxying let us shield the credentials.
• It frees us from wrestling with CORS headers — we already use CORS a lot, but getting it all to cooperate can be a hassle, and the Geolocation service doesn't support CORS at all, which would otherwise force us into something like JSON-P.
• It insulates us from upstream API changes: since our applications always call our own proxies, only the proxy needs to track an upstream change (like CAPAKEY's SOAP-to-REST move), keeping the impact on our systems minimal and contained.
• The CRAB and CAPAKEY proxies double as caches, cutting the number of calls to the upstream services significantly.
• We've extended these services in a few small ways for our own needs — adding a list of Flemish provinces (present in neither CRAB nor CAPAKEY), and incorporating a list of country codes for address validation.

If you need Flemish address or parcel data yourself and work in Python, feel free to use our CRABpy library; if you're on Pyramid, CRABpy_pyramid simplifies integrating it and adds a set of opinionated JSON views on top.

The other major backend component is an open source project called Mapproxy, which solved what was for a while the hardest part of building the geoportal: dealing with non-publicly-accessible spatial data. Our prime example is a database of archaeological findspots that, for several reasons, isn't public — the data isn't part of INSPIRE, but does have WMS/WFS services on our own Geoserver, protected by username and password. Including that service directly in our frontend would expose those credentials to clients; Mapproxy solves this by proxying the service on our geoportal server and handling authentication and authorisation itself, letting us translate the same Pyramid authentication/authorisation policies we use in all our web applications into rules about which GIS layers are visible to whom.

Beyond this security-related proxying, we also route WMS GetFeatureInfo requests through Mapproxy to avoid CORS issues, and may make more use of its caching features down the line, though we haven't yet.

All told, our geoportal has proven to be an important platform, used by roughly 12,000 people a month in fairly intensive sessions, while remaining cheap to build and run — it needs very little in the way of resources itself, since the heavy lifting is done by underlying services shared with other applications and processes. Interested in the setup? Browse the geoportal, check our libraries on GitHub, read more posts tagged geoportaal, or drop us a line at ict@onroerenderfgoed.be.