13.07.2013 Views

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

SHOW MORE
SHOW LESS

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

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!