Messages posted by: ccrosby

Deleted it.

Yes, sorry Steve. As part of the updated data release (http://www.opentopography.org/index.php/news/detail/updated_tahoe_data_products) we also added projection definitions to all of the point cloud files since they were not delivered with coordinate definitions set by the vendor. We're in the process of pushing this new set of files over to the bulk download server. The old files are in _old, but I recommend you grab the new files once the transfer is complete. Sorry about the confusion.

-cc

Yes, the site is HTTP accessible and a download manager or a simple wget or curl request is the most efficient way to access the data. We assume that if you want that much data you also know how to automate a download from an http site.

-cc

FYI: We've released an updated set of data products for Tahoe that correct some issues identified with the first release. See for more information: http://www.opentopography.org/index.php/news/detail/updated_tahoe_data_products

Kittipat - thanks for sharing your MATLAB filtering software. It looks quite promising and I will play with it when I have a chance.

I'd strongly encourage you to take 5 minutes and register your software in the OpenTopography Tool Registry (http://opentopography.org/tools) so that it is visible to other lidar users. Click the "Contribute" link to get started.

-Chris

BingCai,
I think we addressed this problem via email yesterday correct?

A file such as 38119F8101N.las would only be available via the bulk download file server. Click the "Bulk Download" link above the map to access the file server.

-Chris

Steven,
I do not include the Min surface in the pre-computed Google Earth image overlays because I typically generate bare earth and highest hit surfaces. As you know, the Min output falls someplace between these two products.

An auto split feature is something we could explore, but it may be a bit tricky, and would still result in boundary effects. In some ways the preferred solution is just to improve the OT processing systems and algorithms to allow larger jobs to be run. This is a constant effort for us.

What I recommend, is that you download the original Tahoe point cloud data files from our bulk server (you already have access as a power user). Then, grab the Points2Grid (our binning algorithm that outputs the Min surface) source code, compile it, and set up a little script to process the full Tahoe dataset to whatever products you need. Although OT is great for most applications, there are still situations where local data processing via scripting is more efficient and controllable.

More information on the Points2Grid source and link to the SourceForge download page is here: http://www.opentopography.org/index.php/resources/otforge/points2grid

Thanks,

-cc

FYI: We've posted the vendor generated DEMs and intensity rasters for download. More information in this blog post: http://www.opentopography.org/index.php/blog/detail/tahoe_standard_dem_data

-cc

FYI, since the issue was discussed by Janet and Jarlath earlier in this thread, you can now download the vendor generated DEMs (and intensity rasters) from OT: http://www.opentopography.org/index.php/blog/detail/tahoe_standard_dem_data

-cc

Hi Daniel,
Building footprint extraction from lidar point cloud data is an area that I don't have a lot of experience in given that OpenTopography primarily emphasizes Earth science applications of the data. My understanding is that this is an area of active research - have you consulted the literature to see what the latest approaches are?

Classification for OpenTopography-hosted data vary greatly. In most datasets points have been classified to differentiate bare earth but buildings and vegetation points are typically undifferentiated and assigned to the "unclassified" class. The EarthScope NoCal data are of this category.

There are certainly commercial software products that would allow you to import the point cloud and then further classify the data. Terrasolid is the industry standard software package and is what is used by many data vendors. In the open source realm, you might look at GRASS GIS, and the v.lidar.edgedetection, > v.lidar.growing > v.lidar.correction series of commands which are advertised as being able to "recognize and extract attached and detached object (such as buildings, bridges, power lines, trees, etc.) in order to create a Digital Terrain Model". I have not explored this functionality in any detail so can't comment on its effectiveness.

Finally, you might look at return intensity. If the building roofs are consistently dark, you may be able to use that attribute to help extract footprints.

Good luck. Let us know how it goes.

-Chris

Steve, yes, the min elevation raster sometimes works ok as a low-budget vegetation filter, but in dense forest it is never going to beat a real classification algorithm. It works best when vegetation are sparse (e.g., sagebrush) and the search radius is set a bit larger than the default so that you're able to capture ground points surrounding the vegetation.

Looking forward to seeing the results of Jarlath's work to reclassify the points based on the imagery.

-cc

We have a copy of the WSI produced DEMs too - we'll try to get them posted next week. I think WSI uses a TIN to generate their surface models.

-cc

Hi Janet,
Thanks for the post. There are a few issues here that you are seeing.

The first is that the slope and hillshade rasters that are output by OT are 32-bit floating point GeoTIFFs. Depending on the software you are using, you probably need to calculate the statistics on the grid since many GIS packages don't handle 32-bit grids very well. If you are in Arc, you can go to the grid layer properties and choose a stretched color ramp - Arc will ask if you want to calculate statistics. Say yes and then the correct grid values should be displayed.

Regarding the ground model: OpenTopography uses a local gridding algorithm to generate a grid from the lidar returns. Because the ground sample density in vegetated areas tends to be low (< 1 shot per meter), the algorithm, when run with the defaults, often doesn't find any ground points for a given local search area, and thus sets the DEM cell to "null". This is a very honest (and computationally efficient) way to grid the data, but it requires some tweaking to generate good ground models. If you see lots of nulls in the grid (your "ground_hillshade.jpg") image, then you need to tweak the settings. You can either expand the search radius (use a higher value in the "Radius value" box - e.g., 2 meters). You can also fill the null values in the grid by using the "null filling" option on the processing page. By default, null filling is set to "none", but you'll get much better bare earth models if you use null filling (which uses a focal mean via a rectangular moving window of 3x3, 5x5 or 7x7 cells to calculate the value of a null cell). See attached images for a comparison of null filling = none vs null filling = 7.

Keep an eye on the OpenTopography blog (http://www.opentopography.org/index.php/blog) where I'll try to do a longer post in the next few days on how to optimize DEM generation with OpenTopography. I should also note that we are about to add a TIN algorithm to OT, which should do a much better job of gridding ground points.

Steve,
Jarlath's suggestion re: going back to the original points to look at the classifications is a good one. But, my guess is that in the granitic landscape with high curvature (dominated by boulders) with vegetation growing between the rocks and in joints, the automated point cloud classification routines are going to have a hard time making the distinction between rock and vegetation, and thus is likely striping topographic details. We see similar issues in the desert where sharp edges in the landscape (e.g., arroyo channels banks), get planed off by the classification routine.

A good intro to how these classification routines work was present by Ralph Haugerud at our 2009 Geological Society of America short course. Check out the "Return Classification & Anatomy of a Data Set" slides here: http://www.opentopography.org/index.php/resources/short_courses/09gsashortcourse

-cc

Yes, adjusting the transparency to "blend" the hillshade into the native imagery is a nice approach.

I'm not familiar with the shading method you propose.

Google Earth supports 3D trees now - is this what you are thinking?:
http://www.google.com/earth/explore/showcase/trees.html

-cc