get_moon does not support non-scalar times for non-geocentric observer

If you call get_moon with a non-scalar time and specify an observer location with the location keyword argument, the function fails. Here’s an example:

In [1]: from astropy.coordinates import EarthLocation, get_moon

In [2]: from astropy.time import Time

In [3]: get_moon(Time(['2014-01-01', '2014-01-02']))
Out[3]:
<SkyCoord (GCRS: obstime=['2014-01-01 00:00:00.000' '2014-01-02 00:00:00.000'], obsgeoloc=[ 0.  0.  0.] m, obsgeovel=[ 0.  0.  0.] m / s): (ra, dec, distance) in (deg, deg, AU)
    [(273.79665999, -19.09558029, 0.00239101),
     (289.77426273, -17.30906137, 0.00238599)]>

In [4]: location = EarthLocation.of_site('apo')

In [5]: get_moon(Time(['2014-01-01', '2014-01-02']), location=location)
---------------------------------------------------------------------------
ValueError                                Traceback (most recent call last)
<ipython-input-5-782877431d86> in <module>()
----> 1 get_moon(Time(['2014-01-01', '2014-01-02']), location=location)

/Users/bmmorris/anaconda/lib/python3.5/site-packages/astropy-1.3.dev15928-py3.5-macosx-10.6-x86_64.egg/astropy/coordinates/solar_system.py in get_moon(time, location, ephemeris)
    378     """
    379
--> 380     return get_body('moon', time, location=location, ephemeris=ephemeris)
    381
    382 get_moon.__doc__ += indent(_EPHEMERIS_NOTE)[4:]

/Users/bmmorris/anaconda/lib/python3.5/site-packages/astropy-1.3.dev15928-py3.5-macosx-10.6-x86_64.egg/astropy/coordinates/solar_system.py in get_body(body, time, location, ephemeris)
    344         gcrs = icrs.transform_to(GCRS(obstime=time,
    345                                       obsgeoloc=obsgeoloc,
--> 346                                       obsgeovel=obsgeovel))
    347     else:
    348         gcrs = icrs.transform_to(GCRS(obstime=time))

/Users/bmmorris/anaconda/lib/python3.5/site-packages/astropy-1.3.dev15928-py3.5-macosx-10.6-x86_64.egg/astropy/coordinates/baseframe.py in __init__(self, *args, **kwargs)
    540
    541             # Validate input by getting the attribute here.
--> 542             getattr(self, fnm)
    543
    544         args = list(args)  # need to be able to pop them

/Users/bmmorris/anaconda/lib/python3.5/site-packages/astropy-1.3.dev15928-py3.5-macosx-10.6-x86_64.egg/astropy/coordinates/baseframe.py in __get__(self, instance, frame_cls)
    210             out = self.default
    211
--> 212         out, converted = self.convert_input(out)
    213         if instance is not None and converted:
    214             setattr(instance, '_' + self.name, out)

/Users/bmmorris/anaconda/lib/python3.5/site-packages/astropy-1.3.dev15928-py3.5-macosx-10.6-x86_64.egg/astropy/coordinates/baseframe.py in convert_input(self, value)
    333                 raise ValueError('The provided value has shape "{0}", but '
    334                                  'should have shape "{1}"'.format(value.shape,
--> 335                                                                   self.shape))
    336             if (oldvalue.unit == value.unit and hasattr(oldvalue, 'value') and
    337                 np.all(oldvalue.value == value.value)):

ValueError: The provided value has shape "(3, 2)", but should have shape "(3,)"

This is using astropy v1.2. This is related to the old closed issue #5069. This is coming up because we are using get_moon in astroplan and have to loop over each time to avoid this bug, which is a pretty slow solution (astropy/astroplan#211).

cc @StuartLittlefair @eteq @mhvk

[StuartLittlefair]

Thanks for raising this @bmorris3. There’s a PR already submitted which should fix this issue.

[StuartLittlefair]

@bsipocz Those errors look like they are related to changes made in #5254, which made frames and their attributes (I.e obstimes) handle shapes correctly.

IIRC there are a number of places in astroplan where these attributes are assumed to be 1D lists which is probably causing the errors you see.

We should probably discuss this further on the astroplan repo but IMO the decision to use lists of FixedTargets in that code rather than non scalar SkyCoords had led to a lot of pain and poor performance, as well as the bugs you’re seeing. It may be wise to consider a code refactoring.