Send error: Polygon input not valid

[JasonJordan00]

I have a survey using geoshape however we are getting an error if we try to collect a new record. 

"24305: The polygon input is not valid because the ring does not have enough distinct points. Each ring much contain at least three distinct points."

The polygons we are drawing *definitely* have more than 3 points. We have many records preloaded into the feature service and most of the work is done using the inbox. Updating those records has been no issue in the field.

Other surveys using polygons have worked without a problem. Any ideas? Thanks!

[JamesTedrick]

Hi Jason,

Apologies for the delay.  Without seeing the polygon, it's difficult to be able to see what the problem might be.  One thing that may cause an issue is if the polygon self-crosses - Survey123 does not support complex polygons.

[JasonJordan00]

I've attached a screenshot of a typical polygon we've tried to input. I've tried all manner of shapes, and none seem to work. 

[KrishV]

Hi Jason,

Even, I have the same issue. I'm getting this error when trying to submit survey using survey123 mobile app (I'm using Android). But, when I submit the survey from web app, survey is getting submitted without any errro.

Are you able to fix.

Thanks,

Krish

[JenniferLidgett]

Hi

I am having the same issue as well.   It was working initially and in the last few weeks it has stopped working on all 3 survey's that use this feature.  What causes this issue?  All polygons contain at least 4 points and don't cross over. 

FYI - I am using Survey123 Version 3.9.149 on an Android Samsung Tab A.  I am also having the same issue using the Survey123 app on my desktop.

[JimmyKnowles]

Has anyone found a resolution for this? I'm using 3.9.149 on iOS and Windows 10 and am seeing the same behavior. The app (iOS and W10) returns the error for a very simple polygon, but the web version works fine. 

Here's the geometry of the polygon that I'm trying to submit with this survey submission.

"geometry": {
  "rings": [
    [
      [
        -117.19983194520817,
        34.062409431377134,
        0
      ],
      [
        -117.19395254305022,
        34.05785861838573,
        0
      ],
      [
        -117.20124815156996,
        34.05291644316269,
        0
      ]
    ]
  ],
  "spatialReference": {
    "wkid": 4326
  }
}‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

It appears that the polygon isn't being closed. The first and last vertices are not the same. I looked through the log and didn't see anything else that raised a red flag.

Method is set to vertex. In another survey that works, method is set to sketch.

The spatial reference of the basemap used in S123 is different than that of the feature service that it's writing to (102100)

Any ideas?

[JimmyKnowles]

James Tedrick‌ - this appears to be a bug. Should I go through support channels to submit bug report?

[JamesTedrick]

Hi Jimmy,

Is the geometry you are presenting taken from the applyEdits call or just from the logging of the feature prior to submittal?  The internal representation inside Survey123 should auto-close and append a copy of the first vertex as the last vertex.  In a basic test, I'm able to submit a 3 vertex polygon.  Could I ask you to please file an issue with Esri Support to work out what the issue may be?

[JimmyKnowles]

James - thanks for getting back to me. This is after the applyEdits call. The error seems to be thrown due to the response it gets from AGOL. The only difference between my successful test (and I imagine your successful test) and the survey that gives an error is that we're trying to use an existing feature service. Based on the OP's description, he is also using an existing feature service.

Update: using Fiddler, I can confirm S123 is not closing the polygon, The applyEdits call that is sent to AGOL has an unclosed polygon.

We can open up a support ticket, but this appears to be a bug with using method=vertex for creating new polygons on surveys that hit an existing feature service.

[JasonJordan00]

Jimmy, I can confirm that's the behavior I'm seeing on my end too. Definitely a bug using that method on existing services.