Migrate TileMesh-related modules to typescript

[Desplandis]

Description

This PR introduces TypeScript migration of the whole tile conversion process. This includes TileMesh, OBB and convertToTile.

Depends on #2556.

[Neptilo]

This PR introduces 3 new TODOs (and removes 1, thanks for that!).
In general, I’d recommend avoiding TODOs in code unless they’re tied to a clear follow-up process (e.g. a linked issue). Otherwise, they often get forgotten and accumulate over time. A good alternative is to either address them before merging, or create an issue and link it directly in the TODO.

I also noticed a question added in a comment in LayerUpdateStrategy. Similar to TODOs, that kind of question is more likely to get answered if raised in chat or as part of an issue.

[Neptilo]

Would a cast be better than a ts-expect-error?
(this.parent as TileMesh).findCommonAncestor(tile.parent as TileMesh)
(The comment is still useful anyway.)

[Desplandis]

Yeah, but I think our linter does not authorize such cast, but I will do it either way (with a @ts-expect-error)

[Neptilo]

The language is quite difficult to understand here. If I understood well, it could be:
"In case of adding a label layer, remove labels that have no chance of being visible.
Even in the best case, labels will never be displayed, for example, if there are many labels."

[Neptilo]

Is this a simplified, POD version of TiledGeometryLayer? If so, we could mention it.

[Desplandis]

Since TiledGeometryLayer is not typed yet, I decided to go for an sub-type for this function.

[Desplandis]

@Neptilo I did all changes following your review. =)

[Neptilo]

@Neptilo I did all changes following your review. =)

Nice!

And what do you think about my previous comment?

This PR introduces 3 new TODOs (and removes 1, thanks for that!). In general, I’d recommend avoiding TODOs in code unless they’re tied to a clear follow-up process (e.g. a linked issue). Otherwise, they often get forgotten and accumulate over time. A good alternative is to either address them before merging, or create an issue and link it directly in the TODO.

Currently I can see two added TODOs in OBB:

• in updateZ: "why not add the geoid height to the min and max parameters? The implementation of GeoidLayer is leaking here."
• in setFromExtent: "The crs are hardcoded here."
• a TODO in disguise ;) : "we should investigate the use of the THREE.OBB class."

[Desplandis]

My bad, I forgot about those comments!

[Desplandis]

@Neptilo

For the updateZ, it will be fixed when we'll have the possibility to combine multiple elevation layers (additive or as a mask). The geoid layers will be considered as elevation layers instead (and removing this implementation leakage). I can add a short notice to explain this.

For setFromExtent, it will surely not be fixed. Unless we use three OBB implementation (but this is my TODO in disguise ;)). I will remove both comments.