Hallo aixbrick,

ich verwende als tag das key/value pair 'locality' (key) und 'ALKIS Lagebezeichnung' (value).
Values können free form text sein und insofern Leerzeichen enthalten. Die Sprache dürfte auch deutsch sein, ist sie hier aber nicht. Der Wert heißt in jeder Sprache 'ALKIS Lagebezeichnung' (So wie ja auch Straßennamen nicht in englisch abzulegen sind oder ohne Leerzeichen). Woraus leitest du ab, dass dieses von mir so gewählte tagging nicht "sauber" sei?

Gruß,
physi

Richtig, exakt so, wie du schreibst, ist es:
Das ist so, als gäbe es locality = "ALKIS Lagebezeichnung" nicht...

Die hundertfache Wiederholung würde doch im übrigen auch bei locality mit sub tag genau so auftreten.

Und noch ein Zitat aus dem englischen Wiki:

Place a node at the appropriate location and add a place=locality tag together with (...) note=* (...) and similar tags are strongly encouraged (!) to explain the use of place=locality. ((!) von mir ergänzt)

Gruß,
physi

Hi tux67,
ohne jetzt wieder Diskussionen der Vergangenheit zu wiederholen: es ist meiner Ansicht nach nicht redundant, weil place/locality auch anderes bezeichnen kann. Meine Überlegung war, dass die Vielzahl der Gewannbezeichnungen so identifizierbar bleibt... Und wenn ich auf OSM als Datenbank zugreife, ist ein changeset-Kommentar völlig unpraktikabel zur Auswertung, insbesondere wenn man die Historie mit prüfen müsste.

Gruß,
physi

Hi tux67,

gibt es denn gute Gründe, die mich überzeugen könnten, weshalb du mein tagging als "note" in "source" änderst? Die note soll einen Hinweis darauf geben, um was es sich hier handelt (nämlich eine ALKIS Lagebezeichnung), nicht auf die Quelle, die ja im Changeset bereits angegeben ist.

Gruß,
physi

kurze Ergänzung: vielleicht hast du doch recht und es war wegen der Größe des Flurstücks eine andere Erfassung für ALKIS nicht möglich. Insofern gilt: ich hab auch kein Problem damit, wieder den anderen Zustand herzustellen...
Gruß
physi

Hallo rempshaener,

danke für deinen Beitrag, ich halte meine Änderung allerdings bis jetzt noch für ok (vielleicht übersehe ich etwas).
Du hast zwei Punkte eingetragen (Hasenbungert, Kuckhofer Werres), die meiner Ansicht nach dort nicht richtig sind. Hasenbungert finde ich in den ALKIS Daten überhaupt nirgends als Einzelbezeichnung und Kuckhofer Werres finde ich nur als Bezeichnung eines Wegabschnitts, nicht für eine landwirtschaftlich genutzte Flur.

Meine Bezeichnung (Kuckhofer Werres Hasenbungert) ist die Lagebezeichnung des Flurstücks so wie sie in ALKIS angegeben ist und daraus folgt, dass mindestens dort, wo dieses Flurstück ist, diese Lage auch tatsächlich ist.

Ich nehme an, du entnimmst deine Informationen aus der amtlichen Basiskarte. Dort ist das tatsächlich so abgebildet, als seien es zwei Lagebezeichnungen. Da aber für die ABK gilt:
“Die ABK wird aus den ALKIS-Daten des Sekundärdatenbestandes des Geodatenzentrums Liegenschaftskataster abgeleitet.” folgere ich, dass bei dieser “Ableitung” ein Darstellungsfehler aufgetreten ist.
Viele Grüße,
physi

Hallo aixbrick,

vielen Dank für deinen Beitrag, in welchem du auf kürzlich geführte Diskussionen hinweist. Die dort von mir formulierten Überlegungen halte ich nach wie vor für richtig. Das geänderte tagging von ALKIS-Lagebezeichnungen ist nicht optimal, aber meiner Ansicht nach besser als der Zustand vorher.

Gruß,
physi

Hallo rempshaener,
wir können gern noch weiter diskutieren.

Zu deinem Zitat “... but which still see use (and/or have value) as named locations”:

Du argumentierst, wenn ich es richtig verstehe, in etwa so: “use oder value” ergibt sich zum einen aus der Tatsache, dass Gewannbezeichnungen immer noch in amtlichen Datenbanken/Karten enthalten sind, zum anderen aus der Verwendung des Namens auch an anderer Stelle (beispielsweise als Straßennamen).
Ich verstehe unter use dagegen, dass der Name tatsächlich für das Gewann selbst noch aktuell von jemandem benutzt wird. Und in diesem Fall ist place=locality auch aus meiner Sicht sinnvoll und richtig. Das muss dann aber auch nicht unbedingt eine historische Gewannbezeichnung sein, sondern kann auch neueres, wie zum Beispiel “Königshovener Höhe”, sein.

Insofern kann ich meine Vorstellung von einer guten Datenbankdefinition wie folgt präzisieren:
1. Wenn ein Gewann in der Datenbank erfasst wird, muss auch im Nachhinein bei der Nutzung der Datenbank diese Eigenschaft ”Gewann” noch sicher ermittelbar sein (wie das auch für andere Objekte der Fall ist). Das ist mit place=locality allein nicht gegeben (man könnte vielleicht locality=Gewann ergänzen?)
2. Wenn man zig-zehntausende von Namen in einem dichten Netz über ganz Deutschland erfasst (in der ”Endausbaustufe”) und darunter sind viele sehr gebräuchliche, aber auch viele völlig ungebräuchliche, dann muss eine Unterscheidung möglich sein, damit man die gebräuchlichen, die im allgemeinen einen echten Nutzen haben, auch wiederfindet. Das kann man nicht erst auf renderer-Seite lösen, dazu braucht man eine vernünftige Datenbankdefinition.

Aber wir können uns immerhin insofern einigen: ich warte jetzt auch erst mal ab…
Gruß,
physi

Hallo rempshaener,
ok, einverstanden.

Da die Diskussion dauerhaft sichtbar bleibt, will ich aber eine meiner Ansicht nach unrichtige These zumindest nicht unwidersprochen stehen lassen (ohne nach der bisherigen Erfahrung auf Zustimmung zu hoffen):

Tagging für den renderer findet hier tatsächlich statt, allerdings bereits durch das taggen von Gewannen als place = locality.

Dazu drei Zitate aus dem englischen wiki zu “place = locality”:

“Also consider creating a new tag if you would like to map a specific feature that does not yet have an established tag”

”Although place=locality will always show a locality's name in Openstreetmap-carto, this does not justify tagging for the renderer when a taggable feature doesn't show its name on the map.”

“Don't use place=locality just to force a name to appear on a feature.”

Gruß,
physi

Hallo rempshaener ,
lass mich bitte klarstellen, worum es mir geht: ich möchte zu möglichst guten, praktisch verwendbaren, Karten beitragen. Aus eigener Erfahrung bin ich unzufrieden mit einer Anzeige sämtlicher Gewannbezeichnungen, die sich wegen des zu allgemeinen taggings in keiner Darstellung verhindern lässt. Ich kann dir einige meiner heutigen Änderungen als Beispiel geben:

Bisher wurde dort angezeigt “Rüblinghoven” -> ein Ort, den es schon lange nicht mehr gibt
oder “Am Driesch” -> eine Straße dieses Namens existiert, ist aber mehrere hundert Meter entfernt (ähnlich für “Am Schulweg”)
oder “Moogshütte” -> da ist keine Hütte

Es sind historische Bezeichnungen und niemand, der heute von “Am Schulweg” spricht, wird das Gewann meinen.

Deshalb: die Anzeige solcher Daten muss sinnvoll gesteuert werden können und eine erzwungene Darstellung, wie sie durch place=locality in Verbindung mit name erreicht wird, ist meiner Ansicht nach nicht akzeptabel. Die von mir gewählte Variante (old_name/ noname) halte ich für einen sinnvollen Kompromiss, solange keine spezifisches tagging verfügbar ist.

Wenn du dennoch zu einer anderen Beurteilung kommst, dann mach die Änderungen bitte wieder rückgängig...

Gruß,
physi

Hallo rempshaener,

zu diesem Thema gibt es inzwischen eine Reihe von Diskussionen, einen relativ aktuellen Startpunkt findest du beispielsweise hier: changeset/117559338

Da sich die Argumentation im Lauf der Zeit aber weiterentwickelt, nachfolgend nochmal meine Begründung für diese Änderungen:

Ich unterstütze die Erfassung von Gewannbezeichnungen in die OSM-Datenbank. Allerdings muss sicher erkennbar sein, dass es sich bei einem erfassten Objekt tatsächlich um eine Gewannbezeichnung handelt. Das ist aber mit dem unspezifischen place=locality nicht möglich und deshalb sollte zunächst ein geeignetes tagging-scheme eingeführt werden. Dann erst können User oder renderer sachlich entscheiden, ob Gewanne angezeigt werden sollen oder nicht.

Viele Grüße,
physi

einverstanden, werde ich mal in Angriff nehmen...
Gruß,
physi

Hallo tux67,

zunächst 2 Punkte vorab:

noname=yes ist sinnvoll und hätte ich auch hier eintragen sollen. Und die Lizenzproblematik hat aus meiner Sicht heute keine Bedeutung mehr.

Meine Überlegungen, nochmal auf den aktuellen Stand gebracht:

Wie können in OSM sinnvoll Gewannbezeichnungen erfasst werden? Ein Gewann hat keine fest definierten Umrisse. Ein Flurstück kann Teil eines Gewanns sein, ist aber im allgemeinen nicht selbst eins. Außerdem sind vielen Gewannen mehrere Flurstücke zugeordnet.
Die Gewannbezeichnung kann deshalb nur an einem geeignet positionierten Punkt angehängt werden. place=locality leistet das, ist aber nicht spezifisch für Gewanne. Ein renderer muss den Namen deshalb immer anzeigen, weil er nichts über das Objekt weiß.

Problematisch ist das, wenn diese Namen vieltausendfach (!) automatisch importiert werden, wie das hier der Fall war. Das führt zu einer überfrachteten und teilweise verwirrenden Darstellung (z. B. xy-Weg, obwohl dort gar kein solcher Weg ist)

Und deshalb scheint mir die Änderung von name auf old_name vernünftig, so dass die wesentliche Information in der Datenbank erhalten bleibt, aber ohne Darstellungsproblem.

Ich vermute, wenn man ein tagging für Gewanne, z. B. place = gewann, einführen würde, wäre das Ergebnis in den meisten Darstellungen ähnlich.
Und abschließend: mir ist natürlich bekannt, dass im deutschsprachigen wiki (und nur dort) die Verwendung von place=locality für Gewanne erwähnt wird. Da empfehle ich, sich mal die Historie dieses Eintrags näher anzusehen. Ein einzelner user hat das eingetragen, einer hat dagegen argumentiert, das wars. Mir sind keine Diskussionen bekannt, die zu diesem Eintrag geführt haben.

Gruß,
physi

habe die beiden "Quellenangaben" entfernt (die im übrigen auch nur eine historische Information fortschreiben) siehe auch Diskussion zu changeset/111016937 und im Forum https://forum.openstreetmap.org/viewtopic.php?id=71409

Du hast völlig Recht. Da hab ich einen Fehler gemacht. Korrigiere ich im Lauf des Tages. Gruss physi

hab es schon selbst wieder korrigiert...

Gruß,
physi

Lieber user waldhans,

könntest du die Abgrabung der Firma Lankes bitte wieder herstellen, die ich vor einiger Zeit eingetragen habe und die du nun fälschlich als "verfüllt" bezeichnest? Deine Quellen sind leider veraltet.

Da du unlängst in ähnlicher Weise auch das von mir aktualisierte Betriebsgelände der Firma Röben Tonbaustoffe an der Swalmener Straße unkorrekterweise wieder geändert hast, folgender freundlicher Hinweis: geh mal wieder raus zum mappen, das führt im allgemeinen zu besseren Ergebnissen...

Gruß,
physi

ja, kannst du gern entfernen. Vielen Dank für den Hinweis auf die Chatgruppe, aber ganz offen gesagt, ist das für mich eher weniger interessant...
Gruß,
physi

Hallo reigi,
ich war damals zwar auch vor Ort, kann das aber nicht mehr genau rekonstruieren. Möglicherweise habe ich den Eintrag barrier=fence, der ja bei einem einzelnen Punkt laut Wiki nicht korrekt ist, deshalb auf gate geändert. Aber wenn du aktuell dort gar nichts gesehen hast, dann kann das tagging sicher entfernt werden.

Gruß,
physi

Hallo Amegaz,

ja stimmt, man_made=embankment ist eine gute Idee, könnte man so machen...

Gruß,
physi