Make GOES event location variable names more explicit: lon/lat

[jmason86]

I've just done a bunch of digging around and determined that when using get_goes_event_list, the first array coordinate is longitude and the second is latitude. This is the same as what's returned when using IDL solarsoft rd_gev (which you can drill down several levels to find gbo_struct [code], where a comment defines these two location values). This is the opposite of what you see in the GOES event lists on the NOAA web interfaces (e.g., here) where location is reported as latitude, longitude. I noticed this when looking at several years of flare event data and checking the minmax on the two locations. The first location ranges from [-90, +90] and the second (in the timeframe I was looking) from [-32, +56]. I had serious doubts that the GOES event list had anything reported from the poles.

So my suggested change is to make variable names more explicit so people in the future don't make mistakes, or have uncertainty if they're new to solar physics, or have to go through the exercise I just did. In sunpy/instr/goes there is a function called get_goes_event_list. In there, it defines location just as it is in IDL solarsoft: 'goes_location': (r['event_coord1'], r['event_coord2'])

I suggest this be changed to goes_longitude and goes_latitude

I'm happy to make this change (or a similar one based on feedback) in a PR but I'm not sure what other code it may break.

[Cadair]

If possible I think it would be even better to return a SkyCoord object to represent the position so it's completely ambiguous. Is there enough information in the event list to make a full SkyCoord, i.e. observer location and observation time?

[jmason86]

Maybe? You definitely get the NOAA definition for flare start and peak times. The heliocentric latitude/longitude they give you probably applies to the peak time, though finding out for sure is likely to be nontrivial. Start and peak are usually a few minutes apart; I don't know how sensitive the SkyCoord is to time.

As for observer location, it's always from a GOES spacecraft, which is in Earth geostationary orbit. The online reports do list which GOES spacecraft (lately either GOES 15 or 16 and now 17 is on orbit) from which you should be able to figure out position with anscillary data, but that's not provided in the report. However, the return from ssw rd_gev and sunpy get_goes_event_list does not even include the satellite identifier. Again, I don't know how sensitive SkyCoord is to location; is just putting it at Earth good enough?

Here's an example of what's returned from sunpy.instr.goes.get_goes_event_list

[{'end_time': datetime.datetime(2018, 1, 18, 7, 39),
  'event_date': '2018-01-18',
  'goes_class': 'B9.7',
  'goes_location': (5, -12),
  'noaa_active_region': 12696,
  'peak_time': datetime.datetime(2018, 1, 18, 7, 35),
  'start_time': datetime.datetime(2018, 1, 18, 7, 28)},
 {'end_time': datetime.datetime(2018, 1, 18, 8, 16),
  'event_date': '2018-01-18',
  'goes_class': 'B4.0',
  'goes_location': (5, -12),
  'noaa_active_region': 12696,
  'peak_time': datetime.datetime(2018, 1, 18, 8, 13),
  'start_time': datetime.datetime(2018, 1, 18, 8, 8)}]

[Cadair]

The answer is that it really depends on how accurate you want things to be. The best thing would be to get precise values for both. If they don't exist then just SkyCoord(lat=, lon=, frame="helioprojective") will at least store the information in a way that people can augment (it will default to 'earth' and refuse to transform out of helioprojective).

I would imagine that just using 'earth' would be good enough for 99% of people, as long as there is a reasonably accurate obstime.

The true answer to this of course would probably only be obtained by chasing down the HEK feature detection algorithm to work out the correlations between the lat/lon and the obstime satellite position etc.

[jmason86]

Hm... that could be dangerous for some fraction of that 1%: people that think the existence of a SkyCoord implies a precision that isn't true in this case. They'd probably become aware if they tried to transform. Is there anything in SkyCoord that could warn them?

Either way, this would be an improvement for everyone compared to the ambiguous event_coord1 event_coord12.

[Cadair]

Yeah if you specify an obstime, the position of earth will be looked up and converted to a real coordinate, the information that it was "earth" is effectively lost at that point.

>>> SkyCoord(0,0,unit=u.arcsec, frame="helioprojective")
<SkyCoord (Helioprojective: obstime=None, rsun=695508.0 km, observer=earth): (Tx, Ty) in arcsec
    (0., 0.)>
>>> SkyCoord(0,0,unit=u.arcsec, frame="helioprojective", obstime="2011-01-01")
<SkyCoord (Helioprojective: obstime=2011-01-01 00:00:00, rsun=695508.0 km, observer=<HeliographicStonyhurst Coordinate (obstime=2011-01-01 00:00:00): (lon, lat, radius) in (deg, deg, AU)
    (0., -2.97718014, 0.98335587)>): (Tx, Ty) in arcsec
    (0., 0.)>

I personally think the best thing to do is to set the observer to earth and the obstime the best you can and stick a note in the documentation. Having said that I would like some input from someone with more understanding of HEK / goes to back me up on this. @wafels any ideas?

[dpshelio]

This coordinate positioning of GOES predates HEK. I'm not sure which telescope has been used to get them. I believe is SXR on GOES, but maybe nowadays they can use AIA with faster cadence. In any case, as the coordinates are given in degrees, I don't think there's much accuracy needed, so Earth is good enough. The time accuracy given by goes is good too.

I believe the best would be to use the peak of the flare as the time for the coordinates (when they exist) and keep the satellite information (for the flare detection - not the coordinates) as an output of the query. However, we may not be providing that information because HEK may not be giving it out... (I've not checked...)

[wafels]

GOES flare co-ordinates also occasionally default to (0,0), at least according to how they are stored in the HEK. I think GOES sets the co-ordinates to (0, 0) when they can't make a determination of where the flare happened on the disk.

On Fri, Jun 29, 2018 at 2:31 PM, David Pérez-Suárez < notifications@github.com> wrote:

This coordinate positioning of GOES predates HEK. I'm not sure which telescope has been used to get them. I believe is SXR on GOES, but maybe nowadays they can use AIA with faster cadence. In any case, as the coordinates are given in degrees, I don't think there's much accuracy needed, so Earth is good enough. The time accuracy given by goes is good too.

I believe the best would be to use the peak of the flare as the time for the coordinates (when they exist) and keep the satellite information (for the flare detection - not the coordinates) as an output of the query. However, we may not be providing that information because HEK may not be giving it out... (I've not checked...)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/sunpy/sunpy/issues/2673#issuecomment-401437420, or mute the thread https://github.com/notifications/unsubscribe-auth/AA8CF-nZz0H8svHio0rLl0LR-9S0KYDJks5uBnJmgaJpZM4U2flo .

[wtbarnes]

Barring a reliable source of the GOES spacecraft position, this may be a good case for observer=None. That way, a user has the benefit of using a SkyCoord, but it will be explicitly noted that there is no observer location and they will be explicitly told so if they try to transform to another frame.

[Cadair]

We have support for that now, so that could be implemented.