Messages posted by: ccrosby

FYI - I just saw this. Might be of interest to OpenTopography users:

Getting Started with Lidar in ArcGIS - free 60 minute online training video.

This seminar introduces lidar in general, discusses how to manage lidar data using ArcGIS, and also addresses the needs of those who would like to know the benefits of using lidar data in ArcGIS.

Hi Sally,
There are not pre-computed DEMs available for any portion of the B4 data. You will have to generate your own from the point cloud data via OpenTopography. Fortunately it should be a relatively simple process, but let me know if you encounter problems.

The SIO Viz Center group did produce Google Earth files (1m hillshade images) for the B4 data, and those can be accessed via OpenTopography by going to Data > Google Earth files > B4 Project The direct link is: http://www.siovizcenter.ucsd.edu/topo/b4.php

Let me know if you have questions. Cheers,

-cc

Part 7 of the "LiDAR Solutions in ArcGIS" series on the Geoprocessing Blog

Minimizing noise from lidar for contouring and slope analysis

I've also added the link to the first post in this thread.

Reply:
---

The GeoEarthScope LiDAR data are in ellipsoidal elevations, not the more commonly used orthometric (height above sea-level) elevations. You can calculate the geoid separation here: http://sps.unavco.org/geoid/ Once you have the separation value, you can "move" the DEM into the correct orthometric location with a quick bit of raster math (using something like the raster calculator in ArcGIS).

The vertical datum of the GeoEarthScope data set was not fully addressed in the first generation of the metadata document produced by NCALM. Since this issue comes up occationally, I asked NCALM to include a discussion of vertical datums in all future metadata reports on GeoES data they deliver to OpenTopo. I've added a revised NoCal metadata report to the Metadata & Files section of OpenTopo. The text of the new addition to the metadata report reads:

The users should also be aware that the elevation values of all datasets are heights above the ellipsoid (WGS84) and not orthometric heights. The ellipsoid-heights are measured along the ellipsoid normal in contrast to the orthometric heights which follow the direction of the gravity. In many applications the term elevation most commonly refers to the orthometric height of a point. Ellipsoid heights from GPS surveys are converted to traditional orthometric values by applying a geoid height using the latest geoid model from the National Geodetic Survey (NGS).

The Corps of Engineers Coordinate Conversion (CORPSCON, currently at v.6.0) tool can be used to transform the point data (XYZ ASCII tiles) ellipsoid heights into NAVD88 elevations using various GEOID models, including the latest iteration - GEOID03. The converted point data files can be then re-grided to ArcInfo raster format using your preferred interpolation technique. CORPSCON can be downloaded from this address:
http://crunch.tec.army.mil/software/corpscon/corpscon.html

Yet another question received via email - this is a good one on vertical datums:

----

I downloaded my DEM from Google Earth and brought it into GIS. The area I am looking at is giving me pixel readings of around 6 and we believe the elevation at this point is over 100. I have read and read and from what I can find, the data is in WG84, Zone 10 and the vertical datum is NAVD88. Is that right? I am assuming that if the horizontal datum is in meters the vertical is in meters? That still leaves me with a huge vertical elevation difference.

Any help is appreciated!

Email from an OpenTopography user regarding a corrupt tile DEM zip file. I am re-posting it here in case other users encounter the same problem. IZArc is worth noting if it can open corrupt zips. We've repaired this particular file, and are working on a QA/QC process to make sure all of the zips are valid in the future.

-cc

I seem to be having a problem with extracting one particular .zip file, the archive for the Lidar DEM data for tile 513_3937. I have been extracting and processing many of the tiles and this is the first one i have had a problem with.

I get tiled Lidar DEM data from http://opentopo.sdsc.edu/gridsphere/gridsphere?cid=standarddems

I maneuver to the tile in the on-line map and right-click. The archive (.zip) file downloads ok. I have downloaded it twice, once a couple months ago and once recently. the specific download URL is:
http://cordillera.la.asu.edu:8080/SoCAL/SocalMapServlet?mapid=513_3937_Garlock_Corr9_PolyB.zip

When I go to extract the .zip i get the following error message from the 7-Zip software that "513_3937.zip is not a supported archive"

IZArc reports that 513_3937.zip has a bad zip header but will still extract it. I have reviewed the resulting datasets in ArcCatalog. The fg versions of the datasets look normal. On the ug side the hillshade is missing and the ug DEM looks like it had processing problems. We are using the fg versions.

None of the data hosted in OpenTopography are in geographic coordinates. In the case of the the NSAF and Rainier datasets, coordinates are in State Plane (CA and WA) - please see the metadata document for full coordinate system description. It is quite uncommon for LiDAR to be collected or analyzed in geographic coordinates, but if you want to convert these data to lat/long, you could use PROJ4 (http://trac.osgeo.org/proj/) to do so.

noirasura wrote:

here,are X,Y Z stand for 'latitude'/'longitude'/'elevation', if not, how to convert them to lat/long?

Sorry for the delayed reply - I was on vacation last week.

Regarding the Return_Number values, I agree that something is odd if you are not seeing last returns ("4") in the data you've downloaded. I've never fully understood the attribute scheme used by Terapoint (the vendor who acquired these data)...I'll see if I can get clarification from someone on what to make of what you are seeing. I presume that you are downloading the full point cloud and not just the "Ground" classified points?

You should not expect each set of returns to have the same x & y position since the laser scanner is only perfectly vertical (at nadir) once per scan. For the rest of the scan the laser is pointing off nadir and hence is passing obliquely through the vegetation and will result in different x,y positions for returns from the same outgoing pulse. Also keep in mind that the point cloud is composed of multiple passes of the plane over a survey area and therefore when you download points from OpenTopo, you are getting a merged point cloud back that represents all returns for the area you selected.

-cc

Good question. I believe you are asking about either the NSAF or Rainier datasets - which were both acquired by the same vendor and have these attributes.

The metadata document for these data (it can be downloaded under "Resources" > "Metadata & Files") describes these attributes as follows:

Up to four returns can be recorded per laser pulse; number_of_returns is the total returns for a pulse (up to a maximum of 4). Return_number is assigned as a number from 1 to 7 in a scheme that identifies which return is the last return recorded for a pulse:
1 first return with subsequent returns detected
2 second return with subsequent returns detected
3 third return with subsequent returns detected
4 fourth return
5 first return with no subsequent returns detected
6 second return with no subsequent returns detected
7 third return with no subsequent returns detected

Hope this is helpful.

-cc

Part 6 of the "LiDAR Solutions in ArcGIS" series on the Geoprocessing Blog

Updating a portion of a terrain dataset with new measurements

I've also added the link to the first post in this thread.

A few tutorials on the basics of working with DEMs in ArcGIS that may be useful to OpenTopography users:

1. DEM: Downloading and Analyzing via ESRI's ArcLessons
"This 20-page step-by-step lesson walks a user through downloading a Digital Elevation Model from the USGS seamless data server, formatting it, projecting it, and using it within a 2-D ArcMap session and a 3-D session using 3-D Analyst. In addition, National Land Cover Data (NLCD), Digital Orthophotoquads (DOQ), and Digital Raster Graphic (DRG) data are also downloaded and used. Derivative products are created from the data, including contour lines, slope, aspect, hillshade, and TIN."

2. Digital Elevation Data via OpenTopography team member Ramon Arrowsmith's Computers in Earth and Space Exploration course at ASU.
"- How to acquire NED, SRTM and Orthoimagery data from the USGS website - How to get them into ARCGIS and change the projection (e.g. to UTM)
- How to produce a hillshade map
- How to produce a simple (but nice!) map in ARCGIS"

3. Digital Elevation Data II via OpenTopography team member Ramon Arrowsmith's Computers in Earth and Space Exploration course at ASU.
- How to use ArcScene to make a DOQQ three-dimensional

Part 5 of the "LiDAR Solutions in ArcGIS" has been posted to the Geoprocessing Blog

Creating Intensity Images from Lidar

I've also added the link to the first post in this thread.

Explanation and solution:

"This is a known issue with the early deliveries of the NoCal data and has been resolved for the later deliveries. When NCALM exported the tiles a few had the wrong projection assigned seemingly at random. If you look at the projection of the tile offset to the north (ug596_4149) you'll see that it is "Clarke_1866_UTM_Zone_10N" instead of the "WGS_1984_UTM_Zone_10N" projection assigned to the rest of the dataset (including tile ug595_4149).

The fix here is to use the "Define Projection" tool in ArcToolbox to redefine the projection for tile ug596_4149 to what it should be (WGS_1984_UTM_Zone_10N)...note that you want to redefine the projection NOT reproject the data. The data in the tile have the correct coordinates, Arc just gets confused and puts it in the wrong place because the projection definition is wrong."

-cc

A good question from an OpenTopo user regarding misaligned tiles downloaded from the system - this isn't the first time this issue has been identified, so I'm posting the problem and solution here:

"Could you please look at the two files listed below, they were downloaded from GeoEarthScope Northern Calif LiDAR Project.

fg596_4149
fg595_4149

...The two tiles will not line up side-by-side like they should (east to west). The east-most tile (ug596_4149) seems to be shifted up or north relative to the adjacent tile (ug595_4149)?

I view the LiDAR imagery through ESRI GIS v9.3. I also use the imagery to view my Trimble GPS data.When I place the GPS data, the locations appear to be the right scale, but shifted in the wrong place on the tile"

Here's an image to illustrate the issue:

Another post in ESRI Geoprocessing blog series on LiDAR point cloud data in ArcGIS:

Estimating Forest Density and Height

I'll add this to the first post above too.