Separate out primary mapping geometry from new feature geometry (user select during proj create)

[spwoodcock]

What type of PR is this? (check all applicable)

• 🍕 Feature
• 🐛 Bug Fix
• 📝 Documentation
• 🧑‍💻 Refactor
• ✅ Test
• 🤖 Build or CI
• ❓ Other (please specify)

Related Issue

• Fixes Points as map features are not visible on project details page #2164
• Fixes Replace hardcoded new_geom_type with user configuration #2220

Describe this PR

New Geoms vs Existing (Primary) Geoms

• Went down a rabbit hole due to needing to display point geoms.
• It was clear we needed to update project creation config: primary geoms to map are separate from new geoms to map, e.g.
  • Map polygons, where new geoms drawn are points
  • A entirely point based mapping workflow
  • Any other combination of point, polygon, linestring!
• I updated the db / migrations and models, then added extra options to the frontend during project creation.

Custom XLSForm Is Redundant

I also added a modification to the custom XLSForm upload.

Instead of having:

1. Category selection
2. Optional custom XLSForm upload

I refactored to have:

1. The XLSForm must always be uploaded.
2. Category selection was removed, including from osm-fieldwork code that used it in the form.
3. The form can either be custom, or downloaded from a list of options (and optionally modified before upload).

Normalise geometry type during project creation

• If the user uploads a polygon project, but specifies they want to map with points, we calculate the centroids for them to map with automatically.
• TODO in a future PR: If the user uploads mixed geometry type data upload, but specifies they are mapping lines, we strip out the polygons and points automatically (perhaps we revisit this behaviour, but it will do for now)

Remaining Tidy Up

@NSUWAL123 if you wouldn't mind helping finalise this tomorrow, it would help a lot 🙏
Once merged I think we can test thoroughly, then push through to prod as new release for Tokha.

• Fix text highlighting on left for Upload Survey and Map Data tabs (sorry I messed this up a bit in a rush)
• Spacing issues - large gaps between elements on both Upload Survey and Map Data tabs.
• Upload Survey tab: if validation logic is triggered that form is not attached, then a form is uploaded afterwards, the validation message does not disappear.
• Map Data tab: conflict between two radio geometry selections - clicking label of new geometry type changes the selection for the primary geometry type? Is this linked to how the CustomCheckbox works, or did I miss something?

Screenshots

Moved form upload to top, with optional form download and modification below:

User can download an existing form and modify, before upload (or modify in-browser):

More options on the 'Map Data' tab:

Selecting different geom types for 'main' geoms and 'new' geoms (draw toolbar):

Mapper frontend with correct geom types

Review Guide

• Hopefully no changes are needed in the db for Tokha, as the default was originally polygon geoms + point new geoms.
• New projects created should be manually selected as polygon type, with point new geoms if needed.
• If both polygon existing and new geoms are needed, then the default is to match new geoms to the primary geom type.

Checklist before requesting a review

• 📖 Read the FMTM Contributing Guide: https://github.com/hotosm/fmtm/blob/main/CONTRIBUTING.md
• 📖 Read the HOT Code of Conduct: https://docs.hotosm.org/code-of-conduct
• 👷‍♀️ Create small PRs. In most cases, this will be possible.
• ✅ Provide tests for your changes.
• 📝 Use descriptive commit messages.
• 📗 Update any related documentation and include any relevant screenshots.

[optional] What gif best describes this PR or how it makes you feel?

[NSUWAL123]

Sure, I'll have a look on these stuffs

[NSUWAL123]

@spwoodcock, The confirmation popup is in the middle of the screen. Is that expected or should it be placed at the top?

[spwoodcock]

@spwoodcock, The confirmation popup is in the middle of the screen. Is that expected or should it be placed at the top?

Yeah I put it there purposefully, as it seemed a bit hidden at the top (I didn't notice it immediately).

It could block the screen until the user clicks an option (grey our the background temporarily)