No platform dependency
Imagery is not held by a vendor who can change terms, raise prices or delist you. Map, tiles, viewer and imagery are all served from the operator's own server.
Pre-1.0 · in active development
Self-hosted mapping platform
Capture, Process and Publish 360° Imagery on Your Own Infrastructure.
Bayon Atlas handles street-level coverage, virtual walkthroughs of buildings, and place pages for the businesses inside them. No third-party map API, no imagery leaving the server, no per-request billing, and nothing that can change its terms.
The reference installation is maps.bayon360.com, operated by Bayon360 — a subsidiary of Bayon Shield Co., Ltd — covering Cambodia. It is both the live demo and the proving ground: everything described on this page is running there.
What it is
One Installation, Under One Operator's Control
Most immersive mapping runs on someone else's platform, at someone else's prices, under someone else's terms. Bayon Atlas is the opposite arrangement: it runs entirely on infrastructure the operator controls, and the base map is generated from open data and served as a single static archive from the same box.
Nothing meters a page load
No API keys, no per-request billing, and no third party learning where visitors look. Pages never call an external mapping service.
Privacy before publication
Faces and plates are obscured before an image can go public, reviewed by a person in both directions, with a visible reporting route for whatever still gets through.
Ordinary hardware, ordinary cameras
Consumer 360° cameras and CPU-only processing, with a configurable CPU budget so heavy background work leaves room for the site it is serving.
Verified rather than asserted
Privacy invariants are checked against live data by a command that can gate a deployment. Backups are proven by a restore drill. The site is requested over real HTTP after every deploy. Each exists because the assumption was wrong at least once.
Branded by whoever runs it
Operator name, legal entity, takedown contact, site title, tagline, footer, logo, light-mode logo, favicon and default share card are all set in the admin.
Privacy and anonymisation
Detection Is Automated. The Decision Is Not.
Software alone over-blurs cultural sites and under-blurs anyone looking away from the camera. Bayon Atlas keeps detection and redaction as separate steps so a person settles what actually gets obscured, then burns that decision permanently into the published pixels.
Project, then detect
A panorama is projected into two dozen overlapping perspective views before anything is detected. Running a detector directly on an equirectangular image works poorly, because faces near the top and bottom of the frame are severely distorted. Detection runs across those views and the results are mapped back onto the sphere.
Review in both directions
The result is an editable list, not a finished job. An operator adds regions the detector missed and dismisses the ones it got wrong — the carved faces on temple reliefs, for instance, which detectors reliably mistake for people. Dismissals are remembered, so re-running detection never resurrects a decision someone already made.
Burned in, not layered over
Once the list is settled it is written into the pixels — pixelation followed by a Gaussian pass under a feathered mask. The blurred pixels replace the originals in the published image. There is no version of the published file with the blur removed.
-
Originals stay private
Raw captures sit outside every web-server route and are reachable only through an authenticated allow-list. There is no URL that serves an unedited file.
-
Published images can always be rebuilt
Because the published image is a deterministic function of the original plus the region list, output resolutions can be changed and derivatives rebuilt later without touching the source material.
-
A privacy audit gates publication
It reports blur pending approval, regions drawn but not applied, and derivatives older than the blur they should have been cut from — and blocks publication until the list is clear.
-
Visitors can report a problem on any scene
Pick a reason, describe what to look for, send. No account and no captcha, because someone who has just found their own face in a panorama should not have to prove anything to ask for it to be removed. Reporter IP addresses are never stored.
Getting imagery in
Insta360 Camera Card Straight to Published Scene
Drop an Insta360 card in and the dual-fisheye .insp files are stitched to equirectangular on the server — no Insta360 Studio, no phone app, no vendor SDK, no cloud processing service and nothing to license. It removes the camera to phone to workstation to upload cycle entirely, and it batch-converts hundreds of .insp frames in one pass rather than one at a time. Standard equirectangular JPEG, PNG and TIFF are accepted too.
Clean, seam-free stitching
The two fisheye halves are blended into a single equirectangular sphere with no visible join — including on near objects, where a doorframe or a railing a metre from the lens is the hardest thing to get right. Full resolution is preserved; nothing is downsampled to hide a seam.
Self-levelling that actually is level
Insta360 cameras write a gravity vector into their metadata, so a tilted frame is corrected by a known rotation rather than by guessing a horizon from image content — exact every time, with no failure case on scenes that have no strong verticals. The rotation applied is the minimal one, so your chosen framing survives it and any blur regions already drawn rotate with the image.
Whole-card upload
Select every file from a capture run at once; each becomes its own scene, held in capture order. A file that cannot be read is reported by name and the rest still go through — one bad frame does not discard the batch.
Bulk ZIP import
Hundreds of scenes in one archive, processed in capture order and hardened against path traversal, zip bombs and excessive entry counts. Folder structure inside the archive becomes tours, creating any that do not exist yet.
GPX track import
Timestamp geotagging from a recorded track, with a per-session clock offset for capture runs where the camera's clock drifted.
Work at volume
Bulk actions for visibility, tour assignment, tags, detection, cover regeneration and blur. Sequential navigation between scenes in every editor, so a route is worked through without returning to a list.
Building walkthroughs
Movement That Behaves Like the Place You Are In
A road is not a building, and a walkthrough that treats them the same gets one of them wrong. Bayon Atlas carries the camera differently depending on which it is.
-
Automatic route building for linear captures
Camera heading is derived from the GPS track, then every scene is linked forward and back in one action, so a capture of hundreds becomes a walkthrough without per-scene work. Chains break across implausible jumps and collapse stationary bursts, both configurable.
-
Visual arrow aiming for everything else
Spatial auto-linking handles non-linear sites; where it cannot, you click in the panorama where the next scene actually is. Field GPS is often several metres out, which visibly aims arrows at walls.
-
On a route, your view is carried between scenes
Your heading is corrected through the real-world bearing, so someone watching a river off to one side keeps watching it as they walk, and a curve in the track does not swing them round.
-
Room to room, each scene opens on its own framing
You came through a doorway and turned a corner, and where you were looking a moment ago describes nothing about where you now are.
-
Opening views are set by looking
Drag and zoom to frame what visitors see first, then capture — and it saves, rather than waiting for a separate press. An optional composition overlay marks the thirds, the horizon and the exact centre of the frame: aim the centre line down the route in every scene and forward and back navigation stops swinging as a visitor walks it.
-
Transitions look the same every time
Moving between scenes is a straight crossfade that arrives already framed. The alternative — animating a turn to wherever the next scene happens to be framed — produces a different movement for every step, which reads as instability.
-
Several walkthroughs in one place
A development is one location with parallel things worth showing — the grounds, a studio, a two-bed — not storeys of one building. Each is its own page with its own cover, description, URL and short link, while the place keeps one pin, one set of business details and one entry in search. A visitor can be sent straight to the unit they asked about.
-
A minimap
Shows your position and the scenes around you, on the real map outdoors or on a floor plan indoors. Which one is used is chosen per tour, because a development is genuinely mixed.
Branding the imagery
Your Mark on the Imagery, Applied Properly
Branding is applied to the published imagery rather than the originals, so it can be changed or removed later without touching the capture.
-
Nadir logos
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 from a managed library.
-
Text watermarking, per place
For imagery somebody holds exclusive rights to show — an agency's name across a property it alone is marketing. Off everywhere by default and deliberately without a site-wide switch, because a global setting for something used on one place in fifty is a setting that gets left on.
-
Each copy is rendered on its own tangent plane
Rendered flat, then mapped into the panorama, so it reads as flat text to a visitor. Drawn straight into the equirectangular file instead — the obvious way — it arrives bent: a word laid across the middle bows upward at its ends, and higher up becomes an unreadable arc. The distortion is invisible in an image viewer and unmissable the moment somebody opens the scene.
-
Sized in degrees of arc, not pixels
So the mark is the same apparent size in every scene and at every zoom level. Copies repeat around the horizon and, optionally, in staggered rows. A preview renders one scene into the 360° viewer before the whole place is rebuilt.
For people visiting a map
A Public Experience That Owes Nobody Anything
No account, no sign-up, no cookie wall, no third-party analytics. The landing page is the coverage itself — every public scene as a point, clustered at low zoom — and it works on a phone without an app.
-
A map, not a list
Filters for category, province, capture date and free text are all driven by the query string, so a filtered view is linkable, survives the back button, works without JavaScript and can be crawled. For a page whose entire job is discovery, that matters more than the interaction being instant.
-
Place pages
A business, temple, hotel or public space gets its own page: 360° scenes, a description, opening hours, contact details, amenities, social links, and a map showing exactly where it sits. Search engines are given structured data for the same.
-
Every scene opens on a view somebody chose
Not wherever the camera happened to face. Arriving cold from a shared link or a search result always uses that framing.
-
Light and dark
Follows the system setting until the visitor presses the toggle, then remembers. Resolved before the page paints, so there is no flash of the wrong theme. The map follows the page — the tile archive holds no styling, so both palettes come from the same download.
-
Short links
Every place, tour and scene has one on a dedicated domain, for messaging, print and QR codes. They redirect rather than permanently forwarding, so a destination can move later without the link breaking — which has already been needed twice.
-
Share previews
Generated from the scene's own imagery, framed at its opening view rather than cropped from the raw panorama, so a link looks like the page it opens.
-
Khmer alongside Latin script
Map labels carry both.
Publishing and upkeep
You Can See What the System Is Doing
Outstanding work, indexing decisions, disk cost, backup health and deployment status are all reported rather than assumed.
-
A publishing checklist
Per place and as a dashboard worklist: scenes without GPS, without an opening view, with blur pending or failed, still processing, or unpublished under a live place. Problems affecting visitors now are separated from outstanding work. It knows the difference between a route and a building, so it does not report sixty items of work that do not exist.
-
Naming a scene is what promotes it into search
Sixty frames along one route are near-duplicates competing for a single query, and a search engine resolves that by picking one and discounting the rest. A scene still carrying its camera filename is served
noindexand kept out of the sitemap — reachable, shareable and present in the walkthrough, but not competing. Giving it a title makes it a landing page. There is no second list to maintain: the naming decision is the indexing decision. -
An SEO check
Reports what published pages are missing that search engines and social platforms actually use — places with no share card or nothing to describe them, published places with no public scenes, tags that lead nowhere. Deliberately a separate report from the privacy audit: nothing in it is exposed or broken, and the two lists must never feel alike.
-
Choose how much of the world to host
A continent, a sub-region, the whole planet, or a bounding box of your own. The list stops at continents because countries are two hundred entries and provinces are thousands — anything smaller is four numbers. The disk cost of each is shown before you commit, and figures measured on your own server are labelled as measurements while the rest are labelled as estimates. A guess wearing the clothes of a measurement is how somebody fills a disk.
-
The base map is a dated snapshot
A stale one renders perfectly and is simply wrong, so its age is tracked and flagged. Refreshing downloads, verifies and atomically swaps the archive, keeping the previous one for rollback; the live map works throughout.
-
Backups that are tested, not assumed
Nightly database and media backup to encrypted off-site storage, with encryption client-side so the provider never holds readable imagery. A restore drill restores the database into a throwaway copy, checks the row counts, and verifies a sample of original panoramas byte-for-byte against the checksums recorded at ingest. The panel warns when a backup is overdue or the last drill is too old to mean anything.
-
Every deployment is verified over real HTTP
Public pages, the admin panel booting, media serving, sprite sheets, robots.txt — checked for both status and content, because a blank page returns 200 perfectly well. A failed check fails the deployment loudly rather than reporting success while a page is broken.
-
Host health on the dashboard
Disk, memory, CPU load and stalled jobs, with thresholds reporting how long they have been breached rather than a bare number. Storage is broken down by media type and by place, separating raw originals — which are never served — from the derivatives that are.
What comes next
Roadmap and Coming Soon
Listed because anyone evaluating this deserves to know what is on the way as much as what is already here. None of the following is working today.
-
Google Street View publishing
The mechanism is in place: an operator connects a Google account through OAuth from the admin, scenes are queued to a dedicated worker, each upload carries the scene's coordinates, heading and photo-sphere metadata, the nadir logo is baked into the exported copy so branding survives leaving the platform, and upload status is tracked per scene so a batch can be resumed.
-
Client accounts
Limited, scoped access for the businesses whose places you map — staged listings, blur approval, share links and metrics for their own places only.
-
Junction and loop walkthroughs
Automatic route building covers linear captures; forks and intersections still need linking by hand.
-
Per-scene view counts
With daily rollups, so an operator can show a client how often their place is actually being explored.
-
Full-text search
Across places and scenes. Browsing is currently by map, category and tag.
-
A public API
Documented and versioned for third-party use.
-
Multi-tenancy
One organisation per installation today.
Status
Bayon Atlas is pre-1.0 and in active development. Below 1.0 the shape of the software is still allowed to change; 1.0 is a promise that someone else can install it and rely on it not moving under them, and reaching that is a decision rather than a milestone that arrives on its own.
This page is informational — there is nothing here to sign up for. If you want to see the software rather than read about it, the reference installation is public.