rasterlite2 - mixed resolutions

[jonnieba...@gmail.com]

Apologies if I've missed something but the sql reference list seems to infer that it it is possible to add different resolution sections to the same coverage

RL2_CreateCoverage ( coverageName String , sampleType String , pixelType String , numBands Integer , compressionType String , quality Integer , tileWidth Integer , tileHeight Integer , SRID Integer , horzPixelResolution Double , vertPixelResolution Double , noDataPixel BLOB , strictResolution Integer , mixedResolutions Integer , sectionPaths Integer , sectionMD5 integer , sectionSummary Integer ) : Integer

However, I've been unable to find any references to it in the sources and attempts to import mixed resolutions have failed. Nor can I find any policies tables in a newly created db. Am I right in thinking that mixed resolutions are no longer permitted or have I missed something obvious?


Many thanks - jonnie

[a.fu...@lqt.it]

Hi Jonnie,

first of all a general order clarification:
after the initial release of Release Candidate #0 (RC0) rasterlite2
further evolved in many new directions, and still is under active
development in many critical areas.
many new low-level features were fully implemented during last months
but are practically "invisible" at the user level simply because the
corresponding hi-level methods are still waiting to be implemented;
in other words, many interesting and well promising things currently
are only "half implemented" and/or haven't yet reached their full
mature stability.

more precisely: it's not simply an evolution process affecting
RasterLite2 alone.
many relevant details imply introducing some other change in
libspatialite. so you can get a full comprehension of this complex
transition process only after considering recent changes happened
in both splite and rl2 altogether.

sadly enough, the available documentation still corresponds to
the RC0 phase, so it's now rather obsolete and may be misleading
when using the more recent development sources.

the current priority of these weeks is now releasing spatialite
4.3.0, so to definitely stabilize first the spatialite side.
after reaching this significant milestone will be then able to
focus our attention on completing the rasterlite2 side.


On Tue, 26 May 2015 10:33:18 -0700 (PDT), jonnieba...@gmail.com
wrote:

> Apologies if I've missed something but the sql reference list seems
> to
> infer that it it is possible to add different resolution sections to
> the same coverage
>

yes, confirmed

> However, I've been unable to find any references to it in the sources
> and attempts to import mixed resolutions have failed.
>

this was probably due to the poor current state of the supprting
documentaion.

> Nor can I find any policies tables in a newly created db.
>

this simply is because accordingly to the more recent DB-layout
all informations defining a Raster Coverage have now been relocated
directly into the "raster_coverages" meta-table and there is no
longer any separate policy table.

> Am I right in thinking that mixed resolutions are no longer permitted
>

no, the opposite is true

> or have I missed something obvious?
>

partially correct but not completely true: reality is that in its
current
development state rasterlite2 is exactly in the middle of a complex
transition step, too many things are still waiting to reach their final
stable asset, other could have pssibly gone broken and still waiting
for some appropriate fix.

bye Sandro

[jonnieba...@gmail.com]

Many thanks for the information - I tried to find the appropriate entries in the raster_coverages meta table but none exist in my spatialite databases. I will patiently await an updated version
Many thanks - jonnie

[a.fu...@lqt.it]

On Wed, 27 May 2015 01:50:52 -0700 (PDT), jonnieba...@gmail.com
wrote:

> Many thanks for the information - I tried to find the appropriate
> entries in the raster_coverages meta table but none exist in my
> spatialite databases.
>

Hi Jonnie,

this the most recent definition of raster_coverages (splite 4.3.0):

CREATE TABLE raster_coverages (
coverage_name TEXT NOT NULL PRIMARY KEY,
title TEXT NOT NULL DEFAULT '*** missing Title ***',
abstract TEXT NOT NULL DEFAULT '*** missing Abstract ***',
sample_type TEXT NOT NULL DEFAULT '*** undefined ***',
pixel_type TEXT NOT NULL DEFAULT '*** undefined ***',
num_bands INTEGER NOT NULL DEFAULT 1,
compression TEXT NOT NULL DEFAULT 'NONE',
quality INTEGER NOT NULL DEFAULT 100,
tile_width INTEGER NOT NULL DEFAULT 512,
tile_height INTEGER NOT NULL DEFAULT 512,
horz_resolution DOUBLE NOT NULL,
vert_resolution DOUBLE NOT NULL,
srid INTEGER NOT NULL,
nodata_pixel BLOB NOT NULL,
palette BLOB,
statistics BLOB,
geo_minx DOUBLE,
geo_miny DOUBLE,
geo_maxx DOUBLE,
geo_maxy DOUBLE,
extent_minx DOUBLE,
extent_miny DOUBLE,
extent_maxx DOUBLE,
extent_maxy DOUBLE,
strict_resolution INTEGER NOT NULL,
mixed_resolutions INTEGER NOT NULL,
section_paths INTEGER NOT NULL,
section_md5 INTEGER NOT NULL,
section_summary INTEGER NOT NULL,
is_queryable INTEGER,
red_band_index INTEGER,
green_band_index INTEGER,
blue_band_index INTEGER,
nir_band_index INTEGER,
enable_auto_ndvi INTEGER,
CONSTRAINT fk_rc_srs FOREIGN KEY (srid) REFERENCES spatial_ref_sys
(srid));

if you have something different in your DB this almost surely means
that you are linking some obsolete version of libspatialite unable to
adequately suppprt RL2 expectations.

note: in the current phase any attempt to build librasterlite2 from
Fossil
sources will always require building first libspatialite from Fossil
sources.
in order to avoid any possible conflicting configuration both libraries
must be kept in exact synchronization.

bye Sandro