QGIS is an open source Graphical Information System. The term Graphical is there because it shows data on a map, and Information System refers to the use of underlying databases and data tables.
The application is backed up by a large community of users and developers, that meet regularly:
Annual User Conference
an annual user conference with talks and presentations covering a broad range of topics that are presented by users, showcasing how they use QGIS to solve their day to day analysis needs.
QGIS Open Day
On the last Friday of every month an informal virtual meeting is held to engage with the QGIS community. The agenda is dependent on the community and encourages a culture of collaboration and self-organisation
The list of meetings is maintained on this Wiki page
Plugins
QGIS is supported by a vast range of plugins. Over time more than 2000 plugins have been developed by the community. This enhances the functionality of QGIS application with thousands of free additional features. The vast majority of these plugins have been written in Python.
Amongst these plugins, there are also plugins that help you build your first plugin, and that update/reload your plugin, whilst it is being developed.
There are a lot of resources available online, that help you get started with building a plugin. I found the Udemy course to build a QGIS plugin very useful (and you can’t complain about the price). Also the following video on YouTube is very helpful.
If you search using Google for GitHub QGIS plugin you’ll find many plugins that have their codebase maintained on GitHub.
You are free to store your plugin locally on your computer, but if you want to share the plugin with the QGIS community, there is a process that you need to follow to publish the plugin on the QGIS plugin repository. The repository is very convenient as it maintains a history of previous versions of your plugin.
Once approval has been granted to use the QGIS plugin repository, the process of uploading and updating a plugin is very straightforward.
Editing your Python project can be done using a Community Edition of Pycharm, or alternatively, by installing the Visual Studio “VS Code” editor enhanced with several plugins to develop Python.
As VS Code is gaining popularity and is backed up by Microsoft, I opted for this code editor. Initially, I had some issues trying to debug my Python Plugin using VS Code, as discussed in this blog entry, but once solved, it provides a very effective working environment.
Roll
1. Introduction
Roll is a plugin aimed at designing and evaluating 3D seismic survey geometries, using a hierarchical and template based approach. Once templates have been defined, you can run a ‘basic’ binning analyses that are shown as ‘attribute maps’ in the survey area.
Attribute maps
- A fold map that shows (offset dependent) fold
- A minimum offset map that `shows minimum offsets coverage
- A maximum offset map that shows maximum offsets coverage
- A RMS offset increment map that shows regularity of offset increments
When you carry out a ‘full’ binning analysis, additional information becomes visible under the Analysis tab
Analysis tab
- Offset/azimuth histogram for all traces in the selected binning area, in steps of 5 degrees
- A trace table, showing the information from the analysis file
- Radial offsets shown for a line in the inline direction
- Radial offsets shown for a line in the x-line direction
- Source -> receiver azimuths shown for a line in the inline direction
- Source -> receiver azimuths shown for a line in the x-line direction
- Kr stack response shown for a line in the inline direction
- Kr stack response shown for a line in the x-line direction
- Kxy stack response shown for a single bin
- |Offset| histogram for all traces in the selected binning area
Roll uses a hierarchical approach to define one or more survey templates
Survey hierarchy
- Each survey consists of one or more (rectangular) blocks
- Each block contains at least two templates:
- One for receiver layout
- One for source layout
- Each template contains one or more seeds
- A seed defines the starting location of a single source / receiver
- Each seed can be grown up to three times
- The 1st grow step changes a seed position into a line segment (sequence) of positions
- The 2nd grow step changes a line segment into a multitude (grid) of lines
- The 3rd grow step changes the grid into a sequence of (intertwined) grids
- The seeds, combined with their grow steps, define the active sources and receivers in a template
- Each template can be rolled in up to three directions, for instance:
- Firstly in the inline direction, at source line intervals
- Secondly in the crossline direction, at receiver line intervals
- Optionally at a skew angle for fancy designs
The survey hierarchy is reflected in the xml-based survey-file structure, as shown in the following excerpt:
<block_list>
<block>
<name>Block-1</name>
<borders>
<src_border xmin="-20000.0" xmax="20000.0" ymin="-20000.0" ymax="20000.0"/>
<rec_border xmin="0.0" xmax="0.0" ymin="0.0" ymax="0.0"/>
</borders>
<template_list>
<template>
<name>Template-1</name>
<roll_list>
<translate n="10" dx="0.0" dy="200.0"/>
<translate n="10" dx="250.0" dy="0.0"/>
</roll_list>
<seed_list>
<seed x0="5975.0" src="True" y0="625.0" argb="#77ff0000" typno="0" azi="False" patno="0">
<name>Src-1</name>
<grow_list>
<translate n="1" dx="250.0" dy="0.0"/>
<translate n="4" dx="0.0" dy="50.0"/>
</grow_list>
</seed>
<seed x0="0.0" src="False" y0="0.0" argb="#7700b0f0" typno="0" azi="False" patno="1">
<name>Rec-1</name>
<grow_list>
<translate n="8" dx="0.0" dy="200.0"/>
<translate n="240" dx="50.0" dy="0.0"/>
</grow_list>
</seed>
</seed_list>
</template>
</template_list>
</block>
</block_list> 2. Editing a survey file
As it is cumbersome to manipulate xml-data directly, the user is helped on two levels:
- Creating a new project can be done using a survey wizard. At present there are separate wizards to generate templates for land seismic and/or OBN-data. A marine wizard has been made to create streamer surveys.
- Parameters can be modified added or deleted from the property pane. Behind the scenes, this updates the xml-structure, which is always visible from the Xml-tab in the main window.
But if you get familiar with the xml-structure, you could edit the xml data directly and apply any changes using the ‘Refresh Document‘ toolbar button
3. Geometry files
The templates can be converted into geometry files, consisting of (a) a source file, (b) a receiver file and (c) a relation file, similar how this is managed in the SPS format. The source- and receiver points from the source and receiver files can be exported to the current QGIS project as an ArcGIS Shape file, where these points can be inspected, moved around or deleted. Edited points can be re-imported into Roll to assess the impact on fold, etc.
The geometry files themselves can also be exported as SPS-files, and the source and receiver locations can be exported to the current QGIS project, to be shown on the map. These locations can be edited (deleted, shifted) and can be imported back into Roll, for an updated analysis.
Note: Qt5 takes care of the widgets shown in QGIS. The Model/View approach used by Qt5 allows for fairly large tables. Nevertheless, circa 12 bytes are allocated for each row in a table view. For very large tables, QGIS will simply crash without any warning. As a result the GUI will 'hang' and you may lose all your work. For that reason, the trace table has been limited to 50 million traces. Larger tables can still be used without any problems, traces are just not shown in the trace table. If you need detailed information from a large survey, the current solution is to select a smaller binning area, such that the total number of traces (Nx x Ny x Fold) is less than 50 million. This is a bit of a workaround. A 'proper' solution is being contemplated.
4. Legacy SPS data
If (legacy) SPS data is available, this can be imported from the file menu, and is treated the same as the internally generated geometry files. This makes it handy to analyze survey performance based solely on SPS-data. This SPS data can also be exported as shapefiles to the current QGIS project.
As there are many flavors of SPS files, a number varieties have been predefined, and can be selected from File -> Settings. The SPS-flavors are kept in a list of available Python dictionaries kept in config.py.
The user can expand this list with new SPS ‘flavors’, by defining new ‘point’ and ‘relational’ record formats and store these in the config.py file.
5. External dependencies
Roll depends on the following Python libraries that need to be installed separately In the OSGeo4W Command Shell, type: pip install --upgrade 'library-name', where –upgrade forces the installation of the latest version
| Library | Minimum Version | Description/purpose |
|---|---|---|
| numba | 0.59.1 | Significantly speed up some numpy calculations |
| numpy | 1.26.24 | Array and matrix manipulation |
| pyqtgraph | 0.13.4 | Plotting of vector and raster data |
| rasterio | 1.3.9 | Export of figures as GeoTiff files |
| wellpathpy | 0.5.0 | Handle sensors & sources in a well trajectory (VSPs etc.) |
| ptvsd | 4.3.3 | Needed if you want to debug routines that run in a worker thread |
5. Status
On 8 Feb 2024, the first release of Roll has been published on GitHub. Initial release on the QGIS plugin website occurred on 13 March 2024.
As of version 3.3.3 Roll is no longer considered an experimental plugin. But there is still some functionality left to be added. See ‘To Do’ section.
Furthermore, see the ‘Changelog’ for already implemented functionality. Any Issues or pull requests can be raised through the GitHub repository, that you can find here.
6. To Do
The following improvements are yet to be made:
- Improve handling of SPS data
- Related to this, improve the interface with QGIS to manipulate SPS data
- Make processing of Geometry & SPS data more robust
- Improve speed of loading large parameter sets in the Property pane (mainly affecting streamer surveys, using fanning)
- Improve Roll’s analysis capabilities
- Use multiprocessing instead of a worker thread to speed up background tasks
- Consider using a relational database instead of numpy arrays for geometry tables