I have a ‘QGIS Project’ I want to use in the field.
I create a ‘local QFieldcloud project’ which is uploaded to the cloud
I use QField project in the field, push all changes
I can update the ‘local QFieldcloud project’ at step 2, but if I try to sync with my original ‘QGIS Project’ (at step 1), nothing happens and it simply opens the ‘local QField project’.
But I want my ‘QGIS Project’ updated and all photos transferred to a sub folder of that project.
Am I missing something? How do I update my original ‘QGIS Project’ .
This seems like a very clumsy workflow. I would expect.
I have a ‘QGIS Project’ I want to use in the field.
I create a ‘QFieldcloud project’ in the cloud
I use QField project in the field, push all changes
I update the original ‘QGIS Project’ by syncing with the ‘QFieldcloud project’
In my experience, for QField in general (and not just QFieldCloud), it’s better to thing that the original QGIS project (the one located on a random folder in your computer) is only a sort of original template for your actual QField project (the one you’ll be going back and forth between PC and field work); and either stop using the original folder, or deal externally with the synchronisation between QField and this original project.
This is because QFIeld prefers to organize the projects on specific folders and do a separate copy specifically for working within the QField ecosystem. On your PC, this typically is in <user folder>/QField/cloud when using QFieldCloud, or on <user folder>/QField/import and /export when cable transfering. On mobile, it’s pretty much the same. Think of them as “staging” folders, where QField and QFieldSync can prepare the information for handling. I think this is a reasonable step, taking into account how complex with relationships a QGIS project can get. If there are some unavoidable quirks and changes that must be made in order to open a QGIS project on mobile, this approach at least sounds better than the alternative: to mess up and modify your original project.
There are lots of ways you can improve on this basic functionality if you want to keep a separate folder for your actual project on the PC side. Since most of the field work should be modifying datasets and not the QGIS project itself, you can edit your “actual” project and point to the same datasets that QField uses, for example. That way, you ensure that as soon as you download the changes, they’ll be accessible on your real project.
Some ways to implement that can be as simple as dragging the copied datasets on the <user name>/QField folder as layers on your QGIS project, or creating symbolic links for the datasets on your actual project’s folder pointing to the corresponding files on the QField folder, etc. You can also try using Shared Datasets, basically having one or more central locations for your datasets and managing those for both QField and your PC QGIS projects.
Surely not. My oirginal project may contain other layers, e.g. those set to ‘remove from project’ for QField packaging. The existence of the settting ‘remove from project’ for QField packaging implies that the original project will be kept and used.
or deal externally with the synchronisation between QField and this original project
That seems to defeat, or at least curtail, a key benefit of ‘QFieldcloud’. For instance, I can create an offline project, transfer it to and from my fied device by cableexport, and updating the original project. This probably takes less time than having to ‘ deal externally with the synchronisation between QField and this original project’.
I also disagree that QFieldcloud forcing a particular folder structrure on you is a reaosnable ‘cost’. It is likely to lead to dupliaction of files and all the difficulties that causes with version control; and I reasonably want all files associated with a project within a single project root folder.
I’m tempted to save myself the monthly fee and revert to cable export. Surely QFieldcloud should be better than this.
Both in Cable export and QFieldCloud sync the QFieldSync plugin creates a new project from your original project, with a different name (it adds _qfield or _cloud to the QGIS projectfile). So syncing back from your device, it will never update your original project. If it would do that, you would lose your ‘removed layers’ from your original project.
If you need the updated data in your original project (or any other project) you need to set up something in your own workflow to use the updated data.
One way to do this is use the newly created datafiles in your cloud-project as source in your original project (right click layer and change data source from the original source to the new datafile). I have not tested this, but I am pretty sure the QFieldSync plugin will detect data changes when you happen to edit data through the original project in stead of the QFieldCloud project.
If it would do that, you would lose your ‘removed layers’ from your original project.
That’s not true. I frequently sync the original project to the qfield project I breing back form the field. Using qfieldsync I just point the original project at the field project. It only updates layers that exist in both projects and which have changes in the QField Project. Where that it is not as functional as QFieldckoud is handling multiple users.
One way to do this is use the newly created datafiles in your cloud-project as source in your original project (right click layer and change data source from the original source to the new datafile).
Yes, but I would still have duplication issues, and files outside of my project file structure.
It is, it makes sense then that they make a copy. It is called “packaging for QField” after all, not “sending to qfield without creating new files and no side-effects”. I’ve never seen a “packaging” function on any software that moves or modifies the original files; it always creates a sort of “cleaned copy”, sometimes zipped. Is this not expected behaviour for you?
When you say that ‘implies that the original project will be kept and used’ I think you’re conflating “qfIeld will use” with “I (Oisin) will use”. In that case, I understand why you feel like what qfield needs to work is an attack on how you want to work. To me, it only implies that it will be kept (since I expect the packaging proccess to have no effect on the original project). Not saying that you need to care for what I think, just saying that it seems more like a matter of perspective.
I don’t see how what you describe previous to this statement is anything but ‘deal externally with the synchronisation between QField and this original project’. Is there a way to cable transfer directly inside of QFieldSync?
I don’t get this either. Neither I nor probably you know what it entails to use a QGIS project on a mobile device, this was never the original intent of the program and (as far as I know) is mostly a QField effort. The existence of all these intermediary steps implies to me that something has to be changed in order to work. To just simply impose these changes, that might break things on your project or limit it in some way, is what sounds like forcing me to work a certain way, not the other way around.
Nobody is forcing you to use qfield, I think we are all trying to help here.
How is having ‘all files associated with a project within a single project folder’ helping fight file duplication? You have two projects working with the same data and then boom, duplicated files. How is this better than having central locations for your datasets, in regards to preventing data duplication problems? If you meant to say a central location, again, I think that Shared datasets (link to documentation) might be of help.
What is the point of this? This is a community forum. Do you need written justification to go spending on arcgis or something?
What duplication issues? The layers would be pointing to the same files as the qfield project.
I’m sorry if I sound argumentative, I’m not trying to be. I’m trying to understand the workflow on the assumption that QFieldcloud is intended to streamline the process of packaging an existing QGIS project for Qfield and eventually updating the original QGIS project, i.e extraction translate and load. It troubles me that the original QGIS project is not easily updated using either QFieldcloud or QFieldsync. When I try updating the original project using QField sync to pull data from the lcloud synced ocal QField project, is does nothing to the original QGIS project files, and seems to merely close the existing QGIS project and opens the local QField project. There are reasons that seems obvious to me why this is undesirable e.g. The original project may contain other layers; the original layers may contain other styles or user defined functions etc.; if I want to create a different QField project, the layer files are no longer all in the Project home directory, which throws warnings and potential errors when packaging.
I don’t understand why my expectations seems unreasonable?
Your expectations do sound reasonable, that’s is why I, and probably @Jeroen-GroeneBij, are trying to help. The thing is, as he said, that this seems to just be the way QField works, so
I think you aren’t missing anything, the conclusion seems to be that you “can’t”* update the original QGIS Project (I get what you say about the cable transfer, take it as “in the expected workflow for qfield”). This duplication in order to copy to and from qfield is also concerning for me, I get that it creates “an extra thing” to worry about. I wouldn’t call it “not helpful”, otherwise I wouldn’t be here. In comparison to not having a way to work with QGIS files on the field, I’m glad to concede it as a minor inconvenience.
I believe that on this forum, we can either propose and organise ways to contribute to qfield in order to improve it ourselves, help clear misunderstandings on the use of the program, or go around problems with alternative solutions. Correct me if I’m wrong, but I understand that you’re saying that your case is neither of those. I don’t expect for developers to be paying close attention here, nor taking too much feedback or requests for implementing features for free (it is my personal understanding, not a statement of facts). I do believe they have ways to finance for specific feature implementations.
I now see what you mean and where your confusion might come from.
Cable Packaging is certainly different from QFieldCloud synchronisation.
These are the workflows, as far as I understand them:
With Cable Packaging you have a local, original project ‘orig’.
You click ‘Package for QField’ , it will create a new project ‘orig_qfield’ with a copy of the necessary datasets and saves it into an export folder.
The contents of the export folder are copied to the field device to the ‘imported projects’ folder (on android). Now you can edit your data in the field.
The same content from the ‘imported projects folder’ is then copied to an ‘import’ folder on your local machine.
You open your original project in QGIS, ‘orig’, and click ‘Synchronize from QField’. This will synchronise the edited data with your original data.
Now for QFieldCloud
With QFieldCloud you have a local, original project ‘orig’
You click ‘QFieldCloud Projects Overview’ and create a new QFieldCloud project, ‘Convert currently open project to cloud project’. It forces you to save the QFieldCloud project locally in a different folder. It can not be saved into your original project folder. It creates a new project, ‘orig_cloud’ and copies the necessary dataset to this new folder.
You can synchronise the orig_cloud project with your field device, edit data in the field and push the changes back to the cloud.
When you want to synchronise the edited data from the cloud to your local machine, you can only sync it with your local copy, orig_cloud. You can not sync directly from the cloud to your original project.
As for the option ‘Remove from project’, I can see the benefit of having it available when creating a Cloud project, but your assumption about the original project being kept (yes) and used (no) is based on the experience and workflow of Cable packaging.
In a nutshell, Cable sync will sync back to your original project by default, and Cloud sync will sync back to your local copy, not your original project.
As to why these two workflows are different, I don’t know. As to why it is not allowed with QFieldCloud to sync to your original project, I don’t know. I hope the dev’s can answers this for us all.
And indeed I was wrong about how removed layers are treated in Cable sync. Thank you for correcting that.