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. As an example, when I was teaching full-stack development at a Bootcamp, 7 out of 10 students (who knew nothing about GIS) wanted to add an interactive map to their final project.
Following the success of Google maps, we had access to a variety of interactive web maps that follow a server client architecture – they 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. However, it still used XML encodings and it did not leverage many of the web practices that we see today.
The next step in terms of web mapping interoperability came 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 (e.g. the use of http status codes, recommended JSON encodings, self-documented using OpenAPI). This was intentional, so as to decrease the learning curve for web developers. As with other OGC APIs, it has a modular structure; i.e. a developer can pick some parts of OGC API – Tiles and integrate them into their existing application. Another very interesting feature about this candidate standard is the tile abstraction – you can serve raster tiles, along with vector tiles, and/or styled tiles. You can explore an example of OGC API – Tiles “in action”, here.
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 us at the “Space Partitions Code Sprint”, in the second week of May. Registrations are free and open to anyone, until the 9th of May.
Let’s build the future of map tiling together!
Top comments (0)