Difference between revisions of "Paris Code Sprint 2016 : SFCGAL Agenda"
Jump to navigation
Jump to search
Wiki-Mhugo (talk | contribs) (Created page with "Discussion and group review topics for the Paris Code Sprint 2016. == Discussion == * How to get rid of validity test before geometry construction ? ** add a flag to the...") |
Wiki-Mhugo (talk | contribs) |
||
| Line 7: | Line 7: | ||
* Is there a way to live with two kernels (inexact and exact) to avoid exact geometry construction when not needed ? | * Is there a way to live with two kernels (inexact and exact) to avoid exact geometry construction when not needed ? | ||
* Does the new "expanded" object representation offered by postgresql helps in avoiding to serialize / unserialize between each call ? | * Does the new "expanded" object representation offered by postgresql helps in avoiding to serialize / unserialize between each call ? | ||
| + | |||
| + | * How to reduce type conversions ? (GSERIALIZED -> LWGEOM -> SFCGAL -> CGAL) ? | ||
| + | ** idea: forget SFCGAL::Geometry, use geometry concepts and traits and each "client" library should adapt its classes to the concepts. There could be an adaptor for GSERIALIZED, one for QgsGeometry, etc. Inspire by boost::geometry see http://www.boost.org/doc/libs/1_60_0/libs/geometry/doc/html/geometry/examples/example__adapting_a_legacy_geometry_object_model.html | ||
* Any advances in CGAL about 3D snap rounding ? | * Any advances in CGAL about 3D snap rounding ? | ||
Latest revision as of 00:03, 2 February 2016
Discussion and group review topics for the Paris Code Sprint 2016.
Discussion
- How to get rid of validity test before geometry construction ?
- add a flag to the postgis geometry ? (is_valid)
- Is there a way to live with two kernels (inexact and exact) to avoid exact geometry construction when not needed ?
- Does the new "expanded" object representation offered by postgresql helps in avoiding to serialize / unserialize between each call ?
- How to reduce type conversions ? (GSERIALIZED -> LWGEOM -> SFCGAL -> CGAL) ?
- idea: forget SFCGAL::Geometry, use geometry concepts and traits and each "client" library should adapt its classes to the concepts. There could be an adaptor for GSERIALIZED, one for QgsGeometry, etc. Inspire by boost::geometry see http://www.boost.org/doc/libs/1_60_0/libs/geometry/doc/html/geometry/examples/example__adapting_a_legacy_geometry_object_model.html
- Any advances in CGAL about 3D snap rounding ?
- Integrate spherical kernels ?
Functions that would be nice to have in SFCGAL
- alpha shapes from CGAL 2D and 3D
- "field of view" : not necessarily related to CGAL
- roof generation from straight skeleton