My Garden Planner project - first hiccups

As I started digging into plant data on the web, I found that there wasn't any API that gives me what I need. But that was only a problem, because I made it one. Here's part two of the journey to build my own (virtual) gardening tool, where I strip it all down to basics. We iterate for a reason!

A few days after I got the idea to make my own garden planning tool, I ran into quite a few hiccups.

In the atoms and molecules world, some of the atoms that made the raised beds for my garden got lost in transit... At the same time, I realized I miscalculated a few things (including my budget) and, as a consequence, the layout of my darling garden had to be tweaked.

On top of that, I found out wallnut trees are know allelopaths - meaning they leak toxins in the soil that other plants are sensitive too. Guess what would provide some shading to the garden on very hot afternoons?! A friggin' wallnut tree. But since the garden's first year is an experiment of many things (no dig, Danish climate, my gardening skills, companion planting, gardening with deer and chickens running wild), I guess we add one more to the list: trying to grow plants in soil full of juglone. I wonder if there's a cheap soil test for this...

So, next year's garden will be exciting to watch!

But on to the thornier issues.

DATA!

It's surprizing how much and how little data there actually is out there for home gardeners.

There's much of it indeed - there's a whole universe of websites that sell plants, seeds, etc. and also provide good quality information about the plant and its care. To mention a few, the Royal Horticultural Society in UK, Thompson & Morgan, Andre Briant, and of course the USDA Plant Database.

Aaaand none of these have APIs. I wrote before about Trefle, which is some outstanding work, but after looking at the data, it appears to be enriching USDA data with additional information from GBIF.

I tried searching for varieties information - how and when exactly do you sow, plant, care and harvest, in addition to specifications such as space, moisture, soil, sun requirements, and so on. I couldn't find any consistent database with an API that provides all that.

If there are any, either I couldn't find them, or they are proprietary, and/or without an API. So, since I actually need to use my garden planner yesterday (!!) I had to reconsider a few things.

Reducing scope

My initial plan was corrupted by the desire to build something AWESOME - enrich any and all data I found on plants across databases and thus create a tool that would be interesting to both botanists and horticulturists. Crazy, right?! Seeing the vast amounts of (by my criteria, incomplete) data, little of which served my own needs, I had to pull back a few steps and consider my priorities.

So, instead of a product for the world, I will make a product for me. I must remember that and keep things as simple as they can be, while still functional. What does that mean?

Database

Since I will make a product for myself, I need an empty database. Sure, I need to model it the right way, but the entries will have to be manual, based on the seeds I purchase, which, being for specific varieties, will have specific requirements. This solves the crazy data problem. Sort of. The database will be a graph in Neo4J which I am just learning, but that's not a problem in and of itself. It's a challenge accepted by default.

API

The API will be fairly straight forward CRUD. I doubt I will ever use the delete function, though. The point is to use this for years to come and evolve the data not diminish it. However, since what I am building is essentially a "book of seeds", they do come with an expiration date so I might have to "soft delete" a batch of seeds - not necessarily the species/variety.

Generating data

Data generation will be done via the frontend.

I might still make use of external APIs for things such as images, taxon information and the likes, if I find it necessary. I will probably also use external sources, such as the ones mentioned above, for adding valuable information about pests, care, characteristics that I need to be aware of. These will require citation and a link, as is proper and nice for work well done.

Frontend

Well, the frontend needs the mother-of-all-forms in order to generate the data correctly and slap me when I'm lazy. If the information I need is not on the seed packet or the seller's website, well, go dig, guuurl! Incomplete data and messy descriptions are the reason I started this in the first place.

When creating an entry, I should also be able to search for / create companions and antagonists.

Ideally, I would also find some (font)icons that would make good illustrations for the garden drawing board.

Once the database is populated, a nice search function would be... nice. Also, I should be able to access quickly a group of plants / fungi (yes! I want to grow some mushrooms too soon). This would probably be done by the plants' genera? Maybe I should just custom group them? To be considered.

NOTE TO SELF: tags are always a quick, easy way to group things. Don't complicate things. If you need hierarchical data, consider how WordPress categories are implemented.

Next steps

  1. Refresh knowledge of plant taxonomies and their hierarchy to support next step;
  2. The first version of the Plant model and taxon models;
  3. A list and description of relations between plants;
  4. The first version of the form;
  5. The most basic API, to save form data in the database;
  6. An idea of possible icon sets.

This week's lessons

  • A smaller, working, app is better than a big project that never sees the light of day.
  • Neo4J is really fun! I wrote my first queries for creating nodes and relationships.
  • Open-source should get A TON of love. Life as a developer would be a nightmare if it didn't exist.
  • Don't try to lift a 300-liters sack of wet peat moss :/ Have a nice weekend!
Care to share?