QField Feature Requests

Search bar allow to make calculations and keep the result to paste it elsewhere. This functionality isn't available anymore when a subform is open, or a form in fullview mode. It would be glad to be able to make those kind of calculations inside numeric fields for example.

As a QField user, it would be very convenient, especially for field work, to be able, when digitizing layers, to enable freehand drawing without specific devices (active pencils and mice), but also allowing capacitive pencils and the same finger. It is at the discretion of the rest of the community and the developers to determine the most convenient way. I personally think that the best thing would be to make the most of the existing infrastructure and merely modify the Freehand Draw button in the Digitization mode, adding a small gear to its icon, so that, when you hold it down, it presents your options: a box that unlocks the drawing by hand and a slider that allows you to choose the sensitivity for tracing lines and polygons when tracing across the screen (fewer milliseconds = more vertices, smoother strokes). The latter is somewhat similar to what was requested at https://ideas.qfield.org/app-feature-requests/p/add-option-to-smooth-lines-digitised-using-the-freehand-option . It may not be a bad option to express sensitivity in the selected measurement unit or in pixels either, but saying that is easier than doing it. Dragging one finger adds vertices due to sensitivity (except in points, leaving only the last position), dragging with two fingers moves the map, pinching with two fingers adjusts the zoom. As with the rest of the scans, it would not be confirmed until the green tick button was activated, the option to undo the last vertex and the rest of the options is maintained.

As a user (fieldworker), I want to be able to turn on the option to smooth the line I have drawn using the freehand option, so that it looks better on maps to be shared with others. When using the freehand digitisation option, I often find that the result is too erratic, possibly due to an oversensitive implementation. I regularly unintentionally digitise a tiny line going in the opposite direction to the rest of the line when lifting my stylus off of the touchscreen. When zoomed out enough it isn't noticeable, but if symbology is used to add an arrow to the end of the line then this ends up facing the wrong way than what was intended (see attached screenshots showing the same line, one is zoomed in closer). I can use the 'minus' button to remove points until the unintended section is removed, but this is time consuming due to the number of points added when using freehand digitisation. Could you add an option to smooth the freehand input (perhaps by selecting the resolution of points in freehand lines, i.e. the distance between points), or an option to apply a smoothing process to lines within a layer?

As a forester working with QField, I want to enter feature attributes and perform common actions using speech input, so that I can work faster in the field.

Not sure if this is a future goal, but could QField eventually integrate and RTK engine for some known receivers? Like Surpad?

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.

The QFieldCloud Sign In dialog opens behind the active project window. It should open on top of the active project window. (Win 10)

We are working with naturalists on the field pointing species. For each observation, they have to select an name through thousands of species. The Reference value widget works perfectly well but it is still time consumming, especially when they often search for the same species. This could be faced with an hybrid of the unique value and the reference value widget. We thought about two options : A dropdown with unique value (P1) The unique values listed before anything is typed (P2) On both cases, once something is typed the widget behaves as the reference relation (P3). This can look like a strange workaround, but that would really save a lot of time for us on the field. The hybrid widget might not be the best solution, if something better is found we'd love it too!

Currently, QField's NTRIP client requires an external Bluetooth-connected GNSS receiver to apply RTK/RTCM corrections — the correction stream is forwarded to the external device, which performs the PVT (Position, Velocity, Time) computation internally, and QField simply consumes the resulting NMEA output. This issue proposes evaluating the feasibility of a complementary, lower-precision pathway: applying differential (DGPS-style) corrections in software to the internal GNSS chipset's raw measurements, without requiring external hardware. This would not replace RTK workflows, but would provide a meaningful accuracy improvement (~5m → ~1-3m) for use cases where a geodetic-grade receiver isn't available or practical. Motivation Android has exposed raw GNSS measurements (pseudorange, Doppler, and in supported chipsets, carrier phase) via the GnssMeasurement API since Android 7.0 (Nougat). This enables applications to implement their own PVT solvers instead of relying solely on the OS-provided fused/black-box location fix. Field-tested comparisons (same device, same route, internal GNSS only) show a noticeable accuracy improvement when NTRIP corrections are applied to the internal chipset's raw measurements versus standalone GNSS. This has been documented academically as well — e.g. PPP/DGPS solutions computed from smartphone raw measurements achieving significantly better results than the phone's internal fused solution (Satellite Navigation, Springer, 2021). OruxMaps appears to implement (or at minimum enable, via its NTRIP + raw measurement logging support) this kind of software-side correction path, and its own users report visibly tighter tracks when NTRIP is active — even with no external antenna connected. This is consistent with published research using OruxMaps as a raw-measurement logging tool for DGPS/PPP evaluation on Android devices. Why this matters for QField specifically QField's current architecture treats GNSS positioning as fully delegated to either: The OS-provided fused internal location (no correction applied), or An external NMEA-outputting receiver (which performs its own corrected PVT) There is no intermediate tier. For field users without access to (or budget for) an RTK-capable external receiver, this leaves standalone ~5m accuracy as the only internal option — even though the underlying Android hardware may support raw measurements capable of a meaningfully better fix via code-based (DGPS) corrections. This would be particularly valuable for: Reconnaissance / preliminary field surveys where cm-level accuracy isn't required but sub-5m matters Users without access to RTK hardware NGOs, students, and low-budget mapping projects using QField in the field Proposed scope (for discussion, not a finished spec) Investigate feasibility of consuming GnssMeasurement raw data (pseudorange/Doppler) on devices/chipsets that support it Apply code-based (DGPS/RTCM 1004/1005 style) corrections from the existing NTRIP client to compute a corrected position independently of the internal fused provider Explicitly not attempting carrier-phase RTK fix/float resolution in software — this is understood to be unreliable on most smartphone chipsets due to duty-cycling and antenna quality, and would misrepresent achievable accuracy Surface this clearly in the UI as a distinct "DGPS (internal, code-based)" positioning source, separate from RTK Fixed/Float, so users are not misled about achievable precision This would be opt-in and clearly documented as not a substitute for RTK — accuracy expectations should be explicitly bounded (~1-3m, not cm-level) Known limitations to flag upfront Duty-cycling on most Android chipsets interrupts continuous raw measurement collection unless "Force Full GNSS Measurements" is enabled in Developer Options — any implementation would depend on this OS-level setting Internal phone antennas introduce significantly more multipath/noise than geodetic antennas, so carrier-phase-based fixes are not a realistic goal Chipset support for raw measurements (especially carrier phase) varies significantly across Android devices and is effectively unsupported on iOS This would add complexity to the positioning stack and should be carefully scoped to avoid conflicting with the existing, well-tested external-receiver RTK workflow Questions for maintainers/community Is there interest in a lower-precision, internal-only correction tier, or is this considered out of scope for QField's target professional survey use case? Would this be better implemented as a QField core feature, or as a companion/plugin approach (similar to how mock-location workarounds are currently used for iOS/Android NTRIP clients)? Are there known technical blockers (Qt/QML GNSS API limitations, cross-platform raw measurement access) that would make this impractical compared to other GIS/GPS apps like OruxMaps? Happy to help test on Android devices with Qualcomm Snapdragon chipsets (raw measurement support confirmed) if this is seen as worth prototyping.

As a cloud architect I want to self-host in Azure, using cloud-native resources. I have now managed to fork the code (using AI) and make it run in Azure Container apps & with Azure storage backend, though I would prefer this to be supported natively. I would be happy to share my code, though in the current state that code isn't merge-ready Especially the job orchestration with Docker-in-Docker is incompatible with Azure Container App Environments, and I rewrote it in order to use Azure Container Jobs