{"comment":{"url":"https://api.github.com/repos/PixInsight/PCL/comments/17835984","html_url":"https://github.com/PixInsight/PCL/commit/0fb8b5856146623515bc1132bf9796eed7459660#commitcomment-17835984","id":17835984,"user":{"login":"jconejero","id":9529604,"avatar_url":"https://avatars.githubusercontent.com/u/9529604?v=3","gravatar_id":"","url":"https://api.github.com/users/jconejero","html_url":"https://github.com/jconejero","followers_url":"https://api.github.com/users/jconejero/followers","following_url":"https://api.github.com/users/jconejero/following{/other_user}","gists_url":"https://api.github.com/users/jconejero/gists{/gist_id}","starred_url":"https://api.github.com/users/jconejero/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jconejero/subscriptions","organizations_url":"https://api.github.com/users/jconejero/orgs","repos_url":"https://api.github.com/users/jconejero/repos","events_url":"https://api.github.com/users/jconejero/events{/privacy}","received_events_url":"https://api.github.com/users/jconejero/received_events","type":"User","site_admin":false},"position":17,"line":822,"path":"src/modules/processes/contrib/kkretzschmar/INDIClient/INDICCDFrameInstance.cpp","commit_id":"0fb8b5856146623515bc1132bf9796eed7459660","created_at":"2016-06-12T17:06:06Z","updated_at":"2016-06-12T17:06:06Z","body":"> So step 1-4 is done in INDIMount and step 5 and 6 in INDICCDFrame?\r\n\r\nExactly.\r\n\r\n> Does it mean that the new CLIENT_DATA property is for more flexible inter-device data transfer (exchange data between INDI devices)?\r\n\r\nThe current INDI implementation, IMHO, lacks some resources necessary to implement an integrated client solution, such as your INDIClient. The problem we are facing now is being caused by the fact that camera and mount devices are basically isolated. We need a link between mount and camera to implement a rigorous and efficient mount control system. For example, imagine that your INDI server is on a remote location, say 1000 km from your home, and you are communicating with it via Internet. Suppose that you need a few minutes to download a newly acquired image. In this scenario, you have no way to know for sure the exact coordinates the telescope was pointing to when the image was acquired, other than the OBJCTRA/OBJCTDEC keywords. EQUATORIAL_EOD_COORD is of no help because on one hand, the telescope could have moved while you have downloaded the image, and on the other hand, there is no way to know for sure whoich mount has been used to acquire an image (ACTIVE_DEVICES > ACTIVE_TELESCOPE depends on a manual user intervention, so it isn't reliable). The OBJCTRA/OBJCTDEC keywords are \"cooked\". What happens if you want to use a different implementation, not necessarily using libnova and its precession routine, based on Meeus' book (Astronomical Algorithms)? You are forced to write an ugly solution, for example using an inverse transformation to \"uncook\" the coordinates, and hence introducing a dependency on a particular INDI server version, ...\r\n\r\nA custom client data property is a clean and simple way to overcome these limitations. For implementations that don't want anything better than OBJCTRA/OBJCTDEC, there is no need to change anything. However, for implementations that look for more accuracy and flexibility, custom data are a good solution.\r\n\r\n\r\nOne of the main problems is that devices are so isolated that we have no way to automate an acquisition. There is no way to manage all of them in a fully coherent way without relying on some FITS keywords that loosely defined"}}
{"actor":{"display_login":"jconejero"}}