Back to <a Atlas Index</a><hr><br>
<table cellspacing="6" cellpadding="6" bgcolor="#f0f0b0"><tr><td>
First of all you need to download the <a image</a> for <b>Blue Marble NG 2km</b> supplied by <b>NASA</b>
that is a really huge image of about <b>173 MB</b>.<br><br>
That's not enough, because the TIFF supplied by NASA lacks any useful georeferencing information, so you need too a companion <b>WorldFile</b> that you can download from <a href="">here</a>.<br>
<b>Note</b>: both files <b>land_shallow_topo_21600.tif</b> and <b>land_shallow_topo_21600.tfw</b> must be placed on the same directory.<br><br>
Now you are finally ready for creating and initializing the <b>blue marble Raster Coverage</b>

<h2>First approach: using the wizards supported by the GUI</h2>
<table width="100%" cellspacing="6" cellpadding="6" border="1">
<tr><td>
<table cellspacing="8" bgcolor="#b0f0b0"><tr><td>
Now execute <b>spatialite_gui</b> and create en empty, brand new database.<br><br>
The side figure shows the <b>menu item</b> you have to select for <b>Creating a Raster Coverage</b>.

</td><td width="60%"><img alt="bluem-01" width="100%">

<tr><td>
<table cellspacing="8" bgcolor="#b0f0b0"><tr><td>
Creating a <b>Raster Coverage</b> implies defining several arguments; let's see all them by omogeneous functional groups:
<ul>
<li>Defining the identity of the Raster Coverage<ul>
<li>We need to specify a <b>Name</b>, a <b>Title</b> and an
<li><b>Note</b>: using clear and meaningful values is a warmly suggested good practice.</li>
<li><b>Warning</b>: the <b>Name</b> is the <b>Primary Key</b>, so you must ensure to use unique values.</li>

<li>Defining the structure of <b>Pixels</b> and choosing an appropriate <b>Compression</b> method:<ul>
<li><b>BlueMarble</b> corresponds to a True Color image, and consequently:<ul>
<li>The interpretation of Pixels will then be <b>RGB</b>:<ul>
<li>This automatically implies <b>3 bands</b> (one for <b>Red</b>, one for <b>Green</b> and one for
<li>Each band will occupy 1 byte (<b>UINT8</b>) so to store intensity values ranging from <b>0</b> to

<li>In order to save disk space we'll adopt the <b>Jpeg2000 lossy compression</b>:<ul>
<li>This compression algorithm supports <b>configurable quality</b>: we'll set a very aggressive value as low as only
<li>Thanks to the advanced capabilities of Jpeg2000 this will cause a very strong compression still preserving a fairly good visual appearence.</li>
<li><b>Note</b> Jpeg2000 is reasonably fast when decompressing, but is really heavy and slow when compressing.</li>

<li><b>BlueMarble</b> doesn't contain any pixel of <b>unspecified value</b>, so <b>NODATA</b> will be set to


<li>Defining a <b>Reference System</b> and the <b>Spatial Resolution</b>:<ul>
<li><b>BlueMarble</b> is a worlwide Coverage, so the <b>SRID</b> will be set as <b>4326 WGS84</b><ul>
<li><b>Note</b>: this is a <b>geographic</b> Reference System, and consequently the Coordinates will be expressed as <b>Longitude</b> and <b>Latitude</b> angles. The <b>Unit of Measure</b> will be
<li>The dimension for each Pixel will be <b>0.01666667</b> degrees (on both axes).</li>
<ul></li>

</ul>

<br><br>
<table cellspacing="8" bgcolor="#f0f0b0"><tr><td>
Why we've set a Pixel Resolution of <b>0.01666667</b> ?<ul>
<li>The TIFF image has an overall dimension of <b>21600</b> x <b>10800</b> Pixels.</li>
<li><b>Latitudes</b> range from <b>-180</b> to <b>+180</b>, so the horizontal Map Extension is <b>360</b> degrees.</li>
<li><b>Longitudes</b> range form <b>+90</b> (<i>North Pole</i>) to <b>-90</b> (<i>South Pole</i>), so the vertical Map Extension is <b>180</b> degrees.</li>
<li><b>360.0 / 21600.0  = 0.01666667</b> (<i>horizontal dimension of a single
<li><b>180.0 / 10800.0  = 0.01666667</b> (<i>vertical dimension of a single
</ul>

</td><td align="center"><img alt="bluem-02">

<tr><td>
<table cellspacing="8" bgcolor="#b0f0b0"><tr><td>
All right, we've jus created an empty <b>Raster Coverage</b>; we are now ready for populating it by importing the corresponding TIFF image.<br><br>
The side figure shows the <b>menu item</b> you have to select for <b>importing</b> one (or more) Raster files(s).

</td><td width="60%"><img alt="bluem-03" width="100%">

<tr><td>
<table cellspacing="8" bgcolor="#b0f0b0"><tr><td>
First of all you need to select <b>land_shallow_topo_21600.tif</b> as the file to be imported.<br>
Eventually you might select multiple files at once, but this isn't the case because <b>BlueMarble 2km</b> is just a single TIFF image.<br><br>
<b>Very important</b>: the TIFF supplied by NASA lacks any internal georeferencing info (it's not a <b>GeoTIFF</b>), so you need to specify that a <b>companion WorldFile</b> is required, and that the <b>SRID</b> value must be unconditionally forced.<br><br>
Last detail: we'll ask to immediately build the <b>multi-resolution Pyramid</b>, so to get a Raster Coverage immediately ready to be visualized on the Map afer completing the import process.

<br><br>
<table cellspacing="8" bgcolor="#f0f0b0"><tr><td>
<b>Remember</b>: as we've already seen while creating the Raster Coverage the <b>Jpeg2000</b> compression is heavy and really slow.<br>
So in order to speed up the import process you must enable <b>parallel processing</b>, that just requires executing a single SQL statement:
<verbatim>
SELECT RL2_SetMaxThreads(32);
</verbatim>
The more parallel threads you authorize, the greater will be the increase in speed: but be cautious and never exaggerate, because too many threads may imply performance degradation.

<br><br>
<table cellspacing="8" bgcolor="#f0f0b0"><tr><td>
<h4>What is the mysterious WorldFile ?</h4>
It's just a plain text file specifying how the imported image has to be anchored to the Map.
<verbatim>
0.01666667
0.0
0.0
-0.01666667
-180.000000
90.000000
</verbatim>
<ul>
<li>first line corresponds the the <b>horizontal dimension</b> of each Pixel.</li>
<li>second and third lines corresponds to an eventual rotation (that is not required in this case).</li>
<li>fourth line corresponds the the <b>vertical dimension</b> of each Pixel.<br>
It must be a <b>negative value</b> because <b>Latitude</b> decreases going from top to bottom.</li>
<li>fifth and sixth lines respectively correspong to the <b>Longitude</b> and <b>Latitude</b> of the <b>upper left corner</b> of the imported image, the so called <b>tie
</ul>

</td><td align="center"><img alt="bluem-04">

<tr><td>
<table cellspacing="8" bgcolor="#b0f0b0"><tr><td>
The import process is finished; you are now ready for testing the <b>BlueMarble</b> Raster Coverage.
<ul>
<li>Open a <b>Map
<li>Then attach <b>BlueMarble</b> to it</li>
<li>As you can directly check by yourself anything works nicely as expected.</li>
</ul>

<br><br>
<table cellspacing="8" bgcolor="#f0f0b0"><tr><td>
<b>Notice</b>: this is a very infrequent case. It happens just because <b>BlueMarble</b> is based on <b>RGB</b> Pixels that doesn't require any <b>Style</b> to be specified; the <b>default style</b> is already perfectly fit.<br><br>
Many others Raster Coverages will require instead to specify some appropriate <b>Style</b> in order to be correctly displayed, as we'll see soon in the next step of this tutorial.

</td><td width="60%"><img alt="bluem-05" width="100%">

</table><br>
<hr>
<h2>Alternative approach: using SQL functions</h2>
Both <b>SpatiaLite</b> and <b>RasterLite2</b> always offer full SQL support for all functionalites.<br>
Also in the case of managing Raster Coverages (creating, populating, configuring and so on).<br><br>
The following SQL functions are supplied by <b>RasterLite2</b> and you can learn more about them from <a
<ul>


</ul>
<br><br>
Further SQL functions are supplied by <b>SpatiaLite</b> and you can learn more about them from <a
<ul>


</ul>
<br>
<hr>
<h2>Where we are</h2>
<table cellspacing="8" bgcolor="#b0f0b0"><tr><td>
You've just completed the first step of the <b>World Atlas</b> tutorial, and you are now expected to have acquired some basic skills about <b>Raster Coverages</b><br><br>
So now return to the <b>index</b> and pass to next topic where we'll examine the <b>ETOPO1</b> Raster Coverage.

<br><br><hr><br>
Back to <a Atlas Index</a>