lascopcindex64 not properly referencing subdirs in windows distribution? #172
Comments
|
I did the implementation of
No, it does not. It would be a nice addition but in my mandate I designed a fast an efficient copc file builder and did not include nice convenient features.
Well, I don't know about this one. The paths are parsed by LASlib as usual as far as I can tell, but this case could be checked.
COPC is a LAZ formats 6, 7, 8 that include gpstime. Moreover, the gpstime is required to sort the points in a way that minimizes the suboptimal compression that results from the COPC standard. Because the points are not in the natural acquisition order, the LAZ compression is less effective on a COPC file. However, if the points are properly sorted by gpstime, it is not that bad and a COPC file can be only 20% bigger than its counterpart pure LAZ with ordered according to the acquisition. This is why you have a warning when building a COPC from a file format without gpstime. Without gpstime the points are literally in a random order and the compression is likely to be terrible.
I'm not sure of that one. It seems that the CRS recorded in your file is not recognized. The CRS of your file is likely in a GeoTIFF format and must be converted to a WKT string in order to build valid COPC files that follow the specifications. I'd say that your CRS is not recognized and can't be converted. This one needs investigation and should at least print a more informative error. |
|
Hi Jean-Romain,
Thank you! I love that it's coming to The version of
My CRS (EPSG:6340, exported from I think that error might be due to some way that I was wondering if that's the reason for the error mostly because of this google groups post from Martin, where he said, "...you are running a duplicate version of In the
maybe @rapidlasso could add the CRS and output crs command line components and other standard ones that may not yet be integrated? I noticed from the orphan file after I control-c'd that -odir and -odix seem to be supported (but not documented).
Martin implemented a "dumb" or "simple" parallelization for many tools when wildcards were used for multiple files - eg las2las - this massively speeds up single-core operations on dirs of dozens to thousands of files - that's what I was referring to. Again, maybe since you don't have access to all of the code, that would be something for @rapidlasso to add?
I'm not sure how |
|
QGIS uses PDAL and PDAL uses a relatively similar approach to re-organize the points. When I'm saying terrible, I actually did not measure it. That a hypothetical through based on how points are re-organized, but maybe it is not that bad. But sure it would be better with gpstime and this is very likely true for PDAL as well. |
|
Just downloaded the new build. The error with lascopcindex64 not properly referencing the system path to pcs.csv and vertcs.csv still exists. No other lastools throw this error, but lascopcindex64 does: ERROR: cannot open 'pcs.csv' file. maybe your LAStools distribution |
|
Which command did you run? |
|
I'm not sure what you mean by "The error message you posted does not match the code situation." - The error I posted is exactly what the code spits out. I've been using lastools with no problems with the pcs.csv or vertcs.csv for like a dozen years. Lascopcindex64 does not find the files like las2las or any other lastool does. I'm sorry if I didn't explain that clearly enough above. I'ave included output from commands I just ran on a little test file, and I attached the file for you to play with too: Also I've run some comparisons converting with lascopcindex64, generating copc with metashape, and converting with QGIS/untwide/pdal - you can read those here Here are some commands I issued:
verbose
Directory of C:\utils\LAStools\bin\serf\geo 10/07/2023 10:59 PM .10/07/2023 10:59 PM .. 10/07/2023 10:59 PM 93,901 gcs.csv 10/07/2023 10:59 PM 1,805 my_epsg.csv 10/07/2023 10:59 PM 421 my_seven.csv 01/22/2024 09:42 AM 882,385 pcs.csv 10/07/2023 10:59 PM 17,299 vertcs.csv |
|
Thanks for your persistence and the sample. We could fix this issue with latest commit. |
Hi LAStools folks! I'm excited that you're adding a copc writer! I tried to use it though (in windows) and had issues. Let me know if I can help figure them out. For now I'm just using QGIS to convert although I've used PDAL too.
I have lastools installed in Windows in the c:\utils\LAStools\ dir with c:\utils\LAStools\bin added to my system environment variables. This has worked fine for the last ~10 years. when I run lascopcindex64 though I get some errors:
first, it looks like it doesn't allow specifying source coordinate systems/datums/etc? It would be nice if it supported those flags in the standard convention. For example:
lascopcindex64 -i *.laz -epsg 6340
ERROR: cannot understand argument '-epsg'
second, it looks like there's an issue discovering relative paths, and it doesn't support the standard multicore parallelization that Martin typically implemented for multiple files. This is what I see when I try to run it. Didn't let it finish because of the errors:
lascopcindex64 -i *.laz -cores 8 -odir copc -odix copc
WARNING: not compiled with multi-core batching. ignoring '-cores' ...
WARNING: building a COPC file without gpstime.
GeogGeodeticDatumGeoKey: look-up for 1116 not implemented
ERROR: cannot open 'pcs.csv' file. maybe your LAStools distribution
has no .\LAStools\bin\serf\geo\pcs.csv file. download the
latest version at http://lastools.org/download/LAStools.zip
set_ProjectedCSTypeGeoKey: look-up for 6340 not implemented
ERROR: cannot open 'vertcs.csv' file. maybe your LAStools distribution
has no .\LAStools\bin\serf\geo\vertcs.csv file. download the
latest version at http://lastools.org/download/LAStools.zip
WARNING: cannot convert CRS from GeoTIFF to OGC WKT.
^C
The text was updated successfully, but these errors were encountered: