[geos-devel] Refactoring CoordinateSequence

[Daniel Baston]

> 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 <vicky at georepublic.de> 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 <lr at pcorp.us> wrote:
>
>> 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> 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] *On
>> Behalf Of *Daniel Baston
>> *Sent:* Thursday, August 30, 2018 9:10 AM
>> *To:* GEOS Development List <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
>> https://lists.osgeo.org/mailman/listinfo/geos-devel
>>
>>
>> _______________________________________________
>> geos-devel mailing list
>> geos-devel at lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/geos-devel
>>
>
>
>
> --
>
> Georepublic UG (haftungsbeschränkt)
> Salzmannstraße 44,
> 81739 München, Germany
>
> Vicky Vergara
> Operations Research
>
> eMail: vicky at georepublic.de
> 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
> 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/2648aee1/attachment-0001.html>