Navstars improvements #955
Conversation
|
I got this problem:
Please fix order of variables and remove extra NavStars:: in headers file. |
There was a problem hiding this comment.
You are added few additional fields:
GHAa : The Greenwich Hour Angle for the first point of Aries
LMST : Local mean sidereal time
SHA : Sidereal hour angle of the target object
DEC : The declination of the target object
GHA : The Green Hour Angle of the target object
LHA : The Local Hour Angle of the target object
LAT : The observer latitude
LON : The observer longitude
Hc : The computed altitude as derived via a Sight Reduction (solution)
Zn : The computed azimuth as derived via a Sight Reduction (solution)
and I think for many newbies will be very helpful if you added short description of each field in About tab of plugin.
Plus I have a 2 questions:
-
You are calculate and show declination of target object, but RA/Dec already exists for each object. Is it really necessary to add an additional Dec field?
-
You are show geodetic coordinates as separate 2 fields. These coordinates already available as tooltip data for location string, but I guess you need it to simplificate of some the navigation tasks. Why you just do not join both coordinates in one line - for example "Geodetic coordinates: N53.55 W33.89"?
|
I assume it's just the labels from the tables which navigators are so used to. LMST is also already available without the plugin. (No, I don't want to allow re-labeling by arbitrary plugins...) But "LON/LAT" and "Zn/Hn" with two coord values each could be an option to save two lines. |
|
@gzotti thanks for notification! I've forgot about Stellarium User Guide. |
|
Thank you for the feedback.
As for your questions. I was aware that some information is repeated. However, having discussed how Stellarium could be used by Celestial Nav teachers the first thing to note was "getting all this data into a viewable form is too complicated for most students, please display it in a form that's together and in a format that students will be using, whole degrees and decimal (one place) minutes. This format must be consistent for all display values, it's all they will ever use. Please make it so that all other data, except the name, can be switched off and the Nav Data is just shown. The data must include the Ho altitude (apparent Alt) for the current position, Nautical Almanac table inputs (UTC and Ho), table intermediate outputs (GP, which is GHA/DEC) and what that final sight reduction solution should be assuming they followed the Almanac sight reduction procedure correctly (that's Hc/Zn)". So, that above was my guide to how I presented the information. However, I will adjust so that coord pairs (lat/lon ie AP, gha/dec ie GP, Hc/Zn Almanac computed alt/az) are paired on a single line. I will also update the user guide to reflect the above. For example, when teaching the celestial object sub-point is important and is called GP (ground point). However, when using the Almanac and following sight reduction, we find GHA and DEC of the target which is the GP. But "GP" doesn't appear in the procedure, only GHA and DEC do. GP is just part of the teaching process to understand what is actually going on. @alex-w @gzotti Please let me know what you think here with regards to the above "requirement" I was trying to achieve. |
|
OK, thanks for explanations of the "external requirements". I did not know about GP, is that the location where the object is in the zenith? Indeed, some basics on CelNav in the Guide would help clarifying the displayed values. Maybe even a label "GP: GHA/DEC=" would be helpful? |
Yes.
Indeed. I will add information to the user guide that's an introduction to CN and how Stellarium can be used to assist learning.
I will do that. I can also add a script that initializes the display. In fact, I added some in my PR that allows me to set up Stellarium to run the test cases where I manually reduced using the Almanac to check the numbers. It's also what I based the Unit tests on, a manual reduction. With regards to the pairing of values such as gha/dec, alt/az, etc. I just spoke with one of my advisors and this was telling... "the problem is most CN students are not astronomers, they are sailors. Whilst astronomers are more than accustomed to coord pairs such as alt/az, CN students work with tables of data. That's why I like the tabulated form I see now. It's how it looks on paper and how they'll actually write it down in their logbooks. It's also how we expect to see it on exam papers. We aren't teaching astronomy but CN". So, I'm a bit at a loss here on the correct display. I could certainly make it configurable to either see paired coords or tabulated. Your thoughts? |
|
Hm, a config option "compact/separate" would of course be extra comfortable, to add the data without taking too many lines for "regular" ("somewhat interested astronomers") users. |
OK, I will add the ability to allow the user to configure how they want the data to be displayed. That's not a big issue. I will default to "astronomer view", ie paired coords as it is how most Stellarium users will expect. Are we ok with the duplication of data fields? Or should in "paired display view" omit duped fields? I will start work on the User Guide shortly. LaTex is a learning curve for me. I expect writing the guide will take longer than the code took to write :) I also need my contribution to the guide to be proofread for grammar and accuracy by others. Luckily I have access to people who can assist me in that. However, this will all take some extra time. |
|
About "astronomer view": Maybe even an extra opt to "omit duplicates" that does not display LON/LAT and Zn/Hn. That may invite a combo box selection, but I don't know what looks best. LaTeX: Maybe it's difficult to start a new project. However I hope it's not very difficult (conceptually it is approximately as difficult as HTML, just a decade older) to follow examples and add a few \section{...}, and else it's all set up to "make pdf" on the command line. Please see the README in the folder. |
|
Here are two screen grabs of the display. Which is used is as determined by the user in the config system. If you are happy with this I'll commit this code and move onto extending the About text to provide extra info. Once we are all settled on the UI section I will begin on the User Guide. Default View:- Tabulated view (selectable by config, not the default out of the box view) |
|
I think in the first screen the tags should also be capitalized (like in the Almanac). Else, from my side yes please proceed. |
|
@gzotti I also noticed GHA doesn't have the leading + sign. I have added that (handling sign is an important part of the sight reduction process and should always be specified, even if the value is always positive). I will capitalize as you suggest. |
I decided that SHA was important enough to add to this view. Screengrab added for reference.
|
… cases are different
|
D'oh, I broke it. Fix coming. |
|
I've found warning also:
|
@axd1967 Are you building in Release mode or Debug mode? I have found there seems to be a problem in Qt5 libs/headers that causes a core dump/crash when running in Debug mode. I have a workaround but it's not pretty. I really need to isolate the actual cause and figure a proper solution. (edit: the problem appears to be with QMultiMap iterators) |
They can't. Be happy if they are within 0.33' now, and when we drop the 0 after the aberration fix, we should be within (hopefully) 2''. |
|
What does the "Only highlight when visible" do? |
|
With Stellarium today the highlight circles are drawn around the Nav stars all the time. This includes during the daytime when the star it is highlighting is not visible. Checking this box will only draw the highlight circle if the star is visible in the sky. So, as dawn approaches are stars start to appear, Nav stars are highlighted at that point and not permanently stuck on. I will add tooltips. |
|
Ah, now I see it. Good feature, thanks! Tooltips will certainly help. |
|
Within the last days I had the opportunity to take a deeper look into your code. I still like it but now I have some comments and questions: You are going to supply the computed altitude of the selected celestial object, cf. Ho in NavStar plugin window. If Ho is indeed the computed observed altitude and azimuth as a solution of Sight Reduction, I cannot see where to define the height of the observer over the sea level. This could be done in the NavStars plugin window. Also I expected the horizontal parallax HP (for Moon or Planets) and the semi-diameter R (for Moon or Sun) in the main window for the selected object. In addition to that I miss the current time and date of Greenwich on the main screen. From my perspective showing this on the main window is mandatory, especially in cases where your current location is in the vicinity of the 180th degree of longitude. Maybe you already discussed this issue but when I learned CN we were forced to use the format xx° xx.x' for LAT, Dec, etc. and xxx° xx.x' for LON, etc. and we were forced to write a leading zero (if existing). The idea behind this was to avoid mistakes and so I suggest to use this format also in Stellarium - also for teaching a more robust way to your students and to me ;-) Additionally the data can be vertical aligned on the screen more easily. To my feeling there is some additional code necessary before a merge into Stellarium is useful. That is the reason why I retracted my pull request #812 last year. At begin of January 2020, you mentioned the first time that you were going to do first steps for implementing CN in Stellarium whereas I already was doing the same. So I tried to ask you for collaboration but I did not get any clear answer. What do you think now about bundling our work? I do have some ideas what I would expect a CN plugin should can do. To be consistent to the other lines in If you need some \LaTeX{} support just let me know. |
First off, I'm displaying Ho, Hc and Zn. As a begin writing the User Guide update I am now toying with the wisdom of displaying Ho at all because it doesn't add anything except confusion (your observation is evidence of just that). So it's likely I will remove it as I make progress with the manual. As for height of the observer, that's merely a function of what the user chooses in the Location window. Again, there will be information about this in the guide.
It is shown? UTC is the first line added in the infoStrings displayed.
Agreed, the leading zero where required is important. I will add that.
I'd be more than happy to collab. The only reason I continued on was I probably found myself with more time on my hands. But yeah, please do! :) The one point I do want to achieve is based on feedback I had from CN instructors. Make sure it's all on the screen. If you have to open another window and start entering data it's not going to be used. What they were looking for was a supporting role. They can "pretend" to be making an observation (that's what Stellarium excels at, it looks superb). But they just wanted the intermediates
Will do.
It doesn't look too bad. \LaTeX{} isn't the issue, writer's block is ;) --Andy |
|
I see that fixes for guide are in separate branch, so, I'll merge this branch. |
|
@alex-w Ah yes, I decided to use a separate branch for guide mainly because I have created a number of "temporary" tools to create graphic for the manual. Some of these tolls will turn out to be "not temporary" as I'll want to keep them in case I need to adjust the manual in future (which is possible) . However, I found that these were "cluttering up" my otherwise clean code branch. So I spun that off to work on as a seperate "mini project". I hope to have that done soon. However, for me, code is easier than manuals so I need endless cycles of proofreading. I'd like to make sure my contribution to the User Guide is the best effort. |
|
@A-j-K please shout when you want a review of the manual. |
|
I should have asked, do you have the ability to compile the manual or would you like me to provide temp links to download the PDF from? I can make them available short term if required unless you can compile it yourself. |
|
@A-j-K I'm new to LaTex, am stumbling across a don't produce binary (PDF) documents that cannot be annotated (yes, I know it is possible, but nevertheless, that is not manageable). and something that does not contain diffs is impossible to review. so my only choice is to do a diff of these commits (which I now see have already merged ............... so where can I find all documentation changes related to this issue? ) and understand this LaTex beast (how elegant it might be). I am trying TexStudio 2.12.6 atm. (so I could ask @gzotti the same question he asled in #960 ... what https://tex.stackexchange.com/questions/55437/how-do-i-update-my-tex-distribution Update: whoohoo! doh! |
|
@axd1967 You could read the README.md which resides in the guide directory about the tools that have been used successfully. |
|
I have read that README... |
|
@axd1967 just try |
|
thanks - still the same error. |
|
I just use TeXLive from tug.org - https://tug.org/texlive/quickinstall.html |
|
@A-j-K you can find a first review here: https://github.com/axd1967/stellarium/compare/navstars_improvements_guide...axd1967:contrib/review-ajk-doc?expand=1 @alex-w thx but I still get errors. don't worry, I wil try to find out but it will take time, I'll try to update the README too. |
|
Last time I configured a system it worked out of the box with these packages: |
|
yes, that's how it is written in the README. but I first want to untangle whatever LaTex was installed via TexStudio. |
|
If it's any help I created a Docker image with all the tools required to build the user guide. I then just have Docker Engine installed on my Ubuntu VM and building it becomes simple. I'm actually going to add instructions and a quick way to build the manual using Docker. As for the manual, I'll be making a new PR shortly to get it rolling. https://hub.docker.com/repository/docker/andykirkham/stellarium-build https://github.com/A-j-K/base-dockers/blob/master/stellarium_build/Dockerfile Really needs instructions on how to use it but it has everything installed to compile the User Guide PDF. In theory, it should compile Stellarium but I haven't tried that yet as I have a Windows dev env currently working quite well so just using that for code. |
|
that is an interesting solution! but I see a (for a Linux user) suspect symlink to an .exe in https://github.com/A-j-K/base-dockers/blob/1962c3e9fa7828837528f74420a8d45dae2f018a/stellarium_build/Dockerfile#L63-L64 (wonder if that would work on other systems). tip: you might also want to separate the packages for stellarium compilation from the packages to build the docs (https://github.com/A-j-K/base-dockers/blob/1962c3e9fa7828837528f74420a8d45dae2f018a/stellarium_build/Dockerfile#L6) but you just gave me an idea; I am more of a Vagrant user, as that allows me to completely isolate the VM environment from the host env, while Docker relies on host OS - in your case Windows. |
|
@axd1967 Yes, Vagrant is another option. I just use VMWare to run Ubuntu and install Docker Engine. Then, I build all my tools as images as it makes running them simple without having my Ubuntu image polluted with 1000s of package installs. Each Docker image contains what it needs to get the job done. It also means my building environments are always the same unless I update the image. Just makes being consistent and repeatable a lot easier. |
Add Nautical Almanac data to extraInfoStrings for navigation stars
Description
The standard out of the box Nav Stars plugin highlights a set of stars that represent those chosen and found in Nautical Almanacs around the world. However, it only high lights them and doesn't provide any extra data.
This patch adds additional information points that include the intermediate values derived from the Almanac along with the Sight Reduction solution. All these additional data points are displayed using the format found in The Nautical Almanac, DDMM.m
These are:-
Additionally, two new configuration checkboxes have been added (default unchecked gives original behavior).
CB: Existing. Only highlight nav stars when the star is visible. Currently, when the plugin is enabled all nav stars are highlighted all the time, even during the day when the star is not visible. Checking this box will only allow the highlight if the star is visible.
CB: New. The modifications allow for Nautical Almanac data for any selectable object. This can be limited to only display data for nav stars, Sun, Moon, and planets.
CB: New. Use "upper limb". Most users of sextants use the lower limb of the Sun or Moon. However, a few use the upper limb. Checking this box ensures the Ho (observed altitude) uses the limb of choice.
Fixes # (issue)
Addresses #408
Screenshots (if appropriate):
Type of change
How Has This Been Tested?
The patch includes a Unit Test. The data from which was reduced and tested using pencil and paper using the 2020 Nautical Almanac. Other pencil and paper tests were conducted around various nav stars.
Checklist: