-
Notifications
You must be signed in to change notification settings - Fork 8
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
Suggestions from Fuhu's Team - Suggestion 2 - neighbours operation for zone query #63
Comments
This still fits in the "demonstration / educational" category since it is not an operation that needs to cross the client-server category in a practical use of the API. However, like zone geometry, OGC API - DGGS - Part 1: Core could include a recommendation to include this in the zone information. A remaining question is whether we will find any non-demosntration / educational use of the zone information in a practical client/server setting. I am thinking for example of data aggregation summary for the zone -- should the resource be used for this, or should that be done with We could decide to keep |
@jerstlouis
Like your GNOSIS shows: |
@AkexStar Yes, it could all be included in the zone information response (but by geometry, I did mean specifically the geometry). Currently in the JSON response all we include is links, id, and areaMetersSquare: https://maps.gnosis.earth/ogcapi/collections/sentinel2-l2a/dggs/GNOSISGlobalGrid/zones/0-0-0?f=json But we could also have parent, children, neighbors, sibling, and geometry. in which case it is the only thing returned (we could potentially include the other things as GeoJSON properties as well). My suggestion is that we define all of those properties either in recommendations of the Core requirements class, or in a separate requirements class. A practical scenario client would not really use this, but an educational DGGS demonstration / explorer-type client might. |
We also support returning the zone geometry for the representation of Zones query when negotiating GeoJSON (or GeoTIFF), for example you can visualize the grid directly in GeoJSON.io by selecting a You can also do this for a specific collection to get only the zones for that collection: Or include a CQL2 Or with |
@jerstlouis Thanks for your demonstration! I've also recently been considering revising our APIs draft. And I have a suggestion(maybe a question) to your GeoJSON, such as bellow: {
"type": "Feature",
"id": 678,
"geometry": {
"type": "Polygon",
"coordinates": [
[
[
92.8125,
36.5625
],
[
93.1640625,
36.5625
],
[
93.1640625,
36.9140625
],
[
92.8125,
36.9140625
],
[
92.8125,
36.5625
]
]
]
},
"properties": {
"feature::id": 678
}
} The |
@AkexStar The "id" (and the feature::id) are only the internal feature ID. But again I point out that this "GeoJSON" output mode of zones is purely for educational / demonstration purposes. or slightly less compact, but avoiding a custom binary encoding, simply JSON IDs: https://maps.gnosis.earth/ogcapi/collections/SRTM_ViewFinderPanorama/dggs/GNOSISGlobalGrid/zones?zone-level=8&compact-zones=true&filter=Elevation%3E3000&f=json Those are the formats that could actually be used in practice, and provide a compact way to exchange / return an area of interest either to a DGGS client performing a Where is it? type query, or between two servers as part of a complex DGGS integration / processing chain, using the same grid. |
Based on the document, there are parent, child, and sibling operations in ZoneQuery, but we failed to find the ‘neighbors’ operation, which is finding the neighbors of zone. We indeed find end-point /collections/{collectionId}/neighbors in the Testbed-16 document, and it gets the neighboring zones to one given zone. We think /dggs/{dggsID}/zones/{zoneID}neighbors might be more suitable with query parameters the number of neighbors. For GeoSOT 2D zones (quadrilateral), their neighbors are zones with common edges or vertices and edges, which means the number of neighbors can be 4 or 8; for 3-dimensional zones, they will have 6, 18, or 26 neighbors differentiated by common vertices, edges, and faces. This is our preliminary idea which takes the number of neighbors as query parameter, please don’t hesitate to propose better opinions.
The text was updated successfully, but these errors were encountered: