Add row to calculate coordinates of additional entity

[Sujanadh]

Description:

This feature introduces functionality to calculate and retrieve the coordinates of an additional entity selected in a survey form.

• Adds a new calculate row that retrieves the coordinates of the selected entity. This is done using an instance reference for the entity and retrieves the geometry field using the following XPath expression:

"calculation": [f"instance('{entity_name}')/root/item[name=${entity_name}]/geometry"]

Issue:

• Unable to view the geometry of additional features in the map in submission detail due to missing coordinates.
• Visualise additional features on submission details page fmtm#1882
• Fixes loading issue of additional entities in odk collect due to unmatch name with additional features uploaded to odk central; removed code that removes trailing 's' letter from the entity name to make it singular.

[spwoodcock]

It's quite nice having the field in code like this.

It's verbose, but we can then use source control.

Do you think we should remove the mandatory fields xls file and build the dataframe here instead?

[Sujanadh]

I think we tried that initially when we were writing this function to append fields. But it looked so messy and complex so we decided to use a file instead, updating the form seemed easier during that time.

[spwoodcock]

Thanks for being my memory 😆

It probably did look messy! But we could clean it up a bit, either using functions or different files to split it up nicely.

I'm leaning more in favour of putting it all in code so it's source controlled and easily visible what we change.

Not high priority to do right now if it's going to take some time. But do you think it's a good idea in the long run? Or we just keep it simple with the file?

[Sujanadh]

I think it's good approach to maintain it in the codebase rather than XLS file. But it still has both merits and demerits.
Appending all mandatory fields using code base will help us to track changes (use source control), it reduces the complexity of maintaining xlsx files, we can also write test cases to ensure dataframe construction and validation.
While for non-developers (project manager) who want to update the mandatory forms, it might be challenging for them. For small datasets, this isn’t an issue, but as the number of mandatory fields grows, managing them directly in the code might become troublesome. @manjitapandey

[spwoodcock]

That's a valid concern for sure, but honestly I can't see anyone modifying the mandatory fields form that isn't a developer 😅

We would have to think up a nice way to manage this without it being too verbose and cumbersome.

I'll merge this PR and we can consider this in the future. Not a high priority right now, as it's a bit of work 👍

[Sujanadh]

okay, I will work on this side by side. We can merge then for now.