Review coordinate limits #99
Conversation
|
I'm all for dropping this "constraint", in particular because it's
not a constraint at all. It's a "should", which operationally means
that I may warn a user if they use coordinate values outside of that
range. Does anyone do that? And when I've warned, what do I then do
with coordinates I can't make heads or tails of?
The sentence would make sense if it said "Geometries with coordinate
values a service does not accept must lead to an error" or "...result
in NULL geometries" or anything like that. But that's not the case;
so, for server implementors, the "constraint" is meaningless. In
effect, the behavour for "odd" coordinate values is still undefined,
and indeed, a CIRCLE(-2, 23, 3) probably deserves to be handled
rather differently from a CIRCLE(3, 230, 2), not to mention things
like CIRCLE(3, 92, 4). Full disclosure: I have no idea what my
implementation does in these cases. That's probably reprehensible.
Does the "constraint" help users? Well, it would if we said "do the
implementors a favour and keep your coordinates between x an y". But
that's a again a can of worms in particular around the stitching
line, where I strongly suspect everyone wants to write
(-1, 0), (1, 1), (1, -1)
rather than
(359, 0), (1, 1), (1, -1)
(not to mention that that has a very plausible interpretation not
crossing the stitching line) -- which brings us back to the whole
question of winding senses and all the remaining polygon horror which
ADQL has no business talking about.
So, I'm all for dropping this now and, in some 2.2 WD, perhaps
inserting a reference to a standard that does a good job of
exhaustively defining such questions (DALI? Coords?).
|
|
I agree, there is a lot of grey area about coordinates, winding sense and polygons. I also agree on the point that ADQL should not say anything about how to deal about all these things...it is an interoperability question that should be answered in a more general purpose standard (as you said, DALI, Coords, or ...). |
|
Here is a new proposal. Instead of removing for good this section, I keep it without any explicit coordinate limits. I just replace limits by a reference to the coordinate system in which coordinates are expressed. This way, there is no explicit idea of "constraint". I did not want to relax this too much: as you said, it would be pretty bad that users start providing weird coordinates (e.g. ra=-10). First, because nobody will know what the ADQL processor will really do and then, because it will be really hard to come back in a future version. At least now, this sentence convey some idea of limits without giving any explicit one. Users may keep being reasonable with their coordinates. So, here I just tried to anticipate a future version of ADQL in which we will be able to make a reference to a proper standard about coordinate limits. What do you think about it? Is it a bad idea? Is the wording confusing and should be rephrased another way? |
|
On Wed, Oct 11, 2023 at 06:38:06AM -0700, Grégory Mantelet wrote:
What do you think about it? Is it a bad idea? Is the wording
confusing and should be rephrased another way?
So... I'm all for removing the MUST-s in "the numeric coordinates
MUST be in the ranges defined in" on grounds that if we do a MUST, we
have to be specific what these ranges are. It was silly to do a
MUST referring to something that's a SHOULD. That that happened in
the text so far is not great.
So... what if we changed these items to "The coordinate values are
subject to the constraints laid down in
\SectionRef{sec:functions.geom.limits}"; that way, we at least have
one central point for the MUST-s and SHOULD-s in that field, and
contradictions are less likely to just pass undetected.
The question remains what to write there. As I said above, I don't
think we can even require or recommend [0, 360] for equatorial
at this point because of polygons crossing the stitching line.
Hence, I would suggest to replace the "Coordinates SHOULD be
expressed in ranges..." paragraph with something like:
At the time of the ADQL 2.1 recommendation, no agreed-upon,
reliable, IVOA-approved convention for what ranges apply to which
reference systems exists, and this is not the place to establish
one. Until such a standard is defined, implementors MUST
accept [-180, 360] in longitude and [-90, 90] in latitude and MAY
accept other coordinate values. Query writers SHOULD NOT pass
values outside of these ranges to the geometry constructors; this
specification does not define behaviour for them in this version
but may do so in the future.
Yes, it's horribly verbose, but what can we do?
We really should try to get this clarified, including whether CIRCLE
10 91 2 is an error (which I think it is) or includes the north pole.
Should we write a bug against DALI for that?
|
|
In DALI the goal in providing limits was to eliminate the need for range reduction of angles, but I think we did inadvertently make geometry less usable (eg for coordinate systems like galactic that have a different range of valid longitude). So the language/fix in DALI should be more along those lines; it would apply to point, circle, polygon (multipolygon and shape refer back to those existing types so they are ok). We could fix (erratum) DALI by just clarifying the intent with "In equatorial coordinatesystems, ...". To make geometry usable in galactic coords, we would need to add "In coordinate systems with different valid ranges, the applicable range of values applies. In all cases, range reduction is never ???" (expected? assumed? required?) but that's something we could add in WD-DALI-1.2... here I am thinking about a TAP service with a table of geometries and the metadata for the column says the values are in galactic, or maybe a iirc, we decided that it's best for no one to do range reduction of values that are passed over the network (in params or responses) to keep the protocols simple. |
|
Ok. Can we then make a reference in ADQL 2.1 to DALI (as suggested by Markus) + make an erratum to DALI? In the meantime, Pat can work on improving this in WD-DALI-1.2. Does it sound like the way to go with this issue? |
|
agree - will work on improving DALI asap |
|
Here is an update. Should it be a SHOULD or a MUST in the "Coordinates limits" section? Should we keep the following paragraph starting with "Note that at the time ..."? |
|
I think the text you have in there now is good. |
|
Great :-) Thanks @pdowler |
As raised in RFC-2.1 (Grid and DAL WGs), coordinates limits given in this document are now obsolete since we deprecated the coordinate system argument in geometrical functions.
In ADQL-2.0 and the current state of ADQL-2.1, coordinates are limited to [0, 360] and [-90, 90]. But if any coordinate system is allowed, these ranges may not be valid anymore. Galactic coordinates are usually limited to [-180, 180] and [-90, 90].
What should we do?
I am not an expect in term of coordinate systems and coordinates limits, so, any advice here is very welcome 🙂