[geos-devel] JTS Harmony

[Paul Ramsey]

> On Feb 18, 2022, at 4:31 PM, Paul Ramsey <pramsey at cleverelephant.ca> wrote:
> 
> 
>> On Feb 18, 2022, at 4:15 PM, Andrew Bell <andrew.bell.ia at gmail.com> wrote:
>> 
>> Has the attitude about keeping the codebase in sync with the JTS code changed? I would potentially do some work on this project if this isn't a requirement -- it seemed difficult to make changes that would make the code more accessible with strict adherence to the JTS structure.
>> 
>> Sorry if this isn't the right thread for this question.
> 
> I think a new thread title makes sense.
> 
> I guess it depends a lot on what those changes are, because one thing we don't want is making porting out of JTS a whole pile harder. 
> 
> Is that a strict restriction, or something else?

Like, there's already affordances for C++ lying around that result in differences. JTS has lots of places where it returns a null Coordinate pointer to indicate a failure, and GEOS ends up working around that with things like Coordinate::isNull(). Similar stuff for Envelopes. The access of Coordinate out of CoordinateArray is a little mismatched to how JTS does it because it's returnng a const Coordinate& instead of a pointer to a Coordinate. Each of these makes porting a wee bit more of a brain exercise, but the trade-offs are worth it in terms of being to stack-allocate things more, work with references, etc.

??

P