Skip to content
Snippets Groups Projects
Commit 72990cbd authored by Laura, Jason R's avatar Laura, Jason R
Browse files

Updated to standards based on Dec meeting

parent 9122e86f
No related branches found
No related tags found
No related merge requests found
--- ---
geekdocCollapseSection: false geekdocCollapseSection: false
weight: 30 weight: 30
--- ---
\ No newline at end of file
The standards enumerated herein are intended to facilitate data interoperability. How is the lunar SDI defining data interoperability? A user of data made available by a data provider, via a data portal that has adopted the Lunar SDI standards can reasonably assume that different data sets will:
- Be made available in the same, [GIS ready formats]({{ ref "data_formats"}}). Data conforming to these standards are interoperable at a technical level by the tools and technologies use to analyze and view the data.
- Have been created or modified to use the same [underlying datums and map projections]({{ ref "data_standards"}}). This ensures that the products will be co-aligned to the level of their control to a common geodetic coordinate reference frame[^1]. Data conforming to these standards are interoperable at the spatial level and can be used for spatial analyses.
- Be documented similarly, such that users are [provided with common metadata]({{ ref "metadata_standards" }}) including information on data product accuracy, fitness-for-use, and know issues with the data. Data conforming to these standards are semantically interoperable and allow users to make informed decisions about whether data are suitable for the analyses they are performing.
Lunar SDI data that are compliant with these standards are said to be interoperable. From a user's perspective, these data are suitable for data discovery, visualization, and analysis. From a data creator's perspective, making their data available in an interoperable way ensures that new products are used with the corpus of existing products, thereby increasing adoption. From a data provider's perspective, releasing interoperable data into a broader ecosystem ensures similar successes, a provider's offerings can be used immediately by users or aggregated into larger scope tools by other data providers.
For U.S. scientists, researchers, and technical staff, the standards described herein are designed to ensure compliance with the NASA published [SMD Policy Document SPD-41 a](https://science.nasa.gov/science-red/s3fs-public/atoms/files/SMD-information-policy-SPD-41a.pdf).
[^1]: See either [Laura and Beyer (2021)](https://iopscience.iop.org/article/10.3847/PSJ/abcb94) or the [Foundational Data Products webpage](https://fdp.astrogeology.usgs.gov/fdp/about/) for a description of the different levels of photogrammetric control.
\ No newline at end of file
...@@ -4,6 +4,14 @@ weight: 51 ...@@ -4,6 +4,14 @@ weight: 51
--- ---
**DRAFT** **DRAFT**
Many geologic maps exist which can be used as a basis for setting cartographic standards. What other symbologies should be standardized with the Lunar SDI? ### Map Projections
- Data are provided in a simple cylindrical (equirectangular) map projection.
- Data are orthorectified to a sphere using the IAU radius => 1737.4km (sphere)
- Data are made available in 0 – 360 positive East coordinate system with a center longitude of 180 degrees using planetocentric latitude.
- For observational data, pixel scale or resolution should be maintained at native scale, (i.e., do not up sample or down sample data.)
- For derived data (e.g., DTMs), data should be made available at a reasonable resolution that avoids extrapolation of information.
- Data for polar areas (latitudes > 65˚ North or South) should use a polar stereographic projection centered at the pole.
### Vector Symbology
- The OGC maintained [Styled Layer Descriptor](https://www.ogc.org/standards/sld) standard will be used for vector symbology for all data in the GeoPackage format.
...@@ -6,7 +6,7 @@ weight: 31.1 ...@@ -6,7 +6,7 @@ weight: 31.1
**DRAFT** **DRAFT**
### Body Parameters ### Body Parameters
The Report of the IAU Working Group on Cartographic Coordinates and Rotational Elements: 2015 (2018) and the Final Report of the Lunar Critical Data Products Specific Action Team (LCDP-SAT) body parameters will be used. This includes a sphere radius of 1737.4km, the 2008 JPL DE 421 ephemeris rotated to the mean Earth/polar axis (ME) system and rotation parameters as defined in Table 2 (Archinal, et al., 2018). The Report of the IAU Working Group on Cartographic Coordinates and Rotational Elements: 2015 (2018) and the [Final Report of the Lunar Critical Data Products Specific Action Team](https://www.lpi.usra.edu/mapsit/standup-committees/LCDP-SAT-REPORT-20211110.pdf) (LCDP-SAT) body parameters will be used. This includes a sphere radius of 1737.4km, the 2008 JPL DE 421 ephemeris rotated to the mean Earth/polar axis (ME) system and rotation parameters as defined in Table 2 (Archinal, et al., 2018).
### Horizontal and Vertical Datum ### Horizontal and Vertical Datum
Reference sphere defined as 1737.4km as defined by the IAU (IAU;2018). Proxy products usable to tie to the vertical reference frame (and have topography or shape) include: Reference sphere defined as 1737.4km as defined by the IAU (IAU;2018). Proxy products usable to tie to the vertical reference frame (and have topography or shape) include:
...@@ -21,14 +21,7 @@ The horizontal datum to be used is the 2008 JPL DE 421, which, as per the LCDP-S ...@@ -21,14 +21,7 @@ The horizontal datum to be used is the 2008 JPL DE 421, which, as per the LCDP-S
At this time, no global visible observations are usable to rigorously align to the horizontal reference frame. At this time, no global visible observations are usable to rigorously align to the horizontal reference frame.
### Map Projections ### Map Projections
- Data are provided in a simple cylindrical (equirectangular) map projection. - See [cartographic standards]({{ ref "cartographic_standards" }}).
- Data are orthorectified to a sphere using the IAU radius => 1737.4km (sphere)
- Data are made available in a -180 – 180 (CLON 0; web maps hate this) OR 0 – 360 (lots of data in this system; historical argument) Positive East coordinate system with a center longitude of 180 degrees and use planetocentric latitude.
- For observational data, pixel scale or resolution should be maintained at native scale, (i.e., do not up sample or down sample data.)
- For derived data (e.g., DTMs), data should be made available at a reasonable resolution that avoids extrapolation of information.
- Data for large spatial scale (e.g., 1:24000), small spatial extent maps, (e.g. landing sites) can be provided in a local stereographic (candidate to also have a grab bag to also include gnomonic and orthographic) centered on image.
- Data at mid-latitudes (35˚ - 65˚ N/S) data providers are encouraged to also provide data in a Lambert Conformal Conic Projection with a longitude origin of 0 and standard parallels of 33˚ and 45˚ N/S (as appropriate). (discuss; this is a classic North America LCC)
- Data for polar areas (latitudes > ??˚ North or South) should use a polar stereographic projection centered at the pole.
### Ephemeris Information ### Ephemeris Information
- All sun, spacecraft, sensor, and target body ephemeris information is to be provided either by [Navigation and Ancillary Information Facility (NAIF)](https://naif.jpl.nasa.gov/naif/) as SPICE kernels or in NAIF SPICE compliant format by another provider (e.g., a mission team). This includes sensor and target positions, velocities, and orientations as well as sensor parameters such as distortion models. - All sun, spacecraft, sensor, and target body ephemeris information is to be provided either by [Navigation and Ancillary Information Facility (NAIF)](https://naif.jpl.nasa.gov/naif/) as SPICE kernels or in NAIF SPICE compliant format by another provider (e.g., a mission team). This includes sensor and target positions, velocities, and orientations as well as sensor parameters such as distortion models.
\ No newline at end of file
...@@ -5,6 +5,8 @@ weight: 70 ...@@ -5,6 +5,8 @@ weight: 70
**DRAFT** **DRAFT**
### Licensing
- Data should be licensed using the open [CC0-1.0](https://creativecommons.org/publicdomain/zero/1.0/) license. When allowable by the funding agency, data may also be licensed using [CC BY 2.0](https://creativecommons.org/licenses/by/2.0/), thereby requiring attribution, or [CC BY-SA 2.0](https://creativecommons.org/licenses/by-sa/2.0/) thereby requiring attribution and including a share-alike clause requiring derived products to adopt the same license.
### Metadata Content ### Metadata Content
- Data will have qualitative process and usability information available in text format that describes (1) a description of the data set, (2) the process used to create the data, (3) the available assets or files within a data set, (4) the accuracy, errors, and identification of known issues with the data set, (5) the qualitative usability of the data set (as mediated by the data provider or steward), (6) textual description of the proposed update cadence for this data set, and (7) optionally textual links to other data sets of potential interest to users of this data set. - Data will have qualitative process and usability information available in text format that describes (1) a description of the data set, (2) the process used to create the data, (3) the available assets or files within a data set, (4) the accuracy, errors, and identification of known issues with the data set, (5) the qualitative usability of the data set (as mediated by the data provider or steward), (6) textual description of the proposed update cadence for this data set, and (7) optionally textual links to other data sets of potential interest to users of this data set.
...@@ -12,7 +14,12 @@ weight: 70 ...@@ -12,7 +14,12 @@ weight: 70
- Accuracy should be described using the [ISO 19157:2013 standard](https://wiki.icaci.org/index.php?title=ISO_19157:2013_Geographic_information_-_Data_quality). - Accuracy should be described using the [ISO 19157:2013 standard](https://wiki.icaci.org/index.php?title=ISO_19157:2013_Geographic_information_-_Data_quality).
### File Formats ### File Formats
- Data will have an FGDC compliant XML metadata file. This file is to be as compliant as possible and should use the planetary domain extension. - Data will have an [ISO compliant XML metadata file](https://wiki.icaci.org/index.php?title=ISO_19157:2013_Geographic_information_-_Data_quality). This file is to be as compliant as possible and should use the planetary domain extension.
- Data will have a Spatio-Temporal Asset Catalog (STAC) metadata JSON file. - Data will have a Spatio-Temporal Asset Catalog ([STAC](https://www.google.com/search?client=safari&rls=en&q=spatio-temporal+asset+catalog&ie=UTF-8&oe=UTF-8)) metadata JSON file.
- Data should have a provenance file that minimally describes the creation of the data. When possible, the provenance file will support complete reproduction of a derived data product by replicating commands provided to processing tools. - Data should have a provenance file that minimally describes the creation of the data. When possible, the provenance file will support complete reproduction of a derived data product by replicating commands provided to processing tools.
### Data Linkages and Unique Identifiers
- Data derived from lower level data, stored in a long term archive, linkages back to the source data should be provided[^1].
- Data not easily derived from lower level data should include a unique identifier (e.g., a DOI).
[^1]: Combined with the provenance files, this allows users to recreate products from source files, reproducing or modifying the processing pipeline as desired.
\ No newline at end of file
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Please register or to comment