Germarkungen / Gewanne eintragen

Diese Version der “Auswertungslastumkehr” wäre auch eine Möglichkeit … :smiley: … das wird aber vermutlich bei den Erfassern der Flurnamen auf wenig Gegenliebe stoßen, da die Namen dann in carto nicht mehr gerendert werden. Ungeachtet dessen würde ich aber die cadastral_section mit drinne lassen:

place=locality
locality=cadastral_section
name:cadastral=Pfaffenacker

Stimme Dir durchaus zu, aber andererseits sind die heute in den Liegenschaftskatastern noch vorhandenen Flurnamen die einzige offizielle, frei zugängliche und damit jederzeit verifizierbare Quelle für diese Bezeichnungen. Die nicht mehr dokumentierten “echten” Flurnamen sterben nach und nach mit den wenigen Alteingesessenen, die sie noch benutzen, weg. Damit ist dann auch eine Verifizierbarkeit nicht mehr gegeben, es sei denn, man macht sich auf die Suche in einem verstaubten Stadtarchiv.

Genau aus diesen Gründen

  • die meisten “echten” Flurnamen sind bereits verschwunden
  • die Bezeichnungen in den Liegenschaftskatastern stimmen häufig mit den “echten” Flurnamen nicht überein
  • die Zuordnung zu einer konkreten Fläche ist meistens nicht möglich
  • die Flurnamen sind selbst den meisten Anwohnern nicht bekannt und haben auch keine offizielle Bedeutung mehr

würde ich selber ganz darauf verzichten, diese Namen überhaupt zu erfassen.

name:cadastral geht in Zusammenhang mit den Flurnamen aus den Liegenschaftskatastern schon in die richtige Richtung. Es gibt auch kaum Alternativen, da eine Flur bzw. ein Gewann korrekterweise als cadastral_section bezeichnet werden. Das allgemeinere “land_parcel” ist m.E. nicht besser.

Vielleicht hat ja jemand anders noch eine bessere Idee?

PS Off-Topic: Hoadoi gefällt mir … :slight_smile:

Leicht OT: Wir mappen auch nicht alle bereits abgebrochenen Gebäude, nur weil sich sonst keiner mehr daran erinnert, dass da mal welche standen. Wer das erforschen will, der kann das ja mit alten Karten machen! Und das damit sogar besser, als mit einer schlechten/unvollständigen/übertragungsfehlerbehafteten Kopie in OSM, bei der dann nebenbei auch nicht erkennbar ist, ob und wann die Namen gebräuchlich waren.

=> Aber in der Sache sind wir uns anscheinend einig: OSM soll die jetzige, verizibierbare und in gewisser Weise relevante Realität abbilden. Die mir bekannten lokalen Flurnamen und Hausnamen* habe ich nicht erfasst und werde sie daher auch nicht erfassen. (*Es sei denn, das wäre zum Beispiel vor Ort am Haus so angeschrieben.)

Edit:

Für eine “Verifizierbarkeit” ( https://de.wikipedia.org/wiki/Verifizierung ) fehlt mir die tatsächliche Überprüfung der Behauptung der Katasterkarte, dass ein Ort so heiße. Noch einmal in die gleiche Karte schauen ist keine Verifizierung.
Mit dem gleichen Vorgehen könnte man jede “Trap Street” ( https://de.wikipedia.org/wiki/Trap_Street ) als “verifiziert” übernehmen - nur indem jemand anderes da noch einmal nachschaut.

https://www.openstreetmap.org/changeset/122150677 hat tux67 oben ja schon genannt. Da entwickelt sich (mal wieder) eine Diskussion und ich gewinne immer mehr den Eindruck, dass der Mapper keine Ahnung hat und stur an seiner Argumentation der Unfehlbarkeit und Korrektheit von ALKIS festhält. Mit der Folge, dass weiterhin die Namen gemappt werden, zuletzt in https://www.openstreetmap.org/changeset/122553475 (nur der Changeset-Kommentar wurde mal wieder geändert).

Naja, ich sehe da die Mapper (und unsere Dokumentation) in der Verantwortung, nicht die Auswerter (per Subtag).
aber den name-Tag als Schalter zu missbrauchen ist vielleicht nicht die beste Idee…

Nur zu meinem Verständnis des place=locality-Tags, der von mir angelegte zu den “Kripplöchern”
https://www.openstreetmap.org/node/8781325098#map=16/51.2507/9.9244
nicht zu verwechseln mit den “Hielöchern” nebenan, schon lange vorher von Kollegen angelegt
https://www.openstreetmap.org/node/851304975/history#map=18/51.24237/9.91242
(keine Ahnung, ob das so auch im Kataster steht, aber das passt schon)

und jetzt mag jeder mal nach z.B. “Am grünen Weg” in OSM suchen
https://www.openstreetmap.org/search?query=Am%20gr%C3%BCnen%20Weg#map=15/50.8252/6.1530
was dort als “Flur” oder “Acker” auftaucht sind doch wohl “Flurnamen aus (div.) externen Katastern in D” - und dafür war und ist place=locality imho nicht gedacht/geeignet (genausowenig wie landuse=farmland usw.).

Wenn das mehrheitsfähig ist, dann muss ein anderer/neuer Tag für (bloße) Flurnamen in D her, und das ganze muss vernünftig dokumentiert werden…

@ pyram @ Jo Cassel

Stimme Euch beiden zu.

“Echte” Ortsnamen, die allgemein gebräuchlich sind (wie z.B. die Kripplöcher) und/oder OTG verifizierbar sind (Beschriftung, Infotafel etc.) → mappen

Flurnamen, für die als einzige frei verfügbare Quelle die Liegenschaftskatastern existieren → nicht mappen, weder als place=locality und schon zweimal nicht als landuse=farmland oder meadow (und davon gibt es haufenweise).

Wenn das trotzdem unbedingt jemand machen will, dann

genau darum geht es hier m.E.

Moin

Wo wir hier gerade bei (Flur-)Namen sind …

Hatte die Tage festgestellt, dass ein benanntes Waldgebiets-Mulitpolygon fälschlich den jenseits der Gemarkungsgrenze traditionell anders benannten Wald mitumfasste …

Also gestern zwei Multipolygone draus gemacht und dabei auch noch paar historisch vor Siedlungs- und Straßenbau dazugehörige Waldstücke mit reingenommen.
Scheint im ersten Anlauf halbwegs gelungen zu sein, weder ist der Wald nun weiß, noch das restliche Stadtgebiet grün oder so … :roll_eyes:
Die Tage noch um den Feinschliff in nachfolgenden Iterationen sorgen …

Dazu zählt der Name, der als name am Multipolygon hängt.
Im Ursprungs-MP saß der Name relativ mittig, fein …
Heute finde ich ihn in einem äußeren Teil-Polygon wieder, den Namen vom 2. Wald noch nirgends, aber es ist eh noch nicht alles neu gerendert …

Gibt es Möglichkeiten, die Position des Namens zu beeinflussen bei Wald-MPs?
Bei Admin-MP gibt’s ja oft einen inkludierten Zentralpunkt, das finde ich bei allg. MPs nicht in der Doku, scheint also nicht vorgesehen?
Man könnte auf die Idee kommen, ein place zu setzen, ob Teil des MP oder extra, im 2. Wald gibt es aber schon einzelne benannte Fluren mit place=locality, desgleichen für den 2. Gesamtwald würde da also untergehen … “Eine Hierarchie-Stufe höher über locality” scheint es aber nicht zu geben?

Nein, und das wäre auch nicht zweckdienlich, da jede Zoomstufe ein kleines bisschen anders aussieht und man ja nicht Zentralpunkte für 22 verschiedene Zoomstufen angeben will.

Die Beschriftung eines Multipolygons erfolgt eigentlich unabhängig von den Membern. Es ist nicht bekannt, dass label-Member irgendwas beeinflussen würden, sie werden eigenständig gerendet (und das nur weil sie place=irgendwas sind).

Nun ja, wer explizit Punkte setzt, wird sich schon eine Stelle aussuchen, wo das mit wenig Konflikt geht, was in einem Wald sooo schwierig nun auch wieder nicht ist …

Hmmm … Mal schauen, bis alle Zoomstufen durchgerendert sind. Das aktuell sich abzeichnende Ergebnis wäre suboptimal und riefe dann nach Tricksereien …

Moin!

ich finde, als Vermesser, es auch interessant diese Namen zu übernehmen. Da wo mir diese bekannt waren, da habe ich diese auch eingetragen.

Was für mich immer ein fraglicher Punkt ist - die Quelle. Die Alkis oder das Liegenschaftskataster haben Urheberrechte und da muss es nicht konform zu osm sein. Auf der anderen Seite sind die Namen oftmals älter als das Liegenschaftskataster selber. Woher dann nehmen.

In SH gibt es jetzt OpenData auch für die Alkis - aber da ist für mich die Frage ob diese mit OSM konform sind.

Selbst wenn ist es schwer die Daten aus den Alkis -Daten zu entnehmen .so aus der Datenmenge und jede Flur einzeln heruntergeladen werden muss - soweit mit bekannt.

Jan

Naja, OT … z.B. verwendet diese website https://www.openstreetmap.org/ den label-Node einer admin-Grenzrelationen zum setzen des Markers für ein flächenbezogenes Suchergebnis.
(carto nutzt role:label z.Zt. nicht, nichtsdestotrotz sind label-Nodes bei admin-Grenzrelationen hochgradig sinnvoll. Für übliche Multipolygone ist dies meines Wissens nach aber nicht dokumentiert/vorgesehen.)

@Lübeck
dann wäre es doch interessant, aus deiner “Betroffenensicht” was zum Thema (Nicht-)Notwendigkeit der Sichtbarkeit (bei carto, bzw. üblichen Auswertern) zu sagen?..

Hi,

ich habe soeben bei der Anmeldung eine Nachricht von Frederik Ramm (woodpeck) erhalten. Darin werde ich gebeten, vor der Eintragung weiterer ALKIS-Lagebezeichnungen eine einvernehmliche Lösung in der community zu dieser Thematik abzuwarten.

Dem werde ich nachkommen und im folgenden die zu klärenden Fragen und mögliche Antworten aus meiner Sicht zusammenfassen.

Damit das gelingen kann, ist es notwendig, klar definierte Begriffe zu verwenden, so dass Missverständnisse vermieden werden.

Der zentrale Begriff ist hier die Lage, gegeben durch einen (errechneten) Mittelpunkt und eine Bezeichnung, so wie sie im amtlichen Liegenschaftskataster (ALKIS) für Deutschland verwendet wird. ALKIS Daten sind hinsichtlich ihrer Lizenz uneingeschränkt nutzbar (Deutschland Zero 2.0). ALKIS gibt den aktuellen Datenbestand wieder und ersetzt ältere Systeme.

Jedes Flurstück, als kleinste Einheit in ALKIS, ist Teil einer - häufig größeren - Lage.
Lagen in bewohnten Gebieten tragen als Bezeichnung in der Regel die Kombination aus Straße und Hausnummer, unbewohnte Gebiete (z. B. Landwirtschaft, Wald, Brache, …) erhalten aus historischen Daten und Kartenwerken übernommene oder auch neu vergebene Bezeichnungen.
Andere Begriffe, wie Gewann oder Flurname, stellen lediglich Spezialfälle einer Lage dar.

Ich möchte in der community klären:

Sollen Lagen aus ALKIS in die OpenStreetMap-Datenbank übernommen werden?
Soll dies für alle oder nur für eine bestimmte Teilmenge geschehen?
Soll dies gar nicht geschehen?
Sofern überhaupt eine Eintragung vorgenommen werden soll, ist zu entscheiden: wie soll die Lage getagged werden?

Meine Antwort und Begründung dazu lauten so:
Es sollte eine Teilmenge übernommen werden. Unstrittig ist das sicher für Straßennamen und Hausnummern mit entsprechendem tagging.

Die Bezeichnungen der unbewohnten Gebiete liegen auf gleicher Ebene. Ihre Aufnahme in den ALKIS-Datenbestand gibt ihnen aktuelle Relevanz. Sie sind aber zudem auch von historischem Interesse und ihre Übernahme in OSM trägt zur Bewahrung dieser Historie bei. Zudem gibt es eine Vielzahl von Beispielen, in denen diese Namen auch heute noch in der jeweiligen Umgebung aufgegriffen werden.

Für unbewohnte Gebiete sehe ich zunächst zwei objektive Auswahlkriterien, die berücksichtigt werden könnten (als Regel mit Ausnahmen): die flächenmäßige Größe der Lage, um Kleinstlagen auszuschließen, sowie die Art der Bezeichnung, um beispielsweise hin und wieder auftretende rein oder im wesentlichen numerische Namen nicht zu übernehmen.

Aktuelle digitale topographische Karten zeigen diese Namen bei entsprechend kleinem Maßstab.

Zur Frage des taggings:

eine Lage im ALKIS-Sinn sollte als solche stets identifiziert werden können, deshalb scheint mir locality/ALKIS_Lage naheliegend. Aber der konkrete Begriff kann auch einer anderer sein, sofern er nicht dazu verleitet, ganz andersartige Objekte darunter abzulegen.

Schlussendlich noch die Anmerkung, dass bekanntlich bereits seit Jahren viele tausende von Lagebezeichnungen aus Karten in OSM übernommen wurden, von einer Vielzahl unterschiedlicher mapper, gestützt durch die deutsche Fassung des place/locality wikis.

Eine community-Lösung sollte deshalb auch den Altdatenbestand berücksichtigen.

physi

Hallo physi,

vielen Dank für Deinen Beitrag.

Als jemand, der bisher nur passiv mitgelesen hat, muss ich aber sagen, dass ich ihn als extrem unkollegial gegenüber den ganzen Usern empfinde, die vor Dir in diesem Thread gepostet haben.
Über mehrere von Dir als ‘zu klärend’ eingeordnete Dinge (bspw. historische Namen) besteht weitgehende Einigkeit.

Insofern wäre es sehr schön gewesen, wenn Du in Deinem Beitrag auch auf den aktuellen Diskussionsstand Bezug genommen hättest.
So, wie Dein Beitrag jetzt dasteht, wirkt er so, als wenn es die Diskussion vorher überhaupt nicht gegeben hätte.

Neuwessi11

Danke, dass du dich nun an dieser Diskussion beteiligst.

Zunächst eine Anmerkung:

Die Aussage ist nicht korrekt. Es gibt Bundesländer, die diese Daten nur in einer mit OSM inkompatiblen Lizenz freigeben, weshalb wir sie dort nicht verwenden dürfen. NRW, um das es hier im Speziellen geht, hat die Freigabe vor einiger Zeit erteilt.

Zum Thema:

ALKIS ist zunächst mal ein Informationssystem (dafür steht auch das “IS”) in dem Daten aus verschiedenen Quellen zusammengeführt wurden. ALKIS ist aber nicht das System, in dem diese Namen definiert werden, sie werden nur angezeigt, weil sie dort eingepflegt wurden. Darum ist es auch nicht sinnvoll, einen Flurnamen mit dem Subtag “locality=ALKIS_Lage” zu taggen. Die Flurnamen sind teilweise vor hunderten Jahren entstanden, in damaligen Karten aufgezeichnet und irgendwann nach ALKIS übernommen worden. Wenn es ein Subtag sein soll, dann sollte die englische Bezeichnung etwas damit zu tun haben, was dieser Name bezeichnet - nämlich ein Flurstück.

Grundsätzlich habe ich kein Problem damit, diese Namen in OSM zu übernehmen (auch wenn ich es persönlich nicht machen würde). Aber bitte nach Abstimmung mit der Community, sinnvoll getaggt (passiert beides gerade) und genauer Prüfung was man übernimmt. In https://www.openstreetmap.org/changeset/122630975 sehe ich z.B. Namen doppelt. Das kann korrekt sein, das kann aber auch ein Fehler in ALKIS sein. Dem Projekt OSM bringt es am Ende nichts, wenn wir einfach aus den Quellen “abmalen” und hoffen, dass das alles schon stimmen wird. Passend dazu ein Zitat von dir:

Und genau das (fett markierte) ist nicht immer gesichert.

@aixbrick

Zur Frage der Lizenz:

Es ist richtig, die Datenlizenz Deutschland - Zero 2.0 wird bisher noch nicht von allen Bundesländern verwendet. Dort, wo die Lizenz eine Datennutzung nicht ermöglicht, kann ALKIS auch nicht als Grundlage für OSM verwendet werden. Dem stimme ich zu.

Zur Frage: was ist ALKIS?

Deine Argumentation (wenn ich sie richtig wiedergebe, sonst korrigiere mich bitte) lautet:

ALKIS ist lediglich ein Informationssystem, das aber keine verbindlichen Informationen wiedergibt und insofern nicht als Quelle verwendet werden kann.

Ich verstehe es anders und zitiere mal aus einer Beschreibung von ALKIS:

“ALKIS ist das Fachverfahren, in dem flächendeckend und aktuell die rechtsverbindlichen Daten aller Liegenschaften (Flurstücke und Gebäude) sowie die nachzuweisenden tatsächlichen und rechtlichen Merkmale geführt werden”

und

“Die in ALKIS geführten obligatorischen Liegenschaftsdaten (zur Geometrie, zur Bezeichnung, zur Beschreibung, Eigentums- und Grundbuchangaben) begründen den Nachweis aller Liegenschaften.”

und

“ALKIS-Daten sind damit Geobasisdaten für viele Nutzungsbereiche und erfüllen eine Basisfunktion.”

Meiner Ansicht nach genügt das, um ALKIS als belastbare Quelle zu betrachten. Richtig ist, dass es in ALKIS auch einzelne Fehler geben wird. Diese können aber nicht die Nutzung grundsätzlich in Frage stellen.

Zur Frage der doppelten Einträge:

Im Nachhinein gebe ich zu, dass ich auf die doppelten Punkte vielleicht besser hätte verzichten sollen. Diese spezielle Eigenschaft habe ich nicht immer aus ALKIS unmittelbar übernommen (gibt es dort auch), sondern bei sehr großen Lagen (nur am Rande: es gibt Lagen mit unter 100 qm und solche mit über 1.000.000 qm) selbst ergänzt um der Ausdehnung gerecht zu werden. Sollte da die Ansicht vorherrschen, das sei zu willkürlich, bin ich gern bereit das anzupassen.

Nein, das ist nicht meine Argumentation.

Der Absatz bezieht sich in seiner Gänze auf deine Idee, den tag “locality=ALKIS_Lage” zu setzen. Es ist aber keine ALKIS-Lage. ALKIS ist nur das System, in dem die Daten zur Verfügung gestellt werden. Ferner habe ich auch nirgendwo ALKIS als Quelle infrage gestellt.

Mit Verlaub, aber ich habe mittlerweile den Eindruck, es gibt ein grundsätzliches Problem zwischen dem, was dir gesagt/geschrieben wird (auch in Changeset-Diskussionen) und was du verstehst bzw. daraus machst.

Das ist so m.E. nicht korrekt. In bebauten Gebieten werden die einzelnen Flurstücke numerisch identifiziert. Die Kobination von Straße und Hausnummer gilt für die Gebäude, nicht für die Flurstücke per se. Die übergeordneten Lagen (oder Fluren), die mindestens ein, häufig n Flurstücke umfassen, haben zumindest hier in Hessen ebenfalls Bezeichnungen, im Normalfall numerische.

Ein Beispiel aus Bad Hersfeld: Das Gebäude mit der Adresse “Am Berg 1A” steht auf Flurstück 85/1 und gehört zu Flur 57. Das lässt sich z.B. aus dem Liegenschaftsplan auslesen. Nicht erkennbar ist jedoch die konkrete Ausdehnung von Flur 57. Von daher sind diese Flurbezeichnungen für OSM m.E. absolut wertlos.

Siehe dazu zunächst mal die vorangegangenen Beiträge, da sind bereits einige Meinungen zusammengetragen worden.

Das hat mit den Lagebezeichnungen nichts zu tun, siehe oben.

Das stimmt so definitiv nicht. Lagebezeichnungen für landwirtschaftliche Flächen haben nichts zu tun mit Adressen von Gebäuden. Und die Aufnahme in die ALKIS Daten macht diese Flurnamen nicht automatisch relevant für OSM. Zu dem “historische Interesse” wurde in den vorangegangenen Beiträgen schon einiges an Informationen zusammengetragen.

Das ist sicher zu berücksichtigen, aber nicht zwingend ein Beweis für die Relevanz dieser Flurnamen (insbesondere, wenn die Flurnamen fälschlicherweise z.B. an die Fläche eines Ackers oder einer Wiese getaggt wurden, also landuse=farmland + name=Flurname). Es gibt auch unendlich viele andere Objekte, die definitiv keinen Namen haben aber trotzdem mit einem name-tag versehen wurden, damit sie auf carto gerendert werden. Die Quantität dieser Tags ist also nicht unbedingt ein Beweis für die Qualität … :wink:

+1!

Ich habe den ganzen Sermon was ALKIS ist und was nicht mal gelöscht weil das hier völlig unerheblich ist und in die völlig falsche Richtung weist.

Wir tragen in OSM bis auf wenige Ausnahmen das ein was “On the ground” und damit für jeden validierbar ist. Ausserdem tragen wir das ein was “common knowledge” ist bzw was in Benutzung ist z.b. Gemeindegrenzen.

Ich habe von vorneherein bezweifelt das jegliche Informationen aus dem ALKIS (Und ich hatte das hier ja auch ausgeführt) “common knowledge” ist. Es sind vielfach Dinge die vor irgendwelchen Gemeindegebietsreformen mal vielleicht interessant und in Benutzung waren.

Dazu kommt das wir keine Kopie des ALKIS oder irgendwelcher öffentlicher Datenbestände sind. Das ganze haben wir in Bielefeld lang und breit durchexerziert und das hat am ende zur dauerhaften Sperrung eines Users geführt der es nicht einsehen wollte das wir nicht flächendeckend Flurstücke aus dem ALKIS in OSM übernehmen.

D.h. bei jedem “Gewannnamen” hätte ich gerne gewusst ob der wirklich vor Ort bekannt und genutzt wird und nicht einfach blindlings aus irgendwelchen Datenquellen das quasi importiert. Und dabei ist es unerheblich ob das ALKIS eine vertrauenswürdige Quelle ist, sondern lediglich ob diese Namen von jemandem vor Ort einem Platz/Position/Gebiet zugeordnet werden kann, d.h. das sie in Benutzung sind. Das zweifel ich einfach mal an, und zwar aus eigener Erfahrung.

Und das das im Kartoffelkrieg mal bekannt war und genutzt wurde ist irrelevant. Kann sein. Dann gehörts in die Open Historical Map.

Flo

Vielen Dank für eure Beiträge.

@Map_HeRo

vielleicht ist es sinnvoll, einfach mal zwei konkrete Beispiele anzugeben, um zu zeigen, was in den ALKIS-Daten tatsächlich enthalten ist. Beispiel 1 ist ein Wohnbaufläche in Hilden, Beispiel 2 eine landwirtschaftlich genutzte Fläche wenige km entfernt. Alle deine Angaben sind darin enthalten, aber eben auch die von mir verwendete Lagebezeichnung

und

Das Beispiel ist aus NRW und natürlich ist richtig: sollten die Daten in anderen Bundesländern entweder aus Lizenzgründen oder noch gar nicht öffentlich verfügbar sein, dann geht es dort eben (noch) nicht.

@Flo

Wir haben hier gar keinen Dissens. Das ist eine Position, die man, auch nach meiner Meinung, vertreten kann. Wie löst man das Problem, dass es dazu unterschiedliche Ansichten gibt? Es gibt mapper (völlig unabhängig von mir), die tragen “Gewannbezeichnungen” (in der Regel aus topographischen Karten) ein und werden das wahrscheinlich auch weiterhin tun. Andere wollen das ausdrücklich nicht. Meine Überlegung war, diese Eintragungen eindeutig erkennen zu können (durch locality key) und damit in der Datennutzung oder im Rendering überhaupt die Chance zu haben, die Daten nicht zu berücksichtigen.

physi

Schon alleine weil die “Lagebezeichnung” im ALKIS NRW ganz verschiedene Dinge bezeichnen kann, lässt sich dies nicht so ohne weiteres aus dem ALKIS in OSM übertragen. Ich habe mir verschiedene Lagebezeichnungen im ALKIS NRW angesehen, und es ist des öfteren nicht klar, ob es eine Flur/Gewann oder einen Wohnplatz bezeichnet. Man muss mit solchen Daten aus ALKIS extrem vorsichtig sein. Auch diese Daten wurden irgendwoher übernommen. Und der, der es in ALKIS eingepflegt hat, ist auch nur ein Mensch und kann Fehler machen. ALKIS als alleinige Quelle scheidet damit aus, ich würde das immer mit anderen (soweit lizenztechnisch zulässig) verfügbaren Karten abgleichen.

Und: für mich ist ALKIS nicht in der Form locality=ALKIS… einzutragen, sondern allenfalls als source:locality=ALKIS*

Konkrete Frage: Wo genau aus ALKIS hast Du diese Bezeichnungen?
https://www.openstreetmap.org/node/9776911021
https://www.openstreetmap.org/node/9776911020
https://www.openstreetmap.org/node/9805658383