Testing location data with edge cases, not just happy paths
An address in a well mapped city center tells you almost nothing about how your system handles a rural route, a disputed border, or a query near the poles. Test the hard cases deliberately.
Why some IP ranges resolve only to a country, not a city
Not every IP address supports the same level of geolocation precision, and for a meaningful number of address ranges, country-level resolution is genuinely the most that can be honestly claimed, no matter which provider is doing the lookup. Understanding why this happens, rather than assuming it reflects a gap that better data would simply close, helps set the right expectations for handling these results in your own application.
Some address blocks are allocated to an organization that operates broadly across an entire country without a clear, consistent regional subdivision in how it actually routes or assigns traffic internally, which means there is no reliable finer-grained signal to report even in principle, not just a signal that happens to be missing from a particular dataset. Certain categories of network, including some satellite services and some large centralized providers, route traffic through a comparatively small number of exit points covering very wide geographic areas, as covered elsewhere, which caps how precise any geolocation of that traffic can honestly be, regardless of how good the underlying compiled data is for every other kind of network.
Newly allocated or recently reassigned address blocks can also lack sufficient real-world usage data to support anything beyond country-level confidence, simply because city-level geolocation for IP addresses generally depends on accumulating and correlating real usage signals over time, and a block that has not been in active, stable use long enough under its current assignment has not yet generated that signal, regardless of how good the underlying methodology otherwise is.
In every one of these cases, the right answer is to report country-level precision honestly rather than manufacturing a plausible-looking but unsupported city guess just to fill in the field. A confidently wrong city is considerably worse for your application than an honestly coarse country-level result, because a wrong but plausible-looking city can pass silently through logic that assumes it is reliable, causing a downstream error that is hard to trace back to its source, while a country-level result at least signals its own limitation clearly and pushes you toward appropriately conservative handling.
If your application depends on city-level accuracy for a meaningful part of its logic, it is worth explicitly checking whether the returned result actually includes a specific, populated city field, or falls back to country and region alone, and having a sensible default behavior ready for the second case rather than assuming a city value that is not there. Our IPv4 and IPv6 lookups return exactly what the underlying data honestly supports for a given address, at whatever level of granularity that happens to be, rather than padding a lower-confidence guess into a field it cannot reliably support.