Artificial Horizon

[Hy Murveit]

I worked on this and came up with a solution I like, that I've put in MR 263
https://invent.kde.org/education/kstars/-/merge_requests/263

The scheduler integration was straightforward...basically this is the same
as the min-altitude constraints that already work fine. It's just that the
scheduler needs to pass the azimuth it's considering as well into a method
I created that computes the altitude constraint for the given azimuth.

I modified the Artificial Horizon UI and feature (with Jasem's blessing).
It now does not represent polygons at all, but rather a sequence of points
defining line segments in azimuth/altitude coordinates (above it in
altitude is clear, below is obstructed). If there are multiple lines, use
the highest. Entering the points for the line segments is easy...you can
enter the points by clicking on the skymap--easy, that is, if you've also
created a terrain backgound for your location (my previous MR) so that it's
obvious where the obstructions are.

I'd like to add some unit testing, but other than that, seems to work.
Testing tonight with my telescope -- gave it some targets with the
obstruction issues, and the scheduler seems to be figuring things out.

Check it out, and let me know what you think.
Hy

PS That new feature to append scheduler jobs came in handy. Hadn't used it
before. Eric--Thanks for that!

On Thu, Mar 25, 2021 at 1:31 AM Eric Dejouhanet <eric.dejouhanet at gmail.com>
wrote:

> There are several ways to improve AH:
>
> - import/export mechanisms, instead of asking the end-user to work with
> sql.
> - edit mode :) the safest way to edit AH is currently entering coordinates
> by hand instead of clicking. This is mostly similar to creating an horizon
> in the eqmod driver, except the end point must be the same as the beginning
> point.
> - proper inside/outside rendering of regions, as you noticed.
> - automatic generation of horizon by making a tool count stars on frames
> taken at grid coordinates.
> - having obstructed regions in the sky instead of horizon obstruction,as
> you mentioned.
> - obstruction restrictions for the Scheduler, which conflicts with the
> current design of the plan: observations are currently expected to be able
> to start at some time of one standard day and to have to finish at some
> time during that day, after which those tasks either complete or abort. No
> provision for tasks that may be able to start, stop then restart at some
> other time before other tasks have even started. This requires a more
> dynamic scheduling, whose first step is to allow user modification of the
> plan while Scheduler is running.
>
> eric.dejouhanet at gmail.com - https://astronomy.dejouha.net
> *De:* murveit at gmail.com
> *Envoyé:* 25 mars 2021 07:23
> *À:* eric.dejouhanet at gmail.com
> *Répondre à:* hy at murveit.com
> *Cc:* hy at murveit.com; kstars-devel at kde.org
> *Objet:* Re: Artificial Horizon
>
> Sorry, don't understand your last line--What is #7?
>
> Also, why would people make scripts when nothing makes use of it? Do users
> find enough added value just marking up the sky? (I'm new to this and don't
> really understand it's current value--happy to be educated. I'm really just
> using my imaging point-of-view).
>
> FWIW, I played with it this evening, and found editing regions buggy. For
> instance, if you define two regions, and then delete one of them, the one
> you didn't delete loses its last point and becomes "not closed".
>
> When defining the polygons, it's necessary to be very exact when clicking
> the last point (it needs to exactly match the first one). I'd like to be
> simpler--e.g. the system could easily close the polygon itself.
>
> Don't think we shoudl constrain the polygons to start (and end) on the
> horizon--the instructions say one needs to do this. For instance, my
> telescope's "horizon" never touches the real horizon at any azimuth.
>
> The UI, though, with the addition of Terrain makes it straight-forward to
> define a horizon. If the buggy-ness, and the issues with what's inside the
> polygon and what's outside it were resolved, this could be a reasonable
> thing to integrate with the scheduler.
>
> Hy
>
>
> On Wed, Mar 24, 2021 at 11:00 PM Eric Dejouhanet <
> eric.dejouhanet at gmail.com> wrote:
>
>> I don't think any other feature is using AH. It is slightly tedious to
>> create and to edit. Some forum users created database scripts to generate
>> it. #7 is registered in gitlab to make use of it in Scheduler.
>>
>> eric.dejouhanet at gmail.com - https://astronomy.dejouha.net
>> *De:* murveit at gmail.com
>> *Envoyé:* 24 mars 2021 22:50
>> *À:* eric.dejouhanet at gmail.com
>> *Répondre à:* hy at murveit.com
>> *Cc:* kstars-devel at kde.org
>> *Objet:* Re: Artificial Horizon
>>
>> Thanks. I'll take a look at rendering, or perhaps add an "invert" option,
>> if I can't improve the logic.
>> Does anything outside of the skymap use the artificial horizon?
>>
>> On Wed, Mar 24, 2021 at 2:39 PM Eric Dejouhanet <
>> eric.dejouhanet at gmail.com> wrote:
>>
>>> 1. For various reasons, your horizon may be rendered "from the outside".
>>> That's why you don't want to do a single 360 polygon.
>>>
>>> 5. Scheduler does not make use of AH. It's been in my pipe for some
>>> time, but it's trickier than it seems. The first step would be to have two
>>> altitude restrictions, one for setting objects (the current one we have)
>>> and one for rising objects.
>>>
>>> eric.dejouhanet at gmail.com - https://astronomy.dejouha.net
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kstars-devel/attachments/20210331/d0a8d05c/attachment.htm>