Small library for getting the CRS in the form of a EPSG code from lidar files.

Either call ParseEpsgCRS::get_epsg_crs on a las::Header or use one of get_epsg_from_geotiff_crs or get_epsg_from_wkt_crs_bytes on the output of las::Header::get_geotiff_crs or las::Header::get_wkt_crs_bytes respectively

The library should be able to parse CRS's stored in WKT-CRS v1 and v2 and GeoTiff U16 (E)VLR(s) stored in both las and laz files (with the laz feature flag activated).

The CRS is returend in a Result<EpsgCRS, crate::Error>.
EpsgCRS has the fields horizontal, which is a u16 EPSG code, and vertical, which is an Option<u16> EPSG code.
If a parsed vertical code is outside EPSG_RANGE it is ignored and set to None.
If a parsed horizontal code is outside EPSG_RANGE an Err(Error::BadHorizontalCodeParsed(EpsgCRS)) is returned.

The validity of the extracted code is only checked against being in EPSG_RANGE.
Use the crs-definitions crate for checking against a registry of valid horizontal EPSG codes.

Be aware that certain software adds invalid CRS VLRs when writing CRS-less lidar files (f.ex when QGIS convert .la(s,z) files without a CRS-VLR to .copc.laz files). This is because the las 1.4 spec (which .copc.laz demands), requires a WKT-CRS (E)VLR to be present (or more generally, all lidar files are supposed to contain CRS data). These VLRs often contain the invalid EPSG code 0 and trying to extract that code will return a BadHorizontalCodeParsed Error.

Parsing EPSG codes from user-defined CRS's and CRS's stored in GeoTiff Ascii or Double data is not supported. But the relevant las::crs::GeoTiffData is returned with the Error::UnimplementedForGeoTiffStringAndDoubleData(las::crs::GeoTiffData).
If you have a Lidar file with CRS defined in this way please make an issue on Github so I can take a look at parsing them. I have yet to see a Lidar file with CRS defined in that way.