Not logged in

Back to main Wiki page

Changes introduced starting since version 1.8.0

1 - Executing multiple SQL statements in a single shot

multiple SQL statements
The execution of multiple SQL statements in a single pass is now supported:

2 - DB connections and Security modes

As you probably remember, there are few SQL functions supported by SpatiaLite that could eventually pose some security concern because they implement some kind of direct data exchange between the DB and the local file-system.
In the worst possible scenario an hypothetical hacker could eventually attempt to attack an external system by offering for download a purposely forged SpatiaLite DB containing maliciously forged Triggers, and the user will then be completely unaware of such a potentially dangerous threat.

The standard approach implemented by libspatialite is the one to always keep completely disabled all these potentially harmful SQL functions, unless the environment variable SPATIALITE_SECURITY=relaxed is explicitly set by the user.
Now spatialite_gui support a smarter and easiest approach, completely based on internal actions and no longer requiring any explicit user action.

not connected
Please note: now a small icon always shows the status of the current DB Connection.

case A) connecting to a sane DB

security relaxed
spatialite_gui will now always perform a preliminary sanity check before connecting to an existing DB.

case B) starting a READ ONLY DB connection

security read only

case C) connecting to a potentially harmful DB

security alert
In the unlucky case, when the preliminary security check identifies some problematic Trigger, an appropriate security alert will mmediately be raised.

security lock

3 - RasterLite2 integrated support

Starting since version 2.0.0 librasterlite2 will become an integral part of spatialite_gui (i.e. it will become a not configurable mandatory dependency).

3.1 - Raster Coverages

raster coverages 1
All RasterCoverage-related tables will be hierarchically grouped as a distinct branch of the Tables Tree.

raster coverages 2
Administering all SLD/SE Styles for each single Raster Coverage will now be directly accessible via the corresponding context menu.

3.2 - SLD/SE Styles administration

3.2a - Adding a new Raster Style for a given Coverage

You can access this feature from the context menu, which will apply to the corresponding Raster Coverage.

raster styles 1
You should first select the XML document, from the file-system, containing the SLD/DE Style you intend to load.

raster styles 2
After the file selection and pressing 'OK', the XML document will be parsed and formally checked for full Schema validation as a valid SLD/SE Raster-Symbolizer.
If no error is found then the Style will be immediately added to the Coverage.

3.2b - Listing all Raster Styles for a given Coverage

You can access this feature from the context menu, which will apply to the corresponding Raster Coverage.

raster styles 3

raster styles 4
Differently from the above case you can now select multiple files in a single pass.

raster styles 5
Then each single XML document will be loaded (with a validation check being done for each selected XML document).

raster styles 6
You could eventually remove some already defined Style; just left-click on the corresponding row.

raster styles 7
After final confirmation the selected Style will be definitely removed from the Coverage.

3.3 - Coverage Tiles Preview

tile preview 1
For each <coverage-prefix>_tile_data table (which contains the raster tiles) a preview feature is supported.

tile preview 2
Each tile will be shown accordingly to the Coverage's default style.

tile preview 3
In the case of tiles adopting some exotic pixel format not directly corresponding to a plain RGB color model (e.g. UINT32, FLOAT or DOUBLE) a default grayscale rendering will be adopted.
In the case of multi-band pixels only the first band (Band #0) will be shown.

Back to main Wiki page