I have been manually entering geometries for activities within a given field area when the activity/task does not occupy the entire field. It would be nice if there were a way to add shading or have the geometry boundary show up in a different color from the overall field/area boundary. This would help better distinguish which section of the field is related to the geometry. Is there a way to do this?
1 Like
@graffte Are you storing both the overall field boundary and the specific activity boundary in the same geometry field on the log?
Ideally the log should only store the geometry specific to the activity being performed, and not duplicate the geometry of the overall area as well. If both geometries are included then there is no way for farmOS (or anyone other than you) to know what the difference is.
Hope I understood correctly, and that makes sense. 
Yes, both. Overall, I manage my records by field area. I’m entering the area name in location field for logs. There are times where I’m tracking work progress within a given field. It might take multiple days to completed something, or I’m running a strip test within the field area and want to highlight where. This is where I add a geometry showing where the work or test
was done.
OK so I would recommend NOT including the full area geometry in the log. If the log is intended to demarcate a portion of the overall field area then it should only include that portion.
I’m entering the area name in location field for logs.
Good! This links the Log back to the area, where you can go to find the full field area. But that full field area shouldn’t be stored on the log.
The reason you shouldn’t store both full and partial geometries on the same log can be summarized with this hypothetical: Imagine someone else looks at this log in the future, with no knowledge of your fields. They see two overlapping geometries, and there is no clear distinction between the two. The same would be true for any code (not just people) who look at this log. Imagine you write a module in the future that wants to calculate the total area that activities were performed on, by loading activity logs, calculating the area of the polygons in them, and summing them all up (strange use-case perhaps, but hypothetically). It would include both geometries in it’s calculation, which would throw off the totals. But if the log only stored the geometry that it is concerned with, then the total would be correct.
I think I’m confused now. For the log entry location, I’m selecting the area from the areas pick list. Then I have used Geometry to highlight an area within the selected area. When you do this you see orange areas boundary lines and the newly entered geometry lines also in orange.
I need the area selection in the log otherwise I can’t search logs by area (my fields). So is this okay to do with a geometry? I’m not sure what case you are describing as the issue.
1 Like
I enter the Area selecting it from the Area location pick list. Then highlight something with that area in the Geometries window. That highlight might include the field area boundary lines or be totally contained within the filed area boundary.
I seeded some peas into a section of a field area using a Seeding Log. I selected the overall field name from the area pick list showing the seed Movement to the field. Since the seeding didn’t involve the entire field area, I added a geometry to show the section of the field where the peas were seeded. How’s someone supposed to document some thing like this within the system?
1 Like
Sorry @graffte I may have caused more confusion. 
(It doesn’t help that the word “area” can mean both “an area record” and “a polygon geometry”. I should have been more clear.)
For the log entry location, I’m selecting the area from the areas pick list. Then I have used Geometry to highlight an area within the selected area.
It sounds like you’re doing it correctly!
I misinterpreted your answer to this question:
Are you storing both the overall field boundary and the specific activity boundary in the same geometry field on the log?
Yes, both.
I thought that meant you were storing two polygons in the log’s geometry field (the map).
So you’re doing it right! And that is exactly how you can represent tasks that only work on a portion of a field.
So… let me re-think your original question to see if I can better understand what you meant…
It would be nice if there were a way to add shading or have the geometry boundary show up in a different color from the overall field/area boundary.
…
When you do this you see orange areas boundary lines and the newly entered geometry lines also in orange.
When you are “viewing” the log you created (the View tab, not the Edit tab), are you seeing one polygon in the map, or two? Are you seeing both the whole and partial field geometries displayed in orange?
The geometry and field boundary are all orange. Can’t tell the geometry location from the 3 internal rectangular regions formed inside the field boundary. This is in View mode
1 Like
Hmm ok - so that looks to me like both polygons are being saved on the log after all! Which is not what you want…
Are you drawing both? Or is one (the overall field boundary) appearing automatically?
If it’s appearing automatically, then that might be a bug…
farmOS has some automated logic that will copy the boundary of the referenced “Areas” into the log’s “Geometry” field - but ONLY if the Geometry is empty otherwise.
So, if you “Add log”, reference an area, and immediately save, then the log will have the geometry of the area that was referenced.
If you “Add log”, reference an area AND draw a geometry in the map, and THEN save, then the geometry of the referenced area will NOT be copied. It basically checks to see if the geometry field is empty first. If it’s not empty (because you drew something on the map), then it assumes you’re saving a custom geometry and doesn’t touch it. That’s how it should be working. If you’re doing the above and getting different results then it might be a bug.
UNLESS… if you “Add log”, reference an area, then save it, THEN edit the log again to draw your custom geometry, the log WILL have the old geometry of the full field saved. So if you draw more shapes, you’ll end up with both saved on the log. That might explain how you ended up with the screenshot above?
If so, then what you can do is this: when you EDIT the log, first clear out the old geometry before drawing new shapes. You can do this by clicking the “Modify” or “Move” buttons in the map, clicking on the old shape, then clicking the “Delete” (trashcan) icon.
1 Like
I am only drawing the geometry. The field boundary is appearing automatically.
1 Like
I think this is the case. Generally I use the field kit to create the initial log entry while working in the field. I then edit the log later from my PC when it’s uploaded to the database. The old geometry lines from the field kit area selection will be there and I’m effectively overlaying another geometry on top.
So if the orange field boundaries are already there, I need to edit them out before adding the new geometry. Oh man… I got a mess to clean up. Not sure how many logs have this situation.
3 Likes
Ah! Mystery solved! 
How many logs need cleaning up? If it’s too many to do by hand, it might be possible to automate it with a script.
1 Like
I don’t know for sure. Is there an easy way to search the log entries for the ones with manually entered or extra geometries?
1 Like
Unfortunately no. But that’s essentially what a script would need to do: load each log, check to see if it has multiple polygons, if so: get the referenced areas, get their geometries, check to see the geometry exists in the log’s geometry collection, if so, and if there are other non-area geometries: remove it.
So, why does it allow someone to add a second geometry within an existing geometry in the first place? An error message or user instruct in these situations would be useful.
Is this allowed… two different geometries in a single log that don’t overlap.
1 Like
There’s no way to know what you intention is. And there aren’t any technical limitations from having overlapping geometries. The only issue is “what does that mean?” So what we’re mostly talking about is keeping a clean convention in data entry so that it’s easy to understand in the future.
Is this allowed… two different geometries in a single log that don’t overlap.
Yes, a geometry can have any number of points/lines/polygons, overlapping or not.
That’s part of the challenge though: farmOS lets you put in whatever data you want. It is not opinionated about it, and doesn’t enforce rules - at least not in the raw “Edit log” form - rules could certainly be enforced at higher levels if someone wanted to build a UI for specific workflows where restriction was necessary. For instance, perhaps the specific workflow you’re doing could be captured in a Field Module in Field Kit, and validation logic could be added there to enforce it. (Just thinking out loud as a way to illustrate why/where validation like this might fit.)