GCP solvers

[Even Rouault]

Hi Sandro,

Just saw that you added GCP solvers in spatialite. If you needed code that can
be released under the usual Spatialite license, a possibility would have been
to borrow the equivalent routines from GDAL :
- polynomial solver : http://svn.osgeo.org/gdal/trunk/gdal/alg/gdal_crs.c
(this comes from the same original code as GRASS)
- TPS solver: http://svn.osgeo.org/gdal/trunk/gdal/alg/thinplatespline.h +
http://svn.osgeo.org/gdal/trunk/gdal/alg/thinplatespline.cpp

From GDAL provenance review :
* gdal_crs.c: derived from old GRASS/UMichigan code also under MIT/X license,
properly noted in headers.
* thinplatespline.cpp: Contributed by VIZRT Inc., Relicensed to MIT/X with
their explicit permission as noted in the header.

Even

--
Spatialys - Geospatial professional services
http://www.spatialys.com

[Even Rouault]

In any case ( code from GRASS or GDAL ), just thinking you might want to prefix
the non-static symbols (the ones in grass_crs.h) with a spatialite prefix, to
avoid potential symbol name clashes.
In case GRASS directly or indirectly links to Spatialite and that the
implementations and/or prototypes evolve over time.

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

Hi Even,

I already noticed during my preliminary explorations that the
same identical initial C code was "kidnapped" both on Grass and
GDAL then being re-licensed under different legal terms.
And just for the sake of curiosity, QGIS too seems to offer
a GeoReferencing plug-in that in ultimate analysis simply
relies on the GDAL support.
I suppose that this one could be a very effective example
of code sharing and code recycling :-D

My final decision to opt for the Grass own implementation is
simply justified by a subtle but anyway relevant difference:
Markus Metz in recent years added an original 3D polynomial
solver, an option unsupported by the GDAL own implementation.

thanks anyway for your nice offer,
Sandro

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

On Wed, 27 May 2015 11:37:27 +0200, Even Rouault wrote:
> In any case ( code from GRASS or GDAL ), just thinking you might want
> to prefix
> the non-static symbols (the ones in grass_crs.h) with a spatialite
> prefix, to
> avoid potential symbol name clashes.
> In case GRASS directly or indirectly links to Spatialite and that the
> implementations and/or prototypes evolve over time.
>

Even,

it's a really useful suggestion: immediately accepted ;-)

bye Sandro