Every now and again, over the past couple of years, the question of “lidar on the web” has come across my desk. People ask, how do we serve lidar data – point clouds – efficiently over HTTP to a browser? I don’t have any good answers yet, but in this article I’ll at least try to frame the problem a little better and mention a couple standards – open standards, natch – that might lead us in the right direction.

You Want to Do What?

Maybe it’s not you, and it certainly isn’t a majority of us, but there are some people out there in Lidarland that have a problem. They have large lidar data holdings spinning on file servers behind a firewall, and they want to make that data available to users (or applications) outside that firewall. As examples, they might want to be able to the following sorts of tasks:

·         Display a 2D DEM of the data, perhaps with a particular interpolation model and a particular color palette for colorizing by depth

·         Display a contour plot of the surface, with user-specified intervals, overlaying a 2D ortho raster

·         Generate a TIN model and render it as a 2D image taken from a given camera point, perhaps with some customized settings for hill-shading – and allow the user to pan and zoom freely (and smoothly!) about the model

Just storing the raw point clouds on disk isn’t sufficient for your users anymore, because the users increasingly aren’t on your fancy local high-bandwidth network and because they don’t want the raw points anyway: they want the data processed into products they can make use of.

Serving It Up, Statically, in 2D

Let’s start by pre-rendering a whole bunch of DEMs and contour plots and make them available to be served up on demand as a set of tiled PNGs. This works only if you know in advance what the interpolation model, hill-shading parameters, and color palettes are going to be used. If you don’t know that information, you could always generate the tile on the fly for the DEM with the currently requested settings – and for extra credit, you could cache the result just in case some user wants that tile with those settings again later.

This model of serving data is mature technology for raster and vector data displayed as 2D imagery, typically using the OGC’s WMS (Web Mapping Service) standard. With WMS, you construct an HHTP GET operation with parameters for the bounding box and perhaps other styling parameters, and pass that to the URL endpoint of your WMS server. If the parameters in the request match a tile you already have cached, then great – otherwise, you build the tile, copy it to the cache, and send the PNG’d tile back to the requestor.

Alas, this approach doesn’t scale well if your users are going to be parameterizing the requests in many different ways. You’ll spend a lot of time trying to quickly generate tiles, and your cache hit ratio is likely to be low.

You Want Fries With That?

The WMS approach doesn’t work at all for the third use case I posed: allowing the user to pan and zoom around through a TIN model. The WMS protocol doesn’t allow you to specify the sorts of information you’d need for the camera model, it only allows you to give a simple bounding box. Another OGC specification, WPVS (Web Perspective View Service), is essentially a proper “3D” version of WMS. While not widely implemented today, it is an open standard and addresses part of our use case.

What WPVS doesn’t support is the interactive aspect we need. Even assuming you had prebuilt the TIN on the server, trying to have the WPVS server render each incrementally different view as a 2D raster and sending to the client isn’t feasible in terms of server computation time, network latency, and network bandwidth.

Various methods have been tried for streaming 3D objects via HTTP in the past, e.g. for operating interactively in a game-like world environment. Unfortunately, that isn’t our use case either: we don’t have “objects” in our lidar data, we just have raw points. (Yes, we might actually have a TIN, but that’s not a streamable “object” either. Some academic research has been done in this area, however.)

A Stream of Zoomable, Cacheable, Locally-Renderable Points

Making dynamic views of 3D data is hard, and my suspicion is that this is a case where the heavy work needs to be pushed down from the server to the client. I suspect the solution is ultimately going to require a combination of four technologies:

·         The ability to incrementally stream points to the client, as opposed to just sending all the data at once. Some raster data servers, such as JPEG 2000, have supported such a mechanism for years.

·         Access to the points on the server in a resolution-dependent manner. Just like pyramids of GeoTIFFs or multiresolution file formats like JPEG 2000 or MrSID, from a distance you may need only to use one point to represent what is actually, when zoomed close in, a cluster of individual points. In the computer graphics world this is typically called Level of Detail (LoD) control.

·         Smart clients which do the rendering locally. GPUs are powerful enough now that, even on low-end hardware, complex scenes can be quickly rendered from points or a TIN.

·         Browser-based, client-side caching of point data. Lidar data is big, and we don’t want to round-trip back to the server to refetch point data we already saw. To the extent practical, we need to be able to store points locally.

Yes, I did say “browser-based” there in that last bullet. Like it or not, the world is indeed tilting towards apps based on HTML and JavaScript over HTTP (although they increasingly may not look like they’re operating in a browser). And fortunately the new HTML5 specification for W3C looks to offer powerful 3D rendering via WebGL and substantive local storage via IndexedDB.

We don’t yet have a good handle on the first two bullet points. The streaming part is probably relatively straight-forward, but we need to define a standard protocol for it, like we did with WMS and 2D raster data. Getting an efficient, cacheable representation (and initial computation!) of the points in a multiresolution space isn’t quite there yet. We need to develop some standards for defining spatial-tree data structures of cacheable units of points.

Not Yet. But Soon.

Our workflows are still often built around derivative products, not the original point clouds, and lidar workflows aren’t as “web-savvy” as a lot of the workflows for the traditional geospatial data types. (Indeed, most every GIS viewer these days allows you to view either a local file or a web service feed like WMS or WFS.) I suspect our industry isn’t yet hurt by the lack of ability to work efficiently with point clouds over the web – but as I said at the beginning of this piece, I do know there are people thinking about how to solve the problem already.

And when the time comes, the solution will be an open standard, either as a de jure standard developed by a group like OGC or as a de facto standard developed by the open source community. Significant pieces of the GIS web infrastructure built on proprietary, closed standards hamper interoperability and simply aren’t acceptable to most of the community anymore.