QGIS Planet Tags
We have recently been working for the French Space Agency ( CNES ) who needed to store and visualize satellite rasters in a cloud platform. They want to access the image raw data, with no transformation, in order to fullfill deep analysis like instrument calibration. Using classic cartographic server standard like WMS or TMS is not an option because those services transform datasets in already rendered tiles.
We chose to use a quite recent format managed by GDAL, the COG (Cloud Optimize Geotiff) and target OVH cloud platform for it provides OpenStack, a open source cloud computing platform.
A COG file is a GEOTiff file which inner structure is tiled, meaning that the whole picture is divided in fixed size tile (256 x 256 pixels for instance) so you can efficiently retrieve parts of the raster. In addition to the HTTP/1.1 standard feature range request, it is possible to get specific tiles of an image through the network without downloading the entire raster.
We used a service provided by OpenStack, called Object Storage to serve the COG imagery. Object storage allows to store and retrieve file as objects using HTTP GET/POST requests.
Web Coverage Service standard could have been an option. A WCS server can serve raw data according to a given geographic extent. It’s completely possible to deploy a container or a VPS (Virtual Private Server) running a WCS Server in a cloud plateform. The main advantages of the COG solution over WCS Server is that you don’t have to deal with the burden of deploying a server, like giving it ressources, configuring load balancing, handle updates, etc…
The beauty of COG solution is its simplicity. It is only HTTP requests, and everything else (rendering for instance) is done on the client side.
Here are the different steps you’d have to go through if you’re willing to navigate in a big raster image directly from the cloud.
First, let’s generate a COG file
Install your openstack-client, it can be achieved easily with Python pip install command line
Next, configure your openstack client in order to generate an athentification token. To do so you need to download your project specific openrc file to setup your environment)
You are now good to push you COG file to the cloud instance
Before starting QGIS, 2 environment variables need to be set. (replace xxxx_my_token_xxxx with the token you’d just come to generate)
It can also be done directly from the QGIS Python console by setting those variable using the os.environ.
Finally, add a cloud raster data source in in QGIS
You can now navigating into your image directly reading it from the cloud
© CNES 2018, Distribution Airbus DS
While panning in the map, QGIS will download only few tiles from the image in order to cover the view extent. The display latency that you could see in the video depends essentially on:
Note that the white flickering that you could see when you move in the map and the raster is refreshed should be removed in next version of QGIS according to this QEP.
Thanks so much to the GDAL and QGIS contributors for adding such a nice feature ! It brings lots of possibilities for organizations that have to deal with great number of big raster and just want to explore part of it.
We are already thinking about further improvments (ease authentification, better integration with processing…), so if you’re willing to fund them or just want to know more about QGIS, feel free to contact us at infos+data@oslandia.com. And please have a look at our support offering for QGIS.
My main reasons for having Python data provider were:
This topic has been floating in my head for a while since I decided to give it a second look and I finally implemented it and merged for the next 3.2 release.
To make this possible I had to:
First, let me say that it wasn’t like a walk in the park: the Python bindings part is always like diving into woodoo and black magic recipes before I can get it to work properly.
For the Python provider sample implementation I decided to re-implement the memory (aka: scratch layers) provider because that’s one of the simplest providers and it does not depend on any external storage or backend.
For now, the main source of information is the API and the tests:
To register your own provider (PyProvider
in the snippet below) these are the basic steps:
metadata = QgsProviderMetadata(PyProvider.providerKey(), PyProvider.description(), PyProvider.createProvider) QgsProviderRegistry.instance().registerProvider(metadata)
To create your own provider you will need at least the following components:
QgsVectorDataProvider
)QgsAbstractFeatureSource
)QgsAbstractFeatureIterator
)Be aware that the implementation of a data provider is not easy and you will need to write a lot of code, but at least you could get some inspiration from the existing example.
Enjoy wirting data providers in Python and please let me know if you’ve fond this implementation useful!
/home/user/Qt/5.9.3/Src/
To build the sources, you can change into that directory and issue the following command – I assume that you have already installed all the dependencies normally needed to build C++ Qt programs – I’m using clang here but feel free to choose gcc, we are going to install the new Qt build into /opt/qt593
../configure -prefix /opt/qt593 -debug -opensource -confirm-license -ccache -platform linux-clangWhen done, you can build it with
make -j9 sudo make installTo build QGIS you also need three additional Qt packages QtWebKit from https://github.com/qt/qtwebkit (you can just download the zip):
/opt/qt593/bin/qmake WebKit.pro make -j9 sudo make installSame with QScintila2 from https://www.riverbankcomputing.com/software/qscintilla
/opt/qt593/bin/qmake qscintilla.pro make -j9 sudo make installQWT is also needed and it can be downloaded from https://sourceforge.net/projects/qwt/files/qwt/6.1.3/ but it requires a small edit in
qwtconfig.pri
before you can build it: set QWT_INSTALL_PREFIX = /opt/qt593_libs/qwt-6.1.3
to install it in a different folder than the default one (that would possibly overwrite a system install of QWT).
The build it with:/opt/qt593/bin/qmake qwt.pro make -j9 sudo make installIf everything went fine, you can now configure Qt Creator to use this new debug build of Qt: start with creating a new kit (you can probably clone a working Qt5 kit if you have one). What you need to change is the Qt version (the path to cmake) to point to your brand new Qt build,: