You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As part of the discussion in #168 we allowed multiple bboxes and time intervals as part of the extent information for a collection, but for Core we basically restricted it to a single bbox/interval. I have not seen any API or client that has used multiple bboxes/intervals so far.
In the discussions in Common (see opengeospatial/ogcapi-common#91) the issue was raised that any client that just looks at the first bbox/interval and uses that will be mislead.
The idea of the change in #168 was to make it extensible for future parts. If no implementation is known to have used the multiplicity yet (we would need to verify this), it might be a good idea to address the issue by clarifying that
the first bbox/time interval always includes the complete spatial/temporal extent (e.g., all of the US);
the second to nth bbox/time interval would be a more detailed extent specification (e.g., the bboxes of the continental US, Hawai, Alaska).
Clients that just want the simple solution (a single bbox/interval) can just use the first array, just as they do now. Clients that want to process the details can do that, too, with the additional clarification about the first bbox/interval.
Any thoughts?
The text was updated successfully, but these errors were encountered:
As part of the discussion in #168 we allowed multiple bboxes and time intervals as part of the extent information for a collection, but for Core we basically restricted it to a single bbox/interval. I have not seen any API or client that has used multiple bboxes/intervals so far.
In the discussions in Common (see opengeospatial/ogcapi-common#91) the issue was raised that any client that just looks at the first bbox/interval and uses that will be mislead.
The idea of the change in #168 was to make it extensible for future parts. If no implementation is known to have used the multiplicity yet (we would need to verify this), it might be a good idea to address the issue by clarifying that
Clients that just want the simple solution (a single bbox/interval) can just use the first array, just as they do now. Clients that want to process the details can do that, too, with the additional clarification about the first bbox/interval.
Any thoughts?
The text was updated successfully, but these errors were encountered: