openlayers
Text from a KML/vector layer is not correctly rendered in 3D mode
Text defined in the style of items in a vector layer is not correctly rendered when in 3D mode.
- The text appears much larger compared to the feature images than it was in 2D mode.
- The text appears behind the feature images, so it can only be partially seen (this is critical when the text may just be one or two digits).
Screenshots attached. This is the same map, just enabling the 3d mode.
Text style is handled in src/featureconverter.js, in olcs.FeatureConverter.prototype.olGeometry4326TextPartToCesium.
For having texts above the circles, there is the https://cesiumjs.org/Cesium/Build/Documentation/Label.html?classFilter=label#eyeOffset property in Cesium.
The vectors sample shows the same issue as above (text labels are too big and behind the feature), plus an additional issue, that letter within a piece of text are not vertically aligned (some letters are higher than others).
Regarding the size of the text, there is certainly some adjustement we should do. Regarding alignment, it may be related to https://github.com/AnalyticalGraphicsInc/cesium/issues/3166 Regarding order, maybe we could put an eyeoffset: https://cesiumjs.org/Cesium/Build/Documentation/Billboard.html#eyeOffset.
Indeed, the alignment issue seems to be the one reported in https://github.com/AnalyticalGraphicsInc/cesium/issues/3166.
On the order, as per the documentation, eyeOffset seems to move the billboard in the y axis, but does not seem to change the z order.
As a workaround I was thinking more along the lines of defining the style as two separate styles for the image and the text, hoping that one will be drawn after the other, though I am not sure if that is supported by style functions.
The documentation example is: b.eyeOffset = new Cartesian3(0.0, 8000000.0, 0.0); which moves in the y direction. Having non zero value for z will move in the z direction.
As suggested, adding options.eyeOffset = new Cesium.Cartesian3(0.0, 0.0, -5.0); to olGeometry4326TextPartToCesium solves the issue with the z-order. Though, that -5 seems a bit arbitrary (I have tried smaller values, -1 and -2, and in those cases the text was still behind the polygon). Should I send a PR?
I don't see an easy and general way to handle this. So I would skip the PR for the moment.
Ok, let me know if you have any other ideas or you want me to test anything.