Include following information in TNRIS Lidar metadata database

[Khushbooagarwalhub]

• File name of DEM as found on Stampede2
• Actual file type of each DEM (.dem,.img,.tif)
• CRS
• Geographic CRS
• EPSG
• Bounding box
• Accuracy calculations for reprojections from source CRS to NAD83(2011) / UTM zone 14N & NAD83(2011) Texas Centric Albers Equal Area
• Polygonizing the rasters
• File size

[dhardestylewis]

Probably best method to collect this data: https://gdal.org/drivers/raster/postgisraster.html

[dhardestylewis]

Reasonings for each:

• File name of DEM as found on Stampede2:

  • this is what we need to georeference each file in the first place

• Actual file type of each DEM (.dem,.img,.tif):

  • for some TNRIS projects and particular files, the file extension does not correspond with the actual file format,
  • this could break functionality of some libraries like RasterIO, for functions that naively assume the extension to be correct

• CRS:

  • should be collected as a WKT string
  • there are sometimes minor differences in WKT strings between projects that may otherwise have the same EPSG

• Geographic CRS:

  • should be collected separately to support mosaicking by geographic CRS as mentioned here: https://gis.stackexchange.com/a/127825/193758

• EPSG:

  • will be used for actual mosaicking: if EPSGs equal, then projections will be assumed to be the same

• Bounding box:

  • initial method to produce these polygons as a vector image from the rasters' bounding boxes: https://gis.stackexchange.com/questions/352445/make-shapefile-from-raster-bounds-in-python
  • nice to have: determining max gaps for slight rotational/projection differences in each corner

• Accuracy calculations for reprojections from source CRS to the following:

  • CWE uses NAD83(2011) / UTM zone 14N for products produced in Texas
  • TDIS will use NAD83(2011) / Texas Centric Albers Equal Area

• File size:

  • needed to estimate memory usage of algorithms in advance -- for example, if it is known that a particular algo will need ~4x the size of the initial DEM in simultaneous memory usage in order to succeed

• Polygonizing the rasters:

  • not initially needed,
  • computationally expensive,
  • most ideal means of expressing coverage