Update instrument.json to include a target. #1014
Conversation
We have been using the STAC specification for non-terrestrially focused data, e.g., the Mars. For non-Earth focused data, we need some mechanism to identify the target of the observation. By target, we mean the planet, moon, asteroid, comet, etc. that was the primary objective of the observation. If a given instrument imaged a single body over the mission lifecycle, we could make use of the mission string. For many missions, observations are captured enroute (for example a few quick snaps of Venus during a gravity assist on the way to the outer planets) or multiple targets can exist (sensors targeting Mars can be rolled to capture data of Phobos for example).
The instrument section of the item specification seems to be the most appropriate place to inject a target keyword. We envision the target keyword being used to identify the body/bodies which was the target of a particular observation. For example:
```
{"instruments":["Kaguya Terrain Camera"],
"mission":"Kaguya/SELENE",
"gsd": "6",
"target":"Moon"}
```
|
Thanks for the PR @jlaura! I love you pulling us to make sure STAC works for other planets. Generally for new fields we only put the most widely applicable ones in the core, and then the extensions define additional fields. Once an extension has lots of uptake then we'll put it into the core. It probably makes sense to make a 'planetary' extension, where you can add in this. And it'd be great if there are other fields you find yourself using in your STAC's to put them there. So you'd be welcome to make a PR to extensions - it doesn't have to be big or fancy, but do follow the general template of the other extensions. |
|
@jlaura definitely encourage you to create an extension for this, even if it's only this one field right now. I'd also say that the extension should attempt to standardize the values. I usually like lowercase or numbers, so maybe use the name for planets ( Though, now that I think about this more -- how do you do EPSG:4326 on Mars? |
|
I am really happy to put in an extension. I can keep this PR open for some of this discussion or we can move it into an issue as well. I defer to you all. Lowercase names would be one option. Alternatively, we have numbers assigned to planetary bodies, moons, comets, etc. The International Astronomical Union (IAU) has some really nice naming convention standardizations. For minor planets like Pluto, we have a number (134340) big old list of minor planets. In the literature bodies will be identified by name and/or number. So, perhaps it is best to use name and/or IAU code with each being a separate entry. We have a prototype solar system (ssys:*) extension that we have played around with that I can float those ideas in. As for planetary datums, ellipsoids, and projections, we get those from the IAU as well most of the time. For example, here are geographic coordinates with Mars as an ellipsoid and Mars using planetocentric latitudes. One of the larger struggles that we have when working with terrestrial standards are hard coded semi-major and semi-minor axes, and hard coded WGS84 / EPSG:4326. Ideally, we need to be able to define the ellipsoid (up to a tri-axial shape) and override the projection using either the standard IAU codes (I believe they are included in GDAL these days) or custom CRSs. I do have to say that the stac-spec has been great to work with because of how light weight it is and because of how standards compliant/interoperable it is. |
I'd definitely make both of those as fields, and decide which one you want to be 'required', but encourage people to use both. And yes, linking to existing naming conventions is the best route by far - point at an existing, accepted standard instead of coming up with our own.
Sounds like you discovered this, but with the projection extension you can use projjson or wkt2 to define it, so hopefully that would be sufficient? EPSG code is required, but you can enter null for it. Or if there's a user space EPSG code that GDAL recognizes that would work too.
Great to hear! That's been a clear goal of ours, so it's good to get feedback that it's working for you. |
I'd say move to an issue, or just start a new PR with a more descriptive title to get across the new extension. Note that with #946 we're going to be putting extensions into https://github.com/stac-extensions so we'll have you move a PR over into its own repo there when we get to it. |
Ah, so you're using STAC as a structure, but not adhering the semantics of the geometry being 4326? I feel like this might open up a whole can of worms, but maybe there's a place for an extension that allows for the geometry to be something other than 4326, like GeoJSON 2008 originally had? |
|
@jlaura I've been thinking about this some, and we had a short discussion during the STAC Sprint mtg this morning. One way to implement this is as I described above, by adding a field to Item for CRS that has the PROJJSON or WKT value, and putting a non-EPSG:4326 Geometry in the However, another option that would still allow conformance with is to set |
|
Closing this PR after discussion of other options. This is a very cool use of STAC! |
|
Apologies for radio silence on my side - I've been working with PySTAC and building some star files for Europa. My colleague @thareUSGS is going to open a PR with our ssys (solar system) extension for the target entry. Either approach is totally cool for handling non-earth centric stuff. I would personally advocate for not having a hard coded 4326; particularly since 4326 is going to go away at some point. I defer to you all that are steeped in the STAC spec. |
We have been using the STAC specification for non-terrestrially focused data, e.g., Mars. For non-Earth focused data, we need some mechanism to identify the target of the observation. By target, we mean the planet, moon, asteroid, comet, etc. that was the primary objective of the observation. If a given instrument imaged a single body over the mission lifecycle, we could make use of the mission string. For many missions, observations are captured enroute (for example a few quick snaps of Venus during a gravity assist on the way to the outer planets) or multiple targets can exist (sensors targeting Mars can be rolled to capture data of Phobos for example).
The instrument section of the item specification seems to be the most appropriate place to inject a target keyword. We envision the target keyword being used to identify the body/bodies which was the target of a particular observation. For example:
Related Issue(s):
No opened related issue at this time. I am quite happy to use the test above as the start of an issue on the repo.
Proposed Changes:
PR Checklist: