GIS viewer for municipalities

A municipal GIS viewer is a web application in which residents, businesses or staff view map layers, search for an address and request information about an object. Think of zoning plans, trees, waste containers, event locations or projects in public space. Behind the viewer are services that supply the map images and objects, often a mix of the municipality's own data and national sources.

A good viewer does three things well. It loads quickly, even on a phone with a poor signal. It is usable for people who cannot see a map or do not use a mouse. And it lets the municipality add and adjust layers itself, without a developer having to step in.

TechinFlow offers the building and management of such viewers, with a focus on government bodies. The starting point is that we work with open source components and open standards, so that the viewer connects to what already runs at PDOK and on your own GeoServer. If you want to explore the market before choosing a supplier, read the guide choosing a GIS viewer (in Dutch). It also sets alternatives side by side, including the situations in which another solution fits better.

If the question is broader than a viewer, for example an application in which staff enter or edit objects on the map, that falls under GIS and digital map solutions.

For the exchange of geographic information, municipalities are covered by the agreements of Forum Standaardisatie, the Dutch standardisation forum. The viewer must be able to use those standards as a consumer, and the services you publish yourself must offer them.

In practice a viewer supports both the new OGC APIs and WMS and WFS. Many municipal and provincial services still run as WMS or WFS, while PDOK offers more and more datasets through OGC APIs. A viewer that speaks only one generation therefore excludes sources. The coordinates of Dutch services are often in the Rijksdriehoekstelsel (the Dutch national grid); with the RD to WGS84 tool you can quickly check whether a point lands in the right place.

PDOK holds open government datasets with up-to-date geo-information, reachable through geo web services and OGC APIs and also as downloads. For a municipal viewer that is the logical basis for background maps, aerial photos and basic registers. The BAG, for example, is available as an OGC API with buildings, accommodation objects and address information. A broader overview of what PDOK offers is in our overview of Dutch open geodata and PDOK, and the register itself is described on the BAG page.

For the search box, a transition is under way. The well-known PDOK Locatieserver is an open and free geocoding service with, among others, a suggest, lookup, free and reverse API. On 31 March 2026 PDOK also launched the PDOK Location API, a new service that according to PDOK closely resembles the Locatieserver and to which PDOK plans the switch. It searches OGC API Features collections of several official datasets and returns, per result, a link to the full object in the source. On 11 October 2026 the Location API has thirteen collections, including address, building, parcel, road section and place of residence.

PDOK itself writes that the Location API is not yet a full replacement. Data sources are missing, and reverse geocoding, searching by clicking on the map, has not been filled in yet. We therefore propose a search function with an intermediate layer of its own. The viewer then uses the Location API where it has the collections needed, falls back on the Locatieserver for reverse geocoding, and can switch over completely once the Location API offers everything the viewer needs. For the municipality that is one setting, not a new build.

According to DigiToegankelijk, government websites and apps must meet the 50 requirements of WCAG 2.1 at levels A and AA and publish an accessibility statement. For a map viewer that is awkward, because a map is essentially an image.

The legal position of the map itself is more nuanced than it is often presented. Article 2(2)(d) of the Tijdelijk besluit digitale toegankelijkheid overheid (the Dutch Temporary Decree on digital accessibility of government) excludes from its scope:

d. onlinekaarten en onlinekarteringsdiensten, mits essentiële informatie op navigatiekaarten op een toegankelijke, digitale wijze wordt verstrekt;

Source: wetten.overheid.nl, BWBR0040936, Article 2(2)(d). In English: online maps and mapping services, provided that essential information on navigation maps is offered in an accessible digital way. The page around the map, the search field, lists, menus, forms and texts remain in scope. Because that boundary is hard to draw, we make the whole viewer accessible rather than lean on the exemption.

The solution is not to leave the map out, but to offer the same information in another way too. Concretely, that means:

• a search field and list view with which someone without a map reaches the same objects and data;
• operation of zooming, layers and pop-ups with the keyboard only, with a visible focus indicator;
• legends and colours that are also distinguishable for colour-blind people, with text next to every colour;
• descriptive texts for map layers, so that a screen reader tells what can be seen;
• a layout that works at 200 per cent zoom and on a narrow screen.

We test the viewer by hand with keyboard and screen reader, alongside automated checks, and deliver the results in a form your municipality can use in its accessibility statement. We recommend an external auditor for the formal evaluation, because a builder should not judge its own work.

With a viewer there are three kinds of ownership: the source code, the configuration and the data. All three must end up with the municipality, otherwise switching to another supplier is in practice a rebuild.

Source code. Our proposal is to build on open source map libraries and to deliver our own code under an open source licence, preferably the European Union Public Licence (EUPL). Interoperable Europe, an initiative of the European Commission, describes the EUPL as a licence for setting out the terms for sharing and reusing software, also for governments. Other municipalities can then reuse the code, and you can hire any developer to build further.

Configuration. The starting point is that map layers, styles, search settings and texts live in readable configuration files in the municipality's repository, not in a database that only the supplier can reach.

Data. Municipal layers stay in your own GeoServer or database. The viewer fetches them through the standards in the table above. For PDOK data you adopt the licence and attribution that PDOK states per dataset.

Also record how management is handed over. A viewer that runs publicly needs library updates, browsers change and PDOK renews its services. Hosting and management can lie with TechinFlow or with your own organisation; the set-up is described under cloud and data infrastructure.

1. Inventory of layers and users. Which map layers must be included, where are they now, in which format and coordinate system? Who uses the viewer, residents or staff, and on which device?
2. Demo on open data. A working viewer with a PDOK background, address search and a few of your public layers. That lets you judge operation and speed on something that actually runs.
3. Configuration and house style. All layers, legends, pop-ups and texts are set up in the configuration, in the municipality's house style.
4. Accessibility and acceptance. Testing with keyboard and screen reader, a check on mobile, and acceptance against the agreed criteria.
5. Go-live and handover. The viewer goes live on your domain. You receive the repository, the configuration, a management manual and an instruction for adding layers yourself.

The pace depends mostly on the state of the source layers. Layers that are already available as OGC API, WMS or WFS get into the viewer quickly. Layers that still sit as loose files on a network drive must first become a service.

A supplier can build the viewer, but a number of things lie with the municipality. The sooner they are arranged, the smoother the project runs.

• A content owner per group of map layers, who decides what may be public and who maintains the data.
• Access to the sources, such as your own GeoServer or database, with a contact person at the administrator.
• A decision on openness. If a layer contains personal data or sensitive locations, the municipality decides whether and how it is shown.
• The accessibility statement, which the municipality publishes and maintains itself.
• The domain and house style, plus any requirements from the communications department.
• A choice about hosting: with the municipality, with a hosting partner or managed by TechinFlow.

If the viewer goes through a tender, look at the guide requirements for a GIS viewer tender (in Dutch). It is written objectively and contains a declaration of interest, because TechinFlow itself supplies GIS viewers.

TechinFlow B.V. is a new company, founded by Tekin Uslu. By his own account, Tekin has worked on geo-information, data engineering and IT architecture since 2006. His GitHub account holds the repositories Atlas-Basic and Atlas-Starter from 2020, a map viewer based on OpenLayers, and ZoekOpAdresLocatieServerPDOK from 2017, an address search on the PDOK Locatieserver. Those repositories are public on GitHub; you can inspect the code yourself.

Earlier work by the founder is not a reference of TechinFlow B.V. For a tender that means TechinFlow cannot list an earlier municipal viewer as a reference of the company. What you can assess is a working demo on PDOK data and a technical explanation of the set-up. Do ask for that in a conversation through the contact page.

A practical test for any supplier, including us, is a short trial with your own public layers. Have the demo opened on a phone, have a colleague operate it with only the keyboard and ask a geo specialist whether the layers appear in the right place and at the right scale. That way you compare viewers on behaviour instead of on a presentation.