2024-01-24, 09:53 PM
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.
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.