Geolocating a random island using geometry and CUDA programming
yassa9.github.io
August 19, 2026
10 min read
61/100
Summary
A geometry- and GPU-based geolocation process identified Oan resort on an islet in the Federated States of Micronesia as the location in Gralhix OSINT Exercise #004. The islet’s coordinates are 7.363444° N, 151.755750° E, and the camera was determined to face northwest, at a bearing of about 324.97°. The process found no useful EXIF or GPS data in the 736-by-515 WEBP image. It modeled three visible landmasses as a triangle, then searched OpenStreetMap’s 882 MB global land-polygon dataset for matching island configurations. Tropical-latitude, local-density, clustering, geometric, open-water, coral-cay-shape, vegetation, and elevation filters reduced more than 80.69 million candidate island triplets to 26. An NVIDIA GeForce RTX 3050 evaluated the initial 80.7 million triples in 204.1 milliseconds using one CUDA thread per triple, producing 158,784 initial matches. Further checks used Sentinel-2 imagery from Element84’s Earth Search catalog to require a normalized difference vegetation index above 0.6, and Copernicus GLO-30 elevation data to require a low resort islet and nearby terrain between 100 and 500 meters high. Manual satellite-map inspection of the final candidates selected the Micronesian location.
Key Takeaways
- Oan resort was identified on an islet at 7.363444° N, 151.755750° E in the Federated States of Micronesia.
- The image camera direction was calculated as approximately 324.97°, which corresponds to northwest.
- An NVIDIA GeForce RTX 3050 processed 80.7 million candidate island triples in 204.1 milliseconds, with one CUDA thread assigned to each triple.
- OpenStreetMap land polygons, Sentinel-2 vegetation data, and Copernicus GLO-30 elevation data narrowed the search from 80.69 million triplets to 26 final candidates.
- The vegetation filter required NDVI above 0.6, while the elevation filter required the resort islet to be no higher than 50 meters and nearby terrain to reach 100 to 500 meters.
What the discussion said
The thread mostly treated the project as an inventive geospatial-search exercise rather than an AI breakthrough, but the AI-adjacent discussion landed on two practical themes: language models as coding assistants and as interfaces to map data. Readers were impressed by the prospect of pairing Claude or Gemini with OpenStreetMap tools to turn rich spatial descriptions into usable queries. That capability was framed as a major shortcut for OSINT and geolocation work, especially in dense places where roads, utilities, businesses, and building patterns offer far more searchable evidence than an isolated shoreline. The sharper exchange concerned the write-up’s claim of avoiding LLM generation. The author clarified that the narrative and reasoning were written manually, while an LLM cleaned up the final published code after a messier exploratory process. Several readers accepted the clarification, but others argued the original wording blurred an important line: AI-assisted code is still AI-generated material, and readers deserve a clear disclosure. There was also skepticism that this particular island-matching workflow can be fully automated; the author stressed that it depended on manual iteration, failed attempts, and judgment calls. On balance, commenters see LLMs as useful accelerators for geospatial analysis, not substitutes for careful investigation or transparent attribution.
Where opinion split
The central dispute was whether the project could fairly advertise no LLM generation when a language model substantially refined the released code. The author’s case was that the human-authored investigation and explanation were the real work, with AI only polishing code; critics argued that publishing AI-refined code without saying so muddies authorship and weakens the claim.
Community Sentiment
Positives
- Natural-language access to OpenStreetMap data through Claude or Gemini could turn elaborate location clues into queries, making geospatial OSINT far more accessible than hand-built map searches.
- Using an LLM to clean up exploratory code can make a complicated image-to-map workflow publishable and reusable without pretending the first working scripts were elegant.
- The discussion treats AI-assisted mapping as especially promising in populated areas, where structured map features provide much richer evidence than raw satellite imagery alone.
Concerns
- The no-LLM label drew justified pushback because AI-refined published code is still a material model contribution, and readers need that boundary stated plainly.
- Commenters cast doubt on full automation: this geolocation method still relies on human judgment through bad candidates, imperfect map geometry, and trial-and-error filtering.