Baumethode der Basemap

Was hier geschuldet ist — und was nicht

Die ODbL regelt Daten, nicht Gestaltung. Geschuldet sind deshalb genau vier Dinge: die Kennung der Quelldaten samt ihrem Stand, die Fassung des Bauwerkzeugs, die vollständige Bau-Konfiguration einschließlich der Tag-Negativliste, und derjenige Code, der Geometrie oder Attribute verändert. Alles davon steht auf dieser Seite und auf ihren Unterseiten.

Nicht geschuldet und deshalb nicht hier: der XAPE-Objektbestand, der Betriebs- und Auslieferungsteil, der Kartenstil samt Farben, Icons und Signaturen, und der Anwendungscode. Der Grund ist nicht Zurückhaltung, sondern der Gegenstand der Lizenz. Ein Kartenstil sagt, wie ein Hafenbecken aussieht, nicht welche Hafenbecken es gibt; er verändert die abgeleitete Datenbank nicht und wird von Ziffer 4.6 nicht berührt. Für den Anwendungscode gilt dasselbe: er liest die Kacheln, er baut sie nicht.

Die Grenze ist an einer Stelle bewusst überschritten. Die beiden Prüfprogramme unter „Programme" sind nach 4.6(b) nicht geschuldet, weil sie weder Geometrie noch Attribute verändern. Sie stehen trotzdem hier, weil sie der Entlastungsbeweis dafür sind, dass der Ausschluss kategorisch erfolgt ist und nicht als vergleichender Abgleich gegen OpenStreetMap.

Quellen und ihre Lizenz

Das erzeugte Archiv ist damit eine abgeleitete Datenbank im Sinne der ODbL. Es trägt die Attribution in seinen eigenen Metadaten, und der letzte Schritt des Baus bricht ab, wenn sie dort fehlt — sie ist eine Lizenzpflicht, kein Zierat.

Stand der Quellen

Welcher Stand der Welt in den Kacheln steckt, beantwortet keine Prüfsumme, sondern die Replikations-Sequenznummer. Planetiler schreibt sie in die Metadaten des Archivs; über den Replikationsdienst von Geofabrik lässt sich derselbe Auszug auf genau diesen Stand zurückführen.

Lauf vom

15. August 2026

OSM-Auszug

germany-latest.osm.pbf

Größe

4 818 596 428 Byte

last-modified

15.08.2026 02:44 GMT

OSM-Replikationsstand

2026-08-14T20:21:03Z

Replikations-Sequenznummer

4877

Landpolygone

land-polygons-split-3857.zip, 949 122 982 Byte

Prüfsummen der tatsächlich benutzten Dateien (SHA-256)

Die beiden Polygon-Quellen hängen an Adressen ohne Fassungsnummer. Für sie ist die Prüfsumme oben der einzige Pin.

Die von Geofabrik angebotene .md5 taugt nicht zum Pinnen. Am 15. August 2026 nannte und prüfte sie einen Auszug vom 24. Mai, während die ausgelieferte Datei vom 15. August war; der Download war vollständig und gültig, die Prüfsumme wich trotzdem ab. Festgehalten wird deshalb die eigene Prüfsumme der tatsächlich benutzten Datei.

Werkzeug

Das Konfigurationsformat des Bauwerkzeugs ist vom Hersteller ausdrücklich als instabil markiert. Die Fassungen sind deshalb gepinnt: ein Lauf mit anderen Fassungen ist ein anderer Lauf.

Der Weg von den Quelldaten zu den Kacheln

Der ganze Vorgang steht unten als ein Skript (werkzeug/bau.sh) und läuft in sechs Schritten. Ausgabegebiet ist die Deutsche Bucht: --bounds=6.0,53.2,9.9,55.3. Ein vollständiger Lauf dauerte am 15. August 2026 drei Minuten und siebzehn Sekunden auf 32 Kernen mit 62 GB RAM und -Xmx32g; der einmalige Download der Quellen von rund 5,8 GB ist darin nicht enthalten.

1. Schema erzeugen — schema-bauen.py setzt die Tag-Negativliste als exclude_when auf alle 28 OSM-Quelleinträge des übernommenen Schemas. Wo dort schon ein exclude_when stand (fünf Einträge), wird hineingemischt statt danebengesetzt; bei einer Schlüsselkollision bricht der Erzeuger ab.
2. Proben — planetiler verify läuft über 76 Beispiele, bevor eine einzige Kachel entsteht: 67 unverändert übernommene und 9 eigene. Ein Schema, dessen Negativliste nicht greift, soll gar nicht erst bauen.
3. Baulauf 1 — der OSM-Auszug wird mit schema/xape.yml nach xape-osm.pmtiles gebaut. Gemessen: 2 min 04 s, 176 463 930 Byte, 7 468 332 Merkmale.
4. Baulauf 2 — die Landpolygone der OSMF werden mit schema/land.yml nach xape-land.pmtiles gebaut. Gemessen: 1 min 01 s, 806 654 Byte.
5. Merge — tile-join führt beide Kachelsätze zu xape-basemap.pmtiles zusammen, ohne Größengrenze je Kachel (-pk), weil tile-join sonst Merkmale aus dichten Kacheln still verwirft. Gemessen: 12 s, 176 555 232 Byte, 27 Ebenen.
6. Herkunft nachziehen — tile-join überträgt keine planetiler:*-Angaben und setzt type auf overlay. Damit fiele ausgerechnet die Replikations-Sequenznummer aus dem Erzeugnis. metadaten-nachziehen.py holt sie aus dem OSM-Teilarchiv zurück, setzt type auf baselayer und prüft die Attribution nach.

Warum zwei Läufe: die beiden Quellen haben verschiedene Änderungstakte und verschiedene Anforderungen — der OSM-Lauf baut einen Knotenindex über Millionen Knoten, der Landpolygon-Lauf liest ein Shapefile. Getrennt gehalten lässt sich der teurere auslassen, wenn sich nur die andere Quelle geändert hat.

Nicht gemessen und deshalb nicht behauptet: dass zwei Läufe über dieselbe Eingabe bitgleiche Kacheln liefern. Nachgewiesen ist bisher nur die Wiederholbarkeit des Schema-Teils — schema-bauen.sh erzeugt byteweise dasselbe, und planetiler verify läuft 76 von 76 durch.

Die Tag-Negativliste

Nach der Horizontal-Layers-Guideline der OpenStreetMap Foundation gilt für jede Objektart: entweder OpenStreetMap oder eigene Erhebung, niemals beides. Erschiene eine Objektart in XAPEs Kacheln, die XAPE zugleich selbst führt, würde XAPEs eigener Bestand dieser Art share-alike-pflichtig. Die Negativliste schließt solche Objektarten kategorisch aus, bevor die erste eigene Erhebung dieser Art entsteht.

Für die Beta führt XAPE genau eine Objektart selbst: die Marina. Ausgeschlossen ist deshalb genau eine Auszeichnung: leisure=marina. Alles andere bleibt in den Kacheln — pier, dock, ferry_terminal, lighthouse und auch der Hafen (harbour=*, landuse=harbour, seamark:type=harbour), weil XAPE ihn nicht führt. Der Ausschluss ist eng gefasst, und das ist Absicht: eine zu weite Liste ist der teurere Fehler.

Der Ausschluss ist kategorisch, nicht vergleichend. „Wir übernehmen nur, was OpenStreetMap noch nicht hat" wäre das ausdrückliche Negativbeispiel der Guideline. Dass es anders gemacht wurde, ist genau an dieser veröffentlichten Liste ablesbar — sie ist ein Bauteil, kein Dokument.

Das gilt auch seewärts der Küstenlinie. Eine Mole ragt ins Wasser, ein Leuchtturm steht darin, eine Fährlinie verläuft über See — sie bleiben alle in den Kacheln. Der Bau schneidet nichts an der Küstenlinie ab; was die Karte seewärts zeigt, entscheidet der Kartenstil. Ein an OSM-Geometrie beschnittener Bestand darf zu keinem Zeitpunkt entstehen.

Der Nachweis

Ein Scan nach dem Wert marina beweist nichts, und das ist der wichtigste Satz dieses Abschnitts: das übernommene Schema kopiert leisure nicht in die Kacheln, ein Hafenbecken steht dort als kind=water. Der Wert kommt in der Ausgabe deshalb nie vor, mit Liste wie ohne. Nur die Differenz zweier vollständiger Bauläufe belegt die Wirkung.

Geprüft

16 949 Kacheln, 7 405 127 Merkmale, Zoom 0–14

Befund

BESTANDEN

Wirkung der Negativliste

523 Merkmale entfernt

Erhalten geblieben und ausdrücklich gegengeprüft: pier (21 460 Linien, 2 593 Flächen), dock (107), ferry_terminal (649), lighthouse (189). Ohne diese Hälfte wäre die Prüfung auch bei einem leeren Archiv grün.

Erzeugt von werkzeug/kachel-pruefung.py. Das Programm liest PMTiles und Vector Tiles ohne Bibliothek und ohne das Bauwerkzeug, nur mit der Standardbibliothek — ein Beweismittel, das mit dem erzeugenden Werkzeug arbeitet, prüft die Baukette gegen sich selbst.

Ein Archiv mit fehlgeschlagenem Nachweis wird nicht abgelegt: bau.sh entfernt es und bricht ab. Ein liegengebliebenes Archiv ist genau das, was später versehentlich hochgeladen wird.

Abweichungen vom übernommenen Schema

schema/xape.yml entsteht ausschließlich aus schema/shortbread.upstream.yml und den drei Eingriffen unten. Ebenen, Zoomstufen, Attribute und Filter sind unverändert; insbesondere bleibt die Ebene „ocean" aus den Wasserpolygonen erhalten.

• A1 — Die Tag-Negativliste steht als exclude_when an allen 28 Feature-Einträgen mit source: osm. Bei den fünf Einträgen, die schon eines hatten, wird hineingemischt: ein zweiter Schlüssel exclude_when wäre ein doppelter YAML-Schlüssel, und ein Mapping ist in diesem Schema ohnehin ein Oder über seine Schlüssel.
• A2 — schema_name und schema_description: aus „Shortbread" wird „XAPE Basemap", dazu eine Beschreibung, die Ableitung und Ausschluss benennt. Der Name landet in den Metadaten des ausgelieferten Archivs, und ein Erzeugnis, das die Objektarten des Vorbilds absichtlich nicht enthält, darf dessen Namen nicht führen.
• A3 — examples zeigt auf die zusammengeführte Beispieldatei xape.spec.yml statt auf shortbread.spec.yml, damit die 67 übernommenen und die 9 eigenen Proben in einem Zug laufen.

Mit der Betonnung des MVP kommen Objektarten hinzu, die XAPE dann selbst führt — lighthouse, Hafeninfrastruktur, alles mit seamark:-Kennzeichnung. Sie müssen zu diesem Zeitpunkt in die Negativliste, und diese Seite zieht mit.

Wann diese Seite nachgezogen wird

Der Bau ist ein vierteljährlicher Handgriff von Hand. Jeder Lauf, der die Bau-Konfiguration oder den Stand der Quelldaten ändert, zieht eine Aktualisierung dieser Seite nach — sie ist ein Schritt des Laufs und keine Aufgabe danach. Solange die hier gezeigten Dateien und Zahlen nicht zu dem Archiv gehören, das gerade ausgeliefert wird, ist die Offenlegung falsch, und eine falsche Offenlegung ist schlechter als keine.

Rückfallposition

Ziffer 4.6 lässt eine zweite Erfüllung zu: 4.6(a), ein schlichter Download-Verweis auf die abgeleitete Datenbank selbst. Dieser Weg stünde XAPE offen, und zwar unter einer Bedingung, die hier erfüllt ist — das Archiv enthält per Konstruktion nur OSM-Ableitung und keine XAPE-Eigendaten. Ein Download-Verweis darauf würde den Wortlaut von 4.6 vollständig erfüllen, ohne jede Offenlegung von Konfiguration oder Code.

Er ist bewusst nicht gewählt worden. Die veröffentlichte Ausschlussliste ist das Beweismittel dafür, dass der Ausschluss kategorisch erfolgte, und dieser Beweis ist mehr wert als das, was seine Veröffentlichung kostet. Die Rückfallposition bleibt als Möglichkeit protokolliert; fiele die Bedingung je weg — käme also XAPE-Eigenbestand in das Archiv —, wäre sie ohnehin verschlossen.

Die veröffentlichten Dateien

Jede Datei steht unverändert, so wie sie im Bau benutzt wird, mit ihrer SHA-256-Prüfsumme. Wo basemap/WERKZEUG.md eine Prüfsumme veröffentlicht, ist sie danebengestellt; laufen die beiden auseinander, sagt es diese Seite.

Die Dateien sind eine Kopie aus dem Verzeichnis basemap/ des XAPE-Repositoriums, übernommen am 16. August 2026. Sie liegen hier eingebettet und nicht als Verweis auf ein fremdes System, weil eine Offenlegung, die von der Erreichbarkeit eines Dritten abhängt, keine verlässliche ist. (2026-08-16)