search

seignovert / python-webgeocalc

Python package for NAIF WebGeoCalc API
https://webgeocalc.readthedocs.io
MIT License
6 stars 4 forks source link

Adding PositionEventFinder calculation type ? #3

Closed BaptisteCecconi closed 3 years ago

BaptisteCecconi commented 3 years ago

Hi @seignovert, do you have any plan to include the PositionEventFinder calculation type?

BaptisteCecconi commented 3 years ago

Does GF_COORDINATE_SEARCH correspond to PositionEventFinder?

If so, it would be nice to have a lookup table to map the API methods with the web interface feature names.

jdiazdelrio commented 3 years ago

Hi @BaptisteCecconi,

yes, GF_COORDINATE_SEARCH corresponds to Position Event Finder in the WGC web interface. All other features match if you take into consideration that the prefix GF_ indicates "Event Finder" capability. Note that Target in Field of View Event Finder corresponds to GF_TARGET_IN_INSTRUMENT_FOV_SEARCH.

BaptisteCecconi commented 3 years ago

Thanks @jdiazdelrio I'll see what I can do with this. I may propose a pull request implementing GF_COORDINATE_SEARCH if you agree.

seignovert commented 3 years ago

Hi @BaptisteCecconi, You are right I did not implement de GF_* entry points yet, but I will be happy to add your PR.

Just for reference, here is the full list of the missing entries, as described in the docs:

Web interface API Implementation
Position Finder GF_COORDINATE_SEARCH #4
Angular Separation Finder GF_ANGULAR_SEPARATION_SEARCH
Distance Finder GF_DISTANCE_SEARCH
Sub-Point Finder GF_SUB_POINT_SEARCH
Occultation Finder GF_OCCULTATION_SEARCH
Surface Intercept Finder GF_SURFACE_INTERCEPT_POINT_SEARCH
Target in Field of View Finder GF_TARGET_IN_INSTRUMENT_FOV_SEARCH
Ray in Field of View Finder GF_RAY_IN_FOV_SEARCH
Range Rate Finder GF_RANGE_RATE_SEARCH
Phase Angle Finder GF_PHASE_ANGLE_SEARCH

This should be include in the module docs as well.

It's open to debate, but I would recommend to use the Web naming convention (I find them more clear):

from webgeocalc import PositionFinder

instead of

from webgeocalc import GFCoordinateSearch

We can always overload GFCoordinateSearch as child of PositionFinder (or the other way around) but it might be confusion for the end-user.

I'm open to suggestions!

seignovert commented 3 years ago

Actually… I realized that I'm using OsculatingElements naming convention instead of OrbitalElements.

So you are right, it may be relevant to implement it as GFCoordinateSearch and eventually overload it as PositionFinder (to keep backward compatibility).