
GDPR Preferences (TOML, SAMPLE)
SAMPLE consent/preferences TOML for privacy-export parsers.
- File
- TOML · Exports
Find files, editable templates and browser test targets by what you need to make or test. Explore complete business kits for connected records, templates and expected results.
Page 85 of 221; 24 results per page.

SAMPLE consent/preferences TOML for privacy-export parsers.

A small ZIP shaped like a GDPR subject-access export: profile JSON, activity CSV, consents JSON, and a README. All PII is fictional SAMPLE data.

A Bundler lockfile in its indentation-significant block format: specs nested under GEM, transitive requirements nested one level deeper, and the BUNDLED WITH version on its own indented line. Every package, version, hash and licence is fictional: the tree describes nothing real.

Every interval written in both coordinate conventions with its length, which is identical either way. It is the lookup table for the most common bioinformatics off-by-one, and the length column is what proves a conversion did not quietly change an interval's size.

RFC 7946 permits `"geometry": null` for a feature with attributes but no location. Readers that assume every feature has coordinates crash here, and writers that emit an empty Point instead corrupt the record's meaning.

A single Feature whose geometry is a GeometryCollection of a Point, a LineString and a Polygon. Many simple readers flatten or silently drop these, and many writers cannot produce them at all, so it is the usual place a conversion loses data.

A one-feature FeatureCollection holding the four-vertex Coast Road, so a reader can be exercised on LineString in isolation. Coordinates come from the Kestrel Bay territory, so the same shape appears again in every other format in this category.

A one-feature FeatureCollection holding all three roads as one geometry, so a reader can be exercised on MultiLineString in isolation. Coordinates come from the Kestrel Bay territory, so the same shape appears again in every other format in this category.

A one-feature FeatureCollection holding three harbour buoys, so a reader can be exercised on MultiPoint in isolation. Coordinates come from the Kestrel Bay territory, so the same shape appears again in every other format in this category.

A one-feature FeatureCollection holding the three parcels as one geometry, so a reader can be exercised on MultiPolygon in isolation. Coordinates come from the Kestrel Bay territory, so the same shape appears again in every other format in this category.

A one-feature FeatureCollection holding a single position, so a reader can be exercised on Point in isolation. Coordinates come from the Kestrel Bay territory, so the same shape appears again in every other format in this category.

A one-feature FeatureCollection holding a simple four-corner parcel, so a reader can be exercised on Polygon in isolation. Coordinates come from the Kestrel Bay territory, so the same shape appears again in every other format in this category.

A one-feature FeatureCollection holding a parcel with a courtyard cut out of it, so a reader can be exercised on Polygon in isolation. Coordinates come from the Kestrel Bay territory, so the same shape appears again in every other format in this category.

A GeoJSON FeatureCollection with a point, a line, and a polygon, for testing map tools and geo importers.

Intentionally invalid: the file is perfectly good JSON but the coordinates are quoted strings, which RFC 7946 does not allow. It is exactly what a CSV-to-GeoJSON script produces when it forgets to cast, and a permissive reader will coerce it and hide the bug.

Intentionally invalid: the second ring is a whole separate parcel filed as an interior ring of the first, which OGC Simple Features forbids. It is what happens when a MultiPolygon is flattened into a Polygon by concatenating rings.

Intentionally invalid: the five towns with their coordinates written latitude-first. RFC 7946 fixes the order as longitude then latitude, and this is the mistake that arrives via an EPSG-URN-ordered source such as the GML twin in the territory subcategory.

Intentionally invalid: latitude 95, five degrees past the north pole. This is the value that appears when longitude and latitude have been swapped somewhere upstream, so catching it early usually finds an axis-order bug rather than a data-entry one.

Intentionally invalid: a point at longitude 200. It is a plausible-looking number that usually comes from adding an offset without wrapping, and it survives JSON schema checks that only test for `number`.

Intentionally invalid: a ring of three positions that closes back on itself and therefore encloses nothing. RFC 7946 requires at least four positions for a linear ring, and this is the shape a simplification pass produces when it over-thins a small polygon.

Intentionally invalid: a bowtie ring whose two lobes wind in opposite directions, so the shoelace areas nearly cancel. Buffer, intersection and area operations on this geometry return nonsense rather than failing, which is why it belongs in a validation suite.

Intentionally invalid: the parcel's exterior ring omits the repeated closing position that RFC 7946 requires. Many readers close it silently, which hides the producer's bug until a stricter consumer downstream rejects the data.

Intentionally invalid: Web Mercator metres inside a file that claims to be GeoJSON, with a legacy `crs` member as the only hint. RFC 7946 allows exactly one coordinate system, so this file is what a desktop GIS produces when someone exports a projected layer to GeoJSON without reprojecting it first.

The same transect cut at the 180th meridian into a two-part MultiLineString, which is what RFC 7946 section 3.1.9 recommends. The split latitude is the linear interpolation of the unsplit twin, so the two files describe the same ground path.
We use Google Analytics and show ads via Adsterra. Non-essential cookies and ad scripts run only after you allow the matching categories. See our cookie policy.