-
Notifications
You must be signed in to change notification settings - Fork 50
Added view to enable target selection for manual observing runs #840
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: dev
Are you sure you want to change the base?
Conversation
jchate6
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've made some specific comments, that I think are important, but I have some general comments that I think will require a larger discussion.
Specifically, I'd like to talk about what you are actually looking to accomplish here. This returns a selection of targets in a list that have an airmass < 2.0 within a specific 24 hour window with 10 steps starting at YYYY-MM-DDT00:00:00 for a list of telescopes at a specific observatory. That feels like a highly specific use case that should probably be made more generalized. Users might want to change the limiting airmass, or see all of the telescopes at once, or set up their window so it encompasses a full night at CPT rather than splitting it.
Additionally, I feel like the information returned is limiting. This doesn't tell a user WHEN the target will be at it's lowest airmass, or sort them in any way or give a user an idea of how long the target will be up. Also, this is completely incompatible with non-sidereal targets.
Ultimately I'm wondering if this whole idea makes more sense being incorporated into the target list view. An airmass filter could possibly be added, and "observation planning" columns could be put on the table.
Would love to discuss further when you have time.
tom_targets/templates/tom_targets/target_facility_selection.html
Outdated
Show resolved
Hide resolved
|
I've implemented all of the changes requested above. I take your point about the potential for more generalized functionality for this view but I think it makes sense to implement this version first before trying to generalize. |
jchate6
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A few things.
Mostly small. Let me know if you want to talk about the general facility module.
tom_targets/templates/tom_targets/target_facility_selection.html
Outdated
Show resolved
Hide resolved
| :alt: Target Selection table with additional columns added | ||
|
|
||
|
|
||
| Adding An Observing Facility to the Target Selection Form |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I really don't like this section.
We really don't want people making orphaned facilities in this way.
I think we can add the basics for a DB driven general facility in a sprint.
I would recommend cutting this section and prioritizing that work in the upcoming sprint. It would be a much more sustainable way to do this, and will be necessary in the long run.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've removed this section, pending the other issue to add a General Facility model.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Having now implemented the General Facility model, and integrated it with the target selection form, I've updated this section of the documentation accordingly.
|
Ideally I'd like this view to present the form, plus a paginated list of results when available, but this involves combining both a FormView to handle the POST and a ListView to handle the pagination. Pushing a partial refactor with most of the comments completed in order to get advice on the best way forward. |
… so as to cap the number of visibility calculations that can take place at a given time.
|
I've refactored the FormView to implement pagination on the list of targets, and updated the get and post methods so that pagination works as intended in the template. |
…ture/facility_target_selection
…calculation handling
|
I've integrated the new general facilities model with this form for calculating target visibilities from different observatories. The easiest way to handle this was to do some refactoring of the tom_observations.utils.get_sidereal_visibility function. |
jchate6
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've pointed out a few broken or problematic changes. I haven't really gotten back into the actual utility of the feature. It seems like there is some pagination issue, but I can't really tell if that's just a symptom of other problems.
| return redirect(reverse('tom_targets:list') + '?' + query_string) | ||
|
|
||
|
|
||
| class TargetGroupingView(PermissionListMixin, ListView): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm confused by this change.
This will break. There is no form included in the context.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This class has a FormView rather than a ListView.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't understand what you mean.
A FormView requires a form, and will try to return a form class.
This view has no form. So you will get a TypeError if you try to load this page.
…idereal_visibility function
…ture/facility_target_selection
jchate6
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry to go another round, but I think this is looking much better!
Let me know if you have any questions.
| return redirect(reverse('tom_targets:list') + '?' + query_string) | ||
|
|
||
|
|
||
| class TargetGroupingView(PermissionListMixin, ListView): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't understand what you mean.
A FormView requires a form, and will try to return a form class.
This view has no form. So you will get a TypeError if you try to load this page.
| visibiliy_intervals, airmass_max, | ||
| observation_facility=request.POST.get('observatory') | ||
| ) | ||
| for site, vis_data in visibility_data.items(): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| <th>{{col}}</th> | ||
| {% endfor %} | ||
| </tr> | ||
| {% if target_visibilities|length > 0 %} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This doesn't make sense to be in the template after the pagination.
The pagination is happening in views, so the whole target list is being paginated, but only the visible targets are being displayed. This leads to many empty pages. Instead we should paginate the list of visible targets, removing the non-visible targets in views around line 960.
| form_class = TargetSelectionForm | ||
| observable_targets = [] | ||
|
|
||
| def get_context_data(self, *args, **kwargs): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We probably want to keep the form data after submitting, so it's still in the form above the table. To do this, we need to add the results of request.POST to the context data.
change this to get_context_data(self, request, *args, **kwargs):
and see other changes below.
|
|
||
| context = super().get_context_data(*args, **kwargs) | ||
| # Surely this needs to verify that the user has permission? | ||
| context['form'] = TargetSelectionForm() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
change this to context['form'] = TargetSelectionForm(request.POST or None)
To pass the form results from a post back into the form.
| telescope at the target, but it can be easily extended to add further information. | ||
|
|
||
| The columns of the table can be configured by editing the TOM's ``settings.py`` file. | ||
| Additional parameters can be defined for each target by adding dictionary definitions |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems confusing to me. I think we should separate the EXTRA_FIELDS conversation from the SELECTION_EXTRA_FIELDS description.
Instead, let's link them to docs/targets/target_fields.rst where they can learn how to add other fields, and then tell them how to use SELECTION_EXTRA_FIELDS
|
|
||
| # Extract any requested extra parameters for this object, if available | ||
| for param in getattr(settings, 'SELECTION_EXTRA_FIELDS', []): | ||
| if param in target.extra_fields.keys(): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should also look for fields in the Target Model itself, not just target extras.
People will be adding custom Target models for exactly this purpose.
| .. image:: target_selection_table_extra_fields.png | ||
| :alt: Target Selection table with additional columns added | ||
|
|
||
| .. code:: python |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this section sill relevant? At the very least it feels non-sequitur
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should probably all be included in or a reference to docs/observing/observation_module.rst
| This page can be reached by adding ``/admin/`` to the end of the TOM's root URL in your browser's navigation bar, e.g.: | ||
|
|
||
| .. code-block:: html | ||
| > https://demo.lco.global/admin/ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Needs a blank line and an indent.
| .. code-block:: html | ||
| > https://demo.lco.global/admin/ | ||
|
|
||
| Scrolling down the list of database tables, you will find ``Facilitys`` under the tables from the ``tom_observations`` app. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oof, no, let's fix this.
go to tom_observations.models.py
inside Facility immediately after you define the model parameters, add
class Meta:
verbose_name_plural = "facilities"

This feature aims to improve the TOM's useability for observers operating more traditional, block-scheduled observing facilities, often manually or through remote operations. The feature provides a form and view to enable them to easily identify targets visible at their facility on the date indicated.