Conventions Bi-weekly Call: March 28th - Geometries, fixed vs not, & strategies for Plans

Discussion of running geography allowing for logs/assets across time x space

Thinking about farmOS in the context of USDA as essentially a dev tool

How is geometry maintained for plant assets? Set as log (seeding log), which both references a location & stores own geometry (& can modify if you need)

Alex B. - Startin’ Blox search engine for data - using solid standards to output compatible APIs

  • Connect w Octavio for similar functionality happening in Mongo mirror

Alex C. - Working with Laura Morton on a method for crop management plans / intentions to stay associated with data (Conservation Practice codes & data to validate) - how to structure link between plant asset & activity log to meet their needs?

  • For a field with both seeding & grazing, do those require separate plant assets?
    • Walkthrough from Mike:
    • fields have their own geometry - can see all logs associated with that field, and assets currently associated with it.
      • within this, can have a sheep herd as a unique asset with type ‘group’, which contains members
      • can move that group/herd to a new location (field B) but could also specify particular area of field B, which creates a new activity log with a new geometry
    • Location from sheep herd then comes directly from that new log - record knows where that sheep is located via movement logs
    • Logic aka “Location” != geometry

In Alex’s model, have been equating assets with fixed geometries -

  • Land assets have fixed geometries, but that’s not the only way to conceptualize - every asset has the concept ‘fixed’ y/n

  • Example of logic embedded in farmOS that has yet to be / needs to be generalized for common conventions

  • Have options for custom conventions for USDA needs based on how granular records need to be

  • Proposal - Codeshare

    • Do we need to capture discrepancy between plan intention & what actually occurred - or just what actually occurred?
    • This need may be a result of farmer timeline & need for creating records - pre-planning
    • Is the database we’re designing for a tool for farmers to use, or a tool to store data outputs?
    • Goal is that it would be useful for both, for many user types - data into system is dependent on farmer benefit - if it’s useful for farmers, we get more data into system
    • Planning structure is dependent on where data is coming from - USDA interest is in how practices impact GHG fluctuation, which is invested in actual events
      • But we need to be able to draw lines around certain sets of events - plan 1 vs plan 2 in order to compare them
      • Use concept of plan to feed info into a script
      • Greg’s ideal - plan lines up 1-1 with plan template -( template is not a core farmOS concept, but something Greg is working on. Could have Plan distinct as a concept) - could just do this work within conventions?
        • This is how bulk farmOS importer works - you define a template & it populates based on info & relationships you provide
        • (not a convention, but template can be auto-derived from a convention - similar to a pre-populated log - applies a convention to constrain the data)

Purpose & Function of Plans

Purpose of a plan is to constrain (?), purpose of a convention is to validate

  • From Mike - Plan is not always about planning, it’s more about encapsulation of assets & logs - it’s an entity type with subtypes, can associate certain logs & assets for a given purpose.
    • Further conversation - plan record

Need for more / more frequent conversations on this front – try to schedule a time that Paul can make! Mondays?

1 Like

Notes from Greg - proposals for plans / templates

structure workbook as logical database
output workbook correctly
automate validation
generate COMET outputs


/*
- land asset // "Field A" PLU, farmers field, ... 
- plant asset // "2020 Corn planting (in field A)" succession (line we draw around seeds in the ground on the same day)
- seeding log // the seeding event
- harvest log // the harvest event
- grazing log
- irrigation log
- [...] plan
- [...] plan_record
- plan_template

Question: how do I track geometries for animal grazing
Answer: I put the specific grazing location in the grazing log
*/

// option 1: create a template with custom information to generate a plan
// option 2: create a template with the exact items needed for the plan (list of entities)
// option 3: utilize conventions to simple create a constrained plan convention (no template at all)


// Option 1: General Management Plan
// - gives you a container to associate together records under the same Plan and that Plan information.  Enter whatever data you want there relating to the Management Plan. 

// Option 2: General Management Plan and Template
// - gives you a container to associate together records under the same Plan and that Plan information.  Enter whatever data you want there relating to the Management Plan. 
// - gives you a Template to associate Plans that came from the same 

// could use the convservation practice code as a common reference in the plan (liket his plan follows this thing)
// maybe also use a 'template' as a 'create new', and 'reference', and 'validate'
// needs:
// - contain key information describing the system - must be flexible.  May reference external systems
// - contain the ability to instatiate the events - may also require a script to generate it
// - contain the ability to validate a bucket of events to a plan

// OPTION 4

// an actual activity that we did.
// have a irrigaiton log convention that's constrained and contains all your management data in it.
// DOESN'T DO... don't really give you lots of flexibility between logs/assets/quantities in a complex way.
// we have a convention called log__irrigation__energy_saving

let log__irrigation = {
	attributes: {
		geometry: {
      value: '<the WKT object',
      source: "well"
    }
  }, relationships: {  	
    assets: {
      data: [ { id: '<the_asset_id>' } ]
    }, plan: {
      data: [ { id: '<the_plan_id>' } ]
    }
  }
}


// what we generally do
// example: "Energy Saving Irrigation System"
// water source, equipment used, discharge rate, irrigation duration
// I would propose this could define how a conservation practice is defined (?)
let plan__irrigation__template = {
	attributes: {
    name: "Energy Saving Irrigation System",
    id: "232;jlkfj2-f23f",
    water_source: "well",
    equipment: ["tractor"],
    discharge_rate: {
      maximum: 10,
      rate: "gal_hr"
    }, irrigation_duration: {
      maximum: 2,
      rate: "hrs"
    }
  }, relationships: {
  }
}

// OPTION 1
// script --> convert plan__irrigation__template --> plan__irrigation
// what we planned to do for a specific field or planting
// example: "Energy Saving Irrigation Plan"
let plan__irrigation = {
	attributes: {
    name: "my actual irrigation plan for field 5",
    id: "we23rff23f2f23",
    source: "well",
  }, relationships: {
    "equipment": {
      data: [ { id: '<the_equipment_id_used>' } ]      
    }
  }
}

// an actual activity that we did.
// script --> convert plan__irrigation__template --> plan__irrigation
let log__irrigation = {
	attributes: {
		geometry: {
      value: '<the WKT object',
    }
  }, relationships: {  	
    assets: {
      data: [ { id: '<the_asset_id>' } ]
    }, plan: {
      data: [ { id: '<the_plan_id>' } ]
    }
  }
}

// OPTION 2
// what we planned to do for a specific field or planting
// example: "Energy Saving Irrigation Plan"
let plan__irrigation = {
	attributes: {
    name: "Energy Saving Irrigation System",
    id: "232;jlkfj2-f23f",
    water_source: "well",
    equipment: ["tractor"],
    discharge_rate: {
      maximum: 6,
      rate: "gal_hr"
    }, irrigation_duration: {
      maximum: 1,
      rate: "hrs"
    }
  }, relationships: {
  }
}

// an actual activity that we did.
let log__irrigation = {
	attributes: {
		geometry: {
      value: '<the WKT object',
    }
  }, relationships: {  	
    assets: {
      data: [ { id: '<the_asset_id>' } ]
    }, plan: {
      data: [ { id: '<the_plan_id>' } ]
    }
  }
}

// OPTION 3

1 Like