[geos-devel] Refactoring CoordinateSequence

[Vicky Vergara]

I really dont notice where the "pack" is taking place.

On Thu, Aug 30, 2018 at 7:05 PM, Daniel Baston <dbaston at gmail.com> 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 <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
>
>
> _______________________________________________
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/geos-devel/attachments/20180830/1ab277dd/attachment.html>