ENH: Handling open RANGE intervals for POS options: handling Inf

[bsipocz]

I was following up on recent reports of SIAv2 inconsistencies, and run into the issues that currently we don't allow +/- Inf for POS values, though that standard (e.g. SIA2 2.1.1 section) lists them as valid values for e.g around the poles or for all sky.

Should we allow these? It will need a bit of a hackery in the validator, but can make it work.

# North pole: (0, 360, 89, +Inf)]
# All sky: (-Inf +Inf -Inf +Inf)

(Also, with the very recent #594 it became clear that we have these position parsers both in DAL and in registry. Now the two are not exactly the same, so may not worth spending too much effort to cleanup, but still, we may consider doing it at some point.

[bsipocz]

However, trying to use Inf in an actual query gets back an error message from the server side, too, UsageFault: BAD_REQUEST: dec value inf lies outside valid interval [-90, 90] so maybe we should just leave it alone, here, too.

https://irsa.ipac.caltech.edu/SIA?COLLECTION=wise_allwise&COLLECTION=twomass_allsky&POS=range+164.7+165.8+89.8+Inf&RESPONSEFORMAT=html

[bsipocz]

We can/should also support more SkyCoord/angle inputs. I wrote up what I had in mind here: #409 (comment)

[msdemlei]

On Mon, Sep 16, 2024 at 05:03:00PM -0700, Brigitta Sipőcz wrote: However, trying to use Inf in an actual query gets back an error message from the server side, too, `UsageFault: BAD_REQUEST: dec value inf lies outside valid interval [-90, 90]` so maybe we should just leave it alone, here, too. https://irsa.ipac.caltech.edu/SIA?COLLECTION=wise_allwise&COLLECTION=twomass_allsky&POS=range+164.7+165.8+89.8+Inf&RESPONSEFORMAT=html

Hm... *in principle*, I don't think we should let buggy server-side implementations keep us from implementing the protocols as intended. Half-open intervals are a requirement in 1D intervals (on both the client and the server). For geometries I think it would be much preferable if we had proper, first class circles, polygons, and <gasp> mocs on input and hid the ugly RANGE from our (non-wicked) users entirely. I notice with some interest that I have not bothered to implement the open geometry RANGE-s either: https://dc.g-vo.org/__system__/siap2/sitewide/siap2.xml?POS=RANGE+164.7+165.8+89.8+%2bInf&MAXREC=50 Given that pgsphere cannot do Inf in its sbox either, handling it isn't straightforward; I suppose I'd have to replace the Infs with 0, 360, -90 and 90 at the respective places, and there's *very* little to be gained by that. I don't think a single client operation becomes simpler if I implement it like that, but I can imagine any number of ways in which this can fail. I'd say the Infs in RANGE are just a very practical interoperability trap. I will acknowledge that CADC did implement Inf handling: https://ws.cadc-ccda.hia-iha.nrc-cnrc.gc.ca/sia/v2query?POS=RANGE+164.7+165.8+89.8+%2bInf&MAXREC=50 Still, this would seem to me a case of over-generalisation: On 1D cartesian ranges, there's Inf to signify open ranges. On a spherical 2D "range" object, this concept really does not apply, and it should not have pulled over from 1D cart to 2D spher. Rather than hacking around, I'd say we ought to report back to the IVOA that in POS=RANGE, Inf handling is broken on many services and doesn't seem to have any merits, as clients have complete control about "up to the pole" or "until the stitching line" anyway. And we could ask them to drop Infs here. Or even better, drop RANGE entirely?

[bsipocz]

Rather than hacking around, I'd say we ought to report back to the
IVOA that in POS=RANGE, Inf handling is broken on many services and
doesn't seem to have any merits, as clients have complete control
about "up to the pole" or "until the stitching line" anyway. And we
could ask them to drop Infs here. Or even better, drop RANGE
entirely?

This sounds good to me, and thank you for doing a better due diligence and checking multiple services for this. Dropping Infs sounds great to me, but I haven't got enough insight on how disruptive would be to drop RANGE.

Would you mind doing the reporting back to the appropriate IVOA channels?

[msdemlei]

On Tue, Sep 17, 2024 at 10:13:28AM -0700, Brigitta Sipőcz wrote: Would you mind doing the reporting back to the appropriate IVOA channels?

I will keep it in mind, sure. Let's see what we can do.