PC_SetPCID(pcpatch/pcpoint,pcid)

[mbredif]

(Replaces #12 and #13)

The intent of PC_SetPCID(pcpatch/pcpoint,pcid) is to change the pcid as quickly and efficiently as possible without looking at its raw payload values, similar to a glorified ST_SetSRID(geometry).

The main optimized use case is to efficiently select a subset of the columns (cf former proposals #12 and #13 for a PC_Get(pcpoint/pcpatch,text[]) : pcpoint/pcpatch), while possibly modifying the srid, offset and scales.

It just :

• changes the pcid in the header (hence the srid as well)
• drops and adds dimensions without looking at the scales/offsets, based on the set of dimension names of the old and new pcids.

Requirements (to be discussed) :

1. if the dimension ordering and interpretations are unchanged, just pass the original payload.
2. internal types (interpretation) should stay unchanged. That would enable very efficient implementation for dimensional patches (keep and reorder relevant PCBYTES, create RLE-compressed PCBYTES of zeros for new dimensions), uncompressed patches would require 0(npoints*ndims) memcpys (or maybe less if coalesing is possible, case 1 being the extreme case of a single coalesced memcpy), other compressions could fall back to uncompression.
3. new dimensions have a constant raw value (unscaled/unoffset) of 0. Or should it be a scaled/offset value of 0 ?

This proposal, compared to the current implementation offers the possibility of more efficient implementations by not taking into account the possible change of scale/offset.

PS: The active attribute in schema dimensions is unused for now. It could be relevant to handle dropped dimensions.

[mbredif]

@elemoine, @pblottiere, I gave a try at this one here : mbredif/pointcloud@d02500e
what do you think ?

[elemoine]

@mbredif do you have specific use-cases for PC_SetPCID that we need to cover? If so then I'd suggest that we implement the minimum that fullfills our needs.

For example, a simple implementation could involve just returning an error when we cannot complete the operation with just one memcpy.

I am really not sure right now, so i'd just keep it simple, and stick to our minimum requirements.

Sorry if I'm stating the obvious here!