QField Feature Requests

I really would like to be able to search for features which consist of less then 3 letters.

I have been exploring the "Full Motion Video" plugin for QGIS, which allows for the extraction of data from video—such as footage captured by drones. To utilize the Full Motion Video functionality, the videos must be accompanied by supporting telemetry data, including coordinates, orientation, angles, and similar information. Most drones come with this capability built-in. It would be a significant advancement to be able to record videos directly within QField, incorporating the telemetry data that most smartphones are capable of providing. Respectfully,

As a proponent of aletrnativ app stores, I want to access QField through F-Droid for its commitment to Free Software, privacy, and secure, unrestricted app distribution. (source: https://github.com/opengisch/QField/discussions/2706 )

What is the problem you are trying to solve? In QField, multi-select Value Relation dropdowns successfully display and group checked items when reviewing a previously saved/plotted feature. However, this behavior breaks when creating a brand-new feature while utilizing the "Remember Last Value" pin. When a field worker creates a new feature, the data carried over from the previous feature is active in the background cache, but QField treats the new record as completely blank visually. The carried-over items remain scattered throughout long lookup lists (e.g., a list of mixed species in forestry or biodiversity monitoring). Users are forced to scroll extensively through the entire list just to see what data has carried over or is already checked. In mixed environments (like woodlands containing a combination of conifer, broadleaf, native, and non-native trees simultaneously), splitting the data into cascading parent/child dropdowns isn't a viable workaround. What is your proposed solution? Update the user interface behavior within multi-select lookups so that carried-over data from the "Remember Last Value" cache is treated identically to pre-existing row data. When a new feature form opens, these active selections should automatically pin to the absolute top of the list view. This enhancement should: • Create a visual partition on new features: Group all carried-over/active selections at the very top of the widget immediately upon form creation, with the remaining unchecked options listed cleanly below them. • Preserve project sorting: Maintain the project's underlying sort order (such as alphabetical order or custom priority columns configured in QGIS Desktop) within those two separate blocks. • Update dynamically: Refresh the list order cleanly every time the dropdown widget is tapped open. What is the value of this feature? This fixes a major UX consistency gap between editing old features and creating new ones. It aligns QField with modern mobile UX standards, dramatically reduces form scrolling during rapid data collection, and eliminates critical data validation errors caused by carried-over selections being hidden deep within large lookup datasets.

We are communicating with other companys by sharing QFIELD-atlas-created-PDFs containig feature-lines/-points/-polygons with are drawn in maps. Additional photos from QFIELD in the PDF added to the map with some additional text descibe the situation/tasks in the field. Unfortunately with standard-printable-A4/A3-paper-sizes there is often too less space on the paper to fit in all the important informations on the paper. Using larger paper-sizes are not well suitable for others out in the field/wind. QGIS offers "reports" to split all the information to more than one page per feature (i.e. first page: desciption; second page: map; following page(s): fotos) It would be great to have a simmilar possibility within QFIELD

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.

When multiple users edit the same GeoPackage project from QGIS desktop via qfieldsync, there's currently no real protection against one user's sync overwriting another's changes. QField mobile already has a real conflict-resolution mechanism for this class of problem, but qfieldsync doesn't participate in it. Using postgres instance to deal with that problem could be a solution but in some cases it's more inconvinient than it seems to be. I needed a fix quickly for self hosted deployment and prototyped a stopgap: the desktop client remembers the file version it last synced, sends it on upload, and the server does something similar to a three-way merge of the GeoPackage instead of overwriting. It works, but I wonder if building a separate custom system instead of reusing your existing delta/conflict approach is a good final architecture. Is integrating the desktop client into your delta pipeline something you're planning? If you're open to it, I’d be happy to contribute and start off a discussion on how to approach it.

As a user, I want the images to keep the size as small as possible with as good a quality as necessary so as not to unnecessarily overload storage spaces. Today the average size of photos taken with QFIELD could be reduced by two via compression.

description: When collecting data in the field with one hand, the save button (✓) is at the top left of the object form. This is particularly true for subforms that are opened from the relationship editor. With the thumb of the right hand, it cannot be reached either in portrait or landscape mode. This is particularly noticeable when working processes with many linked objects, for example with several photos per area. There, the second hand must be added for each individual entry. Android's back button or back gesture has no effect on subforms and is therefore not a solution. Suggestion: A setting under “User interface” that displays the save button at the bottom right of the form, or alternatively a floating save button. Additionally or alternatively: The back button saves and closes a subform if all mandatory fields are valid. Environment: QField on Android (Samsung), relationship editor with a linked photo table.

As a plugin developer, I want a documented way to create and save a feature with the layer's default values and constraints applied, as QField's form does, so that guided data-collection plugins keep working after QField updates. Example: our field teams map plots and record farm work with a plugin that guides them step by step. One button asks what they want to record, records the shape (an averaged point, a walked boundary or corners), then asks one question per screen and saves. The layer's form holds the rules we rely on: a default value that builds a plot ID from the collector's code, the farm and a running number; a hard constraint that blocks saving when the collector code is missing; a soft constraint that warns when a new boundary overlaps one already recorded. To get those rules applied, the plugin creates its own QfFeatureModel and QfAttributeFormModel and calls create(). That works well, but these classes are not part of the documented plugin API, so we currently have turn off QField updates on the phones and test each new version before allowing it. What would make this stable: Document (and keep in the plugin tests) creating, filling and saving a feature with defaults and constraints applied, for example a small helper that takes a layer, a geometry and attribute values and returns the constraint results. A documented call to open the add-feature form for a layer with a prepared geometry, with a signal when it is saved or cancelled, as a fallback. A way for a plugin to ask for positions to keep coming while the screen is off, so a boundary can be walked with the phone in a pocket. Happy to test pre-release builds.