Closed m-kuhn closed 1 week ago
@lp-dj great ideas, regarding point 4, would you define that during the copy action or in the project configuration?
Thank you for the positive feedback @m-kuhn.
I was thinking of a way in preparation for the copy operation to restrict the attributes to be copied from the originating feature as needed. For example, you could use your checkboxes for this that you use when digitizing new objects to remember certain attribute values for the next features to be created.
Currently, these checkboxes only appear when creating a new feature. That means their place and action in existing objects is still free, isn't it? ;)
My idea now was to use the checkboxes to mark attributes that you want to copy. If no checkboxes are checked, all attributes are copied and otherwise only the checked ones?
That was roughly my idea when I read your suggestion for the Copy feature enhancement in #1825. But you can certainly think about it for a moment longer.
Perhaps briefly to the background (if interested):
In my daily work as an ecological surveyor, who maps in the field, there are, depending on the concrete task, often recurring constellations of attribute values that you want to store.
The software that we have mainly used for the last 2 decades for data collection has the function to copy the attribute data from one feature to the next. I know that this is a popular function that some colleagues in my line of work like to use and that I was asked about directly the last time I advertised QField ;)
In QField it can be sometimes a bit tedious to type some attributes in over and over again. In several cases the Multi Edits, which were introduced with version 1.6, already help well here (apart from my problem described in #2082). But I still see/ experience quite a few situations where such a finely adjustable copy function including cascaded copying of relations would offer real added value.
The described design of the function would be even much more powerful than our old software, because you could define much finer which attributes to copy, instead of only being able to copy either everything or nothing at all.
But that alone would be pretty cool, in case my idea about 4) makes it too complicated. I know things are much easier said than implemented :D
I can see that this would be helpful.
Another option would also be to "store feature as template", give it a name and select which attributes and then you could paste from template or prefill from template upon creation.
@m-kuhn Yes, that would be a great addition. But I would actually see it as an addition and not an alternative, since for certain scenarios I have in mind it wouldn't be the most effective way to always have to create a template first, name it and select it again at the destination. I'm not sure either though, maybe you just meant it as a complementary suggestion? That would be cool of course, I like to have many options at hand and choose the one that seems most appropriate to me depending on the situation.
Here you might have to consider to what extent you overload the user interface at some point, especially since you did such a great job building a simple, accessible interface for a complex tool!
There are still a few ideas that I have not posted yet, partly for similar reasons. Sometimes I wonder if it might be useful to add an "expert mode" option in the settings, after which activation all the fancy functions appear. That way you would have the choice again: is just the slim interface enough (which would be the default setting) or am I facing a more complex task where I want to use the full power of QField.
But slowly I leave again the topic of this thread here, sorry :-/ :D
This might be implemented as part of https://github.com/opengisch/QField/issues/2285#issue-1046770797
Implemented :partying_face:
What I would also find great would be the possibility to just copy the attributes from one existing feature to another.
Originally posted by @lp-dj in https://github.com/opengisch/QField/issues/1825#issuecomment-900391572