QField Feature Requests

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.

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).