Add option to specify coordinate/propagation epoch

[cgobat]

The catalog generation routine currently attempts to propagate sky coordinates to the current year using proper motions. However, it is sometimes desirable to specify coordinates at an epoch other than present day (such as when using a reference frame tied to J2000).

generate_database could take an optional epoch float parameter that would then be used instead of the current_year value.

[alexw-im]

For my own clarification: The catalog generation routine currently writes hash tables using positions propagated in proper motions, the implicit assumption being that the end user is trying to run lookup on an image of stars taken recently - correct?

Are you saying the solver also currently reports solutions based on this same present-day epoch?

I guess - what's the assumed base use case (epoch of catalog/epoch of solution) vs the use case you propose to support?

Alternately, am I misunderstanding entirely?

[cgobat]

The catalog generation routine currently writes hash tables using positions propagated in proper motions, the implicit assumption being that the end user is trying to run lookup on an image of stars taken recently - correct?

Yep, that's right.

Are you saying the solver also currently reports solutions based on this same present-day epoch?

I believe the solver's reported solutions are basically in whatever coordinate system the catalog/database it uses is in—the solver algorithm doesn't know anything about epochs/proper motions/etc., just the geometries of the asterisms in the catalog and in the image.

I guess - what's the assumed base use case (epoch of catalog/epoch of solution) vs the use case you propose to support?

Consider the case where the original catalog you are using reports coordinates in B1950 or J2000, and you are trying to plate solve images from some time other than present day—say, the early 2000s. It would not make sense to propagate the catalog's sky positions to 2023, because you'd want to have the database reflect the positions of the stars in the sky at the time of the images.

My proposed implementation of this is fairly straightforward: right now the RA/Dec propagation uses the variable current_year, which is set here and then used here and here. Instead, an optional argument could be added to the generate_database() method (something like epoch or propagation_epoch?) that could even still default to the current year but would then be used instead of current_year in the latter two places.

[alexw-im]

Ahhhhh I think I understand now, thank you for spelling that out!

I was initially conflating epoch (which applies to the coordinate system) with, as you've since renamed it, "propagation_epoch", which applies to the sky positions themselves.

So I think you're not talking at all about epoch of the coordinate system, JUST "the time sky positions are propagated to, i.e. approximate capture time of plates you'd like to solve with this DB"?

[cgobat]

I believe this may have been addressed in #22. @gustavmpettersson, should this issue be closed?

[gustavmpettersson]

Correct, this is implemented. Closing the issue, thanks!