Add transform functions

[elemoine]

The plan is to have the li3ds extension provide data transform functions. And the type of objects we want to be able to transform is 3d bounding boxes.

We need multiple functions:

A function that takes a bounding box and a transform id, and that returns the transformed bounding box:

transform_apply(box box3d, transform integer, timestamptz time default null)
returns box3d

The time parameter has no effect if the transform is static.

A function that takes a bounding box, a config id, a source referential id and a target referential id, and that returns the transformed bounding box:

transform_apply(box box3d, config integer, source integer, target integer, timestamptz time default null) 
returns box3d

Internally, the above function will use the dijkstra function.

When we have the above functions we can add a higher-level function that takes a datasource id, a config id, a target referential id, and returns a transformed bounding box:

transform_apply(datasource integer, config integer, target integer, timestamptz time default null)
returns box3d

If time is null, and if capture_start and capture_end are equal for the datasource, then capture_start can be used to get the parameters of dynamic transforms.

@mbredif, @ldgeo, @arnaudbirk, what do you think about that? Does that match our discussion on Thursday?

[mbredif]

transformed type

The types which we may want to transform are:

1. XYZT axis-aligned bounding boxes x0, y0, z0, t0, x1, y1, z1, t1, possibly with t0=t1, eg for image acquisitions which are instantaneous, by contrast with eg lidar point cloud acquisitions.
2. XYZ frustum + T interval [t0,t1]. A frustum is a generalization of a bounding box that is more flexible and thus possibly tighter than an axis aligned bounding box. It is defined as the image of the unit cube by a projective transform, encoded by a 4x4 matrix.
3. XYZT pcpoint / pcpatch
4. (XYZM postgis geometry (with M=time) ?)

• 1 could be encoded with a bounding diagonal (PC_BoundingDiagonal would then readily provide the bounding box of the pcpatch of a point cloud).
• 2 is an optimization of 1 (tighter bounds, exact bounds for images without distortions), so let us start with 1
• 3 and 4 are simpler to implement as they imply point transformations only rather than bounding volume transformations. Implementing them first could give some insight at reduced dev cost.

single transform application

(box4d is the xyzt bounding box, which may be a postgis XYZM bounding diagonal geometry or something else)

I propose one of these :

li_transform(box box4d, transform integer) returns box4d -- compact version
li_transform(box box3d, transform integer, float tmin, float tmax) returns box3d -- developed version

The time parameter has no effect if the transform is static.

One may want to check that time falls within the transform validity period or return NULL. We need 2 times tmin,tmax for non-instantanneous acquisitions (eg lidar)

transform stack application between referentials

A function that takes a bounding box, a config id, a source referential id and a target referential id, and that returns the transformed bounding box:

li_transform(box box4d, config integer, source integer, target integer) returns box4d -- compact version
li_transform(box box3d, config integer, source integer, target integer, float tmin, float tmax) returns box3d -- developed version

I vote for the compact versions.

transformed bounding box of a datasource

extracting the 4D bounding box of a datasource (whatever the type, expressed in its own referential) could be packaged in a function

li_datasourcebox(datasource integer) returns box4d

Then the overall function would then just be a thin wrapper around li_datasourcebox and li_transform, using the datasource referential as the source :

li_datasourcebox(datasource integer, config integer, target integer) returns box4d

If time is null, and if capture_start and capture_end are equal for the datasource, then capture_start can be used to get the parameters of dynamic transforms.

I am not sure what is the use case here. If one wants to forge a different box4d than the one of the datasource, then let him get the original box using li_datasourcebox, modify it and then transform it using li_transform.

discussion

Should time be represented as a float or a timestampz ?

• timestampz resolution is 1ms which may seem ok for now.
• timestampz provides an absolute time referential which is convenient (fixed convention) but inflexible (all times should be converted from their intrinsic time referential before use)
• float would be more homogeneous between XYZ and T dimensions
• float provides a relative time referential, which is more flexible but more ambiguous : no need to convert time to an absolute time frame. To be usable, the referential should also qualify to the time dimension Having time referentials similar to xyz referentials is for me the way forward but I understand if we have take a shortcut on the short term.

[elemoine]

li_transform(box box4d, transform integer) returns box4d -- compact version li_transform(box box3d, transform integer, float tmin, float tmax) returns box3d -- developed version`

Why a box 4D? Do we want/need to transform the time dimension as well? If not then I'd rather go with the "developed version". Also more convenient when the transfo is static and you don't need to provide time values.

[mbredif]

I agree that most of the time the time values will just be forwarded from the input to the output box. I however expect time transformations, eg when dealing with datasources that have an internal time that is to be converted (eg : timestamps in a rosbag or a sbet. In ept, the time is expressed in seconds since a provided absolute time)

Also more convenient when the transfo is static and you don't need to provide time values.

On the reverse side, we will always have it when transforming the bbox of a datasource, so checking whether we need to provide it requires an alternative code path...

[elemoine]

Ok, I understand and agree. Let's use a BOX4D. Now we have two options, either we rely on PostGIS' Geoemtry type (LineStringZM) or we create our own BOX4D type.

I think I am in favor of BOX4D. Using LineStringZM would be less convenient for the user, and that would require to link to the liblwgeom library. Any opinion?

[mbredif]

I vote for BOX4D because that will be smoother when we will be at the point of implementing frustums, which have no postgis counterpart. I guess we can provide, for convenience, simple LineStringZM<->BOX4D conversion functions without linking with liblwgeom, as done in pgpointcloud.

[elemoine]

I vote for BOX4D because that will be smoother when we will be at the point of implementing frustums, which have no postgis counterpart. I guess we can provide, for convenience, simple LineStringZM<->BOX4D conversion functions without linking with liblwgeom, as done in pgpointcloud.

Yep, so let's go with LIBOX4D in LI3DS/pointcloud.