Why Z = NaN is changed to 0 and new feature is created?
Please see below test code screenshot. Two questions:
1. Why Z value is changed from NaN to 0 after feature is added to table? In our business workflow, when the Z value is NULL in database, we present it as NaN in code, which means that the elevation data is missing. If the Z value is 0 in database, we preserve it in code and consider the elevation is at sea level. This also follows OGC standard, which allows NaN. In ArcGIS Maps SDK, it also allows NaN when create the MapPoint. However, after the feature is added to table, NaN becomes 0. This is causing confusion, because in our survey data, some records do miss Z values, while some records do have Z = 0, and now they are mixed together and difficult to distinguish.
2. Why it needs to create a new feature after added? This make the source data not the same as the final data and there are two sets of data stored in the memory, doesn't it slow down the performance and increase memory consumption?
I think you might not review my code in detail.
When I used public MapPoint(double x, double y, double z, SpatialReference? spatialReference) and use that MapPoint to create the feature, it preserves Z = NaN. The problem is, after the feature is added to collection table, it returns a new instance and it's geometry now has Z = 0. FYI, both the created and added features have HasZ = true. See below debug output.
ESRI does not follow OGC standard, I get it. However, it should not automatically change NaN to 0 for whatever unknown reason. If the final data must have Z = 0 in collection table, then the initial creation of MapPoint or Feature should throw error and not allow Z = NaN.
So, when the collection table must be Z-enabled, and must input a NaN Z value, which overload I should use to create a MapPoint to prevent the collection table from changing NaN to 0? Based on what I see here, it is not the MapPoint or CreateFeature problem, so I don't see any overload can work.
