Where are we going with web-based maps?

The evolution of web mapping has enabled a far more integrated and collaborative ecosystem, we explore new data standards and what’s next.

Web mapping is indisputably one of the most popular GIS applications. Back in the 90’s, most digital maps were static. So, in order to have some interactivity, users would often have to install desktop applications or browser plugins.

In the 2000’s, with the rise of Google Maps, map “mashups” that integrated different data sources in the same interactive map became popular. Mainstream websites, from governments to newspapers, started using interactive maps to illustrate their “data stories.” Maps became as essential to any data-aware website as the popular interactive table.

Following the success of Google maps, we had access to a variety of interactive web maps that follow a server client architecture that do something very similar, in a slightly different way. The lack of interoperability between all these solutions was something that was addressed early on by the Open Geospatial Consortium (OGC), with the WMS standard. As with other OGC standards at the time, WMS relied on SOAP technology for serving georeferenced map images over the Internet. As images are rendered on-the-fly from a vector data source, the workload can be quite heavy on the server side and users may have to deal with suboptimal response times.

The OGC WMTS standard, created in 2010, addressed this problem by serving pre-rendered tiles. Unlike WMS, WMTS adopted a REST architecture which already started to be popular at the time. We can see WMTS in action in the OS Data Hub, through the OS Maps API.

The introduction of these standards negates the need for bespoke GIS applications, bringing the multi-domain nature of geospatial data to a wider audience of web developers.

The next step in terms of web mapping interoperability arrives with OGC API — Tiles. As with other Standards and candidate standards from the OGC API “family”, it leverages many of the patterns/best practices that we see on the web today: the use of http status codes, recommended JSON encodings, self-documented using OpenAPI. The OGC APIs adopt loose guidelines, without mandated encodings, you can learn more about this new “breed” of APIs in a previous blog post. A very interesting and distinctive feature about this candidate standard is the tile abstraction where you can serve raster tiles, along with vector tiles, and/or styled tiles. An example of raster tiles could be satellite imagery, like the one you see on data cubes, while an example of vector tiles could be any chunk of vector information, like roads or place names.

If you are interested in learning more about this promising candidate standard, and maybe even coding one of its earlier implementations, you are very welcome to join a free OGC code sprint at the “Space Partitions Code Sprint”, in the second week of May. This code sprint looks at the development across a number of standards within the OGC standards.

Geospatial data can provide multi-purpose support across multiple disciplines. We often emphasize the power of location in our blogs but collaborative initiatives help us build and interpret new data Standards, which informs new products and services. Ordnance Survey’s role is thematic, providing the foundations to applying data and the economic outcome is determined by a willingness for collaboration so let’s build the future of map tiling together!

This blog was authored by Joana Simoes, Developer Relations lead at the Open Geospatial Consortium.