<div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">I really dont notice where the "pack" is taking place.<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 30, 2018 at 7:05 PM, Daniel Baston <span dir="ltr"><<a href="mailto:dbaston@gmail.com" target="_blank">dbaston@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span class=""><div>> <span style="font-family:arial,helvetica,sans-serif">Very strange desing for those 2 classes (I would first "merge" both classes into one, SetAt is on CoordinateArraySequence)</span></div><div><br></div></span>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.<div><br></div><div>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.</div><div><br></div><div>Dan</div></div><div class="HOEnZb"><div class="h5"><br><div class="gmail_quote"><div dir="ltr">On Thu, Aug 30, 2018 at 5:43 PM Vicky Vergara <<a href="mailto:vicky@georepublic.de" target="_blank">vicky@georepublic.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">In GEOS there are 2 classes about Coordinate Sequence</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><a href="https://cvvergara.github.io/GEOS/classgeos_1_1geom_1_1CoordinateSequence.html" target="_blank">https://cvvergara.github.io/<wbr>GEOS/classgeos_1_1geom_1_<wbr>1CoordinateSequence.html</a></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><a href="https://cvvergara.github.io/GEOS/classgeos_1_1geom_1_1CoordinateArraySequence.html" target="_blank">https://cvvergara.github.io/<wbr>GEOS/classgeos_1_1geom_1_<wbr>1CoordinateArraySequence.html</a></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">CoordinateArraySequence is "an Array view" for CoordinateSequence</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">I find these 2 classes confusing, normally you use CoordinateSequence, some operations are accesible only through CoordinateArraySequence</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Very strange desing for those 2 classes (I would first "merge" both classes into one, SetAt is on CoordinateArraySequence)<br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">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.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Regards</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">VIcky<br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">I was never "married" to JTS, I think GEOS must get "divorced" of JTS, and a re-design is part of the divorce papers :)<br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 30, 2018 at 11:00 AM, Regina Obe <span dir="ltr"><<a href="mailto:lr@pcorp.us" target="_blank">lr@pcorp.us</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div link="blue" vlink="purple" lang="EN-US"><div class="m_-859496000556825742m_7992977701087880943m_2400573881141223179WordSection1"><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Great. I'm fine with it then – adding to C-APi is fine, removing not so fine.<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p><div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt"><div><div style="border:none;border-top:solid #e1e1e1 1.0pt;padding:3.0pt 0in 0in 0in"><p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> geos-devel [mailto:<a href="mailto:geos-devel-bounces@lists.osgeo.org" target="_blank">geos-devel-bounces@<wbr>lists.osgeo.org</a>] <b>On Behalf Of </b>Daniel Baston<br><b>Sent:</b> Thursday, August 30, 2018 11:20 AM<span><br><b>To:</b> GEOS Development List <<a href="mailto:geos-devel@lists.osgeo.org" target="_blank">geos-devel@lists.osgeo.org</a>><br></span><b>Subject:</b> Re: [geos-devel] Refactoring CoordinateSequence<u></u><u></u></span></p></div></div><div><div class="m_-859496000556825742m_7992977701087880943h5"><p class="MsoNormal"><u></u> <u></u></p><div><p class="MsoNormal">Hi Regina,<u></u><u></u></p><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">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.<u></u><u></u></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">Dan<u></u><u></u></p></div></div><p class="MsoNormal"><u></u> <u></u></p><div><div><p class="MsoNormal">On Thu, Aug 30, 2018 at 9:53 AM Regina Obe <<a href="mailto:lr@pcorp.us" target="_blank">lr@pcorp.us</a>> wrote:<u></u><u></u></p></div><blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in"><div><div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">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.</span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"> </span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">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.</span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"> </span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"> </span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Thanks,</span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Regina</span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"> </span><u></u><u></u></p><div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt"><div><div style="border:none;border-top:solid #e1e1e1 1.0pt;padding:3.0pt 0in 0in 0in"><p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> geos-devel [mailto:<a href="mailto:geos-devel-bounces@lists.osgeo.org" target="_blank">geos-devel-bounces@<wbr>lists.osgeo.org</a>] <b>On Behalf Of </b>Daniel Baston<br><b>Sent:</b> Thursday, August 30, 2018 9:10 AM<br><b>To:</b> GEOS Development List <<a href="mailto:geos-devel@lists.osgeo.org" target="_blank">geos-devel@lists.osgeo.org</a>><br><b>Subject:</b> [geos-devel] Refactoring CoordinateSequence</span><u></u><u></u></p></div></div><p class="MsoNormal"> <u></u><u></u></p><div><div><p class="MsoNormal">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?<u></u><u></u></p></div><div><p class="MsoNormal"> <u></u><u></u></p></div><div><p class="MsoNormal">Dan<u></u><u></u></p></div></div></div></div></div><p class="MsoNormal">______________________________<wbr>_________________<br>geos-devel mailing list<br><a href="mailto:geos-devel@lists.osgeo.org" target="_blank">geos-devel@lists.osgeo.org</a><br><a href="https://lists.osgeo.org/mailman/listinfo/geos-devel" target="_blank">https://lists.osgeo.org/<wbr>mailman/listinfo/geos-devel</a><u></u><u></u></p></blockquote></div></div></div></div></div></div><br>______________________________<wbr>_________________<br>
geos-devel mailing list<br>
<a href="mailto:geos-devel@lists.osgeo.org" target="_blank">geos-devel@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/geos-devel" rel="noreferrer" target="_blank">https://lists.osgeo.org/<wbr>mailman/listinfo/geos-devel</a><br></blockquote></div><br><br clear="all"><br>-- <br><div class="m_-859496000556825742m_7992977701087880943gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><pre>Georepublic UG (haftungsbeschränkt)
Salzmannstraße 44,
81739 München, Germany
Vicky Vergara
Operations Research
eMail: vicky@<a href="http://georepublic.de" target="_blank">georepublic.de</a>
Web: <a href="https://georepublic.info" target="_blank">https://georepublic.info</a>
Tel: +49 (089) 4161 7698-1
Fax: +49 (089) 4161 7698-9
Commercial register: Amtsgericht München, HRB 181428
CEO: Daniel Kastl
<span></span></pre></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div>
</div>
______________________________<wbr>_________________<br>
geos-devel mailing list<br>
<a href="mailto:geos-devel@lists.osgeo.org" target="_blank">geos-devel@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/geos-devel" rel="noreferrer" target="_blank">https://lists.osgeo.org/<wbr>mailman/listinfo/geos-devel</a></blockquote></div>
</div></div><br>______________________________<wbr>_________________<br>
geos-devel mailing list<br>
<a href="mailto:geos-devel@lists.osgeo.org">geos-devel@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/geos-devel" rel="noreferrer" target="_blank">https://lists.osgeo.org/<wbr>mailman/listinfo/geos-devel</a><br></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><pre>Georepublic UG (haftungsbeschränkt)
Salzmannstraße 44,
81739 München, Germany
Vicky Vergara
Operations Research
eMail: vicky@<a href="http://georepublic.de" target="_blank">georepublic.de</a>
Web: <a href="https://georepublic.info" target="_blank">https://georepublic.info</a>
Tel: +49 (089) 4161 7698-1
Fax: +49 (089) 4161 7698-9
Commercial register: Amtsgericht München, HRB 181428
CEO: Daniel Kastl
<span></span></pre></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div>
</div>