Lidar point clouds (LPC), elevation models, GPS data, image mosaics, and aerial images from natural color (RGB) camera collected during UAS operations at Lower Darby Creek, Darby Township, Pennsylvania, March 2025

GROUND CONTROL: Over the two days of data collection, 20 AeroPoint2 GCPs were spaced out over the field site and left on for at least 30 minutes to collect GNSS data. One Aeropint failed on day one so only 19 are recorded. After collection the AeroPoint2s data were uploaded via a Wi-Fi connection and run through a post-processing kinematic algorithm of the Propeller network to get corrected positions. The data were exported in NAD83(2011) (EPSG:6318) to produce latitude, longitude, and ellipsoid heights, and then NAD83(2011)/UTM zone 18N (EPSG:6347) and NAVD88 (EPSP:5703) with GEOID 18 to produce easting and northing and orthometric heights. These were exported to a CSV file and named 2025011FA_Clearview_Mar_GCP.csv. An Emlid RS2+ was set up as a base station using an RTK FIX on the highest section of boardwalk to record GNSS data for post processing the lidar data. An Emlid RS3 with tilt compensation was connected to the base to take RTK three-second averaged check shots the parking lot, beach, and AeroPoint2s, data were provided in 2025011FA_Clearview_Mar_Emlid_RTK.csv
UAS FLIGHTS: The lidar sensor was a 905 nm wavelength Hesai XT32-M2X with a 90 / 40.3 degree horizontal and vertical field of view (FOV). It is a rotating sensor, generating up to three returns with an effective point rate for a single return of 160k pts/s. The camera module uses the Wingtra MAP61 61-megapixel (MP) camera with a 17 mm lens. The system uses a NovAtel OEM7500 multi-frequency, high precision GNSS receiver. The lidar data was saved to the 256 GB thumb drive in eight different *.data files. The RGB images are saved as *.JPG files. The lidar data were collected with the Wingtra UAS flying 61 meters above ground level with northeast-southwest transect passes. The camera module was set to take images based on GNSS coordinates calculated by Wingtra based on the flight area. After the flights the lidar and RGB data were taken off their respective sensor. Note, the geotagged positions embedded in the imagery Exif information were in EPSG:4326, this is the only option in the software. The positions were converted to EPSG:6347 and EPSG:5703 in the imagery locations file (2025011FA_Clearview_Mar_ImageryLocations.csv) and were accounted for when transforming to EPSG:6347 and EPSG:5703 in the products.

RAW IMAGERY: The W1G2 images were geotagged in WingtraHub using the base station RINEX file and OPUS corrected location of the base. All images were processed to add additional information required by the USGS to the Exif headers using ExifTools (https://exiftool.org/, version: 12.06), and the files were renamed to a unique identifier to avoid any possibility of duplicate names. These steps are described here. 1. ExifTools was used to tag each photo headers following the Imagery Data System EXIF Guidance. Attributes (e.g. Credit, Copyright, UsageTerms, ImageDescription, Artist, etc) were stored in a csv file and written to each image with the command:' exiftool -csv="C:\directory\name\EXIF.csv" C:\directory\name\of\photos *.JPG ' To read out the photo information to a csv when in the directory with the photos the command is: exiftool -csv *.JPG > directory\name\allheaders_out.csv 2. All the images were renamed using a Python script to ensure unique filenames and compliance with the USGS Coastal and Marine Hazards and Resources Program's best practices for image naming convention. Images were renamed with the field survey ID prefix; flight number, and ID that distinguishes USGS cameras by make/camera number, the image acquisition date, coordinated universal time (UTC) in ISO8601 format, and a suffix with the original image name. For example, image name '2025011FA_f13MAP61_20250327T164058Z_#####', 2025011FA is the field activity ID; f13 is the flight number for that day; MAP61 is camera used; 20250327 is the UTC date in the format YYYYMMDD, and a 'T' is used to separate UTC date from UTC time in format HHMMSS followed by a Z. The ##### is the original raw photo suffix appended to the end of the new filename. 3. Images are validated and uploaded onto the Imagery Data System.

PHOTOGRAMMETRY: The ortho product was created in Agisoft Metashape v. 2.2.0 using the following general steps (see Over and others, 2021 for a more detailed SfM methodology explanation): 1. A project was created and imagery was imported along with a csv file containing the following information about the camera when the image was taken: latitude/longitude (WGS84), ellipsoid altitude (m), vertical and horizontal accuracy (m), omega/phi/kappa (°), and accuracy (°). 2. Photos were aligned at a high accuracy using a keypoint limit of 60,000 and unlimited tie points. 3. The alignment process matched pixels between images to create point clouds and put the imagery into a relative spatial context using the PPK geotagged image locations. The resultant point clouds were filtered using one iteration of the 'Reconstruction uncertainty' filter at a level of 10, one iteration of the 'Projection accuracy' filter at a level of 10, and multiple iterations of the 'Reprojection accuracy' filter to get to a level of 0.3. With each filter, iteration points are selected, deleted, and then the camera model was optimized to refine the focal length, cx, cy, k1, k2, k3, p1, and p2 camera model coefficients. 4. In a new chunk a high-quality dense cloud with a low-frequency filtering algorithm was made. The dense point cloud was then edited by visual inspection to remove points with a low confidence near the edges and near water bodies. 5. An interpolated DSM was built from the dense point cloud and then an orthomosaic was built from the DSM with refined seamlines. This DSM was then used to generate the orthomosiac, which consists of 3-bands and was exported at 5 cm resolution (2025011FA_Clearview_Mar_MAP61_Ortho_5cm.tif). Step processed by J. Cramer.

LIDAR DATA: The lidar data were processed in the Wingtra LIDAR app. The .data files were uploading into the app along with the base station RINEX *.25O file. The OPUS corrected location of the base and the ARP-APC offset were then entered manually. After the processing was complete, the start and end location of each transect was manually identified to clip the paths and remove points obtained when the aircraft was turning. This point cloud product was exported from the Wingtra LIDAR app and was brought into Global Mapper (GM) and manually cleaned of points interpreted to be noise. The LPC was colorized in GM with the SfM orthomosaic. Then, the LPC was gridded at 25 cm into a DSM using maximum values binning grid method and the setting 'Grid "No Data" Distance' set to 0, along with a 10 cm DTM generated using TIN gridding; the resulting file was exported as 2025011FA_Clearview_Mar_WLDR_DSM_10cm.tif. and 2025011FA_Clearview_Mar_WLDR_DTM_10cm.tif. The LPC was exported as 2025015FA_Clearview_Mar_WLDR_LPC.laz. All files were exported in EPSG:6347 and EPSG:5703 using GEOID 18.

CLOUD OPTIMIZATION: The DSM and DTM were deflate compressed and turned into a cloud-optimized GeoTIFF (cog) using gdal_translate with the following command: for %i in (.\*.tif) do gdal_translate %i .\cog\%~ni_cog.tif -of COG -stats -co BLOCKSIZE=256 -co COMPRESS=DEFLATE -co PREDICTOR=YES -co NUM_THREADS=ALL_CPUS -co BIGTIFF=YES (v. 3.1.4 accessed October 20, 2020 https://gdal.org/). Where i is the name of each GeoTIFF section.
The orthomosaic was JPEG compressed and turned into a cog using gdal_translate with the following command: for %i in (.\*.tif) do gdal_translate %i .\%~ni_cog.tif -of COG -stats -co BLOCKSIZE=256 -co COMPRESS=JPEG -co QUALITY=90 -co PREDICTOR=YES -co NUM_THREADS=ALL_CPUS -co BIGTIFF=YES