-
Notifications
You must be signed in to change notification settings - Fork 22
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support a list or a single number in localization #120
Support a list or a single number in localization #120
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we have a single description for each field, like this?
"ra_uncertainty": {
"description": "fill me in",
"oneOf": [
{"type": "number"},
{"type" "array", "maxItems": 2, "items": {"type": "number"}}
]
}
"type": "array", | ||
"maxItems": 2, | ||
"description": "Uncertainty in RA [deg] with optional asymmetric errors, measured from the RA in the schema; respective ex: [r], [r1], [l1-, l1+]. For ellipse, ra axis is r1 or semi-major axis." | ||
"description": "Uncertainty in RA [deg], measured w.r.t. RA. A single number for circle, and ellipse, RA axis alligns with semi-major axis. For rectangle, use optional aymmetric errors array, [l1-, l2+].", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What does "Uncertainty in RA measured with respect to RA" mean?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So there have been confusion, about it's understanding. It's uncertainty error measured from RA centre like 2 (-+0.2) or, shape coordinates 2 (1.8, 2.2), so tried to be more explicit, please help with better wordings.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In that case, the name of this field is wrong. It is the uncertainty in the semimajor axis.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But but if it's rectangle?
"type": "array", | ||
"maxItems": 2, | ||
"description": "Uncertainty in RA [deg] with optional asymmetric errors, measured from the RA in the schema; respective ex: [r], [r1], [l1-, l1+]. For ellipse, ra axis is r1 or semi-major axis." | ||
"description": "Uncertainty in RA [deg], measured w.r.t. RA. A single number for circle, and ellipse, RA axis alligns with semi-major axis. For rectangle, use optional aymmetric errors array, [l1-, l2+].", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"description": "Uncertainty in RA [deg], measured w.r.t. RA. A single number for circle, and ellipse, RA axis alligns with semi-major axis. For rectangle, use optional aymmetric errors array, [l1-, l2+].", | |
"description": "Uncertainty in RA [deg]. A single number for circle, and ellipse, RA axis alligns with semi-major axis. For rectangle, use optional aymmetric errors array, [l1-, l2+].", |
"type": "array", | ||
"maxItems": 2, | ||
"description": "Uncertainty in Dec [deg] with optional asymmetric errors, measured from the Dec in the schema; respective ex: [r2], [l2-, l2+]. Not reported if circular and Dec axis is r2 or semi-minor axis for ellipse." | ||
"description": "Uncertainty in Dec [deg], measured w.r.t. Dec, not reported for circle. A single number for ellipse, Dec axis alligns with semi-minor axis. For rectangle, use optional aymmetric errors array, [b1-, b2+].", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"description": "Uncertainty in Dec [deg], measured w.r.t. Dec, not reported for circle. A single number for ellipse, Dec axis alligns with semi-minor axis. For rectangle, use optional aymmetric errors array, [b1-, b2+].", | |
"description": "Uncertainty in Dec [deg], not reported for circle. A single number for ellipse, Dec axis alligns with semi-minor axis. For rectangle, use optional aymmetric errors array, [b1-, b2+].", |
I spoke with @jracusin about this. I think that the positional uncertainty fields are poorly conceived and named and need a redesign. What we call Please study how these fields are named and encoded in other prominent software applications in astronomy, and propose names and descriptions that are as consistent as possible with prior work:
|
@Vidushi-GitHub, please post an update with your progress on this. |
Yes, had a discussion with @jracusin. She agreed to correct the description. Vera Rubin uses uncertainty word. Elliptical uncertainty ex: https://gcn.nasa.gov/circulars/35535. We can't shift the center, to make errors symmetric, as mean can be different than negative/positive bars, ex bayesian posterior cases. |
This change is not an improvement over the current situation. There should be two positional uncertainty fields for uncertainty in orthogonal directions and one position angle field. All three fields should be scalar. You give two reasons for having array-valued positional uncertainties, but I find neither convincing:
I insist that the only localization parametrization that we should support (other than a freeform HEALPix map) is a bounding ellipse. Based on prior astronomy software that reports position uncertainty on points, I strongly recommend giving scalar three parameters: the length of the semi major axis, the length of the semi minor axis, and position angle of an ellipse containing N% probability. If the semi minor axis is omitted, then it is assumed to equal the semi major axis. If the position angle is omitted, then it is assumed to be zero. |
What about following, with no min change wrt previous and better description? I am still trying more options. Validation is failing w/t array, so for trials copy-pasted here. "uncertainty_shape": { |
e0f2abc
to
6553bf5
Compare
Co-authored-by: Judy Racusin <[email protected]>
Co-authored-by: Judy Racusin <[email protected]>
May look redundant, but just for simplicity, I have tried to keep Josh feedback as it is and have added as union. I feel may be in future community start shifting to proposal 2. |
"position_error_pa" | ||
] | ||
} | ||
] | ||
}, | ||
"containment_probability": { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we go with this approach, containment_probability should also be part of error.
"type": "number", | ||
"description": "Anti-clockwise position angle from RA axis [deg]. Used if uncertainty_shape ellipse or rectangle is tilted w.r.t. standard (RA, Dec) coordinate.", | ||
"default": 0 | ||
"error": { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
'error' is a bit too generic, there can be error in many quantities. We could call it position_error. This nesting seems to break the flattening of the schema, and be a bit clunky.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Vidushi-GitHub, I asked you to make position_error
a union of a single number or an array, with the elements of that array being a, b, and pa. This is not an array; it's a composite data structure. None of our other core schema contain composite data types. Let's stick to that convention.
Replace the localization properties `uncertainty_shape`, `ra_uncertainty`, `dec_uncertainty`, and `position_angle` with a single property called `ra_dec_error`. The original localization uncertainty properties were ill-conceived in many ways: 1. The names `ra_uncertainty` and `dec_uncertainty` were misleading. For example, for ellipses, these fields actually represented the lengths of the semi-major and semi-minor axes, and not the uncertainty in ra or dec. 2. The names of these properties were inconsistent with other schema. Every other uncertainty property exept for these has a name ending in `_error`, not `_uncertainty`. 3. The `rectangle` shape was not useful. The most significant examples of quadrilateral localization regions are IPN error boxes. However, these are parallelograms, not rectangles, so the shape would have been under-specified. We have observed that all current missions in GCN either report error circles or HEALPix maps. Given that observation, this patch replaces all of the ill-conceived localization properties with a single `ra_dec_error` field which is the radius in degrees of the error circle. In the future, there might be a mission that requires ellipses. We won't deal with that now, but in that event we would have a few different backwards-compatible options. For example, we could: - Treat the `ra_dec_error` field as the semi-major axis, and add optional fields `ra_dec_error_b` and `ra_dec_error_pa` for the semi-minor axis and the position angle, respectively; or - Allow `ra_dec_error` to be either a single scalar, or an array of up to three numbers, representing the semi-major axis, semi-minor axis, and position angle, respectively. Fixes nasa-gcn#120.
Co-authored-by: Judy Racusin <[email protected]>
Co-authored-by: Leo Singer <[email protected]>
No description provided.