Users should be able to add plants to the database

[RickCarlino]

I propose the following attributes until we can integrate with FarmBot:

• Common name
• Binomial name (Ex. Citrullus Lanatus)
• Description text
• Sun requirements (full / partial / etc)
• Sowing method (Direct to soil, start indoors, etc.)
• Spread (plant girth)
• Days to maturity
• Row spacing (store in database as CM, allow imperial conversion on front end)
• Height (see note above)

Obviously, there will be more data fields in the future, but after looking at several seed catalogs, Wikipedia and a few other sites, I think this will be enough for the first release.

[roryaronson]

This looks like a good starting point. One I would add is watering requirements. We talked before about giving "ballpark" numbers based on the plant's life stage (seedling, flowering, fruiting, etc) and then allowing FarmBot to number crunch and get a more specific amount based on the day and current conditions.

So maybe we could define the life stages a plant goes through and an average amount of water per plant per day during that stage?

[cpursley]

I recommend plant hardiness zones. Much of the growth cycle depends on this.

http://planthardiness.ars.usda.gov/PHZMWeb/

I'll search around for an API ~ or this data can be used: http://www.climatesource.com/PHZM/zip.html

[warpling]

Any further thoughts on this guys? Is it worth keeping things this simple while we get stuff up and running or should we start scheming for how to handle variable life cycles, hardiness zones, etc?

[roryaronson]

I found a couple other databases yesterday that we can look at and also maybe partner with or share data (I've reached out to both)

http://practicalplants.org/wiki/Practical_Plants got there starting data from plants for a future, see the link in their footer.

http://growstuff.org has an API but it doesn't look like the data will be as good as the practical plants stuff because it's less focused on the knowledge side of things.

[warpling]

Oh wow… interesting… Growstuff is great looking but simple, Practical Plants has everything and more that we want, but could be designed better. Not a bad guide system at all though. Wow it's actually a full wiki and they're pulling in some data from here?…

[GeoffCapper]

Hi,

You seem to be missing a rather important field, the sowing time range. It might be useful to store it as entries from a season enum (if ruby has those or something like it) rather than as dates, and then calculate dates based on the end user's hemisphere, that way you're not opening up so many avenues for data entry problems.

[roryaronson]

Calculating dates based on the user's hemisphere is a great idea.

What you see in the production site right now is our very first database that we threw in quickly because we didn't know what it should really look like yet. We've been brainstorming and have come up with a much more comprehensive structure that is yet to be implemented. You can see it here

[octopuscabbage]

I would reccommend adding way too many fields and then going down from there. You can always filter out some model stuff you don't really need, but it's way harder to add more things in later. So if only a few plants have their data about optimal water temperature or something like that filled in we should have that early on as opposed to having that put in later.

[RickCarlino]

I would prefer we don't do it that way.

We're using MongoDB so additional fields don't require migrations or schema changes as with traditional SQL databases.

A better idea is to build out the UI first and make a database that supports the application rather than defining the application. Start from the outside and move in.

[TimEvWw]

I'm guessing you're going to use a dynamic parameter list? It's mongo as a database so adding more parameters later on should be a non-event.

The values and dates on the other hand I think should be depending on multiple parameters. Growing season and water usage is different depending on greenhouse/outside and location. Certainly if you also make a difference between the official numbers and the user corrected values, or also want to incorporate aquaponics data. For mongo, this would mean that one value (a date or amount of water) is actually a document with in there a lot more possible values.

From what I've seen of 'companion plants', permaculture sees this as an outdated method. They define each plant by it's multiple functions, like retains water, fixes nitrogen, deep roots, ... Good adjacent plants in a garden are the ones that give a good mix of these functions, something that can be written in an optimizer later on.

Also missing I think is the size of the plant. The diameter for each growth stage is handy for scheduling where weeding must be done by the hardware.

On Fri, Jun 27, 2014 at 11:57 PM, Chris Denniston notifications@github.com wrote:

I would reccommend adding way too many fields and then going down from there. You can always filter out some model stuff you don't really need, but it's way harder to add more things in later. So if only a few plants have their data about optimal water temperature or something like that filled in we should have that early on as opposed to having that put in later.

— Reply to this email directly or view it on GitHub https://github.com/FarmBot/OpenFarm/issues/7#issuecomment-47404709.

[octopuscabbage]

My appolgies, I somehow had it in my mind we were using sqllite.

I feel like that approach could work, but some preconsideration should be given to the database because this is a database driven program.

[TimEvWw]

Sqlite is used on the raspberry pi for caching the schedule and settings.

On Sat, Jun 28, 2014 at 12:28 AM, Chris Denniston notifications@github.com wrote:

My appolgies, I somehow had it in my mind we were using sqllite.

I feel like that approach could work, but some preconsideration should be given to the database because this is a database driven program.

— Reply to this email directly or view it on GitHub https://github.com/FarmBot/OpenFarm/issues/7#issuecomment-47406962.

[roryaronson]

Tim, good eye about the missing data pieces. I gave you edit permissions on the spreadsheet.

It's important to separate the subjective data that people will be entering into their "Guides", from the objective data that can be scraped from other resources and is applied universally to that plant variety.

Understanding that there is no "official" way to grow something is key because there are nearly unlimited ways to grow a plant based on methodology, and nearly unlimited environmental conditions that it might be grown in. So OpenFarm allows anyone to create their own "Guide" that is the story of how they grow the plant. The guides will be rated so the best ones get used more often. And each guide will have a "Compatibility Score" between the guide and the user and their garden, based on the methodologies used/preferred, and the environmental differences the guide calls for and the user's profile.

I suggest everyone here view the most recent mockup of the "Guide" pages to get a better understanding. Feedback is welcome. I'll put a better description of OpenFarm into the README right now.

Tim, as the database becomes more advanced, we can add sections specifically for companion plantings that may be more based on plant attributes or functions like you mentioned. One day, Guides could be created specifically for plant combinations such as the popular Three Sisters one.

[andru]

From what I've seen of 'companion plants', permaculture sees this as an outdated method. They define each plant by it's multiple functions, like retains water, fixes nitrogen, deep roots, ... Good adjacent plants in a garden are the ones that give a good mix of these functions, something that can be written in an optimizer later on.

This can be true. Certainly many common "companion" relationships are just combinations of, to use permaculture terminology, function and spacial/temporal niche. e.g. To offer a classic example: in The three sisters polyculture (Maize, vine legume and vine winter squashes) the maize occupies the canopy spacial niche and functions as a structure for the vine legume, which occupies a vertical/climbing spacial niche and functions as a nitrogen fixer and the winter squashes occupy a soil surface spacial niche and function as a ground cover. The three compete on a temporal niche (that is, they all reach their peak growth approximately around the same time), and so are spaced and fertilized accordingly. There are also additional spacial niches to consider beneath the soil based on root depth and spread. Plants which perform no detrimental (though preferably beneficial) functions to their neighbours and which do not compete for the same niche (spacial or temporal) could be considered companion plants, and indeed many traditional companion plants can be categorised by these two properties alone.
Some, however, may share more specific relationships not so easily defined by a simple niche and function system and would require significantly a significantly more complex model to infer any useful relationship. For a concrete example: onions function as a pest deterrent/confuser to some species of insects but not others. One must therefore be capable of categorizing which species of insects onions deter and which species of plant those insects predate upon in order to infer that onions and carrots share a beneficial relationship: onions deter carrot fly. This information could be more easily modeled as a specific relationship than as a product of function/niche.

The key, I think, in modeling relationships is to accept that sometimes nature is far too complex to consider attempting to model accurately, and that as long as sufficient data be provided to explain the nature of the relationship, it's ok to create a direct link based on evidence/experience between two species rather than rely on their properties to create the link.