[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: Valentin <valentin () boettcher ! cf>
Date: 2020-10-31 22:30:57
Message-ID: 05963261-2A56-448F-BC3A-D69F6D554E43 () boettcher ! cf
[Download RAW message or body]
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.
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)]
<html><head></head><body>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><br><div \
class="gmail_quote">On October 31, 2020 11:16:51 PM GMT+01:00, Akarsh Simha <akarshsimha@gmail.com> \
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">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.</body></html>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic