<br><br><div class="gmail_quote">On Fri, Sep 9, 2011 at 5:33 PM, Paul Ramsey <span dir="ltr"><<a href="mailto:pramsey@cleverelephant.ca">pramsey@cleverelephant.ca</a>></span> wrote:<br><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

* We are a PgSQL extension, not a third-party library. If this<br>
actually "succeeds" in getting people using liblwgeom, it also "fails"<br>
in that now we have to, in addition to doing our own work as PostGIS<br>
developers, ensure we don't break other people's work. If we do change<br>
things all the time and people don't use us, then we don't "succeed",<br>
so the "let other people use liblwgeom" argument fails.<br>
<br></blockquote><div><br>You already have to ensure you don't break other people's work: you must keep the faith with the interface contracts of your SQL functions. :) The difference between liblwgeom (private) and liblwgeom (public) is the size of your public API, not "no API vs API". Whether internal-only or shared, you're going to want to strive for a <i>stable </i>liblwgeom API.<br>
<br>Now I think the real question is "is it worth sharing"? To be honest, I don't know what features are offered by the various libraries out there. It sounds like there is some postgis-unique enhanced validity checking in liblwgeom not present in other libraries, and not easily integrated into GEOS/OGR/etc. If it was a rational thing to do, I'd argue for offloading the geometry burden altogether: to GEOS or OGR; writing the extra postgis functionality on top of one of these foundations. This would mean that postgis doesn't need to maintain its own wkt/wkb parser, its own internal geometry format, its own roundtrip translations to an external geometry type where the heavy lifting is done... I don't know whether the functional requirements would make this a rational long term goal or not. But in my opinion, if liblwgeom adds no unique capabilities, it should disappear over time; if it has something that others do not, it should be shared. The mechanism of sharing may be: 1] installed as a shared library systemwide; 2] forked as a separate project; or 3] assimilated into an existing separate project. ..and if you start with #1, declaring your intentions to migrate to #3, well, your users have been warned.<br>
<br>One thing that occurs to me is that with a separate liblwgeom (complete with serialization functions), it becomes possible to write "compatible" postgresql extensions. For instance, if no one here wants my raster iterator engine, I can write a completely separate postgresql extension which can read and write postgis-compatible geometries to the database. It would be awful nice if the raster serialization stuff was in there too: in fact, I'd want everything required to interact with database objects supported by PostGIS. If you don't do that, then everyone wanting to extend functionality or datatypes must plan on modifying the postgis code base itself. Not so modular. Icky. So I guess the thing liblwgeom has which no other libraries have is the ability to support postgis-compatible postgresql modules.<br>
<br><br>W.r.t. rearranging (dustymugs): I see the contents of liblwgeom as a separate issue from whether or not liblwgeom is shared separately from PostGIS. But I think that voting on whether liblwgeom should have accumulated the
 functions it did (which is what it looked like you were objecting to) is kind of moot at this point. The evil deed is done. 
We (y'all) can take away some lessons learned about how to better approach 
similar changes in the future. But with the rearranging, your potential contributors have the option of hearing something other than: <br><br>1] "No, it duplicates code"; or <br>2] "No, we don't want to rearrange"<br>
<br>..that is, if they make it past the stage of being so totally aggravated that they have to reinvent supporting code which is already in the codebase, but which is unusable... :) <br><br>Bryce<br><br><br></div></div>