You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If a copc file is modified i.e. read and streamed into an output file with some modifications to retain points of interest for example, or simply decompressed, all the copc VLR and EVLR should be removed otherwise the file becomes an invalid and corrupted copc file.
It may seems obvious but the existing tools are not copc aware and are supposed to preserves the VLR and EVLR when writing a file. In the current state many software are likely to produce corrupted copc files when processing a copc file. I'm thinking, for example, about las2las or laszip from lastools that preserve all the VLR and EVLR and are not copc aware yet. Many more existing tools should be impacted the same way. Consequently, in the current state, one can easily generate invalid copc files with an irrelevant EPT hierarchy.
I'm suggesting to explicitly mention somewhere in the specs that a copc file is read only and any writer that is not copc aware should always get rid of the copc VRLS and EVLR when the input is a copc file. That won't solve the problem in existing market but will at least show explicitly the information.
The text was updated successfully, but these errors were encountered:
If a copc file is modified i.e. read and streamed into an output file with some modifications to retain points of interest for example, or simply decompressed, all the copc VLR and EVLR should be removed otherwise the file becomes an invalid and corrupted copc file.
💯 this. COPC VLRs are invalid upon any rewrite of the file, as this changes the organization and the linkage between what the VLR points to and the chunks in the file is broken.
In the current state many software are likely to produce corrupted copc files when processing a copc file.
Yes, this is possible. Paranoid implementations can make a simple check however. When parsing the COPC VLR, each byte location it is going to point to is an uncompressed first point that denotes the beginning of a chunk. If it points into junk the COPC VLR is invalid. Additionally, the LASzip VLR's offsets and the COPC VLRs offsets must match. If they don't, the COPC VLR is invalid.
We have implemented a NodeJS COPC validation software at https://www.npmjs.com/package/copc-validator and users can run this over data to get a synopsis of the file's state in regard to COPC validity.
If a copc file is modified i.e. read and streamed into an output file with some modifications to retain points of interest for example, or simply decompressed, all the copc VLR and EVLR should be removed otherwise the file becomes an invalid and corrupted copc file.
It may seems obvious but the existing tools are not copc aware and are supposed to preserves the VLR and EVLR when writing a file. In the current state many software are likely to produce corrupted copc files when processing a copc file. I'm thinking, for example, about
las2las
orlaszip
fromlastools
that preserve all the VLR and EVLR and are not copc aware yet. Many more existing tools should be impacted the same way. Consequently, in the current state, one can easily generate invalid copc files with an irrelevant EPT hierarchy.I'm suggesting to explicitly mention somewhere in the specs that a copc file is read only and any writer that is not copc aware should always get rid of the copc VRLS and EVLR when the input is a copc file. That won't solve the problem in existing market but will at least show explicitly the information.
The text was updated successfully, but these errors were encountered: