Rotating geometries in PostGIS
Recently we were pleased to announce the release of our new Map Creator. The refreshed version of this tool gives users the notion of a real drawing board, which makes the process of creating maps smoother and more intuitive. We also took a closer look at the most popular graphic programs and followed their steps regarding the layout of the workspace and navigation. But we did more than that to help users with drafting their own space plans easily. The new Map Creator enables drawing in the most convenient position, yet it respects geographic coordinates. Check out why this new feature matters so much and what we had to do with all the existing maps.
**Spoiler alert: this article contains tons of useful hints**
How did it work before?
In the previous version of the Indoorway Map Creator in order to create a space plan our user had to:
- choose the location of the building with Google Maps API,
- upload a file with a space plan,
- place it in the correct position on the map.
In this configuration we showed the space plan in the Map Creator, where our user could continue drafting a map: draw rooms, set paths and POIs, etc. The process was clear, but drawing on an image aligned to the map of the world — which often was flipped or shifted — might have caused some troubles.
Now it’s seamless and more enjoyable!
Looks great, doesn’t it? This post will teach you how to achieve such an effect.
The power of PostGIS
Because at Indoorway we work with geospatial data, the PostGIS is very helpful in our daily tasks. And once again, it didn’t disappoint us at all. Just to remind you, the PostGIS is a great geospatial extension to the PostgreSQL. It enables saving geometric and geographic objects to a database and performing operations on them.
With PostGIS you can create different shapes (polygons, linestrings, etc.), calculate the area of the shape or the distance between given objects, determine whether the object is within radius of another object and much more. We are impressed with PostGIS features and how easy it is to manipulate and analyze data with this library.
Spatial reference systems
The rotation of spatial objects is not as easy as it may seem, especially when we want to show the results without any distortion in the Map Creator. The key to solving this problem is using a proper spatial reference system (SRS), which defines a location of geographic features. There are two common types of coordinate systems:
- Geographic coordinate reference system which is the well-known latitude-longitude system
- Projected coordinate reference system which defines a specific map projection. All of available map projections transform the spherical shape of the Earth into a flat surface.
These systems can be identified by Spatial Reference System ID (SRID), including the EPSG dataset.
PostGIS includes special table called spatial_ref_sys, where we can find definitions of all the available coordinate systems for database.
The correct definition of SRS turns out to be very important for our transformation process. But how do we know what SRID we should use?
Before you get the answer to this question, see what tools we use to visualize data in our project.
The tools Indoorway loves
All of Indoorway’s frontend developers agree that Leaflet.js and Google Maps API are super useful tools. It is important to know what coordinate systems they use.
By default Google Maps and Leaflet.js use the Spherical Mercator projection coordinate system. Spherical Mercator is officially described by EPSG:3857. Furthermore, the data we send to Leaflet.js is in GeoJSON format, which uses coordinates in geographic coordinate system (EPSG:4326).
Having this basic information in mind, let’s get to real work.
Transformation flow
The following space plan will be our example:
We store data describing the outline of the space plan and its background in GeoJSON. As mentioned above, in a draft of a space plan you can also add rooms and paths. The transformation of these objects is based on the same rules as the transformation of the outline, so we skipped them in this article.
What do we need to start the rotation?
PostGIS supports us with ST_Rotate(geometry geom, float radians, geometry pointOrigin) function which rotates geometry by given radians, relative to a reference point, in counter-clockwise direction.
Let's start by defining an angle. ST_Azimuth — one of the PostGIS functions is helpful here. As the documentation says:
”ST_Azimuth returns the north-based azimuth as the angle in radians measured clockwise from the vertical on pointA to pointB. The azimuth is angle is referenced from north, and is positive clockwise: North = 0; East = π/2; South = π; West = 3π/2.”
We take corners of the uploaded space plan as pointA and pointB. The illustration below shows how to choose corners and set the proper angle:
How do we implement this action? Just like this:
Because we show objects in EPSG:3857, all the operations have to be performed in the same coordinate system.
We use ST_Transform(geometry geom, integer SRID) to reproject data. This function can be sometimes confused with the one for managing SRS, which is: ST_SetSRID(geometry, SRID). Please remember that only ST_Transform changes coordinates from their current system to the new one.
Moreover, in the example presented above we see the usage of ST_GeomFromText with defined SRID. This step is quite important before transforming geometry to SRID=3857. What would happen if we applied geometry without defining SRID?
Oops! Something went wrong ¯\_(ツ)_/¯
When we create an object without a defined SRID, we cannot use it in many sorts of spatial processing. One of them is transforming geometry into another coordinate system. As we operate on GeoJSONs, we can apply geographic coordinate reference system.
The first step is behind us. We have to rotate the outline of the space plan relative to a specific reference point, which in this case is the center of our background. PostGIS offers such a function:
Something new appears here — ST_GeomFromGeoJSON function, which parses geojson representation of geometry and returns a geometry.
We’re getting close to the final result. It’s time for the main point of the process: rotation!
We just need to insert the data into the rotation function:
We’re almost done. There is one more important thing to do — passing the result to Leaflet.js, which accepts GeoJSON. To finish the process correctly we should first convert coordinates of geometry to geographic coordinate system and then return the geometry as a GeoJSON element:
With ST_AsGeojson we get only geometry, not completed GeoJSON.
The final effect in the Map Creator is presented in the graphic below:
We did it! It looks great and causes no distortions.
What would happen if we didn’t apply the proper coordinate system?
Well, the result presented above doesn’t look like the shape of our space plan for sure. The project is deformed.
Summary
As you see PostGIS does a great job in Indoorway Map Creator and smoothly deals with all the transformations we need to create a space plan. Its library has been developed for years, thus the API is stable and mature. PostGIS features are clearly and properly documented, which makes it worth considering for any GIS applications.
Right now in our refreshed Map Creator the user can feel like a real designer. He can focus on details of the project and create a more accurate space plan. The draft is adjusted to the world map at the end of the whole process. Of course, we keep the raw data if the user wants to go back to it.
What is your experience with rotating figures? Share your opinion and ideas below this post!
