HEK -when the requested time is on the boundary of two separate F/Es detected by the same FRM

[Jack Ireland]

This shows the issue:

http://hek.delphi.nascom.nasa.gov/?date=2012-05-11T23:11:08.500Z&imageScale=2.4204409&centerX=54.29859691853027&centerY=-12.303858664337158&imageLayers=%5BSDO,AIA,AIA,211,1,100%5D,%5BSOHO,LASCO,C2,white-light,2,100%5D&eventLayers=%5BCC,all,1%5D,%5BCD,all,1%5D,%5BCH,all,1%5D,%5BCJ,all,1%5D,%5BCE,all,1%5D,%5BCR,all,1%5D,%5BCW,all,1%5D,%5BER,all,1%5D,%5BFI,all,1%5D,%5BFA,all,1%5D,%5BFE,all,1%5D,%5BFL,all,1%5D,%5BLP,all,1%5D,%5BOS,all,1%5D,%5BPG,all,1%5D,%5BSP,all,1%5D,%5BSS,all,1%5D&eventLabels=true

There are three coronal holes on the Sun. HEK SPoCA is reporting 6 events. This is because of two things:

(1) the end time of a SPoCA CH detection is equal to the start time of the next detection.
(2) The requested time is precisely the time described in (1) above.

This leads to Helioviewer plotting two regions for each actual coronal hole on the Sun. Criteria need to be developed for picking one of the two regions.

The same also happens for SPoCA AR detections.

http://hek.delphi.nascom.nasa.gov/?date=2012-05-12T02:11:09.000Z&imageScale=2.4204409&centerX=55.266832371325684&centerY=-8.431212317132568&imageLayers=%5BSDO,AIA,AIA,211,1,100%5D,%5BSOHO,LASCO,C2,white-light,2,100%5D&eventLayers=%5BAR,SPoCA,1%5D,%5BCC,all,1%5D,%5BCD,all,1%5D,%5BCH,all,1%5D,%5BCJ,all,1%5D,%5BCE,all,1%5D,%5BCR,all,1%5D,%5BCW,all,1%5D,%5BER,all,1%5D,%5BFI,all,1%5D,%5BFA,all,1%5D,%5BFE,all,1%5D,%5BFL,all,1%5D,%5BLP,all,1%5D,%5BOS,all,1%5D,%5BPG,all,1%5D,%5BSP,all,1%5D,%5BSS,all,1%5D&eventLabels=true

[Jack Ireland (jack-ireland)]

It gets worse:

http://hek.delphi.nascom.nasa.gov/?date=2013-03-22T12:52:43.000Z&imageScale=2.4204409&centerX=1.21022045&centerY=26.5870305109375&imageLayers=%5BSDO,AIA,AIA,304,1,100%5D&eventLayers=%5BAR,NOAA_SWPC_Observer,1%5D,%5BCC,all,1%5D,%5BCD,all,1%5D,%5BCH,all,1%5D,%5BCJ,all,1%5D,%5BCE,all,1%5D,%5BCR,all,1%5D,%5BCW,all,1%5D,%5BEF,all,1%5D,%5BER,all,1%5D,%5BFI,all,1%5D,%5BFA,all,1%5D,%5BFE,all,1%5D,%5BFL,all,1%5D,%5BLP,all,1%5D,%5BOS,all,1%5D,%5BPG,all,1%5D,%5BSG,all,1%5D,%5BSP,all,1%5D,%5BSS,all,1%5D&eventLabels=true

Here there are coronal holes that have split into two. How do we handle that? Perhaps we should always use the most recent detection since the observation will evolve in that direction. The criteria would could be
if (F/E == AR or F/E == CH) and (FRM == SPoCA) then only show the CHs and ARs that have the latest end times. Maybe we need a spatial overlap component too, which would add in more complexity.

[Jack Ireland (jack-ireland)]

Another example of overlapping detections in time and space: Looks like someone re-ran the algorithm on overlapping time periods.

http://hek.delphi.nascom.nasa.gov/?date=2013-03-01T15:02:07.000Z&imageScale=2.4204409&centerX=1.21022045&centerY=3.857577684375&imageLayers=%5BSDO,AIA,AIA,304,1,100%5D&eventLayers=%5BAR,NOAA_SWPC_Observer,1%5D,%5BCC,all,1%5D,%5BCD,all,1%5D,%5BCH,all,1%5D,%5BCJ,all,1%5D,%5BCE,all,1%5D,%5BCR,all,1%5D,%5BCW,all,1%5D,%5BEF,all,1%5D,%5BFI,all,1%5D,%5BFA,all,1%5D,%5BFE,all,1%5D,%5BFL,all,1%5D,%5BLP,all,1%5D,%5BOS,all,1%5D,%5BPG,all,1%5D,%5BSG,all,1%5D,%5BSP,all,1%5D,%5BSS,all,1%5D&eventLabels=true

[Jack Ireland (jack-ireland)]

A work-around for the original bug description might be to very slightly change the query time, say changing it by a fraction of a second. Say the true query time is

01:00:00

and SPoCA active region (AR) and Coronal hole (CH) detections start and end at 01:00:00. If instead we pass the query

01:00:00.001

or

00:59:59.999

then we will recover only one of the two SPoCA AR or CH detections, and that is the one we plot. More generally, let's say that the query time is "t" and the fraction of a second we pass in is dt.

If the user presses the "<-" button then we can assume that the user wants to go to the start of a feature and event, so we really want to query with a time that ensures that that event is visible, and so the query time will be t+dt. If the user presses the "->", then we can assume that the user wants to go to the end of that event and so the query time should be t-dt.

[Jack Ireland (jack-ireland)]

No-one has complained about this. Also, the data is the data - that is what is in the HEK. So we will leave it as it is.