OpenStreetMap
krza's Comments
| Changeset | When | Comment |
|---|---|---|
| 185888509 | PS: Die Tags "orientation" und "parking" machen in dem Zusammenhang übrigens auch keinen Sinn (bzw. sind sogar falsch), da der Bezugspunkt (die Straße) fehlt. |
|
| 185888509 | An der Stelle kann man sein Auto abstellen, auch zwei. Aber wenn man das nicht weiß, deutet nicht viel darauf hin, dass es eine Fläche zum Parken ist. Das ist einfach nur ein freies Stück Gras am Haus. Ich bin nicht sicher, ob da ein Schild mit Parken-Bezug an der Wand hin oder nur der Hinweis auf die Bildhauerei. Jedenfalls empfinde ich den Punkt als angemessener als die Fläche. Ganz gemäß dem Grundsatz: Wir taggen nicht für den Renderer, sondern bilden die Realität ab. Die von Dir wieder eingezeichnete Fläche suggeriert etwas, das schlicht nicht existiert. Ein Punkt hingegen meint einfach nur, dass man da parken kann, ohne aber Aussagen darüber zu treffen, wie dieser Parkplatz aussieht. In meinen Augen eigentlich eine ziemlich klare Sache. |
|
| 72859503 | Linie: 709252151
Linie: 709252158
Linie: 709252152
Linie: 709252154
Linie: 709252153
Linie: 709252156
Linie: 709252150
Linie: 709252149
Linie: 674066149
|
|
| 72859503 | Moin. Der highway=proposed kann doch sicher inzwischen weg, oder? Ich löschen den jetzt mal bis auf die beiden Anbindungen 709252157 und 709252155, die aber vermutlich auch nicht mehr kommen werden. Im nächsten Kommentar stehen die Infos zu den gelöschten Wegen. |
|
| 176948774 | see changeset/176984353 for details |
|
| 176984353 | Main changes beside some additional minor changes and adjustments: - landuse=forest --> natural=wood (see according key definitions for clarification)
Changeset 1: 176948774
|
|
| 166162364 | Danke! |
|
| 167605086 | Zu prüfen wäre vielleicht, ob die nordöstliche Spitze des Parks (498278335) formal noch zum Park gehört, weil diese Fläche ja schon außerhalb der Mauern liegt. |
|
| 158728904 | Reaktion von Deiner Quelle: "vielen Dank für Ihre Mail. Ihe Frage bezieht sich auf den Sehenswürdigkeiten-Artikel. Dieser bedient sich bei solchen Informationen auch nur bei öffentlich einsehbaren Daten. Da ich leider auch keine aktuellen Informationen beim Bezirksamt finden konnte, würde ich dem Schild am Park vertrauen. Ich werde auch den Artikel anpassen." Also werde ich mal auf 16 Uhr zurückstellen ;) |
|
| 158728904 | Ah, danke. Das hatte ich spontan nicht gefunden. Hm. Vermutlich stimmt das dann, und man hat die Schilder nicht erneuert. Lässt sich aber erst im Herbst wieder überprüfen 😉 |
|
| 158728904 | Moin, Du hattest die Öffnungszeiten angepasst. Allerdings frage ich mich, auf welcher Basis? Oder wurden die inzwischen wieder zurückgeändert? Also laut Beschilderunge ist es noch immer (oder wieder) 16 Uhr und nicht 18 Uhr. |
|
| 166162364 | Hi Ralf, in Organic Maps mit den Daten vom 11. Mai steht noch die Baustelle drin, einen Tag später hattest Du das Parkhaus "errichtet". Das hatte ich am Sonntag auch gesehen. Was ich aber nicht mehr gesehen habe, war der Parkplatz ein Stückchen weiter südlich*. Wenn mich nicht alles täuscht, war ich da an einem Rohbau vorbeigefahren, wo ich eigentlich parken wollte ;) Falls das wirklich so war ... Du scheinst ja Ortskenntnis zu haben ... vielleicht wäre es möglich, den Parkplatz dort zu einem Gebäude zu machen (dann ist das in der Historie besser zu erkennen, als wenn man das Ding löscht und durch ein Gebäude ersetzt, wie Du es wohl oben gemacht hattest) und auch die andern beiden Parkplatz-Objekte und die 5 Parkstraßen zu entfernen. Ich würde es ja auch machen, kenne aber die Situation vor Ort nicht. Achso, und die Mülleimer gibt es vermutlich auch nicht mehr ;) Danke! |
|
| 166701190 | > vorab: der Änderungssatz ist zu groß. Welchen meinst Du? Meinen? Der enthielt doch nur 3 Objekte. > wie du hier ... vielleicht gesehen hast Nein, sorry, hatte ich nicht gesehen. > „ist das contacts-Schma kein Ersatz für das Adress-Schema, weder definitionsgemäß, noch von der Logik her“ Wiki: For use when the contact address is not the same as the address of the physical location. Den "contact"-Key würde ich so beschreiben wollen, dass er alle Kontaktinformationen bündelt, die mehr oder weniger "virtuell" sind, also über die physischen örtlichen Informationen hinausgehen (bei einem Festnetz-Telefonanschluss könnte man noch drüber streiten, wenn man sehr penibel ist, aber bei sowas wie Webseiten sollte es klar sein). Es gibt durchaus Fälle, in denen die Kontaktadresse anders ist als die physische. Das ist hier aber nicht der Fall. Abgesehen davon ... wenn man dann schon mit dem Schema arbeitet, sollte man wenigstens konsequent sein und die Webseite dort einbeziehen, auch wenn es rein statistisch vielleicht nicht ganz klar ist, was häufiger verwendet wird bzw. nur "Altlast" ist. > 2. „Und eine physische Adresse muss auch nicht explizit ausgewiesen sein.“
Auch das Ground-Truth-Prinzip hat seine Grenzen. Wenn man es wörtlich nehem würde, dürfte man z.B. keine Postleitzahlen taggen und auch nur bei sehr wenigen Gebäuden die Straßennamen. Du weißt, worauf ich hinaus will. Darüber hinaus wüsste ich nicht, warum ein "contact"-Key von diesem Prinzip ausgenommen sein sollte, der "addr"-Key aber nicht. Interessanter ist das vermutlich z.B. beim "name"-Key, bei dem man sich ja wirklich an die vorgefundene Realität halten sollte (wobei ich trotzdem keine offensichtlichen Schreibfehler auf Schildern in Tagging übernehme). Grundsätzlich kann man aber hier die Frage aufwerfen, wie man mit POIs und Adressen umgeht (auch wenn ein Changeset-Kommentar nicht der richtige Ort dafür ist). Man könnte sagen, dass man nur dem Gebäude (das meines Wissens übrigens sehr wohl eine sichtbare Hausnummer hat irgendwo) eine physische Adresse gibt, den einzelnen Läden oder Einrichtungen aber nicht, wenn sie nur Teil des Gebäudes sind. Die Logik dahinter wäre, dass man vom umschließenden Gebäude auf die Adresse schließen kann. Rein semantisch ist das eindeutig, technisch eigentlich auch (für einen Renderer), nur ggf. mit mehr Aufwand verbunden. Aber hier kommt dann wieder "wir taggen nicht für den Renderer" ins Spiel, auch wenn es manchmal vielleicht besser wäre ;) Wenn man sich also steif an den (losgelösten) Satz aus der Wiki oben hält, sollte man die physische Adresse aus dem "contact"-Key rauslassen und entweder den "addr"-Key verwenden oder das umliegende Gebäude damit versehen. Letzteres halte ich wie gesagt für sauber, aber ich tagge ehrlich gesagt die Adressen auch oft an POI-Knoten, weil viele Karten- oder andere Tools eben leider nicht die schließenden Gebäude bei der Darstellung der Adressen berücksichtigen, obwohl es rein technisch möglich wäre. Man hat dann also im Zweifel eine Redundant und im schlimmsten Falle soger ein doppeltes Rendering der Hausnummer, was ja beides auch nicht im Sinne des Erfinders ist. |
|
| 162274782 | Moin, bei einem Aspekt hatte ich mich vom visuellen Rendering auf die falsche Fährte führen lassen, beim anderen ist es eine Frage, wie konsequent man es auslegt und taggt. Ich kann es aber bei nun korrekter Betrachtung so nachvollziehen, denke ich. Danke. |
|
| 162274782 | Hallo Mond, ich habe ein Problem mit Deinen Sidewalk-Ergänzungen. Sie doppeln in den von mir eben gesehenen Fällen erstens separat erfasste Fußwege und sind auch inhaltlich wegen der baulichen Situation nur bedingt sinnvoll. Es wäre also gut, wenn man die Tags an den betroffenen Straßen wieder entfernen könnte. Die Nutzung von Skripts und Tools (hier scheint ja sowas genutzt worden zu sein) sollte immer mit Vorsicht erfolgen, um solche Fehler zu vermeiden. |
|
| 149808725 | Okay, jetzt sehe ich, worauf Du mit den Gebäuden hinaus willst (Overpass-Link). Allerdings habe ich mit diesen Gebäuden überhaupt nichts zu tun. Eigentlich. Ich weiß also nicht so recht, wie ich es "geschafft" habe, sie zu verändern. Eigentlich hatte ich mir nur den Teil heruntergeladen, der mich betraf, und das waren 3 Objekte. Eins davon war ein Gebäude, das ich auch layer-frei gelassen hatte, weil korrekt. Das andere waren die beiden Flächen, denen ich wieder einen Layer gegeben hatte. Wie die anderen Objekte jetzt da reingeraten sind, weiß ich gerade auch nicht. In JOSM zumindest waren sie mir nicht aufgefallen. Mit anderen Worten: Ohne die anderen Gebäude jetzt angeschaut zu haben, ist dort vermutlich jeweils kein Layer erforderlich, stimmt. Nochmal zu den Flächen: Ich weiß nicht, ob Du das mit dem level-Key verwechselst oderso, aber der layer-Key wurde genau für sowas erfunden. Das hat auch nichts mit "in der Luft schweben" zu tun. Es ist kein 3D-Key, sondern ein Ordnungs-/Sortierungs-Key, wenn man so will. |
|
| 149808725 | Wie oft denn noch: Es ging nicht um Gebäude (dazu htte ich ja im anderen CS was geschrieben), sondern um genau 2 Flächen. Und diese beiden Flächen habe ich wieder mit dem Layer versehen, weil sie sonst mit der darunter liegenden Parkplatzfläche kollidieren. Ganz einfach. |
|
| 149881039 | Es geht hier nicht um nachgeben. Du sagst ja selbst: No tagging for the renderer. Wir taggen die Realität, und der addr-Key ist nun einmal für die postalische Adresse gedacht. Das wurde im Forum damals auch nicht nur von mir klargestellt. Daran gibt es eigentlicht nichts zu deuten. Die PLZ ist keine geografische Angabe, sondern ein administratives Merkmal, das zur Postzustellung dient. Nicht mehr und nicht weniger. Daran ändern auch nichts, dass viele glauben, dass die PLZ zum Navigieren oderso benötigt würde. Das ist aber schlicht falsch. Sie hilft nur in Fällen, die sonst nicht eindeutig wären. Das ist ja auch sinnvoll, ändert aber am Grundprinzip nichts. Ob eine PLZ eine Großkinden-PLZ oder eine andere ist, spielt für OSM keine Rolle. Wir taggen nicht für den Renderer, sondern die Realität. Und die Realität ist ganz einfach: Die postalsche Adresse der Ford-Werke GmbH weist die PLZ 50725 auf. Punkt. Und was anderes kann also auch nicht getaggt werden. Insofern sehe ich die damals gemachten Vorschläge auch kritisch, weil sie das Prinzip ignorieren und verbiegen wollen. Wenig überraschend ist da ja auch nichts bei rausgekommen, wie es aussieht. Man kann den Thread gerne nochmal wiederbeleben, um nach neuen Lösungen zu suchen. Diese sollten sich aber an der Realität und nicht an den Wünschen irgendwelcher Tagger orientieren. Knackpunkt ist, dass addr:postcode nicht verändert ist, weil das korrekt ist und immer die offizielle PLZ enthalten soll. Der Wunsch, auch eine geografische Information zu ergänzen, mag berechtigt sein, auch wenn er rein formal irrelevant ist. Das führt uns aber dazu, dass man ergänzende und nicht ersetztende Tags oder Angaben generiert. Hier könnte man z.B. mit addr:postcode:type arbeiten, in dem man auf die GK-PLZ hinweist. Zusätzlich kann man sich ein addr:postcode:local oder addr:postcode:geo oderso vorstellen, wo man dann die "geografische" PLZ einträgt. Das wäre zwar eigentlich eine Art Tagging für den Renderer, aber man kann es auch als relevante Information bezeichnen, die es Systemen erleichtert, dieses Objekt einer physischen Position zuzuordnen. Und wie gesagt, im Falle des Tors hat natürlich die GK-PLZ nichts verloren. Da gehört die lokale PLZ rein, weil es sich um eine Besucheradresse handelt. Und so ist es momentan ja auch getaggt. Der Hinweis auf Baden-Würtemberg kam übrigens daher, dass Du aus einem 50769 ein 70769 gemacht hattest. Warum auch immer. Du hattest also im Grunde Deine eigene Wunsch-PLZ verstümmelt ;) |
|
| 149881039 | Wir erfassen im addr-Key die Adresse und sonst nichts. Und die PLZ ist nun einmal so, wie sie ist. |
|
| 149852606 | Ja, das steht dort. Aber es steht dort unter "Anfahrt", bezeichnet also einen konkreten Ort in Merkenich. Das Tor hat ja auch die 50769 erhalten, weil es quasi "nur" der lokale Anlaufpunkt ist, die Besucheradresse. Aber noch einmal: Die Ford-Werke an sich haben eine Großkunden-PLZ, und zwar die 50725. Das ist die offizielle PLZ dieser Institution, und sie gilt sowohl für Merkenich als auch für Niehl, und in Niehl ist auch der offizielle Hauptsitz. Um die Verwirrung komplett zu machen, listet die Post sie daher beide gleichzeitig auf, wenn man dort nach den Ford-Werken sucht. Die Frage ist hier vielleicht, wie man die postcode-Angabe versteht. Aber sie ist Teil der Adressdaten und somit ein administratives Merkmal und nicht notwendigerweise ein geografisches. In OSM wird das leider weder genau definiert, weil diese Art von Sonderfällen einfach nicht thematisiert werden, noch gibt es eine weitere Detailstufe, die man zusätzlich verwenden könnte. Vielleicht sollte ich die Adresse aus dem Namensknoten komplett rausnehmen und wieder auf den reinen Namen zurückgehen. Der macht es schwierig genug im Zusammenhang mit einer Adresse, weil es offenbar auch keinen "Adresszusatz" gibt in OSM, in dem man ihn unterbringen könnte.Die Adresse kommt dann an das Firmengelände, auch wenn da sicher auch wieder jemand was dran auszusetzen hat ;) |