Observation planning

[guillaume...@gmail.com]

Hi Python-Astronomers,

I've been developing Astroobs (https://pypi.python.org/pypi/astroobs/) for my personal needs, and finally put it on "pip".
I know many colleagues use it; which is why I though it could go into astropy, since it is based on astroquery and a tiny bit of astropy itself. It uses the pyephem library for ephemeris calculations.

The README will give you some hints at what it does, and the API too.

In short, here are some cool features:
* Database of all main observatories,
* Targets searching using target names (querying SIMBAD database) or coordinates,
* Proper handling of local times and time-zones, and of observatories at higher latitude than the arctic circles,
* Conversion of coordinates epochs (J2000, B1950, B1900, etc),
* Calculation of target-moon distances
* Calculation of rise, set and transit times, azimuths and altitudes,
* Polar-sky maps of one or more targets,
* Plots of "parameter" as a function of time for one or more targets, "parameter" taken among altitude, azimuth, airmass, moon distance, hour angle or paralactic angle of the target(s).
* Import of HD, HR, HIP numbers and U-B-V-R-I-J-H-K magnitudes whenever available on SIMBAD,
* Plots of the observability durations of a target as a function of the date,
* All values calculated are accessible to the user for scripting and automation.

Anyhow, let me know if you are interested.

Cheers,
Guillaume

[Christoph]

Hi Guillaume,

thanks for sharing!

There’s already a similar Astropy-affiliated package called “Astroplan"

https://github.com/astropy/astroplan <https://github.com/astropy/astroplan>

From a quick look it’s not clear to me what the differences are wrt. your package.

Ideally the efforts would merge, no?

Christoph

[Guillaume Schworer]

Hi Christoph,
Oh that's true, didn't know of astroplan.

I had a quicklook at it. From what I understood astroobs looks easier/faster to use; part is because it queries SIMBAD - e.g. no need to input the target coordinates (see the README examples).

It was actually my wish to make a "brain-dead easy" library to use.

I'm not against merging, as long as I don't need to upgrade my brain ;-) (and we sort the license out as you pointed out on github)

Guillaume

--
You received this message because you are subscribed to a topic in the Google Groups "astropy-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/astropy-dev/akVp7vCwebg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to astropy-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Guillaume SCHWORER

[Brigitta Sipocz]

Hi Guillaume,

I had a quicklook at it. From what I understood astroobs looks easier/faster to use; part is because it queries SIMBAD - e.g. no need to input the target coordinates (see the README examples).

Actually you can use object names in astroplan, too, as astropy.coordinates [0] can use Sesame to resolve these.

Cheers,

 Brigitta

[0] - http://docs.astropy.org/en/stable/coordinates/index.html?highlight=m42#convenience-methods

[Brett Morris]

Hi Guillaume,

There are a few examples in the astroplan docs where we demonstrate calls to the astropy.coordinates.SkyCoord_from_name method, which queries the CDS name resolver to easily construct targets (1, 2). But those examples are hard to find, so I'm adding some more!

Brett

To unsubscribe from this group and all its topics, send an email to astropy-dev...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Guillaume SCHWORER

[Thomas Robitaille]

Hi Guillaume,

Thanks for working on this package! As Christoph, Brigitta, and Brett
mentioned, this overlaps a fair bit with astroplan, which is an
astropy affiliated package for observation planning. In general, we
try and encourage developers to avoid duplicating functionality in the
Astropy ecosystem, so if you were interested in having your package
become an Astropy affiliated package, we would not currently be able
to accept it because of this.

I would therefore recommend trying to look in detail at each part of
the functionality to see what is missing in astroplan or astropy and
opening pull requests to those packages to add that functionality,
rather than maintain a separate package. We (on this list) can of
course help if you aren't sure how to contribute some of this.

I've included some notes below on the list of functionality - my aim
here is just to make sure we're all on the same page, and as I
indicate below, I think there are places where it would be possible to
contribute some of these features to astropy/astroplan!

> * Database of all main observatories,

We already have functionality for this in the core astropy package:

http://docs.astropy.org/en/stable/api/astropy.coordinates.EarthLocation.html#astropy.coordinates.EarthLocation.of_site

>>> EarthLocation.of_site('Apache Point Observatory')

However, if there are observatories missing from this, you can open a
pull request to add them (see the note at the above URL about how to
do that)

> * Targets searching using target names (querying SIMBAD database) or
> coordinates,

You can do this already with astropy.coordinates using SkyCoord.from_name:

http://docs.astropy.org/en/stable/api/astropy.coordinates.SkyCoord.html#astropy.coordinates.SkyCoord.from_name

>>> c = SkyCoord.from_name('M16')

> * Proper handling of local times and time-zones, and of observatories at
> higher latitude than the arctic circles,

There is a little bit about time zones in the core astropy package:

http://docs.astropy.org/en/stable/api/astropy.time.TimezoneInfo.html?highlight=time%20zone#astropy.time.TimezoneInfo

However if there are ways we can support time zones better, it would
be great to enhance astropy.time. There is an open issue for trying to
get time zone information from a longitude/latitude:

https://github.com/astropy/astropy/issues/676

If you have code to do that, it would be great to contribute it to astropy.time!

> * Conversion of coordinates epochs (J2000, B1950, B1900, etc),

This can be done with astropy.time:

>>> t = Time('B1950')
>>> t.iso
'1949-12-31 22:09:46.862'

> * Calculation of target-moon distances

astropy.coordinates provides get_moon which can get the position of
the moon, and users can then do SkyCoord.separation(moon). I'm not
sure if it makes sense to provide any wrapper around that - instead,
it might be worth simply providing an example of this in the
astropy.coordinates documentation.

> * Calculation of rise, set and transit times, azimuths and altitudes,

I think astroplan can do these (in fact, for azimuths/altitudes, you
can also do it straight with astropy.coordinates)

> * Polar-sky maps of one or more targets,

I think astroplan does this:

http://astroplan.readthedocs.io/en/latest/tutorials/summer_triangle.html#sky-charts

> * Plots of "parameter" as a function of time for one or more targets,
> "parameter" taken among altitude, azimuth, airmass, moon distance, hour
> angle or paralactic angle of the target(s).

The astroplan docs show examples of plotting airmass versus time:

http://astroplan.readthedocs.io/en/latest/tutorials/plots.html

but I'm not sure if it can do things like moon/sun distance - if not,
that would be a worthwhile addition! (maybe Brett or another astroplan
developer can confirm?)

> * Import of HD, HR, HIP numbers and U-B-V-R-I-J-H-K magnitudes whenever
> available on SIMBAD,

This is not something that astropy or astroplan currently do -
astroquery (another affiliated package) can do this I believe:

http://astroquery.readthedocs.io/en/latest/simbad/simbad.html

but I wonder whether it would be worth trying to see if this could
also be included somehow in astroplan?

> * Plots of the observability durations of a target as a function of the
> date,

This sounds cool - I'm not sure if astroplan does this, so again, this
may be a worthwhile addition!

I hope this helps!

Cheers,
Tom

> * All values calculated are accessible to the user for scripting and
> automation.
>
> Anyhow, let me know if you are interested.
>
> Cheers,
> Guillaume
>

> --
> You received this message because you are subscribed to the Google Groups
> "astropy-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an

[Brett Morris]

Hi Tom, Guillaume,

but I'm not sure if it can do things like moon/sun distance - if not,
that would be a worthwhile addition! (maybe Brett or another astroplan
developer can confirm?)

At present there is no convenience method for moon/sun distance plotting. The plotting convenience functions have been developed in response to user requests, and I wasn't yet aware of a use case for those plots, but we'd be happy to have them if someone needs them. What do those get used for?

> * Import of HD, HR, HIP numbers and U-B-V-R-I-J-H-K magnitudes whenever
> available on SIMBAD,

This is not something that astropy or astroplan currently do -
astroquery (another affiliated package) can do this I believe:

http://astroquery.readthedocs.io/en/latest/simbad/simbad.html

but I wonder whether it would be worth trying to see if this could
also be included somehow in astroplan?

Astroplan shouldn't encroach on astroquery's territory, and that sounds like an astroquery task to me. But I don't think there's a simple, uniform interface for accessing SIMBAD magnitudes with astroquery at present? Maybe an astroquery dev can comment. In my experience, it's easiest to get magnitudes by querying Vizier via astroquery, rather than from SIMBAD.

[Brigitta Sipocz]

On 19 August 2016 at 18:13, Brett Morris <nasa...@gmail.com> wrote:

> * Import of HD, HR, HIP numbers and U-B-V-R-I-J-H-K magnitudes whenever
> available on SIMBAD,

This is not something that astropy or astroplan currently do -
astroquery (another affiliated package) can do this I believe:

http://astroquery.readthedocs.io/en/latest/simbad/simbad.html

but I wonder whether it would be worth trying to see if this could
also be included somehow in astroplan?

Astroplan shouldn't encroach on astroquery's territory, and that sounds like an astroquery task to me. But I don't think there's a simple, uniform interface for accessing SIMBAD magnitudes with astroquery at present? Maybe an astroquery dev can comment. In my experience, it's easiest to get magnitudes by querying Vizier via astroquery, rather than from SIMBAD.

Well, I think it's pretty straightforward to get the magnitudes with astroquery, though I agree with you to prefer to get magnitudes from a well defined source through vizier. However this will do the job with simbad (assuming that you care only about the magnitudes, the coordinates field should be removed first, then the magnitudes can be added):

>>> from astroquery.simbad import Simbad
>>> SimbadMag = Simbad()

>>> SimbadMag.remove_votable_fields('coordinates')
>>> for i in ['U','B','V','R','I','J','K']:
...     SimbadMag.add_votable_fields('flux({0})'.format(i))
>>> SimbadMag.query_object('hd189733')

Cheers,

 Brigitta

[Guillaume Schworer]

Hi Tom, Brett,

Thanks Tom for your detailed e-mail and feedback. For the record, I started astroobs slowly a few years back, building a GUI; only a year ago did I abandon the GUI to build a real package available on pip - didn't know of astroplan before posting in this thread, which explains my "blind e-mail".

Astroobs is indeed using astroquery to get magnitudes and HD/HIP/HR numbers. It is however not 100% straightforward: one needs to request "custom output" from astroquery to get the fluxes, and do some string search to extract the HR/HD/HIP numbers out of the whole list of known names. It is 5 lines of tedious code, but still provides valuable information to the observer, especially on target selection when one has harsh sensitivity constraints.
Maybe the HD/HIP/HR number extraction should happen in astroquery indeed.

Moon/Sun distance to target is quite important to know for night observers (moon) or radioastronomers (sun). These bright objects create ghosts in the optics/antennas, they can degrade adaptive optic correction (in the best case) or even grill a detector.
The Moon-rejection radius is 30° on the Subaru Telescope, that's a huge chunk of the sky when it is up (60° diameter.. that's a blind spot of 60cm diameter at 50cm from you) - I already got several targets screwed this way.


Getting time zone information from a longitude/latitude sounds like a nightmare! What is done in astroobs is store the timezone name in the observatory database, so the user only has to tell "UT" or "local" and the math happens behind the scene. The timezone database used is pytz.

Plotting several parameters as a function of time can be important:

- altitude/azimuth: know if your target is going to bump into some landscape/building... depending on the observatory, this may happen!

- airmass (or altitude): know when the target is high enough

- hour angle or paralactic angle: that's useful for knowing the position angle diversity on an acquisition, useful for angular differential stuff, and for spectroscopy too

​Anyhow. Yes forces should join. Although we don't seem to have the same line on usability (https://github.com/astropy/astroplan/pull/227 and https://github.com/ceyzeriat/astroobs/issues/5)

I can tell for a fact that observational scientists are lazy about coding. I even have a colleague who wrote a wrapper to automate the initialisation of the astroobs "Observation" class and write 3 lines of code instead of 4, since he was only using one observatory (see second line down here) - still cracks me up.
>> import astroobs as obs
>> o=obs.Observation('subaru', local_date=(2015, 6, 16), moonAvoidRadius=15, horizon_obs=40)
>> o.add_target('vega')
>> o.plot()

​My feeling is that astroplan has a safer/stronger base than astroobs (more devs people, 100% astropy based, etc), but the user's command-line interface is a real pain in the back to me (and several users of astroobs).
As an example, the 4 lines of astroobs code above are equivalently obtained with 4 imports and 6 additional lines of initialisation and plotting in astroplan. Plus the user needs to know the "Time" class formatting of astropy:
>> import astroplan as ap
>> from astropy.time import Time
>> from astroplan.plots import plot_airmass
>> import matplotlib.pyplot as plt

>> subaru = ap.Observer.at_site('subaru')
>> vega = ap.FixedTarget.from_name('Vega')
>> time = Time('2015-06-16 12:00:00')
>> plot_airmass(vega, subaru, time)
>> plt.legend(loc=1, bbox_to_anchor=(1, 1))
>> plt.show()

​Maybe I'm just too lazy.. but this looks like a lot of hassle​ to me. I understand that​ you want users to be "clean" about the input.. I am wondering however if an observation planning tool is meant to be focusing on being "fully explicit", like a calculus library is.
Btw, one can be flexible and explicit on inputs! Check np.histogram2d parameter "bins" for funky explicitness!

I am happy to pull-request astroplan to add stuff, but again, I can't merge astroobs into astroplan without ensuring a similar usability to the current astroobs users :-)

Maybe a solution is to make astroplan an ephemeris-calculation tool purely (moon&sun avoidance, planets, targets, combined constraints, etc), of which astroobs is a wrapper to deal with plotting and usability.
I guess the least people would be unhappy this way. Just a random idea!

Cheers,

Guillaume

--

You received this message because you are subscribed to a topic in the Google Groups "astropy-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/astropy-dev/akVp7vCwebg/unsubscribe.

To unsubscribe from this group and all its topics, send an email to astropy-dev+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Guillaume SCHWORER

[Christoph Deil]

On 20 Aug 2016, at 01:30, Christoph Deil <Christo...@mpi-hd.mpg.de> wrote:

Hi Guillaume,

On 20 Aug 2016, at 00:26, Guillaume Schworer <guillaume...@gmail.com> wrote:

Hi Tom, Brett,

Thanks Tom for your detailed e-mail and feedback. For the record, I started astroobs slowly a few years back, building a GUI; only a year ago did I abandon the GUI to build a real package available on pip - didn't know of astroplan before posting in this thread, which explains my "blind e-mail".

Astroobs is indeed using astroquery to get magnitudes and HD/HIP/HR numbers. It is however not 100% straightforward: one needs to request "custom output" from astroquery to get the fluxes, and do some string search to extract the HR/HD/HIP numbers out of the whole list of known names. It is 5 lines of tedious code, but still provides valuable information to the observer, especially on target selection when one has harsh sensitivity constraints.
Maybe the HD/HIP/HR number extraction should happen in astroquery indeed.

+1 to add this convenience.

Sounds like astroquery is the right place.

Can you make a PR or issue, please?

You can already now pass time as string to `plot_airmass` and it’ll call the `Time` constructor if you like it short.

Looks like targets and observer can’t be strings (like in your package) at the moment here.

I’m not sure if it’s a good idea, but calling Observer.at_site and FixedTarget.from_name in plot_airmass and similar functions automatically if strings are passed sounds like a proposal to increase convenience we should discuss.

Can you please open a Github issue at https://github.com/astropy/astroplan ?

​Maybe I'm just too lazy.. but this looks like a lot of hassle​ to me. I understand that​ you want users to be "clean" about the input.. I am wondering however if an observation planning tool is meant to be focusing on being "fully explicit", like a calculus library is.
Btw, one can be flexible and explicit on inputs! Check np.histogram2d parameter "bins" for funky explicitness!

I am happy to pull-request astroplan to add stuff, but again, I can't merge astroobs into astroplan without ensuring a similar usability to the current astroobs users :-)

Maybe a solution is to make astroplan an ephemeris-calculation tool purely (moon&sun avoidance, planets, targets, combined constraints, etc), of which astroobs is a wrapper to deal with plotting and usability.
I guess the least people would be unhappy this way. Just a random idea!

I think having two Python packages with huge overlap is bad, it splits the user and developer community.

The best solution IMO would be to fully merge missing functionality and some convenience stuff into astroplan.

If there’s fundamental and unresolvable differences concerning explicitness vs usability for the API, a good way (less duplication of code and effort) would be to rewrite astroobs as thin wrapper functions / classes with the convenient API you like that use astroplan under the hood, and contribute missing functionality to astropy, astroplan or astroquery.

Cheers,

Christoph