<div dir="ltr">Hi Regina,<div><br></div><div>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.</div><div><br></div><div>Dan</div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, Aug 30, 2018 at 9:53 AM Regina Obe <<a href="mailto:lr@pcorp.us">lr@pcorp.us</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="#0563C1" vlink="#954F72"><div class="m_-1427319991473680010WordSection1"><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.<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><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.<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><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Thanks,<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Regina<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@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<u></u><u></u></span></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>_______________________________________________<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/mailman/listinfo/geos-devel</a></blockquote></div>