Lidar points, elevation models, imagery, orthomosaic, and supporting GPS data collected during UAS operations at Town Neck Beach, Sandwich, MA on June 02, 2025

GROUND CONTROL: Ten AeroPoint GCPs were spaced out over the field site and left on for at least 30 minutes to collect GNSS data. After collection, the AeroPoint 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 19N (EPSG:6348) and NAVD88 (EPSP:5703) with GEOID 18 to produce easting and northing and orthometric heights. These were exported to a CSV file and named 2025015FA_TNB_AeroPoints.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 on the parking lot, beach, and AeroPoints, data were provided in 2025015FA_TNB_GPS_Emlid_RS3_checkpoints.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 five 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 northwest-southeast transect passes. The camera module was set to take images every 2 seconds. After the flights the lidar and RGB data were downloaded 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:6348 and EPSG:5703 in the imagery locations file (2025015FA_TNB_MAP61_ImageryLocations.csv) and were accounted for when transforming to EPSG:6348 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. ExifTool was used to tag each photo 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 with Namexif (https://us.digicamsoft.com/softnamexif.html v 2.2 accessed April 2020) 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 '2025015FA_f01MAP61_20250602T165822Z_#####', 2025015FA is the field activity ID; f01 is the flight number; MAP61 is camera used; 20250601 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. The orthomosaic is a 3-band orthomosaic exported at 5 cm resolution (2025015FA_TNB_MAP61_SfM_Ortho_5cm.tif). Step processed by J. Over.

LiDAR DATA: The lidar data were processed in the Wingtra LIDAR app. The .data files were uploaded 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 or water. 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 5; the resulting file was exported as 2025015FA_TNB_WLDR_DSM_25cm.tif. The LPC was exported as 2025015FA_TNB_WLDR_LPC.laz. All files were exported in EPSG:6348 and EPSG:5703 using GEOID 18.

CLOUD OPTIMIZATION: The DSM was 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.
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