QField Feature Requests

As a planter with cold fingers, I want a magnetic snapping crosshair in BROWSING MODE that snaps to nearby features while panning, So that I can simply drag to inspect features and stay zoomed out instead of excessive zooming and precise tapping, preferably even without releasing the finger. Additional context: The snapping crosshair is already working fine in digitizing mode (other purpose, though not selecting the feature, I don't know why). Feature table and attribute table are already there.

As a long-time power user of QField who regularly trains water utility companies in its use, I find the app fantastic for field data collection. However, a critical feature is missing that would dramatically expand its adoption: the ability to type precise distances when drawing lines or polygons, mirroring QGIS Desktop’s "Advanced Digitizing" tool. Currently, water companies (and similar industries) rely on CAD or QGIS for designing water networks due to the need for millimeter-accurate digitization (e.g., pipe lengths, valve placements). While QField excels in mobility, the lack of distance input forces field crews to approximate measurements or resort to post-processing, reducing efficiency and accuracy. Proposed Solution: Integrate a "Distance Input" toggle during vertex placement when drawing lines/polygons. Allow users to manually enter: Distance (e.g., 5.25 m) and angle (e.g., 45°) for the next segment. Mimic the workflow of QGIS’s "Advanced Digitizing" panel for intuitive use. Impact: This addition would make QField indispensable for infrastructure management. Water utilities (currently hesitant to switch from CAD/QGIS Desktop) could: Digitize water/sewer networks with precision directly in the field. Eliminate post-processing errors and save significant time. Fully replace traditional tools with QField’s mobile-first approach. Closing: This feature would elevate QField from a "great" app to a game-changer for engineering-grade fieldwork. Industries managing linear networks (water, energy, telecom) would adopt it en masse, knowing they can trust on-site precision. Thank you for considering this transformative enhancement!

It would be useful, especially if navigating to a location by car, if the map was rotated according to the travel direction instead being fixed to north-up or the device/compass orientation. So for example in the attached GIF the canvas would rotate according to the direction of movement.

It is currently not possible to define a network-proxy in QField. This is especially inconvenient in the Windows version.

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.

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

RTK Antenna Emlid reach RX and RX2 is no made for iphone. There bluetooth nema stream works no on iOS devices. https://blog.emlid.com/de/lernen-sie-die-neue-generation-des-reach-rx-rtk-rovers-kennen-der-jetzt-mit-allen-gaengigen-gis-apps-fuer-ios-kompatibel-ist/ On android this works with QField but on IOS this does not work because QField does not support bluetooth on iOS devices. ArcGIS field mapper App supports bluetooth and the emlid reach RX works there.

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?

QField offers settings for "Enforce accuracy requirement" and, when averaging GNSS positions, for "Minimum number of positions collected". Additional settings are needed. Along with the linear accuracy thresholds, there also needs to be a position quality threshold for the value of the Quality field of the NMEA GGA messages from the GNSS device. The threshold would range from "Autonomous" or "Single Point" as the least restrictive, to DGNSS, to RTK Float, and to RTK Fix as the most restrictive. If the current quality value does not equal or exceed the position quality threshold, then collection of new measurements should be prevented, similarly to the effect of the existing "Enforce accuracy requirement" setting. This will ensure that measurements are not collected that do not meet the user's quality needs. If the position quality drops below the position quality threshold, the accuracy indicator badge attached to the location button should turn red, again, similarly to the effect of the existing "Enforce accuracy requirement setting. During averaging of GNSS positions, if the position quality drops below the position quality threshold, the low-quality positions should not be incorporated into the average, nor cause the displayed count of positions to increment, i.e. averaging should pause. When the position quality rises to equal or exceed the position quality threshold, the averaging and incrementing should resume. This too will ensure that measurements are not collected that do not meet the user's quality needs. If the position quality threshold is implemented, an additional enhancement that would be helpful is another GNSS averaging setting for a time limit (with a resolution of 1 second and a maximum of at least 10 minutes — but really, the setting should allow specifying arbitrary hours, minutes, and seconds). When either the number of averaged positions (with quality values that equal or exceed the position quality threshold) reaches the existing "Minimum number of positions collected" setting, or the time limit setting is reached, the averaging should terminate. If the termination is because of reaching the time limit, the user should be presented with the option to either accept or reject the averaged measurement. The number of positions that were incorporated into the average should be easily visible while that option is presented. Note: These recommended features are typical of other GNSS data collection software.

Unlike QGIS, the QField measure tool does not allow the choice of ellipsoidal or cartesian distances. Apparently, it calculates ellipsoidal distances. For projects that are based on a cartesian grid (e.g. UTM), this can be a source of error or confusion, or at least cause the user to have to do extra calculations involving a scale factor. There should be a setting to choose whether ellipsoidal or cartesian calculations are performed. Along with affecting the calculation of distances, the setting should also affect the calculations of the measure tool's other results as well (azimuth, perimeter, and area).