DEV Community: Pounce

Licences behind a fictional-data map demo: MIT code, CC0 examples and CC BY place references

Pounce — Sun, 01 Nov 2026 10:01:31 +0000

Pounce Atlas is an open-source explorer for geographic datasets. Its demo data is fictional, but parts of it come from other sources with their own licences. This post separates those licences and gives attribution text you can reuse. It is information, not legal advice.

Disclosure: AI assisted with drafting this post. Pounce prepared it from the repository's third-party notices and licence file.

The short version

Application code and documentation contributed to the repository: MIT licence.
Invented business and venue attributes in the demo files: CC0 1.0.
Place names and approximate centre coordinates from GeoNames: CC BY 4.0. Attribution is required.
Boundary geometry for South Africa: derived from Natural Earth 1:10m admin-1 boundaries, simplified for display. Natural Earth map data is public domain.
Interface font (Inter): SIL Open Font License 1.1.
Three.js: MIT licence.

Attribution text you can reuse

Place centres: GeoNames, CC BY 4.0. Selected South African place references associated with fictional example records; coordinates indicate approximate centres. Boundary geometry: Natural Earth, public domain.

What the MIT licence does not cover

The MIT licence does not relicense third-party assets, production data or trademarks. Pounce's name and marks are not licensed as trademarks by MIT, so do not imply endorsement or an affiliation that does not exist.

Where the fictional examples come from

The two fixture files, public/data/demo.json and public/data/venues.json, contain invented business and venue names, attributes and events. Their town names and approximate centre coordinates come from a GeoNames South Africa extract downloaded on 21 October 2026.

Main dependencies

Three.js 0.186.1 (MIT)
TypeScript 5.9.3 (Apache-2.0), used for build-time type checking
Vite 6.4.4 (MIT), build tooling
Playwright Test 1.62.1 (Apache-2.0), browser QA
@axe-core/playwright 4.14.0 (MPL-2.0), accessibility QA
Lighthouse 13.5.0 (Apache-2.0), performance and quality QA

The notices list all 194 locked npm entries in a machine-readable file, docs/dependency-licenses.json.

Links

Third-party notices: https://github.com/zaiqltd/pounce-atlas/blob/main/THIRD-PARTY.md
Licence file: https://github.com/zaiqltd/pounce-atlas/blob/main/LICENSE
Demo with fictional data: https://pounce.co.za/atlas/

A static Three.js map app: the build and QA checks we run

Pounce — Sun, 01 Nov 2026 09:56:43 +0000

Pounce Atlas is an open-source explorer for geographic datasets. It is a static web app built with Three.js and TypeScript. This post describes the build and QA steps in the public repository, what each one covers, and what it cannot prove.

Disclosure: AI assisted with drafting this post. Pounce reviewed it against the repository's package scripts and test files. The examples are fictional.

Build

npm run build runs TypeScript type checking with tsc --noEmit, then a Vite production build. The project also defines release and private build modes.

Model tests

npm test runs Node's built-in test runner over the model tests in tests/*.test.ts. They cover validation, CSV parsing, activity filters and share state. This suite is separate from the browser tests.

Browser tests

npm run test:e2e runs Playwright Test against tests/browser/atlas.spec.ts. Examples of what those tests check:

A CSV import stays local, escapes markup and disables data sharing.
An invalid import keeps the existing dataset and explains the problem row.
A WebGL failure leaves a working, accessible list.
A failed dataset load recovers with another local fixture.
A phone-sized layout does not overflow, and the detail sheet closes.
The main view and the import dialog are checked with automated accessibility tests using axe-core.

Some browser tests need a private dataset that is not distributed. They are skipped unless an environment flag is set.

Licences for the QA tools

The repository's third-party notices list the QA tools and their licences: Playwright Test (Apache-2.0), @axe-core/playwright (MPL-2.0), and Lighthouse (Apache-2.0), which the notices describe as performance and quality QA tooling.

What these checks cannot prove

Passing tests show that the checked paths behave as the tests expect. They do not prove that a dataset is complete, that an address is correct, or that every browser and device works. Treat them as evidence for specific behaviour, not a guarantee.

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

What 21 model tests check in a static map explorer

Pounce — Sun, 01 Nov 2026 09:56:07 +0000

Pounce Atlas is an open-source explorer for geographic datasets. It runs as a static web app built with Three.js and TypeScript. Its data handling is covered by a Node test file with 21 test cases. This post lists what those tests check, and what they do not prove.

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

How the tests run

The project uses Node's built-in test runner. npm test runs node --experimental-strip-types --test tests/*.test.ts, so the model tests need no separate test framework.

What they check

Validation. Bundled examples must validate as independent datasets. Invalid coordinates are rejected, including a latitude of 91, a boolean latitude, and coordinates supplied on only one side. A duplicate public ID fails before a dataset replaces the current one. An unsupported schema version or a missing name fails.

Private fields. Extra fields such as email or phone are stripped during validation.

Unsafe input. Website values with unsafe schemes, such as javascript: or data:, are rejected, and so are URLs with embedded credentials.

Dates. Impossible calendar dates and malformed date strings fail. A future event must carry an announced status rather than occurred. Date stepping is tested to stay stable across month and year boundaries.

Map rules. A province-only point is not drawn as an exact location. A record without coordinates stays usable in the Industries and list views. An exact map cluster never includes places with similar names.

Activity. Activity date filters are inclusive. Records without events are not counted in activity totals.

CSV import. The parser handles quoted commas, escaped quotes and newlines. It flags an unterminated quote, a duplicate header and a ragged row. CSV imports do not invent coordinates or events.

Local file safety. Imported file content is treated as text and is not evaluated. One test feeds in an HTML image tag with an onerror handler and checks that it stays plain text.

Share links. Share state round-trips Unicode filters and selections without including a data payload.

What the tests do not prove

They check code paths. They do not show that any external dataset is complete, that a record's address is correct, or that an announced event later happened. The methodology explains what the app can and cannot claim: https://github.com/zaiqltd/pounce-atlas/blob/main/docs/METHODOLOGY.md

Test source: https://github.com/zaiqltd/pounce-atlas/blob/main/tests/model.test.ts
Demo with fictional data: https://pounce.co.za/atlas/
Code licence: MIT.

An announcement isn’t an opening: separating event, observation and snapshot dates

Pounce — Sun, 01 Nov 2026 09:34:46 +0000

Disclosure: AI assisted the drafting of this article; Pounce reviewed it against the public Atlas source. Pounce builds Pounce Atlas, an open-source explorer for geographic datasets. Its examples are fictional, and its activity view describes only events recorded in the selected dataset.

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.