Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Answered: How to "associate" objects (not a feature at this time)
#1
Thumbs Up 
Just purchased SkyTools 4 Pro today. I'm liking it a lot so far. I have marked quick observations for several catalogs. Is there a way to see the total objects I've observed across all lists?

Also, how might I associate a group of targets together? For example, something like a galaxy cluster in the same field of view. Can it be done?


For what it's worth, I entered the entire O'Meara Secret Deep list. If it would be helpful to share it as a list, how do I upload it so others can grab it?

Thanks for all the fine work that has gone into this application. It was super-quick to enter targets tonight.

Doug

PS. Here's a screen shot from Astroplanner, demonstrating the way it shows the total observations in the top bar - and the way it "associates" objects in a list (attached).


Attached Files Thumbnail(s)
   
Reply
#2
Hello Doug,

"Is there a way to see the total objects I've observed across all lists?" The answer depends on how your are marking objects that you have observed. There are two ways to do that:

1. Create a log entry. This is the main way to track observations. Its designed to be very quick and simple and you don't need to enter a text description if you don't wish to. The easiest way to create a log entry is via a right-click in your observing list. You can also do it elsewhere, including by right-clicking on an object on a chart. What I do is to write my notes on the SkyTools Finder Chart and then sit down and enter them later. There is a multiple log entry tool that makes this very quick.

One you have logs in the system there are a lot of ways to track them. You can see how many logs you have entered for a given night, or class of object, or in a given constellation, etc. via the Log Browser. To see how many in total, use the Search tab. Select All for each type of search and you will see all logs listed with the total.

As far as associated objects, that not something I really thought much about and nobody has suggested it before. I'm not sure how that would work in SkyTools, but I'll think about it. I think you likely observed the nearby targets on the same night, so see all the logs for that night will go a long way in doing what you want.

2. The simplistic way to keep track of observations is via the Observing Status column on the Nightly Planner. But this is meant only to track which objects you have observed from that list, and is not connected to other lists, by design.
Clear skies,
Greg
Head Dude at Skyhound
Reply
#3
That helps a lot! Thank you!
Associated objects: No problem. It can come in handy when a particular catalog lists objects in "sets" - like galaxy clusters, for example, but it's no big deal. Thanks Greg.
Reply
#4
From the beginning I've wanted a "secondary object" feature, essentially the same as your "associated object".  Greg, I think you absolutely need to support this when you get around to supporting EAA.  For example, if one observes M51 he is almost certainly also observing NGC5195 at the same time.  When browsing logs, you want NGC 5195 to show up as observed, sharing a log item with M51.
Reply
#5
I see your point, Howard. And just as importantly, some observers might want to "link" several objects together when they link together in the same field of view. For example, an observer might want a way to link M31 with M32 and M110. Or what if we wanted to link M84, M86, NGC 4477, NGC 4473, NGC 4461, NGC 4458, NGC 4438 and NGC 4435. Just seeing those objects listed like that, maybe a new observer might not see any correlation. But if an observer could somehow associate them together and mark any of them with the name (any guesses? : ) ), Markarian's Chain, now they instantly have meaning. It's the association together in a field of view that makes them special.
Reply
#6
(2024-01-23, 02:22 AM)howardgrams Wrote: From the beginning I've wanted a "secondary object" feature, essentially the same as your "associated object".  Greg, I think you absolutely need to support this when you get around to supporting EAA.  For example, if one observes M51 he is almost certainly also observing NGC5195 at the same time.  When browsing logs, you want NGC 5195 to show up as observed, sharing a log item with M51.

Right now my brain sort of hurts trying to see how one would actually do that, however. I mean, where do they show up as connected, and how?
Clear skies,
Greg
Head Dude at Skyhound
Reply
#7
(2024-01-24, 05:35 PM)theskyhound Wrote:
(2024-01-23, 02:22 AM)howardgrams Wrote: From the beginning I've wanted a "secondary object" feature, essentially the same as your "associated object".  Greg, I think you absolutely need to support this when you get around to supporting EAA.  For example, if one observes M51 he is almost certainly also observing NGC5195 at the same time.  When browsing logs, you want NGC 5195 to show up as observed, sharing a log item with M51.

Right now my brain sort of hurts trying to see how one would actually do that, however. I mean, where do they should up as connected, and how?

hahahaha. Well we don't want to make your brain hurt, Greg.
Trying to think like you program. What if you gave the user one more tiny column - like a checkbox-sized column - but allowed the user to pick a color or a pattern to put in that checkbox. For ungrouped object, the column would be empty. But for *grouped* objects, the user would pick a common color or pattern. So then, if the user could *sort* by that column, at least the groupings would be revealed instantly. Giving us the ability to do a sort on 3 levels would let us pick that column and then two others - like the "Brief Note" field or the primary designation. Just an idea that doesn't sound outside the way you've normally programmed in the rest of SkyTools. Thanks for hearing the idea, Greg!
Reply
#8
Thinking in terms of traditional database organization, I envision the observation log containing an observation table whose entries contain information about a specific observation. It would have one foreign key pointing to a nights table. There would be an objects table that has a many-to-many relationship with the observation table utilizing a junction table. (In similar fashion, many-to-many relationships would exist connecting the objects table to observing lists.)
When an observation is created, the user would specify one or more objects to be included with (i.e linked to) that observation.
When displaying an observing list containing one or both of e.g. M51 and NGC5195, then right clicking on either to get information would ultimately display the corresponding log entries which would note secondary/associated objects.
And crucially, when displaying an Observing List in the Nightly Planner and Real Time Observing panels the Observation Status column would show observed/not-observed status for both M51 and NGC5195 in my example.
Reply
#9
Wow - that's awesome, @Howardgrams!
Reply
#10
So, just thinking out loud here... Why do we want that info on an observing list on the Nightly Planner? The purpose of the NP is to determine which objects to observe on a particular night and then when the best time is to observe each of them. Its not a spreadsheet, even though you can see that I lost that argument a few times over the years... as long as I can see how it can work in step with the primary purpose then I have gone ahead and added more of that side stuff.

But... why couldn't the Log Browser perform the same function? Or maybe the Object Info? The Nightly Planner is just one tool of many: the very most fundamental thing about SkyTools is to choose the right tool for the job rather than try to use one tool to do everything. That's why there is more than one chart, for example. Yet people who never used anything but the atlas, have demanded I put an eyepiece FOV on it (which I only did because it could serve another purpose as well) and then there are other people who ask me to put the features of the atlas (which they never tried) into the finder chart. But I digress.

When people ask me how to ask for features I always tell them the same thing: never tell me how you imagine something should work. That will only end in frustration for both of us. Instead, it is much more useful for me to understand the problem you are trying to solve or the goal you are trying to achieve. Give me that. Let me come up with the best solution. Right now, I don't understand why you need this information. That is my true sticking point. Tell me that. I already know how to program databases.

So I like to start with this:

What is the purpose of the feature? I mean, really, what is its primary purpose? Why do different objects need to be tied together in a more or less arbitrary fashion? How is that connection employed usefully and to what end?

Examples are great, but not of how you want it to work. Tell me what you are trying to accomplish in some detail. To play devils advocate, I can look at this and think, why not have separate logs for each object in the same field of view? After all, if they were observed together its an easy matter to make two log entries (using the context capabilities of the logging), with the bonus that they can have separate descriptions. What purpose does it serve to link them, especially since they are already linked by the night they were observed on?
Clear skies,
Greg
Head Dude at Skyhound
Reply


Forum Jump:


Users browsing this thread: 2 Guest(s)