Bounds are not cubic in ept.json

[wonder-sk]

The EPT spec says about bounds in ept.json:

An array of 6 numbers of the format [xmin, ymin, zmin, xmax, ymax, zmax] describing the cubic bounds of the octree indexing structure.

Currently bounds and boundsConforming are the same in bu output. Can we decide whether the bounds should be relaxed to allow octree nodes to be rectangular cuboids instead of cubes? Our decoder/renderer in QGIS is making the assumption the nodes are cubes and if that's not the case then loading/unloading of nodes does not correctly fit the view.

[abellgithub]

IMO the EPT specification shouldn't require cubic bounds. I don't see any advantage to requiring it, other than it may (slightly) simplify processing for some consumers, but also may be detrimental in other ways.

[connormanning]

I think we definitely need to bloat things to a cube. I'm seeing very strange results on data like the SNCF dataset, which is approximately 30x larger in XY than in Z. For larger/flatter datasets (e.g. state/country sets) I'd imagine this would only be compounded.

For example, the Iowa full state set is 185x larger in X than in Z. That's approximately 500km wide in X, so a node corresponding to 1km x 1km in X would be only 5 meters tall. As far as the spec goes it's maybe debatable, but for the software - at most I think maybe we should have some special flag that would produce non-cubic data and definitely not be producing it by default.

I don't see any benefit to it being non-cubic either - it just makes your densities vary wildly in each dimension while part of the point of EPT is to give you predictable down-sampled data as you traverse the tree.

Cube

Non-cube

[abellgithub]

Fixed with 0f0081d

[abellgithub]

Fixed in 0f0081d