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
