The latest QuestDB release introduces support for geospatial data via the addition of geohash types. Geohashes encode geographic areas as base-32 strings, and native support for this type allows for fast and efficient querying and storage of geodata. Also included are helper functions for rounding timestamps, performance improvements for existing functions, alongside other fixes and features. Here's the full roundup of changes that have just landed!
The addition of geospatial data in QuestDB opens up various possibilities to include spatial dimensions in data sets in QuestDB. We're excited at the options for using QuestDB in different new use cases such as asset tracking, computer vision, machine learning, and other challenging domains. We're excited to see what our community builds with the newly-supported functionality and eagerly awaiting your feedback!
A geohash is a convenient way of expressing a location using a short alphanumeric string, with greater precision obtained with longer strings. The basic idea is that the Earth is divided into grids of defined size, and each area is assigned a unique id called its Geohash.
For a given location on Earth, we can convert latitude and longitude as the approximate center point of a grid represented by a geohash string. This string is the Geohash and will determine which of the predefined regions the point belongs to.
To assist with geospatial queries, a new
geohash type has been added to
QuestDB which allows storing and querying spatial data. The syntax follows the
geohash(<precision>). The following examples show how to create tables
with geohash types and to make basic queries by geohash:
To help with geospatial queries, a
within operator has been added which helps
evaluate if a geohash is equal to or is within a larger grid. The following
query will return the most recent entries by device ID if the
contains a geohash within
Geohashes can be used in SQL via PostgreSQL and HTTP with geohash literals and string to geohash conversion and with some special handling over InfluxDB Line Protocol. For full details of supported features and functionality including advanced usage, see the geohash documentation.
last() functions have had significant internal performance
improvements with the latest release. Improving the efficiency of these
functions has the benefit that geospatial queries are significantly faster. The
most common types of queries which are likely to benefit from this improvement
are those such as "last-known location" of a device or vessel:
To aid with rounding timestamp values, it's now possible to use
timestamp_ceil() functions to round up or down by a
unit of choice:
For more details on using these functions and reference documentation for the types of units that can be passed, see the date and time functions documentation.
It's now possible to pass parameters relating to out-of-order ingestion via REST
/imp endpoint accepts the
parameters on partitioned tables. For more information on the meaning and usage
of these parameters, see the
out-of-order ingestion documentation.
We have been tracking the most active GitHub discussions, and we are keeping a keen eye on the features and fixes that are most popular to our community. We are picking up the most upvoted and active topics in our GitHub Discussions and the feature requests in GitHub issues. If there's a feature you'd love to see, open a discussion on the topic or share your support if a thread for it exists already!
We're eagerly awaiting feedback on this release, so feel free to reach out and tell us how this version is running. Let us know how we're doing or just come by and say hello in our Slack Community or browse the repository on GitHub.