About coords.zone

Who runs it

coords.zone is built and operated by Markus Nordin, a software developer working as an individual (sole trader) in Sweden. There is no company behind it and no team - one person writes the code, runs the servers, and answers the email.

I also build and operate the gardening app gardenhero.app — this API was originally written for it, and still serves it in production.

Why it exists

Plant hardiness zones are published as maps and lookup forms, which is fine for a person with one garden and useless for software with a list of coordinates. Every project that needs a zone ends up either scraping a map or shipping a hardcoded table. coords.zone exists so that a hardiness zone is one HTTP GET, the same as any other geocoding lookup, and so that coordinates outside the United States return something more useful than a USDA zone alone.

It started as one feature inside the garden app. That app is global, which is where the real problem showed up: getting USDA-style coverage for the whole world is one thing, but several countries lean on their own local scale instead, and a zone number is not much use to a gardener in Sweden or the UK if it is not the scale they actually use. That is an easy detail to miss if you have only ever needed US zones. As far as I can tell, nothing else returns a country's own local zone system from a coordinate — there was nothing to buy instead, so it got built.

Building it properly meant assembling global climate data and deriving the zones from it rather than copying someone else's map. Both the data and the work it took came out larger than expected, and a climate dataset of that size sat a little oddly inside a garden app. The USDA-only lookup APIs I found cost more than a single field in a garden app could justify, and none of them answered the local-zone question at all. What this costs is on the pricing page.

So rather than leave that work buried inside a single product, I pulled it out into an API any developer can call. That history is also why the free tier is sized the way it is: someone building a proof of concept should be able to finish it, ship it, and reach their first customers before the limit is something they have to think about.

Where the data comes from

Zones are computed from ERA5-Land, the ECMWF climate reanalysis dataset, at a resolution of 0.1° - roughly 9km per cell. The USDA zone for a coordinate is the mean annual extreme minimum temperature over the most recent 30 complete years, classified into the standard 1a–13b bands. Country boundaries come from Natural Earth admin-0 data at 1:10,000,000.

Nothing is precomputed into a zone table. The underlying climate values are stored as they came from the source, and the classification runs at query time, so a correction to how a zone is derived applies to every coordinate at once rather than requiring a rebuild.

What is exact and what is approximate

USDA zones use the USDA's own published breakpoints, so a returned zone means what the USDA means by it. Germany's zones are the same thing renamed: the official Heinze & Schreiber/DWD scale reuses the USDA breakpoints under different labels, so "Z7b" means exactly what "7b" means.

The local zones for Australia, the United Kingdom, South Africa, Sweden and Norway are approximations. They are derived from the same climate data, fitted to reproduce each country's published scale - they are not licensed reproductions of the official maps, and they are not endorsed by the bodies that publish those maps. Sweden and Norway (Scandinavian) zone maps are hand-surveyed over decades and cannot be accurately approximate in all circumstances. If your use case requires the zoning data to be fully accurate, consider a more transparent approach by providing users with the climate data instead and let them decide on their own, or buy the licenses from each provider.

Contact

Questions about the API, bug reports, or anything about your account: [email protected]. For privacy requests, use [email protected] - see the Privacy Policy for what that covers.