ServiceFeatureTable AddAsync call returns -10 and fails on ApplyEditsAsync

1802
5
09-08-2016 12:48 PM
JeniferCochran
New Contributor II

I have seen other posts where the fix was to add the following during the creation of a FeatureLayer:

myFeatureTable.OutFields = Esri.ArcGISRuntime.Tasks.Query.OutFields.All;

OR

if (_sft.OutFields == null)
{
           _sft.OutFields = new Esri.ArcGISRuntime.Tasks.Query.OutFields();
}
foreach (FieldInfo fi in _sft.Schema.Fields)
{
        _sft.OutFields.Add(fi.Name);
}

I have tried both suggestions but still result in a failure.

Some of the exceptions include:

  • Response status code does not indicate success: 500 (Server Error). (On ApplyEditsAsync)
  • The shape must not have a Z value. (On AddAsync)

  1. We tried multiple attempts to save a MapPoint to the ServiceFeatureTable but the most bizarre case was the following attempt:

Our table consists of a PointZ Shape type.  We tried to save a MapPoint that was constructed = new MapPoint(2, 3, 0, SpatialReferences.Wgs84).  Then when trying to AddAsync it would fail with the following exception:

Exception:

The shape must not have a Z value. :

StackTrace:
at RuntimeCoreNet.Interop.HandleException(Boolean retVal) at RuntimeCoreNet.CoreFeatureSource.InsertRow(Byte[] attributeBytes, UInt32 byteCount, UInt32 attributeCount, ICoreGeometry geometry) at Esri.ArcGISRuntime.Data.FeatureTable.Add(Feature feature) at Esri.ArcGISRuntime.Data.FeatureTable.<>c__DisplayClassb.b__a() at System.Threading.Tasks.Task`1.InnerInvoke() at System.Threading.Tasks.Task.Execute()

Which doesn't make sense since the schema says PointZ type. 

Here is my code:

///currSFT is the ServiceFeatureTable object

try
{
    var recNo = Task.Run(() => currSFT.AddAsync(feature)).Result;
    var updateResult = Task.Run(() => currSFT.ApplyEditsAsync()).Result;
}
catch (Exception ex)
{
    //was unable to save
}

2.    So on a second attempt we tried the following MapPoint: new MapPoint(3, 4, double.NaN, SpatialReferences.Wgs84);
When we try to AddAsync this MapPoint, AddAsync returns a row ID of -10.  Then it will throw when calling ApplyEditsAsync with an exception stating Response status code does not indicate success: 500 (Server Error).

Why would this occur? I did notice when creating the MapPoint it behaves differently depending which constructor I would use.  I am wondering if there is documentation on why runtime would treat an object differently depending on which constructor is used?  As well as how to save my MapPoint to the table via the ServiceFeatureTable.

Thank you for your help!

0 Kudos
5 Replies
AnttiKajanus1
Occasional Contributor III

Hi Jenifer,


There are known issues with this in 10.2.6 and 10.2.7. Basically it's not possible to store geometries with Z values through ServiceFeatureTable directly. You should be able to store features without Z like is defined in a workaround in 10.2.6 doc. If you need to add Z values at the moment, you need to use /applyEdits endpoint directly described in dicussion about M values which also relates to Z values.

We are sorry for the inconvenience and we are looking forward to support this in next major release.

JeniferCochran
New Contributor II

When is the next major release scheduled for Runtime .net? Or are you talking about the Quartz release?

0 Kudos
AnttiKajanus1
Occasional Contributor III

Yes, I was talking about Quartz and it's scheduled to be out quite soon. I cannot give exact date but 'upcoming months'.

0 Kudos
JeniferCochran
New Contributor II

What about a patch for Runtime .Net? Is that in the future?

0 Kudos
JeniferCochran1
New Contributor II

I attempted the workaround but there seems to be a problem.

First there are times in which we do not have a z value for the mappoint therefore we used double.NaN (the default value of a pointz) and it had the same problem.  Then we tried to use a special value so that we recognize that it has not been instantiated yet, we chose double.MinValue.  Then when we used graphic.ToJson() it was in scientific notation which is also not accepted in a RestQuery.  This is a major problem especially if we have small elevation values like 0.0000000000001.  Is there a work around for this issue?

Thank you

0 Kudos