How this platform works

Every panorama on this site was captured in the field by our team, processed on our own servers, and is served from our own servers. The base map is generated from open data and hosted as a single static archive, so loading a page here never calls Google, Mapbox, or any external mapping service.

That independence is not ideological. It means your imagery is not sitting in a platform that can change its terms, raise its prices, or decide your listing no longer fits its plans. What we shoot for you stays under our control and yours.

People walk through the places we photograph. Before anything is published, faces and vehicle number plates are obscured in a way that cannot be reversed — the blurred pixels replace the originals in the published image, rather than being layered over them.

Automated detection does the first pass. A person then reviews the result: drawing over anything the software missed, and clearing anything it flagged wrongly — the carved faces on temple reliefs, for instance, which detectors reliably mistake for people. Both directions matter. Software alone over-blurs cultural sites and under-blurs anyone looking away from the camera.

Original unedited captures never appear on the public site in any form. They stay in private, access-controlled storage, and every thumbnail, preview and full-resolution view a visitor can reach is generated from the anonymised version.

Imagery is backed up off-site and encrypted before it leaves the server, so the backup provider never holds anything readable. The published versions are reproducible from the originals, which means the archive can be rebuilt rather than merely restored.

Backups are tested rather than assumed. A drill restores the database into a throwaway copy and checks a sample of original panoramas byte-for-byte against the checksums recorded when they were first ingested — because a backup nobody has read back is a hypothesis, not a safety net.

The map itself is a dated snapshot of OpenStreetMap. A stale one renders perfectly and is simply wrong, so its age is tracked and refreshed deliberately rather than left to drift.

The same principle runs through the admin generally: the checks report what is outstanding, and they distinguish a measurement from an estimate rather than presenting both as fact. A number that cannot say which kind it is has no business next to a decision.

This is a live platform and it is still growing. Currently planned:

• Client accounts, so organisations can manage their own places directly — staged listings, blur approval, share links and metrics for their own places only. The failure mode is one client seeing another's unpublished imagery, so it will not be rushed.
• Junction and loop walkthroughs. Routes are built automatically from a GPS track, which covers a road or a trail end to end; forks and intersections still need linking by hand.
• View counts, so a business can see how often its place is actually being explored.
• Two-factor authentication on the admin, which is currently restricted at the network layer instead.

Recently finished: several walkthroughs per place, level horizons corrected from the camera's own sensors, light and dark modes, smoother panning on phones, and optional watermarking.

This site runs on Bayon Atlas, a 360° mapping and virtual tour platform built by Bayon Shield Co., Ltd. Everything described on this page — the capture pipeline, the anonymisation, the self-hosted map, the walkthroughs — is the platform itself, not something assembled for one website.

Bayon Atlas is approaching beta and will be available to license for organisations wanting to run their own 360° coverage on their own infrastructure. Licensing and API access are still ahead of us, so there is nothing to sign up for yet — but if it sounds useful, we would like to hear from you.

Our 360° cameras write dual-fisheye frames — two circular images side by side, not yet a panorama. Those files normally have to go through the manufacturer's phone app or desktop software to become anything usable.

We skip that entirely. Cards go straight into the uploader and the stitch happens on our servers using FFmpeg's v360 filter, projecting dual-fisheye to equirectangular in a single pass. No phone round-trip, no vendor SDK, no cloud processing service, and nothing to license. GPS coordinates, capture times and orientation data are carried across with ExifTool, and the result is stamped with the standard photo-sphere XMP metadata so it is a valid panorama to anything that reads it.

The original camera file is kept untouched. Because the conversion is deterministic, a better stitching approach later can simply be re-run against the same originals.

A capture run is not one panorama, so a whole card's worth of files can be selected at once and each becomes its own scene, kept in capture order. If a file carries no GPS fix, the scene takes its Place's position so that it still appears on the map — recorded as approximate, never mistaken for a survey.

The point directly below the camera — where the tripod and the photographer's feet are — can carry a logo, chosen per place or per scene. It is applied to the published imagery, not to the originals, so it can be changed or removed later without touching the capture itself. It is branding and nothing more: anything that genuinely needs to be hidden is blurred, permanently, before publication.

Detection and redaction are deliberately separate steps. A panorama is first projected into two dozen overlapping perspective views — running a detector directly on an equirectangular image works poorly, because faces near the top and bottom of the frame are severely distorted. YOLO-family models run across those views, and the resulting boxes are mapped back onto the sphere as polygons.

Those polygons are then an editable list rather than a finished result. An operator adds regions the detector missed and dismisses the ones it got wrong; dismissals are remembered, so re-running detection never resurrects a decision someone already made. Only once that list is settled is it burned into the pixels, with pixelation followed by a Gaussian pass under a feathered mask.

Because the published image is a deterministic function of the original plus that region list, it can always be regenerated — which is what makes it safe to change output resolutions or rebuild derivatives later without touching the source material.

A Laravel application on Debian and nginx does the heavy lifting — ingestion, processing queues, publishing controls and the APIs feeding the maps — with PostgreSQL and PostGIS as the single source of truth and Valkey running background jobs. Original captures sit outside every web-server route and are reachable only through an authenticated allow-list, so there is no URL that serves an unedited file.