Fairmat 2024: base classes to describe computational geometry

[lukaspie]

Here we propose a refactoring version of the contributed classes NXcg_* for promotion to base classes. The proposal is related to #1531 (with associated PR #1532) that revisits the already existent classes for computational geometry in NeXus.

The main motivation to go beyond the existent was to offer richer descriptive capabilities combined with a layered approach with fields for typical primitives that allow also non-CG-specialists to work with CG in NeXus. There are the following discussion points:

• Is Revisiting non-FAIRmat constructive solid geometry in light of FAIRmat proposal  #1532 ready for consensus and vote
• Is there feedback to the content of this PR

The PR currently has, like most from FAIRmat many files changed because of interdependencies with changes
that affected also non-CG classes. To guide towards a focused review, I recommend to review first of all
all NXcg_* classes in this PR. Another reason for many files changes is that I decided to follow your
suggestions to solve the conflicting use of the postfix "_set" for the base classes that should not be used
as it is a NeXus reserved suffix.

The design of these NXcg_* classes gradually builds up complexity:
NXcg_primitive is the base class
from which all most other NXcg_* classes inherit,
the primitive base class takes care of recurrent fields and concepts.

In what follows, the proposal builds from point cloud to line set, to polygon sets.
NXcg_alpha_complex adds a specific class for more modern CG objects that are useful in practice for
wrapping or representing objects complementing NXcg_polyhedron.

NXcg_polyhedron shares similarities with NXoff_geometry but offers fields beyond
the conventions and constraints of the outdated OFF file format.

OFF is only one of nowadays several formats from the CG community that are used for storing
CG data ready with a formatting ready to become displayed. Modern developments like GPU rendering
are in practice nowadays, though. The most prominent example is the gltf2 standards, VTK or HDFVTK. All these (except for a few special cases in the large VTK standard) have specific but differently formatted representations of primitive data than provided by NXoff_geometry. Given that gltf is a established industry standard in the relevant community we do not wish to compete against
them but wish to offer a standardized representation how users of NeXus can store CG primitive data alongside/in
their NeXus/HDF5 files in concepts serialized such that mapping on either alternative format is facilitated.

Having powerful CG classes in NeXus allows for combining instance data with, if #1531 were
accepted, not only meshed but also CSG which in combination.

For atom probe tomography we have tested the use of NXcg_* classes for representing not only point cloud but
also polyhedron, and alpha complex instance data with model sizes between single objects and scaling out to
hundred thousands of objects which worked even for the most involved scenarios in that community.

In electron microscopy, typically the simpler because 2D cases of NXcg_* can be used.

In electron tomography, the resulting meshes are not more complex than those in atom probe (convex and concave sections and eventually meshes with holes to deal) with therefore from our experience within FAIRmat we are happy with what is proposed here.

[PeterC-DLS]

Some of the deleted files should not be in this PR

[PeterC-DLS]

I've gone through about half of the new base classes

[mkuehbach]

@PeterC-DLS thank you very much for going through these and the great comments, I addressed them,
@lukaspie @sanbrock Sandor, from my perspective this #1421 and #1532 seem converged enough in consensus to point the crowd to these for moving forward in one of the next telcos

[PeterC-DLS]

Suggested change

	Area is a an alias for the two-dimensional case.
	Area is an alias for the two-dimensional case.

[PeterC-DLS]

Suggested change

	If not possible, an identifier for a paper, tech report, or free-text description
	If not possible, an identifier for a paper, technical report, or free-text description

[PeterC-DLS]

Suggested change

	Length of the semi-axes if ellipsoids have individually different length.
	Length of the semi-axes if ellipsoids have individually different lengths.