{"action":"created","issue":{"url":"https://api.github.com/repos/Oslandia/SFCGAL/issues/124","repository_url":"https://api.github.com/repos/Oslandia/SFCGAL","labels_url":"https://api.github.com/repos/Oslandia/SFCGAL/issues/124/labels{/name}","comments_url":"https://api.github.com/repos/Oslandia/SFCGAL/issues/124/comments","events_url":"https://api.github.com/repos/Oslandia/SFCGAL/issues/124/events","html_url":"https://github.com/Oslandia/SFCGAL/issues/124","id":137877988,"number":124,"title":"Operation chaining","user":{"login":"vmora","id":4415710,"avatar_url":"https://avatars.githubusercontent.com/u/4415710?v=3","gravatar_id":"","url":"https://api.github.com/users/vmora","html_url":"https://github.com/vmora","followers_url":"https://api.github.com/users/vmora/followers","following_url":"https://api.github.com/users/vmora/following{/other_user}","gists_url":"https://api.github.com/users/vmora/gists{/gist_id}","starred_url":"https://api.github.com/users/vmora/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/vmora/subscriptions","organizations_url":"https://api.github.com/users/vmora/orgs","repos_url":"https://api.github.com/users/vmora/repos","events_url":"https://api.github.com/users/vmora/events{/privacy}","received_events_url":"https://api.github.com/users/vmora/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":5,"created_at":"2016-03-02T13:47:11Z","updated_at":"2016-03-02T23:32:16Z","closed_at":null,"body":"Experimenting with the python API, raises some question about what we want the API to be.\r\n\r\nChaining operations while maintaining smath precision (SP for lazy exact, mp, interval...) proved difficult to port to postgis (@mhugo any update on passing references around). It is not really a problem with the python API where we can expose whatever class we feel like.\r\n\r\nThe fundamental question to me is: to we need to do that ? \r\n\r\nWe know now that we need to post-cond output validity when plungin back into double. If we are chaining operations with SP (i.e. operation return a ref to a sfcgal class that may be invalid in double), we could do something like:\r\n```\r\ndouble_geometry( operation1( operation2( sp_geometry( input_geom_in_double ) ) ) )\r\n```\r\n\r\nThis seem to be a good approach iff:\r\n  - we are actually able to do that (fine in pythin, maybe not in postgis because we need to pass refs)\r\n  - we think that we can gain something significant (e.g. we may be unable to post-cond the validity of intermediates while the final validity is OK, like we do an intersection at the end, and the constructed problematic area is removed by the operation)\r\n\r\nThe alternative, or complementary (current) interface is:\r\n```\r\ndouble_geometry operation1( input_geom_in_double ) = double_geometry( operation1(  sp_geometry( input_geom_in_double ) ) )\r\n```\r\n\r\nThere is another complexity arising from the \"passing ref to chain\": what is the SP precise type that is accepted as input ? Some operations double -> double would be optimally implemented without SP.\r\n\r\nMy guts feeling is that the simple interface is better (i.e. independant functions that can convert the double input to whatever type is optimal, and return a double geom that is valid in double).\r\n\r\nWhat do you think ?\r\n\r\n\r\n"},"comment":{"url":"https://api.github.com/repos/Oslandia/SFCGAL/issues/comments/191492588","html_url":"https://github.com/Oslandia/SFCGAL/issues/124#issuecomment-191492588","issue_url":"https://api.github.com/repos/Oslandia/SFCGAL/issues/124","id":191492588,"user":{"login":"mborne","id":1783064,"avatar_url":"https://avatars.githubusercontent.com/u/1783064?v=3","gravatar_id":"","url":"https://api.github.com/users/mborne","html_url":"https://github.com/mborne","followers_url":"https://api.github.com/users/mborne/followers","following_url":"https://api.github.com/users/mborne/following{/other_user}","gists_url":"https://api.github.com/users/mborne/gists{/gist_id}","starred_url":"https://api.github.com/users/mborne/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/mborne/subscriptions","organizations_url":"https://api.github.com/users/mborne/orgs","repos_url":"https://api.github.com/users/mborne/repos","events_url":"https://api.github.com/users/mborne/events{/privacy}","received_events_url":"https://api.github.com/users/mborne/received_events","type":"User","site_admin":false},"created_at":"2016-03-02T23:32:16Z","updated_at":"2016-03-02T23:32:16Z","body":"@vmora If we use a single kernel, we should use Epeck. Provided points are not created (situation where Epeck is required), the price should be a factor 2 compared to pure double processing (interval arithmetic)\r\n\r\nOptimal approach might requires to switch between serialized, epick and epeck geometries according to the requirements of the algorithms with the following logic : \r\n- geometry is serialized, read as epick geometry if algorithm doesn't requires epeck, invoke algorithm\r\n- geometry is epick, algorithm requires epick => invoke epick\r\n- geometry is epick, algorithm requires epeck => convert geometry to epeck, invoke epeck\r\n- geometry is epeck, invoke epeck (event if the algorithm only requires epick)\r\n\r\nA kind of \"Lazy Geometry\" behind the opaque pointer (sfcgal_geometry_t) in the CAPI with some helpers :\r\n- isEpeckGeometry \r\n- getEpickGeometry : should not be used if the wrapped geometry is epeck \r\n- getEpeckGeometry\r\n?\r\n"}}