Skip geometry question if new feature is passed

[Sujanadh]

Is your feature request related to a problem? Please describe.
Even if the user creates new feature geometry, the question to select geometry is still there.

Describe the solution you'd like
Whenever the user creates new geometry, the question to select geometry should be skipped. Saying that the logic will be cyclic to each other. Since we hide new feature if geometry is selected, likewise, we need to hide geometry question if a new feature is drawn.

Describe alternatives you've considered
The solution i am thinking of is to remove new_feature field and use geometry for both existing and new feature (which supports our workflow of fmtm; loading odk after selecting feature or creating new feature but might not work when odk collect is used directly)

[spwoodcock]

This is a nice idea!

If we remove the drawing of new features from ODK entirely (its now drawn in FMTM and injected in), then perhaps this is possible.

The problem I see if that the geometry field is not actually a geopoint / geoshape, but is a select_one field, where we are selecting an existing entity. I wonder where the geometry would be added for the new entity creation then.

Definitely worth an experiment though!

(another option I just thought of is we could create two separate forms, one for existing feature collection, another for new feature collection)

[Sujanadh]

The idea I am thinking of is creating a new entity after drawing geometry in the mapper frontend; then we can easily do that in a single field with a single xls form. Whenever a user saves new geometry, we will create a new entity. Furthermore, we are now integrating webhooks; we will probably remove table geometry records as well.

[spwoodcock]

The idea I am thinking of is creating a new entity after drawing geometry in the mapper frontend; then we can easily do that in a single field with a single xls form. Whenever a user saves new geometry, we will create a new entity. Furthermore, we are now integrating webhooks; we will probably remove table geometry records as well.

Ah OK, good point!

So we avoid entity creation via the form entirely, leaving that to FMTM via an API call.

Then the form is purely for selecting existing entities.

That should work well. My old concern is that it relies entirely on FMTM then, and there is no fallback to simply using ODK Collect entirely (say there are issues with FMTM). But I think this could be an acceptable compromise, as the ODK Collect could still be used to map existing geoms just not new geoms.

[spwoodcock]

I think we should give this approach as shot for the best user experience 👍

[Sujanadh]

They still can use odk collect entirely if they want to draw features in odk collect then we can create xls form likewise what we are doing till now. If they want to use fmtm then we allow them to create geometry in the mapper frontend and then create an entity, which will be passed to geometry, so no new feature question will be asked. If not, that means they are using odk collect without relying on fmtm where they will get a question of drawing geometry. We check if a new feature is drawn, then we use create if logic to create a new entity from odk collect as well.

[spwoodcock]

Yep sounds ideal 👍

I was only suggesting the fallback to ODK Collect for a scenario like this:

• We create a project with an XLSForm that expects 'selection' of a geometry (i.e. entity upload from FMTM previously).
• The user goes to the field.
• The internet connection is bad in one task area, so they fall back to simply using ODK Collect.
• They want to map a new geometry in ODK Collect only, so want to draw a geopoint via question.

This isn't a huge concern though. In the long run, with better caching and full offline FMTM support then the problem of patchy internet would be solved hopefully 🤞

[spwoodcock]

As part of this fix to the XLSForm code, we should probably address #2105 too 👍

[spwoodcock]

Also note for this:

• We still need a way to identify that a feature is a 'new' geometry vs an 'existing' geometry.
• Perhaps we still keep a simple boolean yes/no field here for new_geometry, that defaults to 'no', but is set to 'yes' via URL intent when opening ODK for a new geometry.

[rsavoye]

I used to just check the location field from the XLSForm to tell the difference between an existing buildings and a new building. A new building was also a POI, which I then merged during the final conflation step.

[spwoodcock]

I used to just check the location field from the XLSForm to tell the difference between an existing buildings and a new building. A new building was also a POI, which I then merged during the final conflation step.

Sure that's a good point - we can identify this in a conflation workflow afterwards, comparing the source data to the final output data 👍 🙏

New buildings can be points or polygons in the latest FMTM though