WIP: Tile3D getCoordinatesByIndex

[radoslavirha]

Hi,

regarding to my previous discussion #2425 (comment) I prepared something which I can improve with your guidance.

My final target is to create cursor similar to this.

On meshes it should be simple, maybe another method can return orientation of mesh under cursor + cursor coords and I can render oriented circle under cursor.

On point clouds it's more difficult I think, so I started with picking multiple points around cursor and I want to create plane from those (3?) points, calculate orientation,... So this is the use case where it's useful for me. But it could be usable generally too.

Thanks

[ibgreen]

Thanks for putting this together, and apologies that it did not receive a timely review.

The use case is valid, but I don't think this implementation can be merged as written:

• attributes.positions contains tile-local positions. They need to be transformed through the content's cartographicModelMatrix or cartesianModelMatrix before conversion to WGS84. Passing the raw values directly to addMetersToLngLat gives incorrect results for transformed tiles, RTC_CENTER, recentered content, and quantized data.
• Quantized point clouds normally expose positions as an accessor object ({value, size, normalized, ...}), so indexing attributes.positions directly produces undefined/NaN coordinates.
• Invalid, fractional, and out-of-range indices are not validated.
• A public API addition would also need TSDoc, documentation, and coverage for ordinary, transformed, RTC-centered, and quantized point clouds.

The branch is now several years behind master, has conflicts, and the Tile3D implementation has moved. Given that, I'm closing this PR rather than asking for a substantial rebase and redesign.

If this capability is revisited, a fresh PR should probably start with a generic helper that transforms a supplied tile-local position to Cartesian or cartographic coordinates, with an optional point-cloud-specific indexed accessor layered on top. For exact WGS84 output, applying cartesianModelMatrix and then Ellipsoid.WGS84.cartesianToCartographic would be a more robust path.