Property table array in subtree format

[lilleyse]

Instead of inlining a property table in tileMetadata and contentMetadata there is now a dedicated section for property tables. This is consistent with EXT_structural_metadata and is more future proof if we ever need to support property tables referring to other property tables for metadata inheritance (#641).

Current

Proposed

{ "tileMetadata": { "class": "tile", "count": 85, "properties": { "horizonOcclusionPoint": { "values": 2 }, "countries": { "values": 3, "arrayOffsets": 4, "stringOffsets": 5, "arrayOffsetType": "UINT32", "stringOffsetType": "UINT32" } } }, "contentMetadata": [ { "class": "content", "count": 60, "properties": { "attributionIds": { "values": 6, "arrayOffsets": 7, "arrayOffsetType": "UINT16" }, "minimumHeight": { "values": 8 }, "maximumHeight": { "values": 9 }, "triangleCount": { "values": 10, "min": 520, "max": 31902 } } } ] }

{ "propertyTables": [ { "class": "tile", "count": 85, "properties": { "horizonOcclusionPoint": { "values": 2 }, "countries": { "values": 3, "arrayOffsets": 4, "stringOffsets": 5, "arrayOffsetType": "UINT32", "stringOffsetType": "UINT32" } } }, { "class": "content", "count": 60, "properties": { "attributionIds": { "values": 6, "arrayOffsets": 7, "arrayOffsetType": "UINT16" }, "minimumHeight": { "values": 8 }, "maximumHeight": { "values": 9 }, "triangleCount": { "values": 10, "min": 520, "max": 31902 } } } ], "tileMetadata": 0, "contentMetadata": [1] }

[ptrgags]

While I haven't yet started the implementation, this change looks sensible to me.

[javagl]

I think it's good to align the structure more with that of EXT_structual_metadata.
I'm a bit confused about tileMetadata and contentMetadata, though: They are ... wrappers for an integer. If I had to find a reason for that, could only come up with ~"well, maybe, some day, we want to store other things there, beyond the property table index". But that sounds a bit vague. Is there any specific reason to wrap this index into objects?

[lilleyse]

I'm a bit confused about tileMetadata and contentMetadata, though: They are ... wrappers for an integer. If I had to find a reason for that, could only come up with ~"well, maybe, some day, we want to store other things there, beyond the property table index". But that sounds a bit vague. Is there any specific reason to wrap this index into objects?

Future proofing was the main reason. Maybe there would be other encodings in the future? Metadata inheritance is also in the back of my mind, but now that I think about it those fields would be part of the property table definition. It should be ok to simplify and make them integers instead of wrappers for integers. I'll make the change.

[lilleyse]

@javagl updated

[javagl]

Future proofing was the main reason.

So now it will be my fault if we hit a road block in the future :-) But I don't see any reason now to not merge it.