<?xml version="1.0"?>
<metadata xml:lang="en">
<Esri>
<CreaDate>20240823</CreaDate>
<CreaTime>15194500</CreaTime>
<ArcGISFormat>1.0</ArcGISFormat>
<SyncOnce>TRUE</SyncOnce>
<DataProperties>
<lineage>
<Process Date="20240823" Time="151945" ToolSource="c:\program files\arcgis\pro\Resources\ArcToolbox\toolboxes\Data Management Tools.tbx\CreateMosaicDataset">CreateMosaicDataset E:\DCGIS\Projects\Lidar_2024\Final\Lidar_2024.gdb nDSM PROJCS["NAD_1983_HARN_StatePlane_Maryland_FIPS_1900",GEOGCS["GCS_North_American_1983_HARN",DATUM["D_North_American_1983_HARN",SPHEROID["GRS_1980",6378137.0,298.257222101]],PRIMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433]],PROJECTION["Lambert_Conformal_Conic"],PARAMETER["False_Easting",400000.0],PARAMETER["False_Northing",0.0],PARAMETER["Central_Meridian",-77.0],PARAMETER["Standard_Parallel_1",38.3],PARAMETER["Standard_Parallel_2",39.45],PARAMETER["Latitude_Of_Origin",37.66666666666666],UNIT["Meter",1.0]],VERTCS["NAVD_1988",VDATUM["North_American_Vertical_Datum_1988"],PARAMETER["Vertical_Shift",0.0],PARAMETER["Direction",1.0],UNIT["Meter",1.0]] # # None #</Process>
<Process Date="20240823" Time="152105" ToolSource="c:\program files\arcgis\pro\Resources\ArcToolbox\toolboxes\Data Management Tools.tbx\AddRastersToMosaicDataset">AddRastersToMosaicDataset E:\DCGIS\Projects\Lidar_2024\Final\Lidar_2024.gdb\nDSM "Raster Dataset" E:\DCGIS\Projects\Lidar_2024\Final\nDSM UPDATE_CELL_SIZES UPDATE_BOUNDARY NO_OVERVIEWS # 0 1500 # # SUBFOLDERS "Allow duplicates" NO_PYRAMIDS NO_STATISTICS NO_THUMBNAILS # NO_FORCE_SPATIAL_REFERENCE NO_STATISTICS # NO_PIXEL_CACHE C:\Users\brian.putz\AppData\Local\ESRI\rasterproxies\nDSM</Process>
<Process Date="20240823" Time="152318" ToolSource="c:\program files\arcgis\pro\Resources\ArcToolbox\toolboxes\Data Management Tools.tbx\CalculateStatistics">CalculateStatistics E:\DCGIS\Projects\Lidar_2024\Final\Lidar_2024.gdb\nDSM 1 1 # OVERWRITE "Feature Set"</Process>
</lineage>
</DataProperties>
</Esri>
<mdChar>
<CharSetCd value="004"/>
</mdChar>
<mdHrLv>
<ScopeCd value="005"/>
</mdHrLv>
<mdContact>
<rpIndName>GIS Data Coordinator</rpIndName>
<rpOrgName>D.C. Office of the Chief Technology Officer</rpOrgName>
<rpCntInfo>
<cntPhone>
<voiceNum>(202) 727-2277</voiceNum>
<faxNum>(202) 727-6857</faxNum>
</cntPhone>
<cntAddress addressType="both">
<delPoint>200 I Street SE, 5th Floor</delPoint>
<city>Washington</city>
<adminArea>DC</adminArea>
<postCode>20003</postCode>
<country>US</country>
<eMailAdd>dcgis@dc.gov</eMailAdd>
</cntAddress>
<cntHours>8:30 AM to 5:00 PM (Eastern Time)</cntHours>
</rpCntInfo>
<role>
<RoleCd value="007"/>
</role>
</mdContact>
<mdDateSt>20241023</mdDateSt>
<mdStanName>ArcGIS Metadata</mdStanName>
<mdStanVer>1.0</mdStanVer>
<distInfo>
<distributor>
<distorCont>
<rpIndName>GIS Data Coordinator</rpIndName>
<rpOrgName>D.C. Office of the Chief Technology Officer</rpOrgName>
<rpCntInfo>
<cntPhone>
<faxNum>(202) 727-5660</faxNum>
</cntPhone>
<cntAddress addressType="both">
<delPoint>200 I Street SE, 5th Floor</delPoint>
<city>Washington</city>
<adminArea>DC</adminArea>
<postCode>20003</postCode>
<country>US</country>
<eMailAdd>dcgis@dc.gov</eMailAdd>
</cntAddress>
</rpCntInfo>
<role>
<RoleCd value="005"/>
</role>
</distorCont>
<distorFormat>
<formatName>Digital Format</formatName>
</distorFormat>
</distributor>
</distInfo>
<dataIdInfo>
<idCitation>
<resTitle>nDSM_2024</resTitle>
<date>
<pubDate>2024-08-22</pubDate>
</date>
<citRespParty>
<rpOrgName>Fugro USA Land, Inc.<!-- WARNING: translation from FGDC is ambiguous, this may require correction --></rpOrgName>
<role>
<RoleCd value="006"/>
</role>
</citRespParty>
<presForm>
<PresFormCd value="005"/>
</presForm>
<presForm>
<fgdcGeoform>remote-sensing image</fgdcGeoform>
</presForm>
</idCitation>
<idAbs>Normalized Digital Surface Model - 1m resolution. The dataset contains the 1m Normalized Digital Surface Model for the District of Columbia. These lidar data are processed classified LAS 1.4 files at USGS QL1 covering the District of Columbia. Some areas have limited data. The lidar dataset redaction was conducted under the guidance of the United States Secret Service. All data returns were removed from the dataset within the United States Secret Service redaction boundary except for classified ground points and classified water points.</idAbs>
<idPurp>1 meter resolution nDSM from lidar flown in a single lift on March 1st, 2024. This data is used for the planning and management of Washington, D.C. by local government agencies.</idPurp>
<idStatus>
<ProgCd value="001"/>
</idStatus>
<idPoC>
<rpIndName>GIS Data Coordinator</rpIndName>
<rpOrgName>D.C. Office of the Chief Technology Officer</rpOrgName>
<rpCntInfo>
<cntPhone>
<voiceNum>(202) 727-2277</voiceNum>
<faxNum>(202) 727-5660</faxNum>
</cntPhone>
<cntAddress addressType="both">
<delPoint>200 I Street SE, 5th Floor</delPoint>
<city>Washington</city>
<adminArea>DC</adminArea>
<postCode>20003</postCode>
<country>US</country>
<eMailAdd>dcgis@dc.gov</eMailAdd>
</cntAddress>
</rpCntInfo>
<role>
<RoleCd value="007"/>
</role>
</idPoC>
<resMaint>
<maintFreq>
<MaintFreqCd value="011"/>
</maintFreq>
</resMaint>
<placeKeys>
<keyword>District of Columbia, Washington DC</keyword>
</placeKeys>
<themeKeys>
<keyword>LiDAR</keyword>
<keyword>nDSM</keyword>
<keyword>Normalized Digital Surface Model</keyword>
<keyword>topography</keyword>
<keyword>bare earth</keyword>
<keyword>elevation</keyword>
<keyword>Elevation Data</keyword>
<keyword>2024</keyword>
</themeKeys>
<themeKeys>
<keyword>elevation</keyword>
<thesaName>
<resTitle>ISO 19115 Topic Categories</resTitle>
</thesaName>
</themeKeys>
<searchKeys>
<keyword>LiDAR</keyword>
<keyword>nDSM</keyword>
<keyword>Normalized Digital Surface Model</keyword>
<keyword>topography</keyword>
<keyword>bare earth</keyword>
<keyword>elevation</keyword>
<keyword>Elevation Data</keyword>
<keyword>2024</keyword>
<keyword>elevation</keyword>
<keyword>District of Columbia, Washington DC</keyword>
</searchKeys>
<resConst>
<Consts><useLimit>None. However, users should be aware that temporal changes may have occurred since this dataset was collected and that some parts of these data may no longer represent actual surface conditions. Users should not use these data for critical applications without a full awareness of its limitations. This work is licensed under a Creative Commons Attribution 4.0 International License.</useLimit>
</Consts>
</resConst>
<resConst>
<LegConsts>
<useLimit>See access and use constraints information.</useLimit>
<accessConsts>
<RestrictCd value="008"/>
</accessConsts>
<othConsts>No restrictions apply to this data.</othConsts>
</LegConsts>
</resConst>
<spatRpType>
<SpatRepTypCd value="002"/>
</spatRpType>
<tpCat>
<TopicCatCd value="006"/>
</tpCat>
<envirDesc> Version 6.2 (Build 9200) ; Esri ArcGIS 10.8.1.14362</envirDesc>
<dataExt>
<geoEle>
<GeoBndBox>
<exTypeCode>true</exTypeCode>
<westBL>-77.122373</westBL>
<eastBL>-76.900716</eastBL>
<northBL>39.001746</northBL>
<southBL>38.785481</southBL>
</GeoBndBox>
</geoEle>
</dataExt>
<dataExt>
<exDesc>ground condition</exDesc>
<tempEle>
<TempExtent>
<exTemp>
<TM_Period>
<tmBegin>2024-03-01</tmBegin>
<tmEnd>2024-03-01</tmEnd>
</TM_Period>
</exTemp>
</TempExtent>
</tempEle>
</dataExt>
</dataIdInfo>
<mdConst>
<Consts><useLimit>None.</useLimit>
</Consts>
</mdConst>
<mdConst>
<LegConsts>
<accessConsts>
<RestrictCd value="008"/>
</accessConsts>
<othConsts>None.</othConsts>
</LegConsts>
</mdConst>
<mdConst>
<SecConsts>
<class>
<ClasscationCd value="001"/>
</class>
<classSys>None.</classSys>
<handDesc>None</handDesc>
</SecConsts>
</mdConst>
<dqInfo>
<dqScope>
<scpLvl>
<ScopeCd value="005"/>
</scpLvl>
</dqScope>
<report type="DQConcConsis">
<measDesc>Data covers the entire District of Columbia.</measDesc>
</report>
<report type="DQCompOm">
<measDesc>Areas with deleted above-ground features exist in the dataset as directed by the United States Secret Service (USSS).</measDesc>
</report>
<dataLineage>
<prcStep>
<stepDesc>The lidar data acquisition for DC OCTO was flown to support the creation of a 8 ppsm classified lidar point cloud data set, 1m resolution hydro-flattened bare earth DEM, DSM, nDSM, 1 meter resolution intensity images, and .6m contours over the full project area covering the District of Columbia. Due to security requirements in the area, Fugro received waivers to fly in the Flight Restricted Zone (FRZ) and P-56 areas. The lidar acquisition was flown in a single lift on March 1st 2024, at an altitude of 6500 feet above mean sea level and composed of 12 flight lines, 10 primary lines and 2 cross ties. All lidar data was collected with a Piper Navajo PA31, tail# N76JN and a Riegl 1560ii-S lidar sensor, #547. All lidar was collected in conjunction with airborne GPS.</stepDesc>
</prcStep>
<prcStep>
<stepDesc>Rice and Associates, under contract to Fugro USA Land, Inc., successfully established ground control for the DC OCTO project area. A total of 31 survey points were visited, 6 ground control point, 20 NVA checkpoints, and 5 VVA checkpoints. Of those 31 surveys, 21 were only visually observed to maintain control integrity and assure that construction had not altered the point. 13 surveys were done for this project to combine with previously surveyed ground control data. The new surveys used GPS to establish the control network. The ground control was delivered in Maryland State Plane (FIPS1900) meters, with the horizontal datum provided in both NAD1983 and NAD83(2011). The vertical datum was the North American Vertical Datum of 1988 (NAVD88) using GEOID18. The table below shows which points were used as the control, which were used as NVA checkpoints, and which were VVA checkpoints: NVA - NVA-01-2024, NVA-02-2024,NVA-03 ,NVA-04-2024, NVA-05-2024, NVA-06-2024,NVA-07-2,NVA-08,NVA-09,NVA-10 NEW SURVEY,NVA-11-2024,NVA-12-2024,NVA-13,NVA-14-2024, NVA-15-2024,NVA-16,NVA-17,NVA-18,NVA-19 NEW SURVEY,NVA-20; VVA - VVA01,VVA02,VVA03,VVA04,VVA05; GCP - GCP-01-2,GCP-02,GCP-03 NEW SURVEY, GCP-04,GCP-05-2,GCP-06-2. During initial processing, QC and accuracy assessments were run the data in NAD83(2011) datum which is the native coordinate system from the sensor. Following boresight the data was re-projected to NAD83 HARN for delivery per the contract specifications and cut to the delivery extent the control was re-run in the final deliverable projection.</stepDesc>
<stepDateTm>2024-01-01</stepDateTm>
</prcStep>
<prcStep>
<stepDesc>Pre-Processing and Boresight All lidar data went through a preliminary field review to ensure that complete coverage was obtained and that there were no gaps between flight lines prior to leaving the project site. Once back in the office, the data went through a complete iteration of processing to ensure that it is complete, uncorrupted and that the entire project area was covered without gaps. There were three steps to processing: 1) GPS/IMU processing - airborne GPS and IMU data was processed using the airport GPS base station data; 2) raw lidar data processing - the raw data was processed to LAS format flight lines with full resolution output before performing QC. A starting configuration file is used in this process, which contains the latest calibration parameters for the sensor and outputs the flight line trajectories. 3) Verification of coverage and data quality - the trajectory files were checked to ensure completeness of acquisition for the flight lines, calibration lines and cross flight lines. Intensity images were generated for the entire lift and thoroughly reviewed for data gaps in project area. A sample TIN surface was generated to ensure no anomalies or turbulence were present in the data; if any adverse quality issues were discovered, the flight line was rejected and re-flown. The achieved post spacing confirmed against the project specification of 8 ppsm and checked for clustering in point distribution. The review showed that the lidar data exceeded the 4 ppsm post spacing. The lidar data was boresighted using the following steps: 1) The raw data was processed to LAS format flight lines using the final GPS/IMU solution. This LAS dataset was used as source data for boresighting. 2) Fugro proprietary and commercial software was used to calculate initial boresight adjustment angles based on sample areas within the lift. These areas cover calibration flight lines collected in the lift, cross tie and production flight lines. These areas are well distributed in the lift coverage and cover multiple terrain types that are necessary for boresight angle calculation. The results were analyzed and any additional adjustments were completed the selected areas. 3) Once the boresight angle calculation was completed, the adjusted settings were applied to the flight lines of the lift and checked for consistency. The technicians utilized commercial and proprietary software packages to analyze the matching between flight line overlaps for the entire lift and adjusted as necessary. 4) Vertical misalignment of all flight lines was checked and corrected, as was the matching between data and ground truth. 5) A final vertical accuracy check of the boresighted flight lines against the surveyed ground control points was conducted. The boresighted lidar data achieved a vertical accuracy of 0.030m RMSE (0.060m at 95% confidence) against the 20 NVA checkpoint control locations.</stepDesc>
<stepDateTm>2024-01-01</stepDateTm>
</prcStep>
<prcStep>
<stepDesc>Data Redaction Following the boresight completion, the lidar dataset redaction was conducted under the guidance of the United States Secret Service. All lidar data returns and collected data were removed from the dataset based on the redaction footprint shapefile agreed upon in 2023.</stepDesc>
<stepDateTm>2024-01-01</stepDateTm>
</prcStep>
<prcStep>
<stepDesc>Classified Point Cloud The boresighted lidar data underwent an automated classification filter to classify low noise, high noise, and ground points. To obtain optimum results, the parameters used by the automated classification filter are customized for each terrain type and project. Once the automated filtering was completed, the lidar files went through a visual inspection to ensure that an appropriate level of filtering was used. In cases where the filtering was too aggressive and important terrain may have been filtered out, the data is either run through a different filter within localized area or is corrected during the manual filtering process. A second automatic filter is run for the initial classification on buildings. Following the automatic filters, manual editing was completed in Terrascan software to correct any misclassification of the lidar dataset. All tiles then went through a peer review to ensure proper editing and consistency. When the peer review was completed two additional automatic filters were applied. The first filter was used to classify the vegetation - moving the unclassified points to either the low, medium, or high vegetation classes. The second filter was used to re-classify points inside water bodies to water class, and a 1*NPS buffer around water bodies to ignored ground class. Once the manual inspection, QC, and auto filter is complete for the lidar tiles, the LAS point cloud data was converted into the final deliverable format and the accuracy statistics were re-run to confirm the deliverable accuracy. The LAS was then cut to the final delivery layout and in LAS 1.4 format for delivery. The point cloud was delivered with data in the following classifications: Class 1 - Processed but Unclassified; Class 2 - Bare Earth Ground; Class 3 - Low Vegetation; Class 4 - Medium Vegetation; Class 5 - High Vegetation, Class 6 - Buildings; Class 7 - Low Point (Noise); Class 9 - Water; Class 17 - Bridge Decks; Class 18 - High Noise; Class 20 - Ignored Ground.</stepDesc>
<stepDateTm>2024-01-01</stepDateTm>
</prcStep>
<prcStep>
<stepDesc>The nDSM used all point returns, except for the noise class, to create a model of all features collected by the data. The nDSM did not undergo hydro-flattening but to improve the appearance and remove artefacts in the water, the hydro shapefile was sued to set all water bodies to -5 m, an arbitrary, consistent value to ensure the water is blow the surrounding land to keep low lying features such as docks from appearing underwater. The bridges were masked out of the water polygons before applying the -5 m elevation to ensure they remain in the dataset. The nDSM then went through a visual QC to make sure all noise points have been correctly classified out of the data and that the water elevation was properly applied and free of artifacts. Following the final QC the nDSM was converted to Geotiff and packaged for delivery.</stepDesc>
<stepDateTm>2024-01-01</stepDateTm>
</prcStep>
</dataLineage>
</dqInfo>
<spatRepInfo>
<Georect>
<numDims>2</numDims>
<axisDimension type="001">
<dimSize>24000</dimSize>
</axisDimension>
<axisDimension type="002">
<dimSize>19200</dimSize>
</axisDimension>
<cellGeo>
<CellGeoCd value="002"/>
</cellGeo>
</Georect>
</spatRepInfo>
</metadata>
