Disclosure: AI assisted with drafting this post. Pounce reviewed it against the public browser test file. The examples are fictional.

The problem

If the WebGL canvas cannot start, a map-only interface shows nothing useful. Records should still be reachable as a list, and the controls should still work with a keyboard.

What the browser tests check

The browser tests use Playwright Test. Among them, these checks cover the fallback and related behaviour:

• A WebGL failure leaves a working, accessible list of records.
• A failed dataset load recovers with another local fixture, so the page does not stay empty.
• A phone-sized layout does not overflow, and the detail sheet can be closed.
• Menus are opaque, and keyboard selection works.
• Changing datasets stops playback and resets selections, so an old selection does not stay on screen.
• The main view and the import dialog are checked with automated accessibility tests using axe-core.

Why a list matters

A list gives people a second way to read the same records. It also makes the data easier to check: names, categories and locations can be read as text without a 3D scene.

What these tests cannot prove

They show that the checked paths behave as the tests expect, on the configurations that were run. They do not prove that every device, browser or assistive technology works. Some browser tests also need a private dataset that is not distributed, so they are skipped unless an environment flag is set.

Browser test source: https://github.com/zaiqltd/pounce-atlas/blob/main/tests/browser/atlas.spec.ts Repository: https://github.com/zaiqltd/pounce-atlas Demo with fictional data: https://pounce.co.za/atlas/

Disclosure: AI assisted with drafting this post. Pounce reviewed it against the public README, data contract and tests.

What happens to an imported file

According to the README, the Import feature loads a compatible CSV or JSON file in the browser. The imported contents stay on that device in the current page, and no server import service is part of the application.

Share links

A share link preserves a view of a built-in dataset. A share link never uploads a locally imported file.

Events and CSV

CSV imports do not create activity events. If you need dated events, use JSON with correctly dated events.

Rules that still apply to your data

• Use precision labels honestly: exact, town, province or unknown. A town label means an approximate town centre.
• Do not invent coordinates for a missing location. Leave both coordinate cells empty when the location is unknown.
• A town or exact record needs both latitude and longitude. Numeric strings from CSV are accepted, and boolean coordinates are rejected.

The data contract has the full rules: https://github.com/zaiqltd/pounce-atlas/blob/main/docs/DATA-CONTRACT.md

What the parser is tested for

The CSV parser handles quoted commas, escaped quotes and newlines. It flags an unterminated quote, a duplicate header and a ragged row. Imported file content is treated as text, not as code.

What this does not cover

The app does not verify that you have the right to use a dataset, and it does not check that addresses are correct. Check licences and consent for your own data before you import it.

Repository and README: https://github.com/zaiqltd/pounce-atlas Demo with fictional data: https://pounce.co.za/atlas/

A map can make a date look more certain than the evidence behind it. A marker appears, a timeline gains an entry, and a reader may infer that a business opened or expanded on that day. But a dataset often carries several different clocks: when an event happened or is planned, when a record was checked, when a snapshot was generated, and the cutoff through which a source was considered. Collapsing those into one date turns evidence about the data into a claim about the world.

Atlas keeps these meanings separate in its public data contract.

Four dates, four questions

Event date (events[].date) asks: when is the described event dated? It is an ISO calendar date for the event itself. The accompanying status says whether that event is occurred or announced. An announced opening scheduled for a future day is still an announcement, not a completed opening. Preserve that status instead of converting a plan into a fact.

Record check date (checkedAt) asks: when was this record checked? It is a record-level observation about review, not proof that every field was independently reverified. A recent check date does not move an older event forward in time.

Snapshot generation time (generatedAt) asks: when was this dataset file generated? It describes the build of a particular snapshot. Regenerating a file can update this timestamp even when a record was not checked that day and no event occurred then.

Source cutoff (sourceAsOf) asks: what source period does the dataset claim to cover? It is a declared source cutoff, not a blanket assertion that all records were checked at the cutoff. The contract explicitly warns against that inference.

There can be other dates too. A source page’s publication date, the first time a collector fetched it, and the first time a team noticed an event are not interchangeable with those four fields. If they matter, keep them distinct and define them. Do not silently substitute one for another.

A fictional example

Imagine a clearly fictional business called Harbour Lantern Works. A source note dated 18 October says it has announced a second workshop for 1 February next year. A researcher checks the record on 20 October. The dataset’s source cutoff is 25 October, and the file is generated on 26 October.

A careful record could retain the planned event date as 1 February and set its status to announced; it could record checkedAt as 20 October, sourceAsOf as 25 October, and generatedAt as the actual snapshot-build timestamp on 26 October. The source note’s 18 October publication date remains separate if the dataset stores it. The company and dates here are invented to illustrate the schema, not claims about a real business.

A reader should be able to tell that the item is a future plan reported in a snapshot, not evidence that the workshop is already open. If the source only says “early next year,” do not invent a precise day. The Atlas contract says to leave an uncertain event out of a precise dated timeline until it has been checked.

Keep geography and absence honest too

An event has no coordinates in this schema. Its optional locationLabel is text for context; it does not locate the event at a company’s headquarters. The dataset may locate a record at town precision, but that is not an event coordinate or a verified street address. Don’t copy the record’s map point onto an event as if the event happened there.

Likewise, an empty activity view has a narrow meaning. Atlas filters Activity to records with a matching event in the chosen range and filters. If no event matches, the result is “no matching event recorded in this selected snapshot and range.” It is not proof that nothing happened. The methodology notes that a quiet area can reflect incomplete collection, and that Map or Industries may still show records absent from Activity.

Make the distinction executable

The public validateDataset implementation checks event dates and statuses, and rejects a future event marked occurred. The model tests exercise invalid calendar dates, require a future event to be announced, and check that Activity date filters include matching dates while records without events do not enter Activity counts. I ran npm test in the public source checkout for this article: 21 tests passed, 0 failed. That is evidence about the checked code paths, not proof that any external dataset is complete or that an announced event later occurred.

The lesson is simple: event time describes the event; check time describes observation; generation time describes the file; and source cutoff describes the declared coverage boundary. Keep those clocks visible, carry announced through the interface, and treat no match as a limit of the selected data rather than a claim about reality.

Explore the live Pounce Atlas demo using its fictional examples, or inspect the MIT-licensed application source, data contract, methodology, and model tests. Application code is MIT licensed; data and map/font assets have separate notices.

This walkthrough uses Pounce Atlas, an open-source geographic dataset explorer from Pounce. The example below is entirely fictional. It demonstrates two records located only to a town and a third with no location, rather than presenting a real business directory.

1. Make location precision explicit

Save this UTF-8 text as atlas-fictional-import-example.csv:

name,sector,trade,town,province,lat,lon,precision,website
Example Workshop,Manufacturing,Metal fabrication,Johannesburg,Gauteng,-26.20227,28.04363,town,https://example.com
Example Studio,Creative services,Design,Johannesburg,Gauteng,-26.20227,28.04363,town,
Example Remote Team,Professional services,Consulting,,,,,unknown,

The two Johannesburg rows deliberately share an approximate town-centre coordinate. That does not imply they share a building or have a business relationship. The town reference follows the GeoNames-attributed example in Atlas's data contract.

The remote team's town, province and coordinate cells are empty. Its precision is unknown. There is no fabricated location to make the map look complete.

Use the exact header names. Quote cells containing commas or newlines, and double any literal quotes inside a quoted cell. website is optional; the example.com address is a placeholder, not a real organization website. Avoid spreadsheet formulas as field values.

2. Import and check the list before the map

Open the demo, choose Import data, then Choose a CSV or JSON file and select the file.

For this sample, the expected result is:

• 3 listings in the list.
• 2 located listings on the map.
• 1 unlocated record retained in the dataset.
• Three industry categories, each containing one record.
• A Local file label and Snapshot date not supplied notice.

This three-row file was checked against the live demo with those results. Keeping the unlocated record in the list matters: missing geography should not silently remove an entity from the dataset.

3. Treat precision as a constraint

Atlas's contract supports four precision values:

• exact: the relevant premises have actually been established and are suitable for the intended use.
• town: an approximate town centre, not a verified address.
• province: only the province is known.
• unknown: geographic precision is unavailable.

The importer normalizes province and unknown coordinates to null. A town or exact record needs both latitude and longitude. Numeric strings in CSV are accepted, but passing validation does not verify an address. The current South African base map also means globally valid coordinates are not automatically useful for this particular interface.

4. Use JSON when dates and provenance matter

The CSV format has no event or snapshot-license columns. Use the documented JSON envelope when you need stable record IDs, dataset versions, attribution, reuse terms or dated events.

In particular, an event's date is not the day a row was imported or first discovered. An announced opening is not a completed opening. If the date is uncertain, do not manufacture a precise timeline entry.

The importer currently limits files to 10 MB and datasets to 50,000 records. Those are validation limits, not a performance benchmark or a recommendation to start with the largest possible file.

5. Understand what sharing does not do

Imported files are processed in the browser. Atlas has no import endpoint or remote geocoding service. A view URL does not carry an imported file's rows to another person; they need the file themselves. Built-in demonstration datasets have a separate shareable-view workflow.

Before publishing a dataset elsewhere, verify its actual redistribution rights, field allowlist and privacy implications. Successful parsing is not publication permission.

The source repository and data-contract documentation are available for reuse and inspection. Application code is MIT-licensed; map references, place data and fonts retain their separate notices. The released business and venue examples are fictional, not production Pounce data.

Written with AI assistance and checked against the v0.1.0 data contract and a live three-row import.