If the movement geometry is empty, it takes the areas which I select. Well, if we draw a polygon and select data from the areas, it does not save both. It only save polygons.how can i fix this?
When I draw a polygon on the map and select areas, it takes the polygon and does not save the area.
If I select the area first and save the log record, then if I draw the polygon, it takes both.
This is the expected behavior.
When a log is saved, it checks to see if A) there are areas referenced, and B) the geometry is empty. If so, then it copies the geometry of the referenced areas into the geometry of the log.
But if B is not true (and there is geometry on the log already when the log is saved) then it will NOT copy the area geometry. It ONLY does that if the log geometry is empty.
If you draw a geometry and then save the log, then it assumes that you wanted that specific geometry, and does NOT copy the area geometry.
The only way to have both right now is to do like you said:
If I select the area first and save the log record, then if I draw the polygon, it takes both.
Notably, this is a little bit more “smart” in farmOS 2.x… but still would not work the way that you are describing. In 2.x, farmOS basically tries to determine if the geometry is a “custom” geometry or not. If it’s custom, then it doesn’t touch it. If the geometry is equal to that of the areas, then it will reset the log geometry if the area references change.
It sounds like you want to be able to have both a “custom” geometry AND the area geometry. There’s no easy way for farmOS to know that that is what you want, unfortunately.
This is the first time I’ve heard someone request this particular behavior (saving BOTH the area geometry AND a custom geometry). Can you describe why you want that? It’s hard to imagine a situation where you would so now I’m curious. 
Just thinking broadly… one way to achieve this might be to move this “copy” logic client-side, rather than server-side, and include some toggle-able options like “Automatically copy geometry from areas” and auto-update the geofield as you select/deselect areas.
However, this is complicated… you would ALSO need to have it work server-side the same way that it does now, otherwise API-generated logs would never have their geometries populated like they do now.
Still, having some frontend options would be nice… just need to figure out how they would interact with the backend logic.
To add a potential use case I tried a few years ago.
I have banana “fields” that are made up of 3-5 smaller areas in close proximity. These fields are about 2 hectares each with approximately 1800 banana plants per hectare. We harvest once a week all year (more fruit in summer less fruit in winter). In The summer we will be able to take an entire harvest from an area of a field but in winter we jump multiple fields. I was trying to record custom geometry for the area of said field harvested for reference of the area and the field code. But it is easier to just keep the resolution of the data to field and areas are getting a bit too high resolution but the quest for data is strong ;).
Real-world example, I think…
Thanks @MorgsBrew - if I understand correctly it sounds like ultimately you’d like to have the granular geometry on the log (of the actual harvest area), but in practice drawing that geometry is time-consuming, so you are just referencing the area and allowing the larger geometry to be copied in, which saves time but at the expense of granularity.
That makes sense, and seems like the focus should then be on making it easier to achieve the granular data.
But what I heard from @compact2 is that they want BOTH the broad area geometry AND the granular geometry in the same Log (if I understood correctly) - and that doesn’t really make sense to me. There would be no way for someone looking at this log in the future to truly understand where it took place, unless they had some implicit memory or understanding to draw from. And that makes the data brittle… because it has external dependencies on someone’s memory.
Ah but… as I’m thinking more about this… perhaps I can think of a use-case (and maybe this is what both of you are already saying, so bear with me as I get to where you are):
Imagine I am harvesting bananas from two areas, and I completely harvest one area, but only partially harvest another. It would be helpful to be able to “Add log”, reference both areas, automatically copy their geometries into the form (without saving), then modify/delete ONE of the geometries and draw the partial geometry that was harvested.
That would require implementing some options in the client-side code (and figuring out the considerations there) as I described in my previous comment.
