<div dir="ltr"><span style="font-size:12.8000001907349px">During this extensive discussion, the different needs of the different participates have, I believe been crystallized.  </span><div style="font-size:12.8000001907349px"><br></div><div style="font-size:12.8000001907349px">At this point it might be wise to to create a summery of these, that can then be a base for a constructive suggestion on how to deal with this matter.</div><div style="font-size:12.8000001907349px"><br></div><div style="font-size:12.8000001907349px">My impression is, that Andrea Peri of Tuscany Region, is waiting for an agreement of all participants.</div><div style="font-size:12.8000001907349px"><br></div><div style="font-size:12.8000001907349px">Also, so my impression, Tuscany Region may also be a public service, which means that they must justify the expenditure of public funding. So the possible third funding must achieve the final goal that the first 2 funding were indented for.</div><div style="font-size:12.8000001907349px"><br></div><div style="font-size:12.8000001907349px">---</div><div style="font-size:12.8000001907349px">Main Participants (hopefully complete and correct):<br></div><div style="font-size:12.8000001907349px">- Sandro Santilli: as a major maintainer of the GEOS project, but also of PostGIS</div><div style="font-size:12.8000001907349px">- Regina Obe and Paul Ramsey as major maintainers of PostGIS</div><div style="font-size:12.8000001907349px">- Sandro Furieri the major maintainer of Spatialite</div><div style="font-size:12.8000001907349px">- myself (Mark Johnson) as maintainer of the Android Spatialite/RasterLite2 Database Driver</div><div style="font-size:12.8000001907349px"><br></div><div style="font-size:12.8000001907349px">For the Android side (and based on messages sent to the Spatialite User list, possibly for others such as Cordova and <font face="Arial, Helvetica, sans-serif">iOS) the main problem is that applications must be self contained (no Dynamic Library support).</font></div><div style="font-size:12.8000001907349px"><font face="Arial, Helvetica, sans-serif">So that all dependencies must be included in the project</font></div><div style="font-size:12.8000001907349px"><font face="Arial, Helvetica, sans-serif">- in the case of liblwgeom: </font>PostGIS with PostgreSQL plus any dependencies they may have</div><div style="font-size:12.8000001907349px"><br></div><div style="font-size:12.8000001907349px">This is why, when building the Spatialite portion, <span style="font-family:Arial,Helvetica,sans-serif">liblwgeom was not included.</span></div><div style="font-size:12.8000001907349px"><span style="font-family:Arial,Helvetica,sans-serif"><br></span></div><div style="font-size:12.8000001907349px"><span style="font-family:Arial,Helvetica,sans-serif">In September I was asked to check if </span><font face="Arial, Helvetica, sans-serif">liblwgeom, in its present form, compiled and ran as indented without these dependencies (with minor corrections), which it did.</font></div><div style="font-size:12.8000001907349px"><font face="Arial, Helvetica, sans-serif"><br></font></div><div style="font-size:12.8000001907349px"><font face="Arial, Helvetica, sans-serif">So it seems to me that</font></div><div style="font-size:12.8000001907349px"><font face="Arial, Helvetica, sans-serif">- </font>Regina Obe and Paul Ramsey</div><div style="font-size:12.8000001907349px">- Sandro Furieri</div><div style="font-size:12.8000001907349px">and the Android project have a common problem:</div><div style="font-size:12.8000001907349px">- that with certain <font face="Arial, Helvetica, sans-serif">dependencies, versions conflicts occur.</font></div><div style="font-size:12.8000001907349px"><font face="Arial, Helvetica, sans-serif"><br></font></div><div style="font-size:12.8000001907349px"><font face="Arial, Helvetica, sans-serif">So this common problem needs, for all p</font>articipants, a reliable, permanent solution.</div><div style="font-size:12.8000001907349px"><br></div><div style="font-size:12.8000001907349px">Another common problem, is the necessity of not</div><div style="font-size:12.8000001907349px">- 'Reinventing the wheel'</div><div style="font-size:12.8000001907349px"><br></div><div style="font-size:12.8000001907349px">---</div><div style="font-size:12.8000001907349px">As Sandro Furieri mentioned in his note from 24 Oct 2015 (yesterday)</div><div style="font-size:12.8000001907349px">- what is needed is 'just a handful of highly valuable sophisticated spatial</div><div style="font-size:12.8000001907349px">functions that have no equivalent implementation and that</div><div style="font-size:12.8000001907349px">aren't so easy and simple to be independently rewritten.'</div><div style="font-size:12.8000001907349px"><br></div><div style="font-size:12.8000001907349px">These portions are not from GEOS, but from the PostGIS project.</div><div style="font-size:12.8000001907349px"><br></div><div style="font-size:12.8000001907349px">So if a split is made, as Sandro Furieri has suggested:</div><div style="font-size:12.8000001907349px"><br></div><div style="font-size:12.8000001907349px"><div>What the new separated library should possibly be</div><div>--------------------------------------------------</div><div>a) a simple, streamlined and light-weighted library just</div><div>    depending on GEOS alone.</div><div>b) robust thread-safe implementation.</div><div>c) canonic configure scripts fully supporting versioning,</div><div>    SONAMEs and alike so to make maintainers and packagers</div><div>    activities as easy as possible.</div><div>d) long term API/ABI rock-solid stability (with possible</div><div>    exceptions only during initial alpha/beta testing steps).</div><div>e) full support for ISO Topology, and consequently directly</div><div>    supporting all the "super-GEOS" API strictly required by</div><div>    the Topology code itself, as e.g. MakeValid, Snap etc.</div><div>no less than this, no more than this.</div></div><div style="font-size:12.8000001907349px"><br></div><div style="font-size:12.8000001907349px">it would mean original PostGIS code portions would need to be included.</div><div style="font-size:12.8000001907349px"><br></div><div style="font-size:12.8000001907349px">I believe that such a library, with the above mentioned functionality</div><div style="font-size:12.8000001907349px">- should become a sub-project of GEOS</div><div style="font-size:12.8000001907349px">-- possibly called 'geos_extended' </div><div style="font-size:12.8000001907349px"><br></div><div style="font-size:12.8000001907349px">Assuming the these portions (of the 'handful of highly valuable sophisticated spatial functions') are self contained</div><div style="font-size:12.8000001907349px">- i.e. not being used elsewhere inside PostGIS as extra functions</div><div style="font-size:12.8000001907349px">-- that need to be maintained due to internal changes inside PostGIS itself</div><div style="font-size:12.8000001907349px"><br></div><div style="font-size:12.8000001907349px">These are decisions that only the PostGIS project can decide</div><div style="font-size:12.8000001907349px">- including any possible licence differences between GEOS and PostGIS</div><div style="font-size:12.8000001907349px">-- which the transfer of the portions from one project to the other would entail</div><div style="font-size:12.8000001907349px"><br></div><div style="font-size:12.8000001907349px">---</div><div style="font-size:12.8000001907349px">Assuming that all of this is answered with 'yes'</div><div style="font-size:12.8000001907349px">- after extraction, <font face="Arial, Helvetica, sans-serif">liblwgeom could then be integrated back into </font>PostGIS</div><div style="font-size:12.8000001907349px">-- solely as an internal portion</div><div style="font-size:12.8000001907349px"><br></div><div style="font-size:12.8000001907349px">---</div><div style="font-size:12.8000001907349px">Such a 2 part solution would:</div><div style="font-size:12.8000001907349px">- make a common code usable for all</div><div style="font-size:12.8000001907349px">-- without the present conflicts </div><div style="font-size:12.8000001907349px">- without repetition of common functions, implemented differently</div><div style="font-size:12.8000001907349px">-- such as ST_ConcaveHull<br></div><div style="font-size:12.8000001907349px">- no 'Reinventing the wheel'</div><div style="font-size:12.8000001907349px"><br></div><div style="font-size:12.8000001907349px">In this sense, I suggest that, based on the above suggestion, a consensus be made among the participants on how to deal with this problem.</div><div style="font-size:12.8000001907349px"><br></div><div style="font-size:12.8000001907349px">With that, Andrea Peri of Tuscany Region (who started this thread) would receive the answer he, I assume, is waiting for.</div><div style="font-size:12.8000001907349px"><br></div><div style="font-size:12.8000001907349px">Regina Obe stated in point 4 of her note from 22 Oct 2015</div><div style="font-size:12.8000001907349px">- 'Though with PostgreSQL 9.6 coming soon and the whole parallel query thing coming in, I'm not sure if that may change our need for threading.'</div><div style="font-size:12.8000001907349px"><br></div><div style="font-size:12.8000001907349px">Insofar as this has not already been dealt with the present version of <span style="font-family:Arial,Helvetica,sans-serif">liblwgeom</span></div><div style="font-size:12.8000001907349px"><span style="font-family:Arial,Helvetica,sans-serif">- this could also be dealt with in </span>Andrea Peri offer to help in 'the recovery in PostGIS of the previous plpgsql implementation of the Topology module.'</div><div style="font-size:12.8000001907349px"><br></div><div style="font-size:12.8000001907349px">Final decisions could then be made</div><div style="font-size:12.8000001907349px">- and thus end this thread</div><div style="font-size:12.8000001907349px"><br></div><div style="font-size:12.8000001907349px">Mark Johnson, Berlin Germany</div></div>