Spatial data from geographic information systems (GIS) is all around us. From smartphones that make our lives better and more convenient to precision agriculture that is increasing the amount of food farmers can produce while reducing the cost, whether or not we realize it, almost every part of our lives is touched by spatial data.
This increase of spatial data is simultaneously bringing an increase of open spatial datasets that people can consume and use to build all sorts of new applications. However, these types of datasets have not always been easy to work with. Also, due to the size of some of the geographic data, they can be difficult to bring to modern application deployment frameworks such as Kubernetes.
To help with these issues, Crunchy Data recently announced two new open source projects, pg_tileserv and pg_featureserv, to make it easier to develop cloud-native spatial applications. These projects, part of open source Crunchy Spatial, help developers leverage the robust PostGIS geospatial database extension to PostgreSQL without having to write complex SQL statements.
So what are pg_tileserv and pg_featuresev, how do they make it easier for developers to add location services to their Kubernetes applications, and what does this mean for the future of spatial applications?
Traditional GIS vs. modern spatial microservices
Traditionally, when an organization or individual works with spatial data, they start with a product that grew up as a GIS. There are many high-quality open source GIS products (QGIS, GeoServer, GeoNode, etc.), but they may not align with modern, cloud-native approaches to software design.
The popularity of Kubernetes creates challenges for these legacy applications around automation and deployment, as they require a lot of manual configuration, for example, when data sources are added and modified. In many setups, these spatial applications must exist outside Kubernetes and cannot leverage many of the conveniences it provides.
In contrast, modern spatial services should be driven by the spatial data that they are processing and serving out. They should align with modern software development practices and scale efficiently and integrate easily with developer workflows.
Applications that are spatially aware also need to ensure they can handle the unique characteristics of spatial data (e.g., geometries, projections, etc.). To do all of this in independent microservices can be challenging unless you have a highly capable database to do the majority of the work for you. This is where pg_tileserv and pg_featureserv help, as both projects leverage the power of PostGIS, an open source geospatial extension to PostgreSQL, to provide advanced spatial capabilities from a simple REST framework
Generate map vector tiles with pg_tileserv
pg_tileserv is a lightweight vector tile server written in Go that enables you to generate vector tiles directly from PostGIS. It does this by implementing the ST_AsMVT() function in a best-practice method that translates an HTTP request to the database. It includes common defaults that allow you to pass a database connection URL to the server and be up and running in no time. There's no heavyweight software to install and configure, and it's designed for cloud-native GIS applications.
For specific examples on how to use it, check out our blog posts on tile serving and spatial tile serving with PostgreSQL functions.
Annotate your maps with pg_featureserv
pg_featureserv is a lightweight service written in Go that enables you to serve features directly out of PostGIS. It implements the OGC API for features and provides a standard REST endpoint for your spatial data and functions contained in PostGIS. Just like pg_tileserv, there's no heavyweight software to install; just pass a database connection URL to your PostGIS database, and you're off to the races. For a specific example of how to use it, check out our post on querying spatial features.
Focus on spatial data, not GIS
With our deep background in developing PostGIS and building PostGIS-backed applications, we wanted to help developers unlock all the value of spatial data in a way that is easy to deploy, scale, and maintain. As the source code of pg_tileserv and pg_featureserv show, we are just leveraging functions already in PostGIS. This allows developers to quickly add spatial data to their applications and data scientists to focus on the data.
The benefits of this approach are:
- Faster performance because PostgreSQL and PostGIS are doing the work for you
- Less configuration to maintain because the database structure is the configuration
- By design, it runs in the cloud at enterprise scale from the start
- Shorter times to update customer-facing applications—when you update your data in the database, your application is updated instantly
- Ability to focus more on maintaining your data and delivering value to your users and less on wrangling software
Also, since these services respond to the configuration of your database, they also expose functions contained in the database. Rather than developing their data functions to incorporate them into software later, data scientists can create functions in the database that are immediately made available via a REST API. The software begins to fade into the background so an organization can focus on the data.
Suffice it to say, we're pretty excited about these new geospatial services, and we definitely want your feedback on them. Feel free to check out pg_tileserve and pg_featureserv, try deploying them alongside your PostGIS databases with the PostgreSQL Operator, and share your feedback in the comments.
Comments are closed.