Random Geographic Coordinates

Picks random (lat, lng) pairs using crypto.getRandomValues. The default "uniform on sphere" mode samples by the sine of latitude — a flat latitude pick would over-sample near the poles since each degree-band covers less surface area there. Bounding boxes that wrap across the antimeridian (e.g. Pacific-spanning) are handled, and each result links straight to OpenStreetMap to inspect.

The difference between the two modes is larger than it sounds. Drawing latitude uniformly from -90 to 90 puts as many points in the band between 89 and 90 degrees as between 0 and 1, even though the first covers about a nine-hundredth of the area of the second. Sampling by the sine corrects this, and the visible result is that points stop clustering at the top and bottom of the map. Longitude needs no correction, because meridians divide the sphere into equal wedges at every latitude.

Because the sampling is uniform over the surface, roughly seven in ten points land in water, and many of the rest fall in desert, ice or forest. That is the correct behaviour for a geographic sample, not a defect, but it makes the tool a poor fit for generating plausible user addresses or test data that has to resemble where people live. Population-weighted sampling is a different problem and needs a population raster.

The coordinates are decimal degrees on WGS 84, the datum GPS and web maps use, printed at six decimal places, which is about 11 centimetres at the equator and less as you move poleward. That precision is an artefact of the formatting rather than a claim about accuracy. One further caveat: a bounding box drawn by dragging a rectangle on a Mercator map is not a rectangle on the sphere, so a box that looks balanced on screen still covers more ground at its equatorward edge.