Draft selection table for best-in-time-and-space version of the terrain_aggregator workflow
#44
Comments
dhardestylewis
added
documentation
|
lgtm |
|
note that LPC density could be significantly greater than LPC |
|
note PDAL might provide ANPS |
replace new buckets should be delineated by other existing seamless products such as Fathom3m, USGS National Map will be substituted in at end of table as backfill data to address missing data outside of TNRIS source DEM coverage area, replacing
with
Since the best-in-time-and-space algo will be applied first, there will technically be no substitution of rows above - they will be eliminated beforehand by best-in-time-and-space algo and these other seamless products will be appended to selection table after best-in-time-and-space algo is applied note for QAQC: any interior gaps in TNRIS data coverage that are backfilled with seamless data should be explicitly described with a separate vector image |
|
replace following characteristic names for clarity:
|
conda create -n tnris_api geopandas pandas shapely |
conda env export --from-history > environment_tnris_api.yml
name: tnris_api
channels:
- conda-forge
- defaults
dependencies:
- pandas
- shapely
- geopandas |
therefore closes #37 |
@brentporter recommends referring out to TNRIS & possibly IBWC for this question
|
Draft selection table for best-in-time-and-space version of the
terrain_aggregatorworkflowSee below for detail on how to read & interpret this table.
Please let me know if you think
Each row of this table is bucketed by
pixelresolution,resolution,pixeltype,year,srid,colorinterpBasically,
I bucket the complete TNRIS Lidar tileset by the first 6 columns of this table
I throw away the following buckets, relying on separate Fathom 3m complete coverage to fill in any gaps:
Note: These buckets should be thrown away because their data is in integers, and 1m integer elevation is worse accuracy than the vertical accuracy of the Fathom 3m elevation dataset
I transform these buckets to
pixelresolution=0.3meterspixeltype= 32-bit floating point number (32BF)srid= NAD83 / Texas Centric Albers Equal Area (EPSG:3083)colorinterp=Undefinedcolor interpretationI build a VRT using the order of the buckets in the table above to select elevation data from one tile over another. The order of these buckets was determined by this order of preference of these characteristics :
pixelresolution- TNRIS Lidar DEM resolution (in meters)resolution- TNRIS Lidar point-cloud resolution (in meters)pixeltype- TNRIS Lidar DEM pixel data typeyear DESC- TNRIS Lidar project's release year, most recent year firstsrid- projection unique identifiercolorinterp- color interpretation scheme(You can read adjacent rows of the table above from left-to-right to see how one each characteristic's values were chosen over each other.)
The last 3 columns in the table above help provide context for each of the buckets :
definition :
#projects- number of projects contributing tiles to this bucketdefinition :
#tiles_in_bucket- total number of tiles in this bucketdefinition :
sum(#tiles_in_projects)- sum of number of tiles in all projects contributing tiles to this bucket#projectstells you if multiple projects contribute to a bucket#tiles_in_bucket/sum(#tiles_in_projects)tells you if a bucket contains every tile of every project that contributes to itThe text was updated successfully, but these errors were encountered: