Hi, sorry I didn't know that it is unusual to merge address-nodes with buildings in the Netherlands. In Germany most of the standalone adress nodes are from Open-Data-Imports and they will be merged with the buildings. If you fell uncomfortable with the changeset I can also revert it.
Greetings
TheBlackMan

Top Teamarbeit!

Gruß
TheBlackMan

Hi,
die Tordurchfahrt ist eigentlich ein "Hausdurchbruch", das Erdgeschoss ist quasi nicht existent und somit ist ein Durchgang/Durchfahrt ermöglicht. Die aktuelle Verkehrslage ist mir leider nicht bekannt, dass wollte ich bei Gelegenheit noch prüfen. Bin leider noch nicht dazu gekommen. Da allerdings die Straße Wall am Kiez in einer Sackgasse/Wendekreis endet, ist die Durchfahrt aktuell wohl eher nicht gegeben ...
Grundlage fürs Mapping war das Foto des denkmalgeschützten Hauses unter: https://de.wikipedia.org/wiki/Liste_der_Baudenkmale_in_Potsdam/K#/media/File:Kiezstra%C3%9Fe_13_Potsdam.jpg
Den Tag sally_port habe ich auf Grundlage der Erläuterung unter osm.wiki/DE:Key:barrier verwendet: "Ausfalltor, Durchgangsschleuse - Ein Durchgang mit einem inneren und einem äußeren Tor" - in diesem Fall eigentlich nicht ganz korrekt, da es ja gar keine Tore gibt. (Anders als bei meinen anderen Verwendungen in der Potsdamer Innenstadt ;-) )
Die Tagbeschreibung auf der deutschen/englischen Key-Seite als Sicherheitsschleuse/Gefängniszufahrt ist auf jeden Fall "unglücklich"/"falsch" bzw. etwas eng gefasst. In der Key-Tabelle ist die Verwendung jedenfalls "breiter" und ich denke auch sinnvoller gefasst.

Gruß
TheBlackMan

Jetzt wo OsmAnd das noch besser implementiert hat, dachte ich mir, ist das mal dringend nötig ;-)

Hallo Ingo,
also wenn ich mir den Kartenausschnitt anschaue, dann sind deine Hausnummerneinträge in der Yorkstraße jetzt an der Außenlinie der Gebäude, also da wo der Eingang ist. In der Wilhelm-Staab-Straße, wo ich die Denkmalschutzinformationen gerade erst ergänzt habe, sind die Hausnummerninformationen in der Mitte der Gebäudeumrisse und die Eingänge, die ich detailliert erfasst habe, werden mir als kleines Kästchen ohne irgendeine Nummer angezeigt.
Wenn wir grundsätzlich in Potsdam die Adressdaten auf die Eingänge legen, dann mach ich das halt zukünftig so und die Gebäudehülle bleibt hinsichtlich der Adressen leer.
Ich hab halt nicht verstanden, was deine Änderungen sollten und wo da ein "Chaos" war.
Ich will auch nicht, dass wir uns hier streiten oder einen Tag-War vom Zaun brechen - immerhin ist das ja ein Hobby und Freizeitbeschäftigung.
Gruß

Sorry, für mich sah das nach dem klassischen Reihenhaus aus. Ich habe das wieder zurückgesetzt mit osm.org/changeset/68469591
Gruß

Hallo IngoWo,
warum hast du die Adressen von den Gebäudeumrissen entfernt und auf die Eingänge gelegt? Von Chaos zu sprechen, ist sowieso Blödsinn, denn grundsätzlich war alles korrekt getaggt. In der JOSM-Vorlage für Eingänge wird das ref-Tag vorgegeben, was meiner Meinung nach auch Sinn macht, denn so ist die Zugehörigkeit der Hausnummer abgebildet. Und eine Hausnummernangabe für ein Gebäude mit Hausnummern von-bis ist auch nicht falsch, insbesondere dann, wenn die einzelnen Eingänge korrekt gemappt sind. Für eine Erläuterung wäre ich dankbar.
Gruß
TheBlackMan

Ich kenne keins.
Ich fand interessant, wie wenige Mapper beim Berlin-Brandenburger-Stammtisch am Tisch sitzen. Glibbertorsten und ich waren letztes Jahr in Potsdam die Einzigen, der Rest hat sich ausschließlich mit Datenbankstruktur und -auswertung und Anwendungsprogrammierung befasst. Ein aufgeklappter Laptop und die Diskussion von Mappingdetails zwischen uns beiden hat es nach Aussage der anderen länger beim Stammtisch nicht gegeben.
Grundsätzlich ist es natürlich so, dass wir Mapper schon einen Erfolg in Form gerenderter Daten sehen wollen, was ja diese Changeset-Diskussion hinsichtlich der Darstellung von Wald auch wieder gezeigt hat.
Trotzdem hoffe ich, dass nicht demnächst stilisierte Hunde durch Teile des Grunewaldes laufen ... :-)

@streckenkundler: Aber das Rendering ist uns doch allen egal, denn wir taggen doch die Merkmale von geografischen Objekten in eine Datenbank und nicht in eine Karte ;-)

natural=wood, managed=yes müsste es doch sein, wenn ich den Link von glibbertorsten richtig verstanden habe. wood=Fläche, die von Bäumen bestanden sind; managed=yes = bewirtschafteter Wald.
Also forstwirtschaftlich bewirtschaftet wird der Düppeler Forst, aber bestimmt nicht der Park Babelsberg, der wird gärtnerisch gepflegt!

Ok, ich habe mich vielleicht nicht klar genug ausgedrückt - allerdings hat es dx125 irgendwie verstanden. Alles am Park Babelsberg ist künstlerisch gestaltet: Die Anlegung von Landschaftsparks im 18. Jahrhundert ist die Imitierung von Natur, auch von Wald. Die Absicht war eine möglichst abwechslungsreiche Vergnügungsstätte für den Adel zu schaffen. Dazu gehörte auch das Lustwandeln in einem (Ideal-)Wald, der entsprechend den Idealvorstellungen geformt und gepflegt wurde. Deswegen ist aus meiner Sicht alles Park.
Vergleichbar ist dies mit den Vergnügungsparks des 20. Jh., wo eine ideale Westernstadt nachgebaut wird, das ist dann aber noch lange nicht eine amerikanische Kleinstadt des 19. Jahrhunderts, mit amenity=salon usw. ;-). Wie dem auch sei, ich habe den Waldbereich mit natural=wood in changeset osm.org/changeset/68260503 ergänzt und entsprechend den aktuellen Luftbildern etwas angepasst.

Grundsätzlich stellt sich mir jetzt die Frage, hinsichtlich des Tagging-for-the-renderer Problems.
Der Park Babelsberg ist eine künstlich bewirtschaftete Parklandschaft. Jeder Baum, Weg, Parkbank usw. folgt einem vom Fürst Pückler erarbeiteten Gestaltungsplan, dem im Rahmen der Pflege als Weltkulturerbe gefolgt wird. In seiner Gesamtheit ist es also ein Park, was mit dem Tagging leisure=park richtig ausgedrückt ist. Soweit unstreitig.
Die Frage ist halt nun, ob man den Baumbestand in der Karte abgebildet haben will (also tagging-for-the-renderer): landuse=forest ist definitv falsch, da der Park nicht forstwirtschaftlich genutzt wird. Bleibt also natural=wood gem. Methode 1 von glibbertorsten.
Als (ehem.) ausgebildeter Parkführer im Pücklerschen Park Branitz in Cottbus, weiß ich allerdings, dass Pückler und die Landschaftsgärtner im 18. Jh. ihre Parks künstlich geschaffen haben - ggf. unter Einbeziehung eines natürlichen Baumbestandes - aber immer unter gestalterischen Aspekten, insbesondere hinsichtlich der Baumarten, deren unterschiedliche Blattfarben usw.
Ich finde daher, dass sich der Park in seiner Gesamtheit als Park darstellt und würde von dem Baumtagging eher absehen. Falls es die Mehrheit anders sieht, dann korrigiere ich das natürlich (wenn auch ungern ;-)

landuse=forest bedeutet, dass es sich um eine forstwirtschaftlich genutzte Waldfläche handelt. Das ist definitiv nicht der Fall. Der Park Babelsberg ist eine künstlich geschaffene und gepflegte Parklandschaft. Da ist nix forstwirtschaftlich genutzt. Das landuse ist tagging-for-the-renderer, damit Bäume angezeigt werden. Deswegen habe ich es auch nicht auf natural=wood geändert, da es ja keine "natürliche" Waldfläche ist.
Im Glienicker Park, im Neuen Garten und in Sanssouci ist das genauso für den Renderer getaggt, da müsste man eigentlich auch die ganzen landuse-Tags entfernen. Es sind halt alles künstliche Parklandschaften.

Danke für den Hinweis. Bin bisher davon ausgegangen, dass die Eigenschaften/Tags der Relation "vererbt" werden. Dem ist offensichtlich nicht so ;-)
Changeset osm.org/changeset/68228270 sollte für das passende Rendering sorgen :-)

Tja, da hab ich bei der Relation geschlampt, da ich eigentlich immer die Adresse daran mappe. Ist aber auch egal, denn wie du schreibst, besteht eine Relation von type=site aus Flächen und nicht aus einzelnen POIs. Hab somit jetzt die Relation gelöscht.
Ich bin froh, dass wir zwei uns hier in Potsdam so gut verstehen und die Missverständnisse immer im gegenseitigen Einvernehmen gelöst werden können ;-)

Hallo Torsten,
ich hatte ja die einzelnen Arztpraxen in einer Relation "Ärztehaus Am Holländischen Viertel" zusammengefasst und die Relation mit der Adressangabe versehen. Zudem befinden sich ja die einzelnen Praxen auch innerhalb des Gebäudeumrisses Kurfürstenstraße 19. Eigentlich braucht es doch dann nicht noch die Adressangabe an jedem einzelnen POI? Nach meinem Verständnis erfolgt die Adressübernahme doch durch die Relation bzw. durch den Gebäudeumriss - was somit schon "doppelt" war. Jetzt gibt es die Angabe 14x ;-)
Gruß

Guten Morgen,
ich checke das Öffnungszeitentagging immer mit dem opening_hours Auswertewerkzeug und bei Kommas kommt da kein Leerzeichen. Im Wiki kommt zwischen den Wochentagen bei Kommasetzung auch kein Leerzeichen. Einen Flame-War werde ich bestimmt nicht mit dir anfangen, dafür läuft doch unsere Zusammenarbeit viel zu gut.

Hallo Arndt,
ist ok, wenn was falsch ist, soll es ja korrigiert werden. Allerdings frage ich mich, was da falsch war? In JOSM hat er es mir korrekt angezeigt. Aber eigentlich war die TR eh wahrscheinlich überflüssig, da für die Renderer klar sein sollte, dass man nicht in die Einbahnstraße abbiegen darf ;-)

Gruss TheBlackMan

JOSM: Objektvorlagen "Gehwege, Randsteine & Eingänge für Rollis" ;-)
Mach ich an Hand der Fotos von Wikipedia bzw. der Webseitenfotos.

Hallo mondstern,
schön, dass du bei OpenStreetMap in Potsdam mitmachst. Leider sind deine letzten Änderungssätze der Friseure von cut+care family z.T. fehlerhaft. Insbesondere die deutschen Öffnungszeitenangaben entsprechen nicht dem englischsprachigen Taggingschema. Schau dir doch mal im Wiki die Seite zu opening_hours (osm.wiki/DE:Key:opening_hours) genau an. Unter https://openingh.ypid.de/evaluation_tool/?setLng=de gibt es zudem ein tolles Auswertewerkzeug, das dich auf evtl. Fehler hinweist.
Zudem ist in Potsdam die Verwendung des contact-Schemas für die Kontaktangaben zu Internetseite, Tel-Nr. und E-Mail üblich.
Ich habe deine Änderungssätze bereits berichtigt.
Weiterhin frohes mappen
theblackman