From 3025f19b79ea97aa760ff0ec07b1376fedde3b86 Mon Sep 17 00:00:00 2001
From: pramsey <pramsey+github@cleverelephant.ca>
Date: Tue, 13 Aug 2024 17:36:02 +0000
Subject: [PATCH] =?UTF-8?q?Deploying=20to=20gh-pages=20from=20@=20libgeos/?=
 =?UTF-8?q?geos@dfdaa76ba241c74e46046e12a7237bba1ded4b0e=20=F0=9F=9A=80?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 index.xml                            |  3 +--
 posts/2024-08-13-relateng/index.html | 12 ++++--------
 posts/index.html                     |  3 +--
 posts/index.xml                      |  3 +--
 search/en.data.min.json              |  2 +-
 5 files changed, 8 insertions(+), 15 deletions(-)

diff --git a/index.xml b/index.xml
index 4a9610c232..ab293e7e99 100644
--- a/index.xml
+++ b/index.xml
@@ -135,8 +135,7 @@ Go      gogeos  Haskell      geos hgeos  Javascript      node-geos  Julia      L
       <pubDate>Tue, 13 Aug 2024 00:00:00 +0000</pubDate>
       
       <guid>https://libgeos.org/posts/2024-08-13-relateng/</guid>
-      <description>The upcoming 3.13 release of GEOS includes a complete re-write of the &amp;ldquo;boolean predicates&amp;rdquo;, called &amp;ldquo;RelateNG&amp;rdquo;. The boolean predicates are pairwise tests for geometries that return true/false answers. &amp;ldquo;Intersects&amp;rdquo;, &amp;ldquo;Contains&amp;rdquo;, &amp;ldquo;Touches&amp;rdquo; are all examples of boolean predicates.
-The old implementation in JTS and GEOS operated by building a complete topological relationship graph between the two inputs, then reading the result off the graph. However, computing the whole graph every time is computationally expensive, and the results of many predicates can be determined without a full graph &amp;ndash; the first time you hit an edge intersection, you know that geometries intersect, and you do not need to do any more calculations.</description>
+      <description>&lt;p&gt;The upcoming 3.13 release of GEOS includes a complete re-write of the &amp;ldquo;boolean predicates&amp;rdquo;, called &amp;ldquo;RelateNG&amp;rdquo;. The boolean predicates are pairwise tests for geometries that return true/false answers.  &amp;ldquo;Intersects&amp;rdquo;, &amp;ldquo;Contains&amp;rdquo;, &amp;ldquo;Touches&amp;rdquo; are all examples of boolean predicates.&lt;/p&gt;</description>
     </item>
     
     <item>
diff --git a/posts/2024-08-13-relateng/index.html b/posts/2024-08-13-relateng/index.html
index f5d94ab931..dd29b47272 100644
--- a/posts/2024-08-13-relateng/index.html
+++ b/posts/2024-08-13-relateng/index.html
@@ -12,8 +12,7 @@
 <meta name="generator" content="Hugo 0.88.1" />
 
 
-  <meta name="description" content="The upcoming 3.13 release of GEOS includes a complete re-write of the &ldquo;boolean predicates&rdquo;, called &ldquo;RelateNG&rdquo;. The boolean predicates are pairwise tests for geometries that return true/false answers. &ldquo;Intersects&rdquo;, &ldquo;Contains&rdquo;, &ldquo;Touches&rdquo; are all examples of boolean predicates.
-The old implementation in JTS and GEOS operated by building a complete topological relationship graph between the two inputs, then reading the result off the graph. However, computing the whole graph every time is computationally expensive, and the results of many predicates can be determined without a full graph &ndash; the first time you hit an edge intersection, you know that geometries intersect, and you do not need to do any more calculations." />
+  <meta name="description" content="The upcoming 3.13 release of GEOS includes a complete re-write of the &ldquo;boolean predicates&rdquo;, called &ldquo;RelateNG&rdquo;. The boolean predicates are pairwise tests for geometries that return true/false answers. &ldquo;Intersects&rdquo;, &ldquo;Contains&rdquo;, &ldquo;Touches&rdquo; are all examples of boolean predicates." />
 
     <title>RelateNG | GEOS</title>
 
@@ -39,8 +38,7 @@
     content="RelateNG"
   />
   <meta property="og:site_name" content="GEOS" />
-  <meta property="og:description" content="The upcoming 3.13 release of GEOS includes a complete re-write of the “boolean predicates”, called “RelateNG”. The boolean predicates are pairwise tests for geometries that return true/false answers. “Intersects”, “Contains”, “Touches” are all examples of boolean predicates.
-The old implementation in JTS and GEOS operated by building a complete topological relationship graph between the two inputs, then reading the result off the graph. However, computing the whole graph every time is computationally expensive, and the results of many predicates can be determined without a full graph – the first time you hit an edge intersection, you know that geometries intersect, and you do not need to do any more calculations." />
+  <meta property="og:description" content="The upcoming 3.13 release of GEOS includes a complete re-write of the “boolean predicates”, called “RelateNG”. The boolean predicates are pairwise tests for geometries that return true/false answers. “Intersects”, “Contains”, “Touches” are all examples of boolean predicates." />
 <meta property="og:type" content="article" />
 <meta property="og:url" content="https://libgeos.org/posts/2024-08-13-relateng/" />
 
@@ -57,8 +55,7 @@
 
   <meta name="twitter:card" content="summary" />
 <meta name="twitter:title" content="RelateNG" />
-  <meta name="twitter:description" content="The upcoming 3.13 release of GEOS includes a complete re-write of the “boolean predicates”, called “RelateNG”. The boolean predicates are pairwise tests for geometries that return true/false answers. “Intersects”, “Contains”, “Touches” are all examples of boolean predicates.
-The old implementation in JTS and GEOS operated by building a complete topological relationship graph between the two inputs, then reading the result off the graph. However, computing the whole graph every time is computationally expensive, and the results of many predicates can be determined without a full graph – the first time you hit an edge intersection, you know that geometries intersect, and you do not need to do any more calculations." />
+  <meta name="twitter:description" content="The upcoming 3.13 release of GEOS includes a complete re-write of the “boolean predicates”, called “RelateNG”. The boolean predicates are pairwise tests for geometries that return true/false answers. “Intersects”, “Contains”, “Touches” are all examples of boolean predicates." />
 
 
   <script type="application/ld+json">
@@ -69,7 +66,7 @@
       "name": "RelateNG",
       "url" : "https://libgeos.org/posts/2024-08-13-relateng/",
       "headline": "RelateNG",
-      "description": "The upcoming 3.13 release of GEOS includes a complete re-write of the “boolean predicates”, called “RelateNG”. The boolean predicates are pairwise tests for geometries that return true\/false answers. “Intersects”, “Contains”, “Touches” are all examples of boolean predicates.\nThe old implementation in JTS and GEOS operated by building a complete topological relationship graph between the two inputs, then reading the result off the graph. However, computing the whole graph every time is computationally expensive, and the results of many predicates can be determined without a full graph – the first time you hit an edge intersection, you know that geometries intersect, and you do not need to do any more calculations.",
+      "description": "The upcoming 3.13 release of GEOS includes a complete re-write of the “boolean predicates”, called “RelateNG”. The boolean predicates are pairwise tests for geometries that return true\/false answers. “Intersects”, “Contains”, “Touches” are all examples of boolean predicates.",
       "wordCount" : "442",
       "inLanguage": "en",
       "isFamilyFriendly": "true",
@@ -1458,7 +1455,6 @@ <h1 class="gdoc-post__title">RelateNG</h1>
   class="gdoc-markdown__link"
   href="https://lin-ear-th-inking.blogspot.com/2024/05/relateng-performance.html"
 >implementation is faster</a> and just as correct. The existing prepared geometry implementation is still faster, for the cases it supports, but for all the unsupported cases RelateNG now provides faster default implentations.</p>
-
     </section>
   </article>
 
diff --git a/posts/index.html b/posts/index.html
index 112894efe3..acbdfc2178 100644
--- a/posts/index.html
+++ b/posts/index.html
@@ -1362,8 +1362,7 @@ <h1 class="gdoc-post__title">
         </h1>
       </header>
       <section>
-        The upcoming 3.13 release of GEOS includes a complete re-write of the &ldquo;boolean predicates&rdquo;, called &ldquo;RelateNG&rdquo;. The boolean predicates are pairwise tests for geometries that return true/false answers. &ldquo;Intersects&rdquo;, &ldquo;Contains&rdquo;, &ldquo;Touches&rdquo; are all examples of boolean predicates.
-The old implementation in JTS and GEOS operated by building a complete topological relationship graph between the two inputs, then reading the result off the graph. However, computing the whole graph every time is computationally expensive, and the results of many predicates can be determined without a full graph &ndash; the first time you hit an edge intersection, you know that geometries intersect, and you do not need to do any more calculations.
+        <p>The upcoming 3.13 release of GEOS includes a complete re-write of the &ldquo;boolean predicates&rdquo;, called &ldquo;RelateNG&rdquo;. The boolean predicates are pairwise tests for geometries that return true/false answers.  &ldquo;Intersects&rdquo;, &ldquo;Contains&rdquo;, &ldquo;Touches&rdquo; are all examples of boolean predicates.</p>
       </section>
       <div class="gdoc-post__readmore">
         
diff --git a/posts/index.xml b/posts/index.xml
index 2bf0241477..a2d8b94d5d 100644
--- a/posts/index.xml
+++ b/posts/index.xml
@@ -13,8 +13,7 @@
       <pubDate>Tue, 13 Aug 2024 00:00:00 +0000</pubDate>
       
       <guid>https://libgeos.org/posts/2024-08-13-relateng/</guid>
-      <description>The upcoming 3.13 release of GEOS includes a complete re-write of the &amp;ldquo;boolean predicates&amp;rdquo;, called &amp;ldquo;RelateNG&amp;rdquo;. The boolean predicates are pairwise tests for geometries that return true/false answers. &amp;ldquo;Intersects&amp;rdquo;, &amp;ldquo;Contains&amp;rdquo;, &amp;ldquo;Touches&amp;rdquo; are all examples of boolean predicates.
-The old implementation in JTS and GEOS operated by building a complete topological relationship graph between the two inputs, then reading the result off the graph. However, computing the whole graph every time is computationally expensive, and the results of many predicates can be determined without a full graph &amp;ndash; the first time you hit an edge intersection, you know that geometries intersect, and you do not need to do any more calculations.</description>
+      <description>&lt;p&gt;The upcoming 3.13 release of GEOS includes a complete re-write of the &amp;ldquo;boolean predicates&amp;rdquo;, called &amp;ldquo;RelateNG&amp;rdquo;. The boolean predicates are pairwise tests for geometries that return true/false answers.  &amp;ldquo;Intersects&amp;rdquo;, &amp;ldquo;Contains&amp;rdquo;, &amp;ldquo;Touches&amp;rdquo; are all examples of boolean predicates.&lt;/p&gt;</description>
     </item>
     
     <item>
diff --git a/search/en.data.min.json b/search/en.data.min.json
index 6b0540ade5..081245b0f6 100644
--- a/search/en.data.min.json
+++ b/search/en.data.min.json
@@ -1 +1 @@
-[{"id":0,"href":"/project/","title":"Project","parent":"GEOS","content":"","description":""},{"id":1,"href":"/project/development/","title":"Development","parent":"Project","content":"Resources      git repository: https://github.com/libgeos/geos geos-devel mailing list and archive #geos chat channels:  Matrix: https://matrix.to/#/#geos:osgeo.org IRC: irc://irc.libera.chat/#osgeo-geos (https://kiwiirc.com/nextclient/irc.libera.chat/#osgeo-geos) Slack: https://osgeo.slack.com/messages/C07RKJ06B/    Bug Reporting     Defects should be reported using GitHub Issues.\nWhen submitting bugs caused by particular geometries, you must submit the geometries that cause the failure, preferably in hex-encoded WKB, so that we can re-produce the failure cases.\nContributing     To contribute fixes to outstanding issues, enhancements, and other smaller changes, open a pull request with your change and a fullsome description of what you are trying to achieve.\nIf you have any doubts as to whether your work, or planned work, is not a \u0026ldquo;smaller\u0026rdquo; change, please join the geos-devel mailing list and describe your plans. Join the list! It is a great way to get acquainted with what the development community is working on.\n","description":"Resources      git repository: https://github.com/libgeos/geos geos-devel mailing list and archive #geos chat channels:  Matrix: https://matrix.to/#/#geos:osgeo.org IRC: irc://irc.libera.chat/#osgeo-geos (https://kiwiirc.com/nextclient/irc.libera.chat/#osgeo-geos) Slack: https://osgeo.slack.com/messages/C07RKJ06B/    Bug Reporting     Defects should be reported using GitHub Issues.\nWhen submitting bugs caused by particular geometries, you must submit the geometries that cause the failure, preferably in hex-encoded WKB, so that we can re-produce the failure cases.\nContributing     To contribute fixes to outstanding issues, enhancements, and other smaller changes, open a pull request with your change and a fullsome description of what you are trying to achieve."},{"id":2,"href":"/project/rfcs/rfc11/","title":"GEOS RFC 11 - GEOS Version and EOL Policy","parent":"Requests for Comment","content":"         RFC 11 End-of-Life (EOL) Policy   Author Regina Obe   Contact lr@pcorp.us   Status Accepted, September 20, 2022    This document describes the GEOS project policy for versioning and EOLing GEOS minor versions.\nVersioning     The GEOS project generally produces a new minor version every 1-2 years. Minor versions typically contain new features, as well as bug fixes and performance improvements. Minor versions have version numbers in the form major.minor (e.g. 3.9, 3.10, 3.11, etc).\nEach minor version has a named git branch (e.g. branch 3.11). The first release of a minor version has a micro version of x.x.0 and is git tagged. For example, the first release of version 3.11 was 3.11.0 and has git tag 3.11.0.\nPatch Policy     On an as-needed basis, each supported minor version will have additional micro releases (e.g. 3.10.1,3.10.2). These subsequent micro releases may have bug fixes, performance improvements, and security fixes but will not include new features. They are patch releases for the parent minor version. Micro releases are git tagged with the version number (e.g. tag 3.10.1).\n The newer the minor version, the more likely performance improvements will be added. Performance improvements that could destabilize a release (e.g. requiring too much code) or change behavior will generally not be applied. Bug fixes that are not trivial changes of code or major security or crash issues, will likely not be applied to older versions. The latest stable release (meaning the minor release with highest number that is not the main branch) will have all bug fixes and enhancements which are not new features.  End-of-Life Policy     Minor versions marked EOL will not have further releases. We may apply fixes to a minor branch if an entity is willing to fund such an effort, but the change will not be tagged.\nThe policy for making a minor version EOL is:\n If the first release of the minor version is more than 3-5 years old, it may become EOL.  When a minor version is EOL, it will either be removed from Downloads or will have an EOL marker showing it is the last release for the minor version.\n","description":"RFC 11 End-of-Life (EOL) Policy   Author Regina Obe   Contact lr@pcorp.us   Status Accepted, September 20, 2022    This document describes the GEOS project policy for versioning and EOLing GEOS minor versions.\nVersioning     The GEOS project generally produces a new minor version every 1-2 years. Minor versions typically contain new features, as well as bug fixes and performance improvements."},{"id":3,"href":"/project/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@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 projects 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  ","description":"RFC 10 Move Project to GitHub   Author Paul Ramsey   Contact pramsey@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:"},{"id":4,"href":"/project/development/tests/","title":"Testing","parent":"Development","content":"Testing executables are in bin\n See also the ctest documentation.  Unit Tests     The GEOS unit tests are written using the TUT framework. There are tests for both the C++ code and the C API. The test source files are in the test/unit directory. The test group names are in the group declaration in each XXXTest.cpp file. By convention the test group name is based on the test file path and name.\nThe entire set of unit tests is run by calling the test_geos_unit executable:\n$ bin/test_geos_unit # Run all tests The unit tests groups can be listed:\n$ bin/test_geos_unit --list # List all test groups Individual unit test groups can be run by calling test_geos_unit with the test group name:\n$ bin/test_geos_unit capi::GEOSBuffer # Run a single group of tests Individual tests within a test group can be run by specifying the group name and test number:\n$ bin/test_geos_unit capi::GEOSBuffer 1 XML Tests     The XML test suite is a set of portable, declarative tests which can be run in both GEOS and JTS. They are located in tests/xmltester/tests. XML tests can be run using test_xmltester:\nbin/test_xmltester ../tests/xmltester/tests/robust/overlay/TestOverlay-geos-837.xml The XML Tester provides the following options:\nUsage: bin/test_xmltester [options] \u0026lt;test\u0026gt; [\u0026lt;test\u0026gt; ...] Options: -v Verbose mode (multiple -v increment verbosity) --test-valid-output Test output validity --test-valid-input Test input validity --sql-output Produce SQL output --wkb-output Print Geometries as HEXWKB Performance Tests     There are performance tests which are not built or run as part of the standard test suite. Building this is enabled by the cmake -DBUILD_BENCHMARKS=ON flag. The various tests can be run from the command line, e.g.:\n$ bin/perf_iterated_buffer Memory Usage testing     In some cases bugs are caused by improper memory access after deallocation (heap-use-after-free). This may be able to be detected and reported by using the Address Sanitizer compiler capability. Enable this via cmake -DCMAKE_BUILD_TYPE=ASAN.\n","description":"Testing executables are in bin\n See also the ctest documentation.  Unit Tests     The GEOS unit tests are written using the TUT framework. There are tests for both the C++ code and the C API. The test source files are in the test/unit directory. The test group names are in the group declaration in each XXXTest.cpp file. By convention the test group name is based on the test file path and name."},{"id":5,"href":"/usage/","title":"Usage","parent":"GEOS","content":"","description":""},{"id":6,"href":"/project/coc/","title":"Code of Conduct","parent":"Project","content":"Introduction     This code of conduct governs how we behave in any GEOS forum or event and whenever we will be judged by our actions. We expect it to be honored by everyone who participates in the GEOS community formally or informally, or claims any affiliation with the GEOS project.\nIt applies to in-person events (such as conferences and related social events), IRC, public and private mailing lists, the issue tracker, the wiki, blogs, Twitter, and any other forums which the community uses for communication and interactions.\nThis code is not exhaustive or complete. It serves to distill our common understanding of a collaborative, shared environment and goals. We expect it to be followed in spirit as much as in the letter, so that it can enrich all of us and the technical communities in which we participate.\nDiversity Statement     GEOS welcomes and encourages participation by everyone. We are committed to being a community that everyone feels good about joining, and we will always work to treat everyone well. No matter how you identify yourself or how others perceive you: we welcome you.\nSpecific Guidelines     We strive to:\n  Be open.\nWe invite anyone to participate in our community. We preferably use public methods of communication for project-related messages, unless discussing something sensitive. This applies to messages for help or project-related support, too; not only is a public support request much more likely to result in an answer to a question, it also makes sure that any inadvertent mistakes made by people answering will be more easily detected and corrected.\n  Be empathetic, welcoming, friendly, and patient.\nWe work together to resolve conflict, assume good intentions, and do our best to act in an empathetic fashion. We may all experience some frustration from time to time, but we do not allow frustration to turn into a personal attack. A community where people feel uncomfortable or threatened is not a productive one. Note that we have a multi-cultural, multi-lingual community and some of us are non-native speakers. We should be respectful when dealing with other community members as well as with people outside our community.\n  Be collaborative.\nOur work will be used by other people, and in turn we will depend on the work of others. When we make something for the benefit of GEOS, we are willing to explain to others how it works, so that they can build on the work to make it even better. Any decision we make will affect users and colleagues, and we take those consequences seriously when making decisions.\n  Be inquisitive.\nNobody knows everything! Asking questions early avoids many problems later, so questions are encouraged, though they may be directed to the appropriate forum. Those who are asked should be responsive and helpful, within the context of our shared goal of improving GEOS.\n  Be careful in the words that we choose.\nWhether we are participating as professionals or volunteers, we value professionalism in all interactions, and take responsibility for our own speech. Be kind to others. Do not insult or put down other participants.\n  Be concise\nKeep in mind that what you write once will be read by hundreds of persons. Writing a short email means people can understand the conversation as efficiently as possible. Short emails should always strive to be empathetic, welcoming, friendly and patient. When a long explanation is necessary, consider adding a summary.\nTry to bring new ideas to a conversation so that each mail adds something unique to the thread, keeping in mind that the rest of the thread still contains the other messages with arguments that have already been made.\nTry to stay on topic, especially in discussions that are already fairly large.\n  Step down considerately.\nMembers of every project come and go. When somebody leaves or disengages from the project they should tell people they are leaving and take the proper steps to ensure that others can pick up where they left off. In doing so, they should remain respectful of those who continue to participate in the project and should not misrepresent the project’s goals or achievements. Likewise, community members should respect any individual’s choice to leave the project.\n  Anti-Harassment     Harassment and other exclusionary behaviour are not acceptable. This includes, but is not limited to:\n Personal insults or discriminatory jokes and language, especially those using racist or sexist terms. Offensive comments, excessive or unnecessary profanity. Intimidation, violent threats or demands. Sustained disruption of sessions or events. Stalking, harassing photography or recording. Unwelcome physical contact or sexual attention. Repeated harassment of others. In general, if someone asks you to stop, then stop. Posting (or threatening to post) other people’s personally identifying information (“doxing”). Sharing private content, such as emails sent privately or non-publicly, or unlogged forums such as IRC channel history. Advocating for, or encouraging, any of the above behaviour.  Reporting Guidelines     If you believe someone is breaking this code of conduct, you may reply to them, and point to this code of conduct. Such messages may be in public or in private, whatever is most appropriate. Assume good faith; it is more likely that participants are unaware of their bad behaviour than that they intentionally try to degrade the quality of the discussion.\nShould there be difficulties in dealing with the situation, you may report your concerns to event staff, a forum leader or the GEOS PSC. Serious or persistent offenders may be expelled from the event or forum by event organizers or forum leaders.\nTo privately email the code of conduct committee leadership use conduct-report@osgeo.org.\nCredits     GEOS re-uses the OSGeo Code of Conduct\n","description":"Introduction     This code of conduct governs how we behave in any GEOS forum or event and whenever we will be judged by our actions. We expect it to be honored by everyone who participates in the GEOS community formally or informally, or claims any affiliation with the GEOS project.\nIt applies to in-person events (such as conferences and related social events), IRC, public and private mailing lists, the issue tracker, the wiki, blogs, Twitter, and any other forums which the community uses for communication and interactions."},{"id":7,"href":"/project/psc/","title":"Project Steering Committee","parent":"Project","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.\nThis PSC list is valid as of February 18th, 2022.\n Dan Baston Howard Butler Martin Davis Regina Obe Paul Ramsey (chair) Sandro Santilli  The PSC approves major changes and RFC documents. Other work is always ongoing, by the PSC and by the other core contributors, listed below:\n Even Rouault Vicky Vergara Kurt Schwehr Mike Taves  Historical core contributors:\n Mateusz Loskot Charlie Savage Norman Vine Sean Gillies Frank Warmerdam Ben Jubb Chuck Thibert Stephen Wong  ","description":"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.\nThis PSC list is valid as of February 18th, 2022.\n Dan Baston Howard Butler Martin Davis Regina Obe Paul Ramsey (chair) Sandro Santilli  The PSC approves major changes and RFC documents."},{"id":8,"href":"/project/rfcs/","title":"Requests for Comment","parent":"Project","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      GEOS RFC 11 - GEOS Version and EOL Policy      ","description":"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      GEOS RFC 11 - GEOS Version and EOL Policy      "},{"id":9,"href":"/usage/doxygen/","title":"API 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  See also:\n C API tutorial C++ API tutorial.  Code examples are available in the code repository.\n","description":"The Doxygen documentation is the most up-to-date reference for the C and C++ API of GEOS.\n C API C++ API  See also:\n C API tutorial C++ API tutorial.  Code examples are available in the code repository."},{"id":10,"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 several 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 memory management. If you create a GEOS object with a GEOS function, you must free it using the appropriate GEOS destructor.  The C API is 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 to 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     GEOS functions provide reentrant variants, indicated by an _r suffix. The reentrant functions work the same as their regular counterparts, but they have an extra parameter, a GEOSContextHandle_t.\nThe GEOSContextHandle_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, call GEOS_init_r() instead of initGEOS() 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.\nIn this example the overall structure of the code is identical, but the reentrant variants are used, and the preamble and cleanup are slightly different.\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_create_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; } Object Model     The GEOSCoordSequence and GEOSGeometry objects are at the heart of the GEOS object model.\nGEOSCoordSequence     GEOSCoordSequence is an ordered list of coordinates. Coordinates are 2 (XY) or 3 (XYZ) dimensional.\nThere are a number of ways to make a GEOSCoordSequence. You can create a GEOSCoordSequence by creating a blank one and then setting the 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 initialize it 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 initialize it from a coordinate buffer (an array of double in coordinate order, eg: XYXYXY).\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 fundamental structure of the GEOS C API is GEOSGeometry. GEOSGeometry is a generic type that 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. When GEOSGeometry values have been created they must be deallocated 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 createEmpty functions take no arguments and return geometries that are \u0026ldquo;empty\u0026rdquo;. Empty geometries represent a (typed) empty set of space. For example, the intersection of two disjoint polygons is a \u0026ldquo;empty polygon\u0026rdquo;.\nThe GEOSGeom_createPoint(), GEOSGeom_createLinearRing() and GEOSGeom_createLineString() functions accept a single GEOSCoordSequence and take ownership of that sequence, so freeing the geometry with GEOSGeom_destroy() frees all the allocated memory.\ndouble coordBuf[] = {1.0,3.0, 2.0,2.0, 3.0,1.0}; size_t seqSize = 3; GEOSCoordSequence* seq = GEOSCoordSeq_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, /* geometry array */ npoints); /* frees collection and contained points */ GEOSGeom_destroy(collection); /* frees the containing array */ free(points); Readers and Writers     The examples above build GEOSCoordSequences 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; only needed before GEOS 3.12 */ GEOSWKTWriter_setTrim(writer, 1); char* wkt_out = GEOSWKTWriter_write(writer, geom); /* Clean up everything we allocated */ GEOSWKTReader_destroy(reader); GEOSGeom_destroy(geom); /* Use GEOSFree() 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 up-front work to create an optimized object, you reap a performance benefit when executing repeated function calls on that object.\nPrepared geometries contain internal indexes that make calls to the \u0026ldquo;spatial predicate\u0026rdquo; functions 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     The STRTree index allows you to create, populate, and query a spatial index. Like most spatial indexes, the STRTree is based on indexing rectangles. For a complete example using a reader and writer, see capi_strtree.c.\nWhen you build an index, you will usually insert an \u0026ldquo;item\u0026rdquo; \u0026ndash; some kind of struct that you are interested in indexing \u0026ndash; and an associated bounds for that item, in the form of a GEOSGeometry. The geometry does not need to be rectangular, a rectangular bounding box will be automatically calculated for the geometry.\nOnce you have built an STRTree, you have two basic ways to query:\n Find the nearest item to a query geometry, using GEOSSTRtree_nearest_generic() Find all the items that intersect with a query rectangle, using GEOSSTRtree_query()  Build the tree by creating it, then inserting items.\n/* * An application will want to index items, which have * some attributes and a geometry part. */ typedef struct { GEOSGeometry* geom; size_t id; } item; /* * The tree doesn\u0026#39;t take ownership of inputs just * holds references, so we keep our point field * handy in an array */ item* items[nItems]; /* * The create parameter for the tree is not the * number of inputs, it is the number of entries * per node. 10 is a good default number to use. */ GEOSSTRtree* tree = GEOSSTRtree_create(10); for (size_t i = 0; i \u0026lt; nItems; i++) { /* Make a random point */ item* obj = random_item(range); /* Store away a reference so we can free it after */ items[i] = obj; /* Add an entry for it to the tree */ GEOSSTRtree_insert(tree, obj-\u0026gt;geom, obj); } Note that the index does not take ownership of the inserted GEOSGeometry or the item, it just stores pointers. So remember to keep a list of the items you create in order to free them at the end of your process.\nOnce the tree is built, you can query it.\nThe generic nearest-neighbor query uses a callback to check the actual distance between the search item and the indexed item. In this way it can filter through the many candidate nearest nodes in the index to find the actual nearest node.\n/* * Item distance callback for GEOSSTRtree_nearest_generic() */ int itemDistanceCallback(const void* item1, const void* item2, double* distance, void* userdata) { item_t* obj1 = (item_t*)item1; item_t* obj2 = (item_t*)item2; return GEOSDistance(obj1-\u0026gt;geom, obj2-\u0026gt;geom, distance); } The query call requires the tree, the item driving the search (so it can be fed into the callback), the geometry driving the search (because the library doesn\u0026rsquo;t know how to extract the geometry from the item a priori), the callback, and whatever extra information want sent into the callback.\n/* Random item to query the index with */ item_t* item_random = random_item(range); /* Nearest item in the index to our random item */ const item_t* item_nearest = GEOSSTRtree_nearest_generic( tree, // STRTree to query  item_random, // Item to use in search  item_random-\u0026gt;geom, // Geometry to seed search  itemDistanceCallback, // Callback to process nearest object  NULL); // Userdata to hand to the callback The query by rectangle function also uses a callback, which could be used to exactly test for a spatial relationship (intersects, contains, etc), for all the index nodes that meet the rough \u0026ldquo;bounds interact\u0026rdquo; filter the index applies.\n/* * Item query callback for GEOSSTRtree_query() */ void itemQueryCallback(void* item, void* userdata) { double x, y; item_t* i = (item_t*)item; GEOSGeomGetX(i-\u0026gt;geom, \u0026amp;x); GEOSGeomGetY(i-\u0026gt;geom, \u0026amp;y); printf(\u0026#34;Found item %10zu at (%g, %g)\\n\u0026#34;, i-\u0026gt;id, x, y); } This example just prints out every candidate that passes the index filter.\n/* Set up a query rectangle for index query */ const char* wkt_bounds = \u0026#34;POLYGON((20 20, 22 20, 22 22, 20 22, 20 20))\u0026#34;; GEOSGeometry* geom_query = GEOSWKTReader_read(reader, wkt_bounds); /* Find all items that touch the bounds */ /* For non-rectangular query geometry, this will be an over-determined set */ GEOSSTRtree_query( tree, // STRTree to query  geom_query, // GEOSGeometry query bounds  itemQueryCallback, // Callback to process index entries that pass query  NULL); // Userdata to hand to the callback The query itself just uses the tree, the query bounds geometry, the callback, and optional user data. You could use the user data to pass in an array to write results out to, or a prepared geometry to use for exact tests.\n","description":"Most programs using GEOS use the C API, rather than building against the C++ headers. The C API offers several 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:"},{"id":11,"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.\nYou can explore the C++ model via the Doxygen reference.\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 complexity of the GEOS symbol space means that binary symbols are known to 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 to 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); /* Only needed before GEOS 3.12 */ 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; } ","description":"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.\nYou can explore the C++ model via the Doxygen reference."},{"id":12,"href":"/project/development/ci_status/","title":"CI Status","parent":"Development","content":"   CI main 3.12 3.11 3.10 3.9 3.8     GitHub         GitLab         Debbie         Winnie         Dronie         Bessie         Bessie32         Berrie         Berrie64          Runners      GitHub - Ubuntu various, Windows various, CMake GitLab - Debian 8.2, GNU/Linux 64bit, GCC, automake Debbie - Debian sid (bullseye), GNU/Linux 64bit, GCC Debian 10.2.1, cmake (3.18.4) \u0026gt;= 3.9, autotools \u0026lt; 3.8 Winnie - Windows Mingw64, 32bit GCC 8.1.0, 64bit GCC 8.1.0, MSys CMake (3.21.3), 64-bit GCC 12.1 (cmake 3.23.2 ninja) Dronie - Alpine Linux 3.14 (alpine.latest), 64bit, GCC 10.3.1, CMake (3.20.3) , automake \u0026lt; 3.10 Bessie - FreeBSD 12.2, 64-bit clang 10.0.1, CMake (3.19.6) \u0026gt;=3.8, autotools \u0026lt; 3.8 Bessie32 - FreeBSD 12.2, 32-bit clang 10.0.1, 64bit gcc 10.3.0, CMake (3.21.3) \u0026gt;=3.8, autotools \u0026lt; 3.8 Berrie - Raspberry Pi (debian bullseye), 32-bit gcc 10.2.1, CMake (3.18.4) Berrie64 - Raspberry Pi (debian bullseye), 64-bit gcc 10.2.1, CMake (3.18.4)  ","description":"CI main 3.12 3.11 3.10 3.9 3.8     GitHub         GitLab         Debbie         Winnie         Dronie         Bessie         Bessie32         Berrie         Berrie64          Runners      GitHub - Ubuntu various, Windows various, CMake GitLab - Debian 8."},{"id":13,"href":"/specifications/","title":"Geometry Formats","parent":"GEOS","content":"GEOS can read and write common formats for the interchange of simple features geometry.\n   GeoJSON      Well-Known Binary (WKB)      Well-Known Text (WKT)      ","description":"GEOS can read and write common formats for the interchange of simple features geometry.\n   GeoJSON      Well-Known Binary (WKB)      Well-Known Text (WKT)      "},{"id":14,"href":"/posts/","title":"News","parent":"GEOS","content":"","description":""},{"id":15,"href":"/usage/tools/","title":"Tools","parent":"Usage","content":" GeosOp  Usage   JTS TestBuilder    GeosOp     geosop is a CLI (command-line interface) for GEOS. It can be used to:\n Run GEOS operations on one or many geometries Output geometry resuls in various formats (WKT and WKB) Convert between WKT and WKB Time the performance of operations Check for memory leaks in operations Check the semantics of GEOS operations  For more information see the README.\nUsage     The geosop executable is in bin.\n Print usage instructions bin/geosop  Print usage instructions and list of available operations bin/geosop --help  Read a file of geometries in WKT and output them as WKB bin/geosop -a geoms.wkt -f wkb  Compute the area of geometries in a WKT file and output them as text bin/geosop -a geoms.wkt --format=txt area  Compute the centroids of geometries in a WKT file and output them as WKT bin/geosop -a geoms.wkt -f wkt centroid   JTS TestBuilder     The JTS TestBuilder can be useful for creating, visualizing and processing GEOS geometry. Because GEOS and JTS are so closely related it can also be used as a way of verifying GEOS behaviour. For more information see the JTS doc.\n","description":"GeosOp  Usage   JTS TestBuilder    GeosOp     geosop is a CLI (command-line interface) for GEOS. It can be used to:\n Run GEOS operations on one or many geometries Output geometry resuls in various formats (WKT and WKB) Convert between WKT and WKB Time the performance of operations Check for memory leaks in operations Check the semantics of GEOS operations  For more information see the README."},{"id":16,"href":"/usage/bindings/","title":"Bindings","parent":"Usage","content":"GEOS can be accessed from a variety of other languages via bindings to the library.\nGo      gogeos  Haskell      geos hgeos  Javascript      node-geos  Julia      LibGEOS.jl  PHP      php-geos. GeoPHP.  Python     Python bindings are available via:\n Shapely PyGEOS Calling functions from libgeos_c via Python ctypes GeoPandas  R      sf geos  Ruby      RGeo.  Rust      geos crate  Swift      GeoSwift  Geospatial applications using GEOS include:\nDatabases      PostGIS INGRES MonetDB SpatiaLite CockroachDB DuckDB  Applications      GDAL/OGR GRASS GIS MapServer MapGuide Open Source MapWindow GIS osgEarth QGIS  ","description":"GEOS can be accessed from a variety of other languages via bindings to the library.\nGo      gogeos  Haskell      geos hgeos  Javascript      node-geos  Julia      LibGEOS.jl  PHP      php-geos. GeoPHP.  Python     Python bindings are available via:\n Shapely PyGEOS Calling functions from libgeos_c via Python ctypes GeoPandas  R      sf geos  Ruby      RGeo."},{"id":17,"href":"/usage/faq/","title":"FAQ","parent":"Usage","content":" Design and Architecture  Why is the C++ API not kept stable? Why does GEOS follow JTS design?   Spatial Model  Does GEOS support computation on the geodetic ellipsoid? Does GEOS support coordinates with measures (M)?   Robustness  Why does GEOSIntersects(GEOSIntersection(A, B), A) == false? Why doesn\u0026rsquo;t a computed point lie exactly on a line?      Design and Architecture     Why is the C++ API not kept stable?     The C++ API is very large, and may have changes in every release. It is evolving to adopt modern C++ coding practices, and often has additions and removals as GEOS spatial algorithms get enhanced. Trying to provide a stable API would involve significant effort, and slow library evolution. The C API is significantly simpler (both in design and at the binary level), so it is much easier to keep stable.\nWhy does GEOS follow JTS design?     GEOS started life as a port of JTS, so its design reflects that heritage. JTS is still evolving and improving, so keeping GEOS fairly close to the JTS design and organization makes it easier to keep porting JTS changes. However, there have been additions to GEOS which were not originally in JTS (although in some cases those were superseded by later JTS development). Also, GEOS is intended to provide high-performance spatial algorithms, which sometimes requires using different code patterns than in Java.\nSpatial Model     Does GEOS support computation on the geodetic ellipsoid?     No. GEOS assumes that geometries are defined in a Cartesian, planar, 2-dimensional space. Thus it cannot be used to compute accurate metrics, predicates or constructions on the geodetic ellipsoid which is usually used to model the surface of the Earth.\nOne way to perform geodetic computations is to project data to an appropriate planar projection using a transformation library such as PROJ. The desired geometric operations can be computed in planar space, and reprojected back to geodetic.\nDoes GEOS support coordinates with measures (M)?     No, the GEOS coordinate model only supports X,Y and Z ordinates. We hope to add support for M, and also a more efficient XY coordinate storage representation.\nRobustness     Why does GEOSIntersects(GEOSIntersection(A, B), A) == false?     GEOS represents geometry coordinates using IEEE-754 double-precision floating point numbers. This is a finite representation, whereas the implicit lines between vertices have infinite precision. In general it is highly unlikely that a coordinate computed via an arithmetic operation (such as a line intersection) is reported by an intersects test as lying exactly on the (theoretical) lines.\nFor example, the diagram below shows how the computed intersection point of two lines in general does not lie exactly on either line (scale exaggerrated for clarity):\nWhy doesn\u0026rsquo;t a computed point lie exactly on a line?     As explained in the previous question, GEOS uses finite-precision floating point arithmetic. In general coordinates computed via arithmetic operations (such as interpolation along a line) is reported by an intersects test as lying exactly on the (theoretical) line. This is due to both round-off error during calculations, and also because in the general case it is not possible to represent points along a line exactly using finite-precision numbers.\nThe diagram below shows how points interpolated along a line rarely lie exactly on the line (scale exaggerrated for clarity):\n","description":"Design and Architecture  Why is the C++ API not kept stable? Why does GEOS follow JTS design?   Spatial Model  Does GEOS support computation on the geodetic ellipsoid? Does GEOS support coordinates with measures (M)?   Robustness  Why does GEOSIntersects(GEOSIntersection(A, B), A) == false? Why doesn\u0026rsquo;t a computed point lie exactly on a line?      Design and Architecture     Why is the C++ API not kept stable?"},{"id":18,"href":"/posts/2024-08-13-relateng/","title":"RelateNG","parent":"News","content":"The upcoming 3.13 release of GEOS includes a complete re-write of the \u0026ldquo;boolean predicates\u0026rdquo;, called \u0026ldquo;RelateNG\u0026rdquo;. The boolean predicates are pairwise tests for geometries that return true/false answers. \u0026ldquo;Intersects\u0026rdquo;, \u0026ldquo;Contains\u0026rdquo;, \u0026ldquo;Touches\u0026rdquo; are all examples of boolean predicates.\nThe old implementation in JTS and GEOS operated by building a complete topological relationship graph between the two inputs, then reading the result off the graph. However, computing the whole graph every time is computationally expensive, and the results of many predicates can be determined without a full graph \u0026ndash; the first time you hit an edge intersection, you know that geometries intersect, and you do not need to do any more calculations.\nThe new implementation, RelateNG, has a number of advantages:\n Efficient short-circuited evaluation of topological predicates (including matching custom DE-9IM matrix patterns) Optimized repeated evaluation of predicates against a single geometry via * cached spatial indexes (AKA \u0026ldquo;prepared mode\u0026rdquo;) Robust computation (only point-local geometry topology is computed, so invalid topology does not cause failures) GeometryCollection inputs containing mixed types and overlapping polygons are supported, using union semantics. Zero-length LineStrings are treated as being topologically identical to Points. Support for BoundaryNodeRules.  The port to GEOS blends the new functionality with the existing implementation of PreparedGeometry and the C-API.\n All one-shot predicates are now handled by RelateNG, and should in general be faster. These are called in Geometry.cpp. The default implementation in of prepared geometry, BasicPreparedGeometry.cpp now uses the RelateNG implementations. The existing implementations in PreparedPolygon.cpp, etc, still over-ride the defaults, because they are currently slightly faster. If/when the RelateNG implementations are optimized, they can be replaced. The C-API already had functions for things like GEOSPreparedTouches() even though the \u0026ldquo;touches\u0026rdquo; predicate had no prepared implementation, and was just calling the non-optimized predicate. These functions now end up using the RelateNG prepared implementation, so they should automatically be much faster. The C-API has been expanded with two new functions, GEOSPreparedRelate() and GEOSPreparedRelatePattern(), exposing a new feature of RelateNG, the ability to do accelerated relate matrix calculations.  The RelateNG work has been run against the entire regression suite and returns exactly the same answers over all our collected 20 years of tests.\n The only exception is the handling of a zero-length LineString, which is now treated as logically equivalent to a point.  The RelateNG code is new and there are no doubt lots of places in the implementation that can still be tightened up. The existing pair-wise predicates can be considered deprecated, as the new implementation is faster and just as correct. The existing prepared geometry implementation is still faster, for the cases it supports, but for all the unsupported cases RelateNG now provides faster default implentations.\n","description":"The upcoming 3.13 release of GEOS includes a complete re-write of the \u0026ldquo;boolean predicates\u0026rdquo;, called \u0026ldquo;RelateNG\u0026rdquo;. The boolean predicates are pairwise tests for geometries that return true/false answers. \u0026ldquo;Intersects\u0026rdquo;, \u0026ldquo;Contains\u0026rdquo;, \u0026ldquo;Touches\u0026rdquo; are all examples of boolean predicates.\nThe old implementation in JTS and GEOS operated by building a complete topological relationship graph between the two inputs, then reading the result off the graph. However, computing the whole graph every time is computationally expensive, and the results of many predicates can be determined without a full graph \u0026ndash; the first time you hit an edge intersection, you know that geometries intersect, and you do not need to do any more calculations."},{"id":19,"href":"/posts/2023-11-12-geos-3-9-5-and-3-8-4-released/","title":"Version 3.9.5 and 3.8.4 EOL","parent":"News","content":"As part of a batch release of patches for stable branches, the 3.9.5 release of GEOS is now available to download. In addition this release cycle includes the final release of GEOS 3.8 series, GEOS 3.8.4. If you haven\u0026rsquo;t already upgraded to a newer GEOS minor version from GEOS 3.8, we highly recommend you do so.\nRelease notes for 3.8.4 and 3.9.5 are below: 3.8.4, 3.9.5,\n","description":"As part of a batch release of patches for stable branches, the 3.9.5 release of GEOS is now available to download. In addition this release cycle includes the final release of GEOS 3.8 series, GEOS 3.8.4. If you haven\u0026rsquo;t already upgraded to a newer GEOS minor version from GEOS 3.8, we highly recommend you do so.\nRelease notes for 3.8.4 and 3.9.5 are below: 3.8.4, 3.9.5,"},{"id":20,"href":"/posts/2023-11-11-geos-3-12-1-released/","title":"Version 3.12.1","parent":"News","content":"As part of a batch release of patches for stable branches, the 3.12.1 release of GEOS is now available to download.\nRelease notes for the various branches are available: 3.10.6, 3.11.3, 3.12.1\nThe 3.12.1 release is a bug fix release.\n Remove undefined behaviour in use of null PrecisionModel (GH-931, Jeff Walton) Explicitly set endianness for some tests so that output matches expected (GH-934, Paul Ramsey) Fix IncrementalDelaunayTriangulator to ensure triangulation boundary is convex (GH-953, Martin Davis) Improve scale handling for PrecisionModel (GH-956, Martin Davis) Fix PreparedLineStringDistance for lines within envelope and polygons (GH-959, Martin Davis) Fix error in CoordinateSequence::add when disallowing repeated points (GH-963, Dan Baston) Fix InteriorPointPoint to handle empty elements (GH-977, Martin Davis) Skip over testing empty distances for mixed collections. (GH-979, Paul Ramsey) Fix TopologyPreservingSimplifier endpoint handling to avoid self-intersections (GH-986, Martin Davis) Build warnings with Visual Studio (GH-929, Jeff Mckenna, Paul Ramsey) Fix CMake on Windows with Visual Studio (GH-945, Aaron Barany) ","description":"As part of a batch release of patches for stable branches, the 3.12.1 release of GEOS is now available to download.\nRelease notes for the various branches are available: 3.10.6, 3.11.3, 3.12.1\nThe 3.12.1 release is a bug fix release.\n"},{"id":21,"href":"/posts/2023-06-27-geos-3-12-released/","title":"Version 3.12.0","parent":"News","content":"The 3.12 release of GEOS is now available to download.\n  This release includes the following new features in the C API (and of course underlying changes to the C++ code to support these features):\n GEOSDisjointSubsetUnion, anptimized union algorithm for inputs that can be divided into subsets. GEOSLineSubstring, to clip a line using a start and end fractional length. GEOSEqualsIdentical, to test exact equality (with regards to order, structure, etc) of two geometries. GEOSOrientPolygons, to enforce a ring orientation on all polygonal elements in the input geometry. GEOSSTRtree_build, to force an immediate build of an STRtree. GEOSConcaveHullByLength, to build a concave hull by removing the longest outer edges of the Delaunay Triangulation of the space between the polygons, until the specified maximm edge length is reached GEOSGeomGetM, to read the M-dimensional value of a geometry. GEOSVoronoiDiagram, returns the Voronoi polygons or edges of the vertices of the given geometry. GEOSCoverageSimplifyVW, GEOSCoverageUnion, GEOSCoverageIsValid for working with \u0026ldquo;polygonal coverages\u0026rdquo;, collections of polygons that follow coverage rules (no overlaps, exact vertex equivalence on shared edges). GEOSGeom_releaseCollection, to free a collection while leaving the sub-geometries intact. GEOSMinimumRotatedRectangle, a rework of the minimum rectangle code to be faster and more correct.    GEOS has been updated to read and write \u0026ldquo;M\u0026rdquo; dimension. As with the \u0026ldquo;Z\u0026rdquo; coordinate support, not all operations can preserve the \u0026ldquo;M\u0026rdquo; dimension, but best efforts are made to retain it through calculations, input and output.\n  Much work on the core code of GEOS was carried out with a maintenance grant funded by the GDAL project and carried out by Dan Baston.\n  The full list of changes is as follows:\n  New things:\n C++14 is now required. Polygonal coverages: CoverageValidator, CoveragePolygonValidator, CoverageGapFinder, CoverageUnion (JTS-900, Martin Davis \u0026amp; Paul Ramsey) Support reading and writing M values through WKB and WKT readers/writers (GH-721, Dan Baston) Interpolate M values in overlay results (GH-802, Dan Baston) CAPI: GEOSPreparedContainsXY, GEOSPreparedIntersectsXY (GH-677, Dan Baston) Add CoordinateSequenceIterator (GH-685, Dan Baston) Geometry clustering: DBSCAN, geometry intersection/distance, envelope intersection/distance (GH-688, Dan Baston) CAPI: GEOSDisjointSubsetUnion (GH-692, Dan Baston) CAPI: GEOSLineSubstring (GH-706, Dan Baston) CAPI: GEOSEqualsIdentical (GH-810, Dan Baston) CAPI: GEOSOrientPolygons (GH-818, Dan Baston) CAPI: GEOSSTRtree_build (GH-835, Dan Baston) CAPI: GEOSConcaveHullByLength (GH-849, Martin Davis) CAPI: GEOSGeomGetM (GH-864, Mike Taves) Voronoi: Add option to create diagram in order consistent with inputs (GH-781, Dan Baston) Polygonal coverages: CoverageSimplifier (JTS-911, Martin Davis) CAPI: GEOSCoverageIsValid, GEOSCoverageSimplifyVW (GH-867, Paul Ramsey) CAPI: GEOSGeom_releaseCollection (GH-848) CAPI: GEOSMinimumRotatedRectangle now uses MinimumAreaRectangle (Paul Ramsey)    Breaking Changes\n CoverageUnion now requires valid inputs to produce valid outputs and may return invalid outputs silently when fed invalid inputs. Use CoverageValidator first if you do not know the validity of your data.    Fixes/Improvements:\n WKTReader: Fix parsing of Z and M flags in WKTReader (#676 and GH-669, Dan Baston) WKTReader: Throw exception on inconsistent geometry dimension (#1080, Dan Baston) WKTReader: Throw exception if WKT contains extra text after end of geometry (#1095, Dan Baston) GEOSIntersects: Fix crash with empty point inputs (#1110, Dan Baston) GEOSIntersects: Improve performance/robustness by using PreparedGeometry algorithm (GH-775, Dan Baston) LineMerger: Recursively collect all components from GeometryCollections (#401, Dan Baston) GeometryPrecisionReducer: Return correct dimensionality for empty results (GH-684, Dan Baston) Improve performance of coverage union (GH-681, Dan Baston) Improve performance of prepared polygon intersection (GH-690, Dan Baston) Improve performance of prepared polygon distance (GH-693, Dan Baston) Implement indexed calculations for prepared geometry isWithinDistance (GH-691, Dan Baston) Fix LineSegment.orientationIndex(LineSegment) (GH-699, Martin Davis) Fix DepthSegment comparison operation (GH-707, Martin Davis) Add OverlayNG support for simple GeometryCollection inputs (GH-716, Martin Davis) Fix TopologyPreservingSimplifier to produce stable results for Multi inputs (GH-718, Martin Davis) Improve ConvexHull radial sort robustness (GH-724, Martin Davis) Use more robust Delaunay Triangulation frame size heuristic (GH-728, Martin Davis) DiscreteFrechetDistance: Fix crash with empty inputs (GH-751, Dan Baston) GEOSSimplify / DouglasPeuckerSimplifier: Allow ring origin to be removed (GH-773, Dan Baston) GEOSTopologyPreserveSimplify / TopologyPreservingSimplifier: Allow ring origin to be removed (GH-784, Dan Baston) PreparedLineStringIntersects: Fix incorrect result with mixed-dim collection (GH-774, Dan Baston) GEOSIntersection: Fix FE_INVALID exception on intersection of disjoint geometries (GH-791, Joris Van den Bossche \u0026amp; Dan Baston) Fix incorrect result from Envelope::disjoint (GH-791, Dan Baston) Polygonizer: Fix duplicate lines return by getInvalidRingLines (GH-782, Martin Davis \u0026amp; Dan Baston) GEOSUnaryUnion: Fix crash on collection containing empty point (GH-830, Dan Baston) GEOSBuffer: Fix crash with Inf coordinates (GH-822, Dan Baston) GEOSSTRtree_iterate: Do not return removed items (GH-833, Dan Baston) IndexedFacetDistance: Fix crash with Inf coordinates (GH-821, Dan Baston) HausdorffDistance: Fix crash on collection containing empty point (GH-840, Dan Baston) MaximumInscribedCircle: Fix infinite loop with non-finite coordinates (GH-843, Dan Baston) DistanceOp: Fix crash on collection containing empty point (GH-842, Dan Baston) OffsetCurve: improve behaviour and add Joined mode (JTS-956, Martin Davis) GeometryPrecisionReducer: preserve input collection types (GH-846, Paul Ramsey) OffsetCurve: handle zero-distance offsets (GH-850, Martin Davis) Tri: add exceptions for invalid indexes (GH-853, Martin Davis) LargestEmptyCircle: enhance boundary to allow any polygonal geometry (GH-859, Martin Davis) Fix MaximumInscribedCircle and LargestEmptyCircle performance and memory issues (GH-883, Martin Davis) GEOSHasZ: Fix handling with empty geometries (GH-887, Mike Taves) OffsetCurve: fix EndCap parameter handling (GH-899, Martin Davis) Reduce artifacts in single-sided Buffers: (GH-665 #810 and #712, Sandro Santilli) GeoJSONReader: Fix 2D empty geometry creation (GH-909, Mike Taves) GEOSClipByRect: Fix case with POINT EMPTY (GH-913, Mike Taves) Support mixed GeometryCollection in overlay ops (GH-797, Paul Ramsey)    Changes:\n Remove Orientation.isCCW exception to simplify logic and align with JTS (GH-878, Martin Davis) Change MultiPoint WKT to use parentheses in sub-members (GH-903, Mike Taves) Change WKBWriter default output dimension to 4 (GH-908, Mike Taves) Change WKTWriter defaults output dimension to 4 and trim to \u0026lsquo;on\u0026rsquo; (GH-915, Mike Taves)   ","description":"The 3.12 release of GEOS is now available to download.\n  This release includes the following new features in the C API (and of course underlying changes to the C++ code to support these features):\n GEOSDisjointSubsetUnion, anptimized union algorithm for inputs that can be divided into subsets. GEOSLineSubstring, to clip a line using a start and end fractional length. GEOSEqualsIdentical, to test exact equality (with regards to order, structure, etc) of two geometries. GEOSOrientPolygons, to enforce a ring orientation on all polygonal elements in the input geometry. GEOSSTRtree_build, to force an immediate build of an STRtree. GEOSConcaveHullByLength, to build a concave hull by removing the longest outer edges of the Delaunay Triangulation of the space between the polygons, until the specified maximm edge length is reached GEOSGeomGetM, to read the M-dimensional value of a geometry. GEOSVoronoiDiagram, returns the Voronoi polygons or edges of the vertices of the given geometry. GEOSCoverageSimplifyVW, GEOSCoverageUnion, GEOSCoverageIsValid for working with \u0026ldquo;polygonal coverages\u0026rdquo;, collections of polygons that follow coverage rules (no overlaps, exact vertex equivalence on shared edges). GEOSGeom_releaseCollection, to free a collection while leaving the sub-geometries intact. GEOSMinimumRotatedRectangle, a rework of the minimum rectangle code to be faster and more correct.    GEOS has been updated to read and write \u0026ldquo;M\u0026rdquo; dimension. As with the \u0026ldquo;Z\u0026rdquo; coordinate support, not all operations can preserve the \u0026ldquo;M\u0026rdquo; dimension, but best efforts are made to retain it through calculations, input and output.\n  Much work on the core code of GEOS was carried out with a maintenance grant funded by the GDAL project and carried out by Dan Baston.\n "},{"id":22,"href":"/posts/2023-03-16-geos-3-11-2-released/","title":"Version 3.11.2","parent":"News","content":"As part of a batch release of patches for stable branches, the 3.11.2 release of GEOS is now available to download.\nRelease notes for the various branches are available: 3.10.5, and 3.11.2\nThe 3.11.2 release is a bug fix release.\n GEOSIntersection: Fix FE_INVALID exception on intersection of disjoint geometries (GH-791, Joris Van den Bossche \u0026amp; Dan Baston) Fix incorrect result from Envelope::disjoint (GH-791, Dan Baston) Fix handling of odd cases in PolygonHoleJoiner (JTS-946, Paul Ramsey, Martin Davis) Support gcc-13 (GH-743, Sergei Trofimovich) Disallow Inf envelopes in Quadtree, avoid inf loop (Paul Ramsey) GEOSUnaryUnion: Fix crash on collection containing empty point (GH-830, Dan Baston) GEOSSTRtree_iterate: Do not return removed items (GH-833, Dan Baston) IndexedFacetDistance: Fix crash with Inf coordinates (GH-821, Dan Baston) HausdorffDistance: Fix crash on collection containing empty point (GH-840, Dan Baston) MaximumInscribedCircle: Fix infinite loop with non-finite coordinates (GH-843, Dan Baston) DistanceOp: Fix crash on collection containing empty point (GH-842, Dan Baston) Guard against non-finite distances in Buffer/OffsetCurve (GH-661, Paul Ramsey) ","description":"As part of a batch release of patches for stable branches, the 3.11.2 release of GEOS is now available to download.\nRelease notes for the various branches are available: 3.10.5, and 3.11.2\nThe 3.11.2 release is a bug fix release.\n"},{"id":23,"href":"/posts/2022-11-14-geos-3-11-1-released/","title":"Version 3.11.1","parent":"News","content":"As part of a batch release of patches for stable branches, the 3.11.1 release of GEOS is now available to download.\nRelease notes for the various branches are available: 3.9.4, 3.10.4, and 3.11.1\nThe 3.11.1 release is a bug fix release.\n Remove spurious version from \u0026ndash;libs geos-config options Fix PreparedGeometry to avoid crashes with EMPTY elements in input (GH-678, Martin Davis) Fix LineSegment.orientationIndex(LineSegment) (GH-699, Martin Davis) Fix DepthSegment comparison operation (GH-707, Martin Davis) Add OverlayNG support for simple GeometryCollection inputs (GH-716, Martin Davis) Fix TopologyPreservingSimplifier to produce stable results for Multi inputs (GH-718) Fix WKB hex endian test (GH-720, Paul Ramsey) Improve ConvexHull radial sort robustness (GH-724, Martin Davis) Use more robust Delaunay Triangulation frame size heuristic (GH-728, Martin Davis) Fix crash in GEOSIntersects with empty point inputs (GH-673, Dan Baston) Fix RelateOp for empty geometry and closed linear geometry (TRAC-1096, Dan Baston) Return 2D result on 2D input to GeometryPrecisionReducer (TRAC-1137, Dan Baston) ","description":"As part of a batch release of patches for stable branches, the 3.11.1 release of GEOS is now available to download.\nRelease notes for the various branches are available: 3.9.4, 3.10.4, and 3.11.1\nThe 3.11.1 release is a bug fix release.\n"},{"id":24,"href":"/posts/2022-07-01-geos-3-11-0-released/","title":"Version 3.11.0","parent":"News","content":"The 3.11.0 release of GEOS is now available to download.\nThis release includes new features for building \u0026ldquo;concave hulls\u0026rdquo; for both point and polygon input. For polygon input, the hull will be guaranteed to not cross into the interiors of the input polygons.\nThe line merger has been enhanced to support a mode that only merges lines which share orientation.\nThe offset curve algorithm has been updated to be more reliable for different kinds of semi-degenerate inputs, and may output different curves than the previous implementation, for those kinds of inputs. For \u0026ldquo;normal\u0026rdquo; inputs, the results should look very much like the old implementation.\nAs usual, numerous bugs have been fixed, and a few performance improvements discovered and implemented.\nNew Things      OffsetCurve (GH-530, Paul Ramsey/Martin Davis) ConcaveHull (GH-549, Paul Ramsey/Martin Davis) PolygonHull (GH-603, Paul Ramsey/Martin Davis) LineMerger directed option (GH-597, Sergei Sh) CAPI: GEOSHilbertCode (GH-556, Brendan Ward) CAPI: GEOSGeom_createRectangle (GH-558, Brendan Ward) CAPI: GEOSGeom_transformXY (GH-563, Dan Baston/Brendan Ward) CAPI: GEOSRemoveRepeatedPoints (GH-599, Paul Ramsey) CAPI: GEOSLineMergeDirected (GH-597, Sergei Sh) CAPI: setFixStructure for WKB/WKT readers to automatically repair structural errors in the input (GH-639, Paul Ramsey)  Fixes \u0026amp; Improvements      Fix unaryUnion to avoid segfault with empty polygon (GH-501, Mike Taves) Fix SnapRoundingNoder to use tolerance in noding; also fixes GeometryPrecisionReducer (GH-504, Sergei Sh) Allow direct setting of grid size (GH-513, Martin Davis) Allow GEOS to be used as a CMake subproject (GH-518, Robert Coup) Remove .inl inline files in favour of header declaration (GH-543, Paul Ramsey) Add SnappingNoder seeding (Martin Davis) Add OverlayNG area check heuristic (JTS-812, Paul Ramsey) Fix RelateOp (and intersects predicate) for lines with intersections very near boundary (GH-570, Martin Davis) Fix IsValidOp to handle repeated node points (JTS-845, Martin Davis) Fix IsSimpleOp to handle closed LineStrings with repeated endpoints (JTS-851, Martin Davis) Fix LengthIndexedLine (via LengthLocationMap fix) (JTS-859, Martin Davis) Fix PolygonHoleJoiner (JTS-862, Martin Davis) Improve test_geos_unit application error checking and reporting Fix MinimumDiameter getMinimumRectangle for flat input (JTS-875, Martin Davis) Fix BufferOp inverted ring check (JTS-878, Martin Davis) Fix OverlayNG geomunion to avoid lines in result (Martin Davis) ","description":"The 3.11.0 release of GEOS is now available to download.\nThis release includes new features for building \u0026ldquo;concave hulls\u0026rdquo; for both point and polygon input. For polygon input, the hull will be guaranteed to not cross into the interiors of the input polygons.\nThe line merger has been enhanced to support a mode that only merges lines which share orientation.\nThe offset curve algorithm has been updated to be more reliable for different kinds of semi-degenerate inputs, and may output different curves than the previous implementation, for those kinds of inputs. For \u0026ldquo;normal\u0026rdquo; inputs, the results should look very much like the old implementation.\nAs usual, numerous bugs have been fixed, and a few performance improvements discovered and implemented.\n"},{"id":25,"href":"/posts/2022-06-03-geos-3-10-3-released/","title":"Version 3.10.3","parent":"News","content":"As part of a batch release of patches for all stable branches, the 3.10.3 release of GEOS is now available to download.\nRelease notes for the various branches are available: 3.7.4, 3.8.3, 3.9.3 and 3.10.3.\nThe 3.10.3 release is a bug fix release.\n VoronoiDiagramBuilder::setSites(const CoordinateSequence\u0026amp;) return sorted (GH-551) Add SnappingNoder seeding (Martin Davis) Fix RelateOp (and intersects predicate) for lines with intersections very near boundary (GH-570, Martin Davis) Fix segfault in Hausdorff distance with empty geometries (GH-569) Fix inf loop in PolygonTriangulator (GH-574, Andrew Stelter) Fix short circuit from TemplateSTRtree query (GH-577, Andrew Stelter) Fix IsValidOp to handle repeated node points (JTS-845, Martin Davis) Fix IsSimpleOp to handle closed LineStrings with repeated endpoints (JTS-851, Martin Davis) Add OverlayNG area check heuristic (JTS-812, Paul Ramsey) Improve test_geos_unit application error checking and reporting (Martin Davis) Fix LengthIndexedLine (via LengthLocationMap fix) (JTS-859, Martin Davis) Fix PolygonHoleJoiner (JTS-862, Martin Davis) Fix crash in GeometryNoder on empty intpu (GH-601, Paul Ramsey) Handle case where user sets explicit absolute lib and include dirs (GH-608, Paul Ramsey) Fix MinimumDiameter getMinimumRectangle for flat input (JTS-875, Martin Davis) Fix HilbertEncoder difference in ARM vs x64 (GH-579, Paul Ramsey) Fix BufferOp inverted ring check (JTS-878, Martin Davis) ","description":"As part of a batch release of patches for all stable branches, the 3.10.3 release of GEOS is now available to download.\nRelease notes for the various branches are available: 3.7.4, 3.8.3, 3.9.3 and 3.10.3.\nThe 3.10.3 release is a bug fix release.\n"},{"id":26,"href":"/posts/2021-11-02-geos-3-10-2-released/","title":"Version 3.10.2","parent":"News","content":"The 3.10.2 release of GEOS is now available to download.\nThis release is a bug fix release.\n Fix crash in MonotoneChain with empty CoordinateSequence (GH-539, Sandro Santilli) Fix crash in GeoJSONWriter in case of empty points (TRAC-1139, Paul Ramsey) Improve BuildArea performance (TRAC-1122, Sandro Santilli) Fix unaryUnion to avoid segfault with empty polygon (GH-501, Mike Taves) Fix memory leak on exception in prepared geometry (GH-506, Dan Baston) Iterator invalidation in rare cases (GH-508, Momtchil Momtchev) Infinite loop on collapsed input to MaximumInscribedCircle (Paul Ramsey) Write LinearRing to GeoJSON as LineString (TRAC-1140, Paul Ramsey) Fix PolygonEarClipper to handle collapsed corners (GH-526, Martin Davis) Fix GEOSSTRtree_remove for empty tree (GH-544, Dan Baston) Fix crash on query of STRtree with removed items (GH-545, Dan Baston)q ","description":"The 3.10.2 release of GEOS is now available to download.\nThis release is a bug fix release.\n"},{"id":27,"href":"/posts/2021-11-02-geos-3-10-1-released/","title":"Version 3.10.1","parent":"News","content":"The 3.10.1 release of GEOS is now available to download.\nThis release is primarily to fix some version numbering issues in the initial 3.10.0 source tarball. Some extra fixes are bundled as well.\n Fixes a mistake in constants used to select WKB flavor in C API  Fixes a crash when reducing precision on a LinearRing Fixes GeoJSON crash on invalid input Uses std::sqrt exclusively, to support the Solaris build Fixes mistaken version numbers in some parts of 3.10.0   ","description":"The 3.10.1 release of GEOS is now available to download.\nThis release is primarily to fix some version numbering issues in the initial 3.10.0 source tarball. Some extra fixes are bundled as well.\n"},{"id":28,"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 features 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 IsValidOp 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 ","description":"The 3.10 release of GEOS is now available to download.\n  This release includes the following new features 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   "},{"id":29,"href":"/project/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@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 decision 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 break 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 expected 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     Note: The following is for historical interest only. The current PSC is available here.\nPrior to announcing itself, the PSC 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  ","description":"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@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."},{"id":30,"href":"/project/rfcs/rfc02/","title":"GEOS RFC 2 - Committer Guidelines ","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@cleverelephant.ca, lr@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 for 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 adapted 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 legal 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, without 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 corresponding test case included to the GEOS set of unit tests.\n  ","description":"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@cleverelephant.ca, lr@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]."},{"id":31,"href":"/project/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 will 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); For 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 interface which will address the former problems.\n","description":"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."},{"id":32,"href":"/project/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@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 correct 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 Formatting 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 AfterObjCDeclaration: 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/090200.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     Branches 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/  ","description":"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@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."},{"id":33,"href":"/project/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@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 extensively.\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 proposal 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  ","description":"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@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."},{"id":34,"href":"/project/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@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 and 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 Headers 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 compatibility 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 they are not users will ask\n What is this warning I keep on getting about you using an unstable API?\n ","description":"RFC 9 Require explicit configure to use the C++ API   Author Regina Obe   Contact lr@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"},{"id":35,"href":"/project/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@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) Increases 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  ","description":"RFC 7 Use CMake for build system   Author Daniel Baston   Contact dbaston@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."},{"id":36,"href":"/project/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@crunchydata.com   Status In Discussion    This document proposes to modify the Coordinate Sequence API to improve performance 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 calling 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?  ","description":"RFC 8 Improve Coordinate Sequence API   Author Martin Davis   Contact martin.davis@crunchydata.com   Status In Discussion    This document proposes to modify the Coordinate Sequence API to improve performance 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."},{"id":37,"href":"/project/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@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 stated:\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","description":"RFC 9 Restore the C++ API   Author Mateusz Łoskot   Contact mateusz@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 stated:"},{"id":38,"href":"/specifications/geojson/","title":"GeoJSON","parent":"Geometry Formats","content":"\u0026ldquo;GeoJSON\u0026rdquo; is a standard for structuring JSON when encoding geometry and features. By using GeoJSON, rather than some other arbitrary scheme for structuring JSON, you maximize the interoperability of your JSON output. There are dozens of tools and websites that happily consume and emit GeoJSON.\nThe GeoJSON standard is formally maintained by the IETF as \u0026ldquo;RFC 7946\u0026rdquo;.\nUnlike WKB and WKT, GeoJSON does not restrict itself to just geometry representation. It also standardizes the transport of attribution. The three key levels of GeoJSON are:\n Geometry, representation of Points, LineStrings, Polygons, etc. Feature, representation of an object that has a \u0026ldquo;geometry\u0026rdquo; and an arbitrary set of other non-geometric \u0026ldquo;properties\u0026rdquo;. FeatureCollection, representation of a list of Features.  Since GEOS is almost 100% concerned with geometry operations, there is no GEOS abstraction to translate the non-geometric properties of GeoJSON Feature into, so handling of Feature properties is only available via the C++ GeoJSON.h utilities.\nWriting GeoJSON     The GeoJSON writer, in both the C and C++ APIs, only supports writing out the Geometry portion of GeoJSON. So for writing features, the writer will end up embedded in some larger JSON emitter.\n/* Read a linestring */ const char* linestring = \u0026#34;LINESTRING(0 0 1, 1 1 1, 2 1 2)\u0026#34;; GEOSWKTReader* reader = GEOSWKTReader_create(); GEOSGeom* geom = GEOSWKTReader_read(reader, linestring); /* Write it out as GeoJSON */ GEOSGeoJSONWriter* writer = GEOSGeoJSONWriter_create(); /* Generate the JSON, with an indentation of 2 */ int indentation = 2; unsigned char* json = GEOSGeoJSONWriter_writeGeometry(writer, geom, indentation); /* do something ... */ /* Free the WKB */ GEOSFree(json); GEOSGeom_destroy(geom); GEOSGeoJSONWriter_destroy(writer); GEOSWKTReader_destroy(reader); Reading GeoJSON     The C++ GeoJSON reader does include the option to read full Feature and FeatureCollection objects, with a narrow API for reading the resulting objects.\n#include \u0026lt;geos/io/GeoJSON.h\u0026gt; // GeoJSONFeatureCollection, etc#include \u0026lt;geos/io/GeoJSONReader.h\u0026gt;#include \u0026lt;geos/io/WKTWriter.h\u0026gt;#include \u0026lt;geos/geom/Geometry.h\u0026gt; using namespace geos::io; using namespace geos::geom; void main(void) { // Read file into string  std::ifstream ifs(\u0026#34;geojson.json\u0026#34;); std::string content((std::istreambuf_iterator\u0026lt;char\u0026gt;(ifs) ), (std::istreambuf_iterator\u0026lt;char\u0026gt;() )); // Parse GeoJSON string into GeoJSON objects  GeoJSONReader reader; GeoJSONFeatureCollection fc = reader.readFeatures(content); // Prepare WKT writer  WKTWriter writer; writer.setTrim(true); // Only needed before GEOS 3.12  writer.setRoundingPrecision(2); // Print out the features  for (auto\u0026amp; feature: fc) { // Read the geometry  const Geometry* geom = feature.getGeometry(); // Read the properties  std::map\u0026lt;std::string, GeoJSONValue\u0026gt;\u0026amp; props = feature.getProperties(); // Write all properties  std::cout \u0026lt;\u0026lt; \u0026#34;----------\u0026#34; \u0026lt;\u0026lt; std::endl; for (const auto\u0026amp; prop : props) { std::cout \u0026lt;\u0026lt; prop.first \u0026lt;\u0026lt; \u0026#34;: \u0026#34; \u0026lt;\u0026lt; prop.second \u0026lt;\u0026lt; std::endl; } // Write WKT feometry  std::cout \u0026lt;\u0026lt; \u0026#34;geometry: \u0026#34; \u0026lt;\u0026lt; writer.write(geom) \u0026lt;\u0026lt; std::endl; } } ","description":"\u0026ldquo;GeoJSON\u0026rdquo; is a standard for structuring JSON when encoding geometry and features. By using GeoJSON, rather than some other arbitrary scheme for structuring JSON, you maximize the interoperability of your JSON output. There are dozens of tools and websites that happily consume and emit GeoJSON.\nThe GeoJSON standard is formally maintained by the IETF as \u0026ldquo;RFC 7946\u0026rdquo;.\nUnlike WKB and WKT, GeoJSON does not restrict itself to just geometry representation. It also standardizes the transport of attribution."},{"id":39,"href":"/specifications/wkb/","title":"Well-Known Binary (WKB)","parent":"Geometry Formats","content":"\u0026ldquo;Well-known binary\u0026rdquo; is a scheme for writing a simple features geometry into a platform-independent array of bytes, usually for transport between systems or between programs. By using WKB, systems can avoid exposing their particular internal implementation of geometry storage, for greater overall interoperability.\nGEOS can read and write three \u0026ldquo;flavours\u0026rdquo; of WKB:\n Standard WKB Extended WKB ISO WKB  When reading WKB, GEOS will transparently detect the flavour of WKB and automatically read it. When writing WKB, the application developer must indicate what flavour of WKB to use, in particular when writing higher dimensional outputs.\nStandard WKB     Standard WKB supports two-dimensional geometry, and is a proper subset of both extended WKB and ISO WKB.\nData Types     The WKB specification uses three basic types common to most typed languages: an unsigned byte; a 4-byte unsigned integer; and an 8-byte IEEE double.\n// byte : 1 byte // uint32 : 32 bit unsigned integer (4 bytes) // double : double precision number (8 bytes) Byte Order     In order to allow portability between systems with difference architectures, the representation of those types is conditioned by the wkbByteOrder.\nenum wkbByteOrder { wkbXDR = 0, // Big Endian wkbNDR = 1 // Little Endian }; A \u0026ldquo;little endian\u0026rdquo; integer has the least-significant bytes first, hence \u0026ldquo;little\u0026rdquo;. For example, the number 1, encoded in little- and big- endian:\n# Little endian 01 00 00 00 # Big endian 00 00 00 01 In practice this means that almost all WKB is encoded little endian, since most modern processors are little endian, but the existence of the wkbByteOrder allows WKB to transport geometry easily between systems of different endianness.\nCoordinates     The double precision numbers in the coordinates are also subject to the byte order rules. To encode geometries with more than 2 dimensions, see the Extended WKB format below.\nPoint { double x; double y; }; Rings     Linear rings are components of the polygon type, and never appear outside of the polygon. Hence they dispense with the byte order and geometry type, since both are implicit in their location in the polygon structure.\nLinearRing { uint32 numPoints; Point points[numPoints]; }; Empty Geometries     For most geometry types, empty geometries are indicated naturally by having numPoints = 0. Points do not have a numPoints field, so POINT EMPTY is represented by a Point with each ordinate value set to an IEEE-754 quiet NaN value (big endian 0x7ff8000000000000 or little endian 0x000000000000f87f).\nGeometry Types     GEOS only supports the seven original simple features geometry types.\nenum wkbGeometryType { wkbPoint = 1, wkbLineString = 2, wkbPolygon = 3, wkbMultiPoint = 4, wkbMultiLineString = 5, wkbMultiPolygon = 6, wkbGeometryCollection = 7 }; Other systems (eg PostGIS) support a wider range of types (for example, CircularString, CurvePolygon), and hence more geometry type numbers, but GEOS is currently unable to consume those geometries.\nWKBPoint { byte byteOrder; uint32 wkbType; // 1 Point point; }; WKBLineString { byte byteOrder; uint32 wkbType; // 2 uint32 numPoints; Point points[numPoints]; }; WKBPolygon { byte byteOrder; uint32 wkbType; // 3 uint32 numRings; LinearRing rings[numRings] } WKBMultiPoint { byte byteOrder; uint32 wkbType; // 4 uint32 numWkbPoints; WKBPoint WKBPoints[numWkbPoints]; } WKBMultiLineString { byte byteOrder; uint32 wkbType; // 5 uint32 num numWkbLineStrings; WKBLineString WKBLineStrings[numWkbLineStrings]; } wkbMultiPolygon { byte byteOrder; uint32 wkbType; // 6 uint32 numWkbPolygons; WKBPolygon wkbPolygons[numWkbPolygons]; } WKBGeometry { union { WKBPoint point; WKBLineString linestring; WKBPolygon polygon; WKBGeometryCollection collection; WKBMultiPoint mpoint; WKBMultiLineString mlinestring; WKBMultiPolygon mpolygon; } } WKBGeometryCollection { byte byteOrder; uint32 wkbType; // 7 uint32 numWkbGeometries; WKBGeometry wkbGeometries[numWkbGeometries]; } Example     The following bytes (in hex) make up the WKB for a LINESTRING(0 0, 1 1, 2 1):\n01 - byteOrder(wkbNDR) 02000000 - wkbType(LineString) 03000000 - numPoints(3) 0000000000000000 - x(0.0) 0000000000000000 - y(0.0) 000000000000F03F - x(1.0) 000000000000F03F - y(1.0) 0000000000000040 - x(2.0) 000000000000F03F - y(1.0) Extended WKB     The original WKB specification made no allowances for adding extra dimensions, like Z and M, that are common in GIS applications. It also had no space for embedding a spatial reference identifier (SRID), which made it unusable as a database import/export format.\nThe \u0026ldquo;Extended WKB\u0026rdquo; variant is a superset of the standard WKB, which allows applications to optionally add extra dimensions, and optionally embed an SRID.\nThe presence of extra dimensions is indicated by adding flag bits to the existing wkbType that appears in all WKB geometries.\nFor example, here is the structure and flagging for a 3D point \u0026ndash; the dimensionaly flag indicates a Z dimension, and the point member therefore has three coordinates.\nwkbZ = 0x80000000 wkbM = 0x40000000 wkbSRID = 0x20000000 enum wkbGeometryTypeZ { wkbPoint = 1, wkbLineString = 2, wkbPolygon = 3, wkbMultiPoint = 4, wkbMultiLineString = 5, wkbMultiPolygon = 6, wkbGeometryCollection = 7, // | 0x80000000 wkbPointZ = 0x80000001, wkbLineStringZ = 0x80000002, wkbPolygonZ = 0x80000003, wkbMultiPointZ = 0x80000004, wkbMultiLineStringZ = 0x80000005, wkbMultiPolygonZ = 0x80000006, wkbGeometryCollectionZ = 0x80000007, } WKBPointZ { byte byteOrder; // wkbXDR or wkbNDR uint32 wkbType; // wkbPointZ = (wkbPoint | wkbZ) = 0x80000001 Point { Double x; Double y; Double z; } } When the optional wkbSRID is added to the wkbType, an SRID number is inserted after the wkbType number.\nWKBPointS { byte byteOrder; // wkbXDR or wkbNDR uint32 wkbType; // wkbPointS = (wkbPoint | wkbSRID) = 0x20000001 uint32 SRID; Point { Double x; Double y; } } The dimensionality and SRID flags can also be combined. Here is a 3D point with an embedded SRID.\nWKBPointS { byte byteOrder; // wkbXDR or wkbNDR uint32 wkbType; // wkbPointS = (wkbPoint | wbkZ | wkbSRID) = 0xA0000001 uint32 SRID; Point { Double x; Double y; Double z; } } Writing Extended WKB     /* Read a linestring */ const char* linestring = \u0026#34;LINESTRING(0 0 1, 1 1 1, 2 1 2)\u0026#34;; GEOSWKBReader* reader = GEOSWKBReader_create(); GEOSGeom* geom = GEOSWKTReader_read(reader, linestring); GEOSSetSRID(geom, 4326); /* Write it out as Extended WKB */ GEOSWKBWriter* writer = GEOSWKBWriter_create(); /* Next line only needed before GEOS 3.12 */ GEOSWKBWriter_setOutputDimension(writer, 3); GEOSWKBWriter_setFlavor(writer, GEOS_WKB_EXTENDED); GEOSWKBWriter_setIncludeSRID(writer, 1); /* Generate the WKB , and store the output length */ size_t wkb_size; unsigned char* wkb = GEOSWKBWriter_write(writer, geom, \u0026amp;wkb_size); /* do something ... */ /* Free the WKB */ GEOSFree(wkb); GEOSGeom_destroy(geom); ISO WKB     ISO WKB was included in the ISO 13249-3 document (SQL/MM Part 3: Spatial). It allows for higher dimensional geometries, but does not have a facility for SRID embedding.\nGeometry Type     As with extended WKB, ISO WKB supports higher dimensions by adding information to the wkbType number. Rather than using flag bits, however, ISO WKB simply adds a round number to the type number to indicate extra dimensions.\n wkbType + 1000 = wkbTypeZ wkbType + 2000 = wkbTypeM wkbType + 3000 = wkbTypeZM  Writing ISO WKB     /* Read a linestring */ const char* linestring = \u0026#34;LINESTRING(0 0 1, 1 1 1, 2 1 2)\u0026#34;; GEOSWKTReader* reader = GEOSWKTReader_create(); GEOSGeom* geom = GEOSWKTReader_read(reader, linestring); /* Write it out as ISO WKB */ GEOSWKBWriter* writer = GEOSWKBWriter_create(); /* Next line only needed before GEOS 3.12 */ GEOSWKBWriter_setOutputDimension(writer, 3); GEOSWKBWriter_setFlavor(writer, GEOS_WKB_ISO); /* Generate the WKB , and store the output length */ size_t wkb_size; unsigned char* wkb = GEOSWKBWriter_write(writer, geom, \u0026amp;wkb_size); /* do something ... */ /* Free the WKB */ GEOSFree(wkb); GEOSGeom_destroy(geom); GEOSWKBWriter_destroy(writer); GEOSWKTReader_destroy(reader); ","description":"\u0026ldquo;Well-known binary\u0026rdquo; is a scheme for writing a simple features geometry into a platform-independent array of bytes, usually for transport between systems or between programs. By using WKB, systems can avoid exposing their particular internal implementation of geometry storage, for greater overall interoperability.\nGEOS can read and write three \u0026ldquo;flavours\u0026rdquo; of WKB:\n Standard WKB Extended WKB ISO WKB  When reading WKB, GEOS will transparently detect the flavour of WKB and automatically read it."},{"id":40,"href":"/specifications/wkt/","title":"Well-Known Text (WKT)","parent":"Geometry Formats","content":"\u0026ldquo;Well-known text\u0026rdquo; is a scheme for writing a simple features geometry into a standard text string.\nExamples      POINT (0 0) POINT EMPTY LINESTRING (0 0, 0 1, 1 2) LINESTRING EMPTY POLYGON ((0 0, 1 0, 1 1, 0 1, 0 0)) POLYGON ((0 0, 4 0, 4 4, 0 4, 0 0), (1 1, 1 2, 2 2, 2 1, 1 1)) POLYGON EMPTY MULTIPOINT ((0 0), (1 1)) MULTILINESTRING ((0 0, 1 1), (2 2, 3 3)) MULTIPOLYGON (((1 1, 1 3, 3 3, 3 1, 1 1)), ((4 3, 6 3, 6 1, 4 1, 4 3))) GEOMETRYCOLLECTION (MULTIPOINT((0 0), (1 1)), POINT(3 4), LINESTRING(2 3, 3 4))  WKT BNF     \u0026lt;x\u0026gt; ::= \u0026lt;number\u0026gt; \u0026lt;y\u0026gt; ::= \u0026lt;number\u0026gt; \u0026lt;z\u0026gt; ::= \u0026lt;number\u0026gt; \u0026lt;m\u0026gt; ::= \u0026lt;number\u0026gt; \u0026lt;empty set\u0026gt; ::= EMPTY \u0026lt;zm\u0026gt; ::= ZM | Z | M \u0026lt;comma\u0026gt; ::= , \u0026lt;left paren\u0026gt; ::= ( \u0026lt;right paren\u0026gt; ::= ) \u0026lt;point\u0026gt; ::= \u0026lt;x\u0026gt; \u0026lt;y\u0026gt; [ \u0026lt;z\u0026gt; ] [ \u0026lt;m\u0026gt; ] \u0026lt;point text\u0026gt; ::= \u0026lt;empty set\u0026gt; | \u0026lt;left paren\u0026gt; \u0026lt;point\u0026gt; \u0026lt;right paren\u0026gt; \u0026lt;linestring text\u0026gt; ::= \u0026lt;empty set\u0026gt; | \u0026lt;left paren\u0026gt; \u0026lt;point\u0026gt; {\u0026lt;comma\u0026gt; \u0026lt;point\u0026gt;} ... \u0026lt;right paren\u0026gt; \u0026lt;polygon text\u0026gt; ::= \u0026lt;empty set\u0026gt; | \u0026lt;left paren\u0026gt; \u0026lt;linestring text\u0026gt; {\u0026lt;comma\u0026gt; \u0026lt;linestring text\u0026gt;} ... \u0026lt;right paren\u0026gt; \u0026lt;multipoint text\u0026gt; ::= \u0026lt;empty set\u0026gt; | \u0026lt;left paren\u0026gt; \u0026lt;point\u0026gt; {\u0026lt;comma\u0026gt; \u0026lt;point\u0026gt;} ... \u0026lt;right paren\u0026gt; \u0026lt;multilinestring text\u0026gt; ::= \u0026lt;empty set\u0026gt; | \u0026lt;left paren\u0026gt; \u0026lt;linestring text\u0026gt; {\u0026lt;comma\u0026gt; \u0026lt;linestring text\u0026gt;} ... \u0026lt;right paren\u0026gt; \u0026lt;multipolygon text\u0026gt; ::= \u0026lt;empty set\u0026gt; | \u0026lt;left paren\u0026gt; \u0026lt;polygon text\u0026gt; {\u0026lt;comma\u0026gt; \u0026lt;polygon text\u0026gt;} ... \u0026lt;right paren\u0026gt; \u0026lt;geometrycollection text\u0026gt; ::= \u0026lt;empty set\u0026gt; | \u0026lt;left paren\u0026gt; \u0026lt;wkt representation\u0026gt; {\u0026lt;comma\u0026gt; \u0026lt;wkt representation\u0026gt;} ... \u0026lt;right paren\u0026gt; \u0026lt;point text representation\u0026gt; ::= POINT [ \u0026lt;zm\u0026gt; ] \u0026lt;point text\u0026gt; \u0026lt;linestring text representation\u0026gt; ::= LINESTRING [ \u0026lt;zm\u0026gt; ] \u0026lt;linestring text body\u0026gt; \u0026lt;polygon text representation\u0026gt; ::= POLYGON [ \u0026lt;zm\u0026gt; ] \u0026lt;polygon text body\u0026gt; \u0026lt;multipoint text representation\u0026gt; ::= MULTIPOINT [ \u0026lt;zm\u0026gt; ] \u0026lt;multipoint text\u0026gt; \u0026lt;multilinestring text representation\u0026gt; ::= MULTILINESTRING [ \u0026lt;zm\u0026gt; ] \u0026lt;multilinestring text\u0026gt; \u0026lt;multipolygon text representation\u0026gt; ::= MULTIPOLYGON [ \u0026lt;zm\u0026gt; ] \u0026lt;multipolygon text\u0026gt; \u0026lt;geometrycollection text representation\u0026gt; ::= GEOMETRYCOLLECTION [ \u0026lt;zm\u0026gt; ] \u0026lt;geometrycollection text\u0026gt; \u0026lt;wkt representation\u0026gt; ::= \u0026lt;point text representation\u0026gt; | \u0026lt;linestring text representation\u0026gt; | \u0026lt;polygon text representation\u0026gt; | \u0026lt;collection text representation\u0026gt; | \u0026lt;multipoint text representation\u0026gt; | \u0026lt;multilinestring text representation\u0026gt; | \u0026lt;multipolygon text representation\u0026gt; | \u0026lt;geometrycollection text representation\u0026gt; Writing WKT     Because WKT is a decimal text output, it will never be able to exactly represent the underlying machine representation of the coordinates. In general, WKT is used for display to humans, or for transport when exact coordinate representation is not required (some web applications).\nAccordingly, the GEOS well-known text writer allows you to customize the coordinate precision and rounding behaviour, as well as the dimensionality of outputs.\n/* Read a linestring */ const char* linestring = \u0026#34;LINESTRING(0 0 1, 1 1 1, 2 1 2)\u0026#34;; GEOSWKTReader* reader = GEOSWKTReader_create(); GEOSGeom* geom = GEOSWKTReader_read(reader, linestring); /* Get a WKT writer */ GEOSWKTWriter* writer = GEOSWKTWriter_create(); /* Preserve the Z dimension -- only needed before GEOS 3.12 */ GEOSWKTWriter_setOutputDimension(writer, 3); /* Sets the number places after the decimal to output in WKT. Default 16. */ GEOSWKTWriter_setRoundingPrecision(writer, 4); /* * Sets the number trimming option on a \\ref GEOSWKTWriter. * With trim set to 1, the writer will strip trailing 0\u0026#39;s from * the output coordinates. With 0, all coordinates will be * padded with 0\u0026#39;s out to the rounding precision. * This is generally only needed before GEOS 3.12. */ GEOSWKTWriter_setTrim(writer, 1); /* Generate the WKT */ unsigned char* wkt = GEOSWKTWriter_write(writer, geom); /* do something ... */ /* Free the WKT */ GEOSFree(wkt); GEOSGeom_destroy(geom); GEOSWKTWriter_destroy(writer); GEOSWKTReader_destroy(reader); ","description":"\u0026ldquo;Well-known text\u0026rdquo; is a scheme for writing a simple features geometry into a standard text string.\nExamples      POINT (0 0) POINT EMPTY LINESTRING (0 0, 0 1, 1 2) LINESTRING EMPTY POLYGON ((0 0, 1 0, 1 1, 0 1, 0 0)) POLYGON ((0 0, 4 0, 4 4, 0 4, 0 0), (1 1, 1 2, 2 2, 2 1, 1 1)) POLYGON EMPTY MULTIPOINT ((0 0), (1 1)) MULTILINESTRING ((0 0, 1 1), (2 2, 3 3)) MULTIPOLYGON (((1 1, 1 3, 3 3, 3 1, 1 1)), ((4 3, 6 3, 6 1, 4 1, 4 3))) GEOMETRYCOLLECTION (MULTIPOINT((0 0), (1 1)), POINT(3 4), LINESTRING(2 3, 3 4))  WKT BNF     \u0026lt;x\u0026gt; ::= \u0026lt;number\u0026gt; \u0026lt;y\u0026gt; ::= \u0026lt;number\u0026gt; \u0026lt;z\u0026gt; ::= \u0026lt;number\u0026gt; \u0026lt;m\u0026gt; ::= \u0026lt;number\u0026gt; \u0026lt;empty set\u0026gt; ::= EMPTY \u0026lt;zm\u0026gt; ::= ZM | Z | M \u0026lt;comma\u0026gt; ::= , \u0026lt;left paren\u0026gt; ::= ( \u0026lt;right paren\u0026gt; ::= ) \u0026lt;point\u0026gt; ::= \u0026lt;x\u0026gt; \u0026lt;y\u0026gt; [ \u0026lt;z\u0026gt; ] [ \u0026lt;m\u0026gt; ] \u0026lt;point text\u0026gt; ::= \u0026lt;empty set\u0026gt; | \u0026lt;left paren\u0026gt; \u0026lt;point\u0026gt; \u0026lt;right paren\u0026gt; \u0026lt;linestring text\u0026gt; ::= \u0026lt;empty set\u0026gt; | \u0026lt;left paren\u0026gt; \u0026lt;point\u0026gt; {\u0026lt;comma\u0026gt; \u0026lt;point\u0026gt;} ."},{"id":41,"href":"/","title":"GEOS","parent":"","content":"GEOS is a C/C++ library for computational geometry with a focus on algorithms used in geographic information systems (GIS) software. It implements the OGC Simple Features geometry model and provides all the spatial functions in that standard as well as many others. GEOS is a core dependency of PostGIS, QGIS, GDAL, Shapely and many others.\nCapabilities     Spatial Model and Functions\n Geometry Model: 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 geometry (using internal spatial indexes) Spatial Indexes: STR (Sort-Tile-Recursive) packed R-tree spatial index Input/Output: OGC Well Known Text (WKT) and Well Known Binary (WKB) readers and writers.  API Features      C API (provides long-term API and ABI stability) C++ API (will likely change across versions) Thread safety (using the reentrant C API)  License     GEOS is open source software available under the terms of GNU Lesser General Public License (LGPL).\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. We strive to keep our day-to-day interactions collegial and welcoming within a basic Code of Conduct.\nRelationship 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 developed in JTS and ported to GEOS when complete.\nThe projects share testing data. This helps 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).\nCitation     To cite GEOS in publications use:\n GEOS contributors (2021). GEOS computational geometry library. Open Source Geospatial Foundation. URL https://libgeos.org/.\n A BibTeX entry for LaTeX users is\n@Manual{, title = {{GEOS} computational geometry library}, author = {{GEOS contributors}}, organization = {Open Source Geospatial Foundation}, year = {2021}, url = {https://libgeos.org/}, doi = {10.5281/zenodo.11396894} } ","description":"GEOS is a C/C++ library for computational geometry with a focus on algorithms used in geographic information systems (GIS) software. It implements the OGC Simple Features geometry model and provides all the spatial functions in that standard as well as many others. GEOS is a core dependency of PostGIS, QGIS, GDAL, Shapely and many others.\nCapabilities     Spatial Model and Functions\n Geometry Model: 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 geometry (using internal spatial indexes) Spatial Indexes: STR (Sort-Tile-Recursive) packed R-tree spatial index Input/Output: OGC Well Known Text (WKT) and Well Known Binary (WKB) readers and writers."},{"id":42,"href":"/usage/install/","title":"Install Packages","parent":"Usage","content":"   Red Hat Ubuntu Debian Amazon Linux Homebrew Macports      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 software-properties-common 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 repositories.\nsudo apt-get install geos Amazon Linux     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 ","description":"Red Hat Ubuntu Debian Amazon Linux Homebrew Macports      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."},{"id":43,"href":"/categories/","title":"Categories","parent":"GEOS","content":"","description":""},{"id":44,"href":"/usage/download/","title":"Download and Build","parent":"Usage","content":"Download Project        Release Release Date First Release Final Release Download Link Changes     3.12.2 2024/06/05 2023/06/27 2027/07/01 geos-3.12.2.tar.bz2 Changes   3.11.4 2024/06/05 2022/07/01 2026/07/01 geos-3.11.4.tar.bz2 Changes   3.10.6 2023/11/11 2021/10/20 2025/10/20 geos-3.10.6.tar.bz2 Changes   3.9.5 2023/11/12 2020/12/09 2024/12/09 geos-3.9.5.tar.bz2 Changes   3.8.4 EOL 2023/11/12 2019/10/10 2023/11/12 geos-3.8.4.tar.bz2 Changes    Old releases can be downloaded from https://download.osgeo.org/geos/. Any releases not in this list are end-of-life (EOL). Refer to our EOL policy for details. All Final Release dates are subject to change.\nBuild From Source     Build Requirements      CMake 3.13 or later. C++14 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; in a build directory either in the source tree or next to it. The following shows building into a directory in the source tree.\n# Unpack and setup build directory tar xvfj geos-3.12.1.tar.bz2 cd geos-3.12.1 mkdir _build cd _build # Set up the build cmake \\  -DCMAKE_BUILD_TYPE=Release \\  -DCMAKE_INSTALL_PREFIX=/usr/local \\  .. # Run the build, test, install make ctest make install Build Options     The GEOS build can be customized using build options. Options are specified via cmake variables. They are specified on the cmake cmdline as -DVAR=VALUE.\n NOTE: Running cmake with no variables does NOT clear current variable settings. They must be set explicitly on the cmdline, or interactively using ccmake ... To revert to the defaults, clear the build directory contents using rm -rf *.     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. Use ASAN to enable memory usage checking.   CMAKE_INSTALL_PREFIX /usr/local Set to install root. Libraries end up in ./lib or ./lib64, headers in ./include, executables in ./bin   BUILD_DOCUMENTATION ON Attempt to find doxygen executable and build API docs   BUILD_SHARED_LIBS ON Build dynamically linkable libraries   BUILD_TESTING ON Build unit tests   BUILD_BENCHMARKS OFF Build benchmark tests   USE_CCACHE OFF Use ccache to compile C/C++ objects, making subsequent builds quicker    Testing     It is possible to run ctest directly. This gives access to ctest command line options (see ctest --help for a listing).\nctest ctest --output-on-failure 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 ","description":"Download Project        Release Release Date First Release Final Release Download Link Changes     3.12.2 2024/06/05 2023/06/27 2027/07/01 geos-3.12.2.tar.bz2 Changes   3.11.4 2024/06/05 2022/07/01 2026/07/01 geos-3.11.4.tar.bz2 Changes   3.10.6 2023/11/11 2021/10/20 2025/10/20 geos-3.10.6.tar.bz2 Changes   3.9.5 2023/11/12 2020/12/09 2024/12/09 geos-3.9.5.tar.bz2 Changes   3.8.4 EOL 2023/11/12 2019/10/10 2023/11/12 geos-3.8.4.tar.bz2 Changes    Old releases can be downloaded from https://download."},{"id":45,"href":"/tags/","title":"Tags","parent":"GEOS","content":"","description":""}]
\ No newline at end of file
+[{"id":0,"href":"/project/","title":"Project","parent":"GEOS","content":"","description":""},{"id":1,"href":"/project/development/","title":"Development","parent":"Project","content":"Resources      git repository: https://github.com/libgeos/geos geos-devel mailing list and archive #geos chat channels:  Matrix: https://matrix.to/#/#geos:osgeo.org IRC: irc://irc.libera.chat/#osgeo-geos (https://kiwiirc.com/nextclient/irc.libera.chat/#osgeo-geos) Slack: https://osgeo.slack.com/messages/C07RKJ06B/    Bug Reporting     Defects should be reported using GitHub Issues.\nWhen submitting bugs caused by particular geometries, you must submit the geometries that cause the failure, preferably in hex-encoded WKB, so that we can re-produce the failure cases.\nContributing     To contribute fixes to outstanding issues, enhancements, and other smaller changes, open a pull request with your change and a fullsome description of what you are trying to achieve.\nIf you have any doubts as to whether your work, or planned work, is not a \u0026ldquo;smaller\u0026rdquo; change, please join the geos-devel mailing list and describe your plans. Join the list! It is a great way to get acquainted with what the development community is working on.\n","description":"Resources      git repository: https://github.com/libgeos/geos geos-devel mailing list and archive #geos chat channels:  Matrix: https://matrix.to/#/#geos:osgeo.org IRC: irc://irc.libera.chat/#osgeo-geos (https://kiwiirc.com/nextclient/irc.libera.chat/#osgeo-geos) Slack: https://osgeo.slack.com/messages/C07RKJ06B/    Bug Reporting     Defects should be reported using GitHub Issues.\nWhen submitting bugs caused by particular geometries, you must submit the geometries that cause the failure, preferably in hex-encoded WKB, so that we can re-produce the failure cases.\nContributing     To contribute fixes to outstanding issues, enhancements, and other smaller changes, open a pull request with your change and a fullsome description of what you are trying to achieve."},{"id":2,"href":"/project/rfcs/rfc11/","title":"GEOS RFC 11 - GEOS Version and EOL Policy","parent":"Requests for Comment","content":"         RFC 11 End-of-Life (EOL) Policy   Author Regina Obe   Contact lr@pcorp.us   Status Accepted, September 20, 2022    This document describes the GEOS project policy for versioning and EOLing GEOS minor versions.\nVersioning     The GEOS project generally produces a new minor version every 1-2 years. Minor versions typically contain new features, as well as bug fixes and performance improvements. Minor versions have version numbers in the form major.minor (e.g. 3.9, 3.10, 3.11, etc).\nEach minor version has a named git branch (e.g. branch 3.11). The first release of a minor version has a micro version of x.x.0 and is git tagged. For example, the first release of version 3.11 was 3.11.0 and has git tag 3.11.0.\nPatch Policy     On an as-needed basis, each supported minor version will have additional micro releases (e.g. 3.10.1,3.10.2). These subsequent micro releases may have bug fixes, performance improvements, and security fixes but will not include new features. They are patch releases for the parent minor version. Micro releases are git tagged with the version number (e.g. tag 3.10.1).\n The newer the minor version, the more likely performance improvements will be added. Performance improvements that could destabilize a release (e.g. requiring too much code) or change behavior will generally not be applied. Bug fixes that are not trivial changes of code or major security or crash issues, will likely not be applied to older versions. The latest stable release (meaning the minor release with highest number that is not the main branch) will have all bug fixes and enhancements which are not new features.  End-of-Life Policy     Minor versions marked EOL will not have further releases. We may apply fixes to a minor branch if an entity is willing to fund such an effort, but the change will not be tagged.\nThe policy for making a minor version EOL is:\n If the first release of the minor version is more than 3-5 years old, it may become EOL.  When a minor version is EOL, it will either be removed from Downloads or will have an EOL marker showing it is the last release for the minor version.\n","description":"RFC 11 End-of-Life (EOL) Policy   Author Regina Obe   Contact lr@pcorp.us   Status Accepted, September 20, 2022    This document describes the GEOS project policy for versioning and EOLing GEOS minor versions.\nVersioning     The GEOS project generally produces a new minor version every 1-2 years. Minor versions typically contain new features, as well as bug fixes and performance improvements."},{"id":3,"href":"/project/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@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 projects 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  ","description":"RFC 10 Move Project to GitHub   Author Paul Ramsey   Contact pramsey@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:"},{"id":4,"href":"/project/development/tests/","title":"Testing","parent":"Development","content":"Testing executables are in bin\n See also the ctest documentation.  Unit Tests     The GEOS unit tests are written using the TUT framework. There are tests for both the C++ code and the C API. The test source files are in the test/unit directory. The test group names are in the group declaration in each XXXTest.cpp file. By convention the test group name is based on the test file path and name.\nThe entire set of unit tests is run by calling the test_geos_unit executable:\n$ bin/test_geos_unit # Run all tests The unit tests groups can be listed:\n$ bin/test_geos_unit --list # List all test groups Individual unit test groups can be run by calling test_geos_unit with the test group name:\n$ bin/test_geos_unit capi::GEOSBuffer # Run a single group of tests Individual tests within a test group can be run by specifying the group name and test number:\n$ bin/test_geos_unit capi::GEOSBuffer 1 XML Tests     The XML test suite is a set of portable, declarative tests which can be run in both GEOS and JTS. They are located in tests/xmltester/tests. XML tests can be run using test_xmltester:\nbin/test_xmltester ../tests/xmltester/tests/robust/overlay/TestOverlay-geos-837.xml The XML Tester provides the following options:\nUsage: bin/test_xmltester [options] \u0026lt;test\u0026gt; [\u0026lt;test\u0026gt; ...] Options: -v Verbose mode (multiple -v increment verbosity) --test-valid-output Test output validity --test-valid-input Test input validity --sql-output Produce SQL output --wkb-output Print Geometries as HEXWKB Performance Tests     There are performance tests which are not built or run as part of the standard test suite. Building this is enabled by the cmake -DBUILD_BENCHMARKS=ON flag. The various tests can be run from the command line, e.g.:\n$ bin/perf_iterated_buffer Memory Usage testing     In some cases bugs are caused by improper memory access after deallocation (heap-use-after-free). This may be able to be detected and reported by using the Address Sanitizer compiler capability. Enable this via cmake -DCMAKE_BUILD_TYPE=ASAN.\n","description":"Testing executables are in bin\n See also the ctest documentation.  Unit Tests     The GEOS unit tests are written using the TUT framework. There are tests for both the C++ code and the C API. The test source files are in the test/unit directory. The test group names are in the group declaration in each XXXTest.cpp file. By convention the test group name is based on the test file path and name."},{"id":5,"href":"/usage/","title":"Usage","parent":"GEOS","content":"","description":""},{"id":6,"href":"/project/coc/","title":"Code of Conduct","parent":"Project","content":"Introduction     This code of conduct governs how we behave in any GEOS forum or event and whenever we will be judged by our actions. We expect it to be honored by everyone who participates in the GEOS community formally or informally, or claims any affiliation with the GEOS project.\nIt applies to in-person events (such as conferences and related social events), IRC, public and private mailing lists, the issue tracker, the wiki, blogs, Twitter, and any other forums which the community uses for communication and interactions.\nThis code is not exhaustive or complete. It serves to distill our common understanding of a collaborative, shared environment and goals. We expect it to be followed in spirit as much as in the letter, so that it can enrich all of us and the technical communities in which we participate.\nDiversity Statement     GEOS welcomes and encourages participation by everyone. We are committed to being a community that everyone feels good about joining, and we will always work to treat everyone well. No matter how you identify yourself or how others perceive you: we welcome you.\nSpecific Guidelines     We strive to:\n  Be open.\nWe invite anyone to participate in our community. We preferably use public methods of communication for project-related messages, unless discussing something sensitive. This applies to messages for help or project-related support, too; not only is a public support request much more likely to result in an answer to a question, it also makes sure that any inadvertent mistakes made by people answering will be more easily detected and corrected.\n  Be empathetic, welcoming, friendly, and patient.\nWe work together to resolve conflict, assume good intentions, and do our best to act in an empathetic fashion. We may all experience some frustration from time to time, but we do not allow frustration to turn into a personal attack. A community where people feel uncomfortable or threatened is not a productive one. Note that we have a multi-cultural, multi-lingual community and some of us are non-native speakers. We should be respectful when dealing with other community members as well as with people outside our community.\n  Be collaborative.\nOur work will be used by other people, and in turn we will depend on the work of others. When we make something for the benefit of GEOS, we are willing to explain to others how it works, so that they can build on the work to make it even better. Any decision we make will affect users and colleagues, and we take those consequences seriously when making decisions.\n  Be inquisitive.\nNobody knows everything! Asking questions early avoids many problems later, so questions are encouraged, though they may be directed to the appropriate forum. Those who are asked should be responsive and helpful, within the context of our shared goal of improving GEOS.\n  Be careful in the words that we choose.\nWhether we are participating as professionals or volunteers, we value professionalism in all interactions, and take responsibility for our own speech. Be kind to others. Do not insult or put down other participants.\n  Be concise\nKeep in mind that what you write once will be read by hundreds of persons. Writing a short email means people can understand the conversation as efficiently as possible. Short emails should always strive to be empathetic, welcoming, friendly and patient. When a long explanation is necessary, consider adding a summary.\nTry to bring new ideas to a conversation so that each mail adds something unique to the thread, keeping in mind that the rest of the thread still contains the other messages with arguments that have already been made.\nTry to stay on topic, especially in discussions that are already fairly large.\n  Step down considerately.\nMembers of every project come and go. When somebody leaves or disengages from the project they should tell people they are leaving and take the proper steps to ensure that others can pick up where they left off. In doing so, they should remain respectful of those who continue to participate in the project and should not misrepresent the project’s goals or achievements. Likewise, community members should respect any individual’s choice to leave the project.\n  Anti-Harassment     Harassment and other exclusionary behaviour are not acceptable. This includes, but is not limited to:\n Personal insults or discriminatory jokes and language, especially those using racist or sexist terms. Offensive comments, excessive or unnecessary profanity. Intimidation, violent threats or demands. Sustained disruption of sessions or events. Stalking, harassing photography or recording. Unwelcome physical contact or sexual attention. Repeated harassment of others. In general, if someone asks you to stop, then stop. Posting (or threatening to post) other people’s personally identifying information (“doxing”). Sharing private content, such as emails sent privately or non-publicly, or unlogged forums such as IRC channel history. Advocating for, or encouraging, any of the above behaviour.  Reporting Guidelines     If you believe someone is breaking this code of conduct, you may reply to them, and point to this code of conduct. Such messages may be in public or in private, whatever is most appropriate. Assume good faith; it is more likely that participants are unaware of their bad behaviour than that they intentionally try to degrade the quality of the discussion.\nShould there be difficulties in dealing with the situation, you may report your concerns to event staff, a forum leader or the GEOS PSC. Serious or persistent offenders may be expelled from the event or forum by event organizers or forum leaders.\nTo privately email the code of conduct committee leadership use conduct-report@osgeo.org.\nCredits     GEOS re-uses the OSGeo Code of Conduct\n","description":"Introduction     This code of conduct governs how we behave in any GEOS forum or event and whenever we will be judged by our actions. We expect it to be honored by everyone who participates in the GEOS community formally or informally, or claims any affiliation with the GEOS project.\nIt applies to in-person events (such as conferences and related social events), IRC, public and private mailing lists, the issue tracker, the wiki, blogs, Twitter, and any other forums which the community uses for communication and interactions."},{"id":7,"href":"/project/psc/","title":"Project Steering Committee","parent":"Project","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.\nThis PSC list is valid as of February 18th, 2022.\n Dan Baston Howard Butler Martin Davis Regina Obe Paul Ramsey (chair) Sandro Santilli  The PSC approves major changes and RFC documents. Other work is always ongoing, by the PSC and by the other core contributors, listed below:\n Even Rouault Vicky Vergara Kurt Schwehr Mike Taves  Historical core contributors:\n Mateusz Loskot Charlie Savage Norman Vine Sean Gillies Frank Warmerdam Ben Jubb Chuck Thibert Stephen Wong  ","description":"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.\nThis PSC list is valid as of February 18th, 2022.\n Dan Baston Howard Butler Martin Davis Regina Obe Paul Ramsey (chair) Sandro Santilli  The PSC approves major changes and RFC documents."},{"id":8,"href":"/project/rfcs/","title":"Requests for Comment","parent":"Project","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      GEOS RFC 11 - GEOS Version and EOL Policy      ","description":"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      GEOS RFC 11 - GEOS Version and EOL Policy      "},{"id":9,"href":"/usage/doxygen/","title":"API 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  See also:\n C API tutorial C++ API tutorial.  Code examples are available in the code repository.\n","description":"The Doxygen documentation is the most up-to-date reference for the C and C++ API of GEOS.\n C API C++ API  See also:\n C API tutorial C++ API tutorial.  Code examples are available in the code repository."},{"id":10,"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 several 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 memory management. If you create a GEOS object with a GEOS function, you must free it using the appropriate GEOS destructor.  The C API is 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 to 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     GEOS functions provide reentrant variants, indicated by an _r suffix. The reentrant functions work the same as their regular counterparts, but they have an extra parameter, a GEOSContextHandle_t.\nThe GEOSContextHandle_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, call GEOS_init_r() instead of initGEOS() 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.\nIn this example the overall structure of the code is identical, but the reentrant variants are used, and the preamble and cleanup are slightly different.\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_create_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; } Object Model     The GEOSCoordSequence and GEOSGeometry objects are at the heart of the GEOS object model.\nGEOSCoordSequence     GEOSCoordSequence is an ordered list of coordinates. Coordinates are 2 (XY) or 3 (XYZ) dimensional.\nThere are a number of ways to make a GEOSCoordSequence. You can create a GEOSCoordSequence by creating a blank one and then setting the 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 initialize it 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 initialize it from a coordinate buffer (an array of double in coordinate order, eg: XYXYXY).\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 fundamental structure of the GEOS C API is GEOSGeometry. GEOSGeometry is a generic type that 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. When GEOSGeometry values have been created they must be deallocated 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 createEmpty functions take no arguments and return geometries that are \u0026ldquo;empty\u0026rdquo;. Empty geometries represent a (typed) empty set of space. For example, the intersection of two disjoint polygons is a \u0026ldquo;empty polygon\u0026rdquo;.\nThe GEOSGeom_createPoint(), GEOSGeom_createLinearRing() and GEOSGeom_createLineString() functions accept a single GEOSCoordSequence and take ownership of that sequence, so freeing the geometry with GEOSGeom_destroy() frees all the allocated memory.\ndouble coordBuf[] = {1.0,3.0, 2.0,2.0, 3.0,1.0}; size_t seqSize = 3; GEOSCoordSequence* seq = GEOSCoordSeq_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, /* geometry array */ npoints); /* frees collection and contained points */ GEOSGeom_destroy(collection); /* frees the containing array */ free(points); Readers and Writers     The examples above build GEOSCoordSequences 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; only needed before GEOS 3.12 */ GEOSWKTWriter_setTrim(writer, 1); char* wkt_out = GEOSWKTWriter_write(writer, geom); /* Clean up everything we allocated */ GEOSWKTReader_destroy(reader); GEOSGeom_destroy(geom); /* Use GEOSFree() 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 up-front work to create an optimized object, you reap a performance benefit when executing repeated function calls on that object.\nPrepared geometries contain internal indexes that make calls to the \u0026ldquo;spatial predicate\u0026rdquo; functions 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     The STRTree index allows you to create, populate, and query a spatial index. Like most spatial indexes, the STRTree is based on indexing rectangles. For a complete example using a reader and writer, see capi_strtree.c.\nWhen you build an index, you will usually insert an \u0026ldquo;item\u0026rdquo; \u0026ndash; some kind of struct that you are interested in indexing \u0026ndash; and an associated bounds for that item, in the form of a GEOSGeometry. The geometry does not need to be rectangular, a rectangular bounding box will be automatically calculated for the geometry.\nOnce you have built an STRTree, you have two basic ways to query:\n Find the nearest item to a query geometry, using GEOSSTRtree_nearest_generic() Find all the items that intersect with a query rectangle, using GEOSSTRtree_query()  Build the tree by creating it, then inserting items.\n/* * An application will want to index items, which have * some attributes and a geometry part. */ typedef struct { GEOSGeometry* geom; size_t id; } item; /* * The tree doesn\u0026#39;t take ownership of inputs just * holds references, so we keep our point field * handy in an array */ item* items[nItems]; /* * The create parameter for the tree is not the * number of inputs, it is the number of entries * per node. 10 is a good default number to use. */ GEOSSTRtree* tree = GEOSSTRtree_create(10); for (size_t i = 0; i \u0026lt; nItems; i++) { /* Make a random point */ item* obj = random_item(range); /* Store away a reference so we can free it after */ items[i] = obj; /* Add an entry for it to the tree */ GEOSSTRtree_insert(tree, obj-\u0026gt;geom, obj); } Note that the index does not take ownership of the inserted GEOSGeometry or the item, it just stores pointers. So remember to keep a list of the items you create in order to free them at the end of your process.\nOnce the tree is built, you can query it.\nThe generic nearest-neighbor query uses a callback to check the actual distance between the search item and the indexed item. In this way it can filter through the many candidate nearest nodes in the index to find the actual nearest node.\n/* * Item distance callback for GEOSSTRtree_nearest_generic() */ int itemDistanceCallback(const void* item1, const void* item2, double* distance, void* userdata) { item_t* obj1 = (item_t*)item1; item_t* obj2 = (item_t*)item2; return GEOSDistance(obj1-\u0026gt;geom, obj2-\u0026gt;geom, distance); } The query call requires the tree, the item driving the search (so it can be fed into the callback), the geometry driving the search (because the library doesn\u0026rsquo;t know how to extract the geometry from the item a priori), the callback, and whatever extra information want sent into the callback.\n/* Random item to query the index with */ item_t* item_random = random_item(range); /* Nearest item in the index to our random item */ const item_t* item_nearest = GEOSSTRtree_nearest_generic( tree, // STRTree to query  item_random, // Item to use in search  item_random-\u0026gt;geom, // Geometry to seed search  itemDistanceCallback, // Callback to process nearest object  NULL); // Userdata to hand to the callback The query by rectangle function also uses a callback, which could be used to exactly test for a spatial relationship (intersects, contains, etc), for all the index nodes that meet the rough \u0026ldquo;bounds interact\u0026rdquo; filter the index applies.\n/* * Item query callback for GEOSSTRtree_query() */ void itemQueryCallback(void* item, void* userdata) { double x, y; item_t* i = (item_t*)item; GEOSGeomGetX(i-\u0026gt;geom, \u0026amp;x); GEOSGeomGetY(i-\u0026gt;geom, \u0026amp;y); printf(\u0026#34;Found item %10zu at (%g, %g)\\n\u0026#34;, i-\u0026gt;id, x, y); } This example just prints out every candidate that passes the index filter.\n/* Set up a query rectangle for index query */ const char* wkt_bounds = \u0026#34;POLYGON((20 20, 22 20, 22 22, 20 22, 20 20))\u0026#34;; GEOSGeometry* geom_query = GEOSWKTReader_read(reader, wkt_bounds); /* Find all items that touch the bounds */ /* For non-rectangular query geometry, this will be an over-determined set */ GEOSSTRtree_query( tree, // STRTree to query  geom_query, // GEOSGeometry query bounds  itemQueryCallback, // Callback to process index entries that pass query  NULL); // Userdata to hand to the callback The query itself just uses the tree, the query bounds geometry, the callback, and optional user data. You could use the user data to pass in an array to write results out to, or a prepared geometry to use for exact tests.\n","description":"Most programs using GEOS use the C API, rather than building against the C++ headers. The C API offers several 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:"},{"id":11,"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.\nYou can explore the C++ model via the Doxygen reference.\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 complexity of the GEOS symbol space means that binary symbols are known to 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 to 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); /* Only needed before GEOS 3.12 */ 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; } ","description":"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.\nYou can explore the C++ model via the Doxygen reference."},{"id":12,"href":"/project/development/ci_status/","title":"CI Status","parent":"Development","content":"   CI main 3.12 3.11 3.10 3.9 3.8     GitHub         GitLab         Debbie         Winnie         Dronie         Bessie         Bessie32         Berrie         Berrie64          Runners      GitHub - Ubuntu various, Windows various, CMake GitLab - Debian 8.2, GNU/Linux 64bit, GCC, automake Debbie - Debian sid (bullseye), GNU/Linux 64bit, GCC Debian 10.2.1, cmake (3.18.4) \u0026gt;= 3.9, autotools \u0026lt; 3.8 Winnie - Windows Mingw64, 32bit GCC 8.1.0, 64bit GCC 8.1.0, MSys CMake (3.21.3), 64-bit GCC 12.1 (cmake 3.23.2 ninja) Dronie - Alpine Linux 3.14 (alpine.latest), 64bit, GCC 10.3.1, CMake (3.20.3) , automake \u0026lt; 3.10 Bessie - FreeBSD 12.2, 64-bit clang 10.0.1, CMake (3.19.6) \u0026gt;=3.8, autotools \u0026lt; 3.8 Bessie32 - FreeBSD 12.2, 32-bit clang 10.0.1, 64bit gcc 10.3.0, CMake (3.21.3) \u0026gt;=3.8, autotools \u0026lt; 3.8 Berrie - Raspberry Pi (debian bullseye), 32-bit gcc 10.2.1, CMake (3.18.4) Berrie64 - Raspberry Pi (debian bullseye), 64-bit gcc 10.2.1, CMake (3.18.4)  ","description":"CI main 3.12 3.11 3.10 3.9 3.8     GitHub         GitLab         Debbie         Winnie         Dronie         Bessie         Bessie32         Berrie         Berrie64          Runners      GitHub - Ubuntu various, Windows various, CMake GitLab - Debian 8."},{"id":13,"href":"/specifications/","title":"Geometry Formats","parent":"GEOS","content":"GEOS can read and write common formats for the interchange of simple features geometry.\n   GeoJSON      Well-Known Binary (WKB)      Well-Known Text (WKT)      ","description":"GEOS can read and write common formats for the interchange of simple features geometry.\n   GeoJSON      Well-Known Binary (WKB)      Well-Known Text (WKT)      "},{"id":14,"href":"/posts/","title":"News","parent":"GEOS","content":"","description":""},{"id":15,"href":"/usage/tools/","title":"Tools","parent":"Usage","content":" GeosOp  Usage   JTS TestBuilder    GeosOp     geosop is a CLI (command-line interface) for GEOS. It can be used to:\n Run GEOS operations on one or many geometries Output geometry resuls in various formats (WKT and WKB) Convert between WKT and WKB Time the performance of operations Check for memory leaks in operations Check the semantics of GEOS operations  For more information see the README.\nUsage     The geosop executable is in bin.\n Print usage instructions bin/geosop  Print usage instructions and list of available operations bin/geosop --help  Read a file of geometries in WKT and output them as WKB bin/geosop -a geoms.wkt -f wkb  Compute the area of geometries in a WKT file and output them as text bin/geosop -a geoms.wkt --format=txt area  Compute the centroids of geometries in a WKT file and output them as WKT bin/geosop -a geoms.wkt -f wkt centroid   JTS TestBuilder     The JTS TestBuilder can be useful for creating, visualizing and processing GEOS geometry. Because GEOS and JTS are so closely related it can also be used as a way of verifying GEOS behaviour. For more information see the JTS doc.\n","description":"GeosOp  Usage   JTS TestBuilder    GeosOp     geosop is a CLI (command-line interface) for GEOS. It can be used to:\n Run GEOS operations on one or many geometries Output geometry resuls in various formats (WKT and WKB) Convert between WKT and WKB Time the performance of operations Check for memory leaks in operations Check the semantics of GEOS operations  For more information see the README."},{"id":16,"href":"/usage/bindings/","title":"Bindings","parent":"Usage","content":"GEOS can be accessed from a variety of other languages via bindings to the library.\nGo      gogeos  Haskell      geos hgeos  Javascript      node-geos  Julia      LibGEOS.jl  PHP      php-geos. GeoPHP.  Python     Python bindings are available via:\n Shapely PyGEOS Calling functions from libgeos_c via Python ctypes GeoPandas  R      sf geos  Ruby      RGeo.  Rust      geos crate  Swift      GeoSwift  Geospatial applications using GEOS include:\nDatabases      PostGIS INGRES MonetDB SpatiaLite CockroachDB DuckDB  Applications      GDAL/OGR GRASS GIS MapServer MapGuide Open Source MapWindow GIS osgEarth QGIS  ","description":"GEOS can be accessed from a variety of other languages via bindings to the library.\nGo      gogeos  Haskell      geos hgeos  Javascript      node-geos  Julia      LibGEOS.jl  PHP      php-geos. GeoPHP.  Python     Python bindings are available via:\n Shapely PyGEOS Calling functions from libgeos_c via Python ctypes GeoPandas  R      sf geos  Ruby      RGeo."},{"id":17,"href":"/usage/faq/","title":"FAQ","parent":"Usage","content":" Design and Architecture  Why is the C++ API not kept stable? Why does GEOS follow JTS design?   Spatial Model  Does GEOS support computation on the geodetic ellipsoid? Does GEOS support coordinates with measures (M)?   Robustness  Why does GEOSIntersects(GEOSIntersection(A, B), A) == false? Why doesn\u0026rsquo;t a computed point lie exactly on a line?      Design and Architecture     Why is the C++ API not kept stable?     The C++ API is very large, and may have changes in every release. It is evolving to adopt modern C++ coding practices, and often has additions and removals as GEOS spatial algorithms get enhanced. Trying to provide a stable API would involve significant effort, and slow library evolution. The C API is significantly simpler (both in design and at the binary level), so it is much easier to keep stable.\nWhy does GEOS follow JTS design?     GEOS started life as a port of JTS, so its design reflects that heritage. JTS is still evolving and improving, so keeping GEOS fairly close to the JTS design and organization makes it easier to keep porting JTS changes. However, there have been additions to GEOS which were not originally in JTS (although in some cases those were superseded by later JTS development). Also, GEOS is intended to provide high-performance spatial algorithms, which sometimes requires using different code patterns than in Java.\nSpatial Model     Does GEOS support computation on the geodetic ellipsoid?     No. GEOS assumes that geometries are defined in a Cartesian, planar, 2-dimensional space. Thus it cannot be used to compute accurate metrics, predicates or constructions on the geodetic ellipsoid which is usually used to model the surface of the Earth.\nOne way to perform geodetic computations is to project data to an appropriate planar projection using a transformation library such as PROJ. The desired geometric operations can be computed in planar space, and reprojected back to geodetic.\nDoes GEOS support coordinates with measures (M)?     No, the GEOS coordinate model only supports X,Y and Z ordinates. We hope to add support for M, and also a more efficient XY coordinate storage representation.\nRobustness     Why does GEOSIntersects(GEOSIntersection(A, B), A) == false?     GEOS represents geometry coordinates using IEEE-754 double-precision floating point numbers. This is a finite representation, whereas the implicit lines between vertices have infinite precision. In general it is highly unlikely that a coordinate computed via an arithmetic operation (such as a line intersection) is reported by an intersects test as lying exactly on the (theoretical) lines.\nFor example, the diagram below shows how the computed intersection point of two lines in general does not lie exactly on either line (scale exaggerrated for clarity):\nWhy doesn\u0026rsquo;t a computed point lie exactly on a line?     As explained in the previous question, GEOS uses finite-precision floating point arithmetic. In general coordinates computed via arithmetic operations (such as interpolation along a line) is reported by an intersects test as lying exactly on the (theoretical) line. This is due to both round-off error during calculations, and also because in the general case it is not possible to represent points along a line exactly using finite-precision numbers.\nThe diagram below shows how points interpolated along a line rarely lie exactly on the line (scale exaggerrated for clarity):\n","description":"Design and Architecture  Why is the C++ API not kept stable? Why does GEOS follow JTS design?   Spatial Model  Does GEOS support computation on the geodetic ellipsoid? Does GEOS support coordinates with measures (M)?   Robustness  Why does GEOSIntersects(GEOSIntersection(A, B), A) == false? Why doesn\u0026rsquo;t a computed point lie exactly on a line?      Design and Architecture     Why is the C++ API not kept stable?"},{"id":18,"href":"/posts/2024-08-13-relateng/","title":"RelateNG","parent":"News","content":"The upcoming 3.13 release of GEOS includes a complete re-write of the \u0026ldquo;boolean predicates\u0026rdquo;, called \u0026ldquo;RelateNG\u0026rdquo;. The boolean predicates are pairwise tests for geometries that return true/false answers. \u0026ldquo;Intersects\u0026rdquo;, \u0026ldquo;Contains\u0026rdquo;, \u0026ldquo;Touches\u0026rdquo; are all examples of boolean predicates.\nThe old implementation in JTS and GEOS operated by building a complete topological relationship graph between the two inputs, then reading the result off the graph. However, computing the whole graph every time is computationally expensive, and the results of many predicates can be determined without a full graph \u0026ndash; the first time you hit an edge intersection, you know that geometries intersect, and you do not need to do any more calculations.\nThe new implementation, RelateNG, has a number of advantages:\n Efficient short-circuited evaluation of topological predicates (including matching custom DE-9IM matrix patterns) Optimized repeated evaluation of predicates against a single geometry via * cached spatial indexes (AKA \u0026ldquo;prepared mode\u0026rdquo;) Robust computation (only point-local geometry topology is computed, so invalid topology does not cause failures) GeometryCollection inputs containing mixed types and overlapping polygons are supported, using union semantics. Zero-length LineStrings are treated as being topologically identical to Points. Support for BoundaryNodeRules.  The port to GEOS blends the new functionality with the existing implementation of PreparedGeometry and the C-API.\n All one-shot predicates are now handled by RelateNG, and should in general be faster. These are called in Geometry.cpp. The default implementation in of prepared geometry, BasicPreparedGeometry.cpp now uses the RelateNG implementations. The existing implementations in PreparedPolygon.cpp, etc, still over-ride the defaults, because they are currently slightly faster. If/when the RelateNG implementations are optimized, they can be replaced. The C-API already had functions for things like GEOSPreparedTouches() even though the \u0026ldquo;touches\u0026rdquo; predicate had no prepared implementation, and was just calling the non-optimized predicate. These functions now end up using the RelateNG prepared implementation, so they should automatically be much faster. The C-API has been expanded with two new functions, GEOSPreparedRelate() and GEOSPreparedRelatePattern(), exposing a new feature of RelateNG, the ability to do accelerated relate matrix calculations.  The RelateNG work has been run against the entire regression suite and returns exactly the same answers over all our collected 20 years of tests.\n The only exception is the handling of a zero-length LineString, which is now treated as logically equivalent to a point.  The RelateNG code is new and there are no doubt lots of places in the implementation that can still be tightened up. The existing pair-wise predicates can be considered deprecated, as the new implementation is faster and just as correct. The existing prepared geometry implementation is still faster, for the cases it supports, but for all the unsupported cases RelateNG now provides faster default implentations.\n","description":"The upcoming 3.13 release of GEOS includes a complete re-write of the \u0026ldquo;boolean predicates\u0026rdquo;, called \u0026ldquo;RelateNG\u0026rdquo;. The boolean predicates are pairwise tests for geometries that return true/false answers. \u0026ldquo;Intersects\u0026rdquo;, \u0026ldquo;Contains\u0026rdquo;, \u0026ldquo;Touches\u0026rdquo; are all examples of boolean predicates.\n"},{"id":19,"href":"/posts/2023-11-12-geos-3-9-5-and-3-8-4-released/","title":"Version 3.9.5 and 3.8.4 EOL","parent":"News","content":"As part of a batch release of patches for stable branches, the 3.9.5 release of GEOS is now available to download. In addition this release cycle includes the final release of GEOS 3.8 series, GEOS 3.8.4. If you haven\u0026rsquo;t already upgraded to a newer GEOS minor version from GEOS 3.8, we highly recommend you do so.\nRelease notes for 3.8.4 and 3.9.5 are below: 3.8.4, 3.9.5,\n","description":"As part of a batch release of patches for stable branches, the 3.9.5 release of GEOS is now available to download. In addition this release cycle includes the final release of GEOS 3.8 series, GEOS 3.8.4. If you haven\u0026rsquo;t already upgraded to a newer GEOS minor version from GEOS 3.8, we highly recommend you do so.\nRelease notes for 3.8.4 and 3.9.5 are below: 3.8.4, 3.9.5,"},{"id":20,"href":"/posts/2023-11-11-geos-3-12-1-released/","title":"Version 3.12.1","parent":"News","content":"As part of a batch release of patches for stable branches, the 3.12.1 release of GEOS is now available to download.\nRelease notes for the various branches are available: 3.10.6, 3.11.3, 3.12.1\nThe 3.12.1 release is a bug fix release.\n Remove undefined behaviour in use of null PrecisionModel (GH-931, Jeff Walton) Explicitly set endianness for some tests so that output matches expected (GH-934, Paul Ramsey) Fix IncrementalDelaunayTriangulator to ensure triangulation boundary is convex (GH-953, Martin Davis) Improve scale handling for PrecisionModel (GH-956, Martin Davis) Fix PreparedLineStringDistance for lines within envelope and polygons (GH-959, Martin Davis) Fix error in CoordinateSequence::add when disallowing repeated points (GH-963, Dan Baston) Fix InteriorPointPoint to handle empty elements (GH-977, Martin Davis) Skip over testing empty distances for mixed collections. (GH-979, Paul Ramsey) Fix TopologyPreservingSimplifier endpoint handling to avoid self-intersections (GH-986, Martin Davis) Build warnings with Visual Studio (GH-929, Jeff Mckenna, Paul Ramsey) Fix CMake on Windows with Visual Studio (GH-945, Aaron Barany) ","description":"As part of a batch release of patches for stable branches, the 3.12.1 release of GEOS is now available to download.\nRelease notes for the various branches are available: 3.10.6, 3.11.3, 3.12.1\nThe 3.12.1 release is a bug fix release.\n"},{"id":21,"href":"/posts/2023-06-27-geos-3-12-released/","title":"Version 3.12.0","parent":"News","content":"The 3.12 release of GEOS is now available to download.\n  This release includes the following new features in the C API (and of course underlying changes to the C++ code to support these features):\n GEOSDisjointSubsetUnion, anptimized union algorithm for inputs that can be divided into subsets. GEOSLineSubstring, to clip a line using a start and end fractional length. GEOSEqualsIdentical, to test exact equality (with regards to order, structure, etc) of two geometries. GEOSOrientPolygons, to enforce a ring orientation on all polygonal elements in the input geometry. GEOSSTRtree_build, to force an immediate build of an STRtree. GEOSConcaveHullByLength, to build a concave hull by removing the longest outer edges of the Delaunay Triangulation of the space between the polygons, until the specified maximm edge length is reached GEOSGeomGetM, to read the M-dimensional value of a geometry. GEOSVoronoiDiagram, returns the Voronoi polygons or edges of the vertices of the given geometry. GEOSCoverageSimplifyVW, GEOSCoverageUnion, GEOSCoverageIsValid for working with \u0026ldquo;polygonal coverages\u0026rdquo;, collections of polygons that follow coverage rules (no overlaps, exact vertex equivalence on shared edges). GEOSGeom_releaseCollection, to free a collection while leaving the sub-geometries intact. GEOSMinimumRotatedRectangle, a rework of the minimum rectangle code to be faster and more correct.    GEOS has been updated to read and write \u0026ldquo;M\u0026rdquo; dimension. As with the \u0026ldquo;Z\u0026rdquo; coordinate support, not all operations can preserve the \u0026ldquo;M\u0026rdquo; dimension, but best efforts are made to retain it through calculations, input and output.\n  Much work on the core code of GEOS was carried out with a maintenance grant funded by the GDAL project and carried out by Dan Baston.\n  The full list of changes is as follows:\n  New things:\n C++14 is now required. Polygonal coverages: CoverageValidator, CoveragePolygonValidator, CoverageGapFinder, CoverageUnion (JTS-900, Martin Davis \u0026amp; Paul Ramsey) Support reading and writing M values through WKB and WKT readers/writers (GH-721, Dan Baston) Interpolate M values in overlay results (GH-802, Dan Baston) CAPI: GEOSPreparedContainsXY, GEOSPreparedIntersectsXY (GH-677, Dan Baston) Add CoordinateSequenceIterator (GH-685, Dan Baston) Geometry clustering: DBSCAN, geometry intersection/distance, envelope intersection/distance (GH-688, Dan Baston) CAPI: GEOSDisjointSubsetUnion (GH-692, Dan Baston) CAPI: GEOSLineSubstring (GH-706, Dan Baston) CAPI: GEOSEqualsIdentical (GH-810, Dan Baston) CAPI: GEOSOrientPolygons (GH-818, Dan Baston) CAPI: GEOSSTRtree_build (GH-835, Dan Baston) CAPI: GEOSConcaveHullByLength (GH-849, Martin Davis) CAPI: GEOSGeomGetM (GH-864, Mike Taves) Voronoi: Add option to create diagram in order consistent with inputs (GH-781, Dan Baston) Polygonal coverages: CoverageSimplifier (JTS-911, Martin Davis) CAPI: GEOSCoverageIsValid, GEOSCoverageSimplifyVW (GH-867, Paul Ramsey) CAPI: GEOSGeom_releaseCollection (GH-848) CAPI: GEOSMinimumRotatedRectangle now uses MinimumAreaRectangle (Paul Ramsey)    Breaking Changes\n CoverageUnion now requires valid inputs to produce valid outputs and may return invalid outputs silently when fed invalid inputs. Use CoverageValidator first if you do not know the validity of your data.    Fixes/Improvements:\n WKTReader: Fix parsing of Z and M flags in WKTReader (#676 and GH-669, Dan Baston) WKTReader: Throw exception on inconsistent geometry dimension (#1080, Dan Baston) WKTReader: Throw exception if WKT contains extra text after end of geometry (#1095, Dan Baston) GEOSIntersects: Fix crash with empty point inputs (#1110, Dan Baston) GEOSIntersects: Improve performance/robustness by using PreparedGeometry algorithm (GH-775, Dan Baston) LineMerger: Recursively collect all components from GeometryCollections (#401, Dan Baston) GeometryPrecisionReducer: Return correct dimensionality for empty results (GH-684, Dan Baston) Improve performance of coverage union (GH-681, Dan Baston) Improve performance of prepared polygon intersection (GH-690, Dan Baston) Improve performance of prepared polygon distance (GH-693, Dan Baston) Implement indexed calculations for prepared geometry isWithinDistance (GH-691, Dan Baston) Fix LineSegment.orientationIndex(LineSegment) (GH-699, Martin Davis) Fix DepthSegment comparison operation (GH-707, Martin Davis) Add OverlayNG support for simple GeometryCollection inputs (GH-716, Martin Davis) Fix TopologyPreservingSimplifier to produce stable results for Multi inputs (GH-718, Martin Davis) Improve ConvexHull radial sort robustness (GH-724, Martin Davis) Use more robust Delaunay Triangulation frame size heuristic (GH-728, Martin Davis) DiscreteFrechetDistance: Fix crash with empty inputs (GH-751, Dan Baston) GEOSSimplify / DouglasPeuckerSimplifier: Allow ring origin to be removed (GH-773, Dan Baston) GEOSTopologyPreserveSimplify / TopologyPreservingSimplifier: Allow ring origin to be removed (GH-784, Dan Baston) PreparedLineStringIntersects: Fix incorrect result with mixed-dim collection (GH-774, Dan Baston) GEOSIntersection: Fix FE_INVALID exception on intersection of disjoint geometries (GH-791, Joris Van den Bossche \u0026amp; Dan Baston) Fix incorrect result from Envelope::disjoint (GH-791, Dan Baston) Polygonizer: Fix duplicate lines return by getInvalidRingLines (GH-782, Martin Davis \u0026amp; Dan Baston) GEOSUnaryUnion: Fix crash on collection containing empty point (GH-830, Dan Baston) GEOSBuffer: Fix crash with Inf coordinates (GH-822, Dan Baston) GEOSSTRtree_iterate: Do not return removed items (GH-833, Dan Baston) IndexedFacetDistance: Fix crash with Inf coordinates (GH-821, Dan Baston) HausdorffDistance: Fix crash on collection containing empty point (GH-840, Dan Baston) MaximumInscribedCircle: Fix infinite loop with non-finite coordinates (GH-843, Dan Baston) DistanceOp: Fix crash on collection containing empty point (GH-842, Dan Baston) OffsetCurve: improve behaviour and add Joined mode (JTS-956, Martin Davis) GeometryPrecisionReducer: preserve input collection types (GH-846, Paul Ramsey) OffsetCurve: handle zero-distance offsets (GH-850, Martin Davis) Tri: add exceptions for invalid indexes (GH-853, Martin Davis) LargestEmptyCircle: enhance boundary to allow any polygonal geometry (GH-859, Martin Davis) Fix MaximumInscribedCircle and LargestEmptyCircle performance and memory issues (GH-883, Martin Davis) GEOSHasZ: Fix handling with empty geometries (GH-887, Mike Taves) OffsetCurve: fix EndCap parameter handling (GH-899, Martin Davis) Reduce artifacts in single-sided Buffers: (GH-665 #810 and #712, Sandro Santilli) GeoJSONReader: Fix 2D empty geometry creation (GH-909, Mike Taves) GEOSClipByRect: Fix case with POINT EMPTY (GH-913, Mike Taves) Support mixed GeometryCollection in overlay ops (GH-797, Paul Ramsey)    Changes:\n Remove Orientation.isCCW exception to simplify logic and align with JTS (GH-878, Martin Davis) Change MultiPoint WKT to use parentheses in sub-members (GH-903, Mike Taves) Change WKBWriter default output dimension to 4 (GH-908, Mike Taves) Change WKTWriter defaults output dimension to 4 and trim to \u0026lsquo;on\u0026rsquo; (GH-915, Mike Taves)   ","description":"The 3.12 release of GEOS is now available to download.\n  This release includes the following new features in the C API (and of course underlying changes to the C++ code to support these features):\n GEOSDisjointSubsetUnion, anptimized union algorithm for inputs that can be divided into subsets. GEOSLineSubstring, to clip a line using a start and end fractional length. GEOSEqualsIdentical, to test exact equality (with regards to order, structure, etc) of two geometries. GEOSOrientPolygons, to enforce a ring orientation on all polygonal elements in the input geometry. GEOSSTRtree_build, to force an immediate build of an STRtree. GEOSConcaveHullByLength, to build a concave hull by removing the longest outer edges of the Delaunay Triangulation of the space between the polygons, until the specified maximm edge length is reached GEOSGeomGetM, to read the M-dimensional value of a geometry. GEOSVoronoiDiagram, returns the Voronoi polygons or edges of the vertices of the given geometry. GEOSCoverageSimplifyVW, GEOSCoverageUnion, GEOSCoverageIsValid for working with \u0026ldquo;polygonal coverages\u0026rdquo;, collections of polygons that follow coverage rules (no overlaps, exact vertex equivalence on shared edges). GEOSGeom_releaseCollection, to free a collection while leaving the sub-geometries intact. GEOSMinimumRotatedRectangle, a rework of the minimum rectangle code to be faster and more correct.    GEOS has been updated to read and write \u0026ldquo;M\u0026rdquo; dimension. As with the \u0026ldquo;Z\u0026rdquo; coordinate support, not all operations can preserve the \u0026ldquo;M\u0026rdquo; dimension, but best efforts are made to retain it through calculations, input and output.\n  Much work on the core code of GEOS was carried out with a maintenance grant funded by the GDAL project and carried out by Dan Baston.\n "},{"id":22,"href":"/posts/2023-03-16-geos-3-11-2-released/","title":"Version 3.11.2","parent":"News","content":"As part of a batch release of patches for stable branches, the 3.11.2 release of GEOS is now available to download.\nRelease notes for the various branches are available: 3.10.5, and 3.11.2\nThe 3.11.2 release is a bug fix release.\n GEOSIntersection: Fix FE_INVALID exception on intersection of disjoint geometries (GH-791, Joris Van den Bossche \u0026amp; Dan Baston) Fix incorrect result from Envelope::disjoint (GH-791, Dan Baston) Fix handling of odd cases in PolygonHoleJoiner (JTS-946, Paul Ramsey, Martin Davis) Support gcc-13 (GH-743, Sergei Trofimovich) Disallow Inf envelopes in Quadtree, avoid inf loop (Paul Ramsey) GEOSUnaryUnion: Fix crash on collection containing empty point (GH-830, Dan Baston) GEOSSTRtree_iterate: Do not return removed items (GH-833, Dan Baston) IndexedFacetDistance: Fix crash with Inf coordinates (GH-821, Dan Baston) HausdorffDistance: Fix crash on collection containing empty point (GH-840, Dan Baston) MaximumInscribedCircle: Fix infinite loop with non-finite coordinates (GH-843, Dan Baston) DistanceOp: Fix crash on collection containing empty point (GH-842, Dan Baston) Guard against non-finite distances in Buffer/OffsetCurve (GH-661, Paul Ramsey) ","description":"As part of a batch release of patches for stable branches, the 3.11.2 release of GEOS is now available to download.\nRelease notes for the various branches are available: 3.10.5, and 3.11.2\nThe 3.11.2 release is a bug fix release.\n"},{"id":23,"href":"/posts/2022-11-14-geos-3-11-1-released/","title":"Version 3.11.1","parent":"News","content":"As part of a batch release of patches for stable branches, the 3.11.1 release of GEOS is now available to download.\nRelease notes for the various branches are available: 3.9.4, 3.10.4, and 3.11.1\nThe 3.11.1 release is a bug fix release.\n Remove spurious version from \u0026ndash;libs geos-config options Fix PreparedGeometry to avoid crashes with EMPTY elements in input (GH-678, Martin Davis) Fix LineSegment.orientationIndex(LineSegment) (GH-699, Martin Davis) Fix DepthSegment comparison operation (GH-707, Martin Davis) Add OverlayNG support for simple GeometryCollection inputs (GH-716, Martin Davis) Fix TopologyPreservingSimplifier to produce stable results for Multi inputs (GH-718) Fix WKB hex endian test (GH-720, Paul Ramsey) Improve ConvexHull radial sort robustness (GH-724, Martin Davis) Use more robust Delaunay Triangulation frame size heuristic (GH-728, Martin Davis) Fix crash in GEOSIntersects with empty point inputs (GH-673, Dan Baston) Fix RelateOp for empty geometry and closed linear geometry (TRAC-1096, Dan Baston) Return 2D result on 2D input to GeometryPrecisionReducer (TRAC-1137, Dan Baston) ","description":"As part of a batch release of patches for stable branches, the 3.11.1 release of GEOS is now available to download.\nRelease notes for the various branches are available: 3.9.4, 3.10.4, and 3.11.1\nThe 3.11.1 release is a bug fix release.\n"},{"id":24,"href":"/posts/2022-07-01-geos-3-11-0-released/","title":"Version 3.11.0","parent":"News","content":"The 3.11.0 release of GEOS is now available to download.\nThis release includes new features for building \u0026ldquo;concave hulls\u0026rdquo; for both point and polygon input. For polygon input, the hull will be guaranteed to not cross into the interiors of the input polygons.\nThe line merger has been enhanced to support a mode that only merges lines which share orientation.\nThe offset curve algorithm has been updated to be more reliable for different kinds of semi-degenerate inputs, and may output different curves than the previous implementation, for those kinds of inputs. For \u0026ldquo;normal\u0026rdquo; inputs, the results should look very much like the old implementation.\nAs usual, numerous bugs have been fixed, and a few performance improvements discovered and implemented.\nNew Things      OffsetCurve (GH-530, Paul Ramsey/Martin Davis) ConcaveHull (GH-549, Paul Ramsey/Martin Davis) PolygonHull (GH-603, Paul Ramsey/Martin Davis) LineMerger directed option (GH-597, Sergei Sh) CAPI: GEOSHilbertCode (GH-556, Brendan Ward) CAPI: GEOSGeom_createRectangle (GH-558, Brendan Ward) CAPI: GEOSGeom_transformXY (GH-563, Dan Baston/Brendan Ward) CAPI: GEOSRemoveRepeatedPoints (GH-599, Paul Ramsey) CAPI: GEOSLineMergeDirected (GH-597, Sergei Sh) CAPI: setFixStructure for WKB/WKT readers to automatically repair structural errors in the input (GH-639, Paul Ramsey)  Fixes \u0026amp; Improvements      Fix unaryUnion to avoid segfault with empty polygon (GH-501, Mike Taves) Fix SnapRoundingNoder to use tolerance in noding; also fixes GeometryPrecisionReducer (GH-504, Sergei Sh) Allow direct setting of grid size (GH-513, Martin Davis) Allow GEOS to be used as a CMake subproject (GH-518, Robert Coup) Remove .inl inline files in favour of header declaration (GH-543, Paul Ramsey) Add SnappingNoder seeding (Martin Davis) Add OverlayNG area check heuristic (JTS-812, Paul Ramsey) Fix RelateOp (and intersects predicate) for lines with intersections very near boundary (GH-570, Martin Davis) Fix IsValidOp to handle repeated node points (JTS-845, Martin Davis) Fix IsSimpleOp to handle closed LineStrings with repeated endpoints (JTS-851, Martin Davis) Fix LengthIndexedLine (via LengthLocationMap fix) (JTS-859, Martin Davis) Fix PolygonHoleJoiner (JTS-862, Martin Davis) Improve test_geos_unit application error checking and reporting Fix MinimumDiameter getMinimumRectangle for flat input (JTS-875, Martin Davis) Fix BufferOp inverted ring check (JTS-878, Martin Davis) Fix OverlayNG geomunion to avoid lines in result (Martin Davis) ","description":"The 3.11.0 release of GEOS is now available to download.\nThis release includes new features for building \u0026ldquo;concave hulls\u0026rdquo; for both point and polygon input. For polygon input, the hull will be guaranteed to not cross into the interiors of the input polygons.\nThe line merger has been enhanced to support a mode that only merges lines which share orientation.\nThe offset curve algorithm has been updated to be more reliable for different kinds of semi-degenerate inputs, and may output different curves than the previous implementation, for those kinds of inputs. For \u0026ldquo;normal\u0026rdquo; inputs, the results should look very much like the old implementation.\nAs usual, numerous bugs have been fixed, and a few performance improvements discovered and implemented.\n"},{"id":25,"href":"/posts/2022-06-03-geos-3-10-3-released/","title":"Version 3.10.3","parent":"News","content":"As part of a batch release of patches for all stable branches, the 3.10.3 release of GEOS is now available to download.\nRelease notes for the various branches are available: 3.7.4, 3.8.3, 3.9.3 and 3.10.3.\nThe 3.10.3 release is a bug fix release.\n VoronoiDiagramBuilder::setSites(const CoordinateSequence\u0026amp;) return sorted (GH-551) Add SnappingNoder seeding (Martin Davis) Fix RelateOp (and intersects predicate) for lines with intersections very near boundary (GH-570, Martin Davis) Fix segfault in Hausdorff distance with empty geometries (GH-569) Fix inf loop in PolygonTriangulator (GH-574, Andrew Stelter) Fix short circuit from TemplateSTRtree query (GH-577, Andrew Stelter) Fix IsValidOp to handle repeated node points (JTS-845, Martin Davis) Fix IsSimpleOp to handle closed LineStrings with repeated endpoints (JTS-851, Martin Davis) Add OverlayNG area check heuristic (JTS-812, Paul Ramsey) Improve test_geos_unit application error checking and reporting (Martin Davis) Fix LengthIndexedLine (via LengthLocationMap fix) (JTS-859, Martin Davis) Fix PolygonHoleJoiner (JTS-862, Martin Davis) Fix crash in GeometryNoder on empty intpu (GH-601, Paul Ramsey) Handle case where user sets explicit absolute lib and include dirs (GH-608, Paul Ramsey) Fix MinimumDiameter getMinimumRectangle for flat input (JTS-875, Martin Davis) Fix HilbertEncoder difference in ARM vs x64 (GH-579, Paul Ramsey) Fix BufferOp inverted ring check (JTS-878, Martin Davis) ","description":"As part of a batch release of patches for all stable branches, the 3.10.3 release of GEOS is now available to download.\nRelease notes for the various branches are available: 3.7.4, 3.8.3, 3.9.3 and 3.10.3.\nThe 3.10.3 release is a bug fix release.\n"},{"id":26,"href":"/posts/2021-11-02-geos-3-10-2-released/","title":"Version 3.10.2","parent":"News","content":"The 3.10.2 release of GEOS is now available to download.\nThis release is a bug fix release.\n Fix crash in MonotoneChain with empty CoordinateSequence (GH-539, Sandro Santilli) Fix crash in GeoJSONWriter in case of empty points (TRAC-1139, Paul Ramsey) Improve BuildArea performance (TRAC-1122, Sandro Santilli) Fix unaryUnion to avoid segfault with empty polygon (GH-501, Mike Taves) Fix memory leak on exception in prepared geometry (GH-506, Dan Baston) Iterator invalidation in rare cases (GH-508, Momtchil Momtchev) Infinite loop on collapsed input to MaximumInscribedCircle (Paul Ramsey) Write LinearRing to GeoJSON as LineString (TRAC-1140, Paul Ramsey) Fix PolygonEarClipper to handle collapsed corners (GH-526, Martin Davis) Fix GEOSSTRtree_remove for empty tree (GH-544, Dan Baston) Fix crash on query of STRtree with removed items (GH-545, Dan Baston)q ","description":"The 3.10.2 release of GEOS is now available to download.\nThis release is a bug fix release.\n"},{"id":27,"href":"/posts/2021-11-02-geos-3-10-1-released/","title":"Version 3.10.1","parent":"News","content":"The 3.10.1 release of GEOS is now available to download.\nThis release is primarily to fix some version numbering issues in the initial 3.10.0 source tarball. Some extra fixes are bundled as well.\n Fixes a mistake in constants used to select WKB flavor in C API  Fixes a crash when reducing precision on a LinearRing Fixes GeoJSON crash on invalid input Uses std::sqrt exclusively, to support the Solaris build Fixes mistaken version numbers in some parts of 3.10.0   ","description":"The 3.10.1 release of GEOS is now available to download.\nThis release is primarily to fix some version numbering issues in the initial 3.10.0 source tarball. Some extra fixes are bundled as well.\n"},{"id":28,"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 features 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 IsValidOp 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 ","description":"The 3.10 release of GEOS is now available to download.\n  This release includes the following new features 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   "},{"id":29,"href":"/project/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@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 decision 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 break 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 expected 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     Note: The following is for historical interest only. The current PSC is available here.\nPrior to announcing itself, the PSC 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  ","description":"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@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."},{"id":30,"href":"/project/rfcs/rfc02/","title":"GEOS RFC 2 - Committer Guidelines ","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@cleverelephant.ca, lr@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 for 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 adapted 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 legal 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, without 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 corresponding test case included to the GEOS set of unit tests.\n  ","description":"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@cleverelephant.ca, lr@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]."},{"id":31,"href":"/project/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 will 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); For 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 interface which will address the former problems.\n","description":"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."},{"id":32,"href":"/project/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@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 correct 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 Formatting 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 AfterObjCDeclaration: 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/090200.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     Branches 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/  ","description":"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@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."},{"id":33,"href":"/project/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@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 extensively.\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 proposal 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  ","description":"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@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."},{"id":34,"href":"/project/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@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 and 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 Headers 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 compatibility 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 they are not users will ask\n What is this warning I keep on getting about you using an unstable API?\n ","description":"RFC 9 Require explicit configure to use the C++ API   Author Regina Obe   Contact lr@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"},{"id":35,"href":"/project/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@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) Increases 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  ","description":"RFC 7 Use CMake for build system   Author Daniel Baston   Contact dbaston@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."},{"id":36,"href":"/project/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@crunchydata.com   Status In Discussion    This document proposes to modify the Coordinate Sequence API to improve performance 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 calling 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?  ","description":"RFC 8 Improve Coordinate Sequence API   Author Martin Davis   Contact martin.davis@crunchydata.com   Status In Discussion    This document proposes to modify the Coordinate Sequence API to improve performance 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."},{"id":37,"href":"/project/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@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 stated:\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","description":"RFC 9 Restore the C++ API   Author Mateusz Łoskot   Contact mateusz@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 stated:"},{"id":38,"href":"/specifications/geojson/","title":"GeoJSON","parent":"Geometry Formats","content":"\u0026ldquo;GeoJSON\u0026rdquo; is a standard for structuring JSON when encoding geometry and features. By using GeoJSON, rather than some other arbitrary scheme for structuring JSON, you maximize the interoperability of your JSON output. There are dozens of tools and websites that happily consume and emit GeoJSON.\nThe GeoJSON standard is formally maintained by the IETF as \u0026ldquo;RFC 7946\u0026rdquo;.\nUnlike WKB and WKT, GeoJSON does not restrict itself to just geometry representation. It also standardizes the transport of attribution. The three key levels of GeoJSON are:\n Geometry, representation of Points, LineStrings, Polygons, etc. Feature, representation of an object that has a \u0026ldquo;geometry\u0026rdquo; and an arbitrary set of other non-geometric \u0026ldquo;properties\u0026rdquo;. FeatureCollection, representation of a list of Features.  Since GEOS is almost 100% concerned with geometry operations, there is no GEOS abstraction to translate the non-geometric properties of GeoJSON Feature into, so handling of Feature properties is only available via the C++ GeoJSON.h utilities.\nWriting GeoJSON     The GeoJSON writer, in both the C and C++ APIs, only supports writing out the Geometry portion of GeoJSON. So for writing features, the writer will end up embedded in some larger JSON emitter.\n/* Read a linestring */ const char* linestring = \u0026#34;LINESTRING(0 0 1, 1 1 1, 2 1 2)\u0026#34;; GEOSWKTReader* reader = GEOSWKTReader_create(); GEOSGeom* geom = GEOSWKTReader_read(reader, linestring); /* Write it out as GeoJSON */ GEOSGeoJSONWriter* writer = GEOSGeoJSONWriter_create(); /* Generate the JSON, with an indentation of 2 */ int indentation = 2; unsigned char* json = GEOSGeoJSONWriter_writeGeometry(writer, geom, indentation); /* do something ... */ /* Free the WKB */ GEOSFree(json); GEOSGeom_destroy(geom); GEOSGeoJSONWriter_destroy(writer); GEOSWKTReader_destroy(reader); Reading GeoJSON     The C++ GeoJSON reader does include the option to read full Feature and FeatureCollection objects, with a narrow API for reading the resulting objects.\n#include \u0026lt;geos/io/GeoJSON.h\u0026gt; // GeoJSONFeatureCollection, etc#include \u0026lt;geos/io/GeoJSONReader.h\u0026gt;#include \u0026lt;geos/io/WKTWriter.h\u0026gt;#include \u0026lt;geos/geom/Geometry.h\u0026gt; using namespace geos::io; using namespace geos::geom; void main(void) { // Read file into string  std::ifstream ifs(\u0026#34;geojson.json\u0026#34;); std::string content((std::istreambuf_iterator\u0026lt;char\u0026gt;(ifs) ), (std::istreambuf_iterator\u0026lt;char\u0026gt;() )); // Parse GeoJSON string into GeoJSON objects  GeoJSONReader reader; GeoJSONFeatureCollection fc = reader.readFeatures(content); // Prepare WKT writer  WKTWriter writer; writer.setTrim(true); // Only needed before GEOS 3.12  writer.setRoundingPrecision(2); // Print out the features  for (auto\u0026amp; feature: fc) { // Read the geometry  const Geometry* geom = feature.getGeometry(); // Read the properties  std::map\u0026lt;std::string, GeoJSONValue\u0026gt;\u0026amp; props = feature.getProperties(); // Write all properties  std::cout \u0026lt;\u0026lt; \u0026#34;----------\u0026#34; \u0026lt;\u0026lt; std::endl; for (const auto\u0026amp; prop : props) { std::cout \u0026lt;\u0026lt; prop.first \u0026lt;\u0026lt; \u0026#34;: \u0026#34; \u0026lt;\u0026lt; prop.second \u0026lt;\u0026lt; std::endl; } // Write WKT feometry  std::cout \u0026lt;\u0026lt; \u0026#34;geometry: \u0026#34; \u0026lt;\u0026lt; writer.write(geom) \u0026lt;\u0026lt; std::endl; } } ","description":"\u0026ldquo;GeoJSON\u0026rdquo; is a standard for structuring JSON when encoding geometry and features. By using GeoJSON, rather than some other arbitrary scheme for structuring JSON, you maximize the interoperability of your JSON output. There are dozens of tools and websites that happily consume and emit GeoJSON.\nThe GeoJSON standard is formally maintained by the IETF as \u0026ldquo;RFC 7946\u0026rdquo;.\nUnlike WKB and WKT, GeoJSON does not restrict itself to just geometry representation. It also standardizes the transport of attribution."},{"id":39,"href":"/specifications/wkb/","title":"Well-Known Binary (WKB)","parent":"Geometry Formats","content":"\u0026ldquo;Well-known binary\u0026rdquo; is a scheme for writing a simple features geometry into a platform-independent array of bytes, usually for transport between systems or between programs. By using WKB, systems can avoid exposing their particular internal implementation of geometry storage, for greater overall interoperability.\nGEOS can read and write three \u0026ldquo;flavours\u0026rdquo; of WKB:\n Standard WKB Extended WKB ISO WKB  When reading WKB, GEOS will transparently detect the flavour of WKB and automatically read it. When writing WKB, the application developer must indicate what flavour of WKB to use, in particular when writing higher dimensional outputs.\nStandard WKB     Standard WKB supports two-dimensional geometry, and is a proper subset of both extended WKB and ISO WKB.\nData Types     The WKB specification uses three basic types common to most typed languages: an unsigned byte; a 4-byte unsigned integer; and an 8-byte IEEE double.\n// byte : 1 byte // uint32 : 32 bit unsigned integer (4 bytes) // double : double precision number (8 bytes) Byte Order     In order to allow portability between systems with difference architectures, the representation of those types is conditioned by the wkbByteOrder.\nenum wkbByteOrder { wkbXDR = 0, // Big Endian wkbNDR = 1 // Little Endian }; A \u0026ldquo;little endian\u0026rdquo; integer has the least-significant bytes first, hence \u0026ldquo;little\u0026rdquo;. For example, the number 1, encoded in little- and big- endian:\n# Little endian 01 00 00 00 # Big endian 00 00 00 01 In practice this means that almost all WKB is encoded little endian, since most modern processors are little endian, but the existence of the wkbByteOrder allows WKB to transport geometry easily between systems of different endianness.\nCoordinates     The double precision numbers in the coordinates are also subject to the byte order rules. To encode geometries with more than 2 dimensions, see the Extended WKB format below.\nPoint { double x; double y; }; Rings     Linear rings are components of the polygon type, and never appear outside of the polygon. Hence they dispense with the byte order and geometry type, since both are implicit in their location in the polygon structure.\nLinearRing { uint32 numPoints; Point points[numPoints]; }; Empty Geometries     For most geometry types, empty geometries are indicated naturally by having numPoints = 0. Points do not have a numPoints field, so POINT EMPTY is represented by a Point with each ordinate value set to an IEEE-754 quiet NaN value (big endian 0x7ff8000000000000 or little endian 0x000000000000f87f).\nGeometry Types     GEOS only supports the seven original simple features geometry types.\nenum wkbGeometryType { wkbPoint = 1, wkbLineString = 2, wkbPolygon = 3, wkbMultiPoint = 4, wkbMultiLineString = 5, wkbMultiPolygon = 6, wkbGeometryCollection = 7 }; Other systems (eg PostGIS) support a wider range of types (for example, CircularString, CurvePolygon), and hence more geometry type numbers, but GEOS is currently unable to consume those geometries.\nWKBPoint { byte byteOrder; uint32 wkbType; // 1 Point point; }; WKBLineString { byte byteOrder; uint32 wkbType; // 2 uint32 numPoints; Point points[numPoints]; }; WKBPolygon { byte byteOrder; uint32 wkbType; // 3 uint32 numRings; LinearRing rings[numRings] } WKBMultiPoint { byte byteOrder; uint32 wkbType; // 4 uint32 numWkbPoints; WKBPoint WKBPoints[numWkbPoints]; } WKBMultiLineString { byte byteOrder; uint32 wkbType; // 5 uint32 num numWkbLineStrings; WKBLineString WKBLineStrings[numWkbLineStrings]; } wkbMultiPolygon { byte byteOrder; uint32 wkbType; // 6 uint32 numWkbPolygons; WKBPolygon wkbPolygons[numWkbPolygons]; } WKBGeometry { union { WKBPoint point; WKBLineString linestring; WKBPolygon polygon; WKBGeometryCollection collection; WKBMultiPoint mpoint; WKBMultiLineString mlinestring; WKBMultiPolygon mpolygon; } } WKBGeometryCollection { byte byteOrder; uint32 wkbType; // 7 uint32 numWkbGeometries; WKBGeometry wkbGeometries[numWkbGeometries]; } Example     The following bytes (in hex) make up the WKB for a LINESTRING(0 0, 1 1, 2 1):\n01 - byteOrder(wkbNDR) 02000000 - wkbType(LineString) 03000000 - numPoints(3) 0000000000000000 - x(0.0) 0000000000000000 - y(0.0) 000000000000F03F - x(1.0) 000000000000F03F - y(1.0) 0000000000000040 - x(2.0) 000000000000F03F - y(1.0) Extended WKB     The original WKB specification made no allowances for adding extra dimensions, like Z and M, that are common in GIS applications. It also had no space for embedding a spatial reference identifier (SRID), which made it unusable as a database import/export format.\nThe \u0026ldquo;Extended WKB\u0026rdquo; variant is a superset of the standard WKB, which allows applications to optionally add extra dimensions, and optionally embed an SRID.\nThe presence of extra dimensions is indicated by adding flag bits to the existing wkbType that appears in all WKB geometries.\nFor example, here is the structure and flagging for a 3D point \u0026ndash; the dimensionaly flag indicates a Z dimension, and the point member therefore has three coordinates.\nwkbZ = 0x80000000 wkbM = 0x40000000 wkbSRID = 0x20000000 enum wkbGeometryTypeZ { wkbPoint = 1, wkbLineString = 2, wkbPolygon = 3, wkbMultiPoint = 4, wkbMultiLineString = 5, wkbMultiPolygon = 6, wkbGeometryCollection = 7, // | 0x80000000 wkbPointZ = 0x80000001, wkbLineStringZ = 0x80000002, wkbPolygonZ = 0x80000003, wkbMultiPointZ = 0x80000004, wkbMultiLineStringZ = 0x80000005, wkbMultiPolygonZ = 0x80000006, wkbGeometryCollectionZ = 0x80000007, } WKBPointZ { byte byteOrder; // wkbXDR or wkbNDR uint32 wkbType; // wkbPointZ = (wkbPoint | wkbZ) = 0x80000001 Point { Double x; Double y; Double z; } } When the optional wkbSRID is added to the wkbType, an SRID number is inserted after the wkbType number.\nWKBPointS { byte byteOrder; // wkbXDR or wkbNDR uint32 wkbType; // wkbPointS = (wkbPoint | wkbSRID) = 0x20000001 uint32 SRID; Point { Double x; Double y; } } The dimensionality and SRID flags can also be combined. Here is a 3D point with an embedded SRID.\nWKBPointS { byte byteOrder; // wkbXDR or wkbNDR uint32 wkbType; // wkbPointS = (wkbPoint | wbkZ | wkbSRID) = 0xA0000001 uint32 SRID; Point { Double x; Double y; Double z; } } Writing Extended WKB     /* Read a linestring */ const char* linestring = \u0026#34;LINESTRING(0 0 1, 1 1 1, 2 1 2)\u0026#34;; GEOSWKBReader* reader = GEOSWKBReader_create(); GEOSGeom* geom = GEOSWKTReader_read(reader, linestring); GEOSSetSRID(geom, 4326); /* Write it out as Extended WKB */ GEOSWKBWriter* writer = GEOSWKBWriter_create(); /* Next line only needed before GEOS 3.12 */ GEOSWKBWriter_setOutputDimension(writer, 3); GEOSWKBWriter_setFlavor(writer, GEOS_WKB_EXTENDED); GEOSWKBWriter_setIncludeSRID(writer, 1); /* Generate the WKB , and store the output length */ size_t wkb_size; unsigned char* wkb = GEOSWKBWriter_write(writer, geom, \u0026amp;wkb_size); /* do something ... */ /* Free the WKB */ GEOSFree(wkb); GEOSGeom_destroy(geom); ISO WKB     ISO WKB was included in the ISO 13249-3 document (SQL/MM Part 3: Spatial). It allows for higher dimensional geometries, but does not have a facility for SRID embedding.\nGeometry Type     As with extended WKB, ISO WKB supports higher dimensions by adding information to the wkbType number. Rather than using flag bits, however, ISO WKB simply adds a round number to the type number to indicate extra dimensions.\n wkbType + 1000 = wkbTypeZ wkbType + 2000 = wkbTypeM wkbType + 3000 = wkbTypeZM  Writing ISO WKB     /* Read a linestring */ const char* linestring = \u0026#34;LINESTRING(0 0 1, 1 1 1, 2 1 2)\u0026#34;; GEOSWKTReader* reader = GEOSWKTReader_create(); GEOSGeom* geom = GEOSWKTReader_read(reader, linestring); /* Write it out as ISO WKB */ GEOSWKBWriter* writer = GEOSWKBWriter_create(); /* Next line only needed before GEOS 3.12 */ GEOSWKBWriter_setOutputDimension(writer, 3); GEOSWKBWriter_setFlavor(writer, GEOS_WKB_ISO); /* Generate the WKB , and store the output length */ size_t wkb_size; unsigned char* wkb = GEOSWKBWriter_write(writer, geom, \u0026amp;wkb_size); /* do something ... */ /* Free the WKB */ GEOSFree(wkb); GEOSGeom_destroy(geom); GEOSWKBWriter_destroy(writer); GEOSWKTReader_destroy(reader); ","description":"\u0026ldquo;Well-known binary\u0026rdquo; is a scheme for writing a simple features geometry into a platform-independent array of bytes, usually for transport between systems or between programs. By using WKB, systems can avoid exposing their particular internal implementation of geometry storage, for greater overall interoperability.\nGEOS can read and write three \u0026ldquo;flavours\u0026rdquo; of WKB:\n Standard WKB Extended WKB ISO WKB  When reading WKB, GEOS will transparently detect the flavour of WKB and automatically read it."},{"id":40,"href":"/specifications/wkt/","title":"Well-Known Text (WKT)","parent":"Geometry Formats","content":"\u0026ldquo;Well-known text\u0026rdquo; is a scheme for writing a simple features geometry into a standard text string.\nExamples      POINT (0 0) POINT EMPTY LINESTRING (0 0, 0 1, 1 2) LINESTRING EMPTY POLYGON ((0 0, 1 0, 1 1, 0 1, 0 0)) POLYGON ((0 0, 4 0, 4 4, 0 4, 0 0), (1 1, 1 2, 2 2, 2 1, 1 1)) POLYGON EMPTY MULTIPOINT ((0 0), (1 1)) MULTILINESTRING ((0 0, 1 1), (2 2, 3 3)) MULTIPOLYGON (((1 1, 1 3, 3 3, 3 1, 1 1)), ((4 3, 6 3, 6 1, 4 1, 4 3))) GEOMETRYCOLLECTION (MULTIPOINT((0 0), (1 1)), POINT(3 4), LINESTRING(2 3, 3 4))  WKT BNF     \u0026lt;x\u0026gt; ::= \u0026lt;number\u0026gt; \u0026lt;y\u0026gt; ::= \u0026lt;number\u0026gt; \u0026lt;z\u0026gt; ::= \u0026lt;number\u0026gt; \u0026lt;m\u0026gt; ::= \u0026lt;number\u0026gt; \u0026lt;empty set\u0026gt; ::= EMPTY \u0026lt;zm\u0026gt; ::= ZM | Z | M \u0026lt;comma\u0026gt; ::= , \u0026lt;left paren\u0026gt; ::= ( \u0026lt;right paren\u0026gt; ::= ) \u0026lt;point\u0026gt; ::= \u0026lt;x\u0026gt; \u0026lt;y\u0026gt; [ \u0026lt;z\u0026gt; ] [ \u0026lt;m\u0026gt; ] \u0026lt;point text\u0026gt; ::= \u0026lt;empty set\u0026gt; | \u0026lt;left paren\u0026gt; \u0026lt;point\u0026gt; \u0026lt;right paren\u0026gt; \u0026lt;linestring text\u0026gt; ::= \u0026lt;empty set\u0026gt; | \u0026lt;left paren\u0026gt; \u0026lt;point\u0026gt; {\u0026lt;comma\u0026gt; \u0026lt;point\u0026gt;} ... \u0026lt;right paren\u0026gt; \u0026lt;polygon text\u0026gt; ::= \u0026lt;empty set\u0026gt; | \u0026lt;left paren\u0026gt; \u0026lt;linestring text\u0026gt; {\u0026lt;comma\u0026gt; \u0026lt;linestring text\u0026gt;} ... \u0026lt;right paren\u0026gt; \u0026lt;multipoint text\u0026gt; ::= \u0026lt;empty set\u0026gt; | \u0026lt;left paren\u0026gt; \u0026lt;point\u0026gt; {\u0026lt;comma\u0026gt; \u0026lt;point\u0026gt;} ... \u0026lt;right paren\u0026gt; \u0026lt;multilinestring text\u0026gt; ::= \u0026lt;empty set\u0026gt; | \u0026lt;left paren\u0026gt; \u0026lt;linestring text\u0026gt; {\u0026lt;comma\u0026gt; \u0026lt;linestring text\u0026gt;} ... \u0026lt;right paren\u0026gt; \u0026lt;multipolygon text\u0026gt; ::= \u0026lt;empty set\u0026gt; | \u0026lt;left paren\u0026gt; \u0026lt;polygon text\u0026gt; {\u0026lt;comma\u0026gt; \u0026lt;polygon text\u0026gt;} ... \u0026lt;right paren\u0026gt; \u0026lt;geometrycollection text\u0026gt; ::= \u0026lt;empty set\u0026gt; | \u0026lt;left paren\u0026gt; \u0026lt;wkt representation\u0026gt; {\u0026lt;comma\u0026gt; \u0026lt;wkt representation\u0026gt;} ... \u0026lt;right paren\u0026gt; \u0026lt;point text representation\u0026gt; ::= POINT [ \u0026lt;zm\u0026gt; ] \u0026lt;point text\u0026gt; \u0026lt;linestring text representation\u0026gt; ::= LINESTRING [ \u0026lt;zm\u0026gt; ] \u0026lt;linestring text body\u0026gt; \u0026lt;polygon text representation\u0026gt; ::= POLYGON [ \u0026lt;zm\u0026gt; ] \u0026lt;polygon text body\u0026gt; \u0026lt;multipoint text representation\u0026gt; ::= MULTIPOINT [ \u0026lt;zm\u0026gt; ] \u0026lt;multipoint text\u0026gt; \u0026lt;multilinestring text representation\u0026gt; ::= MULTILINESTRING [ \u0026lt;zm\u0026gt; ] \u0026lt;multilinestring text\u0026gt; \u0026lt;multipolygon text representation\u0026gt; ::= MULTIPOLYGON [ \u0026lt;zm\u0026gt; ] \u0026lt;multipolygon text\u0026gt; \u0026lt;geometrycollection text representation\u0026gt; ::= GEOMETRYCOLLECTION [ \u0026lt;zm\u0026gt; ] \u0026lt;geometrycollection text\u0026gt; \u0026lt;wkt representation\u0026gt; ::= \u0026lt;point text representation\u0026gt; | \u0026lt;linestring text representation\u0026gt; | \u0026lt;polygon text representation\u0026gt; | \u0026lt;collection text representation\u0026gt; | \u0026lt;multipoint text representation\u0026gt; | \u0026lt;multilinestring text representation\u0026gt; | \u0026lt;multipolygon text representation\u0026gt; | \u0026lt;geometrycollection text representation\u0026gt; Writing WKT     Because WKT is a decimal text output, it will never be able to exactly represent the underlying machine representation of the coordinates. In general, WKT is used for display to humans, or for transport when exact coordinate representation is not required (some web applications).\nAccordingly, the GEOS well-known text writer allows you to customize the coordinate precision and rounding behaviour, as well as the dimensionality of outputs.\n/* Read a linestring */ const char* linestring = \u0026#34;LINESTRING(0 0 1, 1 1 1, 2 1 2)\u0026#34;; GEOSWKTReader* reader = GEOSWKTReader_create(); GEOSGeom* geom = GEOSWKTReader_read(reader, linestring); /* Get a WKT writer */ GEOSWKTWriter* writer = GEOSWKTWriter_create(); /* Preserve the Z dimension -- only needed before GEOS 3.12 */ GEOSWKTWriter_setOutputDimension(writer, 3); /* Sets the number places after the decimal to output in WKT. Default 16. */ GEOSWKTWriter_setRoundingPrecision(writer, 4); /* * Sets the number trimming option on a \\ref GEOSWKTWriter. * With trim set to 1, the writer will strip trailing 0\u0026#39;s from * the output coordinates. With 0, all coordinates will be * padded with 0\u0026#39;s out to the rounding precision. * This is generally only needed before GEOS 3.12. */ GEOSWKTWriter_setTrim(writer, 1); /* Generate the WKT */ unsigned char* wkt = GEOSWKTWriter_write(writer, geom); /* do something ... */ /* Free the WKT */ GEOSFree(wkt); GEOSGeom_destroy(geom); GEOSWKTWriter_destroy(writer); GEOSWKTReader_destroy(reader); ","description":"\u0026ldquo;Well-known text\u0026rdquo; is a scheme for writing a simple features geometry into a standard text string.\nExamples      POINT (0 0) POINT EMPTY LINESTRING (0 0, 0 1, 1 2) LINESTRING EMPTY POLYGON ((0 0, 1 0, 1 1, 0 1, 0 0)) POLYGON ((0 0, 4 0, 4 4, 0 4, 0 0), (1 1, 1 2, 2 2, 2 1, 1 1)) POLYGON EMPTY MULTIPOINT ((0 0), (1 1)) MULTILINESTRING ((0 0, 1 1), (2 2, 3 3)) MULTIPOLYGON (((1 1, 1 3, 3 3, 3 1, 1 1)), ((4 3, 6 3, 6 1, 4 1, 4 3))) GEOMETRYCOLLECTION (MULTIPOINT((0 0), (1 1)), POINT(3 4), LINESTRING(2 3, 3 4))  WKT BNF     \u0026lt;x\u0026gt; ::= \u0026lt;number\u0026gt; \u0026lt;y\u0026gt; ::= \u0026lt;number\u0026gt; \u0026lt;z\u0026gt; ::= \u0026lt;number\u0026gt; \u0026lt;m\u0026gt; ::= \u0026lt;number\u0026gt; \u0026lt;empty set\u0026gt; ::= EMPTY \u0026lt;zm\u0026gt; ::= ZM | Z | M \u0026lt;comma\u0026gt; ::= , \u0026lt;left paren\u0026gt; ::= ( \u0026lt;right paren\u0026gt; ::= ) \u0026lt;point\u0026gt; ::= \u0026lt;x\u0026gt; \u0026lt;y\u0026gt; [ \u0026lt;z\u0026gt; ] [ \u0026lt;m\u0026gt; ] \u0026lt;point text\u0026gt; ::= \u0026lt;empty set\u0026gt; | \u0026lt;left paren\u0026gt; \u0026lt;point\u0026gt; \u0026lt;right paren\u0026gt; \u0026lt;linestring text\u0026gt; ::= \u0026lt;empty set\u0026gt; | \u0026lt;left paren\u0026gt; \u0026lt;point\u0026gt; {\u0026lt;comma\u0026gt; \u0026lt;point\u0026gt;} ."},{"id":41,"href":"/","title":"GEOS","parent":"","content":"GEOS is a C/C++ library for computational geometry with a focus on algorithms used in geographic information systems (GIS) software. It implements the OGC Simple Features geometry model and provides all the spatial functions in that standard as well as many others. GEOS is a core dependency of PostGIS, QGIS, GDAL, Shapely and many others.\nCapabilities     Spatial Model and Functions\n Geometry Model: 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 geometry (using internal spatial indexes) Spatial Indexes: STR (Sort-Tile-Recursive) packed R-tree spatial index Input/Output: OGC Well Known Text (WKT) and Well Known Binary (WKB) readers and writers.  API Features      C API (provides long-term API and ABI stability) C++ API (will likely change across versions) Thread safety (using the reentrant C API)  License     GEOS is open source software available under the terms of GNU Lesser General Public License (LGPL).\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. We strive to keep our day-to-day interactions collegial and welcoming within a basic Code of Conduct.\nRelationship 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 developed in JTS and ported to GEOS when complete.\nThe projects share testing data. This helps 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).\nCitation     To cite GEOS in publications use:\n GEOS contributors (2021). GEOS computational geometry library. Open Source Geospatial Foundation. URL https://libgeos.org/.\n A BibTeX entry for LaTeX users is\n@Manual{, title = {{GEOS} computational geometry library}, author = {{GEOS contributors}}, organization = {Open Source Geospatial Foundation}, year = {2021}, url = {https://libgeos.org/}, doi = {10.5281/zenodo.11396894} } ","description":"GEOS is a C/C++ library for computational geometry with a focus on algorithms used in geographic information systems (GIS) software. It implements the OGC Simple Features geometry model and provides all the spatial functions in that standard as well as many others. GEOS is a core dependency of PostGIS, QGIS, GDAL, Shapely and many others.\nCapabilities     Spatial Model and Functions\n Geometry Model: 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 geometry (using internal spatial indexes) Spatial Indexes: STR (Sort-Tile-Recursive) packed R-tree spatial index Input/Output: OGC Well Known Text (WKT) and Well Known Binary (WKB) readers and writers."},{"id":42,"href":"/usage/install/","title":"Install Packages","parent":"Usage","content":"   Red Hat Ubuntu Debian Amazon Linux Homebrew Macports      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 software-properties-common 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 repositories.\nsudo apt-get install geos Amazon Linux     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 ","description":"Red Hat Ubuntu Debian Amazon Linux Homebrew Macports      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."},{"id":43,"href":"/categories/","title":"Categories","parent":"GEOS","content":"","description":""},{"id":44,"href":"/usage/download/","title":"Download and Build","parent":"Usage","content":"Download Project        Release Release Date First Release Final Release Download Link Changes     3.12.2 2024/06/05 2023/06/27 2027/07/01 geos-3.12.2.tar.bz2 Changes   3.11.4 2024/06/05 2022/07/01 2026/07/01 geos-3.11.4.tar.bz2 Changes   3.10.6 2023/11/11 2021/10/20 2025/10/20 geos-3.10.6.tar.bz2 Changes   3.9.5 2023/11/12 2020/12/09 2024/12/09 geos-3.9.5.tar.bz2 Changes   3.8.4 EOL 2023/11/12 2019/10/10 2023/11/12 geos-3.8.4.tar.bz2 Changes    Old releases can be downloaded from https://download.osgeo.org/geos/. Any releases not in this list are end-of-life (EOL). Refer to our EOL policy for details. All Final Release dates are subject to change.\nBuild From Source     Build Requirements      CMake 3.13 or later. C++14 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; in a build directory either in the source tree or next to it. The following shows building into a directory in the source tree.\n# Unpack and setup build directory tar xvfj geos-3.12.1.tar.bz2 cd geos-3.12.1 mkdir _build cd _build # Set up the build cmake \\  -DCMAKE_BUILD_TYPE=Release \\  -DCMAKE_INSTALL_PREFIX=/usr/local \\  .. # Run the build, test, install make ctest make install Build Options     The GEOS build can be customized using build options. Options are specified via cmake variables. They are specified on the cmake cmdline as -DVAR=VALUE.\n NOTE: Running cmake with no variables does NOT clear current variable settings. They must be set explicitly on the cmdline, or interactively using ccmake ... To revert to the defaults, clear the build directory contents using rm -rf *.     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. Use ASAN to enable memory usage checking.   CMAKE_INSTALL_PREFIX /usr/local Set to install root. Libraries end up in ./lib or ./lib64, headers in ./include, executables in ./bin   BUILD_DOCUMENTATION ON Attempt to find doxygen executable and build API docs   BUILD_SHARED_LIBS ON Build dynamically linkable libraries   BUILD_TESTING ON Build unit tests   BUILD_BENCHMARKS OFF Build benchmark tests   USE_CCACHE OFF Use ccache to compile C/C++ objects, making subsequent builds quicker    Testing     It is possible to run ctest directly. This gives access to ctest command line options (see ctest --help for a listing).\nctest ctest --output-on-failure 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 ","description":"Download Project        Release Release Date First Release Final Release Download Link Changes     3.12.2 2024/06/05 2023/06/27 2027/07/01 geos-3.12.2.tar.bz2 Changes   3.11.4 2024/06/05 2022/07/01 2026/07/01 geos-3.11.4.tar.bz2 Changes   3.10.6 2023/11/11 2021/10/20 2025/10/20 geos-3.10.6.tar.bz2 Changes   3.9.5 2023/11/12 2020/12/09 2024/12/09 geos-3.9.5.tar.bz2 Changes   3.8.4 EOL 2023/11/12 2019/10/10 2023/11/12 geos-3.8.4.tar.bz2 Changes    Old releases can be downloaded from https://download."},{"id":45,"href":"/tags/","title":"Tags","parent":"GEOS","content":"","description":""}]
\ No newline at end of file