The aim of\u00a0this paper is\u00a0therefore not only to\u00a0introduce the\u00a0reader to\u00a0some of\u00a0the\u00a0functionalities of\u00a0this mobile application, including its advantages and pitfalls, but also, and most importantly, to\u00a0critically evaluate its usability in\u00a0practice. This is\u00a0done by\u00a0combining the\u00a0experience of\u00a0other authors of\u00a0case studies with our own experience, gained in\u00a0the\u00a0performance of\u00a0tasks arising from the\u00a0activities of\u00a0T.\u00a0G.\u00a0Masaryk Water Research Institute.<\/span><\/p>\n The QField application, intended for mobile mapping of\u00a0objects and real-world phenomena (collection of\u00a0spatial data directly in\u00a0the\u00a0field via a\u00a0mobile device), ranks among typical representatives of\u00a0Open Source Software (OSS). It\u00a0is\u00a0distributed under the\u00a0GNU Public Licence (GPL) version 2 and above\u00a0[1]. This means that under this licence, the\u00a0application can not only be\u00a0used for free, but its source code is\u00a0also freely available, which can be\u00a0further modified (which greatly strengthens the\u00a0user\u2019s\u00a0control over running processes). Closely related to\u00a0this is\u00a0the\u00a0expansion of\u00a0software configuration options and partial functionalities; in\u00a0this way, even more specific user requirements for the\u00a0final product can be\u00a0met with zero or\u00a0completely minimal costs for acquisition or\u00a0operation.<\/span><\/p>\n As\u00a0for the\u00a0other indisputable advantages resulting from the\u00a0OSS principle, we\u00a0must emphasize the\u00a0strong support of\u00a0the\u00a0user community in\u00a0the\u00a0form of\u00a0educational videos placed, for example, on\u00a0YouTube or\u00a0user discussion forums (Github, Stack Overflow, Reddit, etc.). OSS are also characterized by\u00a0being multi-platform or\u00a0having the\u00a0ability to\u00a0run the\u00a0required process on\u00a0more than one platform (in\u00a0the\u00a0sense of\u00a0operating systems or\u00a0hardware platforms). However, in\u00a0the\u00a0case of\u00a0multiplatform software, it\u00a0cannot be\u00a0automatically assumed that the\u00a0software will work on\u00a0all available platforms\u00a0[2].<\/span><\/p>\n QField is\u00a0currently available for:<\/p>\n Usually, easy data transfer is\u00a0ensured, i.e. data storage usually in\u00a0open formats. In\u00a0the\u00a0case of\u00a0QField mobile GIS, the\u00a0data formats of\u00a0the\u00a0QGIS and GDAL data providers are supported. The most common formats are Geopackage, Shapefiles, MBTiles, TIFF, JPEG2000, or\u00a0specifications or\u00a0standards created for the\u00a0needs of\u00a0GIS technologies and interoperability \u2013 WMS, WFS, Simple Features for SQL (however, this list is\u00a0far from complete).<\/p>\n The application is\u00a0developed using programming languages C++, QML, Java, Perl, and Shell scripts. A\u00a0brief history of\u00a0its development is\u00a0shown in\u00a0Tab.\u00a01. However, not all versions of\u00a0the\u00a0application are listed here, only those with major changes\u00a0[1].<\/p>\n The use of the mobile application must be preceded by the preparation of its environment. This phase includes several sub-tasks, such as selection of background maps, addition of other thematic layers that are necessary for the needs of the field data collection itself, setting of their symbology and labels of their elements; last but not least, there is creation of the target layer (or layers), to which new records will be collected. Functionalities that can be used for individual actions will be described in detail below. First of all, it should be emphasized that\u00a0<\/span>for these purposes it\u00a0is\u00a0more than appropriate to\u00a0use the\u00a0QGIS desktop application environment and tools, for several reasons. The first and most important argument is\u00a0the\u00a0high compatibility of\u00a0both software. This is\u00a0mainly caused by\u00a0the\u00a0fact that the\u00a0developers of\u00a0the\u00a0QField mobile application used the\u00a0same libraries (summary of\u00a0procedures, functions, constants, and data types) that QGIS uses. From the\u00a0point of\u00a0view of\u00a0basic data manipulation, whether previous or\u00a0subsequent, this solution appears to\u00a0be\u00a0very practical. Another reason for this connection is\u00a0the\u00a0interlacing with other geotechnologies. These can be, for example, data management and data storage systems\u00a0\u2013 PostgreSQL, SQLite and their extensions for supporting geographic objects (PostGIS, SpatiaLite) or\u00a0tools for providing geodata (GeoServer, QGIS Server) (Fig.\u00a01<\/span><\/em>)\u00a0[5].<\/span><\/p>\n <\/p>\n For custom data transformation between desktop and mobile application (and reverse synchronization of\u00a0changes), the\u00a0QField developers created a\u00a0plug-in\u00a0to\u00a0QGIS QFieldSync. This is\u00a0available in\u00a0the\u00a0plugin repository and can be\u00a0installed in\u00a0QGIS directly via the\u00a0Plugin Manager. The project in\u00a0compressed *.qgz format prepared in\u00a0the\u00a0desktop application environment contains information about the\u00a0configuration of\u00a0individual layers and background maps. Before data transformation itself, the\u00a0project must be\u00a0converted to\u00a0XML format *.qgs, which is\u00a0compatible with the\u00a0requirements of\u00a0the\u00a0mobile application itself. Thanks to\u00a0the\u00a0plug-in\u00a0module, everything (project and input data) is\u00a0stored in\u00a0one folder, which is\u00a0transferred to\u00a0the\u00a0mobile device. The transfer is\u00a0provided in\u00a0two ways; from the\u00a0repository or\u00a0using QFieldCloud (Fig.\u00a02<\/span><\/em>)\u00a0[1]. During application testing, the\u00a0fee was set for his service, so\u00a0we\u00a0were forced to\u00a0proceed with manual import (until an\u00a0adequate equivalent cloud or\u00a0other solution is\u00a0found).<\/span><\/p>\n <\/p>\n An\u00a0acceptable solution to\u00a0this problem appears to\u00a0be\u00a0the\u00a0use of\u00a0the\u00a0PostgreSQL database system connection and its extension for spatial data, PostGIS. The solution methodology proposed for mobile mapping of\u00a0the\u00a0road cadastre inventory of\u00a0the\u00a0city of\u00a0Piacenza in\u00a0Italy seems quite promising. Even though it\u00a0is\u00a0built exclusively on\u00a0free and Open Source Software without the\u00a0QFieldCloud service, it\u00a0complies with official national requirements\u00a0[12, 13]. The basic principle is\u00a0the\u00a0correct setting of\u00a0the\u00a0configuration file pg_service.conf. Thanks to\u00a0this connection, online data availability is\u00a0ensured and one of\u00a0the\u00a0limiting factors \u2013 the\u00a0memory capacity of\u00a0the\u00a0mobile device \u2013 is\u00a0eliminated, especially when taking more extensive photo documentation or\u00a0when using multiple background maps\u00a0[1].<\/span><\/p>\n The initial phase of\u00a0the\u00a0process includes the\u00a0configuration of\u00a0input data, i.e. not only background data (raster and vector), but also empty data sets into which new information about the\u00a0object of\u00a0interest of\u00a0data collection will be\u00a0collected.<\/span><\/p>\n In the case of background vector layers, the main things to deal with are their symbology, adjustment of the displayed legend, visibility in individual display scales, and labels of elements (Labels). In the QGIS environment, all the mentioned attributes are configured in the layer properties (Properties > Symbology). As for the underlying raster layers, there are two options. The first is the use of already prepared XYZ tiles \u2013 OpenStreetMap, Google Maps (e.g. satellite images are very often used), Mapy.cz, etc. If the users require their own specific background data, they must be processed into the project in MBTiles format (Processing Toolbox > Raster tools > Generate XYZ tiles \/MBTiles\/). This format only supports tile data (both vector and raster). A spherical Mercator projection is required for their presentation. The files can be internally compressed and optimized, producing views that adhere to the MBTiles specification [6]. A typical example of the use of this format in our conditions is, for\u00a0<\/span>example, a\u00a0background layer from processed remote sensing data or\u00a0reference map materials of\u00a0the\u00a0State Administration of\u00a0Land Surveying and Cadastre (Basic maps, Orthophoto maps).<\/span><\/p>\n For empty data sets, in\u00a0addition to\u00a0the\u00a0basic configuration of\u00a0their styles, their data model is\u00a0also set \u2013 in\u00a0simple terms, requirements for the\u00a0form and range of\u00a0information about the\u00a0object of\u00a0interest. The data model must be\u00a0defined before the\u00a0start of\u00a0the\u00a0collection \u2013 its modification during collection is\u00a0undesirable and (during subsequent synchronization) will often cause terminal complications, making subsequent geoprocessing impossible. Data layers populated through a\u00a0mobile application are vector by\u00a0default. It\u00a0always depends on\u00a0the\u00a0user\u2019s\u00a0intent; only the\u00a0basic geometry types are available, i.e.\u00a0point, line, and polygon.<\/span><\/p>\n An\u00a0indispensable base is\u00a0the\u00a0definition of\u00a0the\u00a0default attributes of\u00a0the\u00a0vector layer (their name and data type). The available data types vary according to\u00a0the\u00a0format specification. In\u00a0QGIS, the\u00a0data types listed in\u00a0Tab. 2<\/span><\/em> are available.<\/span><\/p>\n Individual attributes behave differently depending on their type (numeric, text, etc.). A summary of the data types used for a specific vector data set can be obtained from the source fields tab in the layer properties (Properties > Fields). When editing, their limits should not be exceeded, e.g. string length, range of values, or entering an incorrect expression. The behaviour of attributes (both in the desktop and mobile application) can be regulated and further specified using the attribute form in the layer properties (Properties > Attributes Form). In general, the configuration of individual attributes could be divided into several sections, namely basic settings, widgets, restrictions, and default values (Fig. 3<\/em>).<\/span><\/p>\n In the first section of the basic setting of the attribute (Fig. 4), the parameters for its display are dealt with, regardless of its data type. The Alias parameter adds a title to the attribute (without string length restrictions, with diacritics and spaces), which often makes it easier for the user to navigate, especially in the case of attributes with similar or unclear names. Another important parameter is the Editable checkbox. By default, editing the fields of this attribute\u00a0is\u00a0allowed. If\u00a0the\u00a0checkbox is\u00a0unchecked, it\u00a0is\u00a0not possible to\u00a0insert new data and edit existing data. A\u00a0relatively useful function in\u00a0the\u00a0field of\u00a0mobile data collection is\u00a0remembering the\u00a0last entered value (checking the\u00a0Reuse last entered value checkbox).<\/p>\n Widgets allow you to\u00a0configure specific forms with certain behaviour and appearance for different data types. In\u00a0the\u00a0following text, we\u00a0will proceed from simpler to\u00a0advanced variants of\u00a0widgets.<\/span><\/p>\n The simplest widget is\u00a0Text Edit. It\u00a0is\u00a0the\u00a0basic type of\u00a0editing window for text strings, while the\u00a0only alternative to\u00a0its extension is\u00a0the\u00a0use of\u00a0a\u00a0multi-line variant (Fig.\u00a05a<\/span>). Selecting the\u00a0Hidden widget hides the\u00a0name and content of\u00a0the\u00a0attribute in\u00a0the\u00a0detail of\u00a0the\u00a0element. The Checkbox field (Fig.\u00a05b<\/span>) writes the values that will be checked into the attribute, while their definition is required in advance. Using a checkbox is convenient for deciding between\u00a0<\/span>two states. Through Unique Values, the\u00a0content of\u00a0the\u00a0drop-down list is\u00a0generated in\u00a0the\u00a0attribute (based on\u00a0the\u00a0values already entered), from which you can choose during editing. If\u00a0this parameter is\u00a0also set as\u00a0editable (Fig.\u00a05c<\/span>), the\u00a0inserted text will be\u00a0automatically supplemented according to\u00a0the\u00a0possibilities of\u00a0the\u00a0drop-down list.<\/span><\/p>\n For numeric data types, the\u00a0permitted range of\u00a0values (Range), i.e. minimum and maximum values, can be\u00a0determined. It\u00a0is\u00a0possible to\u00a0choose between a\u00a0classic editable window and graphic tools, specifically a\u00a0slider or\u00a0a\u00a0spin box\u00a0(Fig.\u00a06<\/span><\/em>).<\/span><\/p>\n Attributes containing Date or Date\/Time can be inserted in many formats, or the user can insert their own format template. As for graphic elements,\u00a0<\/span>the\u00a0attribute can be\u00a0supplemented with a\u00a0pop-up\u00a0window with a\u00a0calendar (Fig.\u00a07<\/span>), from which the\u00a0desired data is\u00a0subsequently selected.<\/span><\/p>\n The Value Map widget could essentially be\u00a0described as\u00a0a\u00a0domain or\u00a0codebook. The attribute is\u00a0edited by\u00a0selecting values from the\u00a0drop-down list (Fig.\u00a08<\/span>). Its items are inserted and edited directly in\u00a0the\u00a0widget settings. Two parameters are used for their definition \u2013 Value, Description; the\u00a0description is\u00a0used during editing, the\u00a0value is\u00a0displayed in\u00a0the\u00a0resulting attribute table of\u00a0the\u00a0layer. As\u00a0for a\u00a0more extensive codebook, there is\u00a0an\u00a0option to\u00a0import it\u00a0from a\u00a0text file. It\u00a0is\u00a0also possible to\u00a0import values from an\u00a0attribute of\u00a0another dataset.<\/span><\/p>\n The UUID generator (Universal Unique Identifier) is\u00a0used exclusively by\u00a0the\u00a0data type. The text is\u00a0filled in\u00a0automatically. This is\u00a0a\u00a0unique identifier composed of\u00a0a\u00a0combination of\u00a0letters and numbers.<\/p>\n A\u00a0big trend in\u00a0recent years is\u00a0that multimedia files (e.g. photographs, audio recordings, and videos) are often attached to\u00a0the\u00a0collected attributes about the\u00a0object of\u00a0interest. In\u00a0this case, it\u00a0is\u00a0advisable to\u00a0use the\u00a0Attachment widget. The attribute of\u00a0the\u00a0data type text string can contain an\u00a0absolute or\u00a0relative path to\u00a0a\u00a0file or\u00a0a\u00a0URL (Uniform Resource Locator), which can be\u00a0displayed directly as\u00a0a\u00a0hyperlink based on\u00a0this configuration. It\u00a0is\u00a0possible to\u00a0set a\u00a0preview for images and web pages. More about the\u00a0possibilities of\u00a0inserting multimedia files will be\u00a0presented in\u00a0the\u00a0practical examples below.<\/p>\n Constraints can affect the\u00a0range of\u00a0attribute values (Fig.\u00a09<\/span>). For example, the\u00a0requirement to\u00a0fill in\u00a0the\u00a0attribute (checked checkbox \u2013 Not null) ensures that the\u00a0attribute is\u00a0filled with data. If\u00a0the\u00a0attribute is\u00a0not filled, the\u00a0user is\u00a0notified of\u00a0this fact and the\u00a0element record can be\u00a0saved. In\u00a0the\u00a0event that the\u00a0attribute values are strictly required by\u00a0the\u00a0user and it\u00a0is\u00a0necessary to\u00a0prevent the\u00a0storage of\u00a0an\u00a0empty attribute, the\u00a0next level of\u00a0this measure is\u00a0to\u00a0check the\u00a0Enforce not null constraint checkbox. Checking the\u00a0uniqueness of\u00a0the\u00a0record works on\u00a0a\u00a0similar principle (check boxes \u2013 Unique, Enforce unique constraint). Expressions can also be\u00a0used to\u00a0set controls for specified values. Based on\u00a0predefined user-defined functions, expressions offer a\u00a0powerful way to\u00a0manipulate attribute value, geometry, and variables to\u00a0dynamically change style, geometry, content, and more.<\/span><\/p>\nINTRODUCTION<\/h2>\n
\n
\n(https:\/\/play.google.com\/store\/apps\/details?id=ch. opengis.qfield),<\/li>\n
\n(https:\/\/ qfield.org\/get_latest\/?platform=linux) and MacOS (https:\/\/ qfield.org\/get_latest\/?platform=macos)\u00a0[3].<\/li>\n<\/ul>\nTab. 1. QField mobile app development history as of 2019 [4]<\/em><\/h5>\n
![\"\"](\"https:\/\/www.vtei.cz\/wp-content\/uploads\/2024\/04\/Matasovska-tab-1-1.jpg\")
<\/a>\n<\/a>\nFig. 1. Linking the mobile application with other geotechnologies<\/h6>\n
<\/a>\nFig. 2. Data transformation between desktop and mobile application<\/h6>\n
PREPARATION OF\u00a0WORK AREA<\/h2>\n
Tab.\u00a02. Examples of available data types\u00a0[7]<\/em><\/h5>\n
<\/a>\n<\/a>\nFig. 3. Data layer attribute form<\/h6>\n
Basic settings<\/h3>\n
<\/a>\nFig. 4. Basic attribute settings<\/h6>\n
Widgets<\/h3>\n
<\/a>\nFig. 5. Widgets \u2013 Text Edit (a), Checkbox\u00a0(b), Unique Values (c)<\/h6>\n
<\/a>\nFig. 6. Widgets \u2013 Range<\/h6>\n
<\/a>\nFig. 7. Widgets \u2013 Date\/Time<\/h6>\n
<\/a>\nFig. 8. Widgets \u2013 Value Map (domain)<\/h6>\n
Constraints<\/h3>\n
<\/a><\/h6>\nFig. 9. Restriction of attribute values<\/h6>\n
Default values<\/h3>\n