This raises a couple of interesting questions.
1. How do you stop someone from finding the actual property location by querying that map a bunch of times and averaging the positions returned?
2. Are there any negative consequences for the people whose property a displaced marker ends up on? For example, if someone is using the map lookup to find the home of a rival gang officer in order to do a drive by attack, and I happen to live down the street, I really don't want that marker showing up on my house.
Rather than a displaced marker, maybe divide the map into rectangular or hexagonal regions, and just highlight the region containing the property.
Back when YikYak was a thing, I was scraping the data for university campus through their API and found that their location data was randomized upon access. This meant that popular posts (they survived for longer) would end up producing pretty accurate location data.
In one case, I confirmed this by walking into the computer lab in the building where the Geography courses were located and asked "who was asking for lab help on YikYak?" and one student sheepishly raised his hand. I helped him and then also gave him a lesson on real world applications of the central limit theorem.
That's definitely plausible: https://splinternews.com/how-an-internet-mapping-glitch-turn...
Or an even simpler, more trivial solution would be to store mangled values next to the true values. Then all of your APIs and services can pick the appropriate value for the circumstance.
To make it more obvious that the data is imprecise, I would also ensure that the mangled geo co-ordinates returned with a minimum number of decimal places. Three decimal places gives you a precision of 50–100 meters, depending on latitude. Four gives you 5-10 meters, which is the most you'd ever need for an approximate house location.
The concern that comes to my mind is the size of the randomisation and whether they factor in the size of surrounding properties. The level of imprecision required in a dense city will have little to no effect on farmland properties. I would dynamically adjust the random amplitude so that the circle of confusion covered a minimum number of properties. At minimum you'd find a database that listed median property sizes for a given postal code/zip code.
https://www.washingtonpost.com/news/the-switch/wp/2016/01/26...
https://splinternews.com/how-an-internet-mapping-glitch-turn...
In those cases there were negative consequences because low-precision markers were not displaced.
If for some reason the data needs to appear random, you have to store a fixed random offset/alternative per point so that there cannot be multiple observations.
If for some reason the data needs to appear randomized between repeated lookups, you need to store a fixed offset/alternative per point and then apply an additional random offset per lookup. Repeated lookups will only leak the (badly) hidden permanently randomized stored alternative.
If people are interested I've included a link on how Tinder keeps your location private. It's really interesting.
https://robertheaton.com/2018/07/09/how-tinder-keeps-your-lo...
The article could have helped answer your question by providing some images to illustrate the flaws with other solutions that the author tried.
https://gis.stackexchange.com/questions/76498/how-is-st-poin...
H3 is similar and cool, but this builds a similar nested grid concept around latitude/longitude, which can map to existing coordinate systems and database storage.
Also note that population density affects how effective a given precision "blur" is for an area; we're also hoping to develop a web service or library to roughly return population density for any given region of the globe.
rand(0,2*pi) for angle, rand(d1,d2) for distance, and then convert from polar coordinates to Cartesian.
Maybe I'm missing something fundamental but it seems more complex than need be, especially for small areas where the distortion of showing a sphere on a Mercator projection is minimal.
edit: Never mind, another comment answered why: This generates a random but not uniform (in area) distribution, because there's a larger circumference (and thus more swept area for a given radial angle) the larger the radius moves out.
> On a previous project we needed to show markers on a map to indicate there was a property, but for privacy reasons we wanted to show the marker on the map close to the property but not at the exact location of the property. So we needed to generate random points within a fixed distance of the original point location.
At those distances, you can treat the surface as a plane and calculate points on a circle. Sure, it won’t be accurate for large distances but that is not a requirement. Nor is accuracy for that matter since the whole point is to obfuscate the original point.
Long rambling version:
The bias in the naive 'solution' is demonstrated in that if we consider a circle of radius 0.5, it has an area of 1/4 that of a circle with radius 1, not half. Which means that as we span our random parameter between 0 and 1, we 'spend too much time' in that small 'inner circle'.
(It's easiest to assume a circle of radius 1, centred about the origin. Nothing interesting arises from additional generality.)
So we don't want the displacement from the origin to rise linearly with the uniform-random parameter. Instead we want the area of our 'inner circle' to rise linearly. Which means that the displacement from the origin should be the square root of the random parameter. (The random parameter's interval will have to be adjusted appropriately of course.)
Our 'theta' has no bias trouble. Transforming from number (angle) into vector/coordinate form, is just routine trig. Nothing interesting to worry about there.
All that's left is to be careful that our theta span the interval [0, 2 * pi) (carefully excluding 2pi), whereas our area should span [0, pi * r^2] (inclusive, assuming that our 'circle' is meant to be an 'open ball' rather than a closed one).
Either we're missing something, or this Haversine business is a needlessly complex answer here.
I considered that another approach might be to define a spiral that 'winds through' all points in the circle, but I'm pretty sure that's not possible. If it were possible, it would give an injective space-filling curve, which is known not to exist. (If it were not injective, it would presumably be biased and so be a non-answer to our question.) Put another way, if your answer involves accepting just one random number, and not two, then your answer is necessarily wrong. (I think I'm getting all this right.) [0]
Another thought: the naive solution is biased despite being injective. Interesting. That seems to be the root of the failure of intuition that leads us to the naive (biased) 'solution'.
[0] https://en.wikipedia.org/w/index.php?title=Space-filling_cur...
This is a bad idea. If you don't randomly distribute points within the entire radius then you've just narrowed the search space for the real location from the entire area in the radius to just a circle around the point you give back.
