[prev in list] [next in list] [prev in thread] [next in thread]
List: kstars-devel
Subject: Re: Observation workflows in KStars -- looking for feedback and ideas
From: Akarsh Simha <akarshsimha () gmail ! com>
Date: 2020-10-31 22:35:26
Message-ID: CA+9k5ty5Ne9RnQjjGypvyXCTKXPqS=MRHdj47Qha+sGKgXCniA () mail ! gmail ! com
[Download RAW message or body]
Am Sa., 31. Okt. 2020 um 15:31 Uhr schrieb Valentin <valentin@boettcher.cf>:
> Hi,
> Just a quick remark without having read the whole thing yet.
>
> It would be great if the observation log and info wasn't stored in the sky
> object itself, because in the new catalog system it isn't guaranteed that
> there is a unique instance of that object.
>
Very valid point. Should be in a DB associated in some way with a UUID.
> On October 31, 2020 11:16:51 PM GMT+01:00, Akarsh Simha <
> akarshsimha@gmail.com> wrote:
>>
>>
>>
>> Am Sa., 31. Okt. 2020 um 05:30 Uhr schrieb Jasem Mutlaq <
>> mutlaqja@ikarustech.com>:
>>
>>> Hello Akarsh,
>>>
>>
>> Hi Jasem
>>
>> I agree that the observing wizard is due for a revamp! The GUI itself
>>> could reuse some design as well. With one object occupying a single row
>>> that includes all information, including a view for Alt vs Time for EACh
>>> object (so you can compare a few against each other). Furthermore, I think
>>> it should also cater now to astrophotography use. For this to work, I have
>>> a couple of ideas:
>>>
>>
>> I agree that the ability to compare a few objects against each other is
>> cool, but I think having the Alt vs Time in the row will make the rows too
>> big, to the point where you will only be able to display 5--6 objects in a
>> smaller screen. This is not ideal if you want to search for an object by
>> just scanning the list. Instead, I propose that you can select multiple
>> objects, and just like in the actual Alt vs Time tool, the Alt vs Time
>> widget that's in the observation planner should plot multiple traces, one
>> for each object that was selected -- does this serve the purpose instead?
>> I'm a bit surprised we don't already do this...
>>
>>
>>> 1. Filter by Band: Broadband vs Narrow band targets.
>>>
>>
>> This would be extremely useful! But this is somewhat challenging because
>> we don't have a field in KStars that describes whether something is a
>> narrow-band target or not. We could make some guesses by catalog (eg: Sh2,
>> Abell PN), but it's hard because I think we only have one designation in
>> KStars ("Diffuse Nebula") for both emission and reflection nebulae. Any
>> ideas on how to make this happen?
>>
>>
>>> 2. Filter by size: Show objects that fit within say 60% to 120% of the
>>> FOV. So they're not too small or too big to image. Of course, this is only
>>> applicable to extended objects with known angular resolutions.
>>>
>>
>> This is totally doable.
>>
>>
>>>
>>> Also, I think instead of having to use the wizard page-by-page to
>>> produce this, these should always be accessible to filter from. So no more
>>> wizard, but controls to filter ALL the objects. Since we're limited by
>>> memory, we only show the first 100 or so applicable objects by default, and
>>> perhaps this can be increased. So we can have these filters:
>>>
>>
>> I agree. I think this is a major itch to scratch! The step-by-step wizard
>> is a bit too "elaborate" and yet inflexible. I would add the ability to
>> search all objects in KStars (including CatalogComponent), as well as apply
>> the filters only on the existing Wish List (while adding to the Session
>> Plan). This way, for those of us who have targeted wish lists that are
>> getting "too large to manage", we can still filter from the wishlist to
>> plan a given night easily.
>>
>> Also, showing 100 objects "live" might be hard because we'll need to
>> filter a very large database repeatedly. So I think we can use a mechanism
>> similar to the present "Update Count" button, with an "Update List" button
>> that can take 1--2 seconds to process the entire database (since we cannot
>> possibly have an index on every field). The other solution is to have an
>> QTimer to update it whenever the user has not changed the filters for a
>> while. This feature is very easy to bring on top of the wish list, but it's
>> very hard to bring for the entire database, especially if we are going to
>> lazy-load things like PGC galaxies at a later stage (Valentin's merge
>> request).
>>
>> So for this project, I think we should "leave out" the ability to filter
>> the entire database including custom catalogs, but we can readily provide
>> the ability to filter the wishlist as well as the NGC/IC catalogs. I think
>> we should merge Valentin's work before we can do any filter on the entire
>> database.
>>
>>
>>> 1. Type: Stars, Planets, Nebulae..etc
>>> 2. Band: RGB, Narrowband..etc
>>> 3. Size: arcmins steps? maybe have option for "camera FOV" as well which
>>> is auto-calculated from INDI.
>>> 4. Region (Constellation or NSWE)
>>> 5. Magnitude
>>> 6. Altitude
>>> 7. ???
>>>
>>
>> On the FOV subject, we could also allow calculation from FOV symbols (and
>> for the FOV symbols, we have the ability to use various calculations while
>> defining them).
>>
>> If I can add a few more here:
>> 1. Regex on the name (so someone can search a specific catalog from the
>> long name etc.)
>> 2. Does the object transit meridian during the dark part of the night?
>> This is immensely useful as is for visual observers, but it becomes very
>> useful for imagers also if we add one more control -- how many hours before
>> / after meridian is available without twilight/moon. This logic will be
>> hard to code, since we should calculate interference from moon and
>> astronomical twilight, but I think it will be extremely useful and
>> therefore worth it.
>> 3. Has a "Note" associated with it in the "Log" field (less important)
>>
>> This is everything I can think of.
>>
>>
>>> --
>>> Best Regards,
>>> Jasem Mutlaq
>>>
>>>
>>>
>>> On Sat, Oct 31, 2020 at 4:43 AM Akarsh Simha <akarshsimha@gmail.com>
>>> wrote:
>>>
>>>> Hi all,
>>>>
>>>> I'm just trying to get a sense of how people use the Observation
>>>> Planner. A long time ago, the "Observation Planner" was called "Observing
>>>> List" and just carried:
>>>> (a) A list of objects
>>>> (b) Ability to add notes / observation logs
>>>> can't remember what else -- there may have been Alt vs Time
>>>>
>>>> But anyway, in 2009, Prakash Mohan and I worked together as part of
>>>> GSoC to add the DSS image download feature, and the bifurcation between a
>>>> "Session Plan" and a "Wishlist". Back then, my idea was as follows:
>>>> 1. Whenever you come across an object that interests you, add it to
>>>> your Wish List
>>>> 2. Before you go out observing, plan out your observing session by
>>>> importing the objects you wish to see from your wish list into your
>>>> "session plan". KStars automatically assigns the upper meridian transit
>>>> time on the night of observation (I suspect this is currently broken) as
>>>> the observing time for each object.
>>>> 3. Before you go out to a dark place, while you still have fast
>>>> internet access, download any reference images you need from the DSS
>>>> 4. On the observing field, sort the observing session plan by
>>>> observation time. A special sorting filter sorts it from evening to morning.
>>>> 5. Work through your objects in order.
>>>> I have a tendency to pack my night with as many objects as I can
>>>> possibly observe, and I imagined that the above workflow would maximize my
>>>> efficiency.
>>>>
>>>> After trying this out on the field a few times, though, I found it very
>>>> sub-par for visual observing. The reason is, it is difficult to estimate
>>>> correctly how long it takes to observe an object. And the above is not
>>>> robust to, let's say, losing half an hour due to dinner. Moreover, for
>>>> those of us who observe with Dobsonians, sometimes meridian transit is a
>>>> very inconvenient time to observe an object because of the singular motion
>>>> of azimuth around the zenith ("Dobson's Hole" / "the Dob hole").
>>>>
>>>> So I later came up with the following workflow that only involves the
>>>> "Wish List":
>>>> 1. Whenever you come across an object that interests you, add it to
>>>> your Wish List.
>>>> 2. Before you go out to a dark place, while you still have fast
>>>> internet access, download any reference images you need from the DSS
>>>> 3. On the observing field, sort the _wish list_ by % of max. altitude
>>>> achieved at current time, while demoting the objects that are in the hole.
>>>> 4. At any given time, pick your favorites amongst the top 5 or 10
>>>> objects in the sorted list and observe it.
>>>>
>>>> I have found the above wishlist-based workflow exceptional for visual
>>>> observing. So much so that I am tempted to deprecate the session plan
>>>> workflow, but I do think:
>>>> (a) The session plan workflow is much better suited for imaging /
>>>> scientific observations
>>>> (b) There might still be people out there using the session plan
>>>> workflow
>>>> so I do think we should still retain it.
>>>>
>>>> Now, finally, I have a few more itches to scratch with the wishlist
>>>> workflow:
>>>> 1. Wish list grows to unmanageable sizes very quickly.
>>>> 2. There is no easy way of removing/demoting objects that you have
>>>> already observed.
>>>> 3. Plus, unlike with the session plan, there's no scope for targeted
>>>> observing projects -- just one massive wishlist.
>>>>
>>>> I'm looking for other people's "itches" with these workflows, and
>>>> trying to understand how others use the Observation Planner, if at all. I
>>>> remember Jasem telling me it's also integrated somehow with the Ekos
>>>> sequencer, so I'm curious to know how that works. Finally, I'm proposing
>>>> the following changes:
>>>>
>>>> 1. Let the Wish List remain a massive "Wish List"
>>>> 2. Move/replicate the "% of max. altitude" workflow into the session
>>>> plan instead.
>>>> 3. Provide flexible ways of selecting and adding objects from the Wish
>>>> List into the session plan (eg: only objects in a certain constellation,
>>>> only objects in a certain catalog, only objects matching a certain regex,
>>>> only objects that will attain culmination tonight, only objects which are
>>>> above a certain magnitude...)
>>>> 4. Preserve the old workflow of "assigned times" for objects, and fix
>>>> any bugs in it
>>>> 5. Provide an "Observed" checkbox that will demote the object in the "%
>>>> of max. altitude" workflow, if checked.
>>>> 6. Provide a way of removing objects that have already been observed
>>>> from the session plan / wishlist
>>>>
>>>> I believe these features will create a much smoother observation
>>>> experience for anyone interested in using the Observation Planner for
>>>> observing. Now, I don't have enough context on imagers' requirements, but
>>>> if there are any allied requirements, I would be happy to incorporate them
>>>> into a project.
>>>>
>>>> The plan for this project is either I will slowly do it over my
>>>> weekends and evenings, or work with a GSoC / SoK student to achieve these
>>>> goals. Anyone else interested is also welcome.
>>>>
>>>> Regards
>>>> Akarsh
>>>>
>>>>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>
[Attachment #3 (text/html)]
<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div \
dir="ltr" class="gmail_attr">Am Sa., 31. Okt. 2020 um 15:31 Uhr schrieb \
Valentin <<a href="mailto:valentin@boettcher.cf">valentin@boettcher.cf</a>>:<br></div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"><div>Hi, <br>Just a quick remark without \
having read the whole thing yet.<br><br>It would be great if the \
observation log and info wasn't stored in the sky object itself, \
because in the new catalog system it isn't guaranteed that there is a \
unique instance of that \
object.<br></div></blockquote><div><br></div><div>Very valid point. Should \
be in a DB associated in some way with a UUID.<br></div><div> \
<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"><div><br><div class="gmail_quote">On \
October 31, 2020 11:16:51 PM GMT+01:00, Akarsh Simha <<a \
href="mailto:akarshsimha@gmail.com" \
target="_blank">akarshsimha@gmail.com</a>> wrote:<blockquote \
class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"> <div dir="ltr"><div \
dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" \
class="gmail_attr">Am Sa., 31. Okt. 2020 um 05:30 Uhr schrieb Jasem Mutlaq \
<<a href="mailto:mutlaqja@ikarustech.com" \
target="_blank">mutlaqja@ikarustech.com</a>>:<br></div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hello \
Akarsh,</div></blockquote><div><br></div><div>Hi Jasem</div><div> \
<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div \
dir="ltr"><div>I agree that the observing wizard is due for a revamp! The \
GUI itself could reuse some design as well. With one object occupying a \
single row that includes all information, including a view for Alt vs Time \
for EACh object (so you can compare a few against each other). Furthermore, \
I think it should also cater now to astrophotography use. For this to work, \
I have a couple of ideas:</div></div></blockquote><div><br></div><div>I \
agree that the ability to compare a few objects against each other is cool, \
but I think having the Alt vs Time in the row will make the rows too big, \
to the point where you will only be able to display 5--6 objects in a \
smaller screen. This is not ideal if you want to search for an object by \
just scanning the list. Instead, I propose that you can select multiple \
objects, and just like in the actual Alt vs Time tool, the Alt vs Time \
widget that's in the observation planner should plot multiple traces, \
one for each object that was selected -- does this serve the purpose \
instead? I'm a bit surprised we don't already do \
this...<br></div><div> </div><blockquote class="gmail_quote" \
style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>1. Filter by Band: \
Broadband vs Narrow band \
targets.</div></div></blockquote><div><br></div><div>This would be \
extremely useful! But this is somewhat challenging because we don't \
have a field in KStars that describes whether something is a narrow-band \
target or not. We could make some guesses by catalog (eg: Sh2, Abell PN), \
but it's hard because I think we only have one designation in KStars \
("Diffuse Nebula") for both emission and reflection nebulae. Any \
ideas on how to make this happen?<br></div><div> </div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>2. Filter by size: \
Show objects that fit within say 60% to 120% of the FOV. So they're not \
too small or too big to image. Of course, this is only applicable to \
extended objects with known angular \
resolutions.</div></div></blockquote><div><br></div><div>This is totally \
doable.<br></div><div> </div><blockquote class="gmail_quote" \
style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>Also, \
I think instead of having to use the wizard page-by-page to produce this, \
these should always be accessible to filter from. So no more wizard, but \
controls to filter ALL the objects. Since we're limited by memory, we \
only show the first 100 or so applicable objects by default, and perhaps \
this can be increased. So we can have these \
filters:</div></div></blockquote><div><br></div><div>I agree. I think this \
is a major itch to scratch! The step-by-step wizard is a bit too \
"elaborate" and yet inflexible. I would add the ability to search \
all objects in KStars (including CatalogComponent), as well as apply the \
filters only on the existing Wish List (while adding to the Session Plan). \
This way, for those of us who have targeted wish lists that are getting \
"too large to manage", we can still filter from the wishlist to \
plan a given night easily.</div><div><br></div><div>Also, showing 100 \
objects "live" might be hard because we'll need to filter a \
very large database repeatedly. So I think we can use a mechanism similar \
to the present "Update Count" button, with an "Update \
List" button that can take 1--2 seconds to process the entire database \
(since we cannot possibly have an index on every field). The other solution \
is to have an QTimer to update it whenever the user has not changed the \
filters for a while. This feature is very easy to bring on top of the wish \
list, but it's very hard to bring for the entire database, especially \
if we are going to lazy-load things like PGC galaxies at a later stage \
(Valentin's merge request).</div><div><br></div><div>So for this \
project, I think we should "leave out" the ability to filter the \
entire database including custom catalogs, but we can readily provide the \
ability to filter the wishlist as well as the NGC/IC catalogs. I think we \
should merge Valentin's work before we can do any filter on the entire \
database.<br></div><div> </div><blockquote class="gmail_quote" \
style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>1. Type: Stars, \
Planets, Nebulae..etc</div><div>2. Band: RGB, Narrowband..etc</div><div>3. \
Size: arcmins steps? maybe have option for "camera FOV" as well \
which is auto-calculated from INDI.</div><div>4. Region (Constellation or \
NSWE)</div><div>5. Magnitude</div><div>6. Altitude</div><div>7. \
???</div></div></blockquote><div><br></div><div>On the FOV subject, we \
could also allow calculation from FOV symbols (and for the FOV symbols, we \
have the ability to use various calculations while defining \
them).<br></div><div><br></div><div>If I can add a few more here:</div>1. \
Regex on the name (so someone can search a specific catalog from the long \
name etc.)<div>2. Does the object transit meridian during the dark part of \
the night? This is immensely useful as is for visual observers, but it \
becomes very useful for imagers also if we add one more control -- how many \
hours before / after meridian is available without twilight/moon. This \
logic will be hard to code, since we should calculate interference from \
moon and astronomical twilight, but I think it will be extremely useful and \
therefore worth it.</div><div>3. Has a "Note" associated with it \
in the "Log" field (less \
important)<br></div><div><br></div><div>This is everything I can think \
of.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px \
0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div \
dir="ltr"><div></div><div><div><div dir="ltr"><div dir="ltr"><div><div \
dir="ltr"><div>--</div><div>Best Regards,<br>Jasem \
Mutlaq<br></div><div><br></div></div></div></div></div></div><br></div></div><br><div \
class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Oct 31, 2020 \
at 4:43 AM Akarsh Simha <<a href="mailto:akarshsimha@gmail.com" \
target="_blank">akarshsimha@gmail.com</a>> wrote:<br></div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi \
all,</div><div><br></div><div>I'm just trying to get a sense of how \
people use the Observation Planner. A long time ago, the "Observation \
Planner" was called "Observing List" and just \
carried:</div><div>(a) A list of objects</div><div>(b) Ability to add notes \
/ observation logs</div><div>can't remember what else -- there may have \
been Alt vs Time<br><br></div><div>But anyway, in 2009, Prakash Mohan and I \
worked together as part of GSoC to add the DSS image download feature, and \
the bifurcation between a "Session Plan" and a \
"Wishlist". Back then, my idea was as follows:</div><div>1. \
Whenever you come across an object that interests you, add it to your Wish \
List</div><div>2. Before you go out observing, plan out your observing \
session by importing the objects you wish to see from your wish list into \
your "session plan". KStars automatically assigns the upper \
meridian transit time on the night of observation (I suspect this is \
currently broken) as the observing time for each object.</div><div>3. \
Before you go out to a dark place, while you still have fast internet \
access, download any reference images you need from the DSS</div><div>4. On \
the observing field, sort the observing session plan by observation time. A \
special sorting filter sorts it from evening to morning.</div><div>5. Work \
through your objects in order.</div><div> I have a tendency to pack my \
night with as many objects as I can possibly observe, and I imagined that \
the above workflow would maximize my \
efficiency.<br></div><div><br></div><div>After trying this out on the field \
a few times, though, I found it very sub-par for visual observing. The \
reason is, it is difficult to estimate correctly how long it takes to \
observe an object. And the above is not robust to, let's say, losing \
half an hour due to dinner. Moreover, for those of us who observe with \
Dobsonians, sometimes meridian transit is a very inconvenient time to \
observe an object because of the singular motion of azimuth around the \
zenith ("Dobson's Hole" / "the Dob \
hole").<br></div><div><br></div><div>So I later came up with the \
following workflow that only involves the "Wish \
List":<br></div><div>1. Whenever you come across an object that \
interests you, add it to your Wish List.</div><div>2. Before you go out to \
a dark place, while you still have fast internet access, download any \
reference images you need from the DSS</div><div>3. On the observing field, \
sort the _wish list_ by % of max. altitude achieved at current time, while \
demoting the objects that are in the hole.</div><div>4. At any given time, \
pick your favorites amongst the top 5 or 10 objects in the sorted list and \
observe it.</div><div><br></div><div>I have found the above wishlist-based \
workflow exceptional for visual observing. So much so that I am tempted to \
deprecate the session plan workflow, but I do think:</div><div>(a) The \
session plan workflow is much better suited for imaging / scientific \
observations</div><div>(b) There might still be people out there using the \
session plan workflow</div><div>so I do think we should still retain \
it.</div><div><br></div><div>Now, finally, I have a few more itches to \
scratch with the wishlist workflow:</div><div>1. Wish list grows to \
unmanageable sizes very quickly.</div><div>2. There is no easy way of \
removing/demoting objects that you have already observed.</div><div>3. \
Plus, unlike with the session plan, there's no scope for targeted \
observing projects -- just one massive \
wishlist.</div><div><br></div><div>I'm looking for other people's \
"itches" with these workflows, and trying to understand how \
others use the Observation Planner, if at all. I remember Jasem telling me \
it's also integrated somehow with the Ekos sequencer, so I'm \
curious to know how that works. Finally, I'm proposing the following \
changes:<br><br></div><div>1. Let the Wish List remain a massive "Wish \
List"<br></div><div>2. Move/replicate the "% of max. \
altitude" workflow into the session plan instead.<br></div><div>3. \
Provide flexible ways of selecting and adding objects from the Wish List \
into the session plan (eg: only objects in a certain constellation, only \
objects in a certain catalog, only objects matching a certain regex, only \
objects that will attain culmination tonight, only objects which are above \
a certain magnitude...)</div><div>4. Preserve the old workflow of \
"assigned times" for objects, and fix any bugs in it</div><div>5. \
Provide an "Observed" checkbox that will demote the object in the \
"% of max. altitude" workflow, if checked.</div><div>6. Provide a \
way of removing objects that have already been observed from the session \
plan / wishlist</div><div><br></div><div>I believe these features will \
create a much smoother observation experience for anyone interested in \
using the Observation Planner for observing. Now, I don't have enough \
context on imagers' requirements, but if there are any allied \
requirements, I would be happy to incorporate them into a \
project.</div><div><br></div><div>The plan for this project is either I \
will slowly do it over my weekends and evenings, or work with a GSoC / SoK \
student to achieve these goals. Anyone else interested is also \
welcome.<br></div><div><br></div><div>Regards</div><div>Akarsh<br></div><div><br></div></div>
</blockquote></div>
</blockquote></div></div>
</blockquote></div><br>-- <br>Sent from my Android device with K-9 Mail. \
Please excuse my brevity.</div></blockquote></div></div>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic