Don't use EVLRs unless you really really have to

[Martin Isenburg]

Hello,

the new LAS 1.4 specification introduces a new concept: EVLRs. They are very useful. They are the only way to *add* VLR with huge payloads (more than 65535 bytes). And they are also great to *modify* an existing LAS/LAZ file on disk in place without a full re-write, for example, when all one wants to do is add CRS information.

However, I like to make the case against using them if possible and restricting their use to the two scenarios outlined above. If at all possible use VLRs and "promote" all small EVLRs to VLRs whenever rewriting a file (assuming this would drop their number to zero). Please don't make it mandatory to place the tiny CRS records into a EVLR that may just as well (and better) life in a VLR. Is it true that there are some specifications (USGS?) that ask folks to do so ...?

Why do I say this? I was one of those who suggested those EVLRs in the first place. Why don't I like them anymore? Well, I only like them in the two scenarios outlined above where they *add* value to the LAS / LAZ format. In general they complicate things. Especially for piping.

The concept of EVLRs is inherently incompatible with "piped processing" because the start of the EVLR block needs to be written at the very beginning of the file. This is only possible if I know exactly how many points I will write and if each point record occupies the same number of bytes. Hence any point source that cannot pre-determine the number of written points, any filter operation, or LAZ compression cannot operate in a piped mode if an EVLR block is present because the "start_of_first_extended_variable_length_record" field cannot be written correctly.

Here an example of some simple piping (with LAStools) that will not be possible when EVLRs are present:

====== piped lasinfo report ======

las2las -i input14withEVLR.las ^

            -keep_first ^
            -stdout |

lasinfo -stdin -o input14withEVLR_filtered.txt

=======  piped DTM creation =======

lasground -i input14withEVLR.las ^
                 -city -extra_fine  ^

                 -stdout |

las2dem -stdin ^

               -keep_class 2 ^

               -step 0.5 -use_tile_bb ^
               -o input14withEVLR_dtm.bil

====   piped pit-free CHM creation ====

lasground -i input14withEVLR.las ^

                 -wilderness  ^
                 -replace_z  ^

                 -stdout |

las2dem -stdin -pipeon ^

               -step 0.5 -kill 1.5 ^

               -o chm_000.bil |

las2dem -stdin -pipeon ^

               -drop_z_below 2.0 ^

               -step 0.5 -kill 1.5 ^

               -o chm_020.bil |

las2dem -stdin -pipeon ^

               -drop_z_below 5.0 ^

               -step 0.5 -kill 1.5 ^

               -o chm_050.bil |

las2dem -stdin -pipeon ^

               -drop_z_below 10.0 ^

               -step 0.5 -kill 1.5 ^

               -o chm_100.bil |

las2dem -stdin -pipeon ^

               -drop_z_below 15.0 ^

               -step 0.5 -kill 1.5 ^

               -o chm_150.bil |

las2dem -stdin -pipeon ^

               -drop_z_below 20.0 ^

               -step 0.5 -kill 1.5 ^

               -o chm_200.bil 

Your thoughts?

Martin @rapidlasso