[geos-commits] [SCM] GEOS branch gh-pages updated. 16ed6daaae6dd68a4fd9f9c65554d26f97f9deeb

[git at osgeo.org]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "GEOS".

The branch, gh-pages has been updated
       via  16ed6daaae6dd68a4fd9f9c65554d26f97f9deeb (commit)
      from  529cfbfb7b7f41de4f44f25cda537f16089d2a13 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
commit 16ed6daaae6dd68a4fd9f9c65554d26f97f9deeb
Author: pramsey <pramsey+github at cleverelephant.ca>
Date:   Wed Nov 10 21:45:36 2021 +0000

    Deploying to gh-pages from @ libgeos/geos at e180cbe044acc1c0ea40db47fe2bed156e2a40e2 🚀

diff --git a/en.search-data.min.json b/en.search-data.min.json
index 85b6e252b..63ac1a023 100644
--- a/en.search-data.min.json
+++ b/en.search-data.min.json
@@ -1 +1 @@
-[{"id":0,"href":"/development/rfcs/rfc10/","title":"GEOS RFC 10 - Move Project to GitHub","parent":"Requests for Comment","content":"         RFC 10 Move Project to GitHub   Author Paul Ramsey   Contact pramsey at cleverelephant.ca   Status Accepted, November 9, 2021    GitHub has been the largest source of 3rd party code contribution via pull-requests for some time now.\nMoving to Github has the following components:\n Move the canonical (writeable) repository to GitHub Migrate the (current, useful) contents of the Trac wiki to the new web framework Deleting the migrated and out-of-date contents of the Trac wiki Switching the Trac tickets to read-only Web scraping the Trac ticket contents and placing in a geos-old-tickets repo  At that point:\n New code is pushed to GitHub New issues are filed at GitHub New documentation is committed to the repository  This should unlock:\n Easier path for new contributors to discover and assist with the project Easier collaboration with downstream pr
 ojects Far easier story on \u0026ldquo;how to we manage the project\u0026rdquo; and \u0026ldquo;where the important things happen\u0026rdquo; Far less dependence on individual contributors for infrastructure work that only they can do  "},{"id":1,"href":"/posts/","title":"News","parent":"GEOS","content":""},{"id":2,"href":"/development/psc/","title":"Project Steering Committee","parent":"Development","content":"The GEOS project is run by a Project Steering Committee made up of developers and contributors to the project and is a project of OSGeo. Major project decisions are made via a Request for Comments (RFC) process, where proposals are first documented and then voted on by the steering committee.\nThe current PSC will refresh itself using the mechanisms in RFC-1.\nThis PSC list is valid as of Oct 23, 2019.\n Sandro Santilli (chair) Martin Davis  Howard Butler \u0026lt;hobu.inc at gmail dot com\u0026gt; Regina Obe  Dale Lutz  Paul Ramsey  Dan Baston   The PSC approves major change
 s and RFC documents. Minor work is ongoing, by the PSC and by the other committers, listed below:\n Vicky Vergara Kurt Schwehr  Historical committers:\n Mateusz Loskot Charlie Savage Norman Vine Sean Gillies Frank Warmerdam Ben Jubb Chuck Thibert Stephen Wong  "},{"id":3,"href":"/development/rfcs/","title":"Requests for Comment","parent":"Development","content":"Process The Request for Comments process is as follows:\n Create a pull request against this repository adding a new RFC document outlining your planned change. Solicit comment and feedback on geos-devel. Call for a vote on the RFC. Note the status and commit the RFC to the web site for the record.  RFCs    GEOS RFC 1 - Project Steering Committee     GEOS RFC 2 - Committer Guidelines      GEOS RFC 3 - Thread Safe CAPI      GEOS RFC 4 - Code Formatting Style     GEOS RFC 5 - C\u0026#43;\u0026#43;11 Compilation Mode     GEOS RFC 6 - Require explicit configure to use the C\u0026#43;\u0026#43; API     GEOS RFC 7 - Use CMake for 
 Build System     GEOS RFC 8 - Improve Coordinate Sequence API (WIP)     GEOS RFC 9 - Restore the C\u0026#43;\u0026#43; API (WIP)     GEOS RFC 10 - Move Project to GitHub     "},{"id":4,"href":"/usage/doxygen/","title":"Reference Docs","parent":"Usage","content":"The Doxygen documentation is the most up-to-date reference for the C and C++ API of GEOS.\n C API C++ API  "},{"id":5,"href":"/usage/c_api/","title":"C API Programming","parent":"Usage","content":"Most programs using GEOS use the C API, rather than building against the C++ headers. The C API offers the a number of benefits:\n Stable API, that preserves behaviour and function naming over multiple releases. Stable ABI, allowing new binaries to be dropped into place without requiring a rebuild of dependent applications. Simple access pattern, using the simple features model as the basis for most operations.  In exchange for this simplicity and stability, the C API has a few requirements from application authors:\n Explicit memo
 ry management. If you create a GEOS object with a GEOS function, you have to remember to free it using the appropriate GEOS destructor.  The C API is entirely contained in the geos_c.h header file.\nBuilding a Program The simplest GEOS C API application needs to include the API header, declare a message handler, initialize the GEOS globals, and link to the GEOS C library when built.\n/* geos_hello_world.c */ #include \u0026lt;stdio.h\u0026gt; /* for printf */#include \u0026lt;stdarg.h\u0026gt; /* for va_list */ /* Only the CAPI header is required */ #include \u0026lt;geos_c.h\u0026gt; /* * GEOS requires two message handlers to return * error and notice message to the calling program. * * typedef void(* GEOSMessageHandler) (const char *fmt,...) * * Here we stub out an example that just prints the * messages to stdout. */ static void geos_msg_handler(const char* fmt, ...) { va_list ap; va_start(ap, fmt); vprintf (fmt, ap); va_end(ap); } int main() { /* Send notice and error messages t
 o the terminal */ initGEOS(geos_msg_handler, geos_msg_handler); /* Read WKT into geometry object */ GEOSWKTReader* reader = GEOSWKTReader_create(); GEOSGeometry* geom_a = GEOSWKTReader_read(reader, \u0026#34;POINT(1 1)\u0026#34;); /* Convert result to WKT */ GEOSWKTWriter* writer = GEOSWKTWriter_create(); char* wkt = GEOSWKTWriter_write(writer, geom_a); printf(\u0026#34;Geometry: %s\\n\u0026#34;, wkt); /* Clean up allocated objects */ GEOSWKTReader_destroy(reader); GEOSWKTWriter_destroy(writer); GEOSGeom_destroy(geom_a); GEOSFree(wkt); /* Clean up the global context */ finishGEOS(); return 0; } When compiling the program, remember to link in the GEOS C library.\ncc geos_hello_world.c -o geos_hello_world -l geos_c Reentrant/Threadsafe API Every function in the examples above and below is shadowed by a reentrant function carrying a _r suffix. The reentrant functions work the same as their simple counterparts, but they all have one extra parameter, a GEOSContextHandle_t.\nThe GEOSConte
 xtHandle_t carries a thread-local state that is equivalent to the state initialized by the initGEOS() call in the simple example above.\nTo use the reentrant API, you skip calling initGEOS() and instead call GEOS_init_r() to create a context local to your thread. Each thread that will be running GEOS operations should create its own context prior to working with the GEOS API.\n/* geos_hello_world.c */ #include \u0026lt;stdio.h\u0026gt; /* for printf */#include \u0026lt;stdarg.h\u0026gt; /* for va_list */ /* Only the CAPI header is required */ #include \u0026lt;geos_c.h\u0026gt; static void geos_msg_handler(const char* fmt, ...) { va_list ap; va_start(ap, fmt); vprintf (fmt, ap); va_end(ap); } int main() { /* Send notice and error messages to the terminal */ GEOSContextHandle_t ctx = GEOS_init_r (); GEOSContext_setNoticeHandler_r(ctx, geos_msg_handler); GEOSContext_setErrorHandler_r(ctx, geos_msg_handler); /* Read WKT into geometry object */ GEOSWKTReader* reader = GEOSWKTReader_crea
 te_r(ctx); GEOSGeometry* geom_a = GEOSWKTReader_read_r(ctx, reader, \u0026#34;POINT(1 1)\u0026#34;); /* Convert result to WKT */ GEOSWKTWriter* writer = GEOSWKTWriter_create_r(ctx); char* wkt = GEOSWKTWriter_write_r(ctx, writer, geom_a); printf(\u0026#34;Geometry: %s\\n\u0026#34;, wkt); /* Clean up allocated objects */ GEOSWKTReader_destroy_r(ctx, reader); GEOSWKTWriter_destroy_r(ctx, writer); GEOSGeom_destroy_r(ctx, geom_a); GEOSFree_r(ctx, wkt); /* Clean up the global context */ GEOS_finish_r(ctx); return 0; } Note that the overall structure of the code is identical, but the reentrant variants are used, and the preamble and cleanup are slightly different.\nObject Model The GEOSCoordSequence and GEOSGeometry objects are at the heart of the GEOS object model.\nGEOSCoordSequence GEOSCoordSequence is an ordered list of coordinates (2 or 3 dimensional). There are a number of ways to make a GEOSCoordSequence.\nYou can create a GEOSCoordSequence by creating a blank one and then setting t
 he coordinate values.\ndouble xList[] = {1.0, 2.0, 3.0}; double yList[] = {3.0, 2.0, 1.0}; size_t seqSize = 3; size_t seqDims = 2; GEOSCoordSequence* seq = GEOSCoordSeq_create(seqSize, seqDims); for (size_t i = 0; i \u0026lt; seqSize; i++) { seq-\u0026gt;setXY(i, xList[i], yList[i]); } GEOSCoordSeq_destroy(seq); You can also create a GEOSCoordSequence and populate it simultaneously from coordinate arrays.\ndouble xList[] = {1.0, 2.0, 3.0}; double yList[] = {3.0, 2.0, 1.0}; size_t seqSize = 3; GEOSCoordSequence* seq = GEOSCoordSeq_copyFromArrays( xList, yList, NULL, /* Zs */ NULL, /* Ms */ seqSize); GEOSCoordSeq_destroy(seq); Finally, you can create a GEOSCoordSequence and populate it simultaneously directly from a single coordinate buffer (an array of double in coordinate order, eg: XYXYXYX).\n/* Coordinates in a buffer (X,Y, X,Y, X,Y) */ double coordBuf[] = {1.0,3.0, 2.0,2.0, 3.0,1.0}; size_t seqSize = 3; GEOSCoordSequence* seq = GEOSCoordSeq_copyFromBuffer( coordBuf, seqSize, 0, /
 * hasZ */ 0 /* hasM */ ); GEOSCoordSeq_destroy(seq); Note that while you can reclaim the memory for a GEOSCoordSequence directly using GEOSCoordSeq_destroy(), you usually will not have to since creating a GEOSGeometry with a GEOSCoordSequence hands ownership of the sequence to the new geometry.\nWhen writing data back from GEOS to whatever application you are using, you have the option of using a standard serialization format like WKB (see below) or by writing back to arrays or buffers.\n GEOSCoordSeq_copyToArrays() GEOSCoordSeq_copyToBuffer()  Using the array or buffer methods can often be faster than using direct coordinate reading or serialization formats, if the target structures use coordinate arrays or XY binary buffers.\nGEOSGeometry The workhorse of the GEOS C API is the GEOSGeometry. GEOSGeometry can be a point, linestring, polygon, multipoint, multilinestring, multipolygon, or geometrycollection. Most functions in the GEOS C API have a GEOSGeometry as a parameter or return
  type. Clean up GEOSGeometry using GEOSGeom_destroy().\nThere are many constructors for GEOSGeometry:\n GEOSGeom_createPoint() GEOSGeom_createPointFromXY() GEOSGeom_createLinearRing() GEOSGeom_createLineString() GEOSGeom_createPolygon() GEOSGeom_createCollection() GEOSGeom_createEmptyPoint() GEOSGeom_createEmptyLineString() GEOSGeom_createEmptyPolygon() GEOSGeom_createEmptyCollection()  The \u0026ldquo;createEmpty\u0026rdquo; functions take no arguments are return geometries that are \u0026ldquo;empty\u0026rdquo;, that is they represent an empty set of space. The intersection of two disjoint polygons is a \u0026ldquo;empty polygon\u0026rdquo;, for example.\nThe GEOSGeom_createPoint(), GEOSGeom_createLinearRing() and GEOSGeom_createLinearRing() all take in a single GEOSCoordSequence and take ownership of that sequence, so freeing the geometry with GEOSGeom_destroy() frees all memory.\ndouble coordBuf[] = {1.0,3.0, 2.0,2.0, 3.0,1.0}; size_t seqSize = 3; GEOSCoordSequence* seq = GEOSCo
 ordSeq_copyFromBuffer( coordBuf, seqSize, 0, 0); /* Takes ownership of sequence */ GEOSGeometry* geom = GEOSGeom_createLineString(seq); /* Frees all memory */ GEOSGeom_destroy(geom); The GEOSGeom_createPolygon() and GEOSGeom_createCollection() functions both require an array of inputs:\n an array of inner ring GEOSCoordSequence to create polygons; and, an array of GEOSGeometry to create collections.  As in the other creation functions, ownership of the contained objects is transferred to the new geometry. However, ownership of the array that holds the contained objects is not transferred.\n/* Two points in an array */ size_t npoints = 2; GEOSGeometry** points = malloc(sizeof(GEOSGeometry*) * npoints); points[0] = GEOSGeom_createPointFromXY(0.0, 0.0); points[1] = GEOSGeom_createPointFromXY(0.0, 0.0); /* takes ownership of the points in the array */ /* but not the array itself */ GEOSGeometry* collection = GEOSGeom_createCollection( GEOS_MULTIPOINT, /* collection type */ points, /* ge
 ometry array */ npoints); /* frees collection and contained points */ GEOSGeom_destroy(collection); /* frees the containing array */ free(points); Readers and Writers The examples above build GEOSCoordSequence from arrays of double, and GEOSGeometry from coordinate sequences, but it is also possible to directly read from and write to standard geometry formats:\n Well-Known Text (WKT) Well-Known Binary (WKB) GeoJSON  For example, reading and writing WKT:\nconst char* wkt_in = \u0026#34;POLYGON((0 0, 10 0, 10 10, 0 10, 0 0))\u0026#34;; /* Read the WKT into geometry object */ GEOSWKTReader* reader = GEOSWKTReader_create(); GEOSGeometry* geom = GEOSWKTReader_read(reader, wkt_in); /* Convert geometry back to WKT */ GEOSWKTWriter* writer = GEOSWKTWriter_create(); /* Trim trailing zeros off output */ GEOSWKTWriter_setTrim(writer, 1); char* wkt_out = GEOSWKTWriter_write(writer, geom); /* Clean up everything we allocated */ GEOSWKTReader_destroy(reader); GEOSGeom_destroy(geom); /* Use GEOSFr
 ee() to free memory allocated inside GEOS~ */ GEOSFree(wkt_out); Note that the output WKT string is freed using GEOSFree(), not the system free(). This ensures that the same library that allocates the memory also frees it, which is important for some platforms (Windows primarily).\nFor more information about the specific options available for each format, see the documentation for the various readers and writers.\n GEOSWKTReader / GEOSWKTWriter GEOSWKBReader / GEOSWKBWriter GEOSGeoJSONReader / GEOSGeoJSONWriter  For a complete example using a reader and writer, see capi_read.c.\nPrepared Geometry The GEOS \u0026ldquo;prepared geometry\u0026rdquo; is conceptually similar to a database \u0026ldquo;prepared statement\u0026rdquo;: by doing a little up-front work to set-up a handler, you can reap a performance benefit when you execute repeated function calls on that object.\nPrepared geometries contain internal indexes that make calls to the \u0026ldquo;spatial predicate\u0026rdquo; func
 tions like GEOSPreparedIntersects() and GEOSPreparedContains() much much faster. These are functions that take in two geometries and return true or false.\nIf you are going to be making repeated calls to predicates on the same geometry, using a prepared geometry could be a big performance boost, at the cost of a little extra complexity.\n/* One concave polygon */ const char* wkt = \u0026#34;POLYGON ((189 115, 200 170, 130 170, 35 242, 156 215, 210 290, 274 256, 360 190, 267 215, 300 50, 200 60, 189 115))\u0026#34;; /* Read the WKT into geometry objects */ GEOSWKTReader* reader = GEOSWKTReader_create(); GEOSGeometry* geom = GEOSWKTReader_read(reader, wkt); GEOSWKTReader_destroy(reader); /* Prepare the geometry */ const GEOSPreparedGeometry* prep_geom = GEOSPrepare(geom); /* Make a point to test */ GEOSGeometry* pt = GEOSGeom_createPointFromXY(190, 200); /* Check if the point and polygon intersect */ if (GEOSPreparedIntersects(prep_geom, pt)) { /* done something ... */ } /* Note that 
 both prepared and original geometry are destroyed */ GEOSPreparedGeom_destroy(prep_geom); GEOSGeom_destroy(geom); GEOSGeom_destroy(pt); For a complete example of using prepared geometry to accelerate multiple predicate tests, see the capi_prepared.c example.\nSTRTree Index  GEOSSTRtree  "},{"id":6,"href":"/usage/cpp_api/","title":"C++ API Programming","parent":"Usage","content":"The GEOS C++ API is included in the collection of header files installed in include/geos which is a very large collection. Effectively it includes both \u0026ldquo;public\u0026rdquo; headers that a user might be expected to make use of and \u0026ldquo;private\u0026rdquo; headers that are mostly only used by internal algorithms. Currently, the two kinds of headers are not marked in any way, nor is there an easy way to disentagle them.\nUsing the C++ API means giving up:\n Stable API, since headers can be moved, re-named or deleted according to the implementation needs of the library. Stable ABI, since the com
 plexity of the GEOS symbol space means that binary symbols are known change between versions, even relatively small releases.  However, if you are careful in restricting your usage you can build applications against the C++ API that avoid most issues:\n Use Geometry as your primary handle, and sub-classes like Point, LineString and Polygon as necessary. Use the reader and writer classes for data access. Use the TemplateSTRtree for indexing. Use the PreparedGeometry class as needed.  One benefit of using the C++ API is access to more modern C++ facilities, like the std::unique_ptr and std::string.\nBuilding a Program The simplest GEOS C++ API application needs to include the geom::Geometry.h header and geom::GeometryFactory.h header, to construct new geometries. To read geometries from input formats, a reader such as geom::WKTReader.h will also be required.\n/* * # GEOS C++ example 1 * * Reads two WKT representations and calculates the * intersection, prints it out, and cleans up. * 
 * In general, to avoid API changes, stick to operations * on Geometry. The more esoteric APIs are more likely * to change between versions. */ #include \u0026lt;iostream\u0026gt; /* For geometry operations */ #include \u0026lt;geos/geom/GeometryFactory.h\u0026gt;#include \u0026lt;geos/geom/Geometry.h\u0026gt; /* For WKT read/write */ #include \u0026lt;geos/io/WKTReader.h\u0026gt;#include \u0026lt;geos/io/WKTWriter.h\u0026gt; /* Geometry/GeometryFactory */ using namespace geos::geom; /* WKTReader/WKTWriter */ using namespace geos::io; int main() { /* New factory with default (float) precision model */ GeometryFactory::Ptr factory = GeometryFactory::create(); /* * Reader requires a factory to bind the geometry to * for shared resources like the PrecisionModel */ WKTReader reader(*factory); /* Input WKT strings */ std::string wkt_a(\u0026#34;POLYGON((0 0, 10 0, 10 10, 0 10, 0 0))\u0026#34;); std::string wkt_b(\u0026#34;POLYGON((5 5, 15 5, 15 15, 5 15, 5 5))\u0026#34;); /* Convert WKT t
 o Geometry */ std::unique_ptr\u0026lt;Geometry\u0026gt; geom_a(reader.read(wkt_a)); std::unique_ptr\u0026lt;Geometry\u0026gt; geom_b(reader.read(wkt_b)); /* Calculate intersection */ std::unique_ptr\u0026lt;Geometry\u0026gt; inter = geom_a-\u0026gt;intersection(geom_b.get()); /* Convert Geometry to WKT */ WKTWriter writer; writer.setTrim(true); std::string inter_wkt = writer.write(inter.get()); /* Print out results */ std::cout \u0026lt;\u0026lt; \u0026#34;Geometry A: \u0026#34; \u0026lt;\u0026lt; wkt_a \u0026lt;\u0026lt; std::endl; std::cout \u0026lt;\u0026lt; \u0026#34;Geometry B: \u0026#34; \u0026lt;\u0026lt; wkt_b \u0026lt;\u0026lt; std::endl; std::cout \u0026lt;\u0026lt; \u0026#34;Intersection(A, B): \u0026#34; \u0026lt;\u0026lt; inter_wkt \u0026lt;\u0026lt; std::endl; } "},{"id":7,"href":"/posts/2021-10-01-geos-3-10-released/","title":"Version 3.10.0","parent":"News","content":"The 3.10 release of GEOS is now available to download.\n  This release includes the following new fe
 atures in the C API (and of course underlying changes to the C++ code to support these features):\n CAPI additions for testing whether geometries are within a distance of each other, GEOSDistanceWithin and GEOSPreparedDistanceWithin CAPI addition for adding extra vertices to a geometry, GEOSDensify CAPI additions for high-performance construction/reading of coordinate sequences from/to memory buffers, GEOSCoordSeq_copyFromArrays, GEOSCoordSeq_copyFromBuffer, GEOSCoordSeq_copyToArrays, and GEOSCoordSeq_copyToBuffer CAPI addition for new validity enforement algorithm, GEOSMakeValidWithParams CAPI addition for ISO WKB output, GEOSWKBWriter_getFlavor and GEOSWKBWriter_setFlavor CAPI addition to create a constrained delaunay of polygonal input, GEOSConstrainedDelaunayTriangulation    There is a new utility for running arbitrary GEOS commands against input files, geosop. See the user guide for examples.\n  The C API is now fully documented and available as a reference document.\n  The IsV
 alidOp and IsSimpleOp have been re-written for higher performance in general and faster response for \u0026ldquo;simple\u0026rdquo; cases of invalidity.\n  The STRtree has been replaced with a templated version that is even faster than before. This has improved algorithm performance across the board.\n  There have been numerous other bug fixes and performance tweaks.\n  "},{"id":8,"href":"/development/ci_status/","title":"CI Status","parent":"Development","content":"   Branch GitHub Debbie Winnie Dronie GitLab Bessie Bessie32     main          3.10          3.9          3.8          3.7           Runners  Debbie - Debian 8.2, GNU/Linux 64bit, GCC Debian 8.2.0-3, automake Winnie - Windows Mingw64, 32bit GCC 8.1.0, 64bit GCC 8.1.0, MSys CMake Dronie - Alpine Linux 3.4, 64bit, GCC 5.3.0, automake GitLab - Debian 8.2, GNU/Linux 64bit, gcc, automake Bessie - FreeBSD 12.2, 64-bit clang 6.0, 64bit gcc, CMake (3.11) \u0026gt;=3.8, autotools \u0026lt; 3.8 Bessie32 - FreeBSD 12.2, 32-bit clan
 g 6.0, 64bit gcc, CMake (3.11) \u0026gt;=3.8, autotools \u0026lt; 3.8 GitHub - Ubuntu various versions, Windows various, CMake  "},{"id":9,"href":"/development/","title":"Development","parent":"GEOS","content":"Developer Resources  Code repository: https://github.com/libgeos/geos Developer mailing list: https://lists.osgeo.org/mailman/listinfo/geos-devel Developer chat channel:  Matrix: https://matrix.to/#/#geos:osgeo.org Slack: https://osgeo.slack.com/messages/C07RKJ06B/    Relationship to JTS GEOS started as a direct port to C++ of the JTS Topology Suite (JTS), and remains tightly bound to that project. Most core algorithms have been prototyped in JTS and ported to GEOS when complete.\nThe projects attempt to share testing data, and to ascertain when failures are caused by differences in implementation (GEOS fails and JTS does not) and when they are caused by algorithm (both libraries fail).\nGovernance The GEOS project is run by a Project Steering Committee made up of developers 
 and contributors to the project and is a project of OSGeo.\n"},{"id":10,"href":"/specifications/","title":"Geometry Formats","parent":"GEOS","content":"    GeoJSON     Well-Known Binary (WKB)     Well-Known Text (WKT)     More\n"},{"id":11,"href":"/development/rfcs/rfc01/","title":"GEOS RFC 1 - Project Steering Committee","parent":"Requests for Comment","content":"This document describes how the PSC GEOS Project Steering Committee determines membership, and makes decisions on all aspects of the GEOS project - both technical and non-technical.\n         RFC 1 Project Steering Committee   Author Paul Ramsey   Contact pramsey at cleverelephant.ca   Status Approved, April 10, 2008    Summary This document describes how the GEOS Project Steering Committee (PSC) determines membership, and makes decisions on all aspects of the GEOS project - both technical and non-technical.\nExamples of PSC management responsibilities:\n setting the overall development road map developing technical standards
  and policies (e.g. coding standards, file naming conventions, etc\u0026hellip;) ensuring regular releases (major and maintenance) of GEOS software reviewing RFC for technical enhancements to the software project infrastructure (e.g. SVN, bug tracking, hosting options, etc\u0026hellip;) formalization of affiliation with external entities such as OSGeo setting project priorities, especially with respect to project sponsorship creation and oversight of specialized sub-committees (e.g. project infrastructure, training)  In brief the project team votes on proposals on geos-devel. Proposals are available for review for at least two days, and a single veto is sufficient delay progress though ultimately a majority of members can pass a proposal.\nDetailed Process  Proposals are announced on the geos-devel mailing list for discussion and voting, by any interested party, not just committee members. Proposals need to be available for review for at least two business days before a final decisi
 on can be made. Respondents may vote \u0026ldquo;+1\u0026rdquo; to indicate support for the proposal and a willingness to support implementation. Respondents may vote \u0026ldquo;-1\u0026rdquo; to veto a proposal, but must provide clear reasoning and alternate approaches to resolving the problem within the two days. A vote of -0 indicates mild disagreement, but has no effect. A 0 indicates no opinion. A +0 indicate mild support, but has no effect. Anyone may comment on proposals on the list, but only members of the Project Steering Committee\u0026rsquo;s votes will be counted. A proposal will be accepted if it receives +2 (including the author) and no vetoes (-1). If a proposal is vetoed, and it cannot be revised to satisfy all parties, then it can be resubmitted for an override vote in which a majority of all eligible voters indicating +1 is sufficient to pass it. Note that this is a majority of all committee members, not just those who actively vote. Upon completion of discussion 
 and voting the author should announce whether they are proceeding (proposal accepted) or are withdrawing their proposal (vetoed). The Chair gets a vote. The Chair is responsible for keeping track of who is a member of the Project Steering Committee. Addition and removal of members from the committee, as well as selection of a Chair should be handled as a proposal to the committee. The Chair adjudicates in cases of disputes about voting.  When is Vote Required?  Any change to committee membership (new members, removing inactive members) Changes to project infrastructure (e.g. tool, location or substantive configuration) Anything that could cause backward compatibility issues. Adding substantial amounts of new code. Changing inter-subsystem API or objects. Issues of procedure. When releases should take place. Anything dealing with relationships with external entities such as OSGeo Anything that might be controversial.  Observations  The Chair is the ultimate adjudicator if things brea
 k down. The absolute majority rule can be used to override an obstructionist veto, but it is intended that in normal circumstances voters need to be convinced to withdraw their veto. We are trying to reach consensus. It is anticipated that separate \u0026ldquo;committees\u0026rdquo; will exist to manage conferences, documentation and web sites. That said, it is expected that the PSC will be the entity largely responsible for creating any such committees.  Committee Membership The PSC is made up of individuals consisting of technical contributors (e.g. developers) and prominent members of the GEOS user community.\nAdding Members Any member of the geos-devel mailing list may nominate someone for committee membership at any time. Only existing PSC committee members may vote on new members. Nominees must receive a majority vote from existing members to be added to the PSC.\nStepping Down If for any reason a PSC member is not able to fully participate then they certainly are free to step
  down. If a member is not active (e.g. no voting, no IRC or email participation) for a period of two months then the committee reserves the right to seek nominations to fill that position.\nShould that person become active again (hey, it happens) then they would certainly be welcome, but would require a nomination.\nMembership Responsibilities Guiding Development Members should take an active role guiding the development of new features they feel passionate about. Once a change request has been accepted and given a green light to proceed does not mean the members are free of their obligation. PSC members voting \u0026ldquo;+1\u0026rdquo; for a change request are expected to stay engaged and ensure the change is implemented and documented in a way that is most beneficial to users. Note that this applies not only to change requests that affect code, but also those that affect the web site, technical infrastructure, policies and standards.\nIRC Meeting Attendance PSC members are expect
 ed to participate in pre-scheduled IRC development meetings. If known in advance that a member cannot attend a meeting, the member should let the meeting organizer know via e-mail.\nMailing List Participation PSC members are expected to be active on both the geos-devel mailing lists, subject to open source mailing list etiquette. Non-developer members of the PSC are not expected to respond to coding level questions on the developer mailing list, however they are expected to provide their thoughts and opinions on user level requirements and compatibility issues when RFC discussions take place.\nBootstrapping Prior to anointing itself the PSW must distribute this RFC to the GEOS community via geos-devel for comment. Any and all substantive comments must be discussed (and hopefully, but not necessarily, addressed via geos-devel.\nInitial members are:\n Dale Lutz Gary Crawford Martin Davis Howard Butler  "},{"id":12,"href":"/development/rfcs/rfc02/","title":"GEOS RFC 2 - Committer Guide
 lines ","parent":"Requests for Comment","content":"This document describes the technical and legal responsibilities of [wiki:PSC GEOS committers].\n         RFC 2 Committer Guidelines   Author Paul Ramsey, Regina Obe   Contact pramsey at cleverelephant.ca, lr at pcorp.us   Status Draft    Summary This document describes the technical and legal responsibilities of [wiki:PSC GEOS committers].\nElection to GIT Commit Access Permission for GIT commit access shall be provided to new developers only if accepted by the [wiki:PSC GEOS Project Steering Committee]. A proposal should be written to the PSC for new committers and voted on normally. It is not necessary to write an RFC document for these votes, a proposal to geos-devel is sufficient.\nEvery developer position in the project is represented by an individual, and commit access will be granted to individuals only, group accounts are not permitted.\nRemoval of GIT commit access should be handled by the same process.\nThe new committer should
  have demonstrated commitment to GEOS and knowledge of the GEOS source code and processes to the committee\u0026rsquo;s satisfaction, usually by reporting bugs, submitting patches, and/or actively participating in the GEOS mailing list(s).\nThe new committer should also be prepared to support any new feature or changes that he/she commits to the GEOS source tree in future releases, or to find someone to which to delegate responsibility for them if he/she stops being available to support the portions of code that he/she is responsible for.\nAll committers should also be a member of the geos-devel mailing list so they can stay informed on policies, technical developments and release preparation.\nBefore being approved, new committers must send an email to the geos-devel mailing list confirming that they have read, understand, and agree to follow the terms of this document.\nCommitter Tracking A list of all project committers will be kept in the GEOS source tree in AUTHORS , listing fo
 r each committer:\n Userid: the id that will appear in the SVN logs for this person. Full name: the users actual name. Email address: A current email address at which the committer can be reached. It may be altered in normal ways to make it harder to auto-harvest. A brief indication of areas of responsibility.  GIT Administrator One member of the Project Steering Committee will be designated the GEOS GIT repository Administrator. That person will be responsible for giving GIT commit access to folks, updating the committers list, and other GIT related management.\nLegal Responsibilities Committers are the front line gatekeepers to keep the code base clear of improperly contributed code. It is important to the GEOS users, developers and the OSGeo foundation to avoid contributing any code to the project without it being clearly licensed under the project license.\nEvery GEOS code contribution should meet the following tests:\n  The person or organization providing code understands that
  the code will be released under the LGPL license.\n  The person or organization providing the code has the legal right to contribute the code.\n  If the contribution was developed on behalf of an employer (on work time, as part of a work project, etc) then it is important that employees have permission from a supervisor or manager to contribute the code.\n  The code should be developed by the contributor, or the code should be from a source which can be rightfully contributed such as from the public domain, or from an open source project under a compatible license.\n  All unusual situations need to be discussed, preferably on the public geos-devel mailing list, and/or documented.\nCommitters should adhere to the following guidelines, and may be personally legally liable for improperly contributing code to the source repository:\n  Make sure the contributor (and possibly employer) is aware of the contribution terms.\n  Code coming from a source other than the contributor (such as ad
 apted from another project) should be clearly marked as to the original source, copyright holders, license terms and so forth. This information can be in the file headers, but should also be added to the project licensing file if not exactly matching normal project licensing (see [source:trunk/COPYING COPYING] file).\n  Existing copyright headers and license text should never be stripped from a file. If a copyright holder wishes to give up copyright they must do so in writing to the OSGeo Foundation before copyright messages are removed. If license terms are changed it has to be by agreement (written in email is OK) of the copyright holders.\n  When substantial contributions are added to a file (such as substantial patches) the author/contributor should be added to the list of copyright holders for the file.\n  If there is uncertainty about whether a change is proper to contribute to the code base, please seek more information from the project steering committee, or the foundation l
 egal counsel.\n  Technical Responsibilities The following are considered good SVN commit practices for the GEOS project.\n  Use meaningful descriptions for commit log entries.\n  Add a bug reference like \u0026ldquo;references #1232\u0026rdquo; or \u0026ldquo;closes #1232\u0026rdquo; at the end of the commit log entries when committing changes related to an existing [wiki:TracTickets Ticket] in the GEOS Trac database, so it\u0026rsquo;s properly linked on the Trac pages (see [wiki:TracLinks])\n  Changes should not be committed in stable branches without a corresponding [wiki:TracTickets Ticket] number. Any change worth pushing into the stable version is worth a [wiki:TracTickets Ticket] entry.\n  Never commit new features to a stable branch without permission of the [wiki:PSC PSC] or release manager. Normally only fixes should go into stable branches. New features go in the main development trunk.\n  Only bug fixes should be committed to the code during pre-release code freeze, with
 out permission from the [wiki:PSC PSC] or release manager.\n  Significant changes to the main development version should be discussed on the geos-devel list before you make them, and larger changes will require a RFC approved by the [wiki:PSC PSC].\n  All source code in GIT should be in Unix text format (LF) as opposed to DOS (CR+LF) or Mac OS text mode (CR).\n  When committing new features or significant changes to existing source code, the committer should take reasonable measures to insure that the source code continues to build and work on the most commonly supported platforms (currently Linux, Windows and Mac OS), either by testing on those platforms directly, running [wiki:Buildbot] tests, or by getting help from other developers working on those platforms. If new files or library dependencies are added, then the configure.in, Makefile.in, Makefile.vc and related documentations should be kept up to date.\n  Every commit introducing new feature *should() be covered with corresp
 onding test case included to the GEOS set of unit tests.\n  "},{"id":13,"href":"/development/rfcs/rfc03/","title":"GEOS RFC 3 - Thread Safe CAPI ","parent":"Requests for Comment","content":"Summary The current CAPI in GEOS is not thread safe. The error handling and initialization/finalization process specifically can cause problems.\nDefinitions (As defined by Frank Warmerdam in http://trac.osgeo.org/gdal/wiki/rfc16_ogr_reentrancy)\nReentrant: A reentrant function can be called simultaneously by multiple threads provided that each invocation of the function references unique data.\nThread-safe: A thread-safe function can be called simultaneously by multiple threads when each invocation references shared data. All access to the shared data is serialized.\nObjective Allow the GEOS CAPI to be thread safe.\nImplementation In order to implement the thread safe API, the current API will be copied and all static variables will be placed into a \u0026lsquo;handle.\u0026rsquo; This handle wi
 ll be initialized on the initGeos call. Once initialized it will be passed to all subsequent GEOS functions, allowing each thread to have it\u0026rsquo;s own copy of the data. This will not affect the current API as it will be provided in addition to the old API. In order to prevent maintenance issues the OLD API will be changed to call the NEW API with a global handle. The handle (GEOSContextHandle_t) will be an opaque type to allow exentensions without recompilation being required. Function names in the new API will be updated with an _r, as is the familiar C standard for reentrant/thread safe versions. Current GEOS functions that do not make reference to the context handle will not be changed.\nThe intent will be to altogether replace the existing functions with the _r functions in a future release, making the thread safe versions the only supported functions.\nHandle Definition Here are the internals of the handle and how the application visual handle will look.\ntypedef struct 
 GEOSContextHandleInternal { const void *geomFactory; GEOSMessageHandler NOTICE_MESSAGE; GEOSMessageHandler ERROR_MESSAGE; int WKBOutputDims; int WKBByteOrder; int initialized; } GEOSConextHandleInternal_t; typedef struct GEOSContextHandle_HS *GEOSContextHandle_t; The typedef for GEOSContextHandle_t will make it easier for the compiler to help detect an incorrect pointer being passed to the functions.\nExample Prototypes Here are examples of what some of the new function prototypes would be.\nGEOSContextHandle_t GEOS_DLL initGEOS_r( GEOSMessageHandler notice_function, GEOSMessageHandler error_function); extern void GEOS_DLL finishGEOS_r(GEOSContextHandle_t handle); extern GEOSGeometry GEOS_DLL *GEOSGeom_createPoint_r(GEOSContextHandle_t handle, GEOSCoordSequence* s); extern GEOSGeometry GEOS_DLL *GEOSGeom_createLinearRing_r(GEOSContextHandle_t handle, GEOSCoordSequence* s); extern GEOSGeometry GEOS_DLL *GEOSGeom_createLineString_r(GEOSContextHandle_t handle, GEOSCoordSequence* s); Fo
 r comparison, here are the same functions as they exist now.\nextern void GEOS_DLL initGEOS(GEOSMessageHandler notice_function, GEOSMessageHandler error_function); extern void GEOS_DLL finishGEOS(void); extern GEOSGeometry GEOS_DLL *GEOSGeom_createPoint(GEOSCoordSequence* s); extern GEOSGeometry GEOS_DLL *GEOSGeom_createLinearRing(GEOSCoordSequence* s); extern GEOSGeometry GEOS_DLL *GEOSGeom_createLineString(GEOSCoordSequence* s); Limitations This change will focus on making a thread safe version of the API. Other extensions to the context handle have been suggested, e.g. Access to other geometry factories, overriding memory allocators. These extensions are beyond the current scope of this design, but this design will be implemented to allow such extensions in the future.\nTesting An example test executable will be provided that shows the current problem. It is copied from the existing CAPI test tool. Once the thread safe API is created the test tool will be updated to the new inter
 face which will address the former problems.\n"},{"id":14,"href":"/development/rfcs/rfc04/","title":"GEOS RFC 4 - Code Formatting Style","parent":"Requests for Comment","content":"This document proposes and describes desired code formatting style used across C/C++ source code in GEOS.\n         RFC 4 Code Formatting Style   Author Mateusz Łoskot   Contact mateusz at loskot.net   Status Dropped (no agreement)    Summary The document proposes and describes desired default code formatting style guidelines for GEOS programming in C and C++ languages.\nThe goal of this document is to initiate process to reach an agreement for the default code formatting style.\nMotivation There is a need to decide on format of GEOS source code and apply such globally consistent format to GEOS C/C++ codebase.\nA uniform, codebase-wide formatting style makes reading and comprehending existing code easier, writing code focused on important aspects of new developments and more pleasant, removes burden during a
  patch or pull request code reviews and prevents bikeshedding religious arguments. Even in small projects, contributing developers discover the problems of working without an agreed upon code format.\nThe utility of such guidelines has been proven by many open source software projects.\nThe scope of the proposal is specifically limited to formatting style guidelines. It is not an intention to develop a general coding guide covering other aspects of writing software like naming, etc.\nProposal It is important to make effortless for developers to produce properly formatted code.\nThe proposal suggests to use clang-format version 3.8 or higher to define C++ code formatting rules for GEOS code.\nThe clang-format is a tool to automatically format C/C++ code, so that developers don\u0026rsquo;t need to worry about style issues. Unlike other tools which use own parsers, clang-format uses the Clang tokenizer and supports the same C++ source code as the Clang compiler. This guarantees correc
 t output is produced and offers unique features (eg. wrapping long lines whether of code, strings, arrays - something which AStyle has no way of doing).\nThe style settings are defined in .clang-format configuration file for our style settings.\nThe clang-format is straightforward to run and can support development workflow as standalone tool or as one of many editor integrations or other bespoke utilities (eg. git cl format [Chromium]).\nNo automation of code reformatting is proposed. It would be treating the symptomps, no cause: developers not following the code formatting standard.\nAlthough no means to enforce the default formatting style are proposed, currently used CI services (eg. Travis CI) may be employed as a post-commit safety valve - a clang-format lint failure as a compile break (eg. clang_format.py build script used by MongoDB). Alternatively, a gatekeeper may be installed in SVN/Git, rejecting commits with code not conforming to the code formatting style.\nCode Format
 ting Rules What code formatting rules to use?\n \u0026ldquo;A mature engineers know that a standard is more important than which standard.\u0026rdquo; ~ MongoDB\n clang-format offers several defaults (eg. LLVM, Mozilla, Linux, Google C++ Style).\nThe proposal recommends to use one of the base styles, if necessary, fine-tuning as an easier way to get started than deciding on each option one by one.\nThe reasons are two-fold:\n make GEOS code unified with the wide spectrum of well-established C/C++ projects long arguments and religious wars prevention.  .clang-format Below is complete set of settings suggested, sufficient to maintain the clean code formatting style.\nNOTE: It remains open for refinements, use different BasedOnStyle as base style, etc.\n--- BasedOnStyle: Mozilla Language: Cpp Standard: Cpp03 ColumnLimit: 80 IndentWidth: 4 TabWidth: 4 UseTab: Never BraceWrapping: AfterClass: true AfterControlStatement: true AfterEnum: true AfterFunction: true AfterNamespace: true AfterO
 bjCDeclaration: true AfterStruct: true AfterUnion: true BeforeCatch: true BeforeElse: true IndentBraces: false BreakBeforeBinaryOperators: None BreakBeforeBraces: Allman BreakBeforeTernaryOperators: true For brevity, the settings above are limited to the base style and points of customizations.\nFor actual implementation, full version of .clang-format should be generated using clang-format -dump-config option and the BasedOnStyle: Mozilla setting commented with #.\n.editorconfig [http://editorconfig.org/ EditorConfig] is currently in use and .editorconfig file is provided to automatically tell popular code editors about the basic style settings like indentation, whitespaces and end-of-line markers for distinguished types of plain text files.\nThe .editorconfig file will have to be updated to match the chosen .clang-format settings.\nEOL clang-format does not enforce line endings.\nThe EOL marker is considered to be [http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20130930/09
 0200.html a part of a file encoding decision] and not part of any coding style.\nThe EOL marker can be enforced as project-wide setting controlled with .gitattributes and .editorconfig.\nHowever, it shall still be left as configurable setting in developer\u0026rsquo;s environment of choice (eg. git config) independently from the project-wide setting.\nBig Reformat What to do about the existing code?\nThe proposal recommends to just do one big reformat of the codebase.\nWhile it may seem causing clutter in the repository log (eg. svn blame), if it occurs infrequently (eg. yearly) and is applied to the entire codebase at that time, it should not be very disruptive to the source code history. One way to cope with skewed history is to use git blame -w which ignores whitespace when comparing commits.\nPartial application of the code formatting rules would create more work without delivering the full benefit [MongoDB] leading to codebase with different styles mixed.\nImplementation Branch
 es to run the big reformat in are:\n trunk branches/3.6 branches/3.5 branches/3.4  After Big Reformat How to work against the natural entropy in a codebase:\n It is highly recommended to use clang-format integration while writing a code. Format changed code before committing or opening pull requests. If you have to commit change in code formatting, do it in separate commit. Avoid commits with a mixture of code and formatting changes.  There is downside of history clutter in repository, but this proposal states that a codebase with different styles across is even worse.     \u0026ldquo;After all, every moment of time wasted on code formatting or discussion thereof is eliminated.\u0026rdquo; ~ MongoDB\n Implementation Set up Travis CI \u0026ldquo;style safety valve\u0026rdquo; build dedicated to run clang-format lint based on the approach used in ​clang_format.py script by MongoDB.\nMiscellaneous Those who build GEOS with GCC 6+ may appreciate consistent code format style as it will
  help to avoid some dozens of the new compiler warnings:\nsrc/geom/Polygon.cpp: In member function ‘virtual int geos::geom::Polygon::getCoordinateDimension() const’: src/geom/Polygon.cpp:154:5: warning: this ‘if’ clause does not guard... [-Wmisleading-indentation] if( shell != NULL ) ^~ src/geom/Polygon.cpp:157:2: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the ‘if’ size_t nholes=holes-\u0026gt;size(); ^~~~~~ References  MongoDB Succeeding With ClangFormat:  https://engineering.mongodb.com/post/succeeding-with-clangformat-part-1-pitfalls-and-planning/ https://engineering.mongodb.com/post/succeeding-with-clangformat-part-2-the-big-reformat/ https://engineering.mongodb.com/post/succeeding-with-clangformat-part-3-persisting-the-change/   Chromium Using clang-format on Chromium C++ Code https://clangformat.com - clang-format interactive guide and builder https://zed0.co.uk/clang-format-configurator/  "},{"id":15,"href":"/developmen
 t/rfcs/rfc05/","title":"GEOS RFC 5 - C++11 Compilation Mode","parent":"Requests for Comment","content":"This document proposes and describes desired code formatting style used across C/C++ source code in GEOS.\n         RFC 5 C++11 Compilation Mode   Author Mateusz Łoskot   Contact mateusz at loskot.net   Status Accepted (no agreement)    Summary The document proposes to switch to C++11 compilation mode as default throughout the whole C++ source code of GEOS.\nThe goal of the document is to request and achieve agreement on using C++11 as the minimum required version of the C++ programming language standard.\nMotivation The C++11 is the first major update of the C++ standard since 1998. (C++03 was a bug fix release.)\nThe C++11 features aim to promote writing clean, compact, type-safe and fast code. It also delivers better feature-wise compatibility with C language (C99).\nThe Wikipedia article at https://en.wikipedia.org/wiki/C++11 does a great job describing all changes in C++11 exte
 nsively.\nThe std::auto_ptr smart pointer, together with a bunch of other features, has been deprecated and will be removed from C++17.\nThe new compilers provide better diagnostics.\nEnabling C++11 compilation mode will improve the programming environment making it much friendlier than C++98.\nA social factor: since (many) C++ programmers no longer enjoy C++98, allowing C++11 mode may increase potential for new contributions.\nCompilers Landscape Summary of compilers supported by GEOS with their minimal versions required to compile source code based on [http://en.cppreference.com/w/cpp/compiler_support C++11 features].\nC++11    Compiler Version Status Support     GCC 4.8.1+ C++11 status Debian 8 (stable), Ubuntu 15.04+, Ubuntu 14.04 ppa:ubuntu-toolchain-r/test, Fedora 19+, RHEL7   Clang 3.3+ C++11 status Debian 8 (stable), Ubuntu 14.04+, Fedora 19+, CentOS 6(?)   MSVC 12.0+ (2013) C++11 status n/a    C++14 The C++14 compilers are listed for comparison only:\n   Compiler Version   
   GCC 4.9+   Clang 3.4+   MSVC 14.0+ (2015)    Plan This proposal only requests agreement for the C++11 compilation mode switch in the current trunk branch only.\nIf accepted, currently available build configurations (Autotools, CMake, NMake) will be updated to switch the compilation mode to C++11.\nThis proposal does not suggest any detailed roadmap of big refactoring of the GEOS C++ codebase.\nThe GEOS codebase is around 150 KLOC and given the available man-power to LOCs ratio, such one-step refactoring would not be feasible.\nInstead, the task will be tackled with the baby step approach gradually transforming the codebase according to priorities set along the way. Any disruptive refactoring, changes in interfaces of C++ classes, breaking changes in C++ API must be announced and discussed on the mailing list or the bug tracker.\nIMPORTANT: C++11 refactoring must not change the C API or break C API compatibility, unless agreed upon based on prior RFC proposed.\nHowever, if the prop
 osal is accepted, any new C++ code written for GEOS can be C++11-compliant.\nPrior acceptance of this proposal is necessary in order to start any source code refactoring using C++11 features.\nOnce accepted, first step will be to update the build configurations to require C++11-compliant compiler.\nIssues This section outlines issues potentially caused by upgrade to C++11 language.\n C++11 destructors, by default, have now the new exception specification of nothrow(true). Destructors of GEOS classes should be reviewed and any that are allowed/expected to throw exceptions must be marked with nothrow(false). Otherwise, any user of the existing GEOS codebase would find the program terminating whenever GEOS destructor throws an exception. Such review would be beneficial anyway.  Release First release of GEOS with C++11 compiler requirement could be 3.7.0 or, perhaps, 4.0.0.\nC++14 This section clarifies status of C++14 support in GEOS.\n Once C++11 is adopted as default compilation mode
 , GEOS developers and maintainers must ensure it also successfully compiles in C++14 and C++17 modes. Are contributors allowed to add ifdef\u0026rsquo;s for C++14 and C++17? No. Is there a plan to upgrade to C++14 or C++17 to allow use of the C++ latest features? No, there is no plan. It is, however, recognized, such motion may be put to the vote around 2020.  References  C++ compiler support  "},{"id":16,"href":"/development/rfcs/rfc06/","title":"GEOS RFC 6 - Require explicit configure to use the C++ API","parent":"Requests for Comment","content":"         RFC 9 Require explicit configure to use the C++ API   Author Regina Obe   Contact lr at pcorp.us   Status Not Passed    Past discussions Trac ticket to deprecate another request to deprecate and osm2pgsql mess more examples about how apps linking directly to GEOS C++ causing problems for other applications Pointing out removing ability to use GEOS C++ reduces users freedoms\nSummary This document proposes to change the ./configure a
 nd CMake to by default only allow use of the C-API.\nThe C++ API headers and library will only be installed if explicitly asked for as detailed in https://lists.osgeo.org/pipermail/geos-devel/2017-October/008054.html\nAny developers who want to use the C++ API will have to build with\n#autoconf users ./configure --with-cplusplus-sdk-install #cmake users cmake -DINSTALL_CPLUSPLUS_SDK If cplusplus sdk install is not expressly requested only the C headers will be included and the C++ headers will not be installed. In addition, when the C++ headers are used by any project, if users choose to build with the cplusplus-sdk, a warning will be shown before start of compile stating:\n The GEOS project does not guarantee ABI stability of the C++ API during minor updates. This means your code may need recompilation or changes to upgrade to next minor version of GEOS. If you want ABI stability from minor version to minor version, you should use the C-API instead.\n In addition the GEOS C++API He
 aders Geometry.h will by default include a warning as noted in https://git.osgeo.org/gogs/geos/geos/pulls/14 as proposed in https://lists.osgeo.org/pipermail/geos-devel/2017-October/008071.html\n The GEOS C++ API is unstable, please use the C API instead HINT: #include geos_c.h\n Which will show during compile time if the following variable is not defined\n WE_ACKNOWLEDGE_THAT_THE_GEOS_CPLUSPLUS_API_IS_UNSTABLE\n This message will continue to be shown in every project that a user tries to compile using GEOS C++ API headers.\nI propose doing this in GEOS 3.7.0.\nThe main purpose is to discourage the use of the C++ API because we do not have the manpower to guarantee ABI or API compatiblity from minor version to minor version and thus using it in an environment where the GEOS library is shared across many software is unsupported. We are also planning significant refactoring in GEOS 3.8 which will very likely break the C++ API.\nCurrently osm2pgsql and OSSIM are the only ones that used
  the GEOS C++ API and largely distributed in shared environment. We want to discourage future projects that plan to be used in a shared environment from using the GEOS C++ API and to stick with the GEOS C API.\nSo the purpose of the above is to affect the following change:\n Package Distributions do not need compile with these flags, though they may choose to at their own risk to support C++ API users. The end effect being, no C++ headers installed and just the C header file installed. People building their own binaries or their own projects that utilize the C++ API may not be able to build using a packaged libgeosdev-++ if packagers don\u0026rsquo;t compile with c++ support. If a package distributtion does choose to offer the headers and take the default of not defining the WE_\u0026hellip; users building with the package will get the above warning at compile time of their project.  That way new projects will be clear about what compromise they are making using the C++ API and if t
 hey are not users will ask\n What is this warning I keep on getting about you using an unstable API?\n "},{"id":17,"href":"/development/rfcs/rfc07/","title":"GEOS RFC 7 - Use CMake for Build System","parent":"Requests for Comment","content":"         RFC 7 Use CMake for build system   Author Daniel Baston   Contact dbaston at gmail.com   Status Accepted, January 15, 2021    This document proposes to use CMake as the build system for GEOS and discontinue use of autotools and NMake.\nSince version 3.5, we have officially supported building GEOS with CMake: https://trac.osgeo.org/geos/wiki/BuildingOnUnixWithCMake\nGEOS is also required to build with autotools and NMake.\nSupporting three build systems:\n Decreases ease of contribution, because any change must be tested against all three build systems. This results in more developer effort devoted to the build system rather than the library itself (see for example, commit history of this PR: https://github.com/libgeos/geos/pull/125) Increa
 ses the risk that differences between build systems cause the library to be compiled with different behavior, or with different version information (for example, see https://trac.osgeo.org/geos/ticket/882) Increases the length of the commit-testing feedback cycle, since multiple build systems must be tested before giving a pull request a \u0026ldquo;green light\u0026rdquo; and insufficient workers are available to test all build systems in parallel.  This RFC proposes that CMake be used as the exclusive build system because:\n It is used by the majority of active committers It is the only cross-platform (OS/compiler) build system  "},{"id":18,"href":"/development/rfcs/rfc08/","title":"GEOS RFC 8 - Improve Coordinate Sequence API (WIP)","parent":"Requests for Comment","content":"         RFC 8 Improve Coordinate Sequence API   Author Martin Davis   Contact martin.davis at crunchydata.com   Status In Discussion    This document proposes to modify the Coordinate Sequence API to improve pe
 rformance and adaptiveness.\nThese improvements are (likely to be) breaking changes to the C++ API.\nThese may require extensions to the C API to be externally available, but should not result in breaking the current C API.\nBackground The Coordinate Sequence API as it stands imposes a large cost on clients.\n It requires copying coordinate list structures one or more times It imposes the cost of a Z ordinate even if not required by the client (related) It is necessary to construct a full Geometry object just to pass a simple Point (e.g. for Point0In-Polygon) (related) Geometry objects for Point and Multi Point are very memory inefficient due to Point overhead  The API also has some functional limitations:\n does not support M values  Downstream projects which are feeling pain:\n PDAL - had to use custom Point-In-Polygon because of overhead in passing points to GEOS Shapely - there are several allocations required to marshall from NumPY to GEOS PostGIS - hopefully this will allow ca
 lling GEOS without copying out of LWGEOM structure  Goals   Allow using external coordinate list structures with no copying (except as needed by GEOS algorithms, e.g. removing repeated points)\n  Prevent mutating of external coordinate structures\n  Support XY, XYM, XYZ, XYZM\n Coord Seq will need to know dimension of coordinates    Support efficient input of Point data\n  Optimized storage of Point and Multi Point data\n  Ideas Memory-based Coordinate Sequence implementation\n Class which contains pointer to memory block of coordinates, length, dimension Coordinate Sequence becomes a slimmed-down interface with accessors Will still provide setters, but use const to prevent unwanted modification How will coordinates be accessed?  By copying into stack-allocated object? This would allow using a Coordinate with XYZM By getX, getY and optional getZ, getM? This requires rewriting some GEOS code to avoid copying coordinates    Templates\n problem: would templates pervade entire code base
 ? does not allow dynamic adapting to external structures?  Prior Art\n C++ string_view  Tasks  Remove extraneous operations from CoordinateSequence (e.g. removeRepeatedPoints) Create a MemoryBasedCoordinateSequence (better name?) which allows access to external blocks of memory Review how Coordinates are accessed - is there a better way? Review how this can provide XYZM capability?  "},{"id":19,"href":"/development/rfcs/rfc09/","title":"GEOS RFC 9 - Restore the C++ API (WIP)","parent":"Requests for Comment","content":"         RFC 9 Restore the C++ API   Author Mateusz Łoskot   Contact mateusz at loskot.net   Status [https://lists.osgeo.org/pipermail/geos-devel/2019-May/008972.html Proposed]    The GEOS library is a C++ library offering two kinds of public API: C++ API and C API.\nThe GEOS library started as a C++ library. The C API was introduced in version 2.2.\nThe GEOS library has never promised any stability of the C++ API and this fact has always been documented and clearly stat
 ed:\non the wiki:\n C++ API (will likely change across versions) C API (provides long-term ABI stability)\n on the front page of the API reference:\n The recommended low-level interface to the GEOS library is the simplified C wrapper interface. This will ensure stability of the API and the ABI of the library during performance improvements that will likely change classes definitions.\nIf you don\u0026rsquo;t care about adapting/rebuilding your client code you can still use the C++ interface.\n in the NEWS file:\n Changes in 2.2.0\n NEW Simplified and stabler C API   The GEOS library as always been deployed as two distinct binaries:\n geos accompanied with the C++ headers. geos_c accompanied with the C header.  Removing the C++ API from the public scope and asking developers to opt-in to use the C++ API,fundamentally breaks the original concept of the library.\nIf there are developers surprised by any breaking changes in the C++ API, it means they have not read the documentation and 
 it is not role of the GEOS developers to make them read it.\nAny user of the GEOS C++ API is expected to be aware of its volatile state and be prepared to update in order to use any newer version of GEOS. These implicit usage terms of the contract, which have always been clear and consistent with nearly any other C++ API, remain unchanged.\nConsidering these issues, there is very little value in the #ifdef USE_UNSTABLE_GEOS_CPP_API and related guards.\nLet\u0026rsquo;s revert the implementation of the RFC6.\n"},{"id":20,"href":"/usage/","title":"Usage","parent":"GEOS","content":""},{"id":21,"href":"/specifications/geojson/","title":"GeoJSON","parent":"Geometry Formats","content":"content\n"},{"id":22,"href":"/specifications/wkb/","title":"Well-Known Binary (WKB)","parent":"Geometry Formats","content":"content\n"},{"id":23,"href":"/specifications/wkt/","title":"Well-Known Text (WKT)","parent":"Geometry Formats","content":"content\n"},{"id":24,"href":"/","title":"GEOS","parent":"","co
 ntent":"GEOS is a C/C++ library for spatial computational geometry of the sort generally used by \u0026ldquo;geographic information systems\u0026rdquo; software. GEOS is a core dependency of PostGIS, QGIS, GDAL, and Shapely.\nCapabilities Spatial Model and Functions\n Geometries: Point, LineString, Polygon, MultiPoint, MultiLineString, MultiPolygon, GeometryCollection Predicates: Intersects, Touches, Disjoint, Crosses, Within, Contains, Overlaps, Equals, Covers Operations: Union, Distance, Intersection, Symmetric Difference, Convex Hull, Envelope, Buffer, Simplify, Polygon Assembly, Valid, Area, Length, Prepared geometries (pre-spatially indexed) STR spatial index OGC Well Known Text (WKT) and Well Known Binary (WKB) encoders and decoders.  API Features  C API (provides long-term API and ABI stability) C++ API (will likely change across versions) Thread safety (using the reentrant API)  License GEOS is open source software available under the terms of GNU Lesser General Public Licen
 se (LGPL).\n"},{"id":25,"href":"/usage/download/","title":"Download Source","parent":"Usage","content":"   Release Date Release Download Link     2021/10/21 3.10.0 geos-3.10.0.tar.bz2   2020/12/10 3.9.1 geos-3.9.1.tar.bz2   2020/03/10 3.8.1 geos-3.8.1.tar.bz2   2019/10/04 3.7.3 geos-3.7.3.tar.bz2   2020/12/11 3.6.5 geos-3.6.5.tar.bz2   2019/10/04 3.5.2 geos-3.5.2.tar.bz2    Build From Source Build Requirements  CMake 3.13 or later. C++11 compiler. We regularly test GCC, Clang and Microsoft Visual C++. Doxygen to build the API documentation.  Build Builds with CMake are done \u0026ldquo;outside the tree\u0026rdquo; either in a build directory in the source tree or next to the tree.\n# Unpack and setup build directory tar xvfz geos-3.10.0.tar.bz2 cd geos-3.10.0 mkdir _build cd _build # Set up the build cmake \\  -DCMAKE_BUILD_TYPE=Release \\  -DCMAKE_INSTALL_PREFIX=/usr/local \\  .. # Run the build, test, install steps make ctest make install Build Options The GEOS build can be custom
 ized using build options.\n   Option Default Note     CMAKE_BUILD_TYPE Release Use Debug to build with debug flags and optimizations off. Use Release for packaging and production installs. Use RelWithDebInfo for optimized build with debug symbols.   CMAKE_INSTALL_PREFIX /usr/local Set to install root. Librarys end up in ./libs headers in ./include   BUILD_DOCUMENTATION ON Attempt to find doxygen executable and build API docs   BUILD_SHARED_LIBS ON Build dynamically linkable libraries.   DISABLE_GEOS_INLINE OFF Turn off inlining. This is bad for performance, only do this if you cannot build to pass tests on your platform with inlining on.    Test Options It is possible to run ctest directly. This gives access to ctest command line options (see ctest \u0026ndash;help for a listing).\nctest ctest --verbose A list of GEOS test suites is obtained by running ctest --show-only:\n$ ctest --show-only # # Test project /home/dan/dev/libgeos/cmake-build-debug # Test #1: test_geos_unit # Test #2
 : test_xmltester # Test #3: test_bug234 # Test #4: test_sweep_line_speed A subset of test suites can be run using a regular expression (and in this case, running 4 jobs in parallel):\n$ ctest --tests-regex test_ --parallel 4 "},{"id":26,"href":"/usage/install/","title":"Install Packages","parent":"Usage","content":"Red Hat There is a GEOS package in the EPEL (Extra Packages for Enterprise Linux) repository.\n# Add the EPEL repository yum -y install epel-release # Install the GEOS runtime and development packages rpm -Uvh geos geos-devel Ubuntu The Ubuntu GIS project maintains a collection of repositories with builds of common open source geospatial projects, including GEOS.\n# Add the Ubuntu GIS PPA sudo apt-get install python-software-properties sudo add-apt-repository ppa:ubuntugis/ppa # Install the packages sudo apt-get install geos Debian The Debian GIS project maintains GEOS packages and pushes them into the appropriate Debian respositories.\nsudo apt-get install geos Amazon Li
 nux Amazon Linux is based on RH7, and can read from the EPEL repository. To enable using Amazon tools, use the amazon-linux-extras utility.\nsudo yum install -y amazon-linux-extras sudo amazon-linux-extras enable epel sudo yum search geos sudo yum install geos geos-devel Homebrew For MacOS, GEOS can be installed using the Homebrew package repository, which downloads source packages and builds them in place using a recipe to ensure all packages integrate with each other nicely.\nFirst install Homebrew. Then:\nbrew install geos Macports For MacOS, GEOS can be installed using the MacPorts package repository, which downloads source packages and builds them in place using a recipe to ensure all packages integrate with each other nicely.\nFirst install MacPorts. Then:\nport install geos "},{"id":27,"href":"/categories/","title":"Categories","parent":"GEOS","content":""},{"id":28,"href":"/tags/","title":"Tags","parent":"GEOS","content":""}]
\ No newline at end of file
+[{"id":0,"href":"/development/rfcs/rfc10/","title":"GEOS RFC 10 - Move Project to GitHub","parent":"Requests for Comment","content":"         RFC 10 Move Project to GitHub   Author Paul Ramsey   Contact pramsey at cleverelephant.ca   Status Accepted, November 9, 2021    GitHub has been the largest source of 3rd party code contribution via pull-requests for some time now.\nMoving to Github has the following components:\n Move the canonical (writeable) repository to GitHub Migrate the (current, useful) contents of the Trac wiki to the new web framework Deleting the migrated and out-of-date contents of the Trac wiki Switching the Trac tickets to read-only Web scraping the Trac ticket contents and placing in a geos-old-tickets repo  At that point:\n New code is pushed to GitHub New issues are filed at GitHub New documentation is committed to the repository  This should unlock:\n Easier path for new contributors to discover and assist with the project Easier collaboration with downstream pr
 ojects Far easier story on \u0026ldquo;how to we manage the project\u0026rdquo; and \u0026ldquo;where the important things happen\u0026rdquo; Far less dependence on individual contributors for infrastructure work that only they can do  "},{"id":1,"href":"/posts/","title":"News","parent":"GEOS","content":""},{"id":2,"href":"/development/psc/","title":"Project Steering Committee","parent":"Development","content":"The GEOS project is run by a Project Steering Committee made up of developers and contributors to the project and is a project of OSGeo. Major project decisions are made via a Request for Comments (RFC) process, where proposals are first documented and then voted on by the steering committee.\nThe current PSC will refresh itself using the mechanisms in RFC-1.\nThis PSC list is valid as of Oct 23, 2019.\n Sandro Santilli (chair) Martin Davis  Howard Butler \u0026lt;hobu.inc at gmail dot com\u0026gt; Regina Obe  Dale Lutz  Paul Ramsey  Dan Baston   The PSC approves major change
 s and RFC documents. Minor work is ongoing, by the PSC and by the other committers, listed below:\n Vicky Vergara Kurt Schwehr  Historical committers:\n Mateusz Loskot Charlie Savage Norman Vine Sean Gillies Frank Warmerdam Ben Jubb Chuck Thibert Stephen Wong  "},{"id":3,"href":"/development/rfcs/","title":"Requests for Comment","parent":"Development","content":"Process The Request for Comments process is as follows:\n Create a pull request against this repository adding a new RFC document outlining your planned change. Solicit comment and feedback on geos-devel. Call for a vote on the RFC. Note the status and commit the RFC to the web site for the record.  RFCs    GEOS RFC 1 - Project Steering Committee     GEOS RFC 2 - Committer Guidelines      GEOS RFC 3 - Thread Safe CAPI      GEOS RFC 4 - Code Formatting Style     GEOS RFC 5 - C\u0026#43;\u0026#43;11 Compilation Mode     GEOS RFC 6 - Require explicit configure to use the C\u0026#43;\u0026#43; API     GEOS RFC 7 - Use CMake for 
 Build System     GEOS RFC 8 - Improve Coordinate Sequence API (WIP)     GEOS RFC 9 - Restore the C\u0026#43;\u0026#43; API (WIP)     GEOS RFC 10 - Move Project to GitHub     "},{"id":4,"href":"/usage/doxygen/","title":"Reference Docs","parent":"Usage","content":"The Doxygen documentation is the most up-to-date reference for the C and C++ API of GEOS.\n C API C++ API  "},{"id":5,"href":"/usage/c_api/","title":"C API Programming","parent":"Usage","content":"Most programs using GEOS use the C API, rather than building against the C++ headers. The C API offers the a number of benefits:\n Stable API, that preserves behaviour and function naming over multiple releases. Stable ABI, allowing new binaries to be dropped into place without requiring a rebuild of dependent applications. Simple access pattern, using the simple features model as the basis for most operations.  In exchange for this simplicity and stability, the C API has a few requirements from application authors:\n Explicit memo
 ry management. If you create a GEOS object with a GEOS function, you have to remember to free it using the appropriate GEOS destructor.  The C API is entirely contained in the geos_c.h header file.\nBuilding a Program The simplest GEOS C API application needs to include the API header, declare a message handler, initialize the GEOS globals, and link to the GEOS C library when built.\n/* geos_hello_world.c */ #include \u0026lt;stdio.h\u0026gt; /* for printf */#include \u0026lt;stdarg.h\u0026gt; /* for va_list */ /* Only the CAPI header is required */ #include \u0026lt;geos_c.h\u0026gt; /* * GEOS requires two message handlers to return * error and notice message to the calling program. * * typedef void(* GEOSMessageHandler) (const char *fmt,...) * * Here we stub out an example that just prints the * messages to stdout. */ static void geos_msg_handler(const char* fmt, ...) { va_list ap; va_start(ap, fmt); vprintf (fmt, ap); va_end(ap); } int main() { /* Send notice and error messages t
 o the terminal */ initGEOS(geos_msg_handler, geos_msg_handler); /* Read WKT into geometry object */ GEOSWKTReader* reader = GEOSWKTReader_create(); GEOSGeometry* geom_a = GEOSWKTReader_read(reader, \u0026#34;POINT(1 1)\u0026#34;); /* Convert result to WKT */ GEOSWKTWriter* writer = GEOSWKTWriter_create(); char* wkt = GEOSWKTWriter_write(writer, geom_a); printf(\u0026#34;Geometry: %s\\n\u0026#34;, wkt); /* Clean up allocated objects */ GEOSWKTReader_destroy(reader); GEOSWKTWriter_destroy(writer); GEOSGeom_destroy(geom_a); GEOSFree(wkt); /* Clean up the global context */ finishGEOS(); return 0; } When compiling the program, remember to link in the GEOS C library.\ncc geos_hello_world.c -o geos_hello_world -l geos_c Reentrant/Threadsafe API Every function in the examples above and below is shadowed by a reentrant function carrying a _r suffix. The reentrant functions work the same as their simple counterparts, but they all have one extra parameter, a GEOSContextHandle_t.\nThe GEOSConte
 xtHandle_t carries a thread-local state that is equivalent to the state initialized by the initGEOS() call in the simple example above.\nTo use the reentrant API, you skip calling initGEOS() and instead call GEOS_init_r() to create a context local to your thread. Each thread that will be running GEOS operations should create its own context prior to working with the GEOS API.\n/* geos_hello_world.c */ #include \u0026lt;stdio.h\u0026gt; /* for printf */#include \u0026lt;stdarg.h\u0026gt; /* for va_list */ /* Only the CAPI header is required */ #include \u0026lt;geos_c.h\u0026gt; static void geos_msg_handler(const char* fmt, ...) { va_list ap; va_start(ap, fmt); vprintf (fmt, ap); va_end(ap); } int main() { /* Send notice and error messages to the terminal */ GEOSContextHandle_t ctx = GEOS_init_r (); GEOSContext_setNoticeHandler_r(ctx, geos_msg_handler); GEOSContext_setErrorHandler_r(ctx, geos_msg_handler); /* Read WKT into geometry object */ GEOSWKTReader* reader = GEOSWKTReader_crea
 te_r(ctx); GEOSGeometry* geom_a = GEOSWKTReader_read_r(ctx, reader, \u0026#34;POINT(1 1)\u0026#34;); /* Convert result to WKT */ GEOSWKTWriter* writer = GEOSWKTWriter_create_r(ctx); char* wkt = GEOSWKTWriter_write_r(ctx, writer, geom_a); printf(\u0026#34;Geometry: %s\\n\u0026#34;, wkt); /* Clean up allocated objects */ GEOSWKTReader_destroy_r(ctx, reader); GEOSWKTWriter_destroy_r(ctx, writer); GEOSGeom_destroy_r(ctx, geom_a); GEOSFree_r(ctx, wkt); /* Clean up the global context */ GEOS_finish_r(ctx); return 0; } Note that the overall structure of the code is identical, but the reentrant variants are used, and the preamble and cleanup are slightly different.\nObject Model The GEOSCoordSequence and GEOSGeometry objects are at the heart of the GEOS object model.\nGEOSCoordSequence GEOSCoordSequence is an ordered list of coordinates (2 or 3 dimensional). There are a number of ways to make a GEOSCoordSequence.\nYou can create a GEOSCoordSequence by creating a blank one and then setting t
 he coordinate values.\ndouble xList[] = {1.0, 2.0, 3.0}; double yList[] = {3.0, 2.0, 1.0}; size_t seqSize = 3; size_t seqDims = 2; GEOSCoordSequence* seq = GEOSCoordSeq_create(seqSize, seqDims); for (size_t i = 0; i \u0026lt; seqSize; i++) { seq-\u0026gt;setXY(i, xList[i], yList[i]); } GEOSCoordSeq_destroy(seq); You can also create a GEOSCoordSequence and populate it simultaneously from coordinate arrays.\ndouble xList[] = {1.0, 2.0, 3.0}; double yList[] = {3.0, 2.0, 1.0}; size_t seqSize = 3; GEOSCoordSequence* seq = GEOSCoordSeq_copyFromArrays( xList, yList, NULL, /* Zs */ NULL, /* Ms */ seqSize); GEOSCoordSeq_destroy(seq); Finally, you can create a GEOSCoordSequence and populate it simultaneously directly from a single coordinate buffer (an array of double in coordinate order, eg: XYXYXYX).\n/* Coordinates in a buffer (X,Y, X,Y, X,Y) */ double coordBuf[] = {1.0,3.0, 2.0,2.0, 3.0,1.0}; size_t seqSize = 3; GEOSCoordSequence* seq = GEOSCoordSeq_copyFromBuffer( coordBuf, seqSize, 0, /
 * hasZ */ 0 /* hasM */ ); GEOSCoordSeq_destroy(seq); Note that while you can reclaim the memory for a GEOSCoordSequence directly using GEOSCoordSeq_destroy(), you usually will not have to since creating a GEOSGeometry with a GEOSCoordSequence hands ownership of the sequence to the new geometry.\nWhen writing data back from GEOS to whatever application you are using, you have the option of using a standard serialization format like WKB (see below) or by writing back to arrays or buffers.\n GEOSCoordSeq_copyToArrays() GEOSCoordSeq_copyToBuffer()  Using the array or buffer methods can often be faster than using direct coordinate reading or serialization formats, if the target structures use coordinate arrays or XY binary buffers.\nGEOSGeometry The workhorse of the GEOS C API is the GEOSGeometry. GEOSGeometry can be a point, linestring, polygon, multipoint, multilinestring, multipolygon, or geometrycollection. Most functions in the GEOS C API have a GEOSGeometry as a parameter or return
  type. Clean up GEOSGeometry using GEOSGeom_destroy().\nThere are many constructors for GEOSGeometry:\n GEOSGeom_createPoint() GEOSGeom_createPointFromXY() GEOSGeom_createLinearRing() GEOSGeom_createLineString() GEOSGeom_createPolygon() GEOSGeom_createCollection() GEOSGeom_createEmptyPoint() GEOSGeom_createEmptyLineString() GEOSGeom_createEmptyPolygon() GEOSGeom_createEmptyCollection()  The \u0026ldquo;createEmpty\u0026rdquo; functions take no arguments are return geometries that are \u0026ldquo;empty\u0026rdquo;, that is they represent an empty set of space. The intersection of two disjoint polygons is a \u0026ldquo;empty polygon\u0026rdquo;, for example.\nThe GEOSGeom_createPoint(), GEOSGeom_createLinearRing() and GEOSGeom_createLinearRing() all take in a single GEOSCoordSequence and take ownership of that sequence, so freeing the geometry with GEOSGeom_destroy() frees all memory.\ndouble coordBuf[] = {1.0,3.0, 2.0,2.0, 3.0,1.0}; size_t seqSize = 3; GEOSCoordSequence* seq = GEOSCo
 ordSeq_copyFromBuffer( coordBuf, seqSize, 0, 0); /* Takes ownership of sequence */ GEOSGeometry* geom = GEOSGeom_createLineString(seq); /* Frees all memory */ GEOSGeom_destroy(geom); The GEOSGeom_createPolygon() and GEOSGeom_createCollection() functions both require an array of inputs:\n an array of inner ring GEOSCoordSequence to create polygons; and, an array of GEOSGeometry to create collections.  As in the other creation functions, ownership of the contained objects is transferred to the new geometry. However, ownership of the array that holds the contained objects is not transferred.\n/* Two points in an array */ size_t npoints = 2; GEOSGeometry** points = malloc(sizeof(GEOSGeometry*) * npoints); points[0] = GEOSGeom_createPointFromXY(0.0, 0.0); points[1] = GEOSGeom_createPointFromXY(0.0, 0.0); /* takes ownership of the points in the array */ /* but not the array itself */ GEOSGeometry* collection = GEOSGeom_createCollection( GEOS_MULTIPOINT, /* collection type */ points, /* ge
 ometry array */ npoints); /* frees collection and contained points */ GEOSGeom_destroy(collection); /* frees the containing array */ free(points); Readers and Writers The examples above build GEOSCoordSequence from arrays of double, and GEOSGeometry from coordinate sequences, but it is also possible to directly read from and write to standard geometry formats:\n Well-Known Text (WKT) Well-Known Binary (WKB) GeoJSON  For example, reading and writing WKT:\nconst char* wkt_in = \u0026#34;POLYGON((0 0, 10 0, 10 10, 0 10, 0 0))\u0026#34;; /* Read the WKT into geometry object */ GEOSWKTReader* reader = GEOSWKTReader_create(); GEOSGeometry* geom = GEOSWKTReader_read(reader, wkt_in); /* Convert geometry back to WKT */ GEOSWKTWriter* writer = GEOSWKTWriter_create(); /* Trim trailing zeros off output */ GEOSWKTWriter_setTrim(writer, 1); char* wkt_out = GEOSWKTWriter_write(writer, geom); /* Clean up everything we allocated */ GEOSWKTReader_destroy(reader); GEOSGeom_destroy(geom); /* Use GEOSFr
 ee() to free memory allocated inside GEOS~ */ GEOSFree(wkt_out); Note that the output WKT string is freed using GEOSFree(), not the system free(). This ensures that the same library that allocates the memory also frees it, which is important for some platforms (Windows primarily).\nFor more information about the specific options available for each format, see the documentation for the various readers and writers.\n GEOSWKTReader / GEOSWKTWriter GEOSWKBReader / GEOSWKBWriter GEOSGeoJSONReader / GEOSGeoJSONWriter  For a complete example using a reader and writer, see capi_read.c.\nPrepared Geometry The GEOS \u0026ldquo;prepared geometry\u0026rdquo; is conceptually similar to a database \u0026ldquo;prepared statement\u0026rdquo;: by doing a little up-front work to set-up a handler, you can reap a performance benefit when you execute repeated function calls on that object.\nPrepared geometries contain internal indexes that make calls to the \u0026ldquo;spatial predicate\u0026rdquo; func
 tions like GEOSPreparedIntersects() and GEOSPreparedContains() much much faster. These are functions that take in two geometries and return true or false.\nIf you are going to be making repeated calls to predicates on the same geometry, using a prepared geometry could be a big performance boost, at the cost of a little extra complexity.\n/* One concave polygon */ const char* wkt = \u0026#34;POLYGON ((189 115, 200 170, 130 170, 35 242, 156 215, 210 290, 274 256, 360 190, 267 215, 300 50, 200 60, 189 115))\u0026#34;; /* Read the WKT into geometry objects */ GEOSWKTReader* reader = GEOSWKTReader_create(); GEOSGeometry* geom = GEOSWKTReader_read(reader, wkt); GEOSWKTReader_destroy(reader); /* Prepare the geometry */ const GEOSPreparedGeometry* prep_geom = GEOSPrepare(geom); /* Make a point to test */ GEOSGeometry* pt = GEOSGeom_createPointFromXY(190, 200); /* Check if the point and polygon intersect */ if (GEOSPreparedIntersects(prep_geom, pt)) { /* done something ... */ } /* Note that 
 both prepared and original geometry are destroyed */ GEOSPreparedGeom_destroy(prep_geom); GEOSGeom_destroy(geom); GEOSGeom_destroy(pt); For a complete example of using prepared geometry to accelerate multiple predicate tests, see the capi_prepared.c example.\nSTRTree Index  GEOSSTRtree  "},{"id":6,"href":"/usage/cpp_api/","title":"C++ API Programming","parent":"Usage","content":"The GEOS C++ API is included in the collection of header files installed in include/geos which is a very large collection. Effectively it includes both \u0026ldquo;public\u0026rdquo; headers that a user might be expected to make use of and \u0026ldquo;private\u0026rdquo; headers that are mostly only used by internal algorithms. Currently, the two kinds of headers are not marked in any way, nor is there an easy way to disentagle them.\nUsing the C++ API means giving up:\n Stable API, since headers can be moved, re-named or deleted according to the implementation needs of the library. Stable ABI, since the com
 plexity of the GEOS symbol space means that binary symbols are known change between versions, even relatively small releases.  However, if you are careful in restricting your usage you can build applications against the C++ API that avoid most issues:\n Use Geometry as your primary handle, and sub-classes like Point, LineString and Polygon as necessary. Use the reader and writer classes for data access. Use the TemplateSTRtree for indexing. Use the PreparedGeometry class as needed.  One benefit of using the C++ API is access to more modern C++ facilities, like the std::unique_ptr and std::string.\nBuilding a Program The simplest GEOS C++ API application needs to include the geom::Geometry.h header and geom::GeometryFactory.h header, to construct new geometries. To read geometries from input formats, a reader such as geom::WKTReader.h will also be required.\n/* * # GEOS C++ example 1 * * Reads two WKT representations and calculates the * intersection, prints it out, and cleans up. * 
 * In general, to avoid API changes, stick to operations * on Geometry. The more esoteric APIs are more likely * to change between versions. */ #include \u0026lt;iostream\u0026gt; /* For geometry operations */ #include \u0026lt;geos/geom/GeometryFactory.h\u0026gt;#include \u0026lt;geos/geom/Geometry.h\u0026gt; /* For WKT read/write */ #include \u0026lt;geos/io/WKTReader.h\u0026gt;#include \u0026lt;geos/io/WKTWriter.h\u0026gt; /* Geometry/GeometryFactory */ using namespace geos::geom; /* WKTReader/WKTWriter */ using namespace geos::io; int main() { /* New factory with default (float) precision model */ GeometryFactory::Ptr factory = GeometryFactory::create(); /* * Reader requires a factory to bind the geometry to * for shared resources like the PrecisionModel */ WKTReader reader(*factory); /* Input WKT strings */ std::string wkt_a(\u0026#34;POLYGON((0 0, 10 0, 10 10, 0 10, 0 0))\u0026#34;); std::string wkt_b(\u0026#34;POLYGON((5 5, 15 5, 15 15, 5 15, 5 5))\u0026#34;); /* Convert WKT t
 o Geometry */ std::unique_ptr\u0026lt;Geometry\u0026gt; geom_a(reader.read(wkt_a)); std::unique_ptr\u0026lt;Geometry\u0026gt; geom_b(reader.read(wkt_b)); /* Calculate intersection */ std::unique_ptr\u0026lt;Geometry\u0026gt; inter = geom_a-\u0026gt;intersection(geom_b.get()); /* Convert Geometry to WKT */ WKTWriter writer; writer.setTrim(true); std::string inter_wkt = writer.write(inter.get()); /* Print out results */ std::cout \u0026lt;\u0026lt; \u0026#34;Geometry A: \u0026#34; \u0026lt;\u0026lt; wkt_a \u0026lt;\u0026lt; std::endl; std::cout \u0026lt;\u0026lt; \u0026#34;Geometry B: \u0026#34; \u0026lt;\u0026lt; wkt_b \u0026lt;\u0026lt; std::endl; std::cout \u0026lt;\u0026lt; \u0026#34;Intersection(A, B): \u0026#34; \u0026lt;\u0026lt; inter_wkt \u0026lt;\u0026lt; std::endl; } "},{"id":7,"href":"/posts/2021-10-01-geos-3-10-released/","title":"Version 3.10.0","parent":"News","content":"The 3.10 release of GEOS is now available to download.\n  This release includes the following new fe
 atures in the C API (and of course underlying changes to the C++ code to support these features):\n CAPI additions for testing whether geometries are within a distance of each other, GEOSDistanceWithin and GEOSPreparedDistanceWithin CAPI addition for adding extra vertices to a geometry, GEOSDensify CAPI additions for high-performance construction/reading of coordinate sequences from/to memory buffers, GEOSCoordSeq_copyFromArrays, GEOSCoordSeq_copyFromBuffer, GEOSCoordSeq_copyToArrays, and GEOSCoordSeq_copyToBuffer CAPI addition for new validity enforement algorithm, GEOSMakeValidWithParams CAPI addition for ISO WKB output, GEOSWKBWriter_getFlavor and GEOSWKBWriter_setFlavor CAPI addition to create a constrained delaunay of polygonal input, GEOSConstrainedDelaunayTriangulation    There is a new utility for running arbitrary GEOS commands against input files, geosop. See the user guide for examples.\n  The C API is now fully documented and available as a reference document.\n  The IsV
 alidOp and IsSimpleOp have been re-written for higher performance in general and faster response for \u0026ldquo;simple\u0026rdquo; cases of invalidity.\n  The STRtree has been replaced with a templated version that is even faster than before. This has improved algorithm performance across the board.\n  There have been numerous other bug fixes and performance tweaks.\n  "},{"id":8,"href":"/development/ci_status/","title":"CI Status","parent":"Development","content":"   Branch GitHub Debbie Winnie Dronie GitLab Bessie Bessie32     main          3.10          3.9          3.8          3.7           Runners  Debbie - Debian 8.2, GNU/Linux 64bit, GCC Debian 8.2.0-3, automake Winnie - Windows Mingw64, 32bit GCC 8.1.0, 64bit GCC 8.1.0, MSys CMake Dronie - Alpine Linux 3.4, 64bit, GCC 5.3.0, automake GitLab - Debian 8.2, GNU/Linux 64bit, gcc, automake Bessie - FreeBSD 12.2, 64-bit clang 6.0, 64bit gcc, CMake (3.11) \u0026gt;=3.8, autotools \u0026lt; 3.8 Bessie32 - FreeBSD 12.2, 32-bit clan
 g 6.0, 64bit gcc, CMake (3.11) \u0026gt;=3.8, autotools \u0026lt; 3.8 GitHub - Ubuntu various versions, Windows various, CMake  "},{"id":9,"href":"/development/","title":"Development","parent":"GEOS","content":"Developer Resources  Code repository: https://github.com/libgeos/geos Developer mailing list: https://lists.osgeo.org/mailman/listinfo/geos-devel Developer chat channel:  Matrix: https://matrix.to/#/#geos:osgeo.org Slack: https://osgeo.slack.com/messages/C07RKJ06B/    Relationship to JTS GEOS started as a direct port to C++ of the JTS Topology Suite (JTS), and remains tightly bound to that project. Most core algorithms have been prototyped in JTS and ported to GEOS when complete.\nThe projects attempt to share testing data, and to ascertain when failures are caused by differences in implementation (GEOS fails and JTS does not) and when they are caused by algorithm (both libraries fail).\nGovernance The GEOS project is run by a Project Steering Committee made up of developers 
 and contributors to the project and is a project of OSGeo.\n"},{"id":10,"href":"/specifications/","title":"Geometry Formats","parent":"GEOS","content":"    GeoJSON     Well-Known Binary (WKB)     Well-Known Text (WKT)     More\n"},{"id":11,"href":"/development/rfcs/rfc01/","title":"GEOS RFC 1 - Project Steering Committee","parent":"Requests for Comment","content":"This document describes how the PSC GEOS Project Steering Committee determines membership, and makes decisions on all aspects of the GEOS project - both technical and non-technical.\n         RFC 1 Project Steering Committee   Author Paul Ramsey   Contact pramsey at cleverelephant.ca   Status Approved, April 10, 2008    Summary This document describes how the GEOS Project Steering Committee (PSC) determines membership, and makes decisions on all aspects of the GEOS project - both technical and non-technical.\nExamples of PSC management responsibilities:\n setting the overall development road map developing technical standards
  and policies (e.g. coding standards, file naming conventions, etc\u0026hellip;) ensuring regular releases (major and maintenance) of GEOS software reviewing RFC for technical enhancements to the software project infrastructure (e.g. SVN, bug tracking, hosting options, etc\u0026hellip;) formalization of affiliation with external entities such as OSGeo setting project priorities, especially with respect to project sponsorship creation and oversight of specialized sub-committees (e.g. project infrastructure, training)  In brief the project team votes on proposals on geos-devel. Proposals are available for review for at least two days, and a single veto is sufficient delay progress though ultimately a majority of members can pass a proposal.\nDetailed Process  Proposals are announced on the geos-devel mailing list for discussion and voting, by any interested party, not just committee members. Proposals need to be available for review for at least two business days before a final decisi
 on can be made. Respondents may vote \u0026ldquo;+1\u0026rdquo; to indicate support for the proposal and a willingness to support implementation. Respondents may vote \u0026ldquo;-1\u0026rdquo; to veto a proposal, but must provide clear reasoning and alternate approaches to resolving the problem within the two days. A vote of -0 indicates mild disagreement, but has no effect. A 0 indicates no opinion. A +0 indicate mild support, but has no effect. Anyone may comment on proposals on the list, but only members of the Project Steering Committee\u0026rsquo;s votes will be counted. A proposal will be accepted if it receives +2 (including the author) and no vetoes (-1). If a proposal is vetoed, and it cannot be revised to satisfy all parties, then it can be resubmitted for an override vote in which a majority of all eligible voters indicating +1 is sufficient to pass it. Note that this is a majority of all committee members, not just those who actively vote. Upon completion of discussion 
 and voting the author should announce whether they are proceeding (proposal accepted) or are withdrawing their proposal (vetoed). The Chair gets a vote. The Chair is responsible for keeping track of who is a member of the Project Steering Committee. Addition and removal of members from the committee, as well as selection of a Chair should be handled as a proposal to the committee. The Chair adjudicates in cases of disputes about voting.  When is Vote Required?  Any change to committee membership (new members, removing inactive members) Changes to project infrastructure (e.g. tool, location or substantive configuration) Anything that could cause backward compatibility issues. Adding substantial amounts of new code. Changing inter-subsystem API or objects. Issues of procedure. When releases should take place. Anything dealing with relationships with external entities such as OSGeo Anything that might be controversial.  Observations  The Chair is the ultimate adjudicator if things brea
 k down. The absolute majority rule can be used to override an obstructionist veto, but it is intended that in normal circumstances voters need to be convinced to withdraw their veto. We are trying to reach consensus. It is anticipated that separate \u0026ldquo;committees\u0026rdquo; will exist to manage conferences, documentation and web sites. That said, it is expected that the PSC will be the entity largely responsible for creating any such committees.  Committee Membership The PSC is made up of individuals consisting of technical contributors (e.g. developers) and prominent members of the GEOS user community.\nAdding Members Any member of the geos-devel mailing list may nominate someone for committee membership at any time. Only existing PSC committee members may vote on new members. Nominees must receive a majority vote from existing members to be added to the PSC.\nStepping Down If for any reason a PSC member is not able to fully participate then they certainly are free to step
  down. If a member is not active (e.g. no voting, no IRC or email participation) for a period of two months then the committee reserves the right to seek nominations to fill that position.\nShould that person become active again (hey, it happens) then they would certainly be welcome, but would require a nomination.\nMembership Responsibilities Guiding Development Members should take an active role guiding the development of new features they feel passionate about. Once a change request has been accepted and given a green light to proceed does not mean the members are free of their obligation. PSC members voting \u0026ldquo;+1\u0026rdquo; for a change request are expected to stay engaged and ensure the change is implemented and documented in a way that is most beneficial to users. Note that this applies not only to change requests that affect code, but also those that affect the web site, technical infrastructure, policies and standards.\nIRC Meeting Attendance PSC members are expect
 ed to participate in pre-scheduled IRC development meetings. If known in advance that a member cannot attend a meeting, the member should let the meeting organizer know via e-mail.\nMailing List Participation PSC members are expected to be active on both the geos-devel mailing lists, subject to open source mailing list etiquette. Non-developer members of the PSC are not expected to respond to coding level questions on the developer mailing list, however they are expected to provide their thoughts and opinions on user level requirements and compatibility issues when RFC discussions take place.\nBootstrapping Prior to anointing itself the PSW must distribute this RFC to the GEOS community via geos-devel for comment. Any and all substantive comments must be discussed (and hopefully, but not necessarily, addressed via geos-devel.\nInitial members are:\n Dale Lutz Gary Crawford Martin Davis Howard Butler  "},{"id":12,"href":"/development/rfcs/rfc02/","title":"GEOS RFC 2 - Committer Guide
 lines ","parent":"Requests for Comment","content":"This document describes the technical and legal responsibilities of [wiki:PSC GEOS committers].\n         RFC 2 Committer Guidelines   Author Paul Ramsey, Regina Obe   Contact pramsey at cleverelephant.ca, lr at pcorp.us   Status Draft    Summary This document describes the technical and legal responsibilities of [wiki:PSC GEOS committers].\nElection to GIT Commit Access Permission for GIT commit access shall be provided to new developers only if accepted by the [wiki:PSC GEOS Project Steering Committee]. A proposal should be written to the PSC for new committers and voted on normally. It is not necessary to write an RFC document for these votes, a proposal to geos-devel is sufficient.\nEvery developer position in the project is represented by an individual, and commit access will be granted to individuals only, group accounts are not permitted.\nRemoval of GIT commit access should be handled by the same process.\nThe new committer should
  have demonstrated commitment to GEOS and knowledge of the GEOS source code and processes to the committee\u0026rsquo;s satisfaction, usually by reporting bugs, submitting patches, and/or actively participating in the GEOS mailing list(s).\nThe new committer should also be prepared to support any new feature or changes that he/she commits to the GEOS source tree in future releases, or to find someone to which to delegate responsibility for them if he/she stops being available to support the portions of code that he/she is responsible for.\nAll committers should also be a member of the geos-devel mailing list so they can stay informed on policies, technical developments and release preparation.\nBefore being approved, new committers must send an email to the geos-devel mailing list confirming that they have read, understand, and agree to follow the terms of this document.\nCommitter Tracking A list of all project committers will be kept in the GEOS source tree in AUTHORS , listing fo
 r each committer:\n Userid: the id that will appear in the SVN logs for this person. Full name: the users actual name. Email address: A current email address at which the committer can be reached. It may be altered in normal ways to make it harder to auto-harvest. A brief indication of areas of responsibility.  GIT Administrator One member of the Project Steering Committee will be designated the GEOS GIT repository Administrator. That person will be responsible for giving GIT commit access to folks, updating the committers list, and other GIT related management.\nLegal Responsibilities Committers are the front line gatekeepers to keep the code base clear of improperly contributed code. It is important to the GEOS users, developers and the OSGeo foundation to avoid contributing any code to the project without it being clearly licensed under the project license.\nEvery GEOS code contribution should meet the following tests:\n  The person or organization providing code understands that
  the code will be released under the LGPL license.\n  The person or organization providing the code has the legal right to contribute the code.\n  If the contribution was developed on behalf of an employer (on work time, as part of a work project, etc) then it is important that employees have permission from a supervisor or manager to contribute the code.\n  The code should be developed by the contributor, or the code should be from a source which can be rightfully contributed such as from the public domain, or from an open source project under a compatible license.\n  All unusual situations need to be discussed, preferably on the public geos-devel mailing list, and/or documented.\nCommitters should adhere to the following guidelines, and may be personally legally liable for improperly contributing code to the source repository:\n  Make sure the contributor (and possibly employer) is aware of the contribution terms.\n  Code coming from a source other than the contributor (such as ad
 apted from another project) should be clearly marked as to the original source, copyright holders, license terms and so forth. This information can be in the file headers, but should also be added to the project licensing file if not exactly matching normal project licensing (see [source:trunk/COPYING COPYING] file).\n  Existing copyright headers and license text should never be stripped from a file. If a copyright holder wishes to give up copyright they must do so in writing to the OSGeo Foundation before copyright messages are removed. If license terms are changed it has to be by agreement (written in email is OK) of the copyright holders.\n  When substantial contributions are added to a file (such as substantial patches) the author/contributor should be added to the list of copyright holders for the file.\n  If there is uncertainty about whether a change is proper to contribute to the code base, please seek more information from the project steering committee, or the foundation l
 egal counsel.\n  Technical Responsibilities The following are considered good SVN commit practices for the GEOS project.\n  Use meaningful descriptions for commit log entries.\n  Add a bug reference like \u0026ldquo;references #1232\u0026rdquo; or \u0026ldquo;closes #1232\u0026rdquo; at the end of the commit log entries when committing changes related to an existing [wiki:TracTickets Ticket] in the GEOS Trac database, so it\u0026rsquo;s properly linked on the Trac pages (see [wiki:TracLinks])\n  Changes should not be committed in stable branches without a corresponding [wiki:TracTickets Ticket] number. Any change worth pushing into the stable version is worth a [wiki:TracTickets Ticket] entry.\n  Never commit new features to a stable branch without permission of the [wiki:PSC PSC] or release manager. Normally only fixes should go into stable branches. New features go in the main development trunk.\n  Only bug fixes should be committed to the code during pre-release code freeze, with
 out permission from the [wiki:PSC PSC] or release manager.\n  Significant changes to the main development version should be discussed on the geos-devel list before you make them, and larger changes will require a RFC approved by the [wiki:PSC PSC].\n  All source code in GIT should be in Unix text format (LF) as opposed to DOS (CR+LF) or Mac OS text mode (CR).\n  When committing new features or significant changes to existing source code, the committer should take reasonable measures to insure that the source code continues to build and work on the most commonly supported platforms (currently Linux, Windows and Mac OS), either by testing on those platforms directly, running [wiki:Buildbot] tests, or by getting help from other developers working on those platforms. If new files or library dependencies are added, then the configure.in, Makefile.in, Makefile.vc and related documentations should be kept up to date.\n  Every commit introducing new feature *should() be covered with corresp
 onding test case included to the GEOS set of unit tests.\n  "},{"id":13,"href":"/development/rfcs/rfc03/","title":"GEOS RFC 3 - Thread Safe CAPI ","parent":"Requests for Comment","content":"Summary The current CAPI in GEOS is not thread safe. The error handling and initialization/finalization process specifically can cause problems.\nDefinitions (As defined by Frank Warmerdam in http://trac.osgeo.org/gdal/wiki/rfc16_ogr_reentrancy)\nReentrant: A reentrant function can be called simultaneously by multiple threads provided that each invocation of the function references unique data.\nThread-safe: A thread-safe function can be called simultaneously by multiple threads when each invocation references shared data. All access to the shared data is serialized.\nObjective Allow the GEOS CAPI to be thread safe.\nImplementation In order to implement the thread safe API, the current API will be copied and all static variables will be placed into a \u0026lsquo;handle.\u0026rsquo; This handle wi
 ll be initialized on the initGeos call. Once initialized it will be passed to all subsequent GEOS functions, allowing each thread to have it\u0026rsquo;s own copy of the data. This will not affect the current API as it will be provided in addition to the old API. In order to prevent maintenance issues the OLD API will be changed to call the NEW API with a global handle. The handle (GEOSContextHandle_t) will be an opaque type to allow exentensions without recompilation being required. Function names in the new API will be updated with an _r, as is the familiar C standard for reentrant/thread safe versions. Current GEOS functions that do not make reference to the context handle will not be changed.\nThe intent will be to altogether replace the existing functions with the _r functions in a future release, making the thread safe versions the only supported functions.\nHandle Definition Here are the internals of the handle and how the application visual handle will look.\ntypedef struct 
 GEOSContextHandleInternal { const void *geomFactory; GEOSMessageHandler NOTICE_MESSAGE; GEOSMessageHandler ERROR_MESSAGE; int WKBOutputDims; int WKBByteOrder; int initialized; } GEOSConextHandleInternal_t; typedef struct GEOSContextHandle_HS *GEOSContextHandle_t; The typedef for GEOSContextHandle_t will make it easier for the compiler to help detect an incorrect pointer being passed to the functions.\nExample Prototypes Here are examples of what some of the new function prototypes would be.\nGEOSContextHandle_t GEOS_DLL initGEOS_r( GEOSMessageHandler notice_function, GEOSMessageHandler error_function); extern void GEOS_DLL finishGEOS_r(GEOSContextHandle_t handle); extern GEOSGeometry GEOS_DLL *GEOSGeom_createPoint_r(GEOSContextHandle_t handle, GEOSCoordSequence* s); extern GEOSGeometry GEOS_DLL *GEOSGeom_createLinearRing_r(GEOSContextHandle_t handle, GEOSCoordSequence* s); extern GEOSGeometry GEOS_DLL *GEOSGeom_createLineString_r(GEOSContextHandle_t handle, GEOSCoordSequence* s); Fo
 r comparison, here are the same functions as they exist now.\nextern void GEOS_DLL initGEOS(GEOSMessageHandler notice_function, GEOSMessageHandler error_function); extern void GEOS_DLL finishGEOS(void); extern GEOSGeometry GEOS_DLL *GEOSGeom_createPoint(GEOSCoordSequence* s); extern GEOSGeometry GEOS_DLL *GEOSGeom_createLinearRing(GEOSCoordSequence* s); extern GEOSGeometry GEOS_DLL *GEOSGeom_createLineString(GEOSCoordSequence* s); Limitations This change will focus on making a thread safe version of the API. Other extensions to the context handle have been suggested, e.g. Access to other geometry factories, overriding memory allocators. These extensions are beyond the current scope of this design, but this design will be implemented to allow such extensions in the future.\nTesting An example test executable will be provided that shows the current problem. It is copied from the existing CAPI test tool. Once the thread safe API is created the test tool will be updated to the new inter
 face which will address the former problems.\n"},{"id":14,"href":"/development/rfcs/rfc04/","title":"GEOS RFC 4 - Code Formatting Style","parent":"Requests for Comment","content":"This document proposes and describes desired code formatting style used across C/C++ source code in GEOS.\n         RFC 4 Code Formatting Style   Author Mateusz Łoskot   Contact mateusz at loskot.net   Status Dropped (no agreement)    Summary The document proposes and describes desired default code formatting style guidelines for GEOS programming in C and C++ languages.\nThe goal of this document is to initiate process to reach an agreement for the default code formatting style.\nMotivation There is a need to decide on format of GEOS source code and apply such globally consistent format to GEOS C/C++ codebase.\nA uniform, codebase-wide formatting style makes reading and comprehending existing code easier, writing code focused on important aspects of new developments and more pleasant, removes burden during a
  patch or pull request code reviews and prevents bikeshedding religious arguments. Even in small projects, contributing developers discover the problems of working without an agreed upon code format.\nThe utility of such guidelines has been proven by many open source software projects.\nThe scope of the proposal is specifically limited to formatting style guidelines. It is not an intention to develop a general coding guide covering other aspects of writing software like naming, etc.\nProposal It is important to make effortless for developers to produce properly formatted code.\nThe proposal suggests to use clang-format version 3.8 or higher to define C++ code formatting rules for GEOS code.\nThe clang-format is a tool to automatically format C/C++ code, so that developers don\u0026rsquo;t need to worry about style issues. Unlike other tools which use own parsers, clang-format uses the Clang tokenizer and supports the same C++ source code as the Clang compiler. This guarantees correc
 t output is produced and offers unique features (eg. wrapping long lines whether of code, strings, arrays - something which AStyle has no way of doing).\nThe style settings are defined in .clang-format configuration file for our style settings.\nThe clang-format is straightforward to run and can support development workflow as standalone tool or as one of many editor integrations or other bespoke utilities (eg. git cl format [Chromium]).\nNo automation of code reformatting is proposed. It would be treating the symptomps, no cause: developers not following the code formatting standard.\nAlthough no means to enforce the default formatting style are proposed, currently used CI services (eg. Travis CI) may be employed as a post-commit safety valve - a clang-format lint failure as a compile break (eg. clang_format.py build script used by MongoDB). Alternatively, a gatekeeper may be installed in SVN/Git, rejecting commits with code not conforming to the code formatting style.\nCode Format
 ting Rules What code formatting rules to use?\n \u0026ldquo;A mature engineers know that a standard is more important than which standard.\u0026rdquo; ~ MongoDB\n clang-format offers several defaults (eg. LLVM, Mozilla, Linux, Google C++ Style).\nThe proposal recommends to use one of the base styles, if necessary, fine-tuning as an easier way to get started than deciding on each option one by one.\nThe reasons are two-fold:\n make GEOS code unified with the wide spectrum of well-established C/C++ projects long arguments and religious wars prevention.  .clang-format Below is complete set of settings suggested, sufficient to maintain the clean code formatting style.\nNOTE: It remains open for refinements, use different BasedOnStyle as base style, etc.\n--- BasedOnStyle: Mozilla Language: Cpp Standard: Cpp03 ColumnLimit: 80 IndentWidth: 4 TabWidth: 4 UseTab: Never BraceWrapping: AfterClass: true AfterControlStatement: true AfterEnum: true AfterFunction: true AfterNamespace: true AfterO
 bjCDeclaration: true AfterStruct: true AfterUnion: true BeforeCatch: true BeforeElse: true IndentBraces: false BreakBeforeBinaryOperators: None BreakBeforeBraces: Allman BreakBeforeTernaryOperators: true For brevity, the settings above are limited to the base style and points of customizations.\nFor actual implementation, full version of .clang-format should be generated using clang-format -dump-config option and the BasedOnStyle: Mozilla setting commented with #.\n.editorconfig [http://editorconfig.org/ EditorConfig] is currently in use and .editorconfig file is provided to automatically tell popular code editors about the basic style settings like indentation, whitespaces and end-of-line markers for distinguished types of plain text files.\nThe .editorconfig file will have to be updated to match the chosen .clang-format settings.\nEOL clang-format does not enforce line endings.\nThe EOL marker is considered to be [http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20130930/09
 0200.html a part of a file encoding decision] and not part of any coding style.\nThe EOL marker can be enforced as project-wide setting controlled with .gitattributes and .editorconfig.\nHowever, it shall still be left as configurable setting in developer\u0026rsquo;s environment of choice (eg. git config) independently from the project-wide setting.\nBig Reformat What to do about the existing code?\nThe proposal recommends to just do one big reformat of the codebase.\nWhile it may seem causing clutter in the repository log (eg. svn blame), if it occurs infrequently (eg. yearly) and is applied to the entire codebase at that time, it should not be very disruptive to the source code history. One way to cope with skewed history is to use git blame -w which ignores whitespace when comparing commits.\nPartial application of the code formatting rules would create more work without delivering the full benefit [MongoDB] leading to codebase with different styles mixed.\nImplementation Branch
 es to run the big reformat in are:\n trunk branches/3.6 branches/3.5 branches/3.4  After Big Reformat How to work against the natural entropy in a codebase:\n It is highly recommended to use clang-format integration while writing a code. Format changed code before committing or opening pull requests. If you have to commit change in code formatting, do it in separate commit. Avoid commits with a mixture of code and formatting changes.  There is downside of history clutter in repository, but this proposal states that a codebase with different styles across is even worse.     \u0026ldquo;After all, every moment of time wasted on code formatting or discussion thereof is eliminated.\u0026rdquo; ~ MongoDB\n Implementation Set up Travis CI \u0026ldquo;style safety valve\u0026rdquo; build dedicated to run clang-format lint based on the approach used in ​clang_format.py script by MongoDB.\nMiscellaneous Those who build GEOS with GCC 6+ may appreciate consistent code format style as it will
  help to avoid some dozens of the new compiler warnings:\nsrc/geom/Polygon.cpp: In member function ‘virtual int geos::geom::Polygon::getCoordinateDimension() const’: src/geom/Polygon.cpp:154:5: warning: this ‘if’ clause does not guard... [-Wmisleading-indentation] if( shell != NULL ) ^~ src/geom/Polygon.cpp:157:2: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the ‘if’ size_t nholes=holes-\u0026gt;size(); ^~~~~~ References  MongoDB Succeeding With ClangFormat:  https://engineering.mongodb.com/post/succeeding-with-clangformat-part-1-pitfalls-and-planning/ https://engineering.mongodb.com/post/succeeding-with-clangformat-part-2-the-big-reformat/ https://engineering.mongodb.com/post/succeeding-with-clangformat-part-3-persisting-the-change/   Chromium Using clang-format on Chromium C++ Code https://clangformat.com - clang-format interactive guide and builder https://zed0.co.uk/clang-format-configurator/  "},{"id":15,"href":"/developmen
 t/rfcs/rfc05/","title":"GEOS RFC 5 - C++11 Compilation Mode","parent":"Requests for Comment","content":"This document proposes and describes desired code formatting style used across C/C++ source code in GEOS.\n         RFC 5 C++11 Compilation Mode   Author Mateusz Łoskot   Contact mateusz at loskot.net   Status Accepted (no agreement)    Summary The document proposes to switch to C++11 compilation mode as default throughout the whole C++ source code of GEOS.\nThe goal of the document is to request and achieve agreement on using C++11 as the minimum required version of the C++ programming language standard.\nMotivation The C++11 is the first major update of the C++ standard since 1998. (C++03 was a bug fix release.)\nThe C++11 features aim to promote writing clean, compact, type-safe and fast code. It also delivers better feature-wise compatibility with C language (C99).\nThe Wikipedia article at https://en.wikipedia.org/wiki/C++11 does a great job describing all changes in C++11 exte
 nsively.\nThe std::auto_ptr smart pointer, together with a bunch of other features, has been deprecated and will be removed from C++17.\nThe new compilers provide better diagnostics.\nEnabling C++11 compilation mode will improve the programming environment making it much friendlier than C++98.\nA social factor: since (many) C++ programmers no longer enjoy C++98, allowing C++11 mode may increase potential for new contributions.\nCompilers Landscape Summary of compilers supported by GEOS with their minimal versions required to compile source code based on [http://en.cppreference.com/w/cpp/compiler_support C++11 features].\nC++11    Compiler Version Status Support     GCC 4.8.1+ C++11 status Debian 8 (stable), Ubuntu 15.04+, Ubuntu 14.04 ppa:ubuntu-toolchain-r/test, Fedora 19+, RHEL7   Clang 3.3+ C++11 status Debian 8 (stable), Ubuntu 14.04+, Fedora 19+, CentOS 6(?)   MSVC 12.0+ (2013) C++11 status n/a    C++14 The C++14 compilers are listed for comparison only:\n   Compiler Version   
   GCC 4.9+   Clang 3.4+   MSVC 14.0+ (2015)    Plan This proposal only requests agreement for the C++11 compilation mode switch in the current trunk branch only.\nIf accepted, currently available build configurations (Autotools, CMake, NMake) will be updated to switch the compilation mode to C++11.\nThis proposal does not suggest any detailed roadmap of big refactoring of the GEOS C++ codebase.\nThe GEOS codebase is around 150 KLOC and given the available man-power to LOCs ratio, such one-step refactoring would not be feasible.\nInstead, the task will be tackled with the baby step approach gradually transforming the codebase according to priorities set along the way. Any disruptive refactoring, changes in interfaces of C++ classes, breaking changes in C++ API must be announced and discussed on the mailing list or the bug tracker.\nIMPORTANT: C++11 refactoring must not change the C API or break C API compatibility, unless agreed upon based on prior RFC proposed.\nHowever, if the prop
 osal is accepted, any new C++ code written for GEOS can be C++11-compliant.\nPrior acceptance of this proposal is necessary in order to start any source code refactoring using C++11 features.\nOnce accepted, first step will be to update the build configurations to require C++11-compliant compiler.\nIssues This section outlines issues potentially caused by upgrade to C++11 language.\n C++11 destructors, by default, have now the new exception specification of nothrow(true). Destructors of GEOS classes should be reviewed and any that are allowed/expected to throw exceptions must be marked with nothrow(false). Otherwise, any user of the existing GEOS codebase would find the program terminating whenever GEOS destructor throws an exception. Such review would be beneficial anyway.  Release First release of GEOS with C++11 compiler requirement could be 3.7.0 or, perhaps, 4.0.0.\nC++14 This section clarifies status of C++14 support in GEOS.\n Once C++11 is adopted as default compilation mode
 , GEOS developers and maintainers must ensure it also successfully compiles in C++14 and C++17 modes. Are contributors allowed to add ifdef\u0026rsquo;s for C++14 and C++17? No. Is there a plan to upgrade to C++14 or C++17 to allow use of the C++ latest features? No, there is no plan. It is, however, recognized, such motion may be put to the vote around 2020.  References  C++ compiler support  "},{"id":16,"href":"/development/rfcs/rfc06/","title":"GEOS RFC 6 - Require explicit configure to use the C++ API","parent":"Requests for Comment","content":"         RFC 9 Require explicit configure to use the C++ API   Author Regina Obe   Contact lr at pcorp.us   Status Not Passed    Past discussions Trac ticket to deprecate another request to deprecate and osm2pgsql mess more examples about how apps linking directly to GEOS C++ causing problems for other applications Pointing out removing ability to use GEOS C++ reduces users freedoms\nSummary This document proposes to change the ./configure a
 nd CMake to by default only allow use of the C-API.\nThe C++ API headers and library will only be installed if explicitly asked for as detailed in https://lists.osgeo.org/pipermail/geos-devel/2017-October/008054.html\nAny developers who want to use the C++ API will have to build with\n#autoconf users ./configure --with-cplusplus-sdk-install #cmake users cmake -DINSTALL_CPLUSPLUS_SDK If cplusplus sdk install is not expressly requested only the C headers will be included and the C++ headers will not be installed. In addition, when the C++ headers are used by any project, if users choose to build with the cplusplus-sdk, a warning will be shown before start of compile stating:\n The GEOS project does not guarantee ABI stability of the C++ API during minor updates. This means your code may need recompilation or changes to upgrade to next minor version of GEOS. If you want ABI stability from minor version to minor version, you should use the C-API instead.\n In addition the GEOS C++API He
 aders Geometry.h will by default include a warning as noted in https://git.osgeo.org/gogs/geos/geos/pulls/14 as proposed in https://lists.osgeo.org/pipermail/geos-devel/2017-October/008071.html\n The GEOS C++ API is unstable, please use the C API instead HINT: #include geos_c.h\n Which will show during compile time if the following variable is not defined\n WE_ACKNOWLEDGE_THAT_THE_GEOS_CPLUSPLUS_API_IS_UNSTABLE\n This message will continue to be shown in every project that a user tries to compile using GEOS C++ API headers.\nI propose doing this in GEOS 3.7.0.\nThe main purpose is to discourage the use of the C++ API because we do not have the manpower to guarantee ABI or API compatiblity from minor version to minor version and thus using it in an environment where the GEOS library is shared across many software is unsupported. We are also planning significant refactoring in GEOS 3.8 which will very likely break the C++ API.\nCurrently osm2pgsql and OSSIM are the only ones that used
  the GEOS C++ API and largely distributed in shared environment. We want to discourage future projects that plan to be used in a shared environment from using the GEOS C++ API and to stick with the GEOS C API.\nSo the purpose of the above is to affect the following change:\n Package Distributions do not need compile with these flags, though they may choose to at their own risk to support C++ API users. The end effect being, no C++ headers installed and just the C header file installed. People building their own binaries or their own projects that utilize the C++ API may not be able to build using a packaged libgeosdev-++ if packagers don\u0026rsquo;t compile with c++ support. If a package distributtion does choose to offer the headers and take the default of not defining the WE_\u0026hellip; users building with the package will get the above warning at compile time of their project.  That way new projects will be clear about what compromise they are making using the C++ API and if t
 hey are not users will ask\n What is this warning I keep on getting about you using an unstable API?\n "},{"id":17,"href":"/development/rfcs/rfc07/","title":"GEOS RFC 7 - Use CMake for Build System","parent":"Requests for Comment","content":"         RFC 7 Use CMake for build system   Author Daniel Baston   Contact dbaston at gmail.com   Status Accepted, January 15, 2021    This document proposes to use CMake as the build system for GEOS and discontinue use of autotools and NMake.\nSince version 3.5, we have officially supported building GEOS with CMake: https://trac.osgeo.org/geos/wiki/BuildingOnUnixWithCMake\nGEOS is also required to build with autotools and NMake.\nSupporting three build systems:\n Decreases ease of contribution, because any change must be tested against all three build systems. This results in more developer effort devoted to the build system rather than the library itself (see for example, commit history of this PR: https://github.com/libgeos/geos/pull/125) Increa
 ses the risk that differences between build systems cause the library to be compiled with different behavior, or with different version information (for example, see https://trac.osgeo.org/geos/ticket/882) Increases the length of the commit-testing feedback cycle, since multiple build systems must be tested before giving a pull request a \u0026ldquo;green light\u0026rdquo; and insufficient workers are available to test all build systems in parallel.  This RFC proposes that CMake be used as the exclusive build system because:\n It is used by the majority of active committers It is the only cross-platform (OS/compiler) build system  "},{"id":18,"href":"/development/rfcs/rfc08/","title":"GEOS RFC 8 - Improve Coordinate Sequence API (WIP)","parent":"Requests for Comment","content":"         RFC 8 Improve Coordinate Sequence API   Author Martin Davis   Contact martin.davis at crunchydata.com   Status In Discussion    This document proposes to modify the Coordinate Sequence API to improve pe
 rformance and adaptiveness.\nThese improvements are (likely to be) breaking changes to the C++ API.\nThese may require extensions to the C API to be externally available, but should not result in breaking the current C API.\nBackground The Coordinate Sequence API as it stands imposes a large cost on clients.\n It requires copying coordinate list structures one or more times It imposes the cost of a Z ordinate even if not required by the client (related) It is necessary to construct a full Geometry object just to pass a simple Point (e.g. for Point0In-Polygon) (related) Geometry objects for Point and Multi Point are very memory inefficient due to Point overhead  The API also has some functional limitations:\n does not support M values  Downstream projects which are feeling pain:\n PDAL - had to use custom Point-In-Polygon because of overhead in passing points to GEOS Shapely - there are several allocations required to marshall from NumPY to GEOS PostGIS - hopefully this will allow ca
 lling GEOS without copying out of LWGEOM structure  Goals   Allow using external coordinate list structures with no copying (except as needed by GEOS algorithms, e.g. removing repeated points)\n  Prevent mutating of external coordinate structures\n  Support XY, XYM, XYZ, XYZM\n Coord Seq will need to know dimension of coordinates    Support efficient input of Point data\n  Optimized storage of Point and Multi Point data\n  Ideas Memory-based Coordinate Sequence implementation\n Class which contains pointer to memory block of coordinates, length, dimension Coordinate Sequence becomes a slimmed-down interface with accessors Will still provide setters, but use const to prevent unwanted modification How will coordinates be accessed?  By copying into stack-allocated object? This would allow using a Coordinate with XYZM By getX, getY and optional getZ, getM? This requires rewriting some GEOS code to avoid copying coordinates    Templates\n problem: would templates pervade entire code base
 ? does not allow dynamic adapting to external structures?  Prior Art\n C++ string_view  Tasks  Remove extraneous operations from CoordinateSequence (e.g. removeRepeatedPoints) Create a MemoryBasedCoordinateSequence (better name?) which allows access to external blocks of memory Review how Coordinates are accessed - is there a better way? Review how this can provide XYZM capability?  "},{"id":19,"href":"/development/rfcs/rfc09/","title":"GEOS RFC 9 - Restore the C++ API (WIP)","parent":"Requests for Comment","content":"         RFC 9 Restore the C++ API   Author Mateusz Łoskot   Contact mateusz at loskot.net   Status [https://lists.osgeo.org/pipermail/geos-devel/2019-May/008972.html Proposed]    The GEOS library is a C++ library offering two kinds of public API: C++ API and C API.\nThe GEOS library started as a C++ library. The C API was introduced in version 2.2.\nThe GEOS library has never promised any stability of the C++ API and this fact has always been documented and clearly stat
 ed:\non the wiki:\n C++ API (will likely change across versions) C API (provides long-term ABI stability)\n on the front page of the API reference:\n The recommended low-level interface to the GEOS library is the simplified C wrapper interface. This will ensure stability of the API and the ABI of the library during performance improvements that will likely change classes definitions.\nIf you don\u0026rsquo;t care about adapting/rebuilding your client code you can still use the C++ interface.\n in the NEWS file:\n Changes in 2.2.0\n NEW Simplified and stabler C API   The GEOS library as always been deployed as two distinct binaries:\n geos accompanied with the C++ headers. geos_c accompanied with the C header.  Removing the C++ API from the public scope and asking developers to opt-in to use the C++ API,fundamentally breaks the original concept of the library.\nIf there are developers surprised by any breaking changes in the C++ API, it means they have not read the documentation and 
 it is not role of the GEOS developers to make them read it.\nAny user of the GEOS C++ API is expected to be aware of its volatile state and be prepared to update in order to use any newer version of GEOS. These implicit usage terms of the contract, which have always been clear and consistent with nearly any other C++ API, remain unchanged.\nConsidering these issues, there is very little value in the #ifdef USE_UNSTABLE_GEOS_CPP_API and related guards.\nLet\u0026rsquo;s revert the implementation of the RFC6.\n"},{"id":20,"href":"/usage/","title":"Usage","parent":"GEOS","content":""},{"id":21,"href":"/specifications/geojson/","title":"GeoJSON","parent":"Geometry Formats","content":"content\n"},{"id":22,"href":"/specifications/wkb/","title":"Well-Known Binary (WKB)","parent":"Geometry Formats","content":"content\n"},{"id":23,"href":"/specifications/wkt/","title":"Well-Known Text (WKT)","parent":"Geometry Formats","content":"content\n"},{"id":24,"href":"/","title":"GEOS","parent":"","co
 ntent":"GEOS is a C/C++ library for spatial computational geometry of the sort generally used by \u0026ldquo;geographic information systems\u0026rdquo; software. GEOS is a core dependency of PostGIS, QGIS, GDAL, and Shapely.\nCapabilities Spatial Model and Functions\n Geometries: Point, LineString, Polygon, MultiPoint, MultiLineString, MultiPolygon, GeometryCollection Predicates: Intersects, Touches, Disjoint, Crosses, Within, Contains, Overlaps, Equals, Covers Operations: Union, Distance, Intersection, Symmetric Difference, Convex Hull, Envelope, Buffer, Simplify, Polygon Assembly, Valid, Area, Length, Prepared geometries (pre-spatially indexed) STR spatial index OGC Well Known Text (WKT) and Well Known Binary (WKB) encoders and decoders.  API Features  C API (provides long-term API and ABI stability) C++ API (will likely change across versions) Thread safety (using the reentrant API)  License GEOS is open source software available under the terms of GNU Lesser General Public Licen
 se (LGPL).\n"},{"id":25,"href":"/usage/download/","title":"Download Source","parent":"Usage","content":"   Release Date Release Download Link     2021/11/02 3.10.1 geos-3.10.1.tar.bz2   2021/11/01 3.9.2 geos-3.9.2.tar.bz2   2021/04/10 3.8.2 geos-3.8.2.tar.bz2   2019/10/04 3.7.3 geos-3.7.3.tar.bz2   2020/12/11 3.6.5 geos-3.6.5.tar.bz2   2019/10/04 3.5.2 geos-3.5.2.tar.bz2    Build From Source Build Requirements  CMake 3.13 or later. C++11 compiler. We regularly test GCC, Clang and Microsoft Visual C++. Doxygen to build the API documentation.  Build Builds with CMake are done \u0026ldquo;outside the tree\u0026rdquo; either in a build directory in the source tree or next to the tree.\n# Unpack and setup build directory tar xvfz geos-3.10.1.tar.bz2 cd geos-3.10.1 mkdir _build cd _build # Set up the build cmake \\  -DCMAKE_BUILD_TYPE=Release \\  -DCMAKE_INSTALL_PREFIX=/usr/local \\  .. # Run the build, test, install steps make ctest make install Build Options The GEOS build can be custom
 ized using build options.\n   Option Default Note     CMAKE_BUILD_TYPE Release Use Debug to build with debug flags and optimizations off. Use Release for packaging and production installs. Use RelWithDebInfo for optimized build with debug symbols.   CMAKE_INSTALL_PREFIX /usr/local Set to install root. Librarys end up in ./libs headers in ./include   BUILD_DOCUMENTATION ON Attempt to find doxygen executable and build API docs   BUILD_SHARED_LIBS ON Build dynamically linkable libraries.   DISABLE_GEOS_INLINE OFF Turn off inlining. This is bad for performance, only do this if you cannot build to pass tests on your platform with inlining on.    Test Options It is possible to run ctest directly. This gives access to ctest command line options (see ctest \u0026ndash;help for a listing).\nctest ctest --verbose A list of GEOS test suites is obtained by running ctest --show-only:\n$ ctest --show-only # # Test project /home/dan/dev/libgeos/cmake-build-debug # Test #1: test_geos_unit # Test #2
 : test_xmltester # Test #3: test_bug234 # Test #4: test_sweep_line_speed A subset of test suites can be run using a regular expression (and in this case, running 4 jobs in parallel):\n$ ctest --tests-regex test_ --parallel 4 "},{"id":26,"href":"/usage/install/","title":"Install Packages","parent":"Usage","content":"Red Hat There is a GEOS package in the EPEL (Extra Packages for Enterprise Linux) repository.\n# Add the EPEL repository yum -y install epel-release # Install the GEOS runtime and development packages rpm -Uvh geos geos-devel Ubuntu The Ubuntu GIS project maintains a collection of repositories with builds of common open source geospatial projects, including GEOS.\n# Add the Ubuntu GIS PPA sudo apt-get install python-software-properties sudo add-apt-repository ppa:ubuntugis/ppa # Install the packages sudo apt-get install geos Debian The Debian GIS project maintains GEOS packages and pushes them into the appropriate Debian respositories.\nsudo apt-get install geos Amazon Li
 nux Amazon Linux is based on RH7, and can read from the EPEL repository. To enable using Amazon tools, use the amazon-linux-extras utility.\nsudo yum install -y amazon-linux-extras sudo amazon-linux-extras enable epel sudo yum search geos sudo yum install geos geos-devel Homebrew For MacOS, GEOS can be installed using the Homebrew package repository, which downloads source packages and builds them in place using a recipe to ensure all packages integrate with each other nicely.\nFirst install Homebrew. Then:\nbrew install geos Macports For MacOS, GEOS can be installed using the MacPorts package repository, which downloads source packages and builds them in place using a recipe to ensure all packages integrate with each other nicely.\nFirst install MacPorts. Then:\nport install geos "},{"id":27,"href":"/categories/","title":"Categories","parent":"GEOS","content":""},{"id":28,"href":"/tags/","title":"Tags","parent":"GEOS","content":""}]
\ No newline at end of file
diff --git a/index.xml b/index.xml
index a492b892d..33cb7ac35 100644
--- a/index.xml
+++ b/index.xml
@@ -209,7 +209,7 @@ The GEOS library has never promised any stability of the C++ API and this fact h
       <pubDate>Mon, 04 Oct 2021 13:44:59 -0700</pubDate>
       
       <guid>http://libgeos.org/usage/download/</guid>
-      <description>Release Date Release Download Link     2021/10/21 3.10.0 geos-3.10.0.tar.bz2   2020/12/10 3.9.1 geos-3.9.1.tar.bz2   2020/03/10 3.8.1 geos-3.8.1.tar.bz2   2019/10/04 3.7.3 geos-3.7.3.tar.bz2   2020/12/11 3.6.5 geos-3.6.5.tar.bz2   2019/10/04 3.5.2 geos-3.5.2.tar.bz2    Build From Source Build Requirements  CMake 3.13 or later. C++11 compiler. We regularly test GCC, Clang and Microsoft Visual C++. Doxygen to build the API documentation.  Build Builds with CMake are done &ldquo;outside the tree&rdquo; either in a build directory in the source tree or next to the tree.</description>
+      <description>Release Date Release Download Link     2021/11/02 3.10.1 geos-3.10.1.tar.bz2   2021/11/01 3.9.2 geos-3.9.2.tar.bz2   2021/04/10 3.8.2 geos-3.8.2.tar.bz2   2019/10/04 3.7.3 geos-3.7.3.tar.bz2   2020/12/11 3.6.5 geos-3.6.5.tar.bz2   2019/10/04 3.5.2 geos-3.5.2.tar.bz2    Build From Source Build Requirements  CMake 3.13 or later. C++11 compiler. We regularly test GCC, Clang and Microsoft Visual C++. Doxygen to build the API documentation.  Build Builds with CMake are done &ldquo;outside the tree&rdquo; either in a build directory in the source tree or next to the tree.</description>
     </item>
     
     <item>
diff --git a/usage/download/index.html b/usage/download/index.html
index 8e929478f..e03b12337 100644
--- a/usage/download/index.html
+++ b/usage/download/index.html
@@ -614,19 +614,19 @@
 </thead>
 <tbody>
 <tr>
-<td>2021/10/21</td>
-<td><strong>3.10.0</strong></td>
-<td><a href="http://download.osgeo.org/geos/geos-3.10.0.tar.bz2">geos-3.10.0.tar.bz2</a></td>
+<td>2021/11/02</td>
+<td><strong>3.10.1</strong></td>
+<td><a href="http://download.osgeo.org/geos/geos-3.10.1.tar.bz2">geos-3.10.1.tar.bz2</a></td>
 </tr>
 <tr>
-<td>2020/12/10</td>
-<td><strong>3.9.1</strong></td>
-<td><a href="http://download.osgeo.org/geos/geos-3.9.1.tar.bz2">geos-3.9.1.tar.bz2</a></td>
+<td>2021/11/01</td>
+<td><strong>3.9.2</strong></td>
+<td><a href="http://download.osgeo.org/geos/geos-3.9.2.tar.bz2">geos-3.9.2.tar.bz2</a></td>
 </tr>
 <tr>
-<td>2020/03/10</td>
-<td><strong>3.8.1</strong></td>
-<td><a href="http://download.osgeo.org/geos/geos-3.8.1.tar.bz2">geos-3.8.1.tar.bz2</a></td>
+<td>2021/04/10</td>
+<td><strong>3.8.2</strong></td>
+<td><a href="http://download.osgeo.org/geos/geos-3.8.2.tar.bz2">geos-3.8.2.tar.bz2</a></td>
 </tr>
 <tr>
 <td>2019/10/04</td>
@@ -655,8 +655,8 @@
 <div class="gdoc-page__anchorwrap"><h3 id="build">Build<a data-clipboard-text="http://libgeos.org/usage/download/#build" class="gdoc-page__anchor gdoc-page__anchor--right clip" aria-label="Anchor Build" href="#build"><svg class="icon link"><use xlink:href="#link"></use></svg></a></h3></div>
 <p>Builds with CMake are done “outside the tree” either in a build directory in the source tree or next to the tree.</p>
 <div class="highlight"><pre tabindex="0" class="chroma"><code class="language-bash" data-lang="bash"><span class="c1"># Unpack and setup build directory</span>
-tar xvfz geos-3.10.0.tar.bz2
-<span class="nb">cd</span> geos-3.10.0
+tar xvfz geos-3.10.1.tar.bz2
+<span class="nb">cd</span> geos-3.10.1
 mkdir _build
 <span class="nb">cd</span> _build
 <span class="c1"># Set up the build</span>
diff --git a/usage/index.xml b/usage/index.xml
index 0e6eca488..15f313e72 100644
--- a/usage/index.xml
+++ b/usage/index.xml
@@ -43,7 +43,7 @@ Using the C++ API means giving up:</description>
       <pubDate>Mon, 04 Oct 2021 13:44:59 -0700</pubDate>
       
       <guid>http://libgeos.org/usage/download/</guid>
-      <description>Release Date Release Download Link     2021/10/21 3.10.0 geos-3.10.0.tar.bz2   2020/12/10 3.9.1 geos-3.9.1.tar.bz2   2020/03/10 3.8.1 geos-3.8.1.tar.bz2   2019/10/04 3.7.3 geos-3.7.3.tar.bz2   2020/12/11 3.6.5 geos-3.6.5.tar.bz2   2019/10/04 3.5.2 geos-3.5.2.tar.bz2    Build From Source Build Requirements  CMake 3.13 or later. C++11 compiler. We regularly test GCC, Clang and Microsoft Visual C++. Doxygen to build the API documentation.  Build Builds with CMake are done &ldquo;outside the tree&rdquo; either in a build directory in the source tree or next to the tree.</description>
+      <description>Release Date Release Download Link     2021/11/02 3.10.1 geos-3.10.1.tar.bz2   2021/11/01 3.9.2 geos-3.9.2.tar.bz2   2021/04/10 3.8.2 geos-3.8.2.tar.bz2   2019/10/04 3.7.3 geos-3.7.3.tar.bz2   2020/12/11 3.6.5 geos-3.6.5.tar.bz2   2019/10/04 3.5.2 geos-3.5.2.tar.bz2    Build From Source Build Requirements  CMake 3.13 or later. C++11 compiler. We regularly test GCC, Clang and Microsoft Visual C++. Doxygen to build the API documentation.  Build Builds with CMake are done &ldquo;outside the tree&rdquo; either in a build directory in the source tree or next to the tree.</description>
     </item>
     
     <item>

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

Summary of changes:
 en.search-data.min.json   |  2 +-
 index.xml                 |  2 +-
 usage/download/index.html | 22 +++++++++++-----------
 usage/index.xml           |  2 +-
 4 files changed, 14 insertions(+), 14 deletions(-)


hooks/post-receive
-- 
GEOS