As spatial technology continues to evolve, we experience its benefits in our daily lives through remote work setups and remote asset management, but also in a processing capacity; such as building maps in web-based applications. The key technologies to recognise in this space are CARTO and deck.gl, which we use frequently at NGIS.
In this blog, I will give a brief overview of CARTO and deck.gl, and show examples of using these sources to customise your web application with a map and layers. You’ll see how straightforward it is to add spatial datasets to CARTO’s database, and get access to them into your application using an API key through deck.gl.
CARTO is a location intelligence platform which enables us to store and visualise spatial data within a matter of seconds. It can also be used as a map server thanks to its APIs and Content Delivery Networks for different types of tiling, styling and cartography.
One of CARTO’s unique selling points is that you’re not required to be a Geographic Information System (GIS) specialist or have professional developing experience to be able to use the platform. However, an intermediate knowledge of Spatial SQL is highly recommended if you want to gain powerful insights from the spatial data that you have stored in CARTO—read our blog for more information on Spatial SQL.
A feature that I really appreciate about CARTO is the capability to query GIS data directly within an application.
Deck.gl is a WebGL-powered library for visualising large spatial datasets on the fly, quickly and with minimal complexity. Deck.gl makes rendering map layers on the client-side much more simple. This means for GIS web applications, we can use as many layers as we want without worrying about the dataset size causing latency issues.
Another benefit of using deck.gl is the flexibility you have when customising layers. All layers come through a flexible API that gives you the ability to programmatically control each aspect of the rendering.
You can find all documents and desired code to set up deck.gl on their website.
In addition, I would recommend looking at the deck.gl website examples section to see the layer types you can use with deck.gl.
Setting up a CARTO database to generage an API key
So, how do you access your data in deck.gl? The answer is CARTO.
Let’s cover the steps for storing your dataset in CARTO and creating an API key to access your database directly from your deck.gl web application. If it’s your first time using CARTO, the good news is that you can use their service free for 12 months to assess if it’s suitable for you or not.
Let’s skip the sign-up process for now and jump directly into adding a table and creating an API key. To help you along, I’ll provide screen shots of the process.
1. After signing in to your account, everything you need is located in the top toolbar. From here, go to the Data section.
2. Now click on add New Dataset:
3. Now, you will see all the data types which you can add to your database.
*Tip for GIS analysts and developers: Did you know that you can access FME desktop directly from CARTO to cleanse and process your data, removing the need to sign in every time or manually upload datasets from FME?
Adding a table and generating your API key
1. For this example, I have selected the CSV option. I can use the drag and drop functionality to import my CSV file to the database.
2. Once you’ve added your CSV, click on the top right of the screen (which is your profile icon) and go to the API keys section to generate your new access key. You can either create a master key for complete access to your database, or you can generate specific API keys to grant access to just one or a few tables with the specific policy that you specify. These could be read only, editable or give users access to remove data from your application.
I would recommend you use a custom API key as it is more secure, and you can prevent any unwanted changes to your dataset from unauthorised users.
3. On the next page, select the table from your database that you’d like to access in your deck.gl application. It’s important to give a unique name to your API key and set the custom functionality for users (see the below image) and then click on ‘save changes’ to get the API key.
This process of adding a table and getting access to it only takes two to three minutes. It’s that simple!
But now, let’s move onto some deck.gl integration examples. At NGIS, we use the integration of deck.gl and CARTO technology to help our clients gain better insights about their spatial data.
Accessing your CARTO data in deck.gl
The following examples are using Google Maps as a base map, CARTO as database and deck.gl for rendering layers.
First, I’ll show you how to add layers on top of your customised Google Maps base map. You’ll notice that the basemap I have used has been styled in darker colours, there are two ways this is made possible:
- Creating a custom Google Map by using the Google Maps Platform: Google Maps has a free feature called Maps Styling which helps us customise the map colours. Once customised, you can utilise the custom basemap within your deck.gl application. For more on styling Google Maps, visit:
- We could also achieve a similar result by using a CARTO basemap. CARTO is known in the industry for making ‘beautiful maps’. CARTO has a choice of three basemap styles, along with the option to switch labels on or off. Full details on CARTO’s basemaps are available here: https://github.com/CartoDB/basemap-styles
Where to use your CARTO API key and configure the deck.gl
A developers code guide from deck.gl can be found here, this is very helpful as you navigate your way through the following steps.
In the example code on the screenshot above, you can see that after importing the ‘@deck.gl/carto’ library, we must use:
- ‘CartoSQLLayer’: which is showing the type of layer we want to render on top of the map, and;
- ‘setDefaultCredentials’: which is a property that defines the configuration to connect our application to our database in CARTO.
In the screenshot above, you will see boxes numbered 1-4. Here is an explanation of what is in each box and why it’s important:
- This box is the place where you need to put your own API key that was created in CARTO and the username of your CARTO account.
- This box is the place where you need to specify which type of layer you intend to render in your application. This can be any of the layers which deck.gl is capable of rendering, such as; ArcLayer, LineLayer, TileLayer and so on. Have a look at all the layers here.
- This box is where you need to get access to your data. In this example, we are doing SQL query to bring back all the data in our table from the CARTO database. You don’t need to worry - deck.gl is smart enough to find which column is responsible for geographical location in your data set in order to render the layer.
- Box four is where you have different accessors to map or find an object in data to configure the visualisation. These accessors are responsible for changing the layer colours, opacity, line width, etc.
You can get more documentation on how to install all dependencies and get started with deck.gl here.
I have used the above process 10 times to define 10 different layers in my web GIS application. Now, let’s have a look at the performance of the application now these layers have been added, rendering all of them on the client side.
The GIF above demonstrates how the map looks and performs with the 10 added layers of data which have been imported from various tables (using the API keys from CARTO’s database) all at once.
Using deck.gl also gives you the option to add tooltips to your layers regardless of it being a heatmap, tile layer or Arc layer. You can also change the opacity of that layer very quickly without compromising the performance of the visualisation.
The benefits of using these technologies together
The benefit of using CARTO and deck.gl together is that it simplifies the architecture of your web GIS application. This means you can either send the request to the CARTO API, get the response back as a geo-json file and render layers on the user device. Or if you wish, you can have a more complex architecture and add this service to the back-end, which is responsible for sending a request to CARTO, getting the response and sending it back to the front-end. You can use it as a proxy to get access to your database in CARTO. Both architectures will not affect the performance of your application so you can choose whichever you desire.
I hope you have a better understanding of what tools are available to help you build your web GIS application and it makes your decision easier by seeing the performance of CARTO and deck.gl.
If you’d like to read some more about our work with CARTO, see here. Or perhaps if you are just starting out in GIS, read my colleague Daphne’s Geotech Friday blog for some useful resources to help you make sense of geospatial data.
Remember, if you need assistance or have a project where you would like our input, get in touch with our team for a chat.
Back To News Stories