EXPERIMENTELLER Wrapper, der die amtlichen deutschen Vermessungsdaten der Arbeitsgemeinschaft der Vermessungsverwaltungen der Länder der Bundesrepublik Deutschland (AdV) (AFIS–ALKIS–ATKIS-Modell und abgeleitete Produkte) als Linked Data bereitstellt.
Jedes AAA-Objekt trägt einen persistenten
urn:adv:oid:-Identifikator. Dieser Wrapper löst ihn auf:
oid/{oid} liefert das Beschreibungsdokument des Objekts direkt
aus (das Objekt selbst heißt oid/{oid}#f; die Herkunft —
der Upstream-WFS-Abruf — steht als prov:hadPrimarySource im
RDF-Dokument; oid/{oid}.json ist ein einzelnes GeoJSON-Feature,
dessen Herkunft und Lizenz in Link-Headern stehen:
rel="via", rel="license",
rel="describedby"). OIDs unterscheiden Groß- und Kleinschreibung. Die Suffixe
.ttl/.rdf/
.nt/.json/.gml wählen das Format;
Browser bekommen eine HTML-Ansicht (.html) mit der Geometrie
auf einer Leaflet-Karte und wählbaren AdV-Kartendiensten
(basemap.de, TopPlus-Open, DTK250) als Hintergrund.
Beispiele:
Ein Fluss quer durch die Landschaftsmodelle — die Pegnitz in
Nürnberg. Jedes Modell führt EIGENE Objekte mit eigenen OIDs (die
veröffentlichten Produkte enthalten keine modellübergreifende
Ableitung). Gemeinsamer Schlüssel ist die
LAWA-Gewässerkennzahl — gewaesserkennzahl im Basis-DLM,
gwk in den BKG-Modellen. Die Kennzahl ist hierarchisch:
2 Rhein → 24 Main → 242
Regnitz → 2422 Pegnitz:
Alle vier Ebenen an einem Fluss — die Ruhr an ihrer Mündung
in den Rhein bei Duisburg. Für Nordrhein-Westfalen sind Basis-DLM
(Live-WFS des Landes) UND DLM50 (per-Objekt-Dump des Landes) angebunden,
dazu die BKG-Modelle DLM250 und DLM1000 — dieselbe Stelle in vier
Generalisierungsstufen. Gut zu sehen: in Basis-DLM, DLM50 und sogar DLM250
ist der breite Unterlauf eine Fläche (AX_Fliessgewaesser) —
die DLM250-Achse endet schon bei Mülheim, erst das DLM1000
generalisiert die Mündung zur Achsenlinie. Der gesamte Fluss ist das
geometrielose ZUSO-Objekt AX_Wasserlauf (NRW führt die Ruhr als Kette
solcher Wasserläufe) mit der LAWA-Kennzahl 276 — in NRW und bei den
BKG-Produkten 19-stellig aufgefüllt
(2760000000000000000; Bayern schreibt oben kurz
2422 — die Auffüllung ist Ländersache):
zeigtAufExternes-Verweise auf genau die
beiden Basis-DLM-Objekte darüberAlle Ruhr-Wasserläufe auf einmal, statt einzeln per OID — eine bundesweite Attributabfrage ohne BBox, siehe Attributabfrage.
Eine Autobahn quer durch die Landschaftsmodelle — und quer durch die
Länder — die A9 (Berlin–München). Gemeinsamer
Schlüssel ist hier die Straßenbezeichnung
(bezeichnung bzw. bez: A9, Widmung
1301 = Bundesautobahn). Im Basis-DLM trägt das übergeordnete
ZUSO-Objekt AX_Straße die Bezeichnung, die Achse verweist per
istTeilVon darauf — und jedes Land vergibt eigene OIDs
für seinen Abschnitt derselben Autobahn:
bezeichnung "A9", "E51"bezeichnung "A9", "E51")bezeichnung "E51", "A9")bez E51#A9),
DLM250 (BKG)bez E51#A9),
DLM1000 (BKG)Eine Bahnstrecke quer durch die Landschaftsmodelle — hier ist der
gemeinsame Schlüssel die VzG-Streckennummer
(nummerDerBahnstrecke im Basis-DLM, nrb in den
BKG-Modellen; Strecke 5903 bei Nürnberg):
nummerDerBahnstrecke "5903", "5922",
Basis-DLM (Bayern)nrb 5903, DLM250 (BKG)nrb 5903, DLM1000 (BKG)DLM50-Massendaten der Länder — das offene, generalisierte
1:50 000-Vektormodell (ohne Live-WFS) wird als per-Objekt-Dump
bereitgestellt; jedes Objekt ist unter oid/{oid} abrufbar. Objekte
mit eigener Geometrie (REO — Achsen, Flächen, Punkte) zeigt die HTML-Ansicht
auf der Karte; die zusammenfassenden ZUSO-Objekte (AX_Straße,
AX_Wasserlauf) tragen selbst keine Geometrie (sie ist die Vereinigung ihrer
REO-Teile). Beispiele je Land (mit Geometrie):
DLM50 ↔ Basis-DLM (Korrespondenz). Jedes DLM50-Objekt trägt
einen zeigtAufExternes-Verweis
(DLM50derivedFromBasis-DLM) auf das Basis-DLM-Objekt, aus dem es
generalisiert wurde — die einzige modellübergreifende Verknüpfung, die
die Länder selbst behaupten. Wo der Basis-DLM-Dienst des Landes angebunden
ist (z. B. NRW), löst sie beidseitig auf: die DLM50-Wegachse
oid/DENWAT021LC04zCU#f verweist auf ihr
Basis-DLM-Original oid/DENWAT01D0005Lmb#f — hier
liegt derselbe Weg in feinerer Auflösung.
Küstengewässer — die BKG-Verwaltungsgebiete VG250 führen
Nord- und Ostsee als eigene Flächen der Staats-, Länder- und
Gemeindeebene, unterschieden nur durch den Geofaktor gf
(1/2 Gewässer, 3/4
Land); auch der Bodensee ist so ein Gewässer-Objekt. Aufgelöst per
objid-Lookup wie die DLM-Objekte:
vg250_sta,
gf 1)vg250_sta,
gf 1)vg250_lan,
gf 1)vg250_lan, gf 1)Weitere Produkte hinter demselben Länderpräfix — die OID
trägt nach dem Ausgabepräfix einen Produkt-/Stellencode
(AT ATKIS, AL ALKIS, GND
BKG-Geographische Namen, POI BKG-POI), und der längste
passende Präfix der Routing-Tabelle wählt den Dienst:
nnid aufgelöst)poi_id
aufgelöst)DEBE/wfs?s={Dienst-URI}&typenames=adv:{Objektart}[,adv:{Objektart}…]&bbox={W,S,O,N}[&count=&offset=]
liefert AAA-Objekte einer BBox aus GENAU EINEM Dienst — den wählt der
Aufrufer, nicht der Wrapper (Formate: .json .gml .rdf .ttl .nt).
typenames= (auch typename=) nimmt eine
kommagetrennte Liste und darf sich wiederholen; mehrere Objektarten kommen
in einem Dokument, der Vereinigung der Einzelantworten.
Keine Abdeckungsprüfung (außerhalb des Dienstes kommt eine leere
Antwort, kein 404). s=dlm50:{region} pinnt eine
DLM50-Dump-Region. Mit id= ist es die By-ID-Abfrage, die
/oid intern benutzt. Ohne s=
antwortet /wfs mit 400.
DEBY), gleicher Objektname
oid/DEBYBDLMaR00069Q#f; beim falschen Dienst ein 404.
/oid nennt seinen Gewinner-Dienst als genau diesen Teil
(dct:hasPart).dlm50.roots[].region)ave:-Namensraum,
NRW)
(.json)adv:-Namensraum wie
Basis-DLM — unterschieden per AX_Flurstueck, siehe
routing.md)
(.json)Ein Objekt lässt sich auch über einen Attributwert finden,
ganz ohne BBox, innerhalb des gepinnten Dienstes. Zurück kommt das
Objekt, das das Attribut TRÄGT (AX_Straße für die
Bezeichnung, AX_Wasserlauf für die Gewässerkennzahl). Ein
eigenschaft=wert-Parameter ist ein Tripelmuster
(?x gid:eigenschaft "wert", mit der Abfrage-URI im
FROM) — das ist auch der Weg, wie SPARQL diese Abfrage
erreicht.
like=, Muster mit */?)typenames= ist PFLICHT — eine klassenlose Form über alle
Objektarten gibt es nicht.
intersects.json?s={Quelle}&bbox={W,S,O,N}&typenames=… nennt die
Objekte einer Quelle, die die BBox schneiden (geo:sfIntersects: berühren oder
überlappen), ohne sie selbst zu liefern: ein RFC-9264-Linkset
(application/linkset+json), jedes Objekt ein item-Link auf sein
oid/{oid}.json. Ein Client holt nur die Objekte, die er noch nicht hat, jedes
unter seiner eigenen URI aus seinem HTTP-Cache. Beim Upstream werden nur die Kennungen
abgefragt, keine Geometrien (Bayern: GetPropertyValue, BKG:
PROPERTYNAME=objid). Alle Objekte in einer Antwort, ohne Seiten; mehr als
20 000 in der BBox sind ein 400. s= ist ein Dienst, auf den
oid/ auflöst, oder ein Dump (dlm50:{region}). Ein Live-WFS prüft die Geometrie selbst;
ein Dump prüft das umgebende Rechteck des Objekts und kann daher auch ein Objekt nennen,
dessen Geometrie die BBox verfehlt.
Die Grundrisse der Gebäude aus dem Liegenschaftskataster: in einer BBox
(/wfs), als Links (/intersects.json) oder einzeln
(oid/{oid}). In Nordrhein-Westfalen und Brandenburg live aus den
NAS-konformen ALKIS-WFS (adv:AX_Gebaeude, mit Funktion, oft Dachform und
Höhe). In Bayern aus den Hausumringen des LDBV (CC BY 4.0, vierteljährlich), als
Dump hausumringe:bayern mit 10,3 Mio. Umringen: jeder trägt nur sein
Polygon und ags, den Gemeindeschlüssel als Zahl
(vocab/by/hausumringe). Die Dateien haben keine Kennung,
daher bildet der Wrapper sie aus der Geometrie: HUBY und 12 Zeichen, keine
AdV-OID; sie ändert sich, wenn das LDBV den Umring ändert.
Ein WMS-Dienst, ein Layer, ein Ausschnitt: /wms?s={Dienst}&layer={Layer}&bbox={W,S,O,N}
liefert das Bild über genau einen gepinnten Dienst (kein Routing).
Die Bildgröße nennt man entweder in Pixeln (width/height)
oder als Bodenauflösung (gsd= Meter pro Pixel; gsd=native
fragt die dokumentierte Produktauflösung ab, z. B. 3,125 m für die DTK100).
Was der Dienst im Moment kann, sagt wms?s={Dienst} ohne Layer.
.json/.ttl liefert statt Pixeln die
Objekte eines Info-Layers im Ausschnitt (GetFeatureInfo an den Ecken und der Mitte):
hier die DOP-Kacheln mit ihrem Bildflugdatum, je Kachel die Abfragepunkte, die sie treffenKachel-Viewer — dieselben WMS-Dienste als
Web-Mercator-Kacheln (/tile?s&layer&z&x&y,
EPSG:3857, das OSM/Leaflet-Gitter): als verschiebbare Karte und als
Einzelkachel in ihren nativen 256 px. Jede Kachel ist zitierbar und
cachebar, /tile.ttl liefert ihre Beschreibung (Fläche,
Bodenauflösung) in Turtle.
Gelände- und Oberflächenmodelle als Werte in Metern, nicht als
Bild: /tile?s={wcs}&coverage={id}&z&x&y liefert dieselbe
Web-Mercator-Kachel als Float32-GeoTIFF, vom WCS selbst zugeschnitten;
/tile.png als 16-Bit-PNG (Meter = px × Height-Scale
+ Height-Offset, px 0 = keine Daten), /tile.ttl beschreibt
Größe, Skala und den GetCoverage-Aufruf. Dienste (NRW, Brandenburg,
Mecklenburg-Vorpommern, Niedersachsen) und ihre Coverages: status,
je Dienst status?s=.
Welche WFS-/WMS-Dienste angebunden sind und ob sie gerade erreichbar sind,
zeigt die Statusseite; was ein Dienst laut Discovery
führt, sein Datensatz status?s={Dienst}; was er im Moment
über sich sagt, wfs?s={Dienst} bzw. wms?s={Dienst}
(GetCapabilities live). Die Abfrage-Endpunkte sind in
der FAQ aufgeführt.
SPARQL über abgerufene Dokumente
unter /sparql. Welche Endpunkte dieser Wrapper
selbst tatsächlich anbietet (Formate, Parameter je Route), listet
maschinenlesbar /routes (Turtle per Default,
.json auf Wunsch).
Die Daten gehören den Vermessungsverwaltungen der Länder und dem BKG und stehen
unter deren Lizenzen, meist
dl-de/by-2.0,
CC BY 4.0 oder
dl-de/zero-2.0. Welche für ein Objekt gilt,
sagt jedes Dokument selbst: im RDF dct:license neben der Quelle
(prov:hadPrimarySource), bei oid/{oid}.json der Link-Header
rel="license" mit dem Namensnennungstext; für einen Dienst oder Dump sein
Datensatz status?s={Quelle}. Die Dokumente dieses Wrappers insgesamt:
dl-de/by-2.0 (index). Der Code des Wrappers: AGPL-3.0.
