spatialite_gui-2.0.0-devel: current state of the art

[sandro furieri]

spatialite_gui is currently in the middle of a deep restructuring
process, certainly the most ambitious and relevant ever experienced
since the initial release of this tool.

the intended final goal for spatialite_gui-2.0.0 "stable" will be the
one to integrate a well extended and comprehensive support for both
libspatialite and librasterlite2.
this will enable users to interact in the most painless and easiest way
with complex db-files containing a whole (and may be highly sophisticated)
"map" within a single monolithic repository shipping altogether:
- vector data
- raster data
- any related rendering style (based on SLD / SE standards)
- all required graphic resources (i.e. bitmap symbols, SVG symbols,
  TrueType fonts and so on)
 
the main processing tool will obviously still continue to remain
based on executing "hand written" SQL statements.
anyway several ad hoc GUI wizards will be supported so to simplify
as much as possible the most common routinely operations (as e.g.
creating and populating a raster coverage, creating and handling
SLD/SE styles and so on).


where we currently are
----------------------
- support for vector data (Spatial SQL) is complete, well mature
  and affordable; in this specific area we can safely assume that
  we've reached the final configuration.
 
- on the other hand support for raster data and SLD/SE styling still
  is rather sparse, incomplete and not yet fully self-consistent;
  and of course, it's not yet extensively tested and stable.
  Here the main blocker obviously is in that RasterLite2 has not yet
  reached its final "stable" configuration and still is under very
  active development.
 
==================================================================

I easily imagine that for many users spatialite_gui is intended
to be the most obvious and most familiar tool supporting SpatiaLite.

Exactly for this reason I decided to release a preliminary snapshot
of the still  incomplete spatialite_gui-2.0.0 as a companion to 4.3.0:
after all the traditional GUI core based on libspatialite is mature
enough to be safely used even in a production environment.
it's only the raster support based on librasterlite2 that currently
is rather unstable and largely immature.

accordingly to all the above considerations the ./configure script
supporting spatialite_gui now accepts a further option:

./configure --enable-rl2extra

the default setting will always be "disabled", i.e. all new unstable
features specifically intended to support RasterLite2 will be
completely suppressed in any standard build.
this is the suggested setting for any public release intended to
support libspatialite-4.3.0 "stable".

enabling the "experimental" extended RL2 support still continues
to be a supported option, but is now strictly reserved to developers
wishing to perform advanced testing (and usually expected to always
start from some custom build based on fresh sources directly
extracted from the most recent snapshot available from the Fossil
repositories).

bye Sandro

[linux...@gmail.com]

On Monday, June 29, 2015 at 11:27:38 AM UTC+2, sandro furieri wrote:

accordingly to all the above considerations the ./configure script
supporting spatialite_gui now accepts a further option:

./configure --enable-rl2extra

the default setting will always be "disabled", i.e. all new unstable
features specifically intended to support RasterLite2 will be
completely suppressed in any standard build.
this is the suggested setting for any public release intended to
support libspatialite-4.3.0 "stable".

enabling the "experimental" extended RL2 support still continues
to be a supported option, but is now strictly reserved to developers
wishing to perform advanced testing (and usually expected to always
start from some custom build based on fresh sources directly
extracted from the most recent snapshot available from the Fossil
repositories).

Would it be possible to not require the availability of librasterlite2 when the rl2extra option is disabled?

With todays spatialite-gui 2.0.0-devel release librasterlite2 is still required for the build even though its features aren't used.

Or am I misunderstanding the intention of the option?

Kind Regards,

Bas

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

On Mon, 29 Jun 2015 15:36:21 -0700 (PDT), linux...@gmail.com wrote:
> Would it be possible to not require the availability of
> librasterlite2
> when the rl2extra option is disabled?
>
> With todays spatialite-gui 2.0.0-devel release librasterlite2 is
> still
> required for the build even though its features aren't used.
>
> Or am I misunderstanding the intention of the option?
>

Hi Bas,

a short historical review surely useful to understand better:
- since very remote times spatialite_gui depended on an external
library specifically intended to support image codecs and a
2D graphics canvas based on Cairo.
- before 2013 this helper library was libgaiagraphics
- then starting since 2013 libgaiagraphics was discontinued and
librasterlite2 was adopted as a full replacement.

the "BLOB explorer" module is widely based on librasterlite2,
and is exactly this library that is expected to implement the
low-level APIs supporting the following tasks:
- image decoding: not only limited to the most obvious GIF,
PNG, TIFF and JPEG but extended also to JPEG2000, WebP,
CharLS and all other tile-formats internally supported by
librasterlite2 itself (RAW/uncompressed, DEFLATE and LZMA)
- vector geometry preview based on Cairo.

So librasterlite2 was always intended to be a structural
dependency for spatialite_gui, and still continues to be.

The recently introduced --enable-rl2extra build option doesn't
minimally affects any GUI tool or wizards already supported
on all previous versions of spatialite_gui.

What --enable-rl2extra really does is making optional the
inclusion of about a dozen of brand new wizards introduced
starting since 2.0.0 and mainly intended as a GUI alternative
to the command line rl2tool:
- creating and configuring Raster Coverages
- loading external raster data into Raster Coverages
- creating pyramidal multi-resolution levels
- managing SLD/SE styles supporting Raster Coverages

all this very recently introduced tasks clearly are in a
still immature "experimental" state and their inclusion in
any general-purpose release isn't a safe option.
anyway different tools of spatialite_gui presenting a
well established historical continuity during the years
(as e.g. the Blob Explorer) still continue to depend
on librasterlite2.

bye Sandro

[Bas Couwenberg]

Hi Sandro,

Thanks for the detailed explanation, it clarifies my misunderstanding very well.

I'm mostly concerned about spatialite-gui 2.0.0 and librasterlite2 as
part of the upcoming spatialite transition in Debian, because we
really need something newer than SpatiaLite 4.1.1.

With the plans described in the '2015 roadmap' thread it's clear that
we shouldn't wait for a librasterlite2 stable release (and
spatialite-gui 2.0.0) because that's not expected soon unlike the
final SpatiaLite 4.3.0 release.

Kind Regards,

Bas

> --
> You received this message because you are subscribed to a topic in the
> Google Groups "SpatiaLite Users" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/spatialite-users/JuOFbHNuujc/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> spatialite-use...@googlegroups.com.
> To post to this group, send email to spatiali...@googlegroups.com.
> Visit this group at http://groups.google.com/group/spatialite-users.
> For more options, visit https://groups.google.com/d/optout.



--
Disclaimer: Any errors in spelling, tact, or fact are transmission errors.

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

On Tue, 30 Jun 2015 09:50:13 +0200, Bas Couwenberg wrote:
> With the plans described in the '2015 roadmap' thread it's clear that
> we shouldn't wait for a librasterlite2 stable release (and
> spatialite-gui 2.0.0) because that's not expected soon unlike the
> final SpatiaLite 4.3.0 release.
>

certainly yes: the intended scope of introducing --enable-rl2extra
exactly is the one to allow building and distributing a safe, stable
and robustly affordable transitional version of spatialite_gui
effectively supporting libspatialite-4.3.0

bye sandro

[Micha Silver]

Can I suggest two small (?) GUI enhancements?

How about a keyboard key for running a query, like F5 in PgAdmin3?

When I create a spatial view, I have to manually enter a row in the views_geometry_columns table. In the GUI. After typing the items there is the right-click and "Confirm Insert". I usually make some typo, and the whole row disappears. So I have to guess where the prob is, and retype everything. Is it possible to leave the details in the "Insert new row" window, to avoid retyping (and then making a second error...)

Thanks,
Micha

--
You received this message because you are subscribed to the Google Groups "SpatiaLite Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to spatialite-use...@googlegroups.com.