Hacker News Reader

Comment by raverbashing | Hacker News Reader

"when MaxMind was first choosing the default point on its digital map for the center of the U.S."

This doesn't make any sense. Why does it need to return a place in the middle of the US when the location is unknown?

This is what it should return: "location is unknown" and absolutely NOT a pair of geographical coordinates

It should just return a precision estimate along with the data. Here's what the ancient (from january 1996) standard for "location" records in the DNS specifies, which in my view is very sensible: https://tools.ietf.org/html/rfc1876

    SIZE The diameter of a sphere enclosing the described entity, in
    centimeters, expressed as a pair of four-bit unsigned integers,
    each ranging from zero to nine, with the most significant four bits
    representing the base and the second number representing the power of
    ten by which to multiply the base. This allows sizes from 0e0 (<1cm) to
    9e9 (90,000km) to be expressed. This representation was chosen such that
    the hexadecimal representation can be read by eye; 0x15 = 1e5. Four-bit
    values greater than 9 are undefined, as are values with a base of zero
    and a non-zero exponent.

    HORIZ PRE The horizontal precision of the data, in centimeters,
    expressed using the same representation as SIZE.  This is
    the diameter of the horizontal "circle of error", rather
    than a "plus or minus" value.  (This was chosen to match
    the interpretation of SIZE; to get a "plus or minus" value,
    divide by 2.)

...so, for a point "somewhere" in the united states, I'd reckon that SIZE=1·10⁰m (1 times 10^0=1m) and HORIZ (and VERT) PRE set to 5·10⁶m (5 times 10^6=5000km) would be a sane choice.

(measuring on google maps, the united states seem to measure about 4500km from east- to west-coast)

This assumes users of the data don't then report the location, and ignore the precision estimate.

> "expressed as a pair of four-bit unsigned integers, each ranging from zero to nine, with the most significant four bits representing the base and the second number representing the power of ten by which to multiply the base. [...] Four-bit values greater than 9 are undefined, as are values with a base of zero and a non-zero exponent."

That is the stupidest data format I have ever heard of...

The precision is in cm, so HORIZ PRE will be 5e8 or 500000000cm = 5000km and VERT PRE is more likely to be around 1e5 or 100000cm = 1km although I'm not sure about this value - maybe 5km or 5e5 would better account for the height variation in the US?

Maybe because the location isn't simply unknown, it's known to be in the US, but not any indication of where in the US.

I'd imagine it's the same as finding the geographic location of a street - often a point on the middle of the street is picked.

Not saying that this couldn't have been handled better though.

Make it the White House, Statue of Liberty or Mount Rushmore, not a private persons house.

It's very common to return the centroid of the matched location (city, state or country).

It's a terrible approach, as it throws off all sorts of algorithms, and has the effect seen above. If you have to return a Long/Lat, make sure that your "Unknown" is something that nobody would ever confuse with being a valid address - North Pole, South Pole, In the middle of some Ocean, Dessert, or Mountain Range - whichever is least likely to be valid for your particularly application.

This makes it much easier for downstream application developers to filter out "Invalid" addresses, and simply eyeballing them on a map makes it clear what the "Invalid" value is.

And of course, nobody has thought of the possibility of including an accuracy radius with the position, so instead of having a point saying "It's here", you have "It's anywhere within this area".

It's the same with site metrics, or sensors in IoT - your measurement isn't X, it's X +/- Y, with some measurement error distribution.

Anyone that's driving out to a farm without checking other data sources will probably just ignore the accuracy radius.

It may be a terrible approach in your view but it's essentially universal and is often the best one. If I ask just about any database for the Lat/Long of some city, it's going to return the location of some approximation for the center of the city--which may be a park, a house, or the middle of a river. It's not going to, nor should it, tell me "invalid question" because the city (or really any address within that city) isn't really represented by a single Lat/Long point.

I've worked on a number of applications, where we need to make a decision as to what the long/lat will be of "Unknown" - and we always pick something that is guaranteed to throw a flag for downstream consuming applications.

Recognizing how your data will be used, and taking some precaution to ensure that it doesn't result in scenarios described in the article is quite often fairly straightforward. (As evidences - The article itself made it clear that when they don't know the actual location, they have changed the long/lat to return a value in the middle of a lake to avoid this sort of problem in the future).

I have not used MaxMind but with another geo data provider in addition to the centroid it returned the shape and the type of match it was (exact address, city, county, state, country,etc...). So you know whether the IP has an exact address match or not. But many application developers probably chose to ignore the complexity as that might be easier.

Not when this has consequences for whomever lives there

"Just send the drones to bomb the centroid of city X" doesn't seem so smart

Or they should have a giant disclaimer on their results saying that their information is subject to errors and it should not be used for legal/law-enforcement purposes

There's always some uncertainty. What do you want it to return when it can tell the location is Springfield, but no further? Will your suggestion actually stop devs from blindly converting into coordinates?

Then it should return both the center of Springfield and an accuracy measurement, like a city boundary. If the act of returning a location is inherently unreliable, then that must be made clear.

That's the current API. Devs ignore the accuracy number.

Return the three points that define the bounding circle.

And then a layer deep in the app that's trying to simplify the world calls a function that calculates the center of that circle. Or averages the points, or returns just the first one, depending on laziness. The mapping world doesn't work in bounding circles, so it gets converted, and it probably gets converted in a way that loses important information.

Or just a point and a radius (a.k.a. an accuracy number).

Three points on the edge is better because it forces the developer to actually think about what he's doing.

Sometimes it seems there is no better alternative, hence the existence of Null Island (http://www.nullisland.com/).

It seems this kind of mistake just keeps cropping up again and again, from api results to programming language features. For some reason, people have this real, buring desire to return something that __looks__ useful, even in the most abject failure case.

If they weren't stuck thinking that the US is the centre of the world, they could've used Null Island as a better default.

It's the default location for US-based IP addresses. Other countries have their own defaults.

Reply on news.ycombinator.com