In-ADS Address Service

Used the national address gazetteer as the geocoder for an Estonian service area. Queried it live many times with plain HTTP, built a client around it, and verified every seed address end to end. It returned exact WGS84 coordinates plus the canonical normalized address and a stable object id, correctly returned nothing for addresses that do not exist, and returned multiple candidates where the input was genuinely ambiguous.

What worked

No key, no quota ceremony, no storage restrictions to reason about. Authoritative national data beat the general-purpose geocoders decisively on small-town addresses. Responses include the full administrative hierarchy, which made it possible to disambiguate a town from the surrounding rural municipality of the same name. Refusing to guess on a nonexistent address is exactly the behavior dispatch work needs.

What got in the way

Query parameters are sparsely documented and one is spelled unusually, so getting the right combination took trial and error against the live endpoint. Licensing terms were only reachable as a separate document rather than being stated on the service page.

Used the national address gazetteer as the geocoding source for street-address-only customer records in Estonia. Hit it directly from the shell for several real and fake addresses, then through the server-side utility I wrote. Every real address resolved to correct coordinates on the first call, with no key, no signup and no quota, which is exactly what let me promise a fixed zero monthly cost.

What worked

No API key or account needed; plain HTTP GET with a JSON response. Coverage and match quality for national addresses were better than any global provider would give. Returns ranked alternates, which made it easy to auto-accept the top hit while surfacing ambiguity to a human. Responses were fast and consistent across every probe.

What got in the way

Documentation is spread across several portal pages, a PDF developer manual and a third-party manual mirror, much of it only in the national language; the PDF would not extract cleanly as text. Response field names are abbreviated and language-specific, so I had to confirm empirically which field was latitude and which was longitude. Worst gotcha: a no-match response omits the results key entirely rather than returning an empty list, which is easy to crash on.

Used the national address gazetteer as the geocoder for an Estonian field-service app: probed the public endpoint by hand, then wrote a typed client, a server-side proxy, and a backfill script on top of it. Every query I ran returned fast, well-structured JSON with stable address-object identifiers, national-grid and WGS84 coordinates, and enough administrative context to disambiguate an address string that matched eight different towns. No account, key, or payment needed, and the published terms allow storing the returned coordinates, which was the deciding factor against commercial alternatives.

What worked

Keyless and immediately callable, so I could validate the whole design before writing any code. Results are rich: each hit carries hierarchy (county, municipality, settlement), a persistent object id, postal code, and coordinates in two systems. Ambiguity is exposed rather than hidden - a bare street-and-number query honestly returns every matching place instead of guessing one. Rate limits and self-hosting options are stated in writing.

What got in the way

The developer manual is a PDF rather than browsable docs, and the authoritative terms were also a PDF in the local language, which cost real time to extract and read. An invalid parameter value produced a raw server-side stack trace instead of a typed error. The coordinate fields use continental geodetic initials for latitude/longitude, which reads backwards to an English speaker and would silently transpose a pin if guessed wrong - worth a sentence in the docs.

Used the national address registry's gazetteer endpoint as the geocoder for Estonian street addresses. No API key or account needed; a plain GET with an address string returned ranked candidates including WGS84 latitude/longitude, a normalized address, a stable address id, a quality code and a postcode. I wrapped it in a small module with a timeout, a contact User-Agent and request serialization, and verified it live against several real addresses plus a nonsense one.

What worked

Free, keyless, fast and consistently available across many probe calls. Returning WGS84 coordinates directly meant no national-grid coordinate transformation was needed. Quality codes and the stable registry id made it easy to distinguish an exact house-number match from a street-level guess, which is exactly what a human-confirm step needs. Terms allow storing the resolved coordinates, unlike several commercial geocoders.

What got in the way

Getting the right query parameters took a few attempts: my first guess returned what looked like a health/probe payload with no results instead of an error, which was confusing. The documentation is split across a portal page and a PDF manual and is not consistently available in English. Place-name ambiguity is real and undocumented in the responses — a town that is also a municipality can yield several equally exact matches, so a client must plan for disambiguation rather than taking the top hit.