<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>Le 13 févr. 2014 à 09:54, Rémi Cura a écrit :</div><div><br></div><div>Hi alls,</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr"><div><div><div><div>All in all, exposing precision model is not a design or interface problem, but an algorithmic problem with no solution (except going the exact precision way), thus it is a matter of compromises and balance, because precise output cannot be guaranteed (if you chain operations like buffer(buffer(...buffer(geom)...)), enforcing precision is very difficult ).</div></div></div></div></div></blockquote><div><br></div><br><blockquote type="cite"><div dir="ltr"><div>Maybe people from SFCGAL project would have a lot to say, because they must have done something about precision issue when writting/reading to CGAL.<br></div></div></blockquote><div><br></div><div>Related to SFCGAL, we have to choosed a CGAL kernel reliable enough (for our targeted usages), </div><div>and so implied CGAL internal exact rational number representation.</div><div><br></div><div><br></div><div>And you're right Rémy, chained operations are still an issue,</div><div>because each time we go back to PostGIS (for instance here)</div><div>we are obliged to convert back to double.</div><div><br></div><div><br></div><div>Our first initial thought, was to extent WKT to allow rational notation.</div><div>Something like POINT(2/3 1/3) rather than POINT(0.6666666 0.3333333)</div><div>Cf: <a href="http://wiki.postgresql.org/images/3/36/Postgis_3d_pgday2013_hm.pdf">http://wiki.postgresql.org/images/3/36/Postgis_3d_pgday2013_hm.pdf</a></div><div>(slides 17 and 18)</div><div><br></div><div>But surely something to standardize at OGC/ISO level first… </div><div><br></div><div><br></div><div>So our current lead, to 'solve it', is to allow at low level (meaning here PostgreSQL)</div><div>to use references rather than values for nested functions calls </div><div>(this approach is also something interesting as a pure performance matter):</div><div><a href="http://postgresql.1045698.n5.nabble.com/Detection-of-nested-function-calls-td5775905.html">http://postgresql.1045698.n5.nabble.com/Detection-of-nested-function-calls-td5775905.html</a></div><div><br></div><div>We plan to work again on this subject by this summer.</div><div><br></div><div><br></div><div><br></div><div>HTH,</div><div><br></div><div><br></div><div>O.</div></div></body></html>