Der Name wird meines Wissens trotzdem gerendert, siehe
Oder meinst du nicht die Standardkarte?
Man hat natürlich weniger Kontrolle über die Position als bei Nutzung von place=locality.
Die Namen sollten auf jeden Fall auf eine place-node.
Diese Namen sind Flur und Gemarkungsnamen
3 Likes
Die Kalkgasse sieht gut aus. Also das Multipolygon aus 8 Teilen (=8 Linien). Bei Neuanlage machbar, aber i. d. R. sind die Weinberge schon als (Teil-)Flächen erfasst.
Das stimmt so nicht, hier z.B. wurde ein Weinberg (Kraichgau, Baden) in eine MP-Relation gekloppt, der Name ist in Mapnik gut sichtbar.
2 Likes
Sehe ich auch so. Hier wäre nur die frage passt hier immer place=locality ?
Ja, da die Bezeichnung immer lokal für für eine Gemeinde ist und nicht übergreifend. Falls doch, dann sind es keine Gemarkungs- oder Flurnamen.
Aber wo platziert man den Node, wenn es mehrere Teilflächen gibt?
Es gibt keine Teilflächen.
Der Name bezieht sich auf eine Fläche, des halb ist an klatschen das landuse sinnbefreit
Zum Thema node vs. Flächen sei auf diese ältere Diskussion hingewiesen:
Ich denke auch, dass der place-Node angebrachter ist. Abgesehen davon, dass die landuse-Flächen in der Regel nicht den Flurausdehnungen entsprechen, bleibt der Flurname unangetastet, wenn ein Schädling den Wein zerstört und der landuse sich ändert.
1 Like
Meines Wissens sind die Namen von Weinbergen bzw. Weinlagen nicht zwangsläufig identisch mit den Flur- bzw. Gemarkungsnamen. Die Benennung von Einzellagen im Weinbau erfolgt nach eigenen Gesetzmäßigkeiten.
Von daher ist ein place=locality nicht die richtige Wahl, oder gibt es einen speziellen place-node für Weinlagen?
place-nodes sind nicht zwingend Flur/Gemarkungsnamen.
locality bedeutet nur: namentlich bekannte Örtlichkeit unbekannter/unerheblicher Ausdehnung, kann man also auch für Einzellagen nehmen.
Wenn man die gesetzlich festgeschriebenen Einzellagen gebietsgenau erfassen wollte, müsste man sich ein Tagging ähnlich den NSGs überlegen, das dann quasi ein Overlay zu landuse und anderen Flächen wäre.
2 Likes
In Amerika hat einer bisher 4 place=wineyard gesetzt. Ob das wirklich was nützt…
Die Weinlagen (Wikipedia) sind eine eigenständige Art von Ortsbezeichnung und nicht (identisch/gleich) Flurnamen. Wikipedia verweist unter “Weblinks” auf die Seite: weinlagen-info.de
Hier der Direktlink zur “Bennsheimer Kalkgasse”.
Das entspricht der OSM Relation “Vineyard Bensheimer Kalkgasse”.
Im Vergleich dazu finden sich im Liegenschaftskataster (ALKIS) dort eine Reihe von (weiteren) Flurnamen:
“In der Kalkgasse”
“Sommerseite”
“Winterseite”
“Im Eichelberg”
“Im Fang”
“Am Ziegelacker”
Aus meiner Sicht sind die Weinlagen eindeutig eine gröbere Gliederung als Flurnamen.
1 Like
Danke für die Bestätigung.
Wobei man fairerweise sagen muss, dass mit dem Namen am landuse=vineyard nicht die komplette Lage erfasst ist, da nicht die komplette Weinlage für den Weinanbau genutzt wird. Aber die Weinbauflächen, die mit diesem Namen erfasst sind, liegen alle komplett in der Weinlage (offensichtlich aber nicht in der gleichen Flur/Gewann)
Ich weiß, dass place=locality nicht ausschließlich für Flure und Gewanne da ist, die Verwendung hierfür hat sich hierzulande aber schon heftig verbreitet und gefestigt. Das ist in meinen Augen bereits de facto use. Das jetzt wieder mit anderen Dingen zu vermischen macht es wieder komplizierter.
Wäre halt noch die Frage, wie es international gesehen wird
Liebs mit einem User mit “
Hamburg” in der Bio über das Tagging von Weinbergen zu diskutieren 
[Edit: Werde morgen zur Strafe wieder ein paar Priele und Deiche mappen 
]
Ich finde Martins Wortwahl auch nicht gut. Trotzdem rechtfertigt das nicht Deinen Beitrag. Das ist doch kein Umgang miteinander.
Ich weiß, dass er sich in Gegenden mit Weinbergen gut auskennt. Man kann durchaus mehr als nur seinen aktuellen Wohnsitz kennen.
4 Likes
Auch wenn da Hamburg steht, so bin ich an der Mosel aufgewachsen und kenne die Gegebenheit gut.
Das nächste mal also bitte nicht immer auf Grund der Bio Angabe falsche Rückschlüsse ziehen
2 Likes
Im OSM-Wiki heißt es:
Das Attribut place=locality kennzeichnet eine örtliche Lage, Lokalität, Flur bzw. Gewann, wenn es dazu keinen passenden Schlüssel in OSM gibt.
Daraus ergibt sich, dass dieses Attribut derartig allgemein gehalten ist, dass es sowohl für Flurnamen als auch für Weinbergnamen genutzt werden kann. Und vor allem ist es gedacht für den Fall, dass die Ausdehnung der mit Namen bezeichneten Fläche nicht klar definiert ist bzw. wenn die mit Namen versehende Örtlichkeit nicht komplett identisch ist mit einem Flächenobjekt wie z.B. einer Wiese oder einem Acker.
Wenn bei einem Weinberg sich der Name eindeutig auf eine oder mehre klar definitiert Flächen mit landuse=vineyard bezieht, sollte man meines Erachtens den Name an diese Fläche anfügen. Besteht dieser Weinberg aus mehreren Teilflächen, dann zeichnet man die Weinbergfläche eben als Mulitipoligon-Relation ein.
Wenn es aber eher eine allgemeine Weinlagebezeichnung ist oder die Bezeichnung eher unabhängig davon ist, ob auf einer bestimmten Fläche nun tatsächlich Wein angebaut wird, dann plädiere ich eher für die Nutzung eines nodes mit place=locality
Man könnte natürlich nun einen passenderen Schlüssel als das allgemeine place=locality definieren. Doch habe ich Zweifel, dass sich ein solche Schlüssel so etabliert, dass dieser auch in den meisten Kartenbildern angezeigt wird. Ich bezweifele, dass in der Breite der Bedarf an einer solchen Differenzierung besteht. Wenn an einzelnen Stellen ein Flurname und ein Weinlagenname ein und die selber Fläche bezeichnen (und dabei ist es egal, ob einer der beiden Namen vielleicht eine größere Fläche als dder andere bezeichnet), reicht es meines Erachtens aus, eine Differenzierung über description=* zu treffen.
vielleicht wäre es besser, statt dessen mit place=locality + locality=vineyard zu arbeiten. Wobei mir unklar ist (kenne mich damit überhaupt nicht aus), ob Weinberg und Weinlage das Gleiche ist, ggf. müsste man insofern mit der englischsprachigen Entsprechung zu “Weinlage” arbeiten.
Mit einer Ergänzung zu place=locality würde man keinen komplet neuen key definieren sondern einen bereits etablierten, allgemeinen key nur weiter präzisieren. Die einen Renderer würden dann Weinberge, Weinlagen, Flurnamen, … nur allgemein bzw. identisch anzeigen, die anderen Renderer hätten über locality=* die Möglichkeit einer differenzierteren Darstellung.
3 Likes