
<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>Le 1 févr. 2013 à 14:50, Oliver Courtin a écrit :</div><div><span class="Apple-style-span" style="border-collapse: separate; font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div><div><br></div><div>Hi Sandro,</div><br><blockquote type="cite"><div>This is really good news, I'm excited to see CGAL getting into<br>the picture. May I ask about robustness issues found with CGAL ?<br>Are there known puzzles that CGAL is able to solve while GEOS<span class="Apple-converted-space"> </span><br>can't ? Does the existing testsuite pass all fine ?<br>Note that I'm only talking 2D here…<br></div></blockquote><div><br></div><div>Right now we are exploring CGAL, as a way to deal with 3D spatial</div><div>operations (as GEOS never planed to handle 3D)</div><div><br></div><div>So first new features provided by CGAL (and implemented in our first</div><div>SFCGAL stuff) are related to 3D spatial functions: ST_3DIntersects,</div><div>ST_3DIntersection, ST_3DDelaunayTriangles and so on…</div><div><br></div><div><div>Related to 3D operations, there's a need to keep arbitrary precision,</div><div>if we want to keep 3D geometries topology/consistency. </div><div>The good news is that CGAL provide arbitrary precision (GEOS don't), </div><div>with quite similar performances than GEOS ones for double precision </div><div>(2D bench here)</div><div><br></div><div>The bad news is that serialization is not as cheap (meaning time) </div><div>to CGAL structures than with GEOS ones, and so we explored a way to </div><div>save (de)serializations on nested functions calls (e.g see ref_geometry)</div><div><br></div></div><div><br></div><div>About robustness and unit tests, the current SFCGAL implementation </div><div>bring their one unit tests, and passed alls, (nota they are more focused </div><div>on integration, rather than in data robustness)</div><div><br></div><div>We have not worked that far on 2D PostGIS/regress GEOS unit tests till now,</div><div>we know that there's at least some formatting issues (decimal handling</div><div>and so on) to deal with, before to be able to fully compare/check with </div><div>SFCGAL 2D functions.</div><div><br></div><div><br></div><div>And even if it's not in your initial question, we don't have the feeling</div><div>that CGAL could be (in a near future) a way to not use GEOS anymore,</div><div>we are more thinking AND than OR...</div><div><br></div><div>O.</div></div></div></div></span></div></div><br></body></html>