PostGIS Raster : Extending PostgreSQL for The Support of ... - CoDE
PostGIS Raster : Extending PostgreSQL for The Support of ... - CoDE
PostGIS Raster : Extending PostgreSQL for The Support of ... - CoDE
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
Figure 6.8: <strong>The</strong> color legend interface.<br />
QGIS retrieves the temporal raster table from <strong>PostgreSQL</strong> using a connection string and a SQL<br />
command. <strong>The</strong> connection string is used to establish a connection to <strong>PostgreSQL</strong>. Its structure is<br />
’PG: dbname=%s host=%s user=%s password=%s port=%s’. <strong>PostgreSQL</strong> then executes the SQL<br />
command and outputs temporal raster table list as a result.<br />
6.3.1 Time Travel<br />
Loading Data<br />
To show the revolution in time <strong>of</strong> a set <strong>of</strong> temporal rasters, first <strong>of</strong> all, data need to be loaded<br />
from <strong>PostgreSQL</strong> into QGIS. <strong>The</strong>re exist two approaches <strong>for</strong> loading temporal raster (or map). <strong>The</strong><br />
first one attempts to load each map, one after another from <strong>PostgreSQL</strong> database into QGIS. When<br />
loading a map, there is a change from QGIS cursor to <strong>PostgreSQL</strong> cursor. That is because when QGIS<br />
establishes a connection to <strong>PostgreSQL</strong>, <strong>PostgreSQL</strong> will execute a request to retrieve a temporal raster<br />
row. When the map is loaded, necessary PyQt instructions like updating current time, progress slider<br />
bar etc. are need to be executed to show the evolution. In turn, a cursor change from <strong>PostgreSQL</strong> to<br />
QGIS occurs again be<strong>for</strong>e these instructions take place, as PyQt instructions are managed by QGIS<br />
cursor. <strong>The</strong>se steps are exactly what will happen to the next loaded map and so on until the final<br />
loaded map. This approach sounds cumbersome and involves a lot <strong>of</strong> execution time due to cursor<br />
changes.<br />
Figure 6.9: <strong>The</strong> loading map sequential approach.<br />
In the second approach, all maps are loaded into QGIS memory once and <strong>for</strong> all. Hence, only two<br />
cursor changes are needed (one from QGIS to <strong>PostgreSQL</strong> and another from <strong>PostgreSQL</strong> to QGIS).<br />
<strong>The</strong>n, the visibility <strong>of</strong> each map is simply handled by turning on or <strong>of</strong>f the check box corresponding to<br />
this map from the layers panel as described in the previous section. This approach reduces enormously<br />
execution time. Another advantage results from this is that all maps can be organized in an order<br />
(descending or ascending) by modifying the SQL command. <strong>The</strong> ordering can not happen in the first<br />
approach as each map is individually loaded.<br />
Pseudo code <strong>of</strong> function iniLayers that loads all layers into QGIS using the second approach:<br />
def iniLayers(self):<br />
Retrieve a list <strong>of</strong> temporal raster IDs to rids<br />
Change QGIS cursor to <strong>PostgreSQL</strong> cursor<br />
77