> On Feb 18, 2022, at 4:31 PM, Paul Ramsey <pram...@cleverelephant.ca> wrote:
>
>
>> On Feb 18, 2022, at 4:15 PM, Andrew Bell <andrew.bell...@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
_______________________________________________
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel
