Hello AsterixDB Dev Community, The vote to accept the proposal for migrating from ESRI's geometry library to JTS has passed with 3 binding votes from - Mike Carey - Ian Maxon - Till Westmann
Thanks for voting! Vote thread: https://lists.apache.org/thread/mchlz7xhlqjtm2xhd9xm1qk4sykq1l7p Best, Suryaa (on behalf of the AsterixDB PMC) On Sun, Aug 4, 2024 at 10:59 AM Mike Carey <dtab...@gmail.com> wrote: > Agreed, nice proposal! +1 > > (Be sure to including testing with both row and columnnar formats.) > > On 7/31/24 3:18 PM, Till Westmann wrote: > > Nice proposal: +1 > > > > On 2024/07/30 00:59:46 Ian Maxon wrote: > >> Sounds good to me. +1 > >> > >> On Jul 29, 2024 at 16:12:09, Suryaa Charan Shivakumar<sshiv...@ucr.edu> > >> wrote: > >> > >>> Hello AsterixDB Dev Community, > >>> > >>> I hope this message finds you well. I am excited to share a proposal > aimed > >>> at advancing our geometric processing capabilities in AsterixDB. The > >>> proposal, identified with JIRA epic *ASTERIXDB-3412*, is targeted for > the > >>> 9.10.0 release and involves transitioning from the current > >>> com.esri.core.geometry.ogc.OGCGeometry to the Java Topology Suite (JTS) > >>> library. > >>> > >>> Key Motivations: > >>> > >>> 1. Enhanced Compatibility & Maintainability: Transitioning to JTS > >>> offers a more robust support for geometric operations, allowing > >>> extensibility and custom implementation over spatial functions. > >>> 2. Potential Performance Improvements: JTS is expected to provide > not > >>> only compatibility but also performance enhancements over the > existing > >>> geometry library. > >>> > >>> Proposed Changes Include: > >>> > >>> 1. Comprehensive Research & Documentation of current OGCGeometry > use > >>> and dependencies. > >>> 2. Thorough Evaluation of JTS Library to ensure it meets our needs > >>> and integrates well with the existing codebase. > >>> 3. Implementation and Testing across the codebase to ensure > seamless > >>> functionality and performance. > >>> 4. Updates and Revisions in Documentation to reflect the new > changes. > >>> 5. Performance Benchmarking to confirm and enhance the benefits of > JTS > >>> integration. > >>> > >>> Known Limitations and Considerations: > >>> > >>> 1. CRS and Dimensionality Support: Address JTS’s native > limitations on > >>> CRS and higher-dimensional (3d,4d) geometries through custom > >>> implementations or additional libraries. > >>> 1. JTS does not consider or support CRS while doing geometric > >>> operations. However, CRS is important to ensure precision and > correctness. > >>> We may have to evaluate the integration of CRS functionalities > through > >>> libraries like GeoTools, minimizing dependencies while ensuring > robust > >>> support for varied CRS applications. > >>> 2. Issues with JTS while handling 3D or 4D geometry, > >>> Does not have some function implementations for Z, eg. Finding > min > >>> z or max z coordinate in a given geometry. Solution - To > implement this is > >>> fairly easy. Other known documented issues in JTS w.r.t > dimensions are > >>> listed below, > >>> https://github.com/locationtech/jts/issues/733 > >>> < > https://urldefense.com/v3/__https://github.com/locationtech/jts/issues/733__;!!CzAuKJ42GuquVTTmVmPViYEvSg!PiGdnbM37SsJM5MdFI4o05dsJmQQjNbeKfB04azc7-SO85bhaS0Vj3T6RwCeRXOYOajJFvWWw1duH8tT$ > > > >>> https://locationtech.github.io/jts/jts-faq.html#B4 > >>> < > https://urldefense.com/v3/__https://locationtech.github.io/jts/jts-faq.html*B4__;Iw!!CzAuKJ42GuquVTTmVmPViYEvSg!PiGdnbM37SsJM5MdFI4o05dsJmQQjNbeKfB04azc7-SO85bhaS0Vj3T6RwCeRXOYOajJFvWWwx1gF13X$ > > > >>> 2. Dependency Management: Carefully manage new dependencies to > >>> prevent over-complexity in the system architecture. > >>> > >>> We invite you to review the detailed proposal, provide your insights, > and > >>> discuss any potential impacts or improvements. Your feedback is > invaluable > >>> as we refine and move forward with this initiative. > >>> > >>> Thank you for your continued support and collaboration. > >>> > >>> Best, > >>> Suryaa Charan > >>>
