[geos-devel] Refactoring CoordinateSequence

[Regina Obe]

Great.  I'm fine with it then – adding to C-APi is fine, removing not so fine.

 

From: geos-devel [mailto:geos-devel-bounces at lists.osgeo.org] On Behalf Of Daniel Baston
Sent: Thursday, August 30, 2018 11:20 AM
To: GEOS Development List <geos-devel at lists.osgeo.org>
Subject: Re: [geos-devel] Refactoring CoordinateSequence

 

Hi Regina,

 

This work would be not cause any changes to the C API, though we would ultimately want to add some functions to the C API to create packed coordinate sequences.

 

Dan

 

On Thu, Aug 30, 2018 at 9:53 AM Regina Obe <lr at pcorp.us <mailto:lr at pcorp.us> > wrote:

I have no objection.  I know Vicky was complaining about the large number of functions that should be private that are exposed. She was planning to deprecate them in 3.8 and remove/make private in a later release.

 

I'm not sure if this is related to that if she's even looked at that class.  Are these linked into CAPI at all?  If so we should probably stub them with an error, if not, I don't care if they are removed as we never said the C++ -API is stable yet.  My hope is once we clean things up a bit, we can guarantee some level of stability for the C++ API as well.

 

 

Thanks,

Regina

 

From: geos-devel [mailto:geos-devel-bounces at lists.osgeo.org <mailto:geos-devel-bounces at lists.osgeo.org> ] On Behalf Of Daniel Baston
Sent: Thursday, August 30, 2018 9:10 AM
To: GEOS Development List <geos-devel at lists.osgeo.org <mailto:geos-devel at lists.osgeo.org> >
Subject: [geos-devel] Refactoring CoordinateSequence

 

I've been exploring porting the PackedCoordinateSequence from JTS to GEOS because it seems like a useful way to improve the interoperability of GEOS with other code (LWGEOM, for example) without requiring copying of everything into GEOS data structures. It turns out that extending CoordinateSequence is pretty onerous in GEOS; the CoordinateSequence class contains many abstract methods that are not in the corresponding CoordinateSequence JTS interface. These methods add requirements of mutability (CoordinateSequence::setAt) and extensibility/contractability (CoordianteSequence::add, CoordianteSequence::deleteAt) and require the author of a derived class to implement functionality that could be seen as unrelated to storing a sequence of coordinates (removeRepeatedPoints, apply_ro, etc.). Does anyone know why so many methods are added to GEOS CoordinateSequence that have no JTS equivalent, and are there any objections to factoring some of the functionality out of the CoordianteSequence class so that it's easier to write other CoordinateSequence implementations?

 

Dan

_______________________________________________
geos-devel mailing list
geos-devel at lists.osgeo.org <mailto:geos-devel at lists.osgeo.org> 
https://lists.osgeo.org/mailman/listinfo/geos-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/geos-devel/attachments/20180830/bb6083fe/attachment-0001.html>