Lunar Data Format Standards
- Data in raster format should be provided as cloud-optimized GeoTiffs(COG), complying with the cartographic standards.
- Rationale: a COG is “just” a GeoTIFF with additional header information that supports data streaming. COGs are preferable as data volumes increase and local analyses of large data volumes become less tractable. Legacy TIFFs can be converted to COGs with little overhead beyond the (re)processing costs.
- Data in vector format should be provided in OGC GeoPackage format with information stored in decimal degrees (i.e., no map projection applied) or in a map projected form complying with the cartographic standards
- Rationale: More widely used vector data standards such as Shapefile are rapidly approaching their End-of-Life. Therefore, we suggest that data users (who often create vector data sets) consider shifting their workflows slightly. See the data examples for suggestions on creating GeoPackage files natively or converting shapefiles into GeoPackage files. Vector data provided in formats other than GeoPackage should include files for proper representation of features without the need for propriety visualization software. This is especially important for data such as geologic maps where the symbology are essential to the interpretation of the data.
- Data in raster format should be provided as cloud-optimized GeoTiffs, complying with the above projection standards. These data will be accessed via their STAC data files. Alternatively, data in raster format can be provided using an OGC-compliant WMS service. This service must encode a proper IAU 2015/2018 projection code.
- Rationale: As data volumes increase, data formats that are both interoperable with existing tooling and performant are required. COGs and OCG WMS both provide remote, streaming data access, a means to communicate spatial metadata and work with the vast majority of spatial tools. For interoperability, standards-compliant projection information must be explicitly included in the data.
- Data in vector format should be served using an OCG-compliant WFS or WMTS service or a vector tile server. Most importantly, the server must encode a proper IAU 2015/2018 projection code.
- Rationale: The complexity of vector data, in terms of vertex count and symbology, is ever-increasing. These OGC standards provide high interoperability and encode projections (something that standards like GeoJSON fail to include).
- The STAC-API specification (a remotely accessible search service) will be used to support metadata query and data discoverability.
- Rationale: The STAC-API is the preferred search API for lunar SDI-endorsed data. This API supports spatial, temporal, and attribute-level queries, is maintained by a large group of corporate, government, and non-governmental organizations, and has proven scalability beyond the raw count of planetary observations. Data providers meet the shared discovery expectations of tool developers and users via a STAC-API-compliant search endpoint.
- Lidar (point cloud) data will be provided using the Cloud Optimised Point Cloud (COPC) or Entwine Point Tile (EPT) format with proper WKT or
proj:json
projection information. Lidar data are encouraged to use an STAC metadata file for improved discoverability. Further, when possible data should be provided in gridded and ungridded (e.g., point cloud for DTMs) forms.- Rationale: Terrestrial lidar projects of varying scales have coalesced around several highly interoperable formats such as LAS and LAZ. These formats, released over 20 years ago, are developed and maintained by the American Society for Photogrammetry and Remote Sensing. The COPC and Entwine formats are small extensions to LAS/LAZ that improve cloud-based streaming and data expansion without sacrificing interoperability.