Coordinates Saved from Null Geopoint Instead of Non-Null Geopoint

573
3
Jump to solution
02-10-2021 01:52 PM
Kasko_Skyler
New Contributor II

I have a survey form with two geopoint questions. The first has bind::esri:fieldType set to null, and the second has the fieldType left blank. When the survey is submitted, I would expect the coordinates saved as the feature's center, e.g. the point that shows up one a web map, to come from the second Geopoint. Instead, when I submit the survey, it always shows up in the web map at the coordinates of the first, null, geopoint.

I have attached a minimal example: an XLSForm with only two questions, null_geopoint and saved_geopoint. As explained above, the feature produced when the survey is submitted appears at the coordinates provided for null_geopoint, rather than at the coordinates provided for saved_geopoint.

I can fix this by switching the order of the questions. So, it appears that the survey is always saving the coordinates of the first geopoint question, rather than the expected behavior of saving the coordinates of the non-null geopoint question. In the actual survey I am working on, through, it is not feasible to switch the order of the questions. Is there a way to get Survey123 to save coordinates of a geopoint question that is not first as its center?

I'm publishing the survey with Survey123 Connect version 3.11.123 and submitting it with the field app version 3.11.164.

Thanks, Sky

 

0 Kudos
1 Solution

Accepted Solutions
Philip-Wilson
Esri Frequent Contributor

Hi @Kasko_Skyler,

The problem is actually the publishing process and the type of feature layer/table that is automatically created by Connect.

When the first geopoint is null, Connect will create a table only, not a layer. This is due to the way the check for the geometry type in the XLSForm is done, it finds the first geopoint/geotrace/geoshape question and checks the type, if it is null it creates a table, if it is not full it creates a point, line or polygon geometry. The second geopoint will be ignored as the check has already occured and been set on the first one.

Therefore when using the field app for this survey, the table you are now submitting the records to, does not have a geometry, and the second geopoint is being ignored. There is currently no way to work around this, except the first geopoint needs to be the one with actual geometry, not the null one.

If you check the Schema tab in Connect you will see the difference between the layers and tabled, depending on order.

Philip-Wilson_0-1613088234035.png

Philip-Wilson_1-1613088316511.png

For now, I would encourage you to submit this issue as a bug via Esri Support. Our Support team will assign an official bug number for your records. This number can be used to search for and subscribe to the bug on the Esri Support site. If the issue is reported by other customers it will be attached to the same bug report, which helps us assess the impact of the issue and prioritize it accordingly.

Regards,

Phil.

View solution in original post

3 Replies
Philip-Wilson
Esri Frequent Contributor

Hi @Kasko_Skyler,

The problem is actually the publishing process and the type of feature layer/table that is automatically created by Connect.

When the first geopoint is null, Connect will create a table only, not a layer. This is due to the way the check for the geometry type in the XLSForm is done, it finds the first geopoint/geotrace/geoshape question and checks the type, if it is null it creates a table, if it is not full it creates a point, line or polygon geometry. The second geopoint will be ignored as the check has already occured and been set on the first one.

Therefore when using the field app for this survey, the table you are now submitting the records to, does not have a geometry, and the second geopoint is being ignored. There is currently no way to work around this, except the first geopoint needs to be the one with actual geometry, not the null one.

If you check the Schema tab in Connect you will see the difference between the layers and tabled, depending on order.

Philip-Wilson_0-1613088234035.png

Philip-Wilson_1-1613088316511.png

For now, I would encourage you to submit this issue as a bug via Esri Support. Our Support team will assign an official bug number for your records. This number can be used to search for and subscribe to the bug on the Esri Support site. If the issue is reported by other customers it will be attached to the same bug report, which helps us assess the impact of the issue and prioritize it accordingly.

Regards,

Phil.

View solution in original post

Philip-Wilson
Esri Frequent Contributor

Hi again @Kasko_Skyler,

Also note that if you are trying to submit via the Survey123 field app (using your test survey example), you should get an error, and the upload of data should not be successful, as there is no geomtry on the table. I see the following when trying to submit in 3.11 or 3.12 beta field app:

Philip-Wilson_2-1613088784061.png

If you are not seeing this error and submissions were successful, just checking are you using the web app to submit?

Regards,

Phil.

0 Kudos
Kasko_Skyler
New Contributor II

Hi @Philip-Wilson,

Thanks for the detailed explanation in your first reply, I will submit a bug report as you suggest.

I did not get that Send Error when testing the full survey I am working on. When I initially created the Geopoint_Test example survey, I did see the Send Error pictured. However, in testing I switched the order of the two questions, republished, and then switched the order back to what it had been originally, and republished again. At that point I no longer saw the Send Error, and the submissions were successful, with a feature created at the coordinates captured by null_geopoint. I am using the field app to submit, not the web app.

Thanks,

Sky