recent news about RasterLite2

[sandro furieri]

Hi List,

the development cycle of librasterlite2 is finally restarted;

we are now going toward the release of the first "stable"

version. A preliminary Release Candidate (including pre-built 

binaries for Windows) is expected during the next weeks.

Linux developers could eventually start their own testing

by downloading the latest sources from the Fossil repo.

Relevant changes since the last commit:

- a massive API breakage occurred: more than half of the

  SQL functions changed their signatures. the same is

  for the C API

- the version number is now 1.1, so to avoid any possible

  confusion with previous versions (1.0-xx).

a short rationale: 

the previous version wasn't able to robustly support 

Raster/Vector Coverages stored within any ATTACHED

DB; many dangerous and potentially harmful conflicts

could eventually arise when accessing any Coverage

outside the MAIN DB.

the new layout is as follows:

- WRITE operations (creating or dropping a coverage,

  populating its tiles, (re)building its multi-resolution

  pyramids and so on) will always assume that the target

  coverage should be located into the MAIN DB; and 

  consequently there is no need at all to explicitly

  specify the prefix identifying the ATTACHED DB.

  in other words: all API of this group have remained

  unchanged.

- READ operations (extracting a raster subset, generating

  a styled image and alike) are now fully supported also

  when the target coverage is stored into some ATTACHED

  DB. So all the API of this second group will now require 

  a further argument intended to specify the prefix of 

  the intended ATTACHED DB; passing a NULL value as the

  DbPrefix is a legal option, and in this case the

  MAIN DB will be implicitly assumed.

  

side note:

all resources required for correctly rendering a

Coverage (fonts, styles, svg or bitmap symbols ...)

will now be always searched within the same DB where

the Coverage is actually stored.

So an ATTACHED DB can now be safely used as an

independent and self-contained repository supplying

a fully styled background (= read-only) map.

All active Layers (subject e.g. to edit operations 

and thus requiring unrestricted ReadWrite access) 

should instead be located within the MAIN DB.

The new layout is obviously much more flexible and

powerful, so the massive API breakage is just a small 

price we are paying now so to ensure many future

benefits.

The SQL documentation page [1] has already been

updated so to reflect the most recent API.

[1] https://www.gaia-gis.it/fossil/librasterlite2/wiki?name=sql_reference_list

bye Sandro