I really dont notice where the "pack" is taking place. On Thu, Aug 30, 2018 at 7:05 PM, Daniel Baston <[email protected]> wrote:
> > Very strange desing for those 2 classes (I would first "merge" both > classes into one, SetAt is on CoordinateArraySequence) > > Well, the reasoning for this is in the JTS source. CoordinateSequence is > intended as an interface that can have multiple implementations, one of > them being a CoordinateArraySequence. Another is a > PackedCoordinateSequence. So, merging these classes seems like a step in > the wrong direction. > > GEOS' raison d'etre is a native port of JTS, so a "divorce" doesn't seem > fruitful to me. JTS is recently seeing quite a bit of new development, and > it's more challenging to share improvements if the codebases diverge. I > don't think a line-by-line port is desirable, and we should take advantage > of niceties like STL algorithms where we can, but keeping the classes and > methods similar seems reasonable. > > Dan > > On Thu, Aug 30, 2018 at 5:43 PM Vicky Vergara <[email protected]> > wrote: > >> In GEOS there are 2 classes about Coordinate Sequence >> https://cvvergara.github.io/GEOS/classgeos_1_1geom_1_ >> 1CoordinateSequence.html >> https://cvvergara.github.io/GEOS/classgeos_1_1geom_1_ >> 1CoordinateArraySequence.html >> >> CoordinateArraySequence is "an Array view" for CoordinateSequence >> I find these 2 classes confusing, normally you use CoordinateSequence, >> some operations are accesible only through CoordinateArraySequence >> Very strange desing for those 2 classes (I would first "merge" both >> classes into one, SetAt is on CoordinateArraySequence) >> >> I dont object on re-design (hey I like to do this kind of stuff), but a >> careful analysis (experimentation of ideas, like the one above) needs to be >> made, because the CoordinateSequence is used in may parts of GEOS. >> >> Regards >> VIcky >> >> I was never "married" to JTS, I think GEOS must get "divorced" of JTS, >> and a re-design is part of the divorce papers :) >> >> >> >> >> >> On Thu, Aug 30, 2018 at 11:00 AM, Regina Obe <[email protected]> wrote: >> >>> Great. I'm fine with it then – adding to C-APi is fine, removing not so >>> fine. >>> >>> >>> >>> *From:* geos-devel [mailto:[email protected]] *On >>> Behalf Of *Daniel Baston >>> *Sent:* Thursday, August 30, 2018 11:20 AM >>> *To:* GEOS Development List <[email protected]> >>> *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 <[email protected]> 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:[email protected]] *On >>> Behalf Of *Daniel Baston >>> *Sent:* Thursday, August 30, 2018 9:10 AM >>> *To:* GEOS Development List <[email protected]> >>> *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 >>> [email protected] >>> https://lists.osgeo.org/mailman/listinfo/geos-devel >>> >>> >>> _______________________________________________ >>> geos-devel mailing list >>> [email protected] >>> https://lists.osgeo.org/mailman/listinfo/geos-devel >>> >> >> >> >> -- >> >> Georepublic UG (haftungsbeschränkt) >> Salzmannstraße 44, >> 81739 München, Germany >> >> Vicky Vergara >> Operations Research >> >> eMail: [email protected] >> Web: https://georepublic.info >> >> Tel: +49 (089) 4161 7698-1 >> Fax: +49 (089) 4161 7698-9 >> >> Commercial register: Amtsgericht München, HRB 181428 >> CEO: Daniel Kastl >> >> >> _______________________________________________ >> geos-devel mailing list >> [email protected] >> https://lists.osgeo.org/mailman/listinfo/geos-devel > > > _______________________________________________ > geos-devel mailing list > [email protected] > https://lists.osgeo.org/mailman/listinfo/geos-devel > -- Georepublic UG (haftungsbeschränkt) Salzmannstraße 44, 81739 München, Germany Vicky Vergara Operations Research eMail: [email protected] Web: https://georepublic.info Tel: +49 (089) 4161 7698-1 Fax: +49 (089) 4161 7698-9 Commercial register: Amtsgericht München, HRB 181428 CEO: Daniel Kastl
_______________________________________________ geos-devel mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/geos-devel
