A model that can read road markings, storefronts, terrain, and building geometry can help a newsroom verify a piece of footage. It can help an insurance team check where a loss photo was taken. It can help an investigator test a location claim against the visible evidence.
Pair the same capability with face search, persistent identity, live camera feeds, and unlimited bulk access, and the job changes. It stops being place verification and starts becoming surveillance.
That line cannot live in a terms-of-service paragraph nobody reads. It has to be built into the model and the product around it.
Locate scenes, not people
The cleanest safety rule for visual geolocation is also the most useful: the system should answer questions about a scene. Where was this image likely captured? Does it match the location being claimed? What visual evidence supports that conclusion?
It should not answer who is in the image, where that person lives, where they went next, or how to find them. Adding identity does not make a geolocation model more complete. It makes it a different and much riskier system.
Capability is not permission
Two models can produce useful location signals and still need the same hard boundary. The safety layer decides which product paths exist. Verifying a scene can pass. Building a route to identify, find, or follow a person cannot.
Model safety gate
Capability is not permission.
Inputs / policy / outcomes
The two labels in that diagram are deliberately generic, because the boundary does not move with accuracy. Below is the published field on a public benchmark. Every system that reports results can place a large share of ordinary photos inside a 25 km radius, and the same gate applies to all of them.
Benchmark
Placing an arbitrary photo within 25 km
Im2GPS3k · n=2,123 scored of 2,997 · D2 · 2026-05-31
| Model | 1 km | 25 km | 200 km | 750 km | 2500 km |
|---|---|---|---|---|---|
| Orca 1.5Oceanir | 32.2% | 64.3% | 75.7% | 86.1% | 93.3% |
| REVERSEPaper | 22.5% | 48.3% | 59.3% | 73.5% | 84.8% |
| Geo-RPaper | 18.1% | 41.5% | 58.3% | 75.3% | 86.4% |
| GAEA-7BWACV'26 | 8.4% | 36.9% | 56.0% | 73.2% | 85.6% |
| GeoCLIPNeurIPS'23 | 14.1% | 34.5% | 50.6% | 69.7% | 83.8% |
| GeoVistaAgentic | — | — | — | — | — |
| GeoAgentCVPR'26 | — | — | — | — | — |
GeoVista and GeoAgent are listed without numbers because neither publishes results on this set. Those cells are missing data, not zeros.
Built for
- Verifying a stated photo location
- Checking public-interest footage
- Reviewing property and claims evidence
- Ranking locations for a human analyst
Not built for
- Identifying a person in a photo
- Finding a private person or home
- Following someone across images
- Running a persistent location watch
Six standards that belong in the system
Safety is not one filter added after training. It is a set of decisions made from the first dataset through the final API call.
Start with a legitimate job
Define the task before collecting data or training a model. Verifying a claimed location, authenticating disaster footage, and checking whether a loss photo matches an insured property are bounded jobs. Finding where a private person lives is not.
Keep identity out of the model
A place model does not need face embeddings, identity graphs, or a way to match the same person across images. People may appear in a street scene, but their identity should not become a feature, an output, or a hidden index.
Treat precision as a privilege
The most precise answer is not always the safest answer. Start coarse, require stronger evidence for a narrower result, and do not expose unit-level or sensitive-location detail just because the model can produce a coordinate.
Make uncertainty visible
A model should rank alternatives, show contradictory evidence, and be allowed to say it cannot determine the location. A confident-looking pin with no explanation invites overreach and hides error.
Build access around misuse
Authentication, rate limits, monitored API use, scoped workspaces, and review for sensitive workflows are safety controls. Anonymous bulk access can turn a useful model into tracking infrastructure even when the model itself has no identity feature.
Collect and retain less
Training sources should be documented and appropriate for the stated task. Uploaded material should be encrypted, isolated between customers, excluded from training by default, and kept only as long as the workflow actually requires.
Test the abuse case, not only the benchmark
Accuracy on a city benchmark tells you whether the model can geolocate a scene. It does not tell you whether the finished system can be used to track someone.
Before release, teams should test repeated images of the same subject, requests involving homes and sensitive facilities, attempts to correlate results across accounts, extraction of training examples, and automated high-volume use. The question is not only “Did the model answer correctly?” It is also “Should this request have been answerable at all?”
Those tests should continue after launch. Abuse patterns change, customers discover combinations the builders did not imagine, and a safe model can become unsafe when another feature is attached to it. Monitoring and the ability to restrict access are part of the product, not an admission that the product failed.
Keep a person responsible for the conclusion
A geolocation result is evidence for a decision. It should not be the decision. No one should be arrested, denied a claim, exposed, or treated as a threat because a model placed one image near one coordinate.
Good workflows keep source material under the user's control and record the model version, candidate locations, confidence, contradictory evidence, and the reviewer's final judgment. That makes a result challengeable. If a person affected by the conclusion cannot see how it was reached, the workflow is not ready for high-stakes use.
The boundary we hold at Oceanir
Oceanir is built to analyze places, properties, vehicles, and location claims. It is not face recognition, biometric matching, identity resolution, people-search, or a system for locating and tracking private individuals. Those are product boundaries, not missing roadmap features.
We also believe useful geolocation should be inspectable. A result should include alternatives and visible evidence, admit when the scene is weak, and leave the final judgment with the analyst. You can read the exact boundary in what Oceanir is and is not, along with our privacy and security commitments.
A model can be good at geography without becoming good at watching people. That should be the standard.
