discussion: changing ./configure default settings ?

[Alessandro Furieri]

the problem:

------------

starting since version 5.0.0 libspatialite supports

Topology and Ground Control Points (GCP).

the first depends on librttopo, that is licensed

under GPL terms.

the second depens on code borrowed from GRASS-GIS

that was initially released under GPL terms.

the net effect is that by enabling one of these

modules (or both) will automatically trigger a

license escalation, and the whole libspatialite

will so implicitly become GPLed (note that this

is nicely allowed by the MPL tri-license).

a GPLed library could easily be far from the ideal

for several users, and after all supporting Topology

and GCP is not necessarily interesting for everyone,

so activating these "special" capabilities was

initially disabled by default in ./configure

./configure --enable-rttopo --enable-gcp

consequently, explicitly enabling this GPLed

modules was required, thus intending an

informed consent.

issues emerging from version 5.0.1

----------------------------------

this last version implements full close integration

of libspatialite and librasterlite2, but this

necessarily requires Topology support.

if not, many SQL functions will unexpectedly

fail, thus causing havoc in the testcoverage.

proposed change

---------------

- reverting the default setting for both rttopo  

  and gcp, so to make --enable-rttopo and

  --enable-gcp the default standard option.

  in this case a final message will be shown

  (as it already happens) informing about

  the GPL license escalation.

- users not intending to activate any GPLed

  module could still continue to disable them

  by explicitily launching

  ./configure --disable-rttopo --disable-gcp

  and in this case a final message will warn

  that under such conditions the testcoverage

  will become crazy.

  

your opinions about the opportunity of this change

will be greatly appreciated.

bye Sandro

[br...@frogmouth.net]

It looks like the control points really is optional, based on code inspection and trying it. Its a nice feature but probably niche application. All tests pass with it disabled (even check_control_points, although its not actually testing anything because of the #ifdef). So I think that part is OK to leave for now.

Topology is harder to judge. If I create a database with an rttopo featured spatialite, will I be able to read the data with a non-rttopo (I.e. current default build)spatialite? Clearly I won't be able to use any SQL function that is built on rttopo, and may not be able to edit. That compatibility is pretty important condition for the way forward.

Brad

--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/spatialite-users/6878242b-4710-4d0b-87d4-329e23d16e71n%40googlegroups.com.

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

On Wed, 27 Jan 2021 21:37:21 +1100, br...@frogmouth.net wrote:
> It looks like the control points really is optional, based on code
> inspection and trying it. Its a nice feature but probably niche
> application. All tests pass with it disabled (even
> check_control_points, although its not actually testing anything
> because of the #ifdef). So I think that part is OK to leave for now.
>

Hi Brad,

I'm very happy to hear from you again.
yes, you are right: GCP plays no role on the DB schema, and keeping
it disabled doesn't forbid creating a full SpatiaLite-5 layout.

however it's required by librasterlite2 because affine trasformations
are a key component for rasters' reprojection.

> Topology is harder to judge. If I create a database with an rttopo
> featured spatialite, will I be able to read the data with a
> non-rttopo
> (I.e. current default build)spatialite? Clearly I won't be able to
> use
> any SQL function that is built on rttopo, and may not be able to
> edit.
> That compatibility is pretty important condition for the way forward.
>

Topology support is strictly required for creating several system
tables
and related triggers needing to be supported by Topology SQL functions.

Once that these tables have been created if no Topology SQL function
will
be called (both explicitly or implicitly) absolutely anything will run
in the most painless way even if that database will be connected to
a copy of libspatialite-5.x built by disabling librttopo and thus
completely
lacking any Topology support.

this is surely true at least until your process doesn't attemptes to
perform INSERT, UPDATE or DELETE on behalf of any Topology table.
you might safely perform SELECT on such tables without any problem;
the only relevant things only are never calling any Topology SQL
function and only performing read-only operations.
and you might even graphically display without any problem all the
primimitives (except for materialized Faces) of an already existing
Topology on the new MapPanel supported by the most recent GUI.

a minor corner case: few predefined Topology Views (such as the
ones materializing Topology Faces) cannot be queried because
they internally depend on ST_GetFaceGeometry(); doesn't seem
a serious limitation.

bye Sandro

[MB]

My preference would be  that for running tests the build be done with -enable-rttopo and  --enable-gcp.

I understand that this would create minor inconvenience for those who develop spatialite code. 

The advantage is that this would provide a seamless upgrade path to those who use spatialite as a black box library.

Otherwise the default build will be backward incompatible as far as licensing is considered and special care would have to be taken for MPL compatibility.

Can you please kindly answer that with the proposed change if the following would work or not?

1. Create a spatialite database on linux (built with  -enable-rttopo and  --enable-gcp), that does not use topology or georeferencing features.

2. Open the spatial database on a client machines using spatialite built  --disable-rttopo --disable-gcp. Would such an application still be able to delete/insert rows or query the database created in step 1? The application does not use any topology functions.

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

On Wed, 27 Jan 2021 10:07:09 -0800 (PST), MB wrote:
> Can you please kindly answer that with the proposed change if the
> following would work or not?
>
> 1. Create a spatialite database on linux (built with -enable-rttopo
> and --enable-gcp), that does not use topology or georeferencing
> features.
> 2. Open the spatial database on a client machines using spatialite
> built --disable-rttopo --disable-gcp. Would such an application still
> be able to delete/insert rows or query the database created in step
> 1?
> The application does not use any topology functions.
>

short reply: certainly yes, supporting or not Topology has no direct
influence on SQL statements such as SELECT, INSERT, UPDATE and DELETE

long reply: except in a very special case.
pre-defined Views supporting materialization of Topology Faces will
always fail on SELECT when no Topology support is available, because
they internally call ST_GetFaceGeometry() that is part of Topology.

a further clarification: directly inserting, updating or deleting
rows of a table intended to store Topology Primitives is a splendid
recipe for disseminating havoc everywhere suddenly transforming the
whole thing into a pile of useless trash.
you are always expected to call SQL functions such as ST_AddIsoNode(),
ST_MoveIsoNode(), ST_RemIsoNode() and friends for editing in a
safe way a Topology.
this is the exact meaning of what I'm intending when I say
"you can't edit Topology tables without rttopo support"
... of course you can, but not in a safe and consistent way.

the proposed change is just a matter of convenience:
1. the current choice (--disable-rttopo --disable-gcp) was very
conservative and had the intention to make life easier for
peoples non interested into Topology
2. the proposed change (--enable-rttopo --enable-gcp) is
mainly intended to protect sers from the risk of
unvulontarily building a gelded library thus causing
many unexpected failures into the testcoverage.

bye Sandro