Hi,
It seems like sharing projects with colleagues is important obstacle for many users.
There is the option to work with QField Cloud.
But I know many users have developped ‘‘Local’’ solutions.
I’d like to know what you do ? Why ? How ?
Thanks
“QField Cloud” or “sync” was no option for my team because
(1) there was limited support for a postGIS backend when I tried it (at least on basic tier);
(2) storage was rather limited, and I could not judge how much my project would grow (fear of potential future migration);
(3) I have to distribute confidential data, which may not be on servers outside organization.
The “Local” solution is not local at all: we simply use our institute’s file sharing servers. It is a bit of fiddling with the “zip” files, and with incoming photos in a DCIM subfolder, but it generally works fine. I have local shell scripts to upload/distribute the project files, and from there field users can grab them when they need to to manually import the QField zip (fieldwork) or QGIS qgs files (desktop work).
Though this works fine for now, I keep an eye open for alternatives and would be grateful to read what others here use!
What I advise for users that cannot afford multiple account, is to share a cloud account. You just share the login info, and the other person can sync on his device. It is quite effective if users just add data, and do not rely on simultaneous data. Though it is limited in storage.
If you wanna keep things local, you can share the zipped project via mail or whatsapp or whatever. It’s acceptable if it is just to share the information, but not efficient to collect data…
Same thing, waiting to hear for better alternatives!
Thank you, this is exactly the kind of answer I was searching for. Interesting.
Seems like this part of the job is hard to manage for many users who are not fully into GIS and informatics.
Thank you for your input Felix. You are right. Sharing projects is one thing and working with colleagues to collect data for a single project is quite different and much more prone to problems.
What would alternative methods need to do exactly to be ‘better’? How would your ideal sharing method look like?
That’s what I’m trying to figure out. The thing is I held a meeting with different users last week and I discovered that the fear of losing data prevented users/potential users from actually choosing QField for serious team projects.
There is certainly a lack of training behind that, but I think there is something to be done.
I think it is easy for different kind of users or organizations to prepare forms and projects and collect data on the field individually. But it seems like the data management part is harder to understand or master and teamwork is just one step beyond.
I’m thus trying to understand what the difficulties are and what solutions have been implemetend so far.
Very sharp insights! I have to agree with your points. There seems to be a big gap between team and solo work in general.
In my case, both when working alone and in teams (almost always without the use of qfieldcloud), I typically setup “survey” projects. That is, I try to separate as much as possible the field work from the desktop work. I might include some data from the actual “master” project, but only in as far as it helps the surveyor to collect the data. For me, typically that’s not the case, the excess of information is more distracting and overtaxing on the mental load of the people in the field. Plus, I prefer to keep information in a “need-to-know-basis” generally and see field devices as the most untrusty and with the greater surface for attack.
What does help a lot, especially when working in teams, is the clarity of the forms’ designs that are achievable with qfield, and all the constraints that are possible to setup on qgis.
So what I usually do is create simple projects oriented to data gathering as fast and easy as possible. No data from the main project can be lost that way. And regarding the loss of field data, when combined with the cable-transfer workflow, I haven’t found as much problems with sudden updates breaking things or being left with no clear way to recover at least some version of the captured data, as it at least forces the allotment of some window of time after the field work to get direct access to the device in case I need to copy directly from qfield’s folder if the need arises. So in the end, I offload the complexity of the data preparation, management and safety to myself instead of the whole team.
To me this adds the additional advantage of more clearly separating the “roles” in the team. It seems perfectly reasonable to expect less tech savvy people to encounter more friction and have the possibility to make more mistakes with the software. Most of my teammates don’t have much experience with advanced PC use, let alone GIS or DBs. In cases with great disparity like that, I think you have only two options:
- A. Setup complex organisational management systems, with user rights, levels of privilege, redundant backups and whatnot. You’ll most likely want a dedicated IT team to handle that. This gives you full power, and have to work to limit and control it.
- B. Try to come up with a simple workflow that limits as much as possible what people need to know to operate. You start with zero power, and have to build your way up.
Both are the same in spirit (simplify the work of the majority of people by limiting what they can do). The difference is only on the mechanism that enforces that simplicity. On the former, it’s the systems in place, in the latter it is just the physical reality of not having access to the information. Systems are flexible and dynamic, but are prone to failure.
Even if we assume that all the users in the team are experts, to me it begs the question if everybody really needs full access, all the time, to edit the direct data on its source, online, 24/7. So I’m eager to see what others have to say regarding their workflows and solutions.
Thank you Cuprico. Many interesting things in there. I think a common problem is not having an expert in the team. The importance of data management is often underestimated and teams are composed of users without any manager…
that’s interesting. Do you have any particular examples? What is their goal? Do they want to, for example, register or catalogue things on a map? Or they plan to analyse the information somehow? How do they find out about qfield?
I’m mostly limited on a kind of “data analysis” process. To me, typically a “map” comes about when trying to synthesise some kind of insight or knowledge about an area by gathering samples and coming to a conclusion. In other words, a map exists because some “expert” requires it because it plans to process some particular information. So in my case, first came qgis as a way to process spatial information, and through it I’ve found qfield as a way to gather some of that information.
You are absolutely right ! The data collection is part of a plan but I think sometimes what is lacking is a good plan to manage the collected data !
In my experience, QFieldCloud is the best option in terms of data handling for non-expert small teams. Synchronisation is easy, fast, and accessible direclty in QGis without transfering anything manually. A whole team can work together on a project without implementing any complicated structure. Morever, all the data is hold in the cloud, that is a huge increase in the security of the data in case of an accident (for people that can spend weeks on the field without any office time).
To me, it is already the best option in most of the cases. The main problem for my clients is the price. For a 3-person team handling 4 or 5 projects, they cannot afford 3 pro accounts or the organization plan. They are willing to pay for the storage, but the multiplication of the accounts makes the price grow too fast.
So you have to manage the name of the photos to avoid duplicates. You also have to make sure to avoir duplicate IDs. What else do you need to consider with this workflow ?
This is of particular interest to me. I am slowly building up understanding and experience in team workflows, and I do think the current documentation is not well suited yet. It feels fragmented, sometimes lacking important steps or prerequisites. Sometimes the documentation seems to have been written or build as a step by step guide and sometimes it seems to be just an explanation of a single feature. And over time, this has become intermingled in the documentation section on the QField website. Also some sections are tailored towards data gathering users and some sections are specifically for project-management users and this is also mixed in the documentation.
So, from a training perspective, we should really create a distinction between users in the field and project management (project-development) in the office.
Users in the field need to know:
- how to interact with the QField user interface
- how to make sure they start with an up to date project (and up to date data)
- how to sync their collected data
- and how to inform the project manager on any issues with the above
A project-manager or project-developer, being the person who creates and maintains the QField project needs to know:
- how to create simple, efficient and fail-safe forms
- how to avoid sharing to much data and layers that may be not be necessary in the field
- how to set up robust attachment collection (because this seems to be the most common issue and question on this forum)
- how to sync to and from QFieldCloud in general and with special attention to attachments
- how to deal with any sync issues that might occur
Although this role might be given to a senior QGIS user, interacting with QFieldCloud and updating a dataset this way is certainly something different from being a (Q)GIS expert.
I think training material and dedicated documentation is needed for this role.
@Jeroen-GroeneBij This sounds like a great suggestion to me, explicitly stating those roles and adding or restructuring the documentation to reflect that might help set better expectations on the whole work that should be done when working with these tools (like what @Territoires mentioned about the often overlooked need for good plans on managing data).
@Territoires I manage the QField photos with a simple python script which checks for duplicates/prior photos, grabs new photos (by date and size), uses ffmpeg or imagemagick to downscale all new photos and push them to the DCIM of the project folders.
It is hacky; no everyday solution. We do not have a WebDAV yet; this would be the way to go.
Alternatively, postgreSQL (which we use as a backend) can store photos as binary blobs ( BinaryFilesInDB - PostgreSQL wiki ) and I would love to do that, but could not get it to run.
Just picking up on what others wrote: there comes a huge benefit from using postgreSQL and postGIS as a backend for QGIS/QField layers. It is super relatively simple, you can use views and update rules, backups, advanced features; all the “hard thinking” is done on the database side, and QGIS/QField are (unfairly) reduced to little more than an interface.
Just thinking here: if QFieldCloud could have some database hosting service as a “dev option”, which hosts the database backend with a beginner friendly interface… That would be a huge selling proposition.