Instead of entwine/1234 for the VLR, it might be useful to use entwine/1000, which would allow us a convenient semver opportunity should we ever need to bump things.

It seems that the chunk table position in the illustration does not match how the LAZ file is actually organized.

In the illustration it's positionned between the VLRs and the points but in reality the chunk table is written after the points and between the VLRs and points there are 8 bytes that contains the offset to the start of the chunk table.

Nowadays the Entwine builder adds detailed dimension statistics to its schema (see here for example) including minimum, maximum, mean, stddev, and variance. Currently this is sort of an undocumented extension intended to be eventually be codified as an optional (in order to be backward-compatible) extension to the EPT specification. Would it be worth specifying a statistics VLR to capture this information? I think the "number of points by return" array in the LAS 1.4 header adds precedent for this kind of thing.

An example might be:

struct BucketItem
{
  double value; // Maybe int64_t here - presumably this is only for integral dimensions
  uint64_t count;
}
struct CopcStatistics
{
  double minimum;
  double maximum;
  double mean;
  double stddev;
  double variance;
  uint64 number_of_buckets; // 0 for most dimensions, but this one is nice for Classification counts
  BucketItem[] buckets;
}

These statistics would then be stored in the order that the dimensions appear in the point data record format header, followed by statistics for extra-bytes dimensions in the order that they appear. Is there enough demand for this type of information to put it in the spec? Enough to require it?

One example of their usage I found is wonder-sk/point-cloud-experiments#60: "QGIS implementation is able to read those stats and use them to set up renderers (min/max values are especially useful to correctly set ranges for rendering)".

If anyone has other concrete use-cases where such data would be used, that would be useful.

I think this is outdated:

Add laz_vlr_offset, laz_vlr_size, wkt_vlr_offset, wkt_vlr_size, eb_vlr_offset, eb_vlr_size to the COPC VLR, replacing 6 reserved entries.

It would be nice if the "important" VLRs were all at the beginning of the file to reduce round-trips when first reading the data over a network connection. Suggest LASZIP VLR/COPC VLR/EB VLR.

It seems to me that the COPC spec currently talks about VLRs but actually conflates VLRs and EVLRs, which may be problematic since the LAS spec clearly distinguishes between those.

Obviously, the info record cannot be an EVLR due to its location requirement, but it might be good to know whether hierarchy and extents must be represented as VLRs, EVLRs, or can be either.

(For anyone wondering, the Autzen sample currently has info and extents as "classic" VLRs, while its hierarchy is an EVLR.)

We (rockrobotic) would love to help on getting the spec and work finalized. Would it be helpful to use the issue queue and assignees or just a task list here?

There's a chance here to correct the choice of EPT by not carrying over span as the concept of resolution/density/spacing.

Entwine/EPT chose this term, which represents the grid width of the voxelization of the data nodes, because of its strict voxelized resolution guarantees at each node depth. However this isn't the only sampling method possible, and Poisson, randomized, FIFO, and other non-gridded distributions may be possible. Also, EPT had the specified limitation that it must be voxelized via a power of 2, which doesn't need to be true for COPC.

In general, span is a very confusing metric that needs a lot of explanation, even though what it represents is actually simple. See for comparison the definition of the Potree equivalent to this field by @m-schuetz:

spacing: (Number) Space between points at the root node. This value is halved at each octree level.

While this definition is directly convertible to a span, its meaning is much more concrete and easy to understand.

I would propose replacing the integral span field in the COPC header with a double-precision field representing the spacing or distance between points at the root node, to more clearly represent the density of the data at each depth without the indirection of span.

Possible terms include spacing, distance, resolution, and the description should indicate that this is not necessarily a 100% deterministic value: in a given node some points may end up being closer together or farther apart than this value depending on the sampling method.

It is possible to have a node level with zero points, but there are points below it. 0-sized chunks are not valid in LAZ. A note describing how to advertise this to hierarchy consumers is required.

It would be nice if the WKT VLR could be located easily without searching. Adding an offset in the COPC VLR to the actual WKT data would support this.

Hi! I'm working on converting las files to copc.laz format and have successfully generated the output files. However, I am looking for ways to validate the generated COPC files.

I came across this link https://github.com/copcio/copcio.github.io?tab=readme-ov-file#validation..But the https://validate.copc.io/ option doesn't show any output and I am not sure how to use the cpp version. So, is there any alternate ways to validate the COPC files? (maybe using Python API or pdal CLI similar to pdal info).

Thanks.

Are we at a point where we can lock the spec for v1.0.0?

All issues are resolved here (sans new example file). If we cut the 1.0.0 version, then other libs would be able to fully implement the spec and ensure future changes.

In the implementation note you wrote

COPC is designed so that a reader needs to know little about the structure of a LAZ file. By reading the first 549 bytes (375 for the header + 54 for the COPC VLR header + 160 for the COPC VLR), the software can verify that the file is a COPC file and determine the point data record format and point data record length, both of which are necessary to create a LAZ decompressor.

375+54+160 = 589 not 549

Are there any thoughts/conventions for MIME/Content-Type values for COPC files?

• LAS is registered as application/vnd.las
• LAZ is registered as application/vnd.laszip

Maybe application/vnd.laszip; profile=copc ?

Related issues for COGTIFF: cogeotiff/cog-spec#13 opengeospatial/CloudOptimizedGeoTIFF#1

This is the one-week call to bring up any significant issues with COPC before we declare it released. Please post any items on this ticket, and we can create new tickets should the need arise. With no significant findings or items, we will declare the release final on 29 NOV 2021.

@m-schuetz's post #19 (comment) about desiring dimension type information brings up the question of whether it might be more generally useful.

My thought on the topic is COPC files are LAS/LAZ, and the dimension types and mappings of LAS files are generally known. Extra byte dimensions are rarer, and the type mapping of those dimensions is indeed missing.

Can any reader client developers make a stronger case for this? @connormanning @CCInc ?

The COPC offsets below are redundant info which is already contained in the LAS VLRs directly:

  uint64_t laz_vlr_offset;      // File offset of the *data* of the LAZ VLR
  uint64_t laz_vlr_size;        // Size of the *data* of the LAZ VLR.
  uint64_t wkt_vlr_offset;      // File offset of the *data* of the WKT VLR if it exists, 0 otherwise
  uint64_t wkt_vlr_size;        // Size of the *data* of the WKT VLR if it exists, 0 otherwise
  uint64_t eb_vlr_offset;       // File offset of the *data* of the extra bytes VLR if it exists, 0 otherwise
  uint64_t eb_vlr_size;         // Size of the *data* of the extra bytes VLR if it exists, 0 otherwise

What is the use-case for this data being duplicated? It seems error-prone to have the same data in multiple spots, and also seems to go against the push behind COPC - to live as a spatially organized structure inside a format that we don't have to invent. Here we are reinventing (a subset of) VLR header information in our own header format.

As for implementing the spec, if you are using a COPC or LAS library like the ones I linked above, you have the VLR information packaged for you for free. And if not, you are going to be manually parsing out the LAS header, the bodies of the VLRs (even if not their headers due to this duplication), walking and parsing the hierarchy, and others. The few lines of VLR header parsing are comparatively trivial.

Both current implementations copc-lib and copc.js awaken the VLR headers on initialization and then ignore these COPC header values in favor of the VLR headers.

And as for reading the data, the magnitudes here are on the order of a few hundred bytes and would generally only be parsed once per reader instance, so I'm skeptical of a big performance impact.

So is there a concrete use-case for this data to exist? I would consider removing it to keep the format simple and less error-prone in the absence of a concrete need.

What do we think about standardizing the file name[filename].copc.laz to represent this file at a high level/easily?

We know there will be a VLR that defines the type as a COPC file, but that doesn't help some processors quickly know how to act (https://github.com/potree/potree/blob/develop/src/Potree.js#L139-L211)

It would be possible to build in the handling that does the check but as I understand it, it would require us to read the header for the VLR and then parse that (not ideal) to do the switch.

• in CopcData, why int64_t span and not uint64_t ?
• in Entry, why int32_t byteSize and not uint32_t ? And given that it might be size of the child hierarchy page, and that Page::count is 64 bit, shouldn't that be a 64 bit integer ?
• in Entry, why int32_t pointCount, and not uint32_t ?
• in Entry, int32_t pointCount: why not have it a uint32_t and use 0 as a special value instead of -1 ?

The current test file is in point format 3 which doesn't fit the specs.
See PDAL/data#3 for a proposed fix.

For EPT, it is pretty easy to understand the structure and the parsing, but this will be a little more verbose, should we add a sample dataset or a link to a sample dataset?

extents by itself isn't particularly useful in practice. Knowing the min/max only helps you for a few dimensions, and if you're a renderer, you want much more than just that.

I think we should drop extents and put forward a definition for a copc stats VLR that is more fully featured but OPTIONAL. Importantly, the stats VLR could be something that could be added as an EVLR long after the file is created instead of during the COPC file creation process.

Principles of the stats VLR are pretty much as @connormanning suggested in #19, but we should do something specified as JSON, with a corresponding JSON Schema that allows implementations freedom to augment with auxiliary information if they desire.

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.