-
Notifications
You must be signed in to change notification settings - Fork 5
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
update xtype ref to MOC-2.0 and add some MIN/MAX clarification #14
Conversation
@@ -762,6 +768,9 @@ \subsubsection{Point} | |||
In spherical coordinates, all longitude values must fall within [0,360] and all | |||
latitude values within [-90,90]. | |||
|
|||
There is no general purpose definition of minimum and/or maximum point values, but | |||
specific services may define something that is applicable in a more limited context. |
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.
Is it worth calling out service sky coverage specifically? I am guessing that is what is meant by 'limited context'
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.
The difficulty is that one can have scalar min/max or min/.max values that are the same type as the param (eg xtype="point" here)... ideally, you'd rather convey sky coverage ~ max as a general region on the sky (something like polygon or moc) and not "the biggest point.
Maybe the "min point" and "max point" is sort of like a coordinate range, but we don't have any use like that so I'd rather stay clear for now. The other uses of max come from datalink service descriptors describing soda params, so they have some existing use we're trying to describe here.
thnx James; will wait for other editors to have a look at this text. |
This PR also now includes definition/explanation of min/max for various xtypes (related to VOTable).
I've tried to be careful here to not specify beyond what we currently do as there is risk to specify further things we haven't implemented. There's also a bit of forward reference to SODA as an example that I'm not really happy about making, but I think in DALI that's OK because it's goal is commonality and usually is pulled up from other specs.