QField Feature Requests

Is it possible to add audible alarms for Geofencing breaches? Currently just has a visual indicator some alarms would be nice for noisy machinery.

This relates to the already-existing request titled "Ability to create new projects within QField app". As good as QField is, it often feels very restrictive compared to typical professional surveying data collector software. The notion of having to "go back to the office" in order to begin new work or to organize data feels very outdated. Being able to create new projects while in the field would be wonderful, but a large portion of the benefit might be achieved with a perhaps simpler enhancement: the ability to create new layers within an existing project. It is often possible to anticipate the need for a new project and thus be able to create it while in the office. However, it's also often the case that once in the field and performing the work, something is observed that had not been anticipated, but for which data ought to be collected, and that does not properly belong in any of the project's already-existing layers. There might be a logical distinction of these new data from the other categories of data that were planned to be collected. It could be very nice to be able to separately control the visibility of this new category of data, even just for ordinary reduction of clutter on the screen. It could also be that there was a problem with some of the data collection, in any layer, e.g. perhaps a GNSS receiver had been misconfigured, and the problem is discovered while still in the field. So far, I have not found a convenient way in QField to delete a large number of features within a layer (have I missed it?), so a work-around would be to turn off the visibility of the "bad" layer and to create a new layer. Back at the office, the "bad" layer could be deleted. Perhaps the ability to create new layers could be an intermediate step toward the ability to create new projects. It would be very beneficial in the meantime. Maybe an even simpler way to achieve much of the benefit would be to have the ability to duplicate an existing layer, asking the user 1) for a name for the duplicate and 2) whether or not the features in the original layer should be copied into the duplicate. I'm suggesting #2 as a safer alternative to having the ability to delete all the features in a layer (e.g. after duplication, with all the features of the original layer having been automatically copied into the duplicate), so as to avoid accidental deletion of needed data.

As a user I would find it very useful to be able to deactivate the pie menu that opens when clicking on my active location. This would allow easy selection of features underneath without having to do an extra click with the centre button that was added as a fix.

First of all, thank you to the QField team for the incredible work. QField + QFieldCloud is an extremely powerful tool, and it has significantly improved how we handle field data collection and synchronization workflows. I’d like to share some feedback based on real-world usage with field teams, specifically regarding the synchronization interface (Synchronize / Push changes / Revert local changes). ### Context One of the biggest challenges we face is not technical — it’s usability in the field. Operators often struggle to understand the difference between: * Synchronize * Push changes * Revert local changes These actions are critical and potentially destructive, yet they are presented at the same level in the UI. This creates a high risk of accidental data loss, especially for non-technical users working under field conditions (limited connectivity, time pressure, fatigue). ### Key Suggestions #### 1. Reduce exposure of destructive actions “Revert local changes” is a highly destructive operation, but it is visually presented alongside routine actions. Recommendation: * Move it into a “Danger zone” or “More actions” section * Rename to something clearer like: “Discard unsynced local edits” This would better communicate the real impact of the action. --- #### 2. Introduce a single primary action Most users don’t need to choose between multiple sync strategies. Recommendation: * Provide a single primary button like: “Sync now” * Internally handle: * Upload of local changes * Download of remote updates Advanced options (like “push only”) could remain available but hidden under an “Advanced” section. --- #### 3. Show a clear summary before actions Users should understand what will happen before they click anything. Example: * Local changes: 1 edited feature * Remote updates: 2 features available * Conflicts: none detected This would dramatically reduce confusion and increase confidence. --- #### 4. Improve confirmation dialogs for destructive actions Instead of generic confirmations, provide contextual warnings. Example: “You are about to permanently delete: * 1 edited feature * 2 photos These changes have not been uploaded to QFieldCloud.” This makes the consequence explicit. --- #### 5. Add basic recovery mechanisms Currently, reverting local changes is irreversible. Even a minimal safeguard would help: * Local snapshot before discard * Temporary undo * Local edit history This would significantly increase trust in the system. --- #### 6. Improve terminology Some labels are technically correct but not intuitive for field users. Suggested improvements: * “Synchronize” → “Sync (upload & download)” * “Push changes” → “Upload local edits only” * “Revert local changes” → “Discard unsynced edits” --- #### 7. Improve visual hierarchy Group actions by risk level: Primary * Sync now Advanced * Upload local edits only Danger zone * Discard unsynced edits --- ### Final Thought The current system is technically solid, but the UI assumes a level of understanding that many field users simply don’t have. In practice, the main issue is not how synchronization works — it’s how clearly the consequences of each action are communicated. Improving this flow would greatly reduce training overhead, prevent data loss, and make QField even more robust for real-world field operations. Thanks again for the amazing work and for maintaining such a valuable open-source project.

When using COGO tools there should be a parameter for relative elevation, so that there is a distinction between a null value and a zero-relative value; with the option to show relative elevation of the live location or any selected point. This is also known as azimuth and over a few miles distance can result in a significant amount of error in measurement if not considered. There should also be a relative bearing from a basis of line between two points, as "true north" is error-prone in a survey. When COGO callouts are legal descriptions referring to benchmarks on some rocks at mountain peaks referenced by telescopes in the 1800's, and all you know is what was claimed to be a basis of bearing between two control points that you do find monuments for; to verify that these are sensible you can shoot points for those benchmarks and calculate if the callouts make sense or have been disturbed/offset. In USA the Public Land Survey System uses, varying by state law, easting and northing with a basis of bearing referenced to well known benchmarks and less commonly anything to do with true north or magnetic north. Disclaimer: I am not a professional surveyor my use case is to plan a farm and ranch for myself; over a distance of a few miles being off by a foot or two is only reliable if it is repeatable and QField / QGIS are missing the ability to do callouts reliably.

It's strange that the Circles Intersection COGO tools variant does not allow to create both A and B points in one action. There are uses for plotting a line at the intersection of two circles between the two points of intersection.

Is it possible to make the QField layout even more flexible so that you can choose whether you want the hamburger menu on the left or right side or make the menu movable so you can move it to the desired place? (The majority of the population is right-handed (appr. 90 %) and our field workers would prefer having the main menu to the right.)

QGis snapping configuration is applied to the active layer. In this way, if we want to set different configurations (in that case : overlap) to different layers, it is not possible. In our case : a land use layer (we don't want any overlap) a polygon observation layer (we want to allow overlap) A good way of solving it would be to add a toggle for overlap on the digitalisation settings, exactly like it is done for the snapping (cf. the picture linked). This solutions was proposed by nirvn here : https://github.com/opengisch/QField/issues/6410

It would be nice if you could set filters directly in QField. At the moment, we have always set filters when creating the project, but you can't change them afterwards, except on the PC. It would also be enough if you could show and hide filters. For the sake of clarity, we have filtered our data so that only the current date is shown. If we could change or turn off this filter, we could see the data from previous days without losing track because there is too much data in the project at the same time.

As a Plugin developer, I want to use volume key inputs so that I can create even more tools that make working with QField easier and more efficient, e.g., triggering plugin automations via Bluetooth remotes. Maybe something like a new setting, "Allow Plugins to capture Volume Key Inputs," which can only be enabled if "Use Volume Keys to Digitize" is disabled?