What your IT needs to know.

Integration paths

pixel.map ships as a TYPO3 extension for the current long-term-support (LTS) versions of TYPO3 — which ones exactly is in the developer documentation — and then appears as its own content element "Map", which editors place on a page like any other content.

What the map shows, editors assemble themselves in the backend: content types, categories and individual places, tours or events, chosen from the data of their own destination. The preview in the page module summarises the settings and warns when a value no longer fits — a category, say, that no longer exists in the destination data.

For websites with their own frontend (headless), the same extension delivers the finished map configuration as JSON, and the frontend assembles the map from it. Editors work exactly the same way.

For Astro sites there is a component: one line in the page and one in the Astro config, which switches on the worker wiring. The map loads only as it approaches the visible area, and without JavaScript a notice appears instead of an empty box. Any other site embeds the map as a single tag. The tag is all it takes: bundle, worker and map are served from our host. If you bundle the package into your own frontend, serve the worker file from the same origin as the bundle and keep MapLibre within the version range the package declares.

Installation and first setup are done once by your agency or IT — the extension comes from a private registry, not from the public TYPO3 repository. This is integration work, not one line of HTML, and releases are announced. After that, your editors maintain the map themselves.

Embedding in a CMS or framework — developer documentation (Opens in a new tab)

This is what embedding this map looks like in Astro — generated from the same configuration the map in the next section loads:

// astro.config.mjs
import pixelmap from '@pixelpoint/pixelmap-astro/integration';
export default defineConfig({ integrations: [pixelmap()] });

// src/pages/karte.astro
import PixelmapWidget from '@pixelpoint/pixelmap-astro/PixelmapWidget.astro';
<PixelmapWidget
  configUrl="https://maps.pixelmap.at/demo/config.json"
  ctaHref="https://maps.pixelmap.at/demo/?lang=en"
  poiIds={[
    "dc65d7f5-4002-4fa7-a969-d264f00b0eaa",
    "307a0fcf-c225-47ea-9514-f32735f7a2e4",
    "ceb22f66-dd0a-4c44-89d9-f9cd19e7ed51",
    "da857dad-74ee-483f-b1f2-8a12456be495",
    "6ec485eb-88f3-4110-b802-892ba4929d62",
    "c9d01fb9-1fa3-4912-b48c-22782e0a8d5f",
    "efbe56be-0627-494a-ae9f-8014f4f8c2ae",
    "c216d066-c32c-420e-8f28-84a2a1f158f9",
    "15b5e048-d0a4-45b3-9356-3dc2e1270fc1",
    "d2442a6c-8847-42b0-8b44-c0cc693895b2"
  ]}
  interactive={false}
  reveal="fly-in"
/>

What the map costs your page

No number on this page is written down. The map below is a real embed over the same path your site would take; open it and your browser measures what it loaded and shows it here. Before the click, the map loads nothing.

Two lines, because two origins: the map code comes from this site and can be measured exactly. Configuration, data and symbols come from our servers — your browser can only show their size once the server allows measuring; until then there is a dash, not an invented zero. The map tiles themselves are fetched by a background process this page cannot measure — we say so rather than invent a number.

Hosts, cookies, consent

The map talks exclusively to hosts under pixelmap.at — the list above is measured, not claimed. It sets no cookies and uses no browser storage.

That is why it needs no consent. Do not put it behind your consent banner: on customer sites the banner otherwise covers the map for no reason. For your GDPR review this means: no cookies, no consent, and the map talks only to the hosts named here.

Where the content comes from

Your content stays in dataCycle — one editorial home, not two. Map and result list are synchronised hourly; when a guest opens a destination, pixel.map fetches its details at that moment. There is no export, no import and no second place to maintain.

When something is wrong

In TYPO3 your editors see it first: the preview in the page module warns when a setting no longer matches the data. That is a help, not a guarantee — this warning requires the destination data to be in the cache already.

If the map cannot load its configuration, it shows a message instead of an empty area. If tiles fail to arrive after loading, it reports that too — once, after a short grace period — and this site then shows the image with a note instead of the map. If the data fails to arrive, the same applies.

Updates

The widget is versioned. New versions are announced and never arrive unasked. On sites with their own frontend, your frontend decides when a change reaches the guest — not we.

Every entry in our news says what you need to do, if anything.

Several brands from one build

One build, one configuration per tenant, one deploy chain. A destination with several brands gets several maps from one source — each with its own logo, accent colour and domain, all on the same data.

Accessibility

This website meets WCAG 2.1 AA. The widget is a visual complement, and we say exactly what it can do: reachable by keyboard are the map itself — arrow keys and plus/minus pan and zoom —, the attribution button, the button to the full map and, in an open popup, its close button.

Not reachable are markers and clusters; popups cannot be opened by keyboard. That is why everything the map shows is also on this site as text — and why we claim no WCAG level for the widget itself.

What is not on this page

Endpoints, parameters and limits are deliberately not here but in the developer documentation.

developer documentation (Opens in a new tab)