> 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<p>This raises a couple of interesting questions.<p>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?<p>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.<p>Rather than a displaced marker, maybe divide the map into rectangular or hexagonal regions, and just highlight the region containing the property.
Any random distribution will be leaky when it is centered around the real location and multiple samples can be taken. Quantization to a desired lack of precision is the answer, nobody will be able to tell a point that happens to be rounded to itself from one that happens to be rounded from close to a neighboring cell.<p>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.<p>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 the rationale is privacy this is probably not the algorithm you want to use, especially if it's possible to force the generation of multiple random points (e.g. by refreshing the map). If you're using a circle with a fixed radius just 3 points would be enough to exactly locate the center. A variable radius could take more, but since the distribution is uniform each additional point would significantly improve the precision.
I regularly use this tool (nodejs) for a list of random coordinates inside a country. Or at least inside any country to avoid the oceans. <a href="https://github.com/tsamaya/random-points-generator" rel="nofollow">https://github.com/tsamaya/random-points-generator</a>
Why can't you simply generate two random numbers with one between 0 and 2pi, and the second between the min and max of distance? Now you've got polar coordinates. I'm not sure if I'm missing something or if this is overengineered.<p>If people are interested I've included a link on how Tinder keeps your location private. It's really interesting.<p><a href="https://robertheaton.com/2018/07/09/how-tinder-keeps-your-location-a-bit-private/" rel="nofollow">https://robertheaton.com/2018/07/09/how-tinder-keeps-your-lo...</a>
Buffer your point to create a polygon then use ST_PointOnSurface (or equivalent) in any competent spatially-enabled DBMS to create a point guaranteed to intersect the bounding polygon. Trivial in SQLite, PostGIS, etc.
Leaflet.BlurredLocation <a href="https://github.com/publiclab/leaflet-blurred-location" rel="nofollow">https://github.com/publiclab/leaflet-blurred-location</a> - A Leaflet-based HTML interface for selecting a "blurred" or low-resolution location, to preserve privacy.<p>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.<p>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.
Converting lat/longs to Uber's H3 [1][2] system might prove useful here. Because H3 indexes are hierarchical, you can easily truncate them to obtain less precision. And then convert them back into lat/longs after truncation.<p>[1] <a href="https://github.com/uber/h3" rel="nofollow">https://github.com/uber/h3</a><p>[2] <a href="https://eng.uber.com/h3/" rel="nofollow">https://eng.uber.com/h3/</a>
In practice, would it be easier to just randomly generate points within the bounding box of the radius, and then throw out any points that fall outside of the circle? Wouldn't work too well for the cases where you want points from some radius away, to some radius away, but would probably work well when you just want a random point inside of a given radius since only 1/4 of the points will have to be thrown out.
This is a fine submission but can you please not put "Show HN" on blog posts? This is in the rules: <a href="https://news.ycombinator.com/showhn.html" rel="nofollow">https://news.ycombinator.com/showhn.html</a>.
Over engineered much?<p>> 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.<p>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.