I have noticed that when I create an Activity Log and assign a location and then save that log, then realize I chose the incorrect area, edit the Activity Log and select the correct area and save the log, then when I View the Log entry, the map shown in the Geometry section still shows the original Area instead of the changed/updated Area.
I have done this twice now, and both logs are still showing the original Area’s that I selected at the time of first creating the Activity Log.
I can supply the log ID’s if needed to help troubleshoot.
1 Like
Hi @ctomayer - Yes, this is expected behavior, although I agree it’s a bit annoying right now. I’ll explain why this is, and how it works, and hopefully that will help.
Basically: there are two separate fields on logs: “Areas” and “Geometry”. Areas are just references to the individual area records themselves. Geometry is for storing geo-located shapes (points, lines, polgyons) on the log record.
When a log is saved, there is some logic in the background that will run, and it will look at the Areas field and the Geometry field. If there are areas referenced, but no geometry entered, then it will load the geometries from the references areas and COPY them into the log’s geometry field. However, it will ONLY do this if the geometry field is empty.
The thinking here is: it can be helpful to store area geometry on the log, so we might as well copy it over if no other geometry is stored. But… if you DID draw a geometry on the log, we don’t want to overwrite that, because it may be something more specific or important to the activity being described.
So… that explains the behavior you’re seeing: if you create a log that references and area, it copies the geometry of that area into the log. But then if you edit the log and change the area, the geometry field already has data in it, so it will NOT be touched.
This is just for safety… farmOS doesn’t really know that you are just changing the area and you want to update the geometry at the same time, so the safe and simple thing to do is just say “oh there’s already geometry - so don’t touch it”. Now… we COULD expand on this logic and make it more intelligent… for instance it could load up the old and new area geometries, compare them, figure out if it’s just the area that’s changing, and then pretty safely assume that it can overwrite the geometry. But that “intelligence” hasn’t been coded yet. Might be worth opening a feature request for it. Another option might be simply having a checkbox that says “copy geometry from areas”, which allows you to explicitly state that you want to overwrite the old geometry.
In the meantime, the workaround is pretty simple: open the geometry field, clear out the “Data” field below it, and save the log. This will empty the field, so that the logic will automatically run again and copy the geometry from the area.
Hope that all makes sense and helps to understand how it works! 
@mstenta - As usual, awesome explanation. The behavior makes sense now.
I think the “copy geometry from areas” would be more than sufficient and make the updating simpler. I will look around to find where to enter a feature request.
Thank you again for such a complete explanation.
I just want to chime in here and say that this behavior has been both slightly annoying and overall valuable to my use-case so far.
At least for my use-case I would argue against trying to make the logic much smarter. It has turned out to be valuable for the old area geometry to be preserved since beds/fields can change over time, but it is still nice to have some historical record of the area that was actually planted at the time the log took place.
The simpler option of giving more control to the end-user seems better. One way to do that would be to have a button on the edit form which makes the behavior more explicit around resetting the geometry back to that of the current area geometry - since part of the confusion here comes just from the somewhat unintuitive behavior of needing to clear the contents of a text box to have it implicitly repopulated on saving.
1 Like
I just want to chime in here and say that this behavior has been both slightly annoying and overall valuable to my use-case so far.
Ha! Glad it was overall valuable. 
At least for my use-case I would argue against trying to make the logic much smarter.
Yea, that’s my gut inclination too. Keep it simple and explicit, so it’s clear what’s happening (we aren’t exactly doing that now, as this thread shows, but we’re close).
It has turned out to be valuable for the old area geometry to be preserved since beds/fields can change over time, but it is still nice to have some historical record of the area that was actually planted at the time the log took place.
Yes! This was actually one of the original reasons/benefits for adding this logic. It was an easy way to automatically make richer history.
The simpler option of giving more control to the end-user seems better. One way to do that would be to have a button on the edit form which makes the behavior more explicit around resetting the geometry back to that of the current area geometry - since part of the confusion here comes just from the somewhat unintuitive behavior of needing to clear the contents of a text box to have it implicitly repopulated on saving.
Agree 100% - I think this would be the best of all around solution. Would either of you like to make a feature request and start working on this? I can show you where the logic currently resides that performs automated copy of geometry.
The tricky part might be: we need this automated logic to work in two contexts… a) when you submit the log edit form, and b) when a log is created via the API. Right now the automated logic fires whenever a log is updated, regardless of whether you are doing that through (a) or (b). So if we add a checkbox to the form, that will require adding additional logic to the form alone (a), but still preserving the API behavior (b).
Let’s create a feature request and continue the discussion of specifics over there. Worth copying the above paragraph into it for reference ^