At version 4.34, using projectOperator on geometries with z values fixes all its z values to 0!
Anyone has a workaround for this ?
Hi @ChristopheSuter ,
Do both spatial references have the same vertical coordinate system and only differ in their horizontal coordinate system? There is a known limitation where vertical coordinate system projections are not currently supported. This should be better documented when version 5.0 comes out next week.
Hi Sage,
No, both spatialReferences have same vcsWkids equal to null, but thanks for the upcoming info
@ChristopheSuter can you provide a repro sample?
Yes but it does not help, since it works correctly: https://codepen.io/christophesuter/pen/WbxVEvq since creating the geometry from its json solves it. Difficult for us to see why it works with a new instance of the geometry
I have adapted my projection method like this .. but it is still a workaround i think
@ChristopheSutergotcha. How are your non-new instance geometries being created when they have the z-problem?
If converting them to JSON is correcting the problem then it's possible there is some sort of issue with the non-JSON geometry instances. If you continue to have issues, or run into convert/revert performance issues, then I'd encourage you to open a support ticket so we can take a deeper look.
Found some strange way to correct the problem, maybe it can help. I am using a polylineGeometry returned by the sketchViewModel with :
in a 2d mapview. Then i use this geometry (that is in EPSG:2056, and has all of its z values to 0 that seems logic) to query elevation on Esri's elevation service (that is in EPSG:3857), so i use the projectOperator to reproject my geometry and then query Elevation on esri's elevationLayer. Everything ok, elevation z fixed and x/y in EPSG:3857.
Then I have to reconvert it to EPSG:2056 -> sets all the z to 0.
So I modified the sketchViewModel property (removed hasZ):