Lidar: Coordinates and Formats

There was recently a question about the Digital Coast lidar holdings via twitter. The questions involved why our lidar had horizontal coordinates of latitude and longitude and why we had LAS 1.2 instead of LAS 1.4 format. The answers are too long for twitter, so I’ll try to address them here. Or just stop with the TL;DR answer.

TL;DR answer: we keep things in their native format and not everyone wants the same projection.

Let’s start with the format. Essentially we don’t change them from their format when we received them. If they came as LAS 1.2, they stay that way. We don’t convert them to LAS 1.4. You’ll find some LAS 1.1 and maybe even 1.0 data too. Why don’t we convert? Essentially, there is no obvious gain from doing so. That’s not to say there aren’t gains from using LAS 1.4 when working with the data, but just changing the format doesn’t add any information. If your processes are going to have advantages with LAS 1.4, by all means use something like las2las (open source part of LAStools) to convert.

There was a statement that USGS is serving all their data in LAS 1.4, but I don’t think that is true. It is true that data conforming to the 3DEP specification will be in LAS 1.4, but there is lots of older data on the rocky ftp site that is in its original format. I haven’t thought of a good reason to justify wholesale conversion of trillions of data points. If there is one, I’d like to hear about it.

I did find out that the original question revolved around LAS 1.4 data that had been compressed to LAZ before a native compressor existed. Those files look like they are compressed LAS 1.2, but become LAS 1.4 when you uncompress them with laszip. They have since been fixed to use the native compressor.

How about those coordinate systems? The complaint that passed by my desk was that geographic coordinates weren’t helpful and why weren’t they all in UTM like the USGS. So, I’ll admit that geographic coordinates have their drawbacks. As does everything else. The biggest drawbacks I know of are: 1) you’re only going to get a precision of around 1 cm horizontally; and 2) the horizontal and vertical coordinates aren’t the same, so some 3D analytics that assume the same units in all directions won’t work. The first one isn’t that big a deal because the horizontal accuracy of airborne lidar isn’t anywhere near a centimeter. The spot size alone is far larger. The second one is a legitimate issue.

Why not make everything UTM? That probably sounds great if you use UTM all the time. A lot of academics fall into that category. However, a lot of engineers do not. They fall in the state plane category and may even be required to use state plane. There is no one projection to rule them all. Anything I pick will make someone less happy. For projected systems, there is also the problem of data sets that cross boundaries. This doesn’t occur to a lot of people because their area of interest is fairly constrained, but there are data sets that span multiple states and multiple UTM zones. That makes things ugly and you have to pay a lot more attention when merging data. I have definitely gotten data that had been in two different UTM zones and then converted as if it was in one zone, creating a six degree separation of the data.

Geographic coordinates are one system that lets us use the same system everywhere. This was more important early on when getting properly coded LAS files was a bit iffy. As long was we knew what the data was in, we could convert to geographic and have confidence in what we were dealing with instead of relying on poor software to figure it out. Software is a lot better now and we could probably change, but it would still make a processing flow change for our custom system (Data Access Viewer; DAV). Right now, we can merge the data needed for a request into one file and then reproject to the requested projection. If the projections might vary, we would have to reproject each file first and then merge. Not a big deal, but slightly messier with more things to keep track of.

Since I brought up the DAV system, I think it’s worth talking about the different intents of the data distribution we have. Originally, we only had the custom system and a user never saw what projection the base data was in. It also happens to be in ellipsoid heights. The DAV system does a lot of processing for you, including reprojection. However, the limits on how big a job we could safely process without causing problems meant that you couldn’t use it to get a county worth of data. We started to put the data onto an ftp site for those people that needed a full county of data (after applying the latest geoid model). The theory was that if you needed a full county of data, you probably had the knowledge and horsepower to handle changing projections and lots of other things. There is a handy table of those data sets. If we hadn’t turned everything into geographic coordinates, we would probably need to do the same thing USGS did and put it out in whatever projection in came in as (not all UTM by the way).

What about the future? The USGS and 3DEP plan is to use Albers Equal Area projection as their standard. There are lots of things to work out still and it’s likely we’ll see data delivered in multiple projections. Essentially though, they’re making the same sort of decision we did with geographic and trying to cover the ground with one system. They also wanted equal area for consistent acquisition sizes. There are good reasons for having different projections and your favorite system isn’t going to make everyone else happy. It’s best to make sure you’ve got some tools to get from one system to another. By the way, all those reprojections go through geographic to get from one system to another. You’ll also go through geographic to do datum transformations.