So I think there's an important lesson in here for software engineers.
How do you design your API so that it is as difficult as possible for your clients to misinterpret?
The "always return a center & accuracy" API is very simple and elegant, but with the benefit of hindsight, you can assume that a significant fraction of your users are just going to ignore that accuracy number and treat the center as precise. As was pointed out elsewhere in this thread, the default point isn't the only problem -- any town, city, or state will generate similar problems.
One option would be to return a richer result type:
(COUNTRY, "United States")
(CITY, "Portland, OR, USA")
(REGION, latlng-a, latlng-b)
(POINT, latlng, accuracy)
Now it becomes more difficult for a client to pretend most of those are precise points.
The best API is sometimes not the one that is easiest to use but most difficult to misuse.
I appreciate the notion that "explicit is better than implicit", so as to minimize assumptions and miscommunications. But that said, if the service is providing details for a region using the center-and-radius approach, that sounds perfectly reasonable. It explicitly states what is being returned, and the fact that it isn't a single point. For responsible clients who are using the API correctly, this data-response is the easiest to parse and make sense of.
I would hate to see a world where services are responsible for generating and clients are responsible for parsing data in an overly convoluted and cumbersome format, just to minimize the risk of irresponsible clients misinterpreting it.
I'd return a rectangle instead of a circle. One point would be the upper-left corner, the other the lower right corner. To get to the "center" you'd have to do arithmetic on the coordinates, which would encourage thinking.
How do you design your API so that it is as difficult as possible for your clients to misinterpret?
The "always return a center & accuracy" API is very simple and elegant, but with the benefit of hindsight, you can assume that a significant fraction of your users are just going to ignore that accuracy number and treat the center as precise. As was pointed out elsewhere in this thread, the default point isn't the only problem -- any town, city, or state will generate similar problems.
One option would be to return a richer result type: (COUNTRY, "United States") (CITY, "Portland, OR, USA") (REGION, latlng-a, latlng-b) (POINT, latlng, accuracy)
Now it becomes more difficult for a client to pretend most of those are precise points.
The best API is sometimes not the one that is easiest to use but most difficult to misuse.