Nov 22 2019

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 gave me what I needed. 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 down to basics. We iterate for a reason!

Vegetable garden layout sketch.
Last updated: Friday, November 22nd, 2019

A few days after I got the idea to make my garden planning tool, I ran into several 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 had miscalculated a few things (including my budget), and consequently, the layout of my darling garden had to be tweaked.

Moreover, I found out walnut trees are known to be allelopathic - meaning they leak toxins in the soil that other plants may not tolerate well. Guess what would provide some shading to the garden on scorching afternoons?! A friggin' walnut 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.


Surprisingly, there is too much and too little data for home gardeners on the web.

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

And none of these have APIs. I wrote about Trefle - some outstanding work, but after looking at the data, it appears to enrich USDA data with additional information from GBIF.

I searched for plant variety information—how and when precisely do you sow, plant, care, and harvest, and 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, I could not find them, or they are proprietary or without an API. So, since I needed to use my garden planner yesterday (!!) I had to reconsider a few things.

Reducing the scope

The desire to build something AWESOME corrupted my initial plan. Instead of a "simple" tool, I started dreaming of enriching all data I found on plants across databases, thus creating a tool that would interest botanists and horticulturists. Crazy, right?! Seeing the vast amounts of (by my criteria, incomplete) data, little of which served my needs, I had to take a breath and consider my priorities.

So, I will make a product for myself instead of one for the world. I must remember to keep things as straightforward as possible while still functional. What does that mean?


Since I will make a product for myself, I need an empty database. Sure, I need to model it correctly, but the entries will have to be manual, based on the seeds I purchase, for specific varieties with specific requirements. This revelation 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.


The API will be reasonably straightforward 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 I am building a "book of seeds," and they come with an expiration date, I might have to "soft delete" a batch of seeds - not necessarily the species/variety.

Generating data

I will be generating data using a front-end application.

If necessary, I might still use external APIs for images, taxon information, etc. I will probably also use external sources, such as the ones mentioned above, to add valuable information about pests, care, and characteristics that I should keep in mind. These will require citation and a link, as it is proper and nice for work well done.


The front-end app needs the mother of all forms to generate the data correctly and slap me when I'm lazy. If I need information absent from the seed packet or the seller's website, 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, an excellent search function would be nice. Also, I should be able to quickly access a group of plants/fungi (yes! I want to grow some mushrooms too soon). The plants' genera would probably do this. 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 implements categories.

Explore by Tag

On each tag page, you can find a link to that tag's RSS feed so you only get the content you want.