Stellar proper motion and IAU constellation label (Rho Aql)

[gzotti]

From the forum https://sourceforge.net/p/stellarium/discussion/278769/thread/ba4e84ab/?limit=25

"Rho Aquilla is listed in the Aquilla constellation while it has already (25 years ago) passed to Delphinus, if you zoom really hard on it you can see it's on the other side of the line between the two constellations. For more info see: https://en.wikipedia.org/wiki/Rho_Aquilae"

GZ: The net result is that the "IAU constellation" in Infostring gives Aql until 2020, while coordinate position is already in Del. There may be similar cases.

[Alexander Wolf (alexwolf)]

Current transformation is J2000.0 -> J1875.0, but (!) the article 1987PASP...99..695R ("Identification of a Constellation from a Position" by Nancy Roman) was received 1987 April 27 and the default epoch for this year is B1950.5 (you can read "equinox 1875.0" in the article). Are you sure that Julian epoch are used for boundaries for constellations?

If answer is "yes", then transformation should be JNow -> J1875.0 (or JNow -> J2000.0 -> J1875.0) for resolve possible issues for stars with high proper motion.

If answer is "no", then transformation should be JNow -> J2000.0 -> B1950.5 -> B1875.0.

[Alexander Wolf (alexwolf)]

Oh yeah, seems the IAU constellation boundaries are defined in the equatorial coordinate system relative to the equinox of B1875.0. Nice! Maybe better way will be recalculate all boundaries into the J2000.0 coordinates and use JNow -> J2000 transformation for checking constellation?

[Alexander Wolf (alexwolf)]

I've updated calculations for boundaries and some constellations has good accuracy for boundaries now, some constellations has not very good accuracy for this data. Is is possible that we have wrong data for lines of boundaries?

[gzotti (georg-zotti)]

Alexander, the fast algorithm used to identify position to constellations is correct as described in the paper. Indeed, in 1926 (or 1931? cannot remember, not so important here) IAU defined constellation boundaries in J1875 (or maybe even B1875?) equinox. Any difference B1875/J1875 should be negligible in this context, though.

What needs to be done for stars is transformation of positions for equinox&epoch Jnow->equinox 1875 (or epoch Jnow in J2000 frame and J2000->J1875, in any case only precession! Proper motion for Jnow, not 1875!!) and check positions. Maybe currently we just check epoch J2000 positions (for efficiency). I had assigned this low-priority issue to myself and intended to look into the code a bit later.

[Alexander Wolf (alexwolf)]

Please see changes in revision 9380 (http://bazaar.launchpad.net/~stellarium/stellarium/trunk/revision/9380)

[gzotti (georg-zotti)]

None of this did change much, although B1875 may be the correct epoch (unclear from Roman's paper). I moved to double precision, nope. Then I checked with mouse coordinates for 1875. Line was displayed perfectly, mouse coordinates constellation was off. Believe it or not, it is a rounding error, actually two rounding error mismatches, in the border data files, best visible on such very "un-round" RAs like this line when zooming in to show arcseconds. This line at 20h8m30s is listed as 20.1417 in constellations_spans.dat (line 169), yielding an error of 0.12 arcseconds.
Extending significant places to 20.14166666667 yields a better approximation. Now rho Aql is shown to move to Del in 1989, but does not cross the visible line before 1997 (as before).
I.e., now this value in this RA border in the reverse lookup file is more accurate than the displayed line. These line catalogs also only give decimal rounded values, whereas the original lines were defined in arcseconds of B1875.

r9383 comes with this single border corrected. Extending precision for the spans file is moderately easy, just rather tedious. The borders file is much more complicated.

[gzotti (georg-zotti)]

r9410 provides a restored border decoding file (and adapted reader) which avoids all these original rounding errors.

[gzotti (georg-zotti)]

I also had a look into the constellations_boundaries.dat file. This includes precessed line points with rounded (slightly too few) numerical digits for ultimate accuracy. These cannot be restored to sub-arcseconds, so either somebody has to process the original data files again (bound_18.dat from Davenhall&Leggett 1990 cat.VI/49) or we keep it as-is. Actually we are approximating the boundaries with great-circle arcs, which is wrong anyhow. But the difference is negligibly small for all practical purposes likely except when it comes to observation of this very star with sub-arcsecond zoom level, so I'd rather say we can close this bug.