Closed codingCoffee closed 2 years ago
@vishalseshagiri
[] Add a select field named "Is container type?" where user can indicate if it is a "container type" or "soil type" plot. If checked ERPNext will NOT keep track of the historical applications of fertilizers, pesticides, water, etc.
If left unchecked, when the crop cycle activity such as "Fertilization" or "Irrigation" is linked to a particular plot, records can be obtained from the database for historical amounts of fertilizers, pesticides, herbicides, etc. applied to this plot.
Definitions Soil type plot: The actual field on the farm which has no physical barrier between the topsoil and sublayers of soil and rocks. If you add water to it, it would eventually reach the aquifer. Container based plot: A plot which has any substrate which is physically separated from the sublayers of soil. Examples are: Pots, planting benches, seedling trays, cement pits with nutrient solution for raft culture of hydroponic plants, or any flat surface where potted plants are placed.
Why is this important? As an example, we had a case where a plot was rented out and was receiving intensive weekly applications of KCl (Potassium chloride), a cheaper source of potassium. After 10 years of this, the yields of the crops were dramatically decreasing. When we took ownership of the plot again, the low yield of the plants became painfully apparent. If you walked on the field, you could see and feel the difference between consciously treated soil and this chloride rich soil: It was stickier! We spent a lot of time investigating, and we finally figured out that Chlorine was the problem. The amount of time spent investigating could have been 10 times less, should thehistoric data been available! This particular crop needed a lot of potassium, but the chlorine was not taken up by the plant and remained in the soil. The consequence of 10 years of Potassium Chloride application was that the excess chlorine ions would not allow the soil to release the necessary nutrient ions (N, P, K, etc.) to the plant, and thus, lower yields were the ultimate consequence. We eventually opted to do an unscheduled final cut, in sections, to turn the soil over completely with a tractor and add amendments to reclaim it. This process overall took several years, and came at a high cost.
Providing a historic series of the nutrients and pesticides applied to a specific plot will give traceability, if only for proper management, but eventually this might come in handy for farmers who need to comply with a specific certification.
Tue Oct 24 20:24:30 IST 2017
@vishalseshagiri I would suggest that the Area UOM be pre-populated from a settings single doctype. Generally farmers are going to use one type more than others, and will often only use one. Example: conventional cereal grain farmer is going to measure everything in hectares or acres Example: a greenhouse may have some areas measured in sq ft or sq meters (interior greenhouse space) but also do some growing outside, which may be measured in acres or hectares.
Given the limited scope of zooming in on a satellite or map based viewport (leaflet, Open Street maps, Google Maps, etc.) I proposed during a meeting with the Frappé (nov 3 2017) programmers that we add functionality to the Land Unit DocType for defining smaller-unit plots of land using some sort of in-browser, JavaScript / HTML /Python based, 2D drawing tool
@codingCoffee suggested we add a select or check field where user can specify if he wants to draw an .SVG (or upload one) of an existing floor plan.
Normally, a farm has a plot of land which can be easily seen from satellite imagery. However, for smaller farms, or farms under greenhouses, the individual "plots" can be smaller than can be useful and discernible from a satellite image. For those cases, the user clicks on a check field in the Parent Land Unit DocType that allows the user to either draw an SVG on a blank canvas (with a scaled grid) or upload a ready made .SVG (or other Open Source CAD files: STEP, IGES, STL, DXF, OBJ, IFC, DAE). This drawing represents all the child land units belonging to it. Each individual "polygon" on the SVG can be linked to a plot of land DocType. For each separate plot drawn on the SVG, a Land Unit DocType is created automatically.
Figure 1: Drawing the plots over a "farm" canvas
The result would be that the user can get a report called "status view" of their child land units (plots) according to crop cycle (user can determine if that specific plot is ready to plant again, or is undergoing maintenance, or needs irrigation or other tasks) or perhaps a "yield report" can show these individual polygons in an SVG file with different colors to represent a relatively high or relatively low yield. Or the report can show different crops in different colors (or overlaid icons) to make it easy to recognize patterns. The drawn diagram can even be useful for orienting new workers, planning applications, or even legal compliance with local authorities that might require these diagrams.
Figure 2: Highly simplified example of a color scale Yield Report Where a greenhouse contains more than 100 individual plots, this comes in very handy.
This would simplify in the sense that there can be only one .SVG file per parent land unit, and in this file, polygons which represent the final or child plots. Each plot can then have their display characteristics altered depending on the report view according to specified parameters by users, such as the yield scale.
I have two ideas in mind, that can be stripped to the bare essentials for drawing a simple 2D Plan:editor.method.ac Which I intuitively used to make the drawings in these images or a Janvas Which can be stripped down to its essentials and actually has a "layers" tool.
I cannot overemphasize the importance of having accurate, simple maps that we share with anybody that does work at our farm. It really minimizes error, and reduces explanation time.
Currently, the new Location DocType measures the area, but does not specify what the correct area UOM is automatically. Fix this!!