ISO Table View
Alternate Views:
Get Data,
FAQ,
ISO Rubric,
CSW,
HTML,
Components, XML
Metadata Identifier: gov.noaa.csc.maps:2003_MS_PearlRiver_m64
MD_DataIdentification
| 1 |
|
2003 Pearl River County, Mississippi Lidar: Flood Plain Management Project
|
This lidar data was collected primarily for flood plain mapping within Pearl
River County, MS. The data were processed into separate Bare Earth and First Surface
products. The two were subsequently classified (bare earth and unclassified) and merged
to create one data set. The data were collected from 1-8 Feb 2003. One flight was
reflown on 30 March 2003.
|
SV_Identification
| 1 |
|
2003 Pearl River County, Mississippi Lidar: Flood Plain Management Project |
|
|
| 1 |
|
Lidar QA/QC Report |
|
|
| 2 |
|
None |
|
|
| 1 |
|
North American Datum 1983 |
|
|
| 1 |
|
|
|
|
|
resourceProvider |
http://www.epsg-registry.org/export.htm?gml=urn:ogc:def:crs:EPSG::4269 |
| 1 |
|
|
|
Citation URL |
|
|
ftp://ftp.csc.noaa.gov/pub/crs/beachmap/qa_docs/ms/pearl_river/Pearl_River_County_MS_Project%20Report.doc |
| 1 |
NOAA CSC (originator) |
|
DOC/NOAA/NOS/CSC > Coastal Services Center, National Ocean Service, National Oceanic
and Atmospheric Administration, U.S. Department of Commerce
|
|
csc.info@noaa.gov |
originator |
|
| 1 |
NOAA CSC (publisher) |
|
DOC/NOAA/NOS/CSC > Coastal Services Center, National Ocean Service, National Oceanic
and Atmospheric Administration, U.S. Department of Commerce
|
|
csc.info@noaa.gov |
publisher |
|
| 1 |
NOAA CSC(distributor) |
|
DOC/NOAA/NOS/CSC > Coastal Services Center, National Ocean Service, National Oceanic
and Atmospheric Administration, U.S. Department of Commerce
|
|
csc.info@noaa.gov |
distributor |
|
| 1 |
NOAA CSC (processor) |
|
DOC/NOAA/NOS/CSC > Coastal Services Center, National Ocean Service, National Oceanic
and Atmospheric Administration, U.S. Department of Commerce
|
|
csc.info@noaa.gov |
processor |
|
| 1 |
EPSG Registry |
|
European Petroleum Survey Group |
|
|
publisher |
http://www.epsg-registry.org/ |
| 1 |
Mike Sutherland(author) |
Mike Sutherland |
DOC/NOAA/NESDIS/NGDC > National Geophysical Data Center, NESDIS, NOAA, U.S. Department
of Commerce
|
|
mike.sutherland@noaa.gov |
author |
|
| 1 |
Mike Sutherland |
Mike Sutherland |
DOC/NOAA/NESDIS/NGDC > National Geophysical Data Center, NESDIS, NOAA, U.S. Department
of Commerce
|
|
mike.sutherland@noaa.gov |
distributor |
|
| 1 |
|
Mr. Elijah Hunt |
U.S. Army Corps of Engineers Vicksburg District |
|
|
pointOfContact |
|
| 1 |
|
Pamela Grothe |
DOC/NOAA/NESDIS/NGDC > National Geophysical Data Center, NESDIS, NOAA, U.S. Department
of Commerce
|
|
|
processor |
|
| 1 |
|
|
U.S. Army Corps of Engineers, Vicksburg District |
|
|
originator |
|
| 1 |
|
ftp://ftp.csc.noaa.gov/pub/crs/beachmap/qa_docs/ms/pearl_river/Pearl_River_County_MS_Project%20Report.doc |
Lidar QA/QC Report |
|
information |
| 1 |
|
http://www.epsg-registry.org/ |
European Petroleum Survey Group Geodetic Parameter Registry |
Registry that accesses the EPSG Geodetic Parameter Dataset, which is a structured
dataset of Coordinate Reference Systems and Coordinate Transformations.
|
search |
| 1 |
|
http://www.epsg-registry.org/export.htm?gml=urn:ogc:def:crs:EPSG::4269 |
NAD83 |
Link to Geographic Markup Language (GML) description of reference system. |
information |
| 1 |
|
Ellipsoid in Meters |
| 1 |
|
urn:ogc:def:crs:EPSG::4269 |
|
Bounding Box |
Temporal Extent |
| 1 |
|
|
-089.512658 |
-089.201145 |
+31.010543 |
+30.263267 |
2003-02-01 |
2003-02-08 |
| 1 |
|
-089.512658 |
-089.201145 |
+31.010543 |
+30.263267 |
| 1 |
Lidar Use Limitation |
These data depict the elevations at the time of the survey and are only
accurate for that time. Users should be aware that temporal changes may
have occurred since this data set was collected and some parts of this data may no
longer represent actual surface conditions. Users should not use this data
for critical applications without a full awareness of its limitations. Any conclusions
drawn from analysis of this information are not the responsibility of NOAA
or any of its partners. These data are NOT to be used for navigational purposes.
|
| 1 |
Ellipsoid |
Ellipsoid in Meters |
|
| 1 |
NAD83 |
urn:ogc:def:crs:EPSG::4269 |
North American Datum 1983 |
| 1 |
|
Lidar QA/QC Report |
|
crossReference |
| 1 |
|
|
Flight Report A Cessna Skymaster 337, N111AT, was mobilized from Huntsville
International Airport, Huntsville, AL to Picayune Municipal Airport, Picayune, MS
on 30 Jan 2003. This aircraft was outfitted with an Optech ALTM 1210 LIDAR system.
Mission planning for the project determined that 103 flight lines would be needed
to successfully cover the specified area, including three control lines. These lines
would be flown at a 120-knot ground speed, 1250 meters above ground level and would
take approximately 37.5 hours to complete. Three GPS base stations supplied and operated
by Sea Systems Corporation were used to support precise positioning and orientation
of the ALTM's sensor head during the entire duration of flight. The GPS base stations
were Trimble 5700 receiver units utilizing Zephyr Geodetic antennas. Each GPS base
station was located within the boundary of the project area. The actual local flight
times and duration of flights were controlled by fuel consumption of the aircraft,
safety of flight operations in the particular airspace and during times when the GPS
constellation was most favorable, producing the highest number of satellites visible
in the best geometric configuration relative to the GPS receivers onboard the aircraft
as well as at the master stations on the ground. A standard of flying with no less
than 7 satellites visible and a PDOP (position dilution of precision) of less than
3.0 was adopted. The initial aerial survey was completed over the course of 8 days.
Data collection started around 23h30 UTC on Saturday, 01 February 2003. Flightlines
completed during this flight were lines one through 12. On 01 February the flight
commenced at 02h50 UTC and completed lines thirteen through twenty-nine. The flight
on 02 February began around 23h10 UTC and collected lines thirty through thirty-eight.
A second flight was then flown beginning around 02h30 UTC on 03 February and completing
lines thirty-nine through forty-five. On 04 February the flight commenced around 22h40
UTC and covered lines forty-five through fifty-four. The second flight followed a
refueling stop around 02h30 UTC and completed lines fifty-five through sixty-six.
The flight on 05 February covering lines 67-69 and 97 through 100 began around 22h10
UTC and ended around 00h30 due to weather. The final day of initial data collection
occurred on 08 February. Two flights were flown this day. The initial flight began
around 00h46 UTC and covered lines seventy through eighty-eight and line 103. The
second flight began around 22h19 UTC and completed lines 67-69, 89-96 and 101 and
102. This completed the initial LIDAR data collection for the project and the ground
crews continued in their remaining work in and around the project area. The aircraft
and personnel involved during the LIDAR portion of the survey were demobilized on
the night of Sunday, 09 Feb 2003. Following a preliminary examination of the collected
data it was determined that one flight was required to refly some of the collected
lines. A Cessna Skymaster 337, N111AT, was mobilized from Huntsville International
Airport, Huntsville, AL to Picayune Municipal Airport, Picayune, MS on 30 Mar 2003.
This aircraft was outfitted with an Optech ALTM 1210 LIDAR system. Data collection
commenced at approximately 22h35 UTC and constituted reflying lines 5, 9, 86-88, 92
and 103 for various technical reasons. This completed the LIDAR data collection for
the project and the ground crews continued in their remaining work in and around the
project area. The aircraft and personnel involved during the LIDAR portion of the
survey were demobilized on Monday, 31 Mar 2003. A Cessna 210, N732JE, was mobilized
from Huntsville International Airport, Huntsville, AL to Picayune Municipal Airport,
Picayune, MS on 11 FEB 2003. This aircraft was outfitted with a RC30 Camera and AGFA
Pan 80 film. Mission planning for the project determined that 40 flight lines would
be needed to successfully cover the specified area at the various flying altitudes.
These lines would be flown at 4800 feet above ground level with 80/30 overlap, 9030
feet above ground level with 60/30 overlap, 12000 feet above ground level with 80/30
overlap and would take approximately 18 hours to complete. Three GPS base stations
supplied and operated by Sea Systems Corporation were used to support precise positioning
and orientation of the photo centers during the entire duration of flight. Each GPS
base station was located within the boundary of the project area. The actual local
flight times and duration of flights were controlled by fuel consumption of the aircraft,
safety of flight operations in the particular airspace and during times when the sun
angle was most favorable. The aerial survey was completed over the course of 3 days.
Data collection started around 11h19 local on Tuesday, 11 February 2003. Flightlines
completed on this day ranged from one to nine at 4800 feet and one through five at
9030 feet. Collection recommenced around 9h47 local on 12 February. Lines completed
during this flight were six through 12 at 9030. On 13 February collection began around
09h26 local and lasting through 15h00 local. Lines collected during this flight included
ten to eighteen at 9030 and ten through twenty-three at 12000 feet. This completed
the photo collection for the project and the ground crews continued in their remaining
work in and around the project area. The aircraft and personnel involved during the
photo portion of the survey were demobilized during the afternoon of Thursday, 13
February 2003. Upon inspection of the film it was determined that reflights would
be necessary. On 23 February 2003 a Cessna 335, N918AA, was mobilized from Huntsville
International Airport, Huntsville, AL to Picayune Municipal Airport, Picayune, MS
outfitted with a RC30 Camera and AGFA Pan 80 film. Collection took place between 09h34
and 12h31 local. Lines six, eight and nine at 9030 and lines sixteen, seventeen, twenty
and twenty-three at 12,000 were reflown. GPS/IMU Data Processing Upon completion of
the flight portions of the project the GPS data was post processed for quality and
backed up. For redundancy and accuracy purposes, the airborne GPS data were processed
from the base stations using GrafNav from Waypoint Consulting, Inc. Results from the
LiDAR N111AT JD_032F01 Final Solution. The final solution for this flight is PR43/PR43
FWD/REV. The REV solution from PR15 and the FWD solution from B154 matched fairly
well with the final, but are not used in the final due to the long baseline distances.
PECK was not processed since an incorrect point was occupied during the flight. This
solution is considered good. DLW 10 April 2003 JD_032F01 Final Solution. The final
solution for this flight is PR43/PR43 FWD/REV. The FWD solution from both PR15 and
B154 matched very well, within a couple of centimeters, with the final, but are not
used in the final due to the long baseline distances. The REV solutions from PR 15
and B154 were both off by about 10 cm. PECK was not processed since an incorrect point
was occupied during the flight. This solution is considered very good. MWB 2 April
2003 JD_032F02 Final Solution The final solution for this flight is PR43/PR43 FWD/REV.
The combined solution from PR15 matched, but adds noise. The FWD solution from B154
matched but is not used in the final due to the long baseline distance. PECK was not
processed since an incorrect point was occupied during the flight. This solution is
considered very good. MWB 2 April 2003 JD_033F01 Final Solution The final solution
for this flight is B154/PR15 CMB/CMB. The solutions from PR43 matched, but added more
noise. PECK processed ok and could have been processed to match, but it was not needed
as part of the solution. This solution is considered very good. MWB 2 April 2003 JD_033F02
Final Solution The final solution for this flight is B154/PECK/PR15 CMB/CMB/CMB. All
solutions from all bases processed very well. PR43 matched, but was not used because
of the added noise. This solution is considered very good. MWB 2 April 2003 JD_035F01
Final Solution The final solution for this flight is B154/PR43 REV/CMB. The REV solution
from PR19 matched, but added noise. The FWD solutions from B154 and PR19 did not process
as well as the REV solutions. PR05 did not process well in either direction, probably
because of baseline distance. This solution is considered good. MWB 2 April 2003 JD_035F02
Final Solution The final solution for this flight is B154/PR19/PR43 CMB/CMB/CMB. All
solutions from all stations processed very well. PR05 was not used because of baseline
distance. This solution is considered very good. MWB 3 April 2003 JD_036F01 Final
Solution The final solution for this flight is PR05/PR19/PR43 REV/REV/CMB. All solutions
from the three stations processed well. The FWD solutions from PR05 and PR19 could
have been used with some work. B154 needed some reprocessing, but was not needed because
of baseline distance. This solution is considered good. MWB 3 April 2003 JD_038F01
Final Solution The final solution for this flight is PR05/PR19/PR43 CMB/CMB/CMB. All
solutions from all stations processed well. B154 was not needed because of baseline
distance. This solution is considered very good. MWB 3 April 2003 JD_039F01 Final
Solution The final solution for this flight is PR05/PR19/PR43 REV/CMB/CMB. All solutions
from all stations processed well. The FWD from PR05 processed ok, but was rather noisy.
B154 was not needed because of baseline distance. This solution is considered very
good. MWB 3 April 2003 JD_089F01 Final Solution The final solution for this flight
is PR17/PR17 FWD/REV. Station PR43 did not process well. External noise seems to be
influencing the data. PR17 processed well during the data collection times of the
flight. The data were noisy during the mobilization from the airport to the work site.
This may be due to baseline distance. This solution is considered good. MWB 9 April
2003 These trajectories were used in the processing of the inertial data. The inertial
data were processed using PosProc from Applanix, Inc. This software produces an SBET
("smooth best estimate of trajectory") using the GPS trajectory from GrafNav and the
roll, pitch and heading information recorded by the POS (Position and Orientation
System). Results were favorable for all flights and errors are estimated to be less
than 5cm. Respectfully Submitted, MD Atlantic Technologies, Inc. Darrick L. Wagg,
P.Geo. 15Jun2004 Data Processing Report Data collection of the survey areas resulted
in a total of 103 flight lines covering the project area including 3 control lines.
The tapes, flight logs, raw air and ground GPS files were then taken to the office
for data processing using Realm, a LiDAR processing software package from Optech.
Processing began by downloading these files into a Realm database. Although Realm
has the capability to perform GPS processing and to utilize real-time inertial data,
MD Atlantic utilizes other methods of obtaining this information as Realm only has
the capability to produce a single-baseline solution. For redundancy and accuracy
purposes, the airborne GPS data were processed from two base stations using GrafNav
from Waypoint Consulting, Inc. The agreement between a minimum of two solutions checked
or combined between a minimum of two stations was better than 10 cm in each of X,
Y, and Z. These trajectories were used in the processing of the inertial data. The
inertial data were processed using PosProc from Applanix, Inc. This software produces
an SBET ("smooth best estimate of trajectory") using the GPS trajectory from GrafNav
and the roll, pitch and heading information recorded by the POS (Position Orientation
System). Realm uses the SBET to generate a set of XYZ data points for each laser return.
Data can be segregated based on the first- and last-pulse information. First and last
pulse files were created during the processing of this dataset. This project's data
were processed in strip form, meaning each flight line was processed independently.
Processing the lines individually provides the data analyst with the ability to QC
the overlap between lines. Raw lidar data are processed within the lidar manufacturer's
software to produce XYZI files. These files are output in UTM coordinates with a corresponding
Ellipsoid Height value. Output XYZI files from Realm were converted from UTM co-ordinates
with GRS80 ellipsoid elevations into State Plane Coordinate System (NAD83) with NGVD29
orthometric heights using the U.S. Army Corps of Engineers' Corpscon, version 5.11.08.
Corpscon utilizes the Geoid96 model for the ellipsoid to orthometric height conversions.
The resultant XYZI files were subsequently imported into a project, on a per pulse
basis, using TerraScan (Terrasolid Ltd.) where each line was checked against adjacent
lines. This check revealed an issue with the calibration numbers being used for the
system. Further investigation led to the understanding that calibration parameters
would have to be determined on a line-by-line basis. Though uncommon, this situation
is not unheard of with airborne laser terrain mapper systems. Once the calibration
parameters for each line were determined and the data recalculated, the data was checked
against the control and validation points across the project area. The results of
these checks showed a bias in the dataset for all lines, save for 97 and 99, of -1.2
U.S. Survey Feet. It was determined that an adjustment to correct for this bias would
be best for the dataset. A subsequent check of the DEM found it fitting the validation
and control points well. See LiDAR DEM Quality Control Report for results. The data
from each line was then combined and a classification routine performed to determine
the rough surface model. This initial surface model was then reduced using MD Atlantic's
proprietary methods to create the final bare-earth dataset. A Triangular Irregular
Network (TIN) was generated using the final surface data. Contours were then created
from the TIN for use in performing a quality control of the surface. The LiDAR data
were taken into a stereo environment and melded with photogrammetric data. Breaklines
were subsequently compiled along hydro features to support the contour generation.
Respectfully Submitted, MD Atlantic Technologies, Inc. Darrick L. Wagg, P.Geo. 03Jun2004
ARC Grids Processing Procedures Processing of the ARC Grids and Tins began by merging
dtm models that overlaid the tile boundary. The merged dtm file was then imported
into an ARC/Info point coverage that was utilized as an input source during the tin
processing. Along with the ARC/Info point coverage, the ARC Generate file of the breaklines
was also utilized as an input source during the Tin process. The final input during
the Tin process was to use the tile polygon boundary to clip the Tin file. Once the
Tin was created, the generation of the 5ft Grids was processed through the ARC/Info
TINLATTICE command. The final product is a Grid with 5ft postings, clipped to the
tile boundary. The final step to having deliverable Grids was to ensure that the projection
was defined for each Grid. The ARC/Info command PROJECTDEFINE was utilized for this
process. ARC Shape Files Processing Procedures The first step in the Shapefile process
was to import the Microstation DGN files into ARC/Info coverages. Once the files are
in an ARC/Info coverage file format, then a Join was performed on the Arc Attribute
Table with the ACODE Info file, which is produced during the IGDSARC translation.
The next step is to add any new items that are to be converted over to the ARC shapefile
DBF. Once all the applicable items are properly calculated, then all unnecessary items
are dropped. The ARC coverages are then exported as a shapefile, which will contain
only the necessary fields in the tables. Respectfully Submitted, MD Atlantic Technologies,
Inc. Jesse Gregg, GIS Technician
|
| 1 |
|
2008-02-20T00:00:00 |
The NOAA Coastal Services Center (CSC) received the files in ASCII
xyz format. The files contained Lidar elevation measurements. The data consisted of
a bare earth and a first return data set. The two were subsequently classified (bare
earth and unclassified) and merged to create one data set. The data was in Mississippi
State Plane Projection, Zone 2301 and NGVD29 vertical datum. CSC performed the following
processing for data storage and Digital Coast provisioning purposes: 1. The data were
converted from Mississippi State Plane coordinates to geographic coordinates. 2. The
data were converted from NGVD29 (orthometric) heights to NAVD88 (orthometric) heights.
3. The data were converted from NAVD88 (orthometric) heights to GRS80 Ellipsoid heights
using Geoid99. 4. Bare earth data set and first return data set merged. 5. The data
were sorted by latitude and the headers were updated.
|
| 1 |
|
2009-07-20T00:00:00 |
The NOAA National Geophysical Data Center (NGDC) received lidar data
files via ftp transfer from the NOAA Coastal Services Center. The data are
currently being served via NOAA CSC Digital Coast at http://www.csc.noaa.gov/digitalcoast/.
The data can be used to re-populate the system. The data are archived in LAS
or LAZ format. The LAS format is an industry standard for LiDAR data developed by
the American Society of Photogrammetry and Remote Sensing (ASPRS); LAZ is a loseless
compressed version of LAS developed by Martin Isenburg (http://www.laszip.org/). The
data are exclusively in geographic coordinates (either NAD83 or ITRF94). The data
are referenced vertically to the ellipsoid (either GRS80 or ITRF94), allowing for
the ability to apply the most up to date geoid model when transforming to orthometric
heights.
|
|
