Auf der Infotafel steht, dass die Gebiete die du eingetragen hast die abgezäunten Bereiche des Naturschutzgebiets sind. Aber ich denke das ganze NSG-13 ist schon die gesammte Grube, wie im Geoportal dargestellt.

Für das Betretten der Sandgrube gibt es eine Ausnahmeregelung in der Verordnung zum Schutz der Landschaft des Grunewaldes §6 Abs. 4 Nr. 2:

"In den Naturschutzgebieten ist es insbesondere verboten, diese außerhalb vorhandener Wege oder auf abgesperrten Flächen zu betreten oder zu befahren; davon abweichend dürfen das Naturschutzgebiet „Sandgrube im Jagen 86“ oder die Kiesgrube am Postfenn im Naturschutzgebiet „Postfenn und Teufelsfenn“ auf den nicht abgesperrten Flächen betreten oder mit Krankenfahrstühlen befahren werden,"
https://gesetze.berlin.de/perma?d=jlr-GrunewNatGebLSchVBEpP6

Bist du sicher, dass das die Grenzen des NSG-13 (Sandgrube im Jagen) sind?

Laut dem Geoportal Berlin erstreckt sich das Naturschutzgebiet über die ganze Sandgrube.
https://fbinter.stadt-berlin.de/fb/index.jsp?loginkey=zoomToMapById&mapId=nsg_lsg@senstadt&Id=NSG-13

https://www.berlin.de/sen/uvk/natur-und-gruen/naturschutz/schutzgebiete/naturschutzgebiete/sandgrube-im-jagen-86-des-grunewaldes/

Ah danke, hab ich zum testen benutzt und vergessen vor dem hochladen wieder zu löschen.

Ich hab deine Änderung rückgängig gemacht. Den Namen des Aussichtspunkt hab ich wieder korrigiert und den Parkplatz als Fläche eingetragen.

Wir können dein ganzes changeset rückgängig machen oder die Werte von Hand wieder hinzufügen.

Bist du denn bei der Lage der Parkplatzfläche sicher? Auf Luftbilder sieht der Parkplatz kleiner aus. Wenn du den Parkplatz als Fläche eintragen willst, hättest du außerdem den bisherigen Parkplatz Node entfernen müssen. Zusätzlich hast du die Parkplatzfläche mit der Straße verbunden, was man nicht machen soll. Flächen bitte nicht mit Straßen/Wegen verbinden.

Du hast hier wichtige Werte der Grunewald Relation entfernt, die denke ich alle wieder hinzugefügt werden müssten.

Warum hast du die entfernt?

Ich kenne mich mit dem Johannesstift nicht aus, aber wenn assisted_living nicht die Hauptnutzung ist, sonder nur ein Angebot von vielen, würde ich das social_facility=assisted_living tag vom Gelände entfernt werden.

Hausnummern: Der Editor JOSM gibt eine Warnung an, wenn ein Gebäude und Nodes im/am Gebäude identische Adressen haben. Entweder du fügst die Adresse zur "building" Area hinzu (zB. osm.org/way/964869606) ODER zum "entrance" Node (zB osm.org/node/3907452654) ODER zu einem Node im Gebäude (zB osm.org/node/11224624036). Aber nur zu einem davon und nicht zu mehreren. Am Gelände des Rosenhof kann hier die Adresse (Hausnummer 6) wiederholt werden, da das Gelände hier ja die Einrichtung Rosenhof als Objekt in der Datenbank darstellt und auf der Webseite die Hausnummer 6 auch als Kontaktadresse für den Rosenhof angegeben wird.

Auch hier kannst du wieder überlegen, wie Anwendungen die Daten am besten verarbeiten können. Wenn eine OSM App nach Rosenhof sucht, kann die App dann einfach alle relevanten Daten über den Rosenhof direkt vom Rosenhof Objekt auslesen. Wenn das Rosenhof Objekt (das Areal in diesem Fall) keine Adressdaten hätte, wüsste die App nicht zuverlässig, welche Adresse der Rosenhof hat und könnte nur Raten, dass der Rosenhof die Adresse von irgendeinem Gebäude auf dem Gebiet hat.

Hi delineatorix,
es gibt ja die One feature, one OSM element Regel (osm.wiki/One_feature,_one_OSM_element) wo zB. steht "Tags should be on the whole area, and not the buildings, unless the buildings are different."
Wenn auf einem Gelände wie dem Evangelischen Johannesstift andere Arten von Einrichtungen wie Krankenhäuser, Schulen, Tageskliniken etc. existieren, können die natürlich extra gemappt werden, auch wenn sie Teil einer übergeordneten Einrichtung sind. Ich frage mich aber auch ob "social_facility=assisted_living" beim Johannesstift am ganzen Gelände korrekt ist, wenn das nur ein paar der Häuser betrifft und die Stiftung noch viele andere Angebote, für Menschen die nicht vor Ort wohnen, hat.

Es gibt natürlich trotzdem Bespiele von mehrfachem Taggen mit amenity, zB. aufgrund von fehlenden tagging Alternativen oder weil Mapper wollen das etwas gerendert wird.

Für Universitäten sollte zB. auch eigentlich nur ein "amenity=university" Object existieren (osm.wiki/Tag:amenity%3Duniversity), aber weil "campus=*" (osm.wiki/Key:campus) oder auch "landuse=educational" noch nicht von Carto gerendert werden, hat meistens jedes Gelände das zu einer Universität gehört ein "amenity=university" tag. Das ist dann streng genommen aber trotzdem nicht korrekt.
Du findest hier https://github.com/gravitystorm/openstreetmap-carto/issues/774 zu "landuse=educational" zB. auch eine Diskussion dazu, dass Schulgelände auf denen zwei separate Schulen existieren oft mit "amenity=school" getaggt sind, was aber wohl nicht korrekt ist und durch "landuse=educational" ersetzt werden sollte. Das wird bisher aber nicht gemacht, da das eben noch nicht gerendert wird.

Ich denke einfach, wenn man kann sollte man auf mehrfache identische tags verzichten und hier beim Rosenhof kann leicht auf mehrere "amenity=social_facility"+"social_facility=assisted_living" verzichtet werden.

Diese Seniorenwohnanlage ist ja nur eine Einrichtung, deshalb sollte auch nur ein amenity tag existieren. Also pro Einrichtung ein amenity tag.

Das ist zB. wichtig fürs Suchen. Wenn man die OSM Daten nach Seniorenwohnanlagen in Berlin durchsuchen würde, sollte für jede Einrichtung genau ein Eintrag gefunden werden, und nicht mehrere Einträge für die selbe Einrichtung.

Du hast hier das Gebäude falsch getaggt.

- das "building" tag wurde entfernt, es ist aber ein Gebäude.
- ein "entrance" tag wurde hinzugefügt, es ist aber kein Eingang.
- "amenity" und "social_facility" tags wurde hinzugefügt, das ganze Gelände der Anlage ist aber schon so getaggt osm.org/way/1075999589 und diese tags müssen hier nicht wiederholt werden.

Kannst du das bitte rückgängig machen.

Hi, du hast hier bei einem Stück vom Steinweg den highway tag entfernt. War das ein Fehler oder wurde die Straße abgerissen?

Ich hab noch oneway=no hinzugefügt um die Befahrbarkeit in beide Richtungen klar zu machen.

Hi, warum legst du für Naturschutzgebiete die nur einen Way als outer haben, der nicht mit etwas Anderem geteilt wird, eigentlich Relationen an? Hier könnte doch auch einfach der Way direkt die entsprechenden tags bekommen und das würde das tagging Schema vereinfachen.
Ich habe schon ein paar mal im Forum gelesen, dass erfahrene Mapper dazu raten, alles so einfach wie möglich zu mappen und Multipolygone sparsam einzusetzen. Also nur dann wenn sie wirklich benötigt werden. Hier werden Sie meiner Meinung nach nicht benötigt.

Hi, du hast hier eine Gehweg entlang einer Straße als highway=pedestrian gemappt. Dafür wird pedestrian nicht benutzt. Deswegen habe ich den way mit pedestrian wieder gelöscht. Der tag sidewalk=left an der Helene-Jacobs-Straße sollte hier reichen. Die Linienführung der Bordsteinkante wird in Berlin ja gewöhnlich durch die Begrenzung der landuse=residential Fläche gekennzeichnet.

Außerdem hättest du durch das separate mappen der Parkbuchten die bestehenden parking:lane tags an dem Bereich der Helene-Jacobs-Straße ändern müssen. Das habe ich jetzt gemacht.

Ja passt, danke :)

Wodurch wird die Wiese zur Hauptwiese und zentraler Begenungsstätte? Ich denke durch die Größe und durch die Lage bzw. Anbindung, da ein Weg außenrum geht und fast alle Wege im Park auf diese Wiese zu gehen. Diese Punkte sind aus der Karte ersichtlich, egal welche landuse oder leisure tags die Fläche hat. Ich finde aber, dass es eine wertvolle Information ist, zu wissen, welche Beschaffenheit diese Fläche hat. Das wurde vorher durch landuse=grass gut ausgedrückt. Daher finde ich, dass leisure=park hier entfernt und wieder durch landuse=grass ersetzt werden sollte.

Ja, mir kommt es halt merkwürdig vor so einen Richtungspfeil auf der Karte zu sehen. Das ein Fußweg wirklich nur oneway ist, gibt es doch extrem selten und trifft sicherlich nicht auf einen Bürgersteig zu.

Warum ist das osm.org/way/697564379 leisure=park? Der Preußenpark ist doch schon extra gemappt (osm.org/way/4413796) und einen Park in einem Park zu haben, macht für mich keinen Sinn.

mtb:scale:uphill=5 gilt aber nicht für den ganzen Weg. Du schreibst ja selbst, dass die starke Steigung "an einer Stelle" ist. Bitte trenne den Weg dann in mehrere Teile und füge mtb:scale:uphill=5 nur zu dem Teil hinzu der so steil ist.

Die gemappte Grenze des LSG-23 stimmt exakt mit der aus dem Geoportal überein. Hab ich schon überprüft.